IPv6 network policies

[Mark Smith]

On Fri, 09 Apr 2010 19:35:23 -0400
Steve Bertrand <steve at ibctech.ca> wrote:

> ...while I'm at it, I might as well ask a couple other questions that
> I've been contemplating recently.
> 
> My network is _just_ under the size that two people can manage. We keep
> extensive documentation on almost absolutely everything (mostly automated).
> 
> There are a couple of areas that are grey and sketchy though. One of
> these areas is ACL management.
> 
> Although I use uRPF for everything, this doesn't fix the areas where
> ACLs are still needed (and in fact, I have ACLs in place on top of uRPF).
> 
> An issue that I notice from time-to-time, is that I have an interface
> that has the appropriate v4 ACLs applied, but the v6 ones have been
> forgotten. What do other operators do to ensure consistency on ACL
> application in regards to both protocols?
> 
> The other 'question' I have is regarding a very sensitive area. I do not
> want to get into a war about this. I figure that this list is exactly
> where I should ask.
> 
> 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 don't have Juniper equipment to play with, however they are also now
claiming RFC4443 compliance for Junos 10.1.

I did find that Linux does suffer from it.

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. I'd think the ND RFC
would be authorative on this, and it says:

     point-to-point - Neighbor Discovery handles such links just like
                      multicast links.  (Multicast can be trivially
                      provided on point to point links, and interfaces
                      can be assigned link-local addresses.)  Neighbor
                      Discovery should be implemented as described in
                      this document.


So it seems to me that the IPv6 protocol is being blamed for a problem
that has been created by not implementing ND completely on P2P to
links. If there is no text in RFCs allowing ND NS/NAs to be avoided on
P2P links, then I wonder what impact that has on claims of IPv6
compliance that these implementations might be making.

> I must admit, I am concerned with
> ping-pong and no real easy way to combat it, so I'd like operational
> feedback and education from those that use them without any traditional
> strong opinions from those that oppose it (if possible :)
> 

Make sure you read RFC3627. While it's title directly refers
to /127s, it also covers some of the issues in using prefix lengths
other than /64. In particular, the requirement to clear bits 70 and 71
correctly in all prefix lengths longer than /64s seems to be commonly
overlooked. It does exist for /64s too, however as people commonly use
static assignments starting at the least significant IID bits
(i.e. :1, :2 etc.), and aren't likely to or need to create a node
address hierarchy, these bits are cleared without active
intention. As it's more likely that subnetting bits are
going to structured with aggregation boundaries, then there needs to be
a conscious effort to ensure they're always cleared.

Regards,
Mark.