Mark Smith wrote: > > > ----- Original Message ----- >> From: Brian E Carpenter <brian.e.carpen...@gmail.com> >> To: manning bill <bmann...@isi.edu> >> Cc: ipv6@ietf.org; "v6...@ietf.org WG" <v6...@ietf.org> >> Sent: Tuesday, 4 June 2013 6:27 AM >> Subject: Re: [v6ops] Could IPv6 address be more than > locator?//draft-jiang-v6ops-semantic-prefix-03 >> On 04/06/2013 03:44, manning bill wrote: >>> On 2June2013Sunday, at 16:47, Sander Steffann wrote: >>> >>>> On 03/06/2013 11:06, manning bill wrote: >>>>> /48's are a horrible policy - one should only advertise what >> one is actually using. >>>> Now *that* would cause a nice fragmented DFZ... >>>> Sander >>>> >>> I'm going to inject a route. One route. why do you care if its a /9, >> a /28, a /47, or a /121? >> >> I've heard tell that there are routers that are designed to handle >> prefixes up to /64 efficiently but have a much harder time with >> prefixes longer than that, as a reasonable engineering trade-off. >> Not being a router designer, I don't know how true this is. >> > > "right-sizing" prefixes to the number of hosts being used also has a cost, > which is the constant cost of on-going adjustment of prefix size, including > complete renumbering of the subnet if the specific prefix cannot be expanded > further, and far more complex address space management. This is a cost was > initially hidden in IPv4 by the fact that it became essential in IPv4 due to > the size of IPv4's address space. RFC1918 and NAT subsequently predominantly > eliminated it, by providing plenty of address space, and preventing that > address space from being reachable from the Internet, the likely source of > attacks on it. > > The issue with IPv6's large prefixes isn't really the specific size of the > prefix, it is the exploitable state that is created during neighbor presence > discovery. If the exploitability of this state is reduced, or better yet > eliminated, via a host/address registration protocol, the amount of dark > space announced doesn't matter. > > Regards, > Mark.
I take this conclusion about ND being the only problem with a large operational dose of salt. AFAIK The only exploit we've seen up until now is neighbor presence discovery. So yes it's important to mitigate that, and I agree address registration is one potential solution. But 2^64 is a very large number. Anything that stores any sort of state about an IPv6 address/IID for any significant amount of time is a potential DOS target. Whether that be ND, a firewall forwarding table, a DNSBL, an IDP probe, a DHCPv6 server lease cache, a network management station status log, or a WFQ or netflow table in a router. No, I haven't seen anything like this yet in the wild, but to my mind good engineering would suggest that you size resources in a balanced way to match both upside (management convenience and difficulty to brute-force scan the address space) and downside (potential resource depletion). IMHO systems that service more than one segment should also take measures to ensure that depletion of any resources allocated to servicing a single /64 segment does not result in resource depletion for an entire site or enterprise. I don't want to lose my DHCPv6 enterprise server or forensic logging because an attacker has conquered one LAN and is sending lots of requests from 2^64 "unique" systems. Simple, appropriately sized, static, ingress filters have saved my bacon on more than one occasion. regards RayH > >> Brian >> >> Its -one- route. >>> That one route covers everything I'm going to use… and nothing I'm >> not. >>> Is there a credible reason you want to be the vector of DDoS attacks, by >> announcing dark space (by proxy aggregation)? >>> Is that an operational liability you are willing to assume, just so you >>> can >> have "unfragmented" DFZ space? >>> /bill >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
