On Tue, Feb 26, 2013 at 11:22 AM, james woodyatt <[email protected]> wrote:
> p1. I don't believe it's reasonable to assume that service providers will > always provide a short enough prefix to number all the links in a > subscriber's network, or that those that currently do will continue to do > so into the foreseeable future, or that they will even give notice prior to > reducing the space delegated to a subscriber. > Ok, but in that case the only options available to us are a) give up, or b) make routing work with smaller-than-/64 prefixes. I believe our current plan is to give up and tell the ISPs that if they want to run a routed home, then they need to assign it more than a /64. The alternative is basically a vicious circle: if ISPs ignore the IETF's advice and assign a /64 because they see additional address space as an upsell opportunity, then someone will figure out how to share the /64 by using ugly hacks like routing /128s assigned from DHCPv6. Goodbye privacy addresses, goodbye robust routing, but still, things will work most of the time. If the ISPs start to assign smaller than /64, things still work until they assign fewer /128s than the number of devices you have. At that point, someone will implement NAPTv6 and we're back where we started in IPv4. > p2. In a decent sized subscriber network, with several subnets in place, a > /56 delegation means a small but significant changes that a randomly > selected subnet identifier will collide with an existing one, whenever a > router joins the network. With a /60, the odds climb quite a bit, and in > some networks it will be 15/16. (Do not make the mistake of assuming that > router joins and leaves will be infrequent events. Plan for them happening > several times per second, or you will be sorry later.) > Ok, but isn't that why the prefix autoconfiguration drafts assume that collisions are a regular part of prefix assignment? Are there issues with those drafts? Will their approach not work? > p3. All this pain can be traded away for the reasonably well-understood > pain of NAT66 and a single ULA prefix with a constant 16-bit subnet > identifier space, where collisions will be rare and stateless prefix > autoconfiguration will settle quickly basically every time. > How is using a single ULA better for this? Perhaps you don't have to deal with changes in flight (well, assuming that a backup router becomes available to act as ULA anchor when the designated ULA anchor is unplugged/crashes), so maybe that's a simplification. However, the moment you try to use more /64s internally than you have externally, stateless NPTv6 doesn't work any more, right? For example, suppose you use fc00::/48 in the home, and you have two links, which you number fc00:0:0:1::/64 and fc00:0:0:2::/64. You have one host on each link, and for some reason they both pick the same interface ID, so host A is fc00:0:0:1::dead:beef host B is fc00:0:0:2::dead:beef. Everything works fine so far. Now suppose that externally you have only one /64, 2001:db8::/64. I can't see how that can work: if you get a packet to 2001:db8::dead:beef, you don't know what to do with it. I think if we want to avoid the temptation of subscribers to deploy NAT66 > to preserve the stability of their 16-bit subnet identifier space in the > face of service providers "enhancing their choices" with a variety of plans > with varying policies for prefix delegation, then we have to do it with a > stateful subnet manager in the network, near the border gateways. If you don't have enough external space for all your hosts, then a stateful subnet manager isn't enough. You need a stateful host+port manager. i.e., you need an IPv4-style NAPT.
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
