Link local for P-t-P links? (Was: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?)
On 1 December 2011 00:55, Jimmy Hess <mysidia@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
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@mikejones.in> wrote:
On 1 December 2011 00:55, Jimmy Hess <mysidia@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/
On 1 December 2011 02:22, Ray Soucy <rps@maine.edu> wrote:
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.
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. On Wed, Nov 30, 2011 at 9:40 PM, Mike Jones <mike@mikejones.in> wrote:
On 1 December 2011 02:22, Ray Soucy <rps@maine.edu> wrote:
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.
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
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
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. -Gabriel -----Original Message----- From: Mike Jones [mailto:mike@mikejones.in] Sent: Wednesday, November 30, 2011 9:16 PM To: nanog@nanog.org Subject: Link local for P-t-P links? (Was: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?) ... 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
On Wed, Nov 30, 2011 at 10:33 PM, McCall, Gabriel <Gabriel.McCall@thyssenkrupp.com> wrote:
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 performance/ 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. Regards, -- -JH
On Wed, Nov 30, 2011 at 9:15 PM, Mike Jones <mike@mikejones.in> wrote:
Link-Local?
For "true" P-t-P links I guess you don't need any addresses on the
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. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
Hi, On 01/12/2011, at 12:45 PM, Mike Jones wrote:
Link-Local? [snip] 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. :) On 01/12/2011, at 12:52 PM, Ray Soucy wrote:
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.
You don't have to give up working traceroute / ping to use link-local on your PtPs. Our traffic routes through globally reachable router loopbacks which looks pretty in traceroutes, are pingable and doesn't break PMTUD. Tom
participants (6)
-
Jeff Wheeler -
Jimmy Hess -
McCall, Gabriel -
Mike Jones -
Ray Soucy -
Tom Lanyon