IPv6 network policies

[Mark Smith]

On Sun, 11 Apr 2010 20:15:43 +0200
Ole Troan <otroan at employees.org> wrote:

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

I don't agree, because I would consider knowing a link layer address
doesn't exist (verified by the absence of a NA in response to an NS) as
significantly different from assuming it exists, which is your
position. The latter position is what is causing the ping-pong problem.

Without ND NS/NA on a P2P link, you're always assuming an address must
exist, and as IPv6 ND doesn't special case P2P links, and says to treat
them as nothing more than multicast links, then only the IPv6 longest
match rule can be used to determine that. A point to point link in
IPv6 can only be recognised by a /127 prefix length - anything shorter
and you're saying to IPv6 one of two things:

(a) all the non-local addresses are assigned to the device at the other
end of the link

(b) the address exists somewhere within the link, and therefore an ND
NS/NA transaction should take place.

As /127s aren't and haven't ever been specified in IPv6 Addressing
RFCs, then that says to me that ND NS/NAs are expected on all links.

But that's my interpretation. I think a lot of the IPv6 RFCs support
that model - in the least the current IPv6 Addressing Architecture RFC
doesn't support prefix lengths greater than a /64.


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

I wouldn't qualify a point to point link being a routing protocol. I'd
interpret that to mean the neighbor recognition / availability
mechanisms in e.g. OSPF.

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

Unfortunately none of those are solutions that suit a scenario I'm
working on. I can't guarantee the routers support RFC4443 (which
includes ADSL CPE), and none of the other options are scalable to 100K+
ADSL PPP/PPPoE subscribers.

I'll email to the v6ops mailing list for answers as to what to do, as I
can only use RFC compliant solutions because I'm working in a very
vendor diverse environment.

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