[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Review of draft-narten-ipv6-3177bis-48boundary-05
This is a solicited review of draft-narten-ipv6-3177bis-48boundary-05.
History: The IAB & IESG made some recommendations for v6 addressing in RFC 3177. In particular, the recommended the assignment of /48 to a site.
This draft reconsiders that recommendation, and argues that more flexibility would be reasonable.
1) The draft retracts the recommendation that /128's can be allocated to sites. The text here is clear about sites, but could possibly call out the distinction between a site and a host. Clearly /128 allocations to a single host are a necessary alternative. Consider the case of a hot spot service provider. Allocating a /48 or even a /64 to each laptop in the coffee shop is not necessary or sane practice.
2) The draft calls out a specific motivation that sites should get enough address space so that they do not feel compelled to use NAT. While this is fine in principle, the pragmatics here are hard to defend. A site can easily make unjustified claims to arbitrary amounts of address space. It is unreasonable to expect that every RIR and LIR is going to make detailed investigations for every single address space request, so there will be established policies for address space assignment, possibly with economic disincentives for over-allocation. However, this will not prevent some end-sites wanting more, especially to avoid additional costs. Thus, some sites will still feel compelled to use NAT. We should avoid the hubris that we can dictate business practices.
3) The draft includes a discussion about the rationale of RFC 3177's argument in favor of /48 to simplify renumbering. It is certainly true that renumbering from one prefix to another is greatly simplified if the prefixes are the same size. The important point, missed in both 3177 and this draft, is that this only argues that any given site get the same sized prefix. This does not imply that it needs to be a /48 for all sites. Nor is there ANY benefit from that. For example, if a site had a /57 (bad for other reasons), then having another /57 to renumber into satisfies this requirement. /48 is not necessary, nor is any other fixed size.
4) The draft seems to shy away from making clear replacement recommendations. While it recommends that policy take certain points into consideration, this seems like mere rhetoric and lacking in any substance. I strongly recommend that the draft make real recommendations and very clearly call those out. If nothing else, the draft needs to clearly and explicitly vacate the previous /48 recommendation. This seems to be done in the Introduction, which seems somewhat odd.
5) The draft misses the opportunity to call for work in v6 renumbering. The fact of the matter is that sooner or later, sites will need to renumber. Even given adequate address space, there are other compelling events (e.g., corporate acquisitions) that drive renumbering. There's much work to do here. If we make the assumption that renumbering WILL be easy (and make it come to pass), then it's reasonable to argue that renumbering into a larger prefix is easy and thus we can be more conservative in initial site addressing.
Tony Li, Ph.D.
Cisco Systems, Inc.