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

Kosuke Ito <kosuke@bugest.net> Mon, 18 July 2005 15:36 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuXfl-0002dr-St; Mon, 18 Jul 2005 11:36:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuXOz-00077O-MZ for ipv6@megatron.ietf.org; Mon, 18 Jul 2005 11:19:31 -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 LAA20417 for <ipv6@ietf.org>; Mon, 18 Jul 2005 11:19:27 -0400 (EDT)
Received: from fj34.ade2.point.ne.jp ([61.117.244.34] helo=nereid.bugest.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuXsP-0008Np-OE for ipv6@ietf.org; Mon, 18 Jul 2005 11:49:55 -0400
Received: from bugest.net (nereid.bugest.net [172.16.0.5]) by nereid.bugest.net (Postfix) with ESMTP id D40123A218; Tue, 19 Jul 2005 00:19:23 +0900 (JST)
Message-ID: <42DBC87C.5070103@bugest.net>
Date: Tue, 19 Jul 2005 00:19:24 +0900
From: Kosuke Ito <kosuke@bugest.net>
Organization: IPv6 Promotion Council of Japan / Canon Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: ja
MIME-Version: 1.0
To: Thomas Narten <narten@us.ibm.com>
References: <200507161220.j6GCKFXD004875@cichlid.raleigh.ibm.com>
In-Reply-To: <200507161220.j6GCKFXD004875@cichlid.raleigh.ibm.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ed68cc91cc637fea89623888898579ba
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 18 Jul 2005 11:36:48 -0400
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

Hi Thomas,

Thomas Narten wrote:

> Ito-san,
> 
> You raise some good questions.

Thank you :-)

> 
>>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.

I guess, we need to levelize this degree of "concern", first.
I understand that some (I don't know there are "Many" or not) starts
worrying about it.

> 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).

But we all agreed that "the goal of conservation is the least
priority" but also all ISPs needs to keep it in their mind when
they determined the user assignment size, don't we?

We agree to go more liberal when we set the current policy.
But I still believe that starting of allocating /2x size
to requesting ISPs who has nothing but only because they
have IPv4 customer is, I think, too far liberal.
Is this the sound model that ISP never come back to RIR
for sub-allocation? Is this not against the basics of
address allocation that address provides when it is needed?

>>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.

What safety factor do we need? how do all of us think?
One study I raised said that it might be allcated upto 50%
in 60 years. Does this make us confident in lasting IPv6
for 100 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.

I agree. But what level means wastage and what level means
a room of reducing operational overhead for less operational cost
for both sides of RIR/NIR and ISP/User.
We need to discuss these points before getting into details of how.
/48? or /56? or both? or various in between?... it might be just
one of technical ways to solve the above questions.

>>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.

I just imagine that we might raise up the "initial" minimum
allocation size issue if we get this discussion far more.
But changing "initial" minimum allocation size has larger
impact which many of us like to avoid, I beieve.

> 
>>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.

Which line says the allocation size is decided automatically
based on the HD-Ratio table by applying the IPv4 customer size?

It might be OK to decide its reserving space for the sake of
globally scalable address management by RIRs internally.
But I have a question in giving it all at once to the requester.

> 
>>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 guess, in the real service, there is no reason for 16 bit subnet
necessary, but just IETF(RFC) said.
But if the larger space of freedom they have, the more of creativity
of services/usages is increased. This is just my personal feeling.

> 
>>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.

Only about 3 or 4 bits but it increases the factor of 8 or 16,
which seems me a great deal. Maybe some of us do not think so,
though.

> 
>>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.

I truely share this point with you.
I would like to see how discussion goes more.

Good night :-)
Kosuke

> Thomas
> _______________________________________________
> global-v6 mailing list
> global-v6@lists.apnic.net
> http://mailman.apnic.net/mailman/listinfo/global-v6
> 


-- 
**********IPv6 Internet Wonderland!************
Kosuke Ito, Master Planning and Steering Group
IPv6 Promotion Council of Japan
(Visiting Researcher, SFC Lab. KEIO University)
Tel:+81-3-5209-4588  Fax:+81-3-3255-9955
Cell:+81-90-4605-4581
mailto: kosuke@v6pc.jp   http://www.v6pc.jp/
Lifetime e-mail: kosuke@stanfordalumni.org


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