Re: draft-narten-ipv6-3177bis-48boundary-02.txt

[Thomas Narten <narten@us.ibm.com>]

Hi Jordi.

> Hi all,

> I've reviewed this document and my comments are as follows.

> 1. Introduction
> "giving out an excessive". I think we need to define excessive
> and/or say if this is an objective or subjective perception.

I have two repsonses to this.

First. giving out a /48 to every home network (which today has at most
a handful of machines, which means, one subnet would suffice) is
widely viewed as excessive. Even a /56 to such end sites seems more
than enough space to meet needs for at least the next decade (and most
people seem to be comfortable with that, even if it is a lot of
space). You've been to RIR meetings. Surely you have noticed this
sentiment both in the hallway and in comments made (regularly) at the
microphone.

But more to the point, the current text in the document actually says:

   There are a number of considerations that factor into address
   assignment policies. For example, to provide for the long-term health
   and scalability of the public routing infrastructure, it is important
   that addresses aggregate well. Likewise, giving out an excessive
   amount of address space could result in premature depletion.

How can you possibly object to the use of the word excessive in the
above context?    

> A general comment/opinion. I don't think this document should be
> published as is, because it provides a bad message to the market
> about IPv6 assignment recommendations not being stable. I will be in
> favor of a "smaller" revision of RFC3177, not so much disruptive as
> this one, but in the other way around, discouraging /128 and /64
> assignments.

As you know, policy proposals to move away from /48 are currently
being discussed in the indvidual RIR regions. Indeed, ARIN has already
adopted one
(http://www.arin.net/policy/proposals/2005_8.html). Publishing this
document will not stop the registries from moving away from
/48. Indeed, a primary goal is to make it clear that making such a
decision is for the RIRs to make (i.e., to acknowledge reality), and
that from an IPv6 architectural perspective, this is fine.

So, to be clear, do you disagree with the statement that moving from
/48 to /56 is fine from an architectural perspective? If not, please
be specific.

I do agree there are operational issues with having varying prefix
sizes. But that is something that the RIRs need to take into
consideration as they discuss policy proposals. Indeed, this document
tries to make clear that taking into consideration such operational
considerations should be done.

> I think the motivations behind the /48 are still valid and one of
> the main goals of IPv6 addressing space is to ensure enough space to
> end-users, which is only ensured with a clear boundary
> recommendation.

It is widely viewed that a /56 to everyone would achieve this
adequately, whereas a /48 is "execessive" to achieve this goal.

> Furthermore, the lack of a clear boundary disrupts the RFC3177 goal of
> ensuring a consistent subnet to facilitate management and renumbering. In
> practice receiving a new assignment from and ISP w/o a specific
> recommendation will be a big source of troubles if different ISPs decide to
> do different things. Take the case of a user moving from an existing ISP
> with today provides a /48 to a new one.

The document says this. But in any case, this argument needs to be
taken directly to the RIRs.

> In addition, as an end user, it provides a recommendation to ISPs to
> provide a reduced service in terms of the number of subnets, instead
> of the actual /48 recommendations (with a clear example for /56),
> which I think is very bad, especially when it is based in a
> subjective view of "excessive".

> I also think that the lack of clarity in stating that more than a
> single /64 is required in most of the cases is going to be wrongly
> taken as a "go for /64".

I see no evidence that RIR policies are going in that direction. My
sense (this is based on following and participating in RIR discussions
for the last few years) is that those communities understand very well
that a /64 as default end site allocation unit is neither desirable
nor necessary and that there is plenty of address space to make the
default allocations much larger. But they (even from day one) have
largely viewed a /48 as excessively large.

Thomas