Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05

Thomas et al:

Let me relay and comment on something Tony, Marla, and I discussed (Jason, I would mention you, but you and I didn't actually talk about this :-).

One of the important points of RFC 3177 is in the opening statements:

   The technical principles that apply to address allocation seek to
   balance healthy conservation practices and wisdom with a certain ease
   of access...

   The IETF makes no comment on business issues or relationships.
   However, in general, we observe that technical delegation policy can
   have strong business impacts.  A strong requirement of the address
   delegation plan is that it not be predicated on or unduly bias
   business relationships or models.

This mirrors comments made in CIDR documents and in the CIDR discussion to the effect that "gee, it would be Really Nice if we could aggregate announcements", and which came out in code words to the RIRs and ISPs saying "gee whiz, guys, would you consider being conservative in your allocations and your aggregation policy wink wink nudge nudge", recognizing their already-ongoing efforts in those directions and expressing approval of them.

These statements appear to be absent from draft-narten-ipv6-3177bis-48boundary.

Tony/Marla/Jason have a draft before the house, draft-azinger-cidrv6. It's fundamental point is "gee, it would be Really Nice if we could aggregate announcements", and suggests that provider-allocated address space is a good thing. It responds to RIR behaviors in allocation of PI address space, and asks that the RIRs tighten up the rules. Tony's observation is that the IETF has made no such statement to the RIRs regarding that, and such a statement might have value.

If we're going to replace a document entitled "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", it might be worthwhile actually updating the recommendations made on allocations to sites, and make a clear statement to the effect that "we make no pretense of telling RIRs or their members how to run their businesses, but we would humbly request that they consider the amount of money they spend on new routers and new memory every year, the amount of money spent on heat and heat dissipation, and seriously consider allocating address space in a way that promotes prefix aggregation in BGP routing." I could imagine, and would welcome, a response from the RIRs of the form "we would really appreciate consideration of an architecture that would address both ISP concerns about the size of the route table and edge network concerns about multihoming complexity and independence from their ISP".

Thought for the day...
Fred

On Aug 20, 2010, at 11:47 AM, Tony Li wrote:
> Hi all,
> 
> 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.
> 
> Regards,
> Tony Li, Ph.D.
> Cisco Fellow
> Cisco Systems, Inc.
> 
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area