IPv6 network policies

[Ole Troan]

Mark,

>>>> NUD could be done, but on most router to router links it is
>>>> unnecessary and not used.
>>>> 
>>> 
>>> I suppose this comes down to if you don't agree with (or maybe just
>>> don't fully understand) the way something works in an RFC, does that
>>> mean it's ok for you not to implement it the way the RFC says?
>> 
>> good to hear that you are the authority on how RFC4861 should be read (note this may be sarcasm. ;-)).
>> please point us to the sections in RFC4861 which require an implementation to do address resolution on a link without L2 addresses. and if it is not address resolution, which part of ND are you referring to?
>> 
> 
> I've quoted the sections of that RFC (and it's ancestor) twice to this
> thread already that support this view. I've also looked through the ND
> RFCs for any statements that specifically refer to the operation of ND
> over P2P links, and what is optional. I can't find any.
> 
> It's well known that the pong pong problem doesn't exist if ND
> NS/NAs are used.

I presume by saying "NS/NA", you mean the address resolution function of ND.
see section 7.2:

   "Address resolution is the process through which a node determines the
   link-layer address of a neighbor given only its IP address.  Address
   resolution is performed only on addresses that are determined to be
   on-link and for which the sender does not know the corresponding
   link-layer address (see Section 5.2).  Address resolution is never
   performed on multicast addresses."

in particular see "does not know the corresponding link-layer address".

then on section 7.3:

   "Neighbor Unreachability Detection is used for all paths between hosts
   and neighboring nodes, including host-to-host, host-to-router, and
   router-to-host communication.  Neighbor Unreachability Detection may
   also be used between routers, but is not required if an equivalent
   mechanism is available, for example, as part of the routing
   protocols."

it is pretty clear that the current behaviour is expected and fully compliant with the IPv6 RFCs.

if you want that behaviour changed, then write an Internet draft. you will have much more luck with that approach than suggesting that implementors of IPv6 stacks don't understand the RFC.

the ping-pong problem is already covered in RFC4443. other workarounds available today are the use of /128, link-locals only, /127, /64 with ACLs...

the solution you propose, 'pseudo address resolution on link-types without L2 addressing', requires spec changes.

cheers,
Ole