[ppml] for your reading pleasure

[Thomas Narten]

Marshall Eubanks <tme at multicasttech.com> writes:

> I must admit that I do not see much in the way of recommendations in
> this document, nor do I see a strong need for it.

One need is to make clear that 3177 has been superceded, and that folk
should stop pointing to it for justification of things. Note that in
the past, at some RIR meetings, people have made reference to 3177 and
wondered if it was appropriate to change the /48 policy given the
existance of 3177. Also, it's useful to the IETF community to have it
go through the formal steps of recognizing that 3177 needs to be
updated/replaced.

So, I agree, maybe not hugely important, but I view this is part of
closing the loop and recognizing where we are today. 

> It says that

>     This document revisits and updates the IAB/IESG recommendations on
>     the assignment of IPv6 address space to end sites.

> but it would be more appropriate to say that it voids them. It does
> imply that smaller address blocks could be handed out - see this
> from the Introduction

>       1) It revisits the RFC 3177 recommendations and concludes that the
>          default IPv6 assignment size could be changed from /48 to some
>          other value (e.g., /56) with essentially no impact on existing
>          IPv6 standards or implementations.

> and this from Section 2

>     The above concerns were met by the original /48 recommendation, but
>     could also be realized through a more conservative approach. A key
>     goal, however, is to avoid the need for a site to renumber into a
>     smaller number of subnet bits when adding a new prefix.

Right.

> but of course the same wording could be used to justify
> automatically handing out larger blocks are well. Particularly, it
> provides no reason why /56's (or / 32's, or /64's, or any other size
> block) should be handed out in preference to any other size.

I'll have to think about this a bit and see if some text should be
added. There are lots of things this document doesn't rule out, by
virtue of not saying something explicit. :-)

But it probably is useful to say something more specific on your point.

> No doubt that there is no _technical_ reason why address blocks need
> to be any particular size (after all, IPv4 CIDR works), but just
> stating that, while useful, is not actually a recommendation do to
> anything in particular.

To be clear, this document is not intended to make a recommendation on
what the RIRs should do. But it does want to make clear that
updating/changing the current /48 recommendation is reasonable, from
an architectural/standards perspective.

> I am surprised that the draft does not even promote aggregation in  
> assignment policies.
> Note this at the end of Section 2, where it says

>     A key goal, however, is to avoid the need for a site to renumber
> into a smaller number of subnet bits when adding a new prefix.

> As I read it, this implies that RIR's should (or, at least, could)
> hand out non-contiguous blocks when end sites need more address
> space. It seems to approve of this, as long as the new block is the
> same size or larger than the existing ones.

Not clear this document should say anything here (though of course we
support better aggregation). But in the specific case of end sites,
it's not immediately clear they need to aggregate the same way as we
want ISP customers (as a whole) to be aggregated. For example, giving
an end site 3 different (non-aggregatable) prefixes that the ISP flat
routes internally, but that are still covered by an ISP's overall
aggregate would seem like a fine think to do. Or in any case, I don't
think this should be ruled out.

> I think that the minimum any IPv6 assignment policy should do is to  
> promote the maximum amount of aggregation possible, and that any  
> recommendation coming out of the IETF / IESG / IAB should clearly  
> state that as a goal.

I don't disagree with the point, but that isn't really in scope with
what I had in mind when writing the document.

Thomas