Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
* 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 Weimerfwei...@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
Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
On Tue, Nov 29, 2011 at 1:43 AM, valdis.kletni...@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 j...@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 j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts
Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
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 o...@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
Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
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_brzozow...@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 doctor...@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
Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
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 s...@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
Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
* 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
Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
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 j...@thejof.com: On Mon, Nov 28, 2011 at 10:43 PM, valdis.kletni...@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
Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
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.ander...@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
Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
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 doctor...@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.ander...@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
DNS 8.8.8.8 was down
Google DNS was down few minutes, at least for few European locations Here is sample traceroute: 4 213.242.116.25 (213.242.116.25) 39.692 ms 39.776 ms 39.774 ms 5 ae-7-7.ebr1.Paris1.Level3.net (4.69.143.238) 50.933 ms 50.792 ms 50.793 ms 6 ae-47-47.ebr1.London1.Level3.net (4.69.143.109) 57.353 ms ae-45-45.ebr1.London1.Level3.net (4.69.143.101) 57.580 ms ae-48-48.ebr1.London1.Level3.net (4.69.143.113) 57.582 ms 7 ae-57-112.csw1.London1.Level3.net (4.69.153.118) 57.577 ms ae-58-113.csw1.London1.Level3.net (4.69.153.122) 57.693 ms ae-57-112.csw1.London1.Level3.net (4.69.153.118) 57.817 ms 8 ae-1-51.edge3.London1.Level3.net (4.69.139.73) 57.654 ms 57.631 ms 57.768 ms 9 unknown.Level3.net (212.113.15.186) 57.958 ms 57.531 ms 57.643 ms 10 209.85.255.78 (209.85.255.78) 57.732 ms 57.598 ms 57.573 ms 11 209.85.253.92 (209.85.253.92) 58.300 ms 209.85.253.196 (209.85.253.196) 57.941 ms 209.85.253.94 (209.85.253.94) 58.002 ms 12 72.14.232.134 (72.14.232.134) 63.726 ms 66.249.95.173 (66.249.95.173) 63.614 ms 72.14.232.134 (72.14.232.134) 63.699 ms After this hop it was dead, now it is working, but seems still there is minor problems 14 216.239.46.117 (216.239.46.117) 64.171 ms * * 15 google-public-dns-a.google.com (8.8.8.8) 63.749 ms 63.729 ms 63.680 ms --- System administrator Denys Fedoryshchenko Virtual ISP S.A.L.
RE: DNS 8.8.8.8 was down
We also observed this issue... # traceroute 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 40 byte packets 1 r1.ldn.uk.sharedband.net (109.68.192.1) 0.480 ms 0.515 ms 0.523 ms 2 195.66.224.125 (195.66.224.125) 0.451 ms 0.453 ms 0.445 ms 3 64.233.175.27 (64.233.175.27) 0.708 ms 0.702 ms 64.233.175.25 (64.233.175.25) 0.387 ms 4 209.85.253.92 (209.85.253.92) 13.737 ms 209.85.253.90 (209.85.253.90) 1.434 ms 209.85.253.196 (209.85.253.196) 1.010 ms 5 72.14.232.134 (72.14.232.134) 6.553 ms 66.249.95.173 (66.249.95.173) 6.549ms 72.14.232.134 (72.14.232.134) 6.404 ms 6 * * * 7 * * * 8 * * * Looks like it was Google (72.14.232.134) Gary Steers Sharedband NOC/3rd Line Support -Original Message- From: Denys Fedoryshchenko [mailto:de...@visp.net.lb] Sent: 29 November 2011 13:06 To: NANOG Subject: DNS 8.8.8.8 was down Google DNS was down few minutes, at least for few European locations Here is sample traceroute: 4 213.242.116.25 (213.242.116.25) 39.692 ms 39.776 ms 39.774 ms 5 ae-7-7.ebr1.Paris1.Level3.net (4.69.143.238) 50.933 ms 50.792 ms 50.793 ms 6 ae-47-47.ebr1.London1.Level3.net (4.69.143.109) 57.353 ms ae-45-45.ebr1.London1.Level3.net (4.69.143.101) 57.580 ms ae-48-48.ebr1.London1.Level3.net (4.69.143.113) 57.582 ms 7 ae-57-112.csw1.London1.Level3.net (4.69.153.118) 57.577 ms ae-58-113.csw1.London1.Level3.net (4.69.153.122) 57.693 ms ae-57-112.csw1.London1.Level3.net (4.69.153.118) 57.817 ms 8 ae-1-51.edge3.London1.Level3.net (4.69.139.73) 57.654 ms 57.631 ms 57.768 ms 9 unknown.Level3.net (212.113.15.186) 57.958 ms 57.531 ms 57.643 ms 10 209.85.255.78 (209.85.255.78) 57.732 ms 57.598 ms 57.573 ms 11 209.85.253.92 (209.85.253.92) 58.300 ms 209.85.253.196 (209.85.253.196) 57.941 ms 209.85.253.94 (209.85.253.94) 58.002 ms 12 72.14.232.134 (72.14.232.134) 63.726 ms 66.249.95.173 (66.249.95.173) 63.614 ms 72.14.232.134 (72.14.232.134) 63.699 ms After this hop it was dead, now it is working, but seems still there is minor problems 14 216.239.46.117 (216.239.46.117) 64.171 ms * * 15 google-public-dns-a.google.com (8.8.8.8) 63.749 ms 63.729 ms 63.680 ms --- System administrator Denys Fedoryshchenko Virtual ISP S.A.L.
Re: DNS 8.8.8.8 was down
On Tue, 29 Nov 2011 15:06:15 +0200, Denys Fedoryshchenko de...@visp.net.lb wrote: Google DNS was down few minutes, at least for few European locations Here is sample traceroute: 4 213.242.116.25 (213.242.116.25) 39.692 ms 39.776 ms 39.774 ms 5 ae-7-7.ebr1.Paris1.Level3.net (4.69.143.238) 50.933 ms 50.792 ms 50.793 ms 6 ae-47-47.ebr1.London1.Level3.net (4.69.143.109) 57.353 ms ae-45-45.ebr1.London1.Level3.net (4.69.143.101) 57.580 ms ae-48-48.ebr1.London1.Level3.net (4.69.143.113) 57.582 ms 7 ae-57-112.csw1.London1.Level3.net (4.69.153.118) 57.577 ms ae-58-113.csw1.London1.Level3.net (4.69.153.122) 57.693 ms ae-57-112.csw1.London1.Level3.net (4.69.153.118) 57.817 ms 8 ae-1-51.edge3.London1.Level3.net (4.69.139.73) 57.654 ms 57.631 ms 57.768 ms 9 unknown.Level3.net (212.113.15.186) 57.958 ms 57.531 ms 57.643 ms 10 209.85.255.78 (209.85.255.78) 57.732 ms 57.598 ms 57.573 ms 11 209.85.253.92 (209.85.253.92) 58.300 ms 209.85.253.196 (209.85.253.196) 57.941 ms 209.85.253.94 (209.85.253.94) 58.002 ms 12 72.14.232.134 (72.14.232.134) 63.726 ms 66.249.95.173 (66.249.95.173) 63.614 ms 72.14.232.134 (72.14.232.134) 63.699 ms After this hop it was dead, now it is working, but seems still there is minor problems 14 216.239.46.117 (216.239.46.117) 64.171 ms * * 15 google-public-dns-a.google.com (8.8.8.8) 63.749 ms 63.729 ms 63.680 ms Some people saw it from .za as well, although apparently 8.8.4.4 is unaffected.
Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
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 doctor...@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 doctor...@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.ander...@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
Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
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.kuarsi...@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 doctor...@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 doctor...@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.ander...@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
Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
On Tue, 29 Nov 2011 03:23:04 EST, Jeff Wheeler said: On Tue, Nov 29, 2011 at 1:43 AM, valdis.kletni...@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.) pgpXw7IZkX7Uu.pgp Description: PGP signature
Computer Networks Special Issue on Botnets: Deadline Extended to Dec. 19
CFP: Special Issue of COMPUTER NETWORS (ELSEVIER) on Botnet Activity: Analysis, Detection and Shutdown Apologies for multiple copies of this announcement. - Dear Colleagues, Please consider the following opportunity to submit and publish original scientific results to a SPECIAL ISSUE of COMPUTER NETWORKS (ELSEVIER journal) on Botnet Activity: Analysis, Detection and Shutdown. The submission deadline is extended to December 19, 2011. http://ees.elsevier.com/comnet/ A pdf version of this CFP is available at http://faculty.cse.tamu.edu/guofei/CFP_COMNET-Botnets.pdf Please help distribute. Thanks! - Large scale attacks and criminal activities experienced in recent years have exposed the Internet to serious security breaches, and alarmed the world regarding cyber crime. In the center of this problem are the so called botnets -- collections of infected zombie machines (bots) controlled by the botmaster to perpetrate malicious activities and massive attacks. Some recent botnets are composed of millions of infected machines, making use of this attack vector inevitably harmfully. Hence, it is paramount to detect, analyze and shutdown such overlay networks before they become active. Research on botnet activity is mostly related to detection and disruption. Detection of botnets has focused on monitoring bot activities, especially during the spread of malicious software to infect new hosts (initial infection phase) and the communication messages exchanged between bots and botmasters (rallying and updating phases). Some behavioral aspects are common: bots have to signal the botmaster informing they are alive, each time their hosts are started; bots send messages whenever connecting and joining with the botnet; the botmaster has to send commands to each zombie machine before initiating malicious activities. This special issue of Computer Networks is intended to foster the dissemination of high quality research in all aspects regarding botnet activity, detection and countermeasures. The objective of this special issue is to publish papers presenting detection algorithms, traffic monitoring and identification, protocols and architectures, as well as botnet modeling, behavior, simulation, statistics, dissemination, analysis, preventive procedures and possible countermeasures. Only technical papers describing previously unpublished, original, state-of-the-art research, and not currently under review by a conference or journal will be considered. We solicit papers in a variety of topics related to botnet research including, but not limited to: - Traffic Monitoring and Detection Algorithms - Data Collection, Statistics and Analysis - Modeling Behavior and Simulation - Protocols and Architectures (IRC, HTTP, P2P, etc) - Firewalls and IDS - Cyber Crime Case Studies - Reverse Engineering and Automated Analysis of Bots - Honeypots and Honeynets - New Platforms: Cellular and Wireless networks, Mobile devices, TV, etc. - Legal Issues and Countermeasures - Underground Markets, Vulnerability Markets and Zero-day Economics - Mini-Botnets Guest Editors Ronaldo Salles Military Institute of Engineering PraçGeneral Tibú 80, 22290-270, R.J.  Brazil sal...@ieee.org Guofei Gu Texas AM University 3112 TAMU, HRBB College Station, TX 77843-3112  USA guo...@cse.tamu.edu Thorsten Holz Ruhr-University Bochum Universitatsstrasse 150, 44780 Bochum  Germany thorsten.h...@rub.de Morton Swimmer Trend Micro Deutschland, GmbH Zeppelinstr. 1 85399 Hallbergmoos - Germany swim...@acm.org Paper submission: 19th Dec 2011 Acceptance notification: 19th Mar 2012 Final papers: 19th May 2012 Submission format The submitted papers must be clearly written in excellent English and describe original research which is not published nor currently under review by other journals or conferences. Author guidelines for preparation of manuscript can be found at www.elsevier.com/locate/comnet/ Submission Guideline All manuscripts and any supplementary material should be submitted through the Elsevier Editorial System (EES). The authors must select Special Issue: Botnets when they reach the ÂArticle Type step in the submission process. The EES website is located at: http://ees.elsevier.com/comnet/ Guide for Authors This site will guide you stepwise through the creation and uploading of you article. The guide for Authors can be found on the journal homepage (www.elsevier.com/comnet/).
Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
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 s...@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/
Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
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 - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpjWZASC9D1s.pgp Description: PGP signature
Equinix
Assuming it's not owned by the NSA does anyone know the address of the equnix colo in the Denver area? I'm working on pricing access circuits into it. A contact from equinix would be helpful as well. We haven't gotten a response to our queries. Regards, Keegan
Re: Equinix
They have been real slow to respond to me in the past 14 days. They say it's a 24 hour turn around after calling their marketing line, I'm still waiting a call back and I've left 3 messages. I guess they don't want to lease a cab in TX… On Nov 29, 2011, at 9:47 AM, Keegan Holley wrote: Assuming it's not owned by the NSA does anyone know the address of the equnix colo in the Denver area? I'm working on pricing access circuits into it. A contact from equinix would be helpful as well. We haven't gotten a response to our queries. Regards, Keegan
RE: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
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:f...@cisco.com] ... I see no reason you couldn't use a /127 prefix if the link was point to point. ...
RE: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
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
Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
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 RE 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 bickn...@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 - bickn...@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/
Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
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.mcc...@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:f...@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/
Re: Equinix
Is Equinix Denver the old Switch and Data site at 9706 East Easter Avenue, Suite 160, Englewood, Colorado, 80112? Edward Dore Freethought Internet - Original Message - From: Keegan Holley keegan.hol...@sungard.com To: NANOG nanog@nanog.org Sent: Tuesday, 29 November, 2011 4:47:37 PM Subject: Equinix Assuming it's not owned by the NSA does anyone know the address of the equnix colo in the Denver area? I'm working on pricing access circuits into it. A contact from equinix would be helpful as well. We haven't gotten a response to our queries. Regards, Keegan
Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
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 doctor...@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.ander...@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
Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
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:f...@cisco.com] ... I see no reason you couldn't use a /127 prefix if the link was point to point. ...
Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
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 o...@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 doctor...@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.ander...@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/
Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
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:f...@cisco.com] ... I see no reason you couldn't use a /127 prefix if the link was point to point. ...
ATT GigE issue on 11/19 in Kansas City
We lost several of our GigE links to ATT for 6 hours on 11/19, anyone else see this and get a root cause from ATT? All I can get is that they believe a change caused the issue.
Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
On Nov 28, 2011, at 9:15 PM, Jeff Wheeler wrote:
On Mon, Nov 28, 2011 at 4:51 PM, Owen DeLong o...@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
Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
On Tue, Nov 29, 2011 at 12:42 AM, Owen DeLong o...@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
Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
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
Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
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:f...@cisco.com] ... I see no reason you couldn't use a /127 prefix if the link was point to point. ...
Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
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:: ::::0003::: Or, if you prefer: Router A: 2001:db8::1 Router B: 2001:db8::2 permit ipv6 any 2001:db8::3 :::::::0003 Owen On Tue, Nov 29, 2011 at 12:21 PM, Owen DeLong o...@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 doctor...@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.ander...@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/
Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
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 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:f...@cisco.com] ... I see no reason you couldn't use a /127 prefix if the link was point to point. ...
Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
On Tue, Nov 29, 2011 at 10:31 PM, Owen DeLong o...@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
Re: Bandwidth prediction tool?
Does anyone know a good Bandwidth Prediction tool?. yes. times 1.5-2.0 every year
