IPv6 network policies

[Mark Smith]

Hi Gert,

On Sun, 11 Apr 2010 11:15:38 +0200
Gert Doering <gert at space.net> wrote:

> Hi,
> 
> On Sat, Apr 10, 2010 at 09:21:00PM +0930, Mark Smith wrote:
> > What I also discovered was that Linux and IOS aren't implementing
> > complete Neighbor Discovery (i.e. NS/NA) on P2P links, 
> 
> I always wondered why anyone would *want* to implement ND on P2P links.
> 

Because you want the simplicity of /64s everywhere, and it's simpler to
try to minimise the differences between link layers - to have IPv6
treat them as alike as possible. Nearly all link layers support
multicast, so all IPv6 ND requires is a multicast capability. That's
why the ND RFC doesn't make very many link layer specific statements -
it doesn't have to. IPv4 was different in this regard - neighbor
discovery protocols were an add on, rather than being designed in from
the outset.

> After all, you know that there is only two entities on the link, so if
> the packet isn't for you, it must be for them

Whether or not an address is offlink or onlink is a dependent on the
prefix length of the subnet assigned to the link, and subnet prefix
length is a property of a layer 3 protocol, not a layer 2 one. If the
prefix length says there are more than two addresses, and the protocol
doesn't make point-to-point links a special case for neighbor
discovery, then layer 3/layer 2 address resolution needs to take place.

> - and there is no need to
> construct a l2 address header for POS or PPP links.  So all "full ND"
> gains you is "more overhead" and "larger attack surface on the router".
> 

The key thing you're not stating is the assumption that you are allowed
to have prefix lengths greater than /64. That hasn't been the case and
currently isn't the case with IPv6, according to the RFCs. Obviously
people are lobbying for /127s, with one of the justifications being
this lack of ND NS/NA implementation on P2P links. IOW, it's the result
of an implementation choice, not what the protocol specified.

The "more overhead" is two packets, and an occasional NUD query, so I
don't think it really justifies this optimisation. If your control
plane is that overloaded then you've probably got much bigger problems
like BGP dropping sessions etc.

I'm presuming the "larger attack surface" you're referring to is the
neighbor cache DoS? That's not specific to P2P links, and either also
justifies switching off ND NS/NA for LANs, or abandoning /64s for LANs
too, or changing ND NS/NA operation so that it isn't vulnerable. I'm in
favour of the latter. There have been one or two proposals to address
it, and I'm thinking about making one myself.

> Yes, the corrolary is "packets might loop", but this is what RFC4443
> takes into account.
> 


People might think I'm being a pedant or too theoretical. I'm not. Here
is my problem. When I encounter equipment which isn't operating as I
expect e.g. may have a fault, at some point one of troubleshooting
steps I follow is "how should it be working", and for that I go
to the RFCs. If the behaviour then doesn't match what is in the RFCs,
when the implementer has claimed compliance with it, then I'll assume
it's a bug in the implementation and lodge a fault for it.

So I'm pretty binary about compliance with RFCs - either the
implementation complies with them or it doesn't (obviously in
accordance with the specified SHOULDs, MUSTs etc.). I need to be able to
rely on RFCs accurately stating what the behaviour should be (and they
must, they are the protocol specifications after all), so that I
can determine where a fault exists and what I then need to do next to
resolve it.

Regards,
Mark.