IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
Hello everybody, It is commonly agreed that /64 is maximal length for LANs because if we use longer prefix we introduce conflict with stateless address autoconfiguration (SLAAC) based on EUI-64 spec. But SLAAC is not used in DOCSIS networks. So there seems to be no objections to use smaller networks per cable interfaces of CMTS. I was not able to find any recommendations anywhere including Cable Labs specs for using prefixes not greater then /64 in DOCSIS networks. Some tech from ISP assumed that DHCPv6 server may generate interface ID part of IPv6 address similarly to EUI-64 so MAC address of the device can easily be obtained from its IPv6 address, but this does not seem like convincing argument. What do you think? Dmitry Cherkasov
It's a good practice to reserve a 64-bit prefix for each network. That's a good general rule. For point to point or link networks you can use something as small as a 126-bit prefix (we do). When it comes to implementation, though, it's not as simple as a yes or no answer. The actual use of 64-bit prefixes is not something I would currently recommend for large-scale deployments due to the denial of service attack vector it opens up (neighbor table exhaustion). Not using 64-bit prefixes tosses SLAAC out the window; but for many networks SLAAC may not be desirable anyway due to the lack of control it presents. Once vendors come out with routers that are able to protect against neighbor table exhaustion, moving to a 64-bit prefix (which you hopefully reserved) will allow you to be more flexible in what addressing methods are used. On Mon, Nov 28, 2011 at 6:37 AM, Dmitry Cherkasov <doctorchd@gmail.com> wrote:
Hello everybody,
It is commonly agreed that /64 is maximal length for LANs because if we use longer prefix we introduce conflict with stateless address autoconfiguration (SLAAC) based on EUI-64 spec. But SLAAC is not used in DOCSIS networks. So there seems to be no objections to use smaller networks per cable interfaces of CMTS. I was not able to find any recommendations anywhere including Cable Labs specs for using prefixes not greater then /64 in DOCSIS networks. Some tech from ISP assumed that DHCPv6 server may generate interface ID part of IPv6 address similarly to EUI-64 so MAC address of the device can easily be obtained from its IPv6 address, but this does not seem like convincing argument. What do you think?
Dmitry Cherkasov
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
On Nov 28, 2011, at 7:29 AM, Ray Soucy wrote:
It's a good practice to reserve a 64-bit prefix for each network. That's a good general rule. For point to point or link networks you can use something as small as a 126-bit prefix (we do).
Technically, absent buggy {firm,soft}ware, you can use a /127. There's no actual benefit to doing anything longer than a /64 unless you have buggy *ware (ping pong attacks only work against buggy *ware), and there can be some advantages to choosing addresses other than ::1 and ::2 in some cases. If you're letting outside packets target your point-to-point links, you have bigger problems than neighbor table attacks. If not, then the neighbor table attack is a bit of a red-herring. Owen
On Nov 28, 2011, at 4:51 52PM, Owen DeLong wrote:
On Nov 28, 2011, at 7:29 AM, Ray Soucy wrote:
It's a good practice to reserve a 64-bit prefix for each network. That's a good general rule. For point to point or link networks you can use something as small as a 126-bit prefix (we do).
Technically, absent buggy {firm,soft}ware, you can use a /127. There's no actual benefit to doing anything longer than a /64 unless you have buggy *ware (ping pong attacks only work against buggy *ware), and there can be some advantages to choosing addresses other than ::1 and ::2 in some cases. If you're letting outside packets target your point-to-point links, you have bigger problems than neighbor table attacks. If not, then the neighbor table attack is a bit of a red-herring.
The context is DOCSIS, i.e., primarily residential cable modem users, and the cable company ISPs do not want to spend time on customer care and hand-holding. How are most v6 machines configured by default? That is, what did Microsoft do for Windows Vista and Windows 7? If they're set for stateless autoconfig, I strongly suspect that most ISPs will want to stick with that and hand out /64s to each network. (That's apart from the larger question of why they should want to do anything else...) --Steve Bellovin, https://www.cs.columbia.edu/~smb
I mentioned this in an earlier reply. CM vs CPE vs CPE router are all different use cases. From a CPE or CPE router point of view SLAAC will likely not be used to provisioned devices, stateful DHCPv6 is required. As such Vista/7 machines that are directly connected to cable modems will receive an IPv6 address and configuration options via stateful DHCPv6. The same now applies to OSX Lion. I do agree that many host implementations have been built around /64 assumptions and departures from the same at this time will seemingly introduce more problems that benefits. John On 11/28/11 5:00 PM, "Steven Bellovin" <smb@cs.columbia.edu> wrote:
On Nov 28, 2011, at 4:51 52PM, Owen DeLong wrote:
On Nov 28, 2011, at 7:29 AM, Ray Soucy wrote:
It's a good practice to reserve a 64-bit prefix for each network. That's a good general rule. For point to point or link networks you can use something as small as a 126-bit prefix (we do).
Technically, absent buggy {firm,soft}ware, you can use a /127. There's no actual benefit to doing anything longer than a /64 unless you have buggy *ware (ping pong attacks only work against buggy *ware), and there can be some advantages to choosing addresses other than ::1 and ::2 in some cases. If you're letting outside packets target your point-to-point links, you have bigger problems than neighbor table attacks. If not, then the neighbor table attack is a bit of a red-herring.
The context is DOCSIS, i.e., primarily residential cable modem users, and the cable company ISPs do not want to spend time on customer care and hand-holding. How are most v6 machines configured by default? That is, what did Microsoft do for Windows Vista and Windows 7? If they're set for stateless autoconfig, I strongly suspect that most ISPs will want to stick with that and hand out /64s to each network. (That's apart from the larger question of why they should want to do anything else...)
--Steve Bellovin, https://www.cs.columbia.edu/~smb
Basically, if the address used by a host is allocated using RFC 3971/4861/4941, the host assumes a /64 from the router and concocts a 64 bit EID as specified. If the address used by the host is allocated using DHCP/DHCPv6, it is the 128 bit number assigned by the DHCP server. I see no reason you couldn't use a /127 prefix if the link was point to point. As you note, there is significant deployment of ND, and insignificant deployment of DHCPv6. However, any network that is in control of all of its hosts should be able to specify the use of DHCPv6. On Nov 28, 2011, at 2:39 PM, Brzozowski, John wrote:
I mentioned this in an earlier reply. CM vs CPE vs CPE router are all different use cases. From a CPE or CPE router point of view SLAAC will likely not be used to provisioned devices, stateful DHCPv6 is required. As such Vista/7 machines that are directly connected to cable modems will receive an IPv6 address and configuration options via stateful DHCPv6. The same now applies to OSX Lion.
I do agree that many host implementations have been built around /64 assumptions and departures from the same at this time will seemingly introduce more problems that benefits.
John
On 11/28/11 5:00 PM, "Steven Bellovin" <smb@cs.columbia.edu> wrote:
On Nov 28, 2011, at 4:51 52PM, Owen DeLong wrote:
On Nov 28, 2011, at 7:29 AM, Ray Soucy wrote:
It's a good practice to reserve a 64-bit prefix for each network. That's a good general rule. For point to point or link networks you can use something as small as a 126-bit prefix (we do).
Technically, absent buggy {firm,soft}ware, you can use a /127. There's no actual benefit to doing anything longer than a /64 unless you have buggy *ware (ping pong attacks only work against buggy *ware), and there can be some advantages to choosing addresses other than ::1 and ::2 in some cases. If you're letting outside packets target your point-to-point links, you have bigger problems than neighbor table attacks. If not, then the neighbor table attack is a bit of a red-herring.
The context is DOCSIS, i.e., primarily residential cable modem users, and the cable company ISPs do not want to spend time on customer care and hand-holding. How are most v6 machines configured by default? That is, what did Microsoft do for Windows Vista and Windows 7? If they're set for stateless autoconfig, I strongly suspect that most ISPs will want to stick with that and hand out /64s to each network. (That's apart from the larger question of why they should want to do anything else...)
--Steve Bellovin, https://www.cs.columbia.edu/~smb
On 11/28/11 6:13 PM, "Fred Baker" <fred@cisco.com> wrote:
Basically, if the address used by a host is allocated using RFC 3971/4861/4941, the host assumes a /64 from the router and concocts a 64 bit EID as specified. If the address used by the host is allocated using DHCP/DHCPv6, it is the 128 bit number assigned by the DHCP server. I see no reason you couldn't use a /127 prefix if the link was point to point. [jjmb] How would this address be assigned? Statically? Practically, I do not see how this would be useful. I do agree it is possible.
As you note, there is significant deployment of ND, and insignificant deployment of DHCPv6. However, any network that is in control of all of its hosts should be able to specify the use of DHCPv6. [jjmb] I do not agree about the insignificance of DHCPv6 deployment, ND support is certainly greater. Having control over hosts ie an enterprise environment, creates the opportunity to mandate DHCPv6, it does not always it should be required. Again this depends on the deployment scenario.
On Nov 28, 2011, at 2:39 PM, Brzozowski, John wrote:
I mentioned this in an earlier reply. CM vs CPE vs CPE router are all different use cases. From a CPE or CPE router point of view SLAAC will likely not be used to provisioned devices, stateful DHCPv6 is required. As such Vista/7 machines that are directly connected to cable modems will receive an IPv6 address and configuration options via stateful DHCPv6. The same now applies to OSX Lion.
I do agree that many host implementations have been built around /64 assumptions and departures from the same at this time will seemingly introduce more problems that benefits.
John
On 11/28/11 5:00 PM, "Steven Bellovin" <smb@cs.columbia.edu> wrote:
On Nov 28, 2011, at 4:51 52PM, Owen DeLong wrote:
On Nov 28, 2011, at 7:29 AM, Ray Soucy wrote:
It's a good practice to reserve a 64-bit prefix for each network. That's a good general rule. For point to point or link networks you can use something as small as a 126-bit prefix (we do).
Technically, absent buggy {firm,soft}ware, you can use a /127. There's no actual benefit to doing anything longer than a /64 unless you have buggy *ware (ping pong attacks only work against buggy *ware), and there can be some advantages to choosing addresses other than ::1 and ::2 in some cases. If you're letting outside packets target your point-to-point links, you have bigger problems than neighbor table attacks. If not, then the neighbor table attack is a bit of a red-herring.
The context is DOCSIS, i.e., primarily residential cable modem users, and the cable company ISPs do not want to spend time on customer care and hand-holding. How are most v6 machines configured by default? That is, what did Microsoft do for Windows Vista and Windows 7? If they're set for stateless autoconfig, I strongly suspect that most ISPs will want to stick with that and hand out /64s to each network. (That's apart from the larger question of why they should want to do anything else...)
--Steve Bellovin, https://www.cs.columbia.edu/~smb
Note that /127 is strongly discouraged in RFC5375 and RFC3627. 3627 suggests using /112 for router links, or /126 at the very most. -----Original Message----- From: Fred Baker [mailto:fred@cisco.com] ... I see no reason you couldn't use a /127 prefix if the link was point to point. ...
Note that /127 is strongly discouraged in RFC5375 and RFC3627. 3627 suggests using /112 for router links, or /126 at the very most.
Of potential interest, since you bring up RFC3627, is the following draft, and RFC6164: http://tools.ietf.org/html/draft-george-6man-3627-historic-01 http://tools.ietf.org/html/rfc6164 Nathan Eisenberg
Yes and no; RFC6164 is attempting to make that more acceptable. Although; the only thing that pushed us from /30 to /31 in IPv4 was the address space crunch; that doesn't exist in the IPv6 world; so using /127 instead of /126 really doesn't seem to buy us much. On Tue, Nov 29, 2011 at 12:00 PM, McCall, Gabriel <Gabriel.McCall@thyssenkrupp.com> wrote:
Note that /127 is strongly discouraged in RFC5375 and RFC3627. 3627 suggests using /112 for router links, or /126 at the very most.
-----Original Message----- From: Fred Baker [mailto:fred@cisco.com] ... I see no reason you couldn't use a /127 prefix if the link was point to point. ...
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
I believe those have been obsoleted, but, /64 remains the best choice, IMHO. Owen On Nov 29, 2011, at 9:00 AM, McCall, Gabriel wrote:
Note that /127 is strongly discouraged in RFC5375 and RFC3627. 3627 suggests using /112 for router links, or /126 at the very most.
-----Original Message----- From: Fred Baker [mailto:fred@cisco.com] ... I see no reason you couldn't use a /127 prefix if the link was point to point. ...
On 11/29/11 09:30 , Owen DeLong wrote:
I believe those have been obsoleted, but, /64 remains the best choice, IMHO.
operational practice has moved on. http://tools.ietf.org/html/rfc6164
Owen
On Nov 29, 2011, at 9:00 AM, McCall, Gabriel wrote:
Note that /127 is strongly discouraged in RFC5375 and RFC3627. 3627 suggests using /112 for router links, or /126 at the very most.
-----Original Message----- From: Fred Baker [mailto:fred@cisco.com] ... I see no reason you couldn't use a /127 prefix if the link was point to point. ...
On Nov 29, 2011, at 10:11 AM, Joel jaeggli wrote:
On 11/29/11 09:30 , Owen DeLong wrote:
I believe those have been obsoleted, but, /64 remains the best choice, IMHO.
operational practice has moved on.
RFC 6164 does not say anything bad about using /64. Owen
Owen
On Nov 29, 2011, at 9:00 AM, McCall, Gabriel wrote:
Note that /127 is strongly discouraged in RFC5375 and RFC3627. 3627 suggests using /112 for router links, or /126 at the very most.
-----Original Message----- From: Fred Baker [mailto:fred@cisco.com] ... I see no reason you couldn't use a /127 prefix if the link was point to point. ...
On Tue, Nov 29, 2011 at 10:31 PM, Owen DeLong <owen@delong.com> wrote:
On Nov 29, 2011, at 10:11 AM, Joel jaeggli wrote:
On 11/29/11 09:30 , Owen DeLong wrote:
I believe those have been obsoleted, but, /64 remains the best choice, IMHO. operational practice has moved on. http://tools.ietf.org/html/rfc6164 RFC 6164 does not say anything bad about using /64. Owen
RFC 6164 does not define operational practice or a recommended way of designing your network or configuring your router(s). All RFC 6164 says is essentially that some networks do want to use longer than 64-bit prefixes and there are some valid reasons, explains what motivates some operators to do so, and adds recommendations that routers must allow assignment of /127 prefixes on P-t-P inter-router links and disable subnet-router anycast when in use. In other words... if you are implementing an IPv6 router, RFC 6164 will assist you by giving you technical recommendations that you implement the capability for /127 prefixes on your router, with motiviations listed that will help you decide whether to include support for /127 inter-router links or not. -- -JH
Yikes, Owen. That's a lot of responses... Saying you can mitigate neighbor table exhaustion with a "simple ACL" is misleading (and you're not the only one who has tried to make that claim). You can mitigate it by: 1. Using a stateful firewall (not an ACL) outside the router responsible for the 64-bit prefix. This doesn't scale, and is not a design many would find acceptable (it has almost all the problems of an ISP running NAT) 2. Using a "simple ACL" that drops traffic to any address not in use. This has the inherent problem that for it to be successful, it either needs to: a) dynamically update (e.g. some sort of captive portal system, where hosts have to register to get access to the outside), or b) defined as a subset of a 64-bit prefix (e.g. only allow a /126 of the prefix). I would put forward the argument that if you're going to call it a "simple ACL" it's not a dynamic ACL (NAC), so you must be talking about the second option. If you're going to create a network that is a /64 and then create an ACL that only allows traffic to a subset of that prefix; then you can't use SLAAC, privacy addressing, or any other features that a /64 would provide; what you do get is increased demand on routing infrastructure to be running many, many, many, ACLs to avoid a problem that could be avoided by using a longer prefix. So I'm not really seeing your argument here. The fact that you apply the ACL breaks the functionality you're claiming to preserve; and adds more overhead to your infrastructure in the process. I could be wrong, but I don't think ACL performance would scale well if you were doing this dynamically, either. All traffic having to traverse an ACL with thousands of statements every packet; it might be fine for a FCC "broadband" connection of 768K, but if you're providing people with actual broadband (Gigabit or greater) the cost becomes very high. I personally don't want my latency or bandwidth affected because of excessive use of ACLs and a "drop everything by default" policy. As for never seeing an neighbor table exhaustion attack "in the wild". I haven't experienced it for IPv6, but I have experienced it for IPv4, for sites that chose to use a 16-bit prefix for every internal network (even though they only needed a hundred host addresses). The only thing preventing it from being an external attack was the fact that it was safely behind NAT. With IPv6 that same problem is exposed to external attacks. I didn't buy it either until I sat down and was able to quickly reproduce it. Does that mean I'm going to attack a network just to prove a point? Of course not. The fact that it hasn't happened yet (or the people its happened to haven't realized it is what has happened; which is a bigger issue) doesn't mean it's a non-issue. DoS attacks are typically targeted at disrupting highly visible services; since the vast majority of users on the Internet don't have IPv6 access; and what IPv6 access is out there is unstable enough on its own (thanks to people throwing up firewalls that drop all ICMPv6 traffic), it's not exactly a vector anyone cares about right now. But that will change as adoption grows. I think the point is that you can easily avoid this attack vector today by using longer prefixes for now; and growing a prefix from a /120 to a /64 is a very easy change. The opposite is just not true; even if that is accomplished with an ACL rather than changing the prefix on the router. Once you have hosts using addresses, it's not something you can take away easily without being disruptive (plenty of experience with such situations as we use public IPv4 for the majority of our networks; not NAT). You keep talking about "purists" as if it's a dirty word, but then proceed to go on about how every network should be a 64-bit prefix, absolutely. You've gotta see the humor in that. ;-) Before we spun this out of control, the OP was asking if there was any problem using prefixes longer than 64-bit in a DOCSIS environment. There is no problem using a prefix-length other than 64. We do it in production and have not actually encountered a single issue as a result. You don't get SLAAC, but SLAAC isn't really desirable for a lot of the networks we're talking about (link networks, enterprise LAN networks, etc). Client systems with mature and stable IPv6 stacks (which are the only systems we care about giving IPv6 to) "just work", even when using DHCPv6 and 120-bit prefixes. If you make use of a prefix longer than 64, but reserve the full 64-bit prefix in your allocation schema, then you can easily migrate from something like a 120 or 126 to a 64; the same is not true for the reverse. If your DOCSIS system has some sort of dynamic ACL system in place already that is able to open up "registered" connections; then you're immune from the attacks discussed. If it doesn't you'll want to find a way to address that (pun intended). -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
On Wed, Nov 30, 2011 at 8:48 AM, Ray Soucy <rps@maine.edu> wrote:
Saying you can mitigate neighbor table exhaustion with a "simple ACL" is misleading (and you're not the only one who has tried to make that claim).
It's true, though, you can. But you can also mitigate neighbor table exhaustion by using a long prefix /126; you create an upper bound on the number of neighbor table entries that are possible, and that bound is less than your device's memory capacity for neighbor table entries. This is a more reliable mitigation than an ACL; it is also simpler and less likely for an operator to mistake to render the mitigation useless, or cause other issues.
From a pure security POV, it's easy to reject ACL mitigation in favor of inherent designed-in mitigation / non-vulnerability.
From a network design POV, there may still be reasons to prefer the ACL method. They better be good reasons, such as a requirement for SLAAC on a large LAN.
-- -JH
-----Original Message----- From: Jimmy Hess [mailto:mysidia@gmail.com] Sent: Wednesday, November 30, 2011 11:14 AM To: Ray Soucy Cc: NANOG Subject: Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
On Wed, Nov 30, 2011 at 8:48 AM, Ray Soucy <rps@maine.edu> wrote:
Saying you can mitigate neighbor table exhaustion with a "simple ACL" is misleading (and you're not the only one who has tried to make
that
claim).
It's true, though, you can. But you can also mitigate neighbor table exhaustion by using a long prefix /126; you create an upper bound on the number of neighbor table entries that are possible, and that bound is less than your device's memory capacity for neighbor table entries.
This is a more reliable mitigation than an ACL; it is also simpler and less likely for an operator to mistake to render the mitigation useless, or cause other issues.
From a pure security POV, it's easy to reject ACL mitigation in favor of inherent designed-in mitigation / non-vulnerability.
From a network design POV, there may still be reasons to prefer the ACL method. They better be good reasons, such as a requirement for SLAAC on a large LAN.
Or maybe the IETF could, you know, decouple SLAAC from a particular netmask and make the world a better place for all of us who aren't backbone providers. Do we have to recreate the mistakes from v4 all over again? Jamie
On Wed, Nov 30, 2011 at 9:48 AM, Ray Soucy <rps@maine.edu> wrote:
1. Using a stateful firewall (not an ACL) outside the router responsible for the 64-bit prefix. This doesn't scale, and is not a design many would find acceptable (it has almost all the problems of an ISP running NAT)
Owen has suggested "stateful firewall" as a solution to me in the past. There is not currently any firewall with the necessary features to do this. We sometimes knee-jerk and think "stateful firewall has gobs of memory and can spend more CPU time on each packet, so it is a more likely solution." In this case that does not matter. You can't have 2^64 bits of memory. You could make a firewall with the needed features (or a layer-3 switch), but it would have to be the layer-3 gateway of the subnets you are protecting (not an upstream device) and it would need knowledge of all addresses in use on the subnet, which must fit within its ND table limits. Only DHCP snooping can do this and customers are not exactly keen on receiving DHCP-assigned addresses in mixed datacenter environments, even if the addresses are static ones. Once you do that, you need to limit the number of addresses that can be leased to each customer to far less than a /64 anyway. All you gain by having all that complexity is the appearance of bigger subnets, when in reality, they are non-functional except for the limited number of addresses which are actively leased out. Again the arguments for /64 are not promising. It is much less complicated to simply deploy a longer subnet. On Wed, Nov 30, 2011 at 11:13 AM, Jimmy Hess <mysidia@gmail.com> wrote:
On Wed, Nov 30, 2011 at 8:48 AM, Ray Soucy <rps@maine.edu> wrote:
Saying you can mitigate neighbor table exhaustion with a "simple ACL" is misleading (and you're not the only one who has tried to make that claim).
It's true, though, you can.
From a network design POV, there may still be reasons to prefer the ACL method. They better be good reasons, such as a requirement for SLAAC on a large LAN.
No, Jimmy, you can't do that with SLAAC. I do not think you understand the problem. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
Owen and I have gone back and fourth over the year(s) as well. I think it really comes down to Owen's adamant belief that _every_ network should be a 64-bit prefix, and that SLAAC should be used for addressing, because it's simple and people will only adopt IPv6 if it's simple. The whole neighbor table exhaustion problem undermines that case he's trying to make, so he tries to dismiss it as a non-issue. It's nothing specific to Owen, it's basic human behavior. I've always held the view that telling people IPv6 is simple is a lie and harmful to IPv6 adoption for a few reasons: If people think IPv6 is simple, they don't bother investing time to plan out adoption and a phased deployment; they assume that when they need it they can just turn it on. If IPv6 isn't at least as flexible as IPv4, and can't fit in the same operational model used for IPv4 today; then it will never be adopted. Saying it's simple and "redesign your network" makes most people turn away from IPv6 and hope that something better will come along. The future of IPv6 for most organizations will include: DHCPv6 for stateful address assignment. NPT (Network Prefix Translation) and ULA address space internally (not NAT, but operationally identical); with load balancing between public allocations much like "dual WAN" SMB firewalls available for IPv4 (after all, having every SMB in the BGP table is not something that any of us want to see). Eventual use of NAT-PT and ALG for providing access to the legacy IPv4 Internet without having to operate a dual-stack network internally (once there is enough IPv6-enabled content so that you're only breaking some things by doing so). We won't see widespread adoption of IPv6 until we have a product people can buy in appliance form that can do these things, along with providing the typical functionality of an SMB firewall. Period. It seems a little silly that we're still having arguments about using 64-bit prefix lengths instead of focusing on how to move IPv6 to a position where it can be operationally identical to the way networks are run today and then promote adoption. You just can't tell people to turn on IPv6, ignore the security concerns, ignore the operational differences, and suck it up and forklift their network. It's not going to happen. On Wed, Nov 30, 2011 at 11:39 AM, Jeff Wheeler <jsw@inconcepts.biz> wrote:
On Wed, Nov 30, 2011 at 9:48 AM, Ray Soucy <rps@maine.edu> wrote:
1. Using a stateful firewall (not an ACL) outside the router responsible for the 64-bit prefix. This doesn't scale, and is not a design many would find acceptable (it has almost all the problems of an ISP running NAT)
Owen has suggested "stateful firewall" as a solution to me in the past. There is not currently any firewall with the necessary features to do this. We sometimes knee-jerk and think "stateful firewall has gobs of memory and can spend more CPU time on each packet, so it is a more likely solution." In this case that does not matter. You can't have 2^64 bits of memory.
You could make a firewall with the needed features (or a layer-3 switch), but it would have to be the layer-3 gateway of the subnets you are protecting (not an upstream device) and it would need knowledge of all addresses in use on the subnet, which must fit within its ND table limits. Only DHCP snooping can do this and customers are not exactly keen on receiving DHCP-assigned addresses in mixed datacenter environments, even if the addresses are static ones. Once you do that, you need to limit the number of addresses that can be leased to each customer to far less than a /64 anyway. All you gain by having all that complexity is the appearance of bigger subnets, when in reality, they are non-functional except for the limited number of addresses which are actively leased out.
Again the arguments for /64 are not promising. It is much less complicated to simply deploy a longer subnet.
On Wed, Nov 30, 2011 at 11:13 AM, Jimmy Hess <mysidia@gmail.com> wrote:
On Wed, Nov 30, 2011 at 8:48 AM, Ray Soucy <rps@maine.edu> wrote:
Saying you can mitigate neighbor table exhaustion with a "simple ACL" is misleading (and you're not the only one who has tried to make that claim).
It's true, though, you can.
From a network design POV, there may still be reasons to prefer the ACL method. They better be good reasons, such as a requirement for SLAAC on a large LAN.
No, Jimmy, you can't do that with SLAAC. I do not think you understand the problem.
-- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
On Nov 30, 2011, at 9:10 AM, Ray Soucy wrote:
Owen and I have gone back and fourth over the year(s) as well.
I think it really comes down to Owen's adamant belief that _every_ network should be a 64-bit prefix, and that SLAAC should be used for addressing, because it's simple and people will only adopt IPv6 if it's simple. The whole neighbor table exhaustion problem undermines that case he's trying to make, so he tries to dismiss it as a non-issue. It's nothing specific to Owen, it's basic human behavior.
I've never said SLAAC should be used for addressing. I have said that SLAAC is useful in many situations and can be a good tool. I have consistently said that administrators should be free to choose the addressing mechanism that work best for their environments. I do believe that there is no benefit to longer prefixes than /64. Nobody has provided any convincing evidence to the contrary. There are better ways to mitigate ND than longer prefixes.
I've always held the view that telling people IPv6 is simple is a lie and harmful to IPv6 adoption for a few reasons:
If people think IPv6 is simple, they don't bother investing time to plan out adoption and a phased deployment; they assume that when they need it they can just turn it on.
I don't believe I've said IPv6 is simple. I've said that IPv6 is easier than IPv4. It is. You don't have to worry about many of the common difficulties with IPv4 (NAT, address conservation, subnet rightsizing, etc.).
If IPv6 isn't at least as flexible as IPv4, and can't fit in the same operational model used for IPv4 today; then it will never be adopted.
I would argue that IPv6 is more flexible than IPv4, but, it does require changes to some IPv4 operational models. IP didn't fit the same operational model as IPX, yet we made the transition from IPX to IPv4, so, I don't buy into your idea that it won't be adopted if it doesn't fit the same operational models. Some operational models for IPv4 are obsoleted by IPv6. Such is the nature of protocol change.
Saying it's simple and "redesign your network" makes most people turn away from IPv6 and hope that something better will come along.
I wouldn't say redesign your network so much as design your IPv6 network. In some cases, keeping in mind your IPv4 topology is useful. In some cases, moving beyond the limitations under which your IPv4 topology was constructed is very beneficial in IPv6. For example, common scenario in enterprise IPv4 is a single link with half a dozen or so /28s on it as the server farm grew. There's no reason not to make that a single IPv6 /64 while still leaving all those different IPv4 networks in place. There's no benefit whatsoever to allocating half a dozen IPv6 prefixes or sizing them to some /120 or whatever.
The future of IPv6 for most organizations will include:
DHCPv6 for stateful address assignment.
I've never argued against DHCP usage.
NPT (Network Prefix Translation) and ULA address space internally (not NAT, but operationally identical); with load balancing between public allocations much like "dual WAN" SMB firewalls available for IPv4 (after all, having every SMB in the BGP table is not something that any of us want to see).
I'm not as convinced as you are of this.
Eventual use of NAT-PT and ALG for providing access to the legacy IPv4 Internet without having to operate a dual-stack network internally (once there is enough IPv6-enabled content so that you're only breaking some things by doing so).
Remains to be seen whether it will be NAT-PT, NAT64, NAT444, IVI, or something else for this. I'm not convinced that the enterprise will be where IPv4 is deprecated first. In fact, I suspect it is likely to be one of the last places to move from dual-stack to IPv6-only as you describe.
We won't see widespread adoption of IPv6 until we have a product people can buy in appliance form that can do these things, along with providing the typical functionality of an SMB firewall.
Time will tell. I suspect that if no such product is made available, it will not prevent widespread deployment of IPv6.
It seems a little silly that we're still having arguments about using 64-bit prefix lengths instead of focusing on how to move IPv6 to a position where it can be operationally identical to the way networks are run today and then promote adoption.
Some of us don't want to do that kind of damage to IPv6. As such, I prefer to deploy IPv6 as it is today and resolve the bugs and the security issues along the way (much like we did with IPv4). IPv6 can be operationally similar, but, making it operationally identical would take away many of its benefits.
You just can't tell people to turn on IPv6, ignore the security concerns, ignore the operational differences, and suck it up and forklift their network. It's not going to happen.
I've never said forklift your network or ignore the operational differences. In fact, I've said embrace the operational differences and celebrate the fact that you don't have to deal with NAT any more. Enjoy simplified address planning with massive headroom. I haven't said that security issues should be ignored, either. Just that they should be viewed in a proper context and assessed with a realistic evaluation of the magnitude of the risk and the difficulty of mitigation. The magnitude of risk is defined in terms of the probability of an event combined with the damage caused by such an event. What has also been lost here is that my description of the various mitigation tactics for ND exhaustion attacks depends on the type of network being protected. Strategies that work for point-to-point links (simple ACLs at the borders in most environments, for example) are not the same as strategies that work to protect client LANs (stateful firewalls with default deny inbound) or strategies necessary to protect server LANs (slightly more complex ACLs and other tactics). Owen
On Wed, Nov 30, 2011 at 3:13 PM, Owen DeLong <owen@delong.com> wrote:
As such, I prefer to deploy IPv6 as it is today and resolve the bugs and the security issues along the way (much like we did with IPv4).
Why is the Hurricane Electric backbone using /126 link-nets, not /64? You used to regularly claim there are significant disadvantages to longer subnets. At best, you are still claiming there are no advantages. These are lies. Please, Owen, tell us why you aren't practicing what you preach.
I haven't said that security issues should be ignored, either. Just that they should be viewed in a proper context and assessed with a realistic evaluation of the magnitude of the risk and the difficulty of mitigation.
You repeatedly claim that ND exhaustion is a non-issue. You also claim you have secret sauce to mitigate attacks. This, after you previously claimed that you were using common ACLs to mitigate attacks, and I showed you how that cannot be true. Your understanding of this problem has rocketed from totally clueless to having secrets you can't discuss. Except it isn't, because you are also advocating ... denying all traffic to all subnets except the first few hundred addresses. What a stellar plan! Just stop telling lies about this, Owen. That's all I'm asking. You, personally, are part of the problem. If the guy who is supposed to be the public-facing technical outreach guy for the self-described leader in IPv6 transit/hosting/etc services continues to go around claiming this is a non-issue, when it very clearly is, that is destructive, not helpful.
What has also been lost here is that my description of the various mitigation tactics for ND exhaustion attacks depends on the type of network being protected. Strategies that work for point-to-point links (simple ACLs at the borders in most environments, for example) are not the same as strategies that work to protect client LANs (stateful firewalls with default deny inbound) or strategies necessary to protect server LANs (slightly more complex ACLs and other tactics).
You have no such "simple ACLs at the borders" on the Hurricane Electric network. In fact, your mitigation mechanism for the backbone is exactly what I recommend: deploy longer subnets. You don't have any mitigation mechanism for your hosting services, other than whack-a-mole. If anyone has trouble believing me, you can do what I did, and email Owen off-list. You can say, Owen, I'd like to subscribe to a Hurricane Electric dedicated server, get myself a /64, and DoS my own subnet, to see if that affects my box or any other nearby customers. The reply you'll get will be that your box will be powered off, because they have no mitigation strategy. Arguing in the abstract is all fun and games, but when you ask Owen to show you something that works in a real-world, production environment, he can't. That's because Owen's network design is not suitable for production use in his own environment with routers he claims to have selected in part based on their performance under ND attacks (another lie.) -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
On Wed, Nov 30, 2011 at 3:13 PM, Owen DeLong <owen@delong.com> wrote:
I do believe that there is no benefit to longer prefixes than /64. Nobody has provided any convincing evidence to the contrary.
There are better ways to mitigate ND than longer prefixes.
Agree to disagree, I guess. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
On 30 Nov 2011, at 21:10, Ray Soucy wrote:
On Wed, Nov 30, 2011 at 3:13 PM, Owen DeLong <owen@delong.com> wrote:
I do believe that there is no benefit to longer prefixes than /64. Nobody has provided any convincing evidence to the contrary.
There are better ways to mitigate ND than longer prefixes.
Agree to disagree, I guess.
To be honest, I can't work out the point of preferring a /64 in the first place if you're not using SLAAC and I'm not sure why SLAAC wanted more than 48 bits. If you use broad ACLs to lock down to a /126 or /112 equivalent, why bother with the /64 in the first place? However, I'm new to the IPv6 business, so I'm sure I'll work it out eventually. - Mark
To be honest, I can't work out the point of preferring a /64 in the first place if you're not using SLAAC and I'm not sure why SLAAC wanted more than 48 bits.
If you use broad ACLs to lock down to a /126 or /112 equivalent, why bother with the /64 in the first place?
However, I'm new to the IPv6 business, so I'm sure I'll work it out eventually.
Or you might do what a lot of us have done: get sick of arguing with the evangelists about how /64's don't make sense for everyone in every scenario. Get sick of trying to argue that every home's CPE doesn't need a /48 delegated to it so that it can automatically subdelegate longer networks to devices which will in turn subdelegate even longer prefixes to devices which "something that hasn't been invented yet will use, and if you don't set it up this way, history will prove that you're an unimaginative fool". Get sick of hearing "It's a huge address space, so don't worry about being conservative - sitting 'on the shelf' or sitting unused in a network are the same thing" (I guess we'll migrate to an even bigger address space if we someday have other stellar bodies in our local star system to send packets to, despite the average home network utilizing far, far less than .00[...]01% of their address space... - add a lot more 0's if the /48 guys win out...) This new IPv6 world is full of lazy evangelists, who are so excited about same-sized subnets, stateless address configuration and globally unique and routable addresses for purposes that no one can quite imagine yet, that they cannot engage in a logical and rational discussion with the rest of us. Instead, we go back and forth over the same concerns, until the patience of the list has been utterly worn out - at which point, these individuals always throw their hands in the air, and exclaim: "You're wrong, and your customers will tell you that with their feet", and presume that they have then proven you wrong. As has been pointed out, there is a lot of human nature at work here: these individuals have made low-level emotional investments in their arguments, and divided the IPv6-think world into two categories: Us (right), and Not Us (wrong). When someone does this, it can take a significant amount of psychology to get the conversation to a rational place, and unless you have a real need to see eye to eye with them, it's often easier to move on. In any case, do the research and testing, and make sure that at least your own deployments have rational addressing policies (whatever you determine that might be). Nathan Eisenberg
Nathan, I respect your positions, but you presume too much. I'm in no way an evangelist, but I agree with most of the points made by those you categorize as such. I'll reply specifically in-line.
-----Original Message----- From: Nathan Eisenberg [mailto:nathan@atlasnetworks.us] Sent: Wednesday, November 30, 2011 4:05 PM To: nanog@nanog.org Subject: RE: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
<SNIP>
Or you might do what a lot of us have done: get sick of arguing with the evangelists about how /64's don't make sense for everyone in every scenario. Get sick of trying to argue that every home's CPE doesn't need a /48 delegated to it so that it can automatically subdelegate longer networks to devices which will in turn subdelegate even longer prefixes to devices which "something that hasn't been invented yet will use, and if you don't set it up this way, history will prove that you're an unimaginative fool". Get sick of hearing "It's a huge address space, so don't worry about being conservative - sitting 'on the shelf' or sitting unused in a network are the same thing" (I guess we'll migrate to an even bigger address space if we someday have other stellar bodies in our local star system to send packets to, despite the average home network utilizing far, far less than .00[...]01% of their address space... - add a lot more 0's if the /48 guys win out...)
It sounds like you are still in the IPv4 paradigm. I agree with your statements, but not your tone or implications. I think you misread people who have immense knowledge on the subject matter and care deeply with people who are grinding an axe for political or emotional purposes. If someone argued with you on the subtleties of gravity and doesn't accept the basic premise of gravity, you would likely respond similarly.
This new IPv6 world is full of lazy evangelists, who are so excited about same- sized subnets, stateless address configuration and globally unique and routable addresses for purposes that no one can quite imagine yet, that they cannot engage in a logical and rational discussion with the rest of us. Instead, we go back and forth over the same concerns, until the patience of the list has been utterly worn out - at which point, these individuals always throw their hands in the air, and exclaim: "You're wrong, and your customers will tell you that with their feet", and presume that they have then proven you wrong.
I'm rubber your glue.... Never mind. The things you are minimalizing are some of the design specifications of the protocol. It's like arguing about the fact that IPv4 has certain headers and they are dumb. GET OVER IT! And no one will ever prove you wrong. It's that everyone else will do one thing and you will do something else. Live with your decision. This debate result can be seen in situations where people are too far apart at the start. This may be due to the paradigm shift to IPv6 from IPv4.
As has been pointed out, there is a lot of human nature at work here: these individuals have made low-level emotional investments in their arguments, and divided the IPv6-think world into two categories: Us (right), and Not Us (wrong). When someone does this, it can take a significant amount of psychology to get the conversation to a rational place, and unless you have a real need to see eye to eye with them, it's often easier to move on. In any case, do the research and testing, and make sure that at least your own deployments have rational addressing policies (whatever you determine that might be).
I wish you hadn't gone into the psychological babble here. You are right about this though. Do what you think is best for you. Please do not denigrate others for not coming to the same conclusions as you. When you ask for an opinion on this type of medium, about a controversial topic, you will get this type of thread. Live it.... Love it! - Brian Johnson
On Wed, Nov 30, 2011 at 1:18 PM, Mark Blackman <mark@exonetric.com> wrote:
... and I'm not sure why SLAAC wanted more than 48 bits.
One reason IPv6 addresses are 128 bits long instead of 40, 48, 64 or 80 is because converting from IPv4 to IPv6 is really painful and we don't want to ever have to do it again in the future. Eventually we will run out of 48-bit MAC addresses, because we'll run out of 24-bit manufacturer ID parts, and we'll transition to EUI-64 or something like it. It will be ugly and painful, and it will break many things, and if we used 48-bit MAC addresses for SLAAC, it would break IPv6 as well. Using EUI-64 instead of MAC means that all the breakage will live at Layer 2. It does break some things in IPv6 - we've spent a couple of years arguing about whether ISPs should give customers /48, /56, /60, or /64, instead of having the nice clean "64 bits for the network provider, 16 bits for subnet, 48 for MAC" that the earlier proposals adapted from Netware IPX, but that would probably have gotten us in trouble also. I can't explain why EUI-64 picked its particular ugly way to convert 48-bit MACs to 64-bit, but I won't rant about that here. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
On 30 Nov 2011, at 23:02, Bill Stewart wrote:
On Wed, Nov 30, 2011 at 1:18 PM, Mark Blackman <mark@exonetric.com> wrote:
... and I'm not sure why SLAAC wanted more than 48 bits.
One reason IPv6 addresses are 128 bits long instead of 40, 48, 64 or 80 is because converting from IPv4 to IPv6 is really painful and we don't want to ever have to do it again in the future.
Sure, 128 bits I can see the point of. Rigid insistence on /64 subnets when no broadcast domain will ever have 2^64 devices on it seems like a less obvious choice. - Mark
I agree with pretty much everything Bill, Doug, and Nathan just said. Just remember "640K ought to be enough for anybody." ;-) It's usually unwise to make statements about "never needing more than" where technology is concerned. IPv6 is still in its "let's get people to use this" phase; I don't think any of us have a clue what kind of new innovation may or may not take place in a world where address space isn't a concern. I would say absolutely reserve 64-bit's per host network in your schema. Even though we talk about broadcast domains, IPv6 shifts the conversation to multicast (and can possibly do away with the need for L2 broadcasts at some point); eventually we might be able to scale these domains to much, much larger levels that previously imagined. 2^64 large? perhaps not, but several thousands or tens of thousands, probably. If we do see this kind of evolution; being able to easily bump your networks up to 64-bit will save you a lot of pain; in the meantime, if you don't need anything that a 64-bit prefix provides (e.g. SLAAC), then by all means, just use what you need. There is a lot of talk about "buggy" systems that are unable to handle prefixes longer than 64; but I've yet to encounter one. I imagine if I did it would be treated as a bug and fixed. So to the question of supporting different prefix lengths: Yes. You should support any valid IPv6 prefix length; it takes a few extra lines of code in the beginning; but will save you a lot of re-coding in the end. I think using DHCPv6 PD, and handing out 64-bit allocations for residential users, and even running SLAAC would work quite nicely. We have moved to a model where customers like having their own domain of control while keeping things simple, and this does that. At the same time; if an ISP wants to put all their customers in an area on a shared prefix, I'm not going to complain about that either. I'd rather have functional native IPv6 at my house than no IPv6 at this point (just let me have as many addresses as I need, please). The fear is that this will push consumers to continue the use of NAT instead of something more friendly like NPT; but if that's the way it is to be then so be it. Plenty of time for the different delivery models to compete and battle it out. I will say that people have gotten used to controlling their own security domain, and it might not be something they're OK with giving up, especially as the Home gets smarter (refrigerator, microwave, entertainment system, healing, lighting, etc. all with addresses). One thing I probably don't need to point out but will anyway, is that IPv6 as it is today is what we have to work with. It took 10 years to get mature OS support established, and likely another 10 to phase out the systems that don't support it. There are plenty of good debates to have on the number of bits for this and the number of nibblets for that; but you're not going to change the IPv6 implementation in any meaningful way at this point; so the debates over the fundamentals of the protocol aren't productive. We have a reasonable foundation to work with that should provide us with flexibility to grow over time, we just need to start implementing it (and developing the software systems to make it all easy). The tweaks will come over time; and vendors will be more inclined to care about them if it's actually being used. On a more productive note; now that we have the workings of IPv6 NAT, has anyone had a chance to play with it yet? I'm anxious to play with the NPT stuff, myself. I wonder how broken it is. ;-) On Wed, Nov 30, 2011 at 6:33 PM, Mark Blackman <mark@exonetric.com> wrote:
On 30 Nov 2011, at 23:02, Bill Stewart wrote:
On Wed, Nov 30, 2011 at 1:18 PM, Mark Blackman <mark@exonetric.com> wrote:
... and I'm not sure why SLAAC wanted more than 48 bits.
One reason IPv6 addresses are 128 bits long instead of 40, 48, 64 or 80 is because converting from IPv4 to IPv6 is really painful and we don't want to ever have to do it again in the future.
Sure, 128 bits I can see the point of. Rigid insistence on /64 subnets when no broadcast domain will ever have 2^64 devices on it seems like a less obvious choice.
- Mark
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
On Wed, 30 Nov 2011 19:19:51 EST, Ray Soucy said:
There is a lot of talk about "buggy" systems that are unable to handle prefixes longer than 64; but I've yet to encounter one. I imagine if I did it would be treated as a bug and fixed.
What year did Cisco first release IOS? What year did Cisco finally stamp the last vestiges of class A/B/C out of IOS? That's how many years it will take to get rid of the last buggy IPv6 that won't do a 64+ prefix.
In a message written on Wed, Nov 30, 2011 at 07:19:51PM -0500, Ray Soucy wrote:
There is a lot of talk about "buggy" systems that are unable to handle prefixes longer than 64; but I've yet to encounter one. I imagine if
This has been one of the first thing I tested with new router gear for, well, a decade or more now of IPv6 testing. I too have never encountered such a box, even in the early days of IPv6. I think if any such boxes were made they were likely prototypes and never sold in quantity. There was a different, but related problem early on. Platforms with 32-bit TCAM that had to be retrofitted for IPv6 had to do multiple lookups. Two lookups got you 64 bits, and since 64 bits was the "longest subnet" they did dumb things past that bit boundary. This could result in less than line rate performance of IPv6 frames. I'm honestly having trouble remembering which platforms had this issue, perhaps someone remembers better than I do. However, I do think my lack of memory is in part because I haven't encountered one in a network anytime recently... In short, a total non-issue in terms of IPv6 deployment today. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On Thursday, December 01, 2011 08:19:51 AM Ray Soucy wrote:
There is a lot of talk about "buggy" systems that are unable to handle prefixes longer than 64; but I've yet to encounter one. I imagine if I did it would be treated as a bug and fixed. So to the question of supporting different prefix lengths: Yes. You should support any valid IPv6 prefix length; it takes a few extra lines of code in the beginning; but will save you a lot of re-coding in the end.
Exactly. /126's for point-to-points, and /112's for router LAN's here, 6 years and counting. Mark.
On Wed, Nov 30, 2011 at 2:13 PM, Owen DeLong <owen@delong.com> wrote:
On Nov 30, 2011, at 9:10 AM, Ray Soucy wrote: I do believe that there is no benefit to longer prefixes than /64. Nobody has provided any convincing evidence to the contrary.
Yes they have, thoroughly; mitigation of this one particular issue, ND table overflow is a benefit. You simply don't have to worry about this issue in the most important place it arises if you implement long prefixes for all P-t-P links from the start. I do believe there is no benefit to prefixes shorter than /126 for P-t-P links. Nobody has provided convincing evidence to the contrary.
There are better ways to mitigate ND than longer prefixes.
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. Keeping in mind we have already explained why stateful firewalls and ACLs are not good ways to mitigate ND overflow, they are very poor ways, because they are expensive, both up front, and continuously in the form of added maintenance work, and add a great amount of undesirable complexity. Neither of those methods pass as "better than using long prefixes". Until the "better ways" have been explained, use of long prefixes remains the best option. -- -JH
On Wed, Nov 30, 2011 at 06:55:56PM -0600, Jimmy Hess wrote:
On Wed, Nov 30, 2011 at 2:13 PM, Owen DeLong <owen@delong.com> wrote:
On Nov 30, 2011, at 9:10 AM, Ray Soucy wrote: I do believe that there is no benefit to longer prefixes than /64. Nobody has provided any convincing evidence to the contrary.
Yes they have, thoroughly; mitigation of this one particular issue, ND table overflow is a benefit. You simply don't have to worry about this issue in the most important place it arises if you implement long prefixes for all P-t-P links from the start.
I do believe there is no benefit to prefixes shorter than /126 for P-t-P links. Nobody has provided convincing evidence to the contrary.
There are better ways to mitigate ND than longer prefixes.
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.
Jumping in here, how about static ND entries? Then you can use the /64 for P-t-P, but set the few static ND entries you need, and turn off dynamic ND. An out-of-band provisioning system could add static ND entries as needed. Another idea, perhaps more useful for client LANs, would be to have a fixed mapping between IPv6 IID and MAC address. Use DHCPv6 to force clients' lower 64 bits to be equal to their MAC address (EUI-64 or similar) and program the router to use this directly instead of using NDP, or statically program the ND table on the router from the DHCPv6 lease data--there is already precedent for doing this with IPv4 & ARP using DHCP Snooping or Relay or Proxy on the router.
On Thu, Dec 1, 2011 at 9:42 AM, Chuck Anderson <cra@wpi.edu> wrote:
Jumping in here, how about static ND entries? Then you can use the /64 for P-t-P, but set the few static ND entries you need, and turn off dynamic ND. An out-of-band provisioning system could add static ND entries as needed.
Another idea, perhaps more useful for client LANs, would be to have a fixed mapping between IPv6 IID and MAC address. Use DHCPv6 to force
Chuck, you are certainly correct that if ND resolution can be deactivated for an interface, there won't be an ND exhaustion problem on it. That's why I characterize the problem as ND exhaustion. :-) Whether or not this is practical for a given environment is up to the operators to decide. I, for example, know it is much easier for me to configure a /126 P-t-P than keep static ND entries and disable ND on those links. In my own backbone, your suggestion can be practical, but what about customer links? If the customer changes his device, he may present a different MAC address to my interface. Then I've got a static ND entry pointing to his old MAC address... resulting in a ticket, and ops work, which would not have been necessary with a simple /126. DHCPv6 with snooping and learning disabled would be great for the datacenter LAN if I thought I could get customers to bite off on it. When vendors begin delivering this feature it is something we will strongly consider. I don't know if customers will prefer to have this and need to run a DHCPv6 client, or prefer to have a /120 (or similar) for the approximate number of addresses they plan to use. I am not closed to alternatives. I want to give my customers /64s as soon as it becomes practical and production-ready. That is why we always reserve a /64 for each subnet, even though it is provisioned as a longer subnet. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
On Wed, Nov 30, 2011 at 10:39 AM, Jeff Wheeler <jsw@inconcepts.biz> wrote:
On Wed, Nov 30, 2011 at 9:48 AM, Ray Soucy <rps@maine.edu> wrote: Owen has suggested "stateful firewall" as a solution to me in the past. There is not currently any firewall with the necessary features to do this. We sometimes knee-jerk and think "stateful firewall has gobs of memory and can spend more CPU time on each packet, so it is a more likely solution." In this case that does not matter. You can't have 2^64 bits of memory.
In principle, a firewall doesn't need 2^64 bits of memory. You can have a single tree node that tells you "OK, all the interface IDs in the range 0x0000000000000000 through 0x000000000007ffff on Interface/network X are in state X; there comes a point where you can discard stale data long before it gets close to 2^64 bits. That's all well and good that in theory you could construct a stateful firewall to protect some /126 inter-router links, but seriously.. Why should you? Stateful firewalls are not free; neither is making a stateful firewall that can do that. What's the overwhelming benefit of forcing in a /126 on your P-t-P inter-router links if it has risks and complicates matters so much? -- -JH
In a message written on Wed, Nov 30, 2011 at 01:41:49PM -0600, Jimmy Hess wrote:
What's the overwhelming benefit of forcing in a /126 on your P-t-P inter-router links if it has risks and complicates matters so much?
Making Owen happy. :) -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
A /112 is almost as bad for the ND attacks as a /64, so, I don't see any reason to use a /112 at all. IMHO, the preferred link network sizes for IPv6 are, in order, /64, /127, /126, /112. Since there's no downside to the first one so long as you take proper precautions about ND attacks, most environments can stop there. If you are actually worried about ND, then consider /127. The only reason to avoid it is if you have routers with code implementing RFCs that have been deprecated for more than 5 years. Better to update your code, but, if you can't, move to /126. It's a silly number, but, at least it's a little less silly than /112. Owen On Nov 29, 2011, at 9:00 AM, McCall, Gabriel wrote:
Note that /127 is strongly discouraged in RFC5375 and RFC3627. 3627 suggests using /112 for router links, or /126 at the very most.
-----Original Message----- From: Fred Baker [mailto:fred@cisco.com] ... I see no reason you couldn't use a /127 prefix if the link was point to point. ...
Steven, SLAAC is prohibited for using in DOCSIS networks, router advertisements that allow SLAAC must be ignored by end-devices, therefore DHCPv6 is the only way of configuring (if not talking about statical assignment). I have seen at least Windows7 handling this properly in its default configuration: it starts DHCPv6 negotiation instead of auto-configuration. Dmitry Cherkasov 2011/11/29 Steven Bellovin <smb@cs.columbia.edu>:
On Nov 28, 2011, at 4:51 52PM, Owen DeLong wrote:
On Nov 28, 2011, at 7:29 AM, Ray Soucy wrote:
It's a good practice to reserve a 64-bit prefix for each network. That's a good general rule. For point to point or link networks you can use something as small as a 126-bit prefix (we do).
Technically, absent buggy {firm,soft}ware, you can use a /127. There's no actual benefit to doing anything longer than a /64 unless you have buggy *ware (ping pong attacks only work against buggy *ware), and there can be some advantages to choosing addresses other than ::1 and ::2 in some cases. If you're letting outside packets target your point-to-point links, you have bigger problems than neighbor table attacks. If not, then the neighbor table attack is a bit of a red-herring.
The context is DOCSIS, i.e., primarily residential cable modem users, and the cable company ISPs do not want to spend time on customer care and hand-holding. How are most v6 machines configured by default? That is, what did Microsoft do for Windows Vista and Windows 7? If they're set for stateless autoconfig, I strongly suspect that most ISPs will want to stick with that and hand out /64s to each network. (That's apart from the larger question of why they should want to do anything else...)
--Steve Bellovin, https://www.cs.columbia.edu/~smb
Technically this is not true. SLAAC is not prohibited, it does come with side affects that complicate the deployment of IPv6. It is technically feasible to use SLAAC, it is just not practical in most cases. Stateful DHCPv6 is the preferred mechanism for address and configuration assignment. Prefix delegation requires the use of stateful DHCPv6 in DOCSIS networks. John ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= On 11/29/11 7:09 AM, "Dmitry Cherkasov" <doctorchd@gmail.com> wrote:
Steven,
SLAAC is prohibited for using in DOCSIS networks, router advertisements that allow SLAAC must be ignored by end-devices, therefore DHCPv6 is the only way of configuring (if not talking about statical assignment). I have seen at least Windows7 handling this properly in its default configuration: it starts DHCPv6 negotiation instead of auto-configuration.
Dmitry Cherkasov
2011/11/29 Steven Bellovin <smb@cs.columbia.edu>:
On Nov 28, 2011, at 4:51 52PM, Owen DeLong wrote:
On Nov 28, 2011, at 7:29 AM, Ray Soucy wrote:
It's a good practice to reserve a 64-bit prefix for each network. That's a good general rule. For point to point or link networks you can use something as small as a 126-bit prefix (we do).
Technically, absent buggy {firm,soft}ware, you can use a /127. There's no actual benefit to doing anything longer than a /64 unless you have buggy *ware (ping pong attacks only work against buggy *ware), and there can be some advantages to choosing addresses other than ::1 and ::2 in some cases. If you're letting outside packets target your point-to-point links, you have bigger problems than neighbor table attacks. If not, then the neighbor table attack is a bit of a red-herring.
The context is DOCSIS, i.e., primarily residential cable modem users, and the cable company ISPs do not want to spend time on customer care and hand-holding. How are most v6 machines configured by default? That is, what did Microsoft do for Windows Vista and Windows 7? If they're set for stateless autoconfig, I strongly suspect that most ISPs will want to stick with that and hand out /64s to each network. (That's apart from the larger question of why they should want to do anything else...)
--Steve Bellovin, https://www.cs.columbia.edu/~smb
John, Due to your note I carefully read again Cable Labs specs and found that really SLAAC is not prohibited. According to CM-SP-MULPIv3.0: * If the M bit in the RA is set to 1, the CM (cable modem) MUST use DHCPv6 ...; * If there are no prefix information options in the RA, the CM MUST NOT perform SLAAC; * If the RA contains a prefix advertisement with the A bit set to 0, the CM MUST NOT perform SLAAC on that prefix. That means that if M bit in the RA is set to 0 and RA contains a prefix advertisement with the A bit set to 1 nothing prevents CM from SLAAC. And if so we probably better reserve /64 per network just in case we may use SLAAC in it in the future. While we do not use SLAAC we can shorten the range of actually used IPv6 addresses by using longer then /64 prefix. You are completely right that prefix delegation enforce DHCPv6 so SLAAC mentioned above can be used only for CMs, not for CPE. Just a note: as far as I can see available DOCSIS 3.0 CMTSes do not support the ability of SLAAC for CMs currently (checked Casa and Cisco uBR10K). Dmitry Cherkasov 2011/11/30 Brzozowski, John <John_Brzozowski@cable.comcast.com>:
Technically this is not true. SLAAC is not prohibited, it does come with side affects that complicate the deployment of IPv6. It is technically feasible to use SLAAC, it is just not practical in most cases.
Stateful DHCPv6 is the preferred mechanism for address and configuration assignment. Prefix delegation requires the use of stateful DHCPv6 in DOCSIS networks.
John ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net =========================================
On 11/29/11 7:09 AM, "Dmitry Cherkasov" <doctorchd@gmail.com> wrote:
Steven,
SLAAC is prohibited for using in DOCSIS networks, router advertisements that allow SLAAC must be ignored by end-devices, therefore DHCPv6 is the only way of configuring (if not talking about statical assignment). I have seen at least Windows7 handling this properly in its default configuration: it starts DHCPv6 negotiation instead of auto-configuration.
Dmitry Cherkasov
2011/11/29 Steven Bellovin <smb@cs.columbia.edu>:
On Nov 28, 2011, at 4:51 52PM, Owen DeLong wrote:
On Nov 28, 2011, at 7:29 AM, Ray Soucy wrote:
It's a good practice to reserve a 64-bit prefix for each network. That's a good general rule. For point to point or link networks you can use something as small as a 126-bit prefix (we do).
Technically, absent buggy {firm,soft}ware, you can use a /127. There's no actual benefit to doing anything longer than a /64 unless you have buggy *ware (ping pong attacks only work against buggy *ware), and there can be some advantages to choosing addresses other than ::1 and ::2 in some cases. If you're letting outside packets target your point-to-point links, you have bigger problems than neighbor table attacks. If not, then the neighbor table attack is a bit of a red-herring.
The context is DOCSIS, i.e., primarily residential cable modem users, and the cable company ISPs do not want to spend time on customer care and hand-holding. How are most v6 machines configured by default? That is, what did Microsoft do for Windows Vista and Windows 7? If they're set for stateless autoconfig, I strongly suspect that most ISPs will want to stick with that and hand out /64s to each network. (That's apart from the larger question of why they should want to do anything else...)
--Steve Bellovin, https://www.cs.columbia.edu/~smb
See below. On 12/1/11 5:11 AM, "Dmitry Cherkasov" <doctorchd@gmail.com> wrote:
John,
Due to your note I carefully read again Cable Labs specs and found that really SLAAC is not prohibited. According to CM-SP-MULPIv3.0: [jjmb] I was part of the team that wrote IPv6 for DOCSIS, so I know the history well. ;)
* If the M bit in the RA is set to 1, the CM (cable modem) MUST use DHCPv6 ...; * If there are no prefix information options in the RA, the CM MUST NOT perform SLAAC;
[jjmb] even if there are PIOs and the A bit is set to 0, the CM will not/must not perform SLAAC.
* If the RA contains a prefix advertisement with the A bit set to 0, the CM MUST NOT perform SLAAC on that prefix. [jjmb] yes, see above.
That means that if M bit in the RA is set to 0 and RA contains a prefix advertisement with the A bit set to 1 nothing prevents CM from SLAAC. [jjmb] correct.
And if so we probably better reserve /64 per network just in case we may use SLAAC in it in the future. While we do not use SLAAC we can shorten the range of actually used IPv6 addresses by using longer then /64 prefix. [jjmb] I suppose, again not sure why you would want to take this route. This also assumes no PIOs in the RA. Please note there are other operational reason why SLAAC is not a truly deployable alternative. We can discuss off list if you are interested.
You are completely right that prefix delegation enforce DHCPv6 so SLAAC mentioned above can be used only for CMs, not for CPE. [jjmb] similar to cable modems, CPEs that only request or require IA_NA could conceivably use SLAAC. Same caveat and comments as above.
Just a note: as far as I can see available DOCSIS 3.0 CMTSes do not support the ability of SLAAC for CMs currently (checked Casa and Cisco uBR10K).
[jjmb] I am sure you make it work on at least one of the above. :)
Dmitry Cherkasov
2011/11/30 Brzozowski, John <John_Brzozowski@cable.comcast.com>:
Technically this is not true. SLAAC is not prohibited, it does come with side affects that complicate the deployment of IPv6. It is technically feasible to use SLAAC, it is just not practical in most cases.
Stateful DHCPv6 is the preferred mechanism for address and configuration assignment. Prefix delegation requires the use of stateful DHCPv6 in DOCSIS networks.
John ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net =========================================
On 11/29/11 7:09 AM, "Dmitry Cherkasov" <doctorchd@gmail.com> wrote:
Steven,
SLAAC is prohibited for using in DOCSIS networks, router advertisements that allow SLAAC must be ignored by end-devices, therefore DHCPv6 is the only way of configuring (if not talking about statical assignment). I have seen at least Windows7 handling this properly in its default configuration: it starts DHCPv6 negotiation instead of auto-configuration.
Dmitry Cherkasov
2011/11/29 Steven Bellovin <smb@cs.columbia.edu>:
On Nov 28, 2011, at 4:51 52PM, Owen DeLong wrote:
On Nov 28, 2011, at 7:29 AM, Ray Soucy wrote:
It's a good practice to reserve a 64-bit prefix for each network. That's a good general rule. For point to point or link networks you can use something as small as a 126-bit prefix (we do).
Technically, absent buggy {firm,soft}ware, you can use a /127. There's no actual benefit to doing anything longer than a /64 unless you have buggy *ware (ping pong attacks only work against buggy *ware), and there can be some advantages to choosing addresses other than ::1 and ::2 in some cases. If you're letting outside packets target your point-to-point links, you have bigger problems than neighbor table attacks. If not, then the neighbor table attack is a bit of a red-herring.
The context is DOCSIS, i.e., primarily residential cable modem users, and the cable company ISPs do not want to spend time on customer care and hand-holding. How are most v6 machines configured by default? That is, what did Microsoft do for Windows Vista and Windows 7? If they're set for stateless autoconfig, I strongly suspect that most ISPs will want to stick with that and hand out /64s to each network. (That's apart from the larger question of why they should want to do anything else...)
--Steve Bellovin, https://www.cs.columbia.edu/~smb
Windows (Vista and later) and OS X (as of Lion) now have mature IPv6 implementations and support DHCPv6 for address allocation. Furthermore, they correctly let the network decide which method is used and only provide the user with the option of "Manual" or "Automatic", where Automatic will make use of SLAAC, DHCPv6, or both, depending on the flags set in the IPv6 RA. We run both systems, in production, using DHCPv6 on prefixes much smaller than 64-bit (typically 120 or 119; we mirror whatever the IPv4 prefix length is). There is functionality (current and future) that the use of a 64-bit prefix provides; so it's a good idea to reserve that space for any LAN network, even if you implement it as a 120-bit prefix on the router. Just to be clear, I don't recommend not reserving a 64-bit prefix per network. That said; neighbor table exhaustion is a real problem. A few lines of C can kill IPv6 on enterprise- and carrier-grade routers. It's a problem that has gone largely ignored because people are still in a private address space mindset. We use 126-bit prefixes for link networks (we would have used 127, but the arguments against them in RFC 3627 were compelling enough to avoid them; after all we don't have a lack of space). There are a few reasons for this: 1. It let's us keep link address short by using the beginning of our allocation (e.g. you'll see things like 2610:48::66 in traceroutes to us), which are easily memorized in the event of DNS failure (face it; there are still some addresses you'll memorize; even if they are IPv6). 2. We know that the number of hosts on these networks is finite; it will always be 2, so using a 64-bit prefix isn't useful in any way; and until we see routers hardened against neighbor table exhaustion, they're actually harmful. 3. We have thousands of link networks; giving them all a 64-bit prefix seems rather wasteful. We've been running IPv6 in production since 2009, and when we first jumped into it I was in the same camp of being a purist; thinking SLAAC was the best; that DHCPv6 wasn't needed; that every network should always be a 64-bit prefix; etc. A few years of experience with using IPv6 in an operational environment has taught me otherwise. I'm not saying posts on list about not using anything but a 64-bit prefix are wrong; but it's a little more complicated than one-size-fits-all networking. It is perfectly valid to make use of prefixes other than 64-bit; so long as you understand the implications of doing so. SLAAC is a great bootstrapping mechanism for ad-hoc networking; and the link-local scope (allowing all IPv6 traffic to happen over IPv6; even neighbor discovery). Just because it's a neat and useful way of addressing doesn't mean it's the best way for every network. Different strokes for different blokes and all that. To those who noticed me and Owen seem to have this argument on-list a few times a year, sorry for the recycled content. ;-) On Mon, Nov 28, 2011 at 5:00 PM, Steven Bellovin <smb@cs.columbia.edu> wrote:
On Nov 28, 2011, at 4:51 52PM, Owen DeLong wrote:
On Nov 28, 2011, at 7:29 AM, Ray Soucy wrote:
It's a good practice to reserve a 64-bit prefix for each network. That's a good general rule. For point to point or link networks you can use something as small as a 126-bit prefix (we do).
Technically, absent buggy {firm,soft}ware, you can use a /127. There's no actual benefit to doing anything longer than a /64 unless you have buggy *ware (ping pong attacks only work against buggy *ware), and there can be some advantages to choosing addresses other than ::1 and ::2 in some cases. If you're letting outside packets target your point-to-point links, you have bigger problems than neighbor table attacks. If not, then the neighbor table attack is a bit of a red-herring.
The context is DOCSIS, i.e., primarily residential cable modem users, and the cable company ISPs do not want to spend time on customer care and hand-holding. How are most v6 machines configured by default? That is, what did Microsoft do for Windows Vista and Windows 7? If they're set for stateless autoconfig, I strongly suspect that most ISPs will want to stick with that and hand out /64s to each network. (That's apart from the larger question of why they should want to do anything else...)
--Steve Bellovin, https://www.cs.columbia.edu/~smb
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
In a message written on Tue, Nov 29, 2011 at 11:39:06AM -0500, Ray Soucy wrote:
We run both systems, in production, using DHCPv6 on prefixes much smaller than 64-bit (typically 120 or 119; we mirror whatever the IPv4 prefix length is).
Can you explain a bit more about how this works? My understanding of the current DHCPv6 implementations is that they had a hard assumption of a /64 prefix and the ability to do SLAAC and hear a valid RA in order to do DHCPv6. Are you doing anything special to make this happen with smaller subnets? -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
We have an in-house IPAM system that's built on top of ISC DHCPd. As far as DHCPd configuration is concerned we only ever hand out static assignments; we have a different process that monitors un-responded requests coming in; allocates an address from the database (if permitted by the logic), and then dynamically updates DHCPd via omapi with the [dynamic] static assignment. It's a little more involved than that; but on a basic level, we only hand out addresses (IPv4 or IPv6) to "registered" hosts in the database. A dhcpd.conf for IPv6 would look something like: ----8<---- subnet6 2001:db8:100:1442::/120 {option dhcp6.name-servers 2001:db8:100:820::b,2001:db8:100:482::7;} host example-hostname.net.maine.edu {hardware ethernet 78:2b:cb:98:ab:cd; fixed-address6 2001:db8:100:1442::13;} ----8<---- An example using the DUID: "host-identifier option dhcp6.client-id 00:01:00:01:11:ee:71:12:00:1a:a0:aa:aa:7f;" Note that with newer versions of ISC DHCPd you can specify a MAC address instead of a DUID; and if the DUID is based on that MAC it will match. Still waiting on ISC to allow us to also specify the IAID, as it would be an issue if a host had multiple NICs in use, since the DUID is shared, though, but there is always manual configuration for that special case until then. Using DHCPv6 to only hand out addresses to hosts we want to have an address has allowed us to make IPv6 ubiquitous across our 7 member universities, and participants in our R&E network. Attempts to roll out IPv6 with SLAAC was a non-starter politically; people don't like the idea of every host on a subnet grabbing an IPv6 address unless configured not to do so; especially when you consider security concerns, and potential bugs with older IPv6 implementations (RHEL 3 and kernel panic when IPv6 connection is received, for example). On Tue, Nov 29, 2011 at 11:46 AM, Leo Bicknell <bicknell@ufp.org> wrote:
In a message written on Tue, Nov 29, 2011 at 11:39:06AM -0500, Ray Soucy wrote:
We run both systems, in production, using DHCPv6 on prefixes much smaller than 64-bit (typically 120 or 119; we mirror whatever the IPv4 prefix length is).
Can you explain a bit more about how this works? My understanding of the current DHCPv6 implementations is that they had a hard assumption of a /64 prefix and the ability to do SLAAC and hear a valid RA in order to do DHCPv6. Are you doing anything special to make this happen with smaller subnets?
-- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
That said; neighbor table exhaustion is a real problem. A few lines of C can kill IPv6 on enterprise- and carrier-grade routers. It's a problem that has gone largely ignored because people are still in a private address space mindset.
Only if you don't have rational ACLs in place or you are compromised from within. If you're compromised from within, this attack makes it easy to identify and resolve the compromised boxes, so, it's a net win.
We use 126-bit prefixes for link networks (we would have used 127, but the arguments against them in RFC 3627 were compelling enough to avoid them; after all we don't have a lack of space). There are a few reasons for this:
That's obsolete and only applies to buggy routers that have implementations that comply with an RFC deprecated more than 5 years ago.
1. It let's us keep link address short by using the beginning of our allocation (e.g. you'll see things like 2610:48::66 in traceroutes to us), which are easily memorized in the event of DNS failure (face it; there are still some addresses you'll memorize; even if they are IPv6).
Doing this with /64s out of the first /xx of your allocation/assignment can work equally well. For /32s, I usually suggest reserving the first /48, for example. Scale according to your particular networks needs. There's not a whole lot of difference between remembering 2610:48:0:66::1 vs. 2610:48::66. If you wanted to get really cute about it, you could even go with 2610:48:0:66:1:: using the 2610:48:0:66:2:: for the other end of the link. (yes, those are both valid /64 static addresses).
2. We know that the number of hosts on these networks is finite; it will always be 2, so using a 64-bit prefix isn't useful in any way; and until we see routers hardened against neighbor table exhaustion, they're actually harmful.
You can easily harden against this in a variety of ways. Yes, vendors should provide additional features in this area. But until they do, you can take out 99% of the attack surface with very simple ACLs.
3. We have thousands of link networks; giving them all a 64-bit prefix seems rather wasteful.
So I have to ask... What do you do with all those prefixes you didn't use? You can waste them in a router or you can waste them on a shelf. Either way, they're idle addresses not being used.
We've been running IPv6 in production since 2009, and when we first jumped into it I was in the same camp of being a purist; thinking SLAAC was the best; that DHCPv6 wasn't needed; that every network should always be a 64-bit prefix; etc.
I think SLAAC and DHCPv6 both have their issues. Primarily because a bunch of purists from both camps spent all their time in the IETF damaging the other camp's protocol instead of perfecting their own. Hopefully now that the IETF is starting to get some additional input from actual operators this will eventually get corrected (on both sides).
A few years of experience with using IPv6 in an operational environment has taught me otherwise.
Are you saying you've seen actual ND attacks actually attack your production network other than deliberate tests? So far, I haven't seen or heard of an actual ND attack in the wild.
I'm not saying posts on list about not using anything but a 64-bit prefix are wrong; but it's a little more complicated than one-size-fits-all networking.
Agreed. However, there's a lot to be said for one-size-fits-all and if you just mitigate the ND attack issue with simple ACLs, you're back to a place where one-size-fits-all works pretty well.
It is perfectly valid to make use of prefixes other than 64-bit; so long as you understand the implications of doing so.
Absolutely. It's more likely to cause you harm than do you any good, but, you can run your network however you see fit.
SLAAC is a great bootstrapping mechanism for ad-hoc networking; and the link-local scope (allowing all IPv6 traffic to happen over IPv6; even neighbor discovery). Just because it's a neat and useful way of addressing doesn't mean it's the best way for every network. Different strokes for different blokes and all that.
You'll have a link-local with at least a /64 anyway on every link. (Technically link-local is supposed to be a /10)
To those who noticed me and Owen seem to have this argument on-list a few times a year, sorry for the recycled content. ;-)
And yet you still don't just accept that I'm right and move on. ;-) But at least it gives us a break from those that think NAT is somehow relevant to security. Owen
On Mon, Nov 28, 2011 at 4:51 PM, Owen DeLong <owen@delong.com> wrote:
Technically, absent buggy {firm,soft}ware, you can use a /127. There's no actual benefit to doing anything longer than a /64 unless you have buggy *ware (ping pong attacks only work against buggy *ware), and there can be some advantages to choosing addresses other than ::1 and ::2 in some cases. If you're letting outside packets target your point-to-point links, you have bigger problems than neighbor table attacks. If not, then the neighbor table attack is a bit of a red-herring.
Owen and I have discussed this in great detail off-list. Nearly every time this topic comes up, he posts in public that neighbor table exhaustion is a non-issue. I thought I'd mention that his plan for handling neighbor table attacks against his networks is whack-a-mole. That's right, wait for customer services to break, then have NOC guys attempt to clear tables, filter traffic, or disable services; and repeat that if the attacker is determined or going after his network rather than one of his downstream customers. I hate to drag a frank, private discussion like that into the public list; but every time Owen says this is a non-issue, you should keep in mind that his own plan is totally unacceptable for any production service. Only one of the following things can be true: either 1) Owen thinks it is okay for services to break repeatedly and require operator intervention to fix them if subjected to a trivial attack; or 2) he is lieing. Take that as you will. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
On Nov 28, 2011, at 9:15 PM, Jeff Wheeler wrote:
On Mon, Nov 28, 2011 at 4:51 PM, Owen DeLong <owen@delong.com> wrote:
Technically, absent buggy {firm,soft}ware, you can use a /127. There's no actual benefit to doing anything longer than a /64 unless you have buggy *ware (ping pong attacks only work against buggy *ware), and there can be some advantages to choosing addresses other than ::1 and ::2 in some cases. If you're letting outside packets target your point-to-point links, you have bigger problems than neighbor table attacks. If not, then the neighbor table attack is a bit of a red-herring.
Owen and I have discussed this in great detail off-list. Nearly every time this topic comes up, he posts in public that neighbor table exhaustion is a non-issue. I thought I'd mention that his plan for handling neighbor table attacks against his networks is whack-a-mole. That's right, wait for customer services to break, then have NOC guys attempt to clear tables, filter traffic, or disable services; and repeat that if the attacker is determined or going after his network rather than one of his downstream customers.
That's _NOT_ a fair characterization of what I said above, nor is it a fair characterization of my approach to dealing with neighbor table attacks. What I said above is that if you allow random traffic aimed at your point to point links, you're doing something dumb. If you don't allow random traffic, you don't have a neighbor table exhaustion attack reaching your point to point interfaces. It's that simple. That's what I said above. As to my actual plan for dealing with it, what I said was that if we ever see a neighbor table attack start causing problems with services, we'd address it at that time. Likely we would address it more globally and not through a whack-a-mole process. I did not give details of all of our mitigation strategies, nor can I. What I can say is that we do have several /64s that could be attacked such that we'd notice the attack. Most likely the attack wouldn't break anything that is a production service before we could mitigate it. In more than a decade of running production IPv6 networks, we have yet to see a neighbor table attack. Further, when you consider that most attacks have a purpose, neighbor table attacks are both more difficult and less effective than other attack vectors that are readily available. As such, I think they are less attractive to would-be attackers.
I hate to drag a frank, private discussion like that into the public list; but every time Owen says this is a non-issue, you should keep in mind that his own plan is totally unacceptable for any production service. Only one of the following things can be true: either 1) Owen thinks it is okay for services to break repeatedly and require operator intervention to fix them if subjected to a trivial attack; or 2) he is lieing. Take that as you will.
No, there is a third possibility. I don't mind you taking a frank private discussion public (though it's not very courteous), but, I do object to you misquoting me and misconstruing the nature and substance of what I said. I do not think it is OK for services to break repeatedly. I do think that the probability of an attacker finding ND attacks useful combined with the effort required to carry one out against a well-defended target make them far less likely than you characterize them to be. As such, I'm willing to limit the mitigation efforts to the steps we've already taken until they prove inadequate. IF they prove inadequate (whether that proof comes in the form of a service breakage or not), then we will address mitigation more broadly. However, investing infinite resources in preventing an unlikely and not particularly effective attack strikes me as a poor use of resources. Yes, ND attacks are possible if you leave your /64 wide open to external traffic. However, if you're using your /64 to provide services, chances are it's pretty easy to cluster your server in a much smaller range of addresses. A simple ACL that only permits packets to that range (or even twice or 4 times that range) will effectively block any meaningful ND attack. For example, let's say you use 2001:db8:fe37:57::1000:0 to 2001:db8:fe37:57:1000:01ff as the IPv6 range for a set of servers. Let's say there are 200 servers in that range. That's 200/512 good ND records for servers and 312 slots where you can put additional servers. That gives you a total attack surface of 312 incomplete ND records. This was part of my frank private discussion with Jeff, but, he seems to have forgotten it. In my mind, if your ACL only permits those 512 addresses to be reached from the outside (potentially attacking) world, then, your router isn't likely to fall over from those 312 incomplete ND entries. Maybe Jeff tries to run production services on something smaller than a LInksys WRT54G. I don't know. I certainly don't. Anything larger should be able to handle a few hundred incomplete NDs that don't belong without incident. If you have networks that you don't protect with ACLs, then, you're asking for other troubles regardless of the protocol anyway. Owen
On Tue, Nov 29, 2011 at 12:42 AM, Owen DeLong <owen@delong.com> wrote:
That's _NOT_ a fair characterization of what I said above, nor is it a fair characterization of my approach to dealing with neighbor table attacks.
Here are some direct quotes from our discussion:
Since we have relatively few customers per aggregation router, I don't think you'd be nearly as successful as you think you would.
On the platforms we use, it won't spill over into IPv4 breakage. Additionally, it will break fewer than 50 other dedicated servers and no other customers. This will be tolerated for about 5 minutes while our support department receives the alarm and looks into the cause, then, your dedicated server won't have power any more and the problem will go away along with your account.
At no time did you ever suggest you had any idea how to systemically solve this problem. Now you are claiming that you have a "more global" approach, but this is another of your lies.
All of our support guys have enough clue to get to this quickly enough and our monitoring systems would detect the abnormally large neighbor table fairly early in the process.
Your monitoring systems keep an eye on the size of your ND tables? How can this be true if you believe that ND attacks are not an issue? Did you just throw resources at monitoring this for no reason? Do you really even poll or alert on this data, or were you simply telling another lie?
Additionally, we have a network engineer on duty 24x7, so, even if the support guys don't figure it out correctly, there's backup with clue right behind them in the same room.
That is exactly "NOC whack-a-mole."
What I said above is that if you allow random traffic aimed at your point to point links, you're doing something dumb.
If your network has nothing but point-to-point links, it is easy to defend. Sadly that is not how you or I interface with many of our customers. In addition, you don't actually practice what you preach. Hurricane Electric uses /126 networks in its backbone. Why are you not rushing to change these to /64? After all, you regularly tell us about the supposed disadvantages of /126 on point-to-point links. What are these disadvantages?
As to my actual plan for dealing with it, what I said was that if we ever see a neighbor table attack start causing problems with services, we'd address it at that time. Likely we would address it more globally and not through a whack-a-mole process.
No, this is not what you said. Again, you are simply telling lies.
I did not give details of all of our mitigation strategies, nor can I.
Yes you did. Your "strategy" is whack-a-mole.
What I can say is that we do have several /64s that could be attacked such that we'd notice the attack. Most likely the attack wouldn't break anything that is a production service before we could mitigate it.
Breaking about 50 customers for as long as it takes your support staff or NOC to troubleshoot, in your mind, muts not be "breaking anything that is a production service," or else "before we could mitigate it" means you have figured out how to travel through time.
In more than a decade of running production IPv6 networks, we have yet to see a neighbor table attack. Further, when you consider that most attacks have a purpose, neighbor table attacks are both more difficult and less effective than other attack vectors that are readily available. As such, I think they are less attractive to would-be attackers.
Again, the "bad guys" don't have much motive (yet) since few services of interest share common IPv4 and IPv6 infrastructure today. That will change.
No, there is a third possibility.
I don't mind you taking a frank private discussion public (though it's not very courteous), but, I do object to you misquoting me and misconstruing the nature and substance of what I said.
It's disingenuous of you to continue to lie every time this topic comes up on the mailing list.
Yes, ND attacks are possible if you leave your /64 wide open to external traffic. However, if you're using your /64 to provide services, chances are it's pretty easy to cluster your server in a much smaller range of addresses. A simple ACL that only permits packets to that range (or even twice or 4 times that range) will effectively block any meaningful ND attack.
For example, let's say you use 2001:db8:fe37:57::1000:0 to 2001:db8:fe37:57:1000:01ff as the IPv6 range for a set of servers.
Let's say there are 200 servers in that range.
That's 200/512 good ND records for servers and 312 slots where you can put additional servers. That gives you a total attack surface of 312 incomplete ND records.
This was part of my frank private discussion with Jeff, but, he seems to have forgotten it.
Since I've re-read our earlier discussion (unlike you) I can state with certainty that it was not part of our earlier discussion. If it was, I would be happy to tell everyone that your plan for deploying IPv6 to your customers includes blocking the use of the majority of the /64, such that it would function better if it were simply a longer subnet anyway. Again, your solution makes no sense.
In my mind, if your ACL only permits those 512 addresses to be reached from the outside (potentially attacking) world, then, your router isn't likely to fall over from those 312 incomplete ND entries. Maybe Jeff tries to run production services on something smaller than a LInksys WRT54G. I don't know. I certainly don't.
If you have a small layer-3 switch with 50 users, as you do, ~512 possible ND entries per user gets you to ~25k total, if the attacker decides they want to take advantage of it. 25k is larger than the IPv6 ND table on all(?) layer-3 ToR switches. Without throttling of ND punts per destination address (which is not possible if the table is exhausted, even if the data plane has this feature otherwise) then either the ND function for legitimate traffic will be broken, or the control-plane will fail in a worse way. I think my characterization of our earlier discussion is quite fair. My characterization of our current one is very simple: you are telling some pretty big lies. Feel free to demonstrate how I am mistaken. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
On Tue, 29 Nov 2011 00:15:02 EST, Jeff Wheeler said:
Owen and I have discussed this in great detail off-list. Nearly every time this topic comes up, he posts in public that neighbor table exhaustion is a non-issue. I thought I'd mention that his plan for handling neighbor table attacks against his networks is whack-a-mole. That's right, wait for customer services to break, then have NOC guys attempt to clear tables, filter traffic, or disable services; and repeat that if the attacker is determined or going after his network rather than one of his downstream customers.
It's worked for us since 1997. We've had bigger problems with IPv4 worms that decided to probe in multicast address space for their next target, causing CPU exhaustion on routers as they try to set up zillions of multicast groups. Sure, it's a consideration. But how many sites are *actually* getting hit with this, compared to all the *other* DDOS stuff that's going on? I'm willing to bet a large pizza with everything but anchovies that out in the *real* world, 50-75 times as many (if not more) sites are getting hit with IPv4 DDoS attacks that they weren't prepared for than are seeing this one particular neighbor table exhaustion attack. Any of the guys with actual DDoS numbers want to weigh in?
On Mon, Nov 28, 2011 at 10:43 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Tue, 29 Nov 2011 00:15:02 EST, Jeff Wheeler said:
Owen and I have discussed this in great detail off-list. Nearly every time this topic comes up, he posts in public that neighbor table exhaustion is a non-issue. I thought I'd mention that his plan for handling neighbor table attacks against his networks is whack-a-mole. That's right, wait for customer services to break, then have NOC guys attempt to clear tables, filter traffic, or disable services; and repeat that if the attacker is determined or going after his network rather than one of his downstream customers.
It's worked for us since 1997. We've had bigger problems with IPv4 worms that decided to probe in multicast address space for their next target, causing CPU exhaustion on routers as they try to set up zillions of multicast groups.
Sure, it's a consideration. But how many sites are *actually* getting hit with this, compared to all the *other* DDOS stuff that's going on? I'm willing to bet a large pizza with everything but anchovies that out in the *real* world, 50-75 times as many (if not more) sites are getting hit with IPv4 DDoS attacks that they weren't prepared for than are seeing this one particular neighbor table exhaustion attack.
Any of the guys with actual DDoS numbers want to weigh in?
Agreed. While I don't have any good numbers that I can publicly offer up, it also intuitively makes sense that there's a greater proportion of IPv4 DDOS and resource exhaustion attacks vs IPv6 ones. Especially on the "distributed" part; there's a heck of lot more v4-only hosts to be 0wned and botnet'ed than dual-stacked ones. That said, I think the risk of putting a /64 on a point-to-point link is much greater than compared to a (incredibly wasteful) v4 /24 on a point-to-point. Instead of ~254 IPs one can destinate traffic towards (to cause a ARP neighbor discovery process), there's now ~18446744073709551614 addresses one can cause a router to start sending ICMPv6 messages for. For links that will only ever be point-to-point, there's no good reason (that I know of) to not use a /127. For peering LANs or places that have a handful of routers, /112's are cute, but I would think the risk is then comparable to a /64 (which has the added benefit of SLAAC). I imagine the mitigation strategies are similar for both cases though: just rate-limit how often your router will attempt neighbor discovery. Are there other methods? Cheers, jof
I suppose router operating as proxy ND (similarly to local proxy ARP in IPv4) can mitigate the threat as well. it is mentioned in 'DOCSIS 3.0 Requirements for IPv6 support' (http://tools.ietf.org/html/draft-mule-cablelabs-docsis3-ipv6-00). Dmitry Cherkasov 2011/11/29 Jonathan Lassoff <jof@thejof.com>:
On Mon, Nov 28, 2011 at 10:43 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Tue, 29 Nov 2011 00:15:02 EST, Jeff Wheeler said:
Owen and I have discussed this in great detail off-list. Nearly every time this topic comes up, he posts in public that neighbor table exhaustion is a non-issue. I thought I'd mention that his plan for handling neighbor table attacks against his networks is whack-a-mole. That's right, wait for customer services to break, then have NOC guys attempt to clear tables, filter traffic, or disable services; and repeat that if the attacker is determined or going after his network rather than one of his downstream customers.
It's worked for us since 1997. We've had bigger problems with IPv4 worms that decided to probe in multicast address space for their next target, causing CPU exhaustion on routers as they try to set up zillions of multicast groups.
Sure, it's a consideration. But how many sites are *actually* getting hit with this, compared to all the *other* DDOS stuff that's going on? I'm willing to bet a large pizza with everything but anchovies that out in the *real* world, 50-75 times as many (if not more) sites are getting hit with IPv4 DDoS attacks that they weren't prepared for than are seeing this one particular neighbor table exhaustion attack.
Any of the guys with actual DDoS numbers want to weigh in?
Agreed. While I don't have any good numbers that I can publicly offer up, it also intuitively makes sense that there's a greater proportion of IPv4 DDOS and resource exhaustion attacks vs IPv6 ones. Especially on the "distributed" part; there's a heck of lot more v4-only hosts to be 0wned and botnet'ed than dual-stacked ones.
That said, I think the risk of putting a /64 on a point-to-point link is much greater than compared to a (incredibly wasteful) v4 /24 on a point-to-point. Instead of ~254 IPs one can destinate traffic towards (to cause a ARP neighbor discovery process), there's now ~18446744073709551614 addresses one can cause a router to start sending ICMPv6 messages for.
For links that will only ever be point-to-point, there's no good reason (that I know of) to not use a /127. For peering LANs or places that have a handful of routers, /112's are cute, but I would think the risk is then comparable to a /64 (which has the added benefit of SLAAC).
I imagine the mitigation strategies are similar for both cases though: just rate-limit how often your router will attempt neighbor discovery. Are there other methods?
Cheers, jof
On Tue, Nov 29, 2011 at 1:43 AM, <Valdis.Kletnieks@vt.edu> wrote:
It's worked for us since 1997. We've had bigger problems with IPv4 worms
That's not a reason to deny that the problem exists. It's even fixable. I'd prefer that vendors fixed it *before* there were massive botnet armies with IPv6 connectivity, but in case they don't, I do not deploy /64. On Tue, Nov 29, 2011 at 2:20 AM, Jonathan Lassoff <jof@thejof.com> wrote:
Agreed. While I don't have any good numbers that I can publicly offer up, it also intuitively makes sense that there's a greater proportion of IPv4 DDOS and resource exhaustion attacks vs IPv6 ones.
Of course. There are comparably few hosts with IPv6 connectivity. Bad guys aren't that familiar with IPv6 yet. Even if they are, their armies of compromised desktops probably can't launch an effective IPv6 attack yet. Lack of sources, no way to get nasty IPv6 packets to the target, or the target has different infrastructure for IPv4 and IPv6 anyway, and taking out the IPv6 one only isn't that beneficial (Happy Eyeballs features and such.) Further, the victim can just turn off IPv6 when they start getting attacked in this way. And that is exactly what sites will end up doing, turning off IPv6 because vendors aren't addressing issues like these. That doesn't help anyone.
I imagine the mitigation strategies are similar for both cases though: just rate-limit how often your router will attempt neighbor discovery. Are there other methods?
Simply rate-limiting the data-plane events that trigger ND resolution is not good enough. One very popular platform that is offered with cards in horizontal or vertical orientation uses the same policer for ARP and NDP. That means when you do eventually start getting ND attacks, it will break your IPv4 services also. If you want to learn more about this, I have some slides: http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
On Tue, 29 Nov 2011 03:23:04 EST, Jeff Wheeler said:
On Tue, Nov 29, 2011 at 1:43 AM, <Valdis.Kletnieks@vt.edu> wrote:
It's worked for us since 1997. We've had bigger problems with IPv4 worms
That's not a reason to deny that the problem exists. It's even fixable. I'd prefer that vendors fixed it *before* there were massive botnet armies with IPv6 connectivity, but in case they don't, I do not deploy /64.
Umm.. Jeff? I never *tried* to deny the problem exists. But if you have an eyeball-heavy network, it's hard to not deploy /64s (currently, we do SLAAC to get the basic config, and DNS/etc is still via dhcp4/IPv4). We just see the business danger of waiting to start deploying IPv6 till the vendors are perfect as being a bigger danger than the ND exhaustion issue. (How many years did we go with ARP and DHCP spoofing being well-known issues before vendors fixed that? Yeah, exactly.)
On 11/28/11 10:29 AM, "Ray Soucy" <rps@maine.edu> wrote:
It's a good practice to reserve a 64-bit prefix for each network. That's a good general rule. For point to point or link networks you can use something as small as a 126-bit prefix (we do). [jjmb] for point to point I agree with this point. If a /64 is reserved one has greater flexibility as far as what is configured on the interfaces.
When it comes to implementation, though, it's not as simple as a yes or no answer.
The actual use of 64-bit prefixes is not something I would currently recommend for large-scale deployments due to the denial of service attack vector it opens up (neighbor table exhaustion). [jjmb] not sure I agree, this depends on where the prefix is being installed in the network.
Not using 64-bit prefixes tosses SLAAC out the window; but for many networks SLAAC may not be desirable anyway due to the lack of control it presents.
Once vendors come out with routers that are able to protect against neighbor table exhaustion, moving to a 64-bit prefix (which you hopefully reserved) will allow you to be more flexible in what addressing methods are used.
On Mon, Nov 28, 2011 at 6:37 AM, Dmitry Cherkasov <doctorchd@gmail.com> wrote:
Hello everybody,
It is commonly agreed that /64 is maximal length for LANs because if we use longer prefix we introduce conflict with stateless address autoconfiguration (SLAAC) based on EUI-64 spec. But SLAAC is not used in DOCSIS networks. So there seems to be no objections to use smaller networks per cable interfaces of CMTS. I was not able to find any recommendations anywhere including Cable Labs specs for using prefixes not greater then /64 in DOCSIS networks. Some tech from ISP assumed that DHCPv6 server may generate interface ID part of IPv6 address similarly to EUI-64 so MAC address of the device can easily be obtained from its IPv6 address, but this does not seem like convincing argument. What do you think?
Dmitry Cherkasov
-- Ray Soucy
Epic Communications Specialist
Phone: +1 (207) 561-3526
Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
You can probably do it, but, what do you gain by doing so? Owen On Nov 28, 2011, at 3:37 AM, Dmitry Cherkasov wrote:
Hello everybody,
It is commonly agreed that /64 is maximal length for LANs because if we use longer prefix we introduce conflict with stateless address autoconfiguration (SLAAC) based on EUI-64 spec. But SLAAC is not used in DOCSIS networks. So there seems to be no objections to use smaller networks per cable interfaces of CMTS. I was not able to find any recommendations anywhere including Cable Labs specs for using prefixes not greater then /64 in DOCSIS networks. Some tech from ISP assumed that DHCPv6 server may generate interface ID part of IPv6 address similarly to EUI-64 so MAC address of the device can easily be obtained from its IPv6 address, but this does not seem like convincing argument. What do you think?
Dmitry Cherkasov
Owen, Currently I research on IPv6 provisioning systems and I need to decide whether the ability to use longer then /64 prefixes should be supported in them or not. If we restrict user to using /64 per network we need to have convincing reasons for this. Best practice and common sense stand for using /64 but this may be not sufficient for some people. Dmitry Cherkasov 2011/11/28 Owen DeLong <owen@delong.com>:
You can probably do it, but, what do you gain by doing so?
Owen
On Nov 28, 2011, at 3:37 AM, Dmitry Cherkasov wrote:
Hello everybody,
It is commonly agreed that /64 is maximal length for LANs because if we use longer prefix we introduce conflict with stateless address autoconfiguration (SLAAC) based on EUI-64 spec. But SLAAC is not used in DOCSIS networks. So there seems to be no objections to use smaller networks per cable interfaces of CMTS. I was not able to find any recommendations anywhere including Cable Labs specs for using prefixes not greater then /64 in DOCSIS networks. Some tech from ISP assumed that DHCPv6 server may generate interface ID part of IPv6 address similarly to EUI-64 so MAC address of the device can easily be obtained from its IPv6 address, but this does not seem like convincing argument. What do you think?
Dmitry Cherkasov
On Tue, Nov 29, 2011 at 3:46 AM, Dmitry Cherkasov <doctorchd@gmail.com> wrote:
Currently I research on IPv6 provisioning systems and I need to decide whether the ability to use longer then /64 prefixes should be supported in them or not. If we restrict user to using /64 per network we need to have convincing reasons for this. Best practice and common sense stand for using /64 but this may be not sufficient for some people.
There's a very strong case to be made for "Be conservative in what you generate and liberal in what you accept" here. One of the primary reasons for using /64 everywhere is the fear that somebody somewhere in your network built some piece of equipment or software that you're using that doesn't let you use prefixes longer than /64, and you don't want to have to find them all the hard way. Please don't be that piece of software! My organization uses longer addresses for equipment we control because we have different ops folks handling routers, firewalls, load balancers, miscellaneous control boxes, etc. and it lets them keep track of who's in charge of what address space without requiring a /47 out of the customer's /48 network just for the management subnets for the equipment we manage for them. We've also found that in production networks, /126 usually is too long a prefix, because often we'll be doing high availability configurations with HSRP/VRRP, so it's cleaner to be /124 or shorter (plus nibble-aligned or byte-aligned address blocks make report generation less ugly.) -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
On 11/30/2011 14:46, Bill Stewart wrote:
There's a very strong case to be made for "Be conservative in what you generate and liberal in what you accept" here.
I've been saying for years that your safest bet is to reserve a /64, regardless of how many bits you use out of it, or why. If you do that you're covered either way. And in the incredibly unlikely event that you run out, and can't get more, you can go back and chop up the /64s where it's proven safe to use longer prefixes. easy peasy, Doug -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
Dmitry, You could consider the use of prefixes longer than the /64 on CMTS interfaces, however, it is not clear to me why this would be done. Further, most DHCPv6 implementations do not require that the generated IPv6 address be eui-64 based. A randomized algorithm could also be used. Another consideration is what happens after IPv6 is used for addressing cable modems. What happens when you want to address CPE or CPE routers? You are right back to /64 or shorter depending on the type of device being provisioned. FWIW - we have found that there are distinct benefits to using IPv6 beyond the amount of addresses that are available. The use of /64 is tightly coupled with these benefits. Can you elaborate as to why one would want to or need to use prefixes longer than /64? John On 11/28/11 6:37 AM, "Dmitry Cherkasov" <doctorchd@gmail.com> wrote:
Hello everybody,
It is commonly agreed that /64 is maximal length for LANs because if we use longer prefix we introduce conflict with stateless address autoconfiguration (SLAAC) based on EUI-64 spec. But SLAAC is not used in DOCSIS networks. So there seems to be no objections to use smaller networks per cable interfaces of CMTS. I was not able to find any recommendations anywhere including Cable Labs specs for using prefixes not greater then /64 in DOCSIS networks. Some tech from ISP assumed that DHCPv6 server may generate interface ID part of IPv6 address similarly to EUI-64 so MAC address of the device can easily be obtained from its IPv6 address, but this does not seem like convincing argument. What do you think?
Dmitry Cherkasov
John, I am determining technical requirements to IPv6 provisioning system for DOCSIS networks and I am deciding if it is worth to restrict user to use not less then /64 networks on cable interface. It is obvious that no true economy of IP addresses can be achieved with increasing prefix length above 64 bits. As for using EUI-64, unlike random or sequential generation it provides predictable results that may be desired, e.g. for tracking some device migration between different networks. Dmitry Cherkasov 2011/11/29 Brzozowski, John <John_Brzozowski@cable.comcast.com>:
Dmitry,
You could consider the use of prefixes longer than the /64 on CMTS interfaces, however, it is not clear to me why this would be done. Further, most DHCPv6 implementations do not require that the generated IPv6 address be eui-64 based. A randomized algorithm could also be used. Another consideration is what happens after IPv6 is used for addressing cable modems. What happens when you want to address CPE or CPE routers? You are right back to /64 or shorter depending on the type of device being provisioned.
FWIW - we have found that there are distinct benefits to using IPv6 beyond the amount of addresses that are available. The use of /64 is tightly coupled with these benefits.
Can you elaborate as to why one would want to or need to use prefixes longer than /64?
John
On 11/28/11 6:37 AM, "Dmitry Cherkasov" <doctorchd@gmail.com> wrote:
Hello everybody,
It is commonly agreed that /64 is maximal length for LANs because if we use longer prefix we introduce conflict with stateless address autoconfiguration (SLAAC) based on EUI-64 spec. But SLAAC is not used in DOCSIS networks. So there seems to be no objections to use smaller networks per cable interfaces of CMTS. I was not able to find any recommendations anywhere including Cable Labs specs for using prefixes not greater then /64 in DOCSIS networks. Some tech from ISP assumed that DHCPv6 server may generate interface ID part of IPv6 address similarly to EUI-64 so MAC address of the device can easily be obtained from its IPv6 address, but this does not seem like convincing argument. What do you think?
Dmitry Cherkasov
* Dmitry Cherkasov
I am determining technical requirements to IPv6 provisioning system for DOCSIS networks and I am deciding if it is worth to restrict user to use not less then /64 networks on cable interface. It is obvious that no true economy of IP addresses can be achieved with increasing prefix length above 64 bits.
I am not familiar with DOCSIS networks, but I thought I'd note that in order to comply with the RIPE policies, you must assign at least a /64 or shorter to each end user: http://www.ripe.net/ripe/docs/ripe-523#assignment_size -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com
Tore, To comply with this policy we delegate at least /64 to end-users gateways. But this policy does not cover the network between WAN interfaces of CPE and ISP access gateway. Dmitry Cherkasov 2011/11/29 Tore Anderson <tore.anderson@redpill-linpro.com>:
* Dmitry Cherkasov
I am determining technical requirements to IPv6 provisioning system for DOCSIS networks and I am deciding if it is worth to restrict user to use not less then /64 networks on cable interface. It is obvious that no true economy of IP addresses can be achieved with increasing prefix length above 64 bits.
I am not familiar with DOCSIS networks, but I thought I'd note that in order to comply with the RIPE policies, you must assign at least a /64 or shorter to each end user:
http://www.ripe.net/ripe/docs/ripe-523#assignment_size
-- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com
Thanks to everybody participating in the discussion. I try to summarize. 1) There is no any obvious benefit of using longer prefixes then /64 in DOCSIS networks yet there are no definite objections to use them except that it violates best practices and may lead to some problems in the future 2) DHCPv6 server can use any algorithm to generate interface ID part of the address, and EUI-64 may be just one of them that can be useful for keeping correspondence between MAC and IPv6 addresses. Yet if we use EUI-64 we definitely need to use /64 prefix 3) Using /64 networks possesses potential security threat related to neighbor tables overflow. This is wide IPv6 problem and not related to DOCSIS only There were also notes about address usage on link networks. Though this was out of the scope of original question it is agreed that using /64 is not reasonable here. BTW, RFC6164 (Using 127-Bit IPv6 Prefixes on Inter-Router Links) can be mentioned here. Dmitry Cherkasov 2011/11/29 Dmitry Cherkasov <doctorchd@gmail.com>:
Tore,
To comply with this policy we delegate at least /64 to end-users gateways. But this policy does not cover the network between WAN interfaces of CPE and ISP access gateway.
Dmitry Cherkasov
2011/11/29 Tore Anderson <tore.anderson@redpill-linpro.com>:
* Dmitry Cherkasov
I am determining technical requirements to IPv6 provisioning system for DOCSIS networks and I am deciding if it is worth to restrict user to use not less then /64 networks on cable interface. It is obvious that no true economy of IP addresses can be achieved with increasing prefix length above 64 bits.
I am not familiar with DOCSIS networks, but I thought I'd note that in order to comply with the RIPE policies, you must assign at least a /64 or shorter to each end user:
http://www.ripe.net/ripe/docs/ripe-523#assignment_size
-- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com
Dmitry et al, I found Jeff's following comments to be quite insightful for general practices. http://www.networkcomputing.com/ipv6-tech-center/231600717 http://www.networkcomputing.com/ipv6-tech-center/231700160 As for using 127s on P2P links.... He discussed reasoning behind using /64s, concerns related to "waste", ND exploits and other points as noted in RFC6164. - directed Regards, Victor K On 11-11-29 7:58 AM, "Dmitry Cherkasov" <doctorchd@gmail.com> wrote:
Thanks to everybody participating in the discussion. I try to summarize.
1) There is no any obvious benefit of using longer prefixes then /64 in DOCSIS networks yet there are no definite objections to use them except that it violates best practices and may lead to some problems in the future
2) DHCPv6 server can use any algorithm to generate interface ID part of the address, and EUI-64 may be just one of them that can be useful for keeping correspondence between MAC and IPv6 addresses. Yet if we use EUI-64 we definitely need to use /64 prefix
3) Using /64 networks possesses potential security threat related to neighbor tables overflow. This is wide IPv6 problem and not related to DOCSIS only
There were also notes about address usage on link networks. Though this was out of the scope of original question it is agreed that using /64 is not reasonable here. BTW, RFC6164 (Using 127-Bit IPv6 Prefixes on Inter-Router Links) can be mentioned here.
Dmitry Cherkasov
2011/11/29 Dmitry Cherkasov <doctorchd@gmail.com>:
Tore,
To comply with this policy we delegate at least /64 to end-users gateways. But this policy does not cover the network between WAN interfaces of CPE and ISP access gateway.
Dmitry Cherkasov
2011/11/29 Tore Anderson <tore.anderson@redpill-linpro.com>:
* Dmitry Cherkasov
I am determining technical requirements to IPv6 provisioning system for DOCSIS networks and I am deciding if it is worth to restrict user to use not less then /64 networks on cable interface. It is obvious that no true economy of IP addresses can be achieved with increasing prefix length above 64 bits.
I am not familiar with DOCSIS networks, but I thought I'd note that in order to comply with the RIPE policies, you must assign at least a /64 or shorter to each end user:
http://www.ripe.net/ripe/docs/ripe-523#assignment_size
-- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com
And here is another useful resource: http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf, particularly chapter 6.1.3 Vulnerabilities in IPv6. Dmitry Cherkasov 2011/11/29 Victor Kuarsingh <victor.kuarsingh@gmail.com>:
Dmitry et al,
I found Jeff's following comments to be quite insightful for general practices.
http://www.networkcomputing.com/ipv6-tech-center/231600717
http://www.networkcomputing.com/ipv6-tech-center/231700160
As for using 127s on P2P links....
He discussed reasoning behind using /64s, concerns related to "waste", ND exploits and other points as noted in RFC6164. - directed
Regards,
Victor K
On 11-11-29 7:58 AM, "Dmitry Cherkasov" <doctorchd@gmail.com> wrote:
Thanks to everybody participating in the discussion. I try to summarize.
1) There is no any obvious benefit of using longer prefixes then /64 in DOCSIS networks yet there are no definite objections to use them except that it violates best practices and may lead to some problems in the future
2) DHCPv6 server can use any algorithm to generate interface ID part of the address, and EUI-64 may be just one of them that can be useful for keeping correspondence between MAC and IPv6 addresses. Yet if we use EUI-64 we definitely need to use /64 prefix
3) Using /64 networks possesses potential security threat related to neighbor tables overflow. This is wide IPv6 problem and not related to DOCSIS only
There were also notes about address usage on link networks. Though this was out of the scope of original question it is agreed that using /64 is not reasonable here. BTW, RFC6164 (Using 127-Bit IPv6 Prefixes on Inter-Router Links) can be mentioned here.
Dmitry Cherkasov
2011/11/29 Dmitry Cherkasov <doctorchd@gmail.com>:
Tore,
To comply with this policy we delegate at least /64 to end-users gateways. But this policy does not cover the network between WAN interfaces of CPE and ISP access gateway.
Dmitry Cherkasov
2011/11/29 Tore Anderson <tore.anderson@redpill-linpro.com>:
* Dmitry Cherkasov
I am determining technical requirements to IPv6 provisioning system for DOCSIS networks and I am deciding if it is worth to restrict user to use not less then /64 networks on cable interface. It is obvious that no true economy of IP addresses can be achieved with increasing prefix length above 64 bits.
I am not familiar with DOCSIS networks, but I thought I'd note that in order to comply with the RIPE policies, you must assign at least a /64 or shorter to each end user:
http://www.ripe.net/ripe/docs/ripe-523#assignment_size
-- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com
On Nov 29, 2011, at 4:58 AM, Dmitry Cherkasov wrote:
Thanks to everybody participating in the discussion. I try to summarize.
1) There is no any obvious benefit of using longer prefixes then /64 in DOCSIS networks yet there are no definite objections to use them except that it violates best practices and may lead to some problems in the future
2) DHCPv6 server can use any algorithm to generate interface ID part of the address, and EUI-64 may be just one of them that can be useful for keeping correspondence between MAC and IPv6 addresses. Yet if we use EUI-64 we definitely need to use /64 prefix
3) Using /64 networks possesses potential security threat related to neighbor tables overflow. This is wide IPv6 problem and not related to DOCSIS only
99% of which can be easily mitigated by ACLs, especially in the context you are describing.
There were also notes about address usage on link networks. Though this was out of the scope of original question it is agreed that using /64 is not reasonable here. BTW, RFC6164 (Using 127-Bit IPv6 Prefixes on Inter-Router Links) can be mentioned here.
I don't agree that using /64 on link networks is not reasonable. It's perfectly fine and there is no policy against it. There are risks (buggy router code having ping pong attack exposure, ND table overflow attacks if not protected by ACL), but, otherwise, there's nothing wrong with it. Owen
Dmitry Cherkasov
2011/11/29 Dmitry Cherkasov <doctorchd@gmail.com>:
Tore,
To comply with this policy we delegate at least /64 to end-users gateways. But this policy does not cover the network between WAN interfaces of CPE and ISP access gateway.
Dmitry Cherkasov
2011/11/29 Tore Anderson <tore.anderson@redpill-linpro.com>:
* Dmitry Cherkasov
I am determining technical requirements to IPv6 provisioning system for DOCSIS networks and I am deciding if it is worth to restrict user to use not less then /64 networks on cable interface. It is obvious that no true economy of IP addresses can be achieved with increasing prefix length above 64 bits.
I am not familiar with DOCSIS networks, but I thought I'd note that in order to comply with the RIPE policies, you must assign at least a /64 or shorter to each end user:
http://www.ripe.net/ripe/docs/ripe-523#assignment_size
-- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com
Could you provide an example of such an ACL that can prevent neighbor table exhaustion while maintaining a usable 64-bit prefix? I am intrigued. On Tue, Nov 29, 2011 at 12:21 PM, Owen DeLong <owen@delong.com> wrote:
On Nov 29, 2011, at 4:58 AM, Dmitry Cherkasov wrote:
Thanks to everybody participating in the discussion. I try to summarize.
1) There is no any obvious benefit of using longer prefixes then /64 in DOCSIS networks yet there are no definite objections to use them except that it violates best practices and may lead to some problems in the future
2) DHCPv6 server can use any algorithm to generate interface ID part of the address, and EUI-64 may be just one of them that can be useful for keeping correspondence between MAC and IPv6 addresses. Yet if we use EUI-64 we definitely need to use /64 prefix
3) Using /64 networks possesses potential security threat related to neighbor tables overflow. This is wide IPv6 problem and not related to DOCSIS only
99% of which can be easily mitigated by ACLs, especially in the context you are describing.
There were also notes about address usage on link networks. Though this was out of the scope of original question it is agreed that using /64 is not reasonable here. BTW, RFC6164 (Using 127-Bit IPv6 Prefixes on Inter-Router Links) can be mentioned here.
I don't agree that using /64 on link networks is not reasonable. It's perfectly fine and there is no policy against it. There are risks (buggy router code having ping pong attack exposure, ND table overflow attacks if not protected by ACL), but, otherwise, there's nothing wrong with it.
Owen
Dmitry Cherkasov
2011/11/29 Dmitry Cherkasov <doctorchd@gmail.com>:
Tore,
To comply with this policy we delegate at least /64 to end-users gateways. But this policy does not cover the network between WAN interfaces of CPE and ISP access gateway.
Dmitry Cherkasov
2011/11/29 Tore Anderson <tore.anderson@redpill-linpro.com>:
* Dmitry Cherkasov
I am determining technical requirements to IPv6 provisioning system for DOCSIS networks and I am deciding if it is worth to restrict user to use not less then /64 networks on cable interface. It is obvious that no true economy of IP addresses can be achieved with increasing prefix length above 64 bits.
I am not familiar with DOCSIS networks, but I thought I'd note that in order to comply with the RIPE policies, you must assign at least a /64 or shorter to each end user:
http://www.ripe.net/ripe/docs/ripe-523#assignment_size
-- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
On Nov 29, 2011, at 9:46 AM, Ray Soucy wrote:
Could you provide an example of such an ACL that can prevent neighbor table exhaustion while maintaining a usable 64-bit prefix? I am intrigued.
For a point-to-point link... Sure... Router A: 2001:db8:0:0:1:: Router B: 2001:db8:0:0:2:: permit ipv6 any 2001:db8:0:0:3:: 0000:0000:0000:0000:0003:0000:0000:0000 Or, if you prefer: Router A: 2001:db8::1 Router B: 2001:db8::2 permit ipv6 any 2001:db8::3 0000:0000:0000:0000:0000:0000:0000:0003 Owen
On Tue, Nov 29, 2011 at 12:21 PM, Owen DeLong <owen@delong.com> wrote:
On Nov 29, 2011, at 4:58 AM, Dmitry Cherkasov wrote:
Thanks to everybody participating in the discussion. I try to summarize.
1) There is no any obvious benefit of using longer prefixes then /64 in DOCSIS networks yet there are no definite objections to use them except that it violates best practices and may lead to some problems in the future
2) DHCPv6 server can use any algorithm to generate interface ID part of the address, and EUI-64 may be just one of them that can be useful for keeping correspondence between MAC and IPv6 addresses. Yet if we use EUI-64 we definitely need to use /64 prefix
3) Using /64 networks possesses potential security threat related to neighbor tables overflow. This is wide IPv6 problem and not related to DOCSIS only
99% of which can be easily mitigated by ACLs, especially in the context you are describing.
There were also notes about address usage on link networks. Though this was out of the scope of original question it is agreed that using /64 is not reasonable here. BTW, RFC6164 (Using 127-Bit IPv6 Prefixes on Inter-Router Links) can be mentioned here.
I don't agree that using /64 on link networks is not reasonable. It's perfectly fine and there is no policy against it. There are risks (buggy router code having ping pong attack exposure, ND table overflow attacks if not protected by ACL), but, otherwise, there's nothing wrong with it.
Owen
Dmitry Cherkasov
2011/11/29 Dmitry Cherkasov <doctorchd@gmail.com>:
Tore,
To comply with this policy we delegate at least /64 to end-users gateways. But this policy does not cover the network between WAN interfaces of CPE and ISP access gateway.
Dmitry Cherkasov
2011/11/29 Tore Anderson <tore.anderson@redpill-linpro.com>:
* Dmitry Cherkasov
I am determining technical requirements to IPv6 provisioning system for DOCSIS networks and I am deciding if it is worth to restrict user to use not less then /64 networks on cable interface. It is obvious that no true economy of IP addresses can be achieved with increasing prefix length above 64 bits.
I am not familiar with DOCSIS networks, but I thought I'd note that in order to comply with the RIPE policies, you must assign at least a /64 or shorter to each end user:
http://www.ripe.net/ripe/docs/ripe-523#assignment_size
-- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com
-- Ray Soucy
Epic Communications Specialist
Phone: +1 (207) 561-3526
Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
From a requirements point of view I am not sure I would enforce these sort of restrictions.
John On 11/29/11 6:59 AM, "Dmitry Cherkasov" <doctorchd@gmail.com> wrote:
John,
I am determining technical requirements to IPv6 provisioning system for DOCSIS networks and I am deciding if it is worth to restrict user to use not less then /64 networks on cable interface. It is obvious that no true economy of IP addresses can be achieved with increasing prefix length above 64 bits.
As for using EUI-64, unlike random or sequential generation it provides predictable results that may be desired, e.g. for tracking some device migration between different networks.
Dmitry Cherkasov
2011/11/29 Brzozowski, John <John_Brzozowski@cable.comcast.com>:
Dmitry,
You could consider the use of prefixes longer than the /64 on CMTS interfaces, however, it is not clear to me why this would be done. Further, most DHCPv6 implementations do not require that the generated IPv6 address be eui-64 based. A randomized algorithm could also be used. Another consideration is what happens after IPv6 is used for addressing cable modems. What happens when you want to address CPE or CPE routers? You are right back to /64 or shorter depending on the type of device being provisioned.
FWIW - we have found that there are distinct benefits to using IPv6 beyond the amount of addresses that are available. The use of /64 is tightly coupled with these benefits.
Can you elaborate as to why one would want to or need to use prefixes longer than /64?
John
On 11/28/11 6:37 AM, "Dmitry Cherkasov" <doctorchd@gmail.com> wrote:
Hello everybody,
It is commonly agreed that /64 is maximal length for LANs because if we use longer prefix we introduce conflict with stateless address autoconfiguration (SLAAC) based on EUI-64 spec. But SLAAC is not used in DOCSIS networks. So there seems to be no objections to use smaller networks per cable interfaces of CMTS. I was not able to find any recommendations anywhere including Cable Labs specs for using prefixes not greater then /64 in DOCSIS networks. Some tech from ISP assumed that DHCPv6 server may generate interface ID part of IPv6 address similarly to EUI-64 so MAC address of the device can easily be obtained from its IPv6 address, but this does not seem like convincing argument. What do you think?
Dmitry Cherkasov
* Dmitry Cherkasov:
It is commonly agreed that /64 is maximal length for LANs because if we use longer prefix we introduce conflict with stateless address autoconfiguration (SLAAC) based on EUI-64 spec. But SLAAC is not used in DOCSIS networks. So there seems to be no objections to use smaller networks per cable interfaces of CMTS.
As far as I understan the IPv6 address architecture, if the network prefix is longer than /64, you're not running Unicast IPv6. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
participants (24)
-
Bill Stewart -
Brian Johnson -
Brzozowski, John -
Chuck Anderson -
Dmitry Cherkasov -
Doug Barton -
Florian Weimer -
Fred Baker -
Jamie Bowden -
Jeff Wheeler -
Jimmy Hess -
Joel jaeggli -
Jonathan Lassoff -
Leo Bicknell -
Mark Blackman -
Mark Tinka -
McCall, Gabriel -
Nathan Eisenberg -
Owen DeLong -
Ray Soucy -
Steven Bellovin -
Tore Anderson -
Valdis.Kletnieks＠vt.edu -
Victor Kuarsingh