Pekka Savola wrote:
>
> On Thu, 2 May 2002, Brian Haberman wrote:
> > Pekka Savola wrote:
> > >
> > > On Thu, 2 May 2002, Brian Haberman wrote:
> > > > I had actually started taking a crack at this whole problem. It
> > > > seems to me that the following components are needed for some form of
> > > > global anycast support:
> > > >
> > > > 1. Host-to-router notification protocol (this is taken care of by
> > > > changes to mld proposed in draft-haberman-ipngwg-host-anycast)
> > > >
> > > > 2. Security: at a minimum some form of authentication to allow
> > > > routers to determine if hosts are allowed to join an anycast
> > > > group
> > >
> > > You're making assumptions here.
> > >
> > > Hosts could very well participate in routing protocols.
> >
> > I don't think I am making assumptions. If a node is injecting routes,
> > it is a router. It may not be a member of the trusted set of routers
> > though. That is where the security comes in. If operators want to
> > protect the set of nodes that can inject routes, they can do so by
> > securing the routing protocol exchanges.
>
> No, if a node is injecting routes, it needs not to be a router, as
> specified in RFC2460 and referred to in addrarch.
>
> The definition:
>
> router - a node that forwards IPv6 packets not explicitly
> addressed to itself. [See Note below].
>
> DNS servers could participate in the routing protocol, injecting a route
> to itself, while still being hosts.
>
> Usually the definition of router also includes forwarding packets between
> interfaces, but that's only implicit here.
I am not disagreeing with what you are saying. I was pointing out
that if a host is injecting routes then an operator would be wise
to ensure that the host is a trusted entity (i.e. uses authentication
keys in the routing protocol messages).
>
> > > > 4. Possibly a draft that documents any impacts on any existing
> > > > protocols (routing protocols, TCP, etc.)
> > >
> > > Unicast RPF is capable of killing anycast with source addresses quite
> > > effectively.
> >
> > Not sure I follow you. The anycast addresses are in the destination
> > address field.
>
> You mentioned a host-to-router notification protocol, so we're discussing
> what would be different if anycast requirements are changed (not as a
> source address, not on a host).
>
> Anycast addresses as source addresses (if allowed) have some amount of
> problems.
Actually, all of my work so far has been based on the assumption that
the rule about anycast addresses being in the source field will not
change.
Here is a very quick example:
A ------ Rtr1 ----- Rtr2 ----- B
A wants to join the anycast group FEC0::1234. It sends an MLD Report
containing that address in the Group Address field. The Report is
sent with an Authentication Header based on the group address. Rtr1
receives the Report and validates the key. If the key is correct,
then Rtr1 can inject a host route for FEC0::1234. Now, when B wants
to communicate with FEC0::1234, Rtr2 will know to send the packets
via Rtr1. The response back from A will use A's unicast address in
the source address field. How will B know that the response came
from a member of FEC0::1234? Well, one possibility would be to have
a Destination Option similar to the Home Address option that holds
the anycast address and can be secured with a security header.
This keeps the anycast address out of the source address field.
And that will minimize the impact of unicast RPF checks stopping
the packets.
Now, this is still a very rough idea, but an anycast address option
may well help address many of the issues that Itojun pointed out in
his anycast analysis draft. Of course, there is still a lot of work
to do, issues to iron out, code to write...
Regards,
Brian
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
