IPv6 network policies

[Mark Smith]

Hi Steinar, 

On Sat, 10 Apr 2010 16:38:16 +0200 (CEST)
sthaug at nethelp.no wrote:

> > > What I'm looking for is from _only_ those that use it, is how you
> > > document it, example config snips, if/how you reserve around it and from
> > > a topology standpoint how you alloc/assign it. I'm sorry, but I'm
> > > talking about /126 or /127 for ptp.
> > 
> > That may be a false fear. In the last week I've tried to cause this
> > issue under IOS 12.3.20 (i.e. quite a number of years old) over a
> > serial link, and no matter what I try, I cannot make it happen. I've
> > tried both HDLC and PPP encapsulations, conventional address assignment,
> > as well as using static interface routes for a /64 pointing out the
> > serial interface on both routers at both ends of the link. RFC4443
> > (ICMPv6) specifies the rule against forwarding packets back onto the
> > point-to-point link it was received on, and it seems IOS has been
> > RFC4443 compliant for a number of years.
> > 
> > I haven't tried it on a p2p POS link. I can organise a test one,
> > however with what I've found with a vanilla serial link, I'm wondering
> > if it is worth the time.
> 
> I have a lab setup with an STM-4 link between a Cisco 12404 running
> IOS XR 3.9.0 and a Juniper M7i running JunOS 9.5R4.3. The loop is very
> clearly evident here, for anything other than /127 on the link. Can be
> reproduced at will.
> 

So it seems that the difference might be hardware vs software
forwarding implementations.

> > I don't have Juniper equipment to play with, however they are also now
> > claiming RFC4443 compliance for Junos 10.1.
> 
> That sounds like a good test for the lab.
> 
> > What I also discovered was that Linux and IOS aren't implementing
> > complete Neighbor Discovery (i.e. NS/NA) on P2P links, and full ND
> > NS/NA implementations won't suffer from this issue. I've started looking
> > to find in the IPv6 RFCs if not implementing NS/NA on P2P
> > links is allowable. I haven't found so in the Neighbor Discovery RFC
> > and neither so in the IPv6 over PPP RFC. The current IPv6 Node
> > Requirements RFC, which applies to both end-nodes and routers, also
> > says ND NS/NA must be implemented on all links.
> 
> As far as I can see on the IOS XR and JunOS boxes I have tried with,
> ND is *not* performed at all on p2p links.
> 

I found a couple of other things that I found that might be
interesting to verify or test in your lab.

Firstly, I did find that the IOS version I tested had DAD enabled by
default, and was performing it (i.e. an NS/NA transaction for the new
address). The 'show ipv6 interface' output will show what the DAD status
is. In the case of PPP encapsulation, this is despite the IPv6 PPP RFC
recommending it is switched off, excepting a few cases that my test
scenario doesn't satisfy. I'd think if these implementations are
interested in optimising away general NS/NA on P2P links, they'd also
default DAD to off on them too.

Secondly, if you view the subscribed IPv6 multicast groups on the
interface, the interface is subscribed to IPv6 solicited node groups
for addresses that have been assigned to it.

If those same observations carry through to hardware platforms such as
the ones you have, that says to me that the interfaces have all the
mechanisms required to perform full, general ND, with the only thing
missing i.e disabled, is a neighbor cache and ND NS/NAs for addresses
that fall within the subnet. IOW, fixing the ping pong issue should be
as simple as a fairly straight forward change to the code to stop
treating P2P links as a special case.


Regards,
Mark.