On Tue, 6 Nov 2001, Robert Elz wrote:
>   | Router B plugged in the network with Router A (e.g. cross-over cable).  
>   | Neither has anything configured or set up yet on this link. 
>   | 3ffe:ffff::1/127 address is added to Router A; now it DAD's for 
>   | 3ffe:ffff::1 (normal address) and, being a router in the subnet, also
>   | 3ffe:ffff::0, and succeeds.
> 
> My point was that it must not.   That is, if there are to be two nodes
> on a link, and there are two addresses available, it is positively insane
> for one of the two nodes to take both of them.

Sure..
 
> If it wants (either via some config file, or just random chance) to pick
> the xxx0 address, then it gets to be the target of the anycast.  If it
> doesn't, then it doesn't...
> 
> It can't pick the xxx1 address for itself, and then go ahead and also
> pick the xxx0 address to be anycast.   If an I-D needs to be written to
> make this (self-evident) truth clear, then I guess we should write one.
> 
> I know that the normal use of anycast is for everyone eligible to assign
> themselves the address, but there's nothing in the definition that requires
> that - this just happens to be a scenario where that is inappropriate
> behaviour.

.. but as you noted, this is different from the "normal" use of anycast.  
This operational/technical restriction has not been discussed anywhere
(AFAICS).  It'd be pretty optimistic to assume every implementation would
do the "right" thing (contrary to "do it by the spec").
 
>   | The fact remains, as shown in the scenario above, that on router-router
>   | links, using /127 is impossible unless subnet-router anycast addresses are 
>   | restricted or disabled.
> 
> No, go back to my first message - it isn't impossible at all.  It just
> needs rational considered implementations.

Sure.  This approach would case the following, I suppose:

 1) (at least almost) everybody implements by the spec (thinking of
"normal procedure")

 2) some implementation, later, notices this problem, discards it by
giving operational advice; "don't do /127 ptp"

 3) some implementation, later, notices this problem, fixes it by a few
rational rules, but if the other end of the pipe is non-rational,
everything can still break.

 4) there will be non-rational implementations forever

I believe, the only thing there is to nail this for good is to either/and:
 - make it widely known that this should be operationally avoided
 - specify the rational behaviour of anycast assignment in this case
 
> If anything, what we have now when systems use /127 for p2p links is
> the use of the subnet-router anycast address ready made (even though
> most probably the nodes don't know that's what they're doing, and in the
> rare cases when one end is a host rather than a router, the host might
> have the subnet-router address inappropriately).   Everything is working
> just like it should.

This is an illusion that will break.  Nobody that I know of implements
subnet-router anycast address yet. (just checked Linux, FreeBSD 4.4,
Cisco), so this is not yet a problem that it would be one day.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

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