Re: [GLOBAL-V6] Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt

Thomas Narten <narten@us.ibm.com> Sat, 16 July 2005 12:20 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtlen-0001oX-Cg; Sat, 16 Jul 2005 08:20:37 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtlel-0001oS-86 for ipv6@megatron.ietf.org; Sat, 16 Jul 2005 08:20:35 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11497 for <ipv6@ietf.org>; Sat, 16 Jul 2005 08:20:31 -0400 (EDT)
Received: from e6.ny.us.ibm.com ([32.97.182.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dtm7k-00050n-5r for ipv6@ietf.org; Sat, 16 Jul 2005 08:50:32 -0400
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j6GCKJ9R015874 for <ipv6@ietf.org>; Sat, 16 Jul 2005 08:20:19 -0400
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j6GCKJSw239366 for <ipv6@ietf.org>; Sat, 16 Jul 2005 08:20:19 -0400
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j6GCKJKU021810 for <ipv6@ietf.org>; Sat, 16 Jul 2005 08:20:19 -0400
Received: from cichlid.raleigh.ibm.com (sig-9-65-241-250.mts.ibm.com [9.65.241.250]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j6GCKHAV021736; Sat, 16 Jul 2005 08:20:18 -0400
Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j6GCKFXD004875; Sat, 16 Jul 2005 14:20:16 +0200
Message-Id: <200507161220.j6GCKFXD004875@cichlid.raleigh.ibm.com>
To: Kosuke Ito <kosuke@bugest.net>
In-Reply-To: Message from Kosuke Ito <kosuke@bugest.net> of "Thu, 14 Jul 2005 23:43:53 +0900." <42D67A29.9030100@bugest.net>
Date: Sat, 16 Jul 2005 14:20:15 +0200
From: Thomas Narten <narten@us.ibm.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c
Cc: "ipv6@ietf.org" <ipv6@ietf.org>, global-v6@lists.apnic.net
Subject: Re: [GLOBAL-V6] Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

Ito-san,

You raise some good questions.

> I have been observing the current discussion on "reviewing
> the current policies and address allocation practices".
> Then, I felt that we should resort what a real issue is.
> Why do we need to change HD-Ratio?

To ensure that we really have plenty of IPv6 addresses to last us 100+
years.  Consider IPv4. Have we already run out? Some say effectively
yes, because now that we see that we will run out, addressing policy
has changed (to increase conservation) and it has become harder to get
them. Hence, we've been forced to change our behavior in response to a
decrease in the supply. I think we'd all agree that it is harder to
get IPv4 address space today than we ever want it to be for IPv6.

If we actually end up using up a significant fraction of the IPv6
address space in the next 50 years (even if there is then still plenty
left), we may find ourselves forced to change our consumption behavior
in anticipation of possibly running out. In order for there really to
be "plenty of addresses", we really want there to never be any serious
concern that we will run out.

draft-narten-iana-rir-ipv6-considerations-00.txt tries to lay out the
rational for changing the policies to be more conservative. See also

http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-wed-ipv6-roundtable-report.pdf

> Why do we need to change an assignment size?

So that we don't ever finding ourselves in the postion of saying
"things sure would be better now had we only been a bit more
conservative from the start". It's easy to make policies more liberal
later (if necessary/desireable). It will be much more difficult to go
from a more liberal policy to an more conservative one later (look at
the IPv4 situation today).

> If we change it/them, what do we have in return?

Increased confidence that there will be plenty of IPv6 addresses for
at least a hundred years.

> Just reducing the pace of address consumption?

Yes, but I would phrase it differently. I'd argue it's more the case
to say "reduce the pace of address wastage". I don't think anyone
wants to prevent people from getting address space that they will
actually use. But as it stands now, we are handing out a lot of
address space that even ISPs who are getting that much are suggesting
is way more than they really need.

> Do we like to creat SWAMP already?

The swamp is more about long prefixes that don't aggregate, leading to
many prefixes in the routing table. Changing the amount of space we
allocate to end sites doesn't change this.

> Let me looking back the original intention of implementing
> HD-Ratio. HD-Ratio was introduced to give ISPs an eligibility
> to request subsequent allocation automatically in order
> to achieve one of the goals raised in the policy, such as
> "reducing overhead".

> But in some point, RIRs start applying HD-Ratio to decide
> the "Initial" allocation size based on ISP's existing _IPv4_
> customer size, and RIRs and community change the policy
> itself to fit its practice. After that, initial allocation
> size gets larger like /21 or /20 than ever before. I believe
> that there is a twist here. I do not deny the current
> practice done by RIRs, if RIRs believe that this practice
> is totally in-line of the global address management to keep
> in good order.
> But reviewing this practice could be less impact than
> considering to change the policy so as to achieve the
> slowing down the pace of allocation (if it is the goal
> of this discussion).

An interesting point. The large allocations we are seeing now do stem
from ISPs using their existing IPv4 infrastructure and applying the HD
ratio to that. I think that is consistent though with the original
policy. I.e., it said:

     4.4.  Consideration of IPv4 Infrastructure
	
	Where an existing IPv4 service provider requests IPv6 space
	for eventual transition of existing services to IPv6, the
	number of present IPv4 customers may be used to justify a
	larger request than would be justified if based solely on the
	IPv6 infrastructure.

> Regarding the assignment size, when we held JP Open Policy
> Meeting last week, there are many voices saying that
> varying assignment size is too much impact on the current
> commercial service not in its network operation but also
> for the low-cost routing devices handling /48.

Can someone explain why this is? What is the issue?

> According to them, they have already been in service,
> so they consider that it is not practical to change the
> assignment policy. But at the same time, ISPs need to make
> their best effort to achieve the goal of "conservation" still
> existing in the policy even it is not the first priority.
> Is it practical to change in other regions?

Personally, I think we probably don't need to do anything about the
existing allocations. So this would be for future allocations.  (Then
again, if DHCP and prefix delegation is being used, how hard would
this be to change for existing home users?)

Are there implementations or deployment scenarios that _assume_ that
they will get a /48? If so, in what ways are they using the 16 subnet
bits? 

> I believe that we can avoid any change in the policy
> if we look back the goals and refrain from asking as
> large allocation size and large assignment size as
> possible just because they can.

To stop the large allocations, changing the HD ratio metric will save
only about 3 bits. That is, it will give save us about an order of
magnitude more space. But changing the /48 default to /56 produces two
orders of magnitude more in savings. Cutting the projected consumption
by three orders of magnitude is a huge amount of savings. One order is
quite a bit less.

> Nevertheless, if we keep the current pace of allocation, one
> extrapolation study said that IPv6 might be allocated 50% in 60
> years in the worst(?) case.  Seems to me, lasting 120 years of IPv6
> is long enough, isn't it??

The main issue is that there is inherent uncertainty in
projections. We really don't know how many devices will be connected
to the network in 50 years. Our projections are at best estimates and
may be closer to guesses. Given that the most important problem IPv6
is supposed to solve is the shortage of addresses, we really don't
want to get this part wrong.

Thomas

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------