Date:        Tue, 6 Nov 2001 10:35:39 +0200 (EET)
    From:        Pekka Savola <[EMAIL PROTECTED]>
    Message-ID:  <[EMAIL PROTECTED]>

  | Or is there something I've missed?

First, I certainly have no objection to the use of /126 for p2p links
(or wider masks if the organisation so desires) - not only does it avoid
your current concern, but its also just slightly cleaner.

However, I don't think it is required - anycast addresses are syntactically
identical to unicast addresses for many reasons.

All that's required of an anycast address is that packets get delivered to
something in the appropriate class.  How the decision of which particular
something is made isn't defined, and shouldn't be.

There are 3 cases to consider for a p2p link using a /127 in this:

Both end points connect to routers.

One end point connects to a router, the other to a host.

Neither end point connects to a router, it is a private link
between two hosts.

The third case is easy - there are no routers, so no need for any
router anycast addresses, no problem at all.

Where one end is a router, that end would need to have the xxx0 address,
then packets sent to that address would arrive at the (only) router on
the link.   That's exactly what is required.  It suggests that where
addresses on the link are auto-configured, a node that is a router should
always try for the xxx0 address first, falling back to the xxx1 address
only if the other node is a router.  It also suggests that hosts should
act the other way - always try the xxx1 address first, falling back to the
xxx0 address only if the other node isn't a router.

Where both ends are routers, then all the anycast address requires is that
one of the two of them receives the packet.   It doesn't suggest which one.
So, if one has the xxx0 address, and the other has the xxx1 address, then
normal unicast packet forwarding will get the packet there.

Note, that on a p2p link using a /127 this way, we know there will be
exactly 1 router using the anycast address - so, the reasons for prohibiting
use of anycast addresses for certain purposes all vanish.  No-one else can
tell that it is an anycast address (only a configured node knows for sure),
so in this case there's no reason at all the node can't simultaneously use
the address as its unicast addr, and as the defined subnet-router anycast
address.

Hence, I don't see any problem that needs fixing.

kre

--------------------------------------------------------------------
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]
--------------------------------------------------------------------

Reply via email to