Subject: FWD: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt

From: Thomas Narten <[email-masked]>
Date: Wed, 13 Jul 2005 23:44:02 +0200

Here's an ID for consideration by the IPv6 WG.

Background:

Discussion on the more general topic took place at the April ARIN and
May RIPE meetings.  A good summary of those presentations can be found
at:

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

A more general discussion of the overall topic of IPv6 address
allocation considerations (the /48 boundary topic is just one piece of
a larger puzzle) can be found at:

http://www.ietf.org/internet-drafts/draft-narten-iana-rir-ipv6-considerations-00.txt

Thomas

------- Forwarded Message

From: [email-masked]
To: [email-masked]
Date: Tue, 12 Jul 2005 15:50:03 -0400
Subject: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt 
Reply-To: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: IPv6 Address Allocation to End Sites
	Author(s)	: T. Narten, et al.
	Filename	: draft-narten-ipv6-3177bis-48boundary-00.txt
	Pages		: 8
	Date		: 2005-7-12
	
   This document revisits the IAB/IESG recommendations on the assignment
   of IPv6 address space to end sites. Specifically, it indicates that
   changing the default end-site assignment for typical home and SOHO
   sites from /48 to /56 is consistent with the goals of IPv6 and RFC
   3177. Although it is for the RIR community to make adjustments to the
   IPv6 address space allocation and end site assignment policies, the
   IETF community would be comfortable with RIRs changing the default
   assignment size to /56 for smaller end sites. This document obsoletes
   RFC 3177 and reclassifies it as historic.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-48boundary-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-narten-ipv6-3177bis-48boundary-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-narten-ipv6-3177bis-48boundary-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-narten-ipv6-3177bis-48boundary-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-narten-ipv6-3177bis-48boundary-00.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--

------- End of Forwarded Message

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 14 Jul 2005 09:31:18 +0200

Hi Thomas,

I've read yesterday this document, and I'm basically ok with it, but with
two considerations that I think must be worked out it parallel somehow:
1) HD-Ratio modification, as it seems to be an integral part of the
discussion.
2) I've the feeling that if we suggest the ISPs to move to a /56, they will
then charge the customers (SOHO, end-users) or create to them a lot of
troubles to get a bigger prefix when this is needed. My feeling is that
today we believe that 8 bits for subnetting is enough, but I think will not
be the case soon and this barrier will then be again a stopper for enabling
innovation. I know this one is somehow not an IETF business, but we must be
worried about that and may be collectively work for the appropriate solution
in the appropriate fora. Otherwise, I will much prefer not to change the /48
to something smaller. Note that I don't think the RIRs are neither a good
fora for making a policy which avoids that the addresses are being charged
at all (hopefully I'm wrong !).

The cost of managing addresses is not a recurrent cost. I mean, it will be
ok to charge for a reasonable setup fee if somebody ask for a /48 instead of
a /56, but charging 12Euros (or even more) per month per address as some
telcos do in EU is a crime.

We need to make sure that anything like that happens with IPv6 ! Otherwise,
we better stop deploying IPv6 now.

Regards,
Jordi

> De: Thomas Narten <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Wed, 13 Jul 2005 23:44:02 +0200
> Para: "[email-masked]" <[email-masked]>
> Asunto: FWD: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
> 
http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-48boundary-00.tx>
t
> Content-Disposition: inline

************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Information available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 14 Jul 2005 10:52:19 +0300 (EEST)

> Here's an ID for consideration by the IPv6 WG.

IMHO, v6ops WG would be more appropriate for this kind of work.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Thomas Narten <[email-masked]>
Date: Thu, 14 Jul 2005 10:11:19 +0200

Hi Jordi.

> 1) HD-Ratio modification, as it seems to be an integral part of the

IMO, changing the HD-ratio is a no-brainer, and I suspect that many
people feel the same way. It's an easy change to make and has minimal
impact. Indeed, there is already an ARIN proposal to do this:

	http://www.arin.net/policy/proposals/2005_5.html

So yes, I expect this will be done and will personally push to see
this happen.

> troubles to get a bigger prefix when this is needed.

We should be careful NOT to assume that just because something is done
one way in IPv4, it will be similar in IPv6.

Indeed, I think one of the big cultural changes w.r.t. IPv6 is the
notion that end sites get subnets (emphasis on plural) where this is
clearly NOT the norm for IPv4 today. My sense is (from talking to folk
in the RIR community) is that they all believe this, and that ISPs
working with IPv6 also get this. So I think we've already changed the
starting point here.

Also, in IPv4, the existing practice is to give out a single
address. There are multiple reasons for this, some cultural (i.e.,
status quo). But another point that I think people sometimes forget is
that the existing protocols and busines practices have been built
around giving out a single address (rather than a subnet) and such,
getting a subnet is, in fact, an exception to the norm. As we know,
exceptions can cost more, i.e., in terms of help desk support, etc.

So even though ISPs in IPv4 do tend to charge more for "more than one
address", the reasons for that are a bit subtle, and when they say its
because "more address just cost more", that is really just FUD. In no
case can the case be made that it is because the extra addresses
actually "cost more", i.e., in terms of RIR policies.

Again, my sense in the RIR regions is that folk want the RIR policies
to be very clear that addresses should be available to end sites at
very low cost (i.e., essentially free), and that the cost of a /48
should be the same as a /56 or /64. And with DHCPv6 prefix delegation
(as the protocol/operational mechanism for achieving this) I think we
are on track to see the right thing happen.

To ensure that happens, the RIR policies will need to be sure that
when LIRs need more space from RIRs, the justification should be
based entirely on whether the existing space is sufficiently utilized
(based on the HD-ratio) with the metric being completely neutral as to
whether end sites are getting /48s or /56s. 

> My feeling is that today we believe that 8 bits for subnetting is
> enough, but I think will not be the case soon and this barrier will
> then be again a stopper for enabling innovation.

I think there is a general feeling in the RIR community that folks
that ask for more than a /56 should generally get it more-or-less by
asking. I'd welcome help in how to word this. What we don't want is
folk automatically asking for a /48 "just because they can". In
practice, a /56 will really be enough for a large percentage of end
sites, for a long while. Hence, the current "justification" for space
is probably best expressed in terms of size of a site in terms of
subnets. That is something objectively measurable and captures the
sense of whether additional space is really needed.

> I know this one is somehow not an IETF business, but we must be
> worried about that and may be collectively work for the appropriate
> solution in the appropriate fora.

We simply need to pay attention to what is going on in the RIR
community, and followup as appropriate. The good news is that my own
sense (from going to ARIN meetings for 3 years or so, and attending
the last RIPE meeting) is that the community there largely shares the
same goals as I'm hearing here. They do understand that IPv6 is
different than IPv4 and that we need to focus less on conservation
than IPv4. I think that most of the community is actually quite happy
about this.

> telcos do in EU is a crime.

No. I think there is no justification (in increased $$) for a /48
vs. a /56. The RIR policies should be clear about that. That won't
prevent ISPs from (perhaps) doing this, but they will use weaker
arguments like "a /48 implies more traffic and therefore more $$". But
then again maybe not. In practice, with a /56, end sites can generate
plenty of traffic and ISP charges may end up having to switch to
something based on actual traffice being carried.

Thomas

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 14 Jul 2005 11:31:31 +0200

Hi Thomas,

I totally agree with your appreciations.

May be one possibility to ensure that this is going to work also with the
RIRs is to hold this document until the RIRs policy changes align to it, and
work pro-actively with them in order to make that happening ASAP ?

I will suggest a small change to this text (section 2):
   "... While that number may
   make sense for larger sites, it is hard to imagine a typical home
   user requiring so much space. Indeed, the default end site assignment
   today is in practice the same for home users and larger businesses."

For something such as:
"... While that number may
make sense for larger sites, it is hard to imagine, at the time being, a
typical home user requiring so much space, but this can change and we must
be ready and open to that. Indeed, the default end site assignment today is
in practice the same for home users and large businesses.
Moreover, the change in the recommended assignment (from /48 to /56) should
not become a barrier for any customer to get a /48 from the ISP, whenever
the ISP is required for that, with no need for further justifications for
that request."

One open question is if this change will impact in the default allocation of
/32 to the LIRs. I mean, should they still keep considering that the
customers will be able to request a /48 and consequently keep allocating the
big prefixes that we have seen until now ? If not, should the big prefixes
already allocated be claimed back ? Yes, I know is a RIR business, but I
think otherwise we clarify it ASAP, it can create a lot of unfairness in the
process with future allocations.

Moreover, it will be a good suggestion for ISPs to block the remaining /56
up to the /48 for each customer, in case he ask for it, in order to avoid
renumbering ? If that's the case, there is any meaning for this change
towards the conservation ?.

Note that there is already some people proposing that the business model for
IPv6 is precisely charging for the addresses, which I believe is totally
broken and a wrong approach. The business will come because there are new
services and applications, for which the ISPs will be able to charge, either
because the service itself or the BW required by the service, or a
combination of both. This will not happen if the addresses aren't available
for free (the applications will never come in that case, and we will end-up
with a NATv6 model). Also some ISPs in AP are already providing only a /64
and charging for a different "service class" if the customer ask for several
subnets.

Regards,
Jordi

(note: I've copied the globa-v6 list as suggested in previous emails from
Thomas)

> Fecha: Thu, 14 Jul 2005 10:11:19 +0200
> Para: <[email-masked]>
> CC: "[email-masked]" <[email-masked]>
> Asunto: Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
> 
> Hi Jordi.
>

---

From: "Soininen Jonne (Nokia-NET/Helsinki)" <[email-masked]>
Date: Thu, 14 Jul 2005 12:59:18 +0300

Thomas and Jordi,

I of course share the worry that the operators will start charging
differently different size end-user allocations. However, I feel there
is little we can do about the in the IETF and therefore I would see that
we should not use too much time on this.

I think the only practical thing we can do is to advice that the
end-user network will have enough addresses to satisfy its communication
needs to avoid the introduction of e.g. NAT into IPv6 networks.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: David Conrad <[email-masked]>
Date: Thu, 14 Jul 2005 07:34:17 -0700

Hi,

On Jul 14, 2005, at 2:59 AM, Soininen Jonne (Nokia-NET/Helsinki) wrote:
> differently different size end-user allocations.

I strongly suspect they will since many ISPs have already  
incorporated address space charges into their business models.  I  
would imagine ISPs continue to look for any way they can add optional  
charges to your monthly bill so they can legally advertise low  
connectivities fees.

> However, I feel there

I would agree.  The IETF hasn't, to my knowledge, been particularly  
effective in limiting business models.

> needs to avoid the introduction of e.g. NAT into IPv6 networks.

I would suggest that NATv6 will be created and exist as long as there  
is a significant (at least perceived) cost to transitioning service  
providers.

Rgds,
-drc

---

From: Kosuke Ito <[email-masked]>
Date: Thu, 14 Jul 2005 23:43:53 +0900

Hi Thomas,
Thank you for extending this discussion to the global ML
from IETF arena.

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?
Why do we need to change an assignment size?
If we change it/them, what do we have in return?
Just reducing the pace of address consumption?
Do we like to creat SWAMP already?

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

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

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.

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

Kosuke

-- 
**********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: [email-masked]   http://www.v6pc.jp/
Lifetime e-mail: [email-masked]

---

From: (Tomohiro -INSTALLER- Fujisaki) <[email-masked]>
Date: Fri, 15 Jul 2005 11:09:48 +0900 (JST)

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

Actually, some providers have already assigned /48 based on current
recommendation in their commercial service, and as Kosuke said, it
will have a large impact to change the assignemnt size.

I've looked up the assignemnt size used in JP regison:

http://www.apnic.net/meetings/18/docs/sigs/policy/policy-pres-tomohiro-ipv6-endusers.pdf

This is slightly dated information, and recently, at least one
provider has been starting commercial IPv6 services with /48
assignment. This service is targeted on residential users.

 | Is it practical to change in other regions?

I also would like to know about this.

--
Tomohiro Fujisaki

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 15 Jul 2005 17:40:24 -0700

I said part of this on the ARIN PPML list but thought it should be repeated
here. 

A /64 allocation never makes any sense. The claims about a PDA only needing
one assume that it will never be dropped into a cradle of a vehicle suddenly
enabling various subnets (freight environmental or inventory monitor,
dispatch service) to reach out or be reached with independent access
controls. A /64 puts the carrier in the position of telling the customer
they can't build anything more than a single lan, where a /60 removes that
limitation with effectively the same impact on space utilization.

We bumped into another version of this when thinking through some of the
issues with cable. The MSO's appear to be focusing around a prefix being the
unit of allocation to a customer. All well and good until we get the 'a /64
is more than enough space' discussion. The issue crystallized when the
discussion included a separate subnet for cable devices in the home to
communicate locally. Since the MSO has bought into the concept of a prefix
maps to a customer, having independent /64's breaks the allocation and
management model. The conservation mindset clashes with the simplified
management mindset and documents with wording like this are not helping.

This draft really needs to remove the discussion about a /64 being
appropriate for anything from an allocation perspective. There is no serious
technical need for the draft to begin with, but if it exists it should point
out that a /60 is the longest prefix that allows customers to build networks
with multiple links (specifically technologies that don't bridge) and maps
cleanly onto the reverse delegation name tree. 

Tony 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Thomas Narten
> Sent: Wednesday, July 13, 2005 2:44 PM
> To: [email-masked]
> Subject: FWD: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
>

---

From: Thomas Narten <[email-masked]>
Date: Sat, 16 Jul 2005 14:20:15 +0200

Ito-san,

You raise some good questions.

> 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

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

> slowing down the pace of allocation (if it is the goal

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.

> for the low-cost routing devices handling /48.

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

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

> 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

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 16 Jul 2005 22:39:25 +0200

I tend to agree with this.

I see situations for assigning a /128 when a unique device is connected,
which is not going to route anything else, but once it has other interfaces
(which is the most common case and will become more and more often) ...

Regards,
Jordi

> De: Tony Hain <[email-masked]>
> Fecha: Fri, 15 Jul 2005 17:40:24 -0700
> Para: 'Thomas Narten' <[email-masked]>, <[email-masked]>
> Asunto: RE: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 17 Jul 2005 13:16:35 +0200

Hi,

El 14/07/2005, a las 16:43, Kosuke Ito escribió:

> Do we like to creat SWAMP already?

i fail to understand why this change would create swamp? could you 
expand on this?
> for the low-cost routing devices handling /48.

why would this have such impact on devices? do they have the /48 
hardcoded? could you expand on this point?

> assignment policy.

I guess it is easier if all users get a /48 indeed, but how much effort 
is required to determine the proper prefix for each costumer? is there 
any additional operational cost that you could let us know?

> Is it practical to change in other regions?

We had a discussion about IPv6 address management in the LACNIC VIII 
meeting in Lima (30 of june 2005) and my reading of the comments of the 
meeting is that they are pretty much in line with the considerations 
expressed by Thomas in his drafts.

Regards, marcelo

>> This electronic message contains information which may be privileged 
>> or confidential. The information is intended to be for the use of the 
>> individual(s) named above. If you are not the intended recipient be 
>> aware that any disclosure, copying, distribution or use of the 
>> contents of this information, including attached files, is 
>> prohibited.
> global-v6 mailing list
> [email-masked]
> http://mailman.apnic.net/mailman/listinfo/global-v6
>

---

From: Gert Doering <[email-masked]>
Date: Mon, 18 Jul 2005 12:28:13 +0200

Hi,

> process with future allocations.

/32s are *not* "big prefixes".

What are you aiming for?  

Reduce the ISP minimum allocation size - for what good?

If all the IPv6 space is handed out as /32s, we have 4 billion routes - which
is very bad.  Anything aiming for even smaller blocks (longer prefix) is 
going the wrong way - brings some benefit to conservation but hurts routing.

> towards the conservation ?.

This suggestion is not useful.  If you reserve the rest of the /48, then
you can hand out the /48 in the first place, and be done with it.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  71007  (66629)

SpaceNet AG                    Mail: [email-masked]
Joseph-Dollinger-Bogen 14      Tel : +49-89-32356-0
D- 80807 Muenchen              Fax : +49-89-32356-234

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 18 Jul 2005 12:46:24 +0200

Hi Gert,

See below, in-line.

Regards,
Jordi

> De: Gert Doering <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Mon, 18 Jul 2005 12:28:13 +0200
> Para: JORDI PALET MARTINEZ <[email-masked]>
> CC: "[email-masked]" <[email-masked]>, <[email-masked]>
> Asunto: Re: [GLOBAL-V6] Re: I-D
> ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
> 
> Hi,
> 

No, I was not referring to /32, but to the big allocations, such as /1x or
/2x, for example.

> Reduce the ISP minimum allocation size - for what good?

What I'm trying to say is that if we change the policy, and those that now
can get, for example a /24 and with the new policy will only get a /28, have
the same right to still get the /24, unless those that got the /24 (now) get
it reduced to /28. Just an example, hopefully is now more clear.

Otherwise, we are behaving in a very unfair way.

Note that I don't want that this happens, I'm just explaining my view point
about how unfair the situation will be.

> going the wrong way - brings some benefit to conservation but hurts routing.

Totally agree, I guess I was not clear, hopefully now is much better !

> you can hand out the /48 in the first place, and be done with it.

That's was my point ;-)

---

From: Kosuke Ito <[email-masked]>
Date: Mon, 18 Jul 2005 22:12:20 +0900

> i fail to understand why this change would create swamp? could you 

I just extend my imagination that we may be about stepping
into the same mistake we made for IPv4, such as network
management nightmare of managing sider space, longer prefix
allocation, etc. which swell ISPs management cost.
But maybe, the minimum initial allocation of /32 would not be
changed, wouldn't it?
Then, my SWAMP statement made before would not be the case.

> hardcoded? could you expand on this point?

Many of home routers sold in Japan is designed and build
to associate with an ISP's service operational scheme.
Currently, a home router receiving /48 from the ISP block
and assigned a /64 out of it automatically ( and manually
done by the user if necessary).

> any additional operational cost that you could let us know?

If the assignment size gets various, more overhead functionality
needs to be implemented into the home router to set the appropriate
assignemnt size user by user, and/or ISP needs to decide its size
user by user (since the size of assignment under /48 is determined
by ISPs).
Who pay this price?

> expressed by Thomas in his drafts.

Thank you.
How many acctual/commercial assignments have been made (or
registered) in LACNIC area?

Kosuke

>>> contents of this information, including attached files, is prohibited.

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 18 Jul 2005 15:37:22 +0200

> registered) in LACNIC area?

See http://www.sixxs.net/tools/grh/dfp/lacnic/
Also for the other regions of course.

Greets,
 Jeroen

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 18 Jul 2005 15:36:10 +0200

Hi Kosuke,

> But maybe, the minimum initial allocation of /32 would not be
well, i guess that these are two different issues:
- on one hand, the size of end-sites assigments, which seems to be one  
of the main focus of the discussion here (to move it from /48 to /56)
- on the other hand, whether this change, would imply a change in the  
minimum allocation to lirs

IMHO, i am much more concerned with the first point than with the  
second point. I mean, i can live with the /32, but i am worried about  
the /48
(Besides, probably changing the /48 would also impact in the size of  
bigger allocations (i.e. prefix shorter than 32 bots) since now each  
site won't account for a /48)

> and assigned a /64 out of it automatically

How does the router obtains the /48? is this automatic? does it uses  
DHCP prefix option?

>  ( and manually
>> I guess it is easier if all users get a /48 indeed, but how much  
>> effort is required to determine the proper prefix for each costumer?  
>> is there any additional operational cost that you could let us know?
>

AFAIU, so far the proposal is to have two prefix lengths /48 for big  
end sites and /56 for smaller sites. I am not sure how much more  
complexity this would add...
I mean, automatic prefix delegation using dhcp prefix option would  
support this transparently.

> Who pay this price?

obviously this an increased cost (there ain't no such thing as a free  
lunch) But quite a few bits are not wasted so, i would need very good  
reasons or very high costs (whatever you want to see it) not to support  
this proposal. I so far, i am far from convinced that the costs  
involved in the support of this policy are high, but i am open to be  
convinced otherwise

>> meeting in Lima (30 of june 2005) and my reading of the comments of  
>> the meeting is that they are pretty much in line with the  
>> considerations expressed by Thomas in his drafts.
>
> Thank you.

i will forward this question to lacnic people

regards, marcelo

>>>>> Administrative Requests:  
>>>>> https://www1.ietf.org/mailman/listinfo/ipv6
>>>> This electronic message contains information which may be  
>>>> privileged or confidential. The information is intended to be for  
>>>> the use of the individual(s) named above. If you are not the  
>>>> intended recipient be aware that any disclosure, copying,  
>>>> distribution or use of the contents of this information, including  
>>>> attached files, is prohibited.

---

From: (Tomohiro -INSTALLER-Fujisaki/藤崎 智宏) <[email-masked]>
Date: Tue, 19 Jul 2005 00:08:23 +0900 (JST)

Hi Marcelo,

 | > Many of home routers sold in Japan is designed and build
 | > to associate with an ISP's service operational scheme.
 | > Currently, a home router receiving /48 from the ISP block
 | > and assigned a /64 out of it automatically
 | 
 | How does the router obtains the /48? is this automatic? does it uses  
 | DHCP prefix option?

>From the address assignment view point, many ISPs in Japan use the
DHCPv6 prefix option for residential users. So, TECHNICALLY, changing
the assignment size may not be so hard for ISPs.

However there may be some cases that ISPs have to check the DHCPv6
client devices' behavior, the independency of the /48 prefix size (/64
prefix selection, filtering function, and so on).

 | > If the assignment size gets various, more overhead functionality
 | > needs to be implemented into the home router to set the appropriate
 | > assignemnt size user by user, and/or ISP needs to decide its size
 | > user by user (since the size of assignment under /48 is determined
 | > by ISPs).
 | 
 | AFAIU, so far the proposal is to have two prefix lengths /48 for big  
 | end sites and /56 for smaller sites. I am not sure how much more  
 | complexity this would add...
 | I mean, automatic prefix delegation using dhcp prefix option would  
 | support this transparently.

This may not be the IETF issue, but from the ISPs' service view point,
changing the prefix size has a impact to existing service spec (of
course, the spec includes the price of the service. Should ISPs
provide existing /48 service and following /56 service as same price?
Don't customers complain this?).

And mixing the different size prefix may increase the cost of the
address management (but this may not be a big problem as you said).

--
Tomohiro Fujisaki

---

From: Kosuke Ito <[email-masked]>
Date: Tue, 19 Jul 2005 00:19:24 +0900

Hi Thomas,

> You raise some good questions.

Thank you :-)

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

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

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

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

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

> 	larger request than would be justified if based solely on the

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.

> they will get a /48? If so, in what ways are they using the 16 subnet

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.

> by three orders of magnitude is a huge amount of savings. One order is

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.

> 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

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 18 Jul 2005 10:50:52 -0700

The operator never should know if the device has a backside interface, so
the argument about /128 being valid is also wrong (/128's are the fastest
track to an IPv6 NAT that there is). From the perspective of the operator
they are selling access via a link, what the consumer does behind the device
connected to the link (other than resell it) is not their business. They
should be set up to allocate a prefix shorter than /64 in all cases. 

Tony 

> JORDI PALET MARTINEZ
> Sent: Saturday, July 16, 2005 1:39 PM
> To: [email-masked]; [email-masked]
> Subject: Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
> 
> >> http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-
> 48boundary-
> >> 00.txt
> >>
> >> [email-masked] with the word unsubscribe in the body of
> the
> >> message.
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the use of the
> individual(s) named above. If you are not the intended recipient be aware
> that any disclosure, copying, distribution or use of the contents of this
> information, including attached files, is prohibited.
> 
> 
> 
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 18 Jul 2005 20:02:45 +0200

I was thinking in a PPP link or PDP context, I'm not really sure if they
allow (at least today, but protocol definition), to use a prefix instead of
an address. Also for tunnel end points, where I think the recommendation is
/126, but some people still use /128, etc.

Regards,
Jordi

> Fecha: Mon, 18 Jul 2005 10:50:52 -0700
> Para: <[email-masked]>, <[email-masked]>,
> <[email-masked]>

---

From: Raul Echeberria <[email-masked]>
Date: Mon, 18 Jul 2005 18:07:45 -0300

Thomas Narten wrote:

>decrease in the supply.
Thomas:

I don't agree with your perception regarding IPv4 policies  what seems 
to be the base of your argument here.
Maybe it is more difficult to get IPv4 addresses now  than in the 
earlies `90, but I don't agree that the policies developed in the RIR's 
forums in the last couple of yesars are more conservatives.
On the other hand, there are many people (including myself) that share 
the concern taht it could happen the same that already happened with 
IPv4 during the early deployment of Internet, causing unfairness in the 
size of allocations of IP addresses.

I tend to agree with the idea behind your draft, but not with that you 
said here.

Raúl

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 18 Jul 2005 14:05:56 -0700

PPP is a link technology for connecting the consumer device to the SP
router. Not to be advertising, but
http://www.cisco.com/en/US/products/hw/routers/ps272/index.html would take
any offered PDP context as an interesting link that might have a route to
someplace useful at the other end. The point is it doesn't matter if that
consumer device is an endpoint or a router; the carrier sees a logical link
to a customer. What the customer does behind the device on the other end of
that link is outside the carrier's realm of concern. Even if they think they
know, widespread use of NAT proves that they don't. So rather than look at
this as a role specific device connecting to a limited scope service, the
carriers need to pay attention to the fact that the consumer edge device is
in control of the actual application, and any barriers just create a market
for technologies to circumvent them. 

Yes, there are no technical problems with long prefixes. The problem with
long prefixes is the operational fall out at the other end. If business
models get built around very long prefixes, people will demand a
one-time-cost device to use the low continuing cost long prefix as a means
to mitigate the costs of doing it right to start with. IETF documents should
not recommend anything longer than a /60 at the demarc between a service
provider and customer. 

It is not the IETF's job to define business models, but outlining the
consequences of specific approaches is a responsibility. 

Tony 

> Sent: Monday, July 18, 2005 11:03 AM
> >>> issues with cable. The MSO's appear to be focusing around a prefix
> being
> >> the
> >>> unit of allocation to a customer. All well and good until we get the
> 'a
> >> /64
> >>>> http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-
> plenary-
> >>>> wed-ipv6-roundtable-report.pdf
> >>>>
> aware

---

From: Randy Bush <[email-masked]>
Date: Mon, 18 Jul 2005 05:52:20 -1000

> address allocation that address provides when it is needed?

there has been a long history of the ivtf v6 designers' view of
the operational/social issues.  essentially, it is based on a
belief that the internet is severely hampered by users having
to go to evil isps for ip space, isps having to go to evil rirs
for address space, and recently, rirs having to go to the evil
iana for address space.  if only ip address space was freely
available without any operational administratriva, ipv6 would
be wildly successful and the world would be saved.

personally, i am most enamored of the next-stage model, where
isps do not have to actually have all those messy circuits to
be able to deliver packets.

randy

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 19 Jul 2005 11:07:30 +0200

> i will forward this question to lacnic people

LACNIC people send the following information w.r.t. IPv6 allocations in 
the lacnic region:

I guess is similar to the one included in the web page sent by Jeroen

regards, marcelo

lacnic|MX|ipv6|2001:1200::|32|20030110|allocated
lacnic|MX|ipv6|2001:1208::|32|20030203|allocated
lacnic|MX|ipv6|2001:1210::|32|20040924|allocated
lacnic|MX|ipv6|2001:1218::|32|20050629|allocated
lacnic|BR|ipv6|2001:12e0::|32|20040702|allocated
lacnic|BR|ipv6|2001:12e8::|32|20040726|allocated
lacnic|BR|ipv6|2001:12f0::|32|20031028|allocated
lacnic|BR|ipv6|2001:12f8::|48|20041202|allocated
lacnic|BR|ipv6|2001:12ff::|32|20030728|allocated
lacnic|PE|ipv6|2001:1300::|32|20050711|allocated
lacnic|DO|ipv6|2001:1308::|32|20030612|allocated
lacnic|CL|ipv6|2001:1310::|32|20030821|allocated
lacnic|AR|ipv6|2001:1318::|32|20031124|allocated
lacnic|PY|ipv6|2001:1320::|32|20040527|allocated
lacnic|UY|ipv6|2001:1328::|32|20040720|allocated
lacnic|CR|ipv6|2001:1330::|32|20041104|allocated
lacnic|VE|ipv6|2001:1338::|32|20041123|allocated
lacnic|CU|ipv6|2001:1340::|32|20050406|allocated
lacnic|UY|ipv6|2001:1348::|32|20050419|allocated
lacnic|VE|ipv6|2001:1350::|32|20050520|allocated
lacnic|CU|ipv6|2001:1358::|32|20050629|allocated
lacnic|GT|ipv6|2001:1360::|32|20050711|allocated
lacnic|PA|ipv6|2001:1368::|32|20050706|allocated
lacnic|HT|ipv6|2001:1370::|32|20050706|allocated
lacnic|BO|ipv6|2001:1378::|32|20050706|allocated
lacnic|PE|ipv6|2001:1380::|32|20050712|allocated
lacnic|PE|ipv6|2001:1388::|32|20050714|allocated
lacnic|AR|ipv6|2001:1390::|32|20050715|allocated
lacnic|AR|ipv6|2001:1398::|32|20050718|allocated

---

From: Bob Hinden <[email-masked]>
Date: Tue, 19 Jul 2005 14:03:41 -0700

Jordi,

>(which is the most common case and will become more and more often) ...

A /128 breaks IPv6 Privacy Addresses (RFC3041).  Every device needs a /64 
to allow this mechanism to be used.

Bob