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

Thu Dec 1 02:22:48 UTC 2011

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

On Wed, Nov 30, 2011 at 9:15 PM, Mike Jones <mike at mikejones.in> wrote:
> 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
>

-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/