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


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 :slight_smile:

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

I for one get really irritated when my traceroutes and pings are
broken and I need to troubleshoot things. :wink: But I guess something
has to give.

My home connection gets IPv6 connectivity via a tunnelbroker tunnel, i
didn't use the "tunnel interface" addresses in the instructions but
configured it without addresses, traceroutes (in all directions) show
up with the routers single assigned global address.

Routers would still have a single global address assigned to loopback
(or anywhere) for management/packet generation purposes so traceroutes
should work fine, although rather than getting a per-interface address
you'll get a per-router address. What addresses do you currently get
in the real world? some routers give a loopback address, some give the
ingress interface, some give the egress interface, all you can safely
assume from the address is the router it hit.

- Mike

I was half joking, but you know, you might be on to something there.

I'll have to try it out and see what the implications are.

I know that for our gear, it uses the interface address so we can map
rDNS to something useful. The other thing to look into would be
neighbor configuration for routing protocols, using a routable address
does tend to make things a bit cleaner, but maybe those are worth
giving up.

The other option, of course, is to just use longer prefixes (e.g.
126), but just using Link-Local would save some effort in allocation
of IPv6 networks for links between routers.

I'd love to see someone like Randy Bush weigh in on it (poke poke, I
know you're reading).

The use of global IPv6 for link networks is something I never really questioned.

Well, traceroutes and other ICMP functions would break. It is occasionally useful to be able to address a specific router interface from someplace other than its connected peer.


Unless your router always sources TTL exceeded from a loopback interface,
breaking traceroute is a problem... breaking ICMP probing is even worse.

I realize IPv6 is the utopian protocol we've all been waiting for,
where routers failing,
latency, packet loss, and hardware glitches are all going to be very
distant memories,
so the familiar troubleshooting tools can all go away and the minor
status questions can be diagnosed using a SNMP status check,

But in the unlikely event something did ever go slightly wrong,
having link locals on routers would
be a killer for the user.

This definitely isn't better than using long prefixes on the P-t-P links.


Point-to-point links in your backbone are by far the easiest thing to
defend against this attack. I wish we would steer the discussion away
from point-to-point links that are entirely within the control of the
operator, as this is really quite well understood. Major ISPs
including Level3 are already doing /126 to their customers today as
well. In fact, Level3 does not even reserve a /64, they will hand out
::0/126 to one customer on a given access router, ::4/126 to the next.
It clearly works.

The access layer for non point-to-point customers, on the other hand,
is less well-understood. That's why we keep having these discussions.
Getting customers (and their device/software) to work correctly with
link-local addressing and DHCP-PD or similar is going to be an uphill
battle in a hosting environment. It also breaks down immediately if
the hosting customer, for example, wishes to use ND to be able to
provision addresses on two or more servers from a common subnet. So
there are both perception and practical problems / limitations with
this approach. I'm not saying it's a bad idea, but it won't work in
some instances.


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?

In a DC / hosting provider context, we're doing this.

We started out assigning all of our PtP links (where we had /31s in the IPv4 world) IPv6 /64s and addressing using ::1 and ::2 with /127 masks from these /64s (to address potential ND table overflow concerns), but have now settled on using automatic link-local addresses instead.

Our IGP propagates the routers' /128 loopbacks and these are used for routing user traffic.

Having the IGP table only contain the /128 loopbacks, and none of the PtP networks is nice. :slight_smile: