Link local for P-t-P links? (Was: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?)

Mike Jones mike at mikejones.in
Thu Dec 1 02:15:49 UTC 2011


On 1 December 2011 00:55, Jimmy Hess <mysidia at gmail.com> wrote:
> Please explain.    What are the better ways that you would propose
> of mitigating ND table overflows?
> If you can show a rational alternative, then it would be persuasive as
> a better option.
>

Link-Local?

For "true" P-t-P links I guess you don't need any addresses on the
interfaces (I don't on my 6in4 tunnels), but I assume most people are
referring to ethernet type cross connects, so Link-Local addresses.

As long as each device has at least 1 address assigned somewhere
(loopback?) that it can use for management/packet generation purposes
you don't need an address on every link like you used to do with IPv4.
Now that there are plenty of addresses you don't need as many :)

I suspect there are probably some practical issues with link-local on
some kit and some network configurations due to lack of people doing
it this way, but in theory there shouldn't be any reason that you
couldn't use link-local for all your links then just have a /128
assigned to each routers loopback for management/packet generation
purposes. This could remove overheads of worrying about address
assignment for those links, you just need a single /128 per router.
Depending on the network it might be better to statically set link
locals rather than using automatic ones (fe80::1 and fe80::2 for
'upstream' and 'downstream' or whatever rules you currently use for
deciding which end is 1 and which is 2)

You could also do something similar for datacentres assigning blocks
to customer servers, instead of configuring a /64 for each customer,
or a /48 then giving customers blocks inside that to use, just
configure a single /64 and give each customer a single address from
that block with unassigned ones filtered, then route a /64 to them for
any "extra addresses" they might want. Chances are if they need more
than a couple of addresses they probably want them routed to them
anyway rather than using ND for them all.

The issue of dynamic assignments to end customers in a non-datacentre
setting is a little more difficult, but I wonder how badly CPEs would
break if you tried using DHCPv6 to give them back their link-local
addresses, then DHCPv6-PD delegating by routing to their link local
address, probably a lot worse than if you just used a /112 of global
space. I don't think this area has too many issues though because DHCP
ensures that the actual addresses on the links are all known, so this
just needs to be used for filtering unknown addresses.

Then there's just the question of what to do about the edge networks
where SLAAC might be used and where you don't have such strict control
over address assignment, i'll pass on that one for now.

Link locals aren't as useful nearer to the edges, but for the
backbones and datacentre networks they should be able to solve most of
the biggest problems with ND attacks. The edge networks where just
using link locals isn't really an option you can probably put a
stateful firewall in quite easily, as these will be the edge default
gateways that clients are sending their traffic directly to rather
than needing to be done in the core. Although there really should be
an option for users to open the firewall for inbound connections.

Am I a complete idiot missing some obvious major issues with link
locals, or am i just the only one not thinking IPv4-think? Opinions?
:)

- Mike




More information about the NANOG mailing list