Subject: [v6ops] new draft: draft-shishio-v6ops-dpvt

From: <[email-masked]>
Date: Mon, 18 Feb 2013 05:45:00 -0800 (PST)

A new draft has been posted, at http://tools.ietf.org/html/draft-shishio-v6ops-dpvt. Please take a look at it and comment.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 19 Feb 2013 21:01:38 +0900

On Mon, Feb 18, 2013 at 10:45 PM, <[email-masked]> wrote:

>
> A new draft has been posted, at
> http://tools.ietf.org/html/draft-shishio-v6ops-dpvt. Please take a look
> at it and comment.
>

Wait... this draft seems to propose a way of figuring out a node's IPv6
prefixes (i.e., part of its configuration). using unauthenticated ICMPv6
messages. How can there be "no additional security considerations"?

---

From: Vízdal Aleš <[email-masked]>
Date: Tue, 19 Feb 2013 15:08:04 +0100

Hi,

can you please bit more elaborate on the problem you're trying to solve?

Cheers,
Ales

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Monday, February 18, 2013 2:45 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [v6ops] new draft: draft-shishio-v6ops-dpvt
> 
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Shishio Tsuchiya <[email-masked]>
Date: Wed, 20 Feb 2013 00:40:52 +0900

Lorenzo

(2013/02/19 21:01), Lorenzo Colitti wrote:
> On Mon, Feb 18, 2013 at 10:45 PM, <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> Wait... this draft seems to propose a way of figuring out a node's IPv6 prefixes (i.e., part of its configuration). using unauthenticated ICMPv6 messages. How can there be "no additional security considerations"?

Indeed.
I should modify this section .
The message should only accept from  authorized node(like 6PE BR and DHCPv6 server).

And
I will replace

"Delegated Prefix(128bit): the delegate prefix which is the operators
   would like to know.If the field be zero,it means all of inteface
   address are requested."

to

"Delegated Prefix(128bit): the delegate prefix which is the operators
   would like to know."

Regards,
-Shishio

---

From: Shishio Tsuchiya <[email-masked]>
Date: Wed, 20 Feb 2013 00:40:57 +0900

Ales
Thank for your interest.
As I described reply to Fred,
The stateless tunnel and prefix delegation technology provides much scalability network to the customer.
On one hand, these technologies are difficult to plan additional capacity and hard to know current deployment
status unless the devices are completely managed.
If the BR has state and DHCPv6 server knows detail route,then the merit of these technologies would be disappeared.

So I thought these technologies need small oam tools.

-confirm only interface configuration from ISP side
-confirm reachability not use end to end

I would appreciate any comment.

Regards,
-Shishio

---

From: Owen DeLong <[email-masked]>
Date: Tue, 19 Feb 2013 11:21:10 -0800

I'm sorry, but I still do not understand the need for this technology.

In the current case:
	The operator's system delegates a prefix to the subscriber.
	The operator has no need for visibility into the subscriber's network.
	The subscriber's equipment can break up the delegated prefix at will.
	The operator only needs to deliver packets to the subscriber through
		the device which requested and received the delegation.

What problem is solved by giving the operator additional visibility into the
subscriber's network and why would this be desirable?

From the subscriber perspective, I think this is a breech of security as it
discloses information about the structure of my network without my
consent.(Even if that disclosure is limited to the provider which
delegated the prefix.)

From the provider perspective, I don't see the advantage to being able to
gather this information.

Perhaps it would help if you could answer the following questions:

1.	What is the advantage to the provider from knowing the subscriber's
	router interface configuration?

2.	What if the router has delegated component prefixes to other
	routers?

Additionally, I think that there are security considerations and merely
restricting the permitted sources of these queries does not adequately
address them.

Owen

---

From: Shishio Tsuchiya <[email-masked]>
Date: Wed, 20 Feb 2013 14:18:36 +0900

Owen
I really appreciate your comment.

>>From the provider perspective, I don't see the advantage to being able to

I know Sakura internet who provides the information of 6rd CE/BR and IPv6 internet.
In this case,the operators can enable 6rd CE on demand.
http://tools.ietf.org/html/draft-sakura-6rd-datacenter-04

BR don't need any additional configuration, so 6rd PE provider can not know
how many CE enabled 6rd without traffic monitoring.

And some enterprise customer would like to use 6rd instead of manual tunnel.

In these cases,PE operators doesn't need additional configuration for each of CEs.
This is really stateless tunnel merit.But can not find how many CE already deployed.

About DHCP-pd,service provider delegates large prefix to CPE.
Service provider can not know proper prefix size for the customer.

> 	router interface configuration?

As I describes, the advantage is for planning.

> 2.	What if the router has delegated component prefixes to other

Umm.Indeed.
The draft can not know information if the delegated prefix move and relay to another routers.

> restricting the permitted sources of these queries does not adequately

Thanks for comment.

Regards,
-Shishio

> .

---

From: Owen DeLong <[email-masked]>
Date: Wed, 20 Feb 2013 00:44:50 -0800

> how many CE enabled 6rd without traffic monitoring.

But why do they need to know? If they've set aside the covering prefix, there's
no prefix capacity planning issue to consider, so what is the justification for
them needing this information?

> And some enterprise customer would like to use 6rd instead of manual tunnel.

Hopefully we won't need tunnels too much longer anyway,. I would rather see us
treat this as a deficiency/limitation in 6rd and continue to push for native
deployment and moving away from 6rd.

In the DHCP case, you've got the logs of the PD request and PD response from
the DHCP server to give you that data.

> This is really stateless tunnel merit.But can not find how many CE already deployed.

Again, once you've set aside the 6rd covering prefix, what does it matter?

> Service provider can not know proper prefix size for the customer.

I would say any prefix longer than /48 requested by the customer's equipment
is the right size, no?

If the customer wants something shorter than a /48, you've moved beyond
straight DHCP configuration without operator intervention anyway.

Such cases should be pretty rare exceptions.

> As I describes, the advantage is for planning.

Planning what, exactly?

> The draft can not know information if the delegated prefix move and relay to another routers.

Which seems to me like a very likely scenario and one which would invalidate any planning based on what you have proposed. Am I missing something?

---

From: Vízdal Aleš <[email-masked]>
Date: Wed, 20 Feb 2013 17:00:51 +0100

Shishio,

> From: Shishio Tsuchiya [mailto:[email-masked]]
> Sent: Tuesday, February 19, 2013 4:41 PM
> To: Vízdal Aleš
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt
> 
> Ales
> Thank for your interest.

What you've responded to is a default email that is send to the authors by the tracker 
once a new draft is posted.

> technologies would be disappeared.

Let's take the DHCP-PD case, I assume that the IP resource planning goes hand in hand 
with the number of subscribers the ISP is expecting to serve. The operator needs to decide 
on the prefix-length to be delegated down to the subscriber and that's it, so they can
plan enough prefixes per access area. The operator does not need to know if/how I am using 
my delegated prefix. They should be happy to give/sell me another prefix if needed. 

Can you please clarify what's the benefit from Operator's point of view?

Cheers,
Ales

---

From: Shishio Tsuchiya <[email-masked]>
Date: Fri, 22 Feb 2013 09:23:16 +0900

Ales
> Can you please clarify what's the benefit from Operator's point of view?

Yes,this is ideal planning.
And RIR also has published guide line of IPv6 assignment for enduser.
http://www.apnic.net/publications/media-library/documents/resource-guidelines/ipv6-guidelines
RFC6177 was published as BCP.
http://tools.ietf.org/html/rfc6177

Most of ISP used be provided /48 by dhcp-pd and when after RFC3177 obsoleted, they changed it to /56 and more shorter.
If the policy would be changed ,then operator should understand how delegated prefix are using.
This is reason of the feature could provide to operators benefit ,I thought.

Thanks for your feedback.

Regards,
-Shishio

---

From: Vízdal Aleš <[email-masked]>
Date: Fri, 22 Feb 2013 10:07:22 +0100

Shishio,

> Sent: Friday, February 22, 2013 1:23 AM
> To: Vízdal Aleš
> Cc: Shishio Tsuchiya; [email-masked]; [email-masked]
> >> On one hand, these technologies are difficult to plan additional capacity and hard
> to
> >> know current deployment

I am not sure I follow ... but are you trying to say that should the RIR policy change resulting
in ISPs trying to figure out what's the best prefix to be allocated to an end user your 
tools would allow to find out the current utilization of already assigned prefixes?

If so, I believe there are other ways how to find out without involving the customer
such as netflow/ipfix.

Cheers,
Ales

---

From: Shishio Tsuchiya <[email-masked]>
Date: Fri, 22 Feb 2013 18:26:29 +0900

Ales

> If so, I believe there are other ways how to find out without involving the customer

Yes, both of dhcp-pd and 6rd cases, operator can use netflow/ipfix to investigate for the utilization of prefixes and traffic.
The draft is proposal of simpler way.
If the merit is fewer than pain and risk, then the proposal should be withdrawn.
So I would like to hear wg comment on IETF86.

I really appreciate your many feedback.
Let's modify next version.

Regards,
-Shishio

---

From: Owen DeLong <[email-masked]>
Date: Fri, 22 Feb 2013 01:27:35 -0800

> Yes,this is ideal planning.

We can agree to disagree on your use of the term "ideal" in this context.

> http://www.apnic.net/publications/media-library/documents/resource-guidelines/ipv6-guidelines

I'm not a particular fan of this document and have given APNIC feedback on it.

> http://tools.ietf.org/html/rfc6177

True. I wasn't participating actively in IETF at the time 6177 was written. IMHO, it is a travesty of v4 thinking being brought forward into IPv6 and should be considered harmful rather than BCP. It is neither common, nor best practice in my experience so far in the IPv6 world.

I will point out that no RIR provides any policy penalty for sticking with /48s and several of them actually provide benefits if you do so. Notably, ARIN policy is now based on the smallest prefix you assign to end users, so if you assign some end-users /64s and some /48s, you have to justify 65,536 /64s for each of your /48s assigned. OTOH, if you just give everyone a /48, you can just count up the number of /48s you assigned and each end user getting
a /48 is considered completely legitimate.

> Most of ISP used be provided /48 by dhcp-pd and when after RFC3177 obsoleted, they changed it to /56 and more shorter.

I believe you mean and longer. This is an unfortunate change that we can hopefully reverse before it becomes too entrenched and does too much harm.

> This is reason of the feature could provide to operators benefit ,I thought.

There is no policy that prevents assigning /48s. Only a BCP that was poorly conceived.

Owen

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 26 Feb 2013 15:34:46 +0900

On Fri, Feb 22, 2013 at 6:27 PM, Owen DeLong <[email-masked]> wrote:

> True. I wasn't participating actively in IETF at the time 6177 was
> written. IMHO, it is a travesty of v4 thinking being brought forward into
> IPv6 and should be considered harmful rather than BCP. It is neither
> common, nor best practice in my experience so far in the IPv6 world.
>

You may disagree that it is best, but unfortunately, it IS common. The
largest IPv6 deployments in the world assign smaller than /48 blocks by
default.

Examples: AT&T /60, free.fr /60, Verizon Wireless /64 (though to be fair,
it's not their fault - 3GPP doesn't support DHCPv6 PD), Comcast /64 (unless
they've changed their default recently), NTT Japan /56 or /64, and so on.

In fact, I'm not aware of any major residential ISP (not a tunnel broker)
that actually assigns /48s. Are you?

---

From: "Brzozowski, John" <[email-masked]>
Date: Tue, 26 Feb 2013 13:52:54 +0000

Comcast has been setup from the beginning to allow up to a /60 for retail
residential broadband and /48 for our commercial services FWIW.  We will
revise these over time so please do not assume this is where things will
remain.  RFC3177 did not influence this decision and frankly was written
too early to be relevant IMO.

RFC6177 seems to be better however this has not factored heavily into our
decisions either.

One example worth noting is the recommendation to not issue /128s, many of
my customers have a single device connected to their broadband connection.
 Should I stop serving them IPv6?  If yes why?  This seems to contradict
our goal to increase IPv6 use across the ecosystem.  I am glad to see most
of the questionable text from 3177 was updated.  Most adopters of IPv6
recognize the need for shorter address blocks to support multiple
connected interfaces, however, there are some implementations that either
a) react poorly to a shorter prefix when the device cannot support the
same or b) simply do not support shorter prefixes.

John
=========================================
John Jason Brzozowski
Comcast Cable
m) 484-962-0060
e) [email-masked]
o) 609-377-6594
w) www.comcast6.net
=========================================

-----Original Message-----
From: Lorenzo Colitti <[email-masked]>
Date: Monday, February 25, 2013 10:34 PM
To: Owen DeLong <[email-masked]>
Cc: "[email-masked]" <[email-masked]>,
"[email-masked]"
<[email-masked]>
Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt

>Examples: AT&T /60, free.fr <http://free.fr> /60, Verizon Wireless /64
>(though to be fair, it's not their fault - 3GPP doesn't support DHCPv6
>PD), Comcast /64 (unless they've changed their default recently), NTT
>Japan /56 or /64, and
> so on.
>
>

---

From: "Brzozowski, John" <[email-masked]>
Date: Tue, 26 Feb 2013 13:58:02 +0000

Forgot to mention, Comcast hat on.

-----Original Message-----
From: <Brzozowski>, John Jason Brzozowski
<[email-masked]>
Date: Tuesday, February 26, 2013 5:52 AM
To: Lorenzo Colitti <[email-masked]>, Owen DeLong <[email-masked]>
Cc: "[email-masked]" <[email-masked]>,
"[email-masked]"
<[email-masked]>
Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 26 Feb 2013 15:00:45 +0100 (CET)

On Tue, 26 Feb 2013, Brzozowski, John wrote:

> One example worth noting is the recommendation to not issue /128s, many 
> of my customers have a single device connected to their broadband 
> connection. Should I stop serving them IPv6?  If yes why?  This seems to 
> contradict our goal to increase IPv6 use across the ecosystem.  I am 
> glad to see most of the questionable text from 3177 was updated.  Most 
> adopters of IPv6 recognize the need for shorter address blocks to 
> support multiple connected interfaces, however, there are some 
> implementations that either a) react poorly to a shorter prefix when the 
> device cannot support the same or b) simply do not support shorter 
> prefixes.

I take it you do not have a CPE device that is actually an L3 router at 
the customer premise, but the "cable modem" is only an L2 bridge?

As long as DHCPv6-PD space is available, then I would be fine by allowing 
for the customer option of a single PC connected would get its single IPv6 
address by means of DHCPv6 /128.

Personally I however opt for a solution where by default what comes out 
the CPE device is a SLAAC /64 where the customer can have a limited amount 
of ND entries (for instance 50), and if they want more then they have to 
get themselves a router which will get a /56 by means of -PD and put their 
additional devices behind that one. This ND 50 limitation is only needed 
if the device upstream that handles ND entries has some kind of limitation 
to ND entries, otherwise that can be skipped.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Brzozowski, John" <[email-masked]>
Date: Tue, 26 Feb 2013 14:07:53 +0000

-----Original Message-----
From: Mikael Abrahamsson <[email-masked]>
Organization: People's Front Against WWW
Date: Tuesday, February 26, 2013 6:00 AM
To: John Jason Brzozowski <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt

>the customer premise, but the "cable modem" is only an L2 bridge?
[jjmb] incorrect I have both, just stating that I have both.  Apologies if
I was not clear.  I also have a good # of home routers actively using IPv6
enabled broadband today, ~3%.
>address by means of DHCPv6 /128.
[jjmb] of course, we offer both.

>to ND entries, otherwise that can be skipped.
[jjmb] it is practical to limit the # of directly connected CPEs, however
for devices connected to the LAN of a CPE router this is really up to the
customer.  Sounds like you concur.

---

From: Owen DeLong <[email-masked]>
Date: Tue, 26 Feb 2013 10:39:23 -0800

On Feb 25, 2013, at 22:34 , Lorenzo Colitti <[email-masked]> wrote:

> You may disagree that it is best, but unfortunately, it IS common. The largest IPv6 deployments in the world assign smaller than /48 blocks by default.
> 

If it's becoming common, that's unfortunate. Hopefully it won't remain common for very long. I don't disagree with John about issuing /128s where necessary or about issuing /64s to devices that can't handle shorter prefixes. I accept the need to make things work in spite of buggy hardware and/or software.

> Examples: AT&T /60, free.fr /60, Verizon Wireless /64 (though to be fair, it's not their fault - 3GPP doesn't support DHCPv6 PD), Comcast /64 (unless they've changed their default recently), NTT Japan /56 or /64, and so on.
> 
> In fact, I'm not aware of any major residential ISP (not a tunnel broker) that actually assigns /48s. Are you?

However, there's zero benefit to issuing /60s, /56s, etc. vs. issuing /48s. I don't know if any of the non-tunnel providers are issuing /48s by default, but, I do know that /48s from our tunnel broker are fairly popular. (Including some from people that could go native if they were willing to accept the smaller prefixes from their providers).

It would be one thing if issuing such longer prefixes actually provided some benefit, but the reality is that it does not. All it does is make future innovation more difficult and reduce the utility of the network.

Owen

---

From: Ivan Pepelnjak <[email-masked]>
Date: Tue, 26 Feb 2013 19:49:16 +0100

On 26.02.2013 19:39 , Owen DeLong wrote:
[...]
> It would be one thing if issuing such longer prefixes actually provided
> some benefit, but the reality is that it does not. All it does is make
> future innovation more difficult and reduce the utility of the network.

Years after a similar comment on my blog I'm still waiting for a sample 
of innovation being stifled by residential end-user prefixes longer than 
/48.

Ivan

---

From: Doug Barton <[email-masked]>
Date: Tue, 26 Feb 2013 11:04:32 -0800

> of innovation being stifled by residential end-user prefixes longer than

Rather than repeat this entire discussion again, the answer I've 
proposed for years now, without anyone showing why it might be a bad 
idea ... :)

1. Reserve a /48 for each assignment
2. Actually assign whatever longer prefix you think is reasonable (/56, 
/60, etc.)
3. When you get past 50% of your space being reserved, review this policy

That way, if the people who say that it should be "/48s all the way 
down" are right, you're covered. If it turns out that you're running out 
of space and you can't get more (unlikely of course), then you can go 
back and chop each reservation in 1/2, and start again.

Doug

---

From: Owen DeLong <[email-masked]>
Date: Tue, 26 Feb 2013 11:06:53 -0800

On Feb 26, 2013, at 10:49 , Ivan Pepelnjak <[email-masked]> wrote:

> Years after a similar comment on my blog I'm still waiting for a sample of innovation being stifled by residential end-user prefixes longer than /48.
> 

It's too early to know. There isn't enough IPv6 deployment yet for the majority of innovators to have even started looking at what would be possible. Unfortunately, we're on a path where we will have to set the constraints first and then see what innovations occur. So far, we're on a good track to repeat the mistakes of IPv4, hamper said innovation (which many of the large residential ISPs may consider a vested interest), and deploy IPv6 in a manner that helps preserve a more consumer/provider model of the internet rather than a more peer-centric model.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Tue, 26 Feb 2013 11:09:06 -0800

On Feb 26, 2013, at 11:04 , Doug Barton <[email-masked]> wrote:

> Rather than repeat this entire discussion again, the answer I've proposed for years now, without anyone showing why it might be a bad idea ... :)
> 
> 2. Actually assign whatever longer prefix you think is reasonable (/56, /60, etc.)
> That way, if the people who say that it should be "/48s all the way down" are right, you're covered. If it turns out that you're running out of space and you can't get more (unlikely of course), then you can go back and chop each reservation in 1/2, and start again.
> 

At least in North America, it's pretty easy to get a very large amount of IPv6 space.

Being unable to obtain space is clearly not a valid reason to use longer prefixes and I certainly think that your proposed compromise is an improvement over dense-packing long prefixes. However, I have yet to hear from anyone any legitimate reason for using longer prefixes to begin with. Nobody has yet stated any benefit to doing so.

Owen

---

From: Doug Barton <[email-masked]>
Date: Tue, 26 Feb 2013 11:16:48 -0800

> At least in North America, it's pretty easy to get a very large amount of IPv6 space.

I think that's true pretty universally, and is likely to remain so for 
well past our lifetimes. :)

> Being unable to obtain space is clearly not a valid reason to use longer prefixes and I certainly think that your proposed compromise is an improvement over dense-packing long prefixes. However, I…

People have given reasons, you just don't agree with them. :)

Personally I am ambivalent, I have sympathy for the argument that we 
don't want to "waste" space since we thought IPv4 was "effectively 
infinite" at the time too. OTOH, the math on available IPv6 space is so 
astonishingly huge that humans literally have a difficult time 
understanding the amount of space we have available.

Given that there are hard and fast opinions on both sides of this 
debate, and neither group is likely to change their mind, the compromise 
I propose covers all the bases. Then 10 or 20 years from now we'll have 
a much better idea about who was right.

Doug (for those keeping score at home ...)

---

From: Owen DeLong <[email-masked]>
Date: Tue, 26 Feb 2013 11:42:04 -0800

On Feb 26, 2013, at 11:16 , Doug Barton <[email-masked]> wrote:

> I think that's true pretty universally, and is likely to remain so for well past our lifetimes. :)
> 

I literally haven't seen anything that is even alleged to be a benefit of longer prefixes.

Here's what I've seen:

	Comcast:	"Covers buggy hardware/software"
		I've already agreed that I accept this. However, that's /128s and /64s. Not /60s and /56s vs. /48s.

	A few others:
		"We shouldn't give it out liberally because we'll run out. Have we learned nothing from IPv4?"

		This isn't a benefit. This is fear mongering. The solution to this is, IMHO, Let's try it liberal until
		we're 50 years down the road or until 2000::/3 is fully allocated to RIRs, whichever comes first.
		If we fully allocate 2000::/3 to RIRs in less than 50 years, then we have plenty of time to talk
		about more conservative ways to allocate the next /3 and we still have 4 other /3s (1/2 of the
		total IPv6 address space) that remains untouched.

If you've seen someone stating an actual benefit (outside of "it covers for the bugs"), then please share... I really have literally missed it. If someone can show a truly valid reason for longer prefixes that involves either a benefit or a real downside to shorter ones, I really am open to being convinced.

> Personally I am ambivalent, I have sympathy for the argument that we don't want to "waste" space since we thought IPv4 was "effectively infinite" at the time too. OTOH, the math on available IPv6 space is so astonishingly huge that humans literally have a difficult time understanding the amount of space we have available.

I have a certain amount of sympathy for "don't waste space". However, providing bits to allow radical new autoconfiguration mechanisms for autonomous topological hierarchies in the residential environment is not a waste IMHO. Providing enough bits that residential end users are not treated as second class citizens for addressing purposes compared to businesses is not a waste IMHO.

If we define "wasted addresses" as "addresses not utilized to number hosts", then, no matter what we do, IPv6 is designed for and depends on huge amounts of waste. However, if we seriously consider the numbers, we see that the waste of giving out /48s to everyone still doesn't really have much of an impact.

UN's highest estimate of world population for 2100 is just under 16,000,000,000 (16 Billion). Let's assume that every single person represents a household that needs a /48 and that each person also has their own business that also needs a /48 (obviously a ridiculous over-estimation). That's a total need for 32 Billion (32,000,000,000) /48s. 2000::/3 provides 2^45 or 35,184,372,088,832, so we would still have more
than 35,150,000,000,000 /48s remaining in 2000::/3 with which we can number ISPs, infrastructure, servers, etc.

That's still within 1/8th of the total IPv6 address space.

> Given that there are hard and fast opinions on both sides of this debate, and neither group is likely to change their mind, the compromise I propose covers all the bases. Then 10 or 20 years from now we'll have a much better idea about who was right.

As I said, your compromise is better than what is being done today. However, both have distinct drawbacks and there are at least potential benefits to providing /48s (or at least /48s on request). Since there are no drawbacks (potential or actual) to issuing shorter prefixes, I really am at a loss as to how the other side justifies its position.

Owen

---

From: John Mann <[email-masked]>
Date: Wed, 27 Feb 2013 10:42:03 +1100

Hi,

On 27 February 2013 06:42, Owen DeLong <[email-masked]> wrote:

> >> Being unable to obtain space is clearly not a valid reason to use
> longer prefixes and I certainly think that your proposed compromise is an
> improvement over dense-packing long prefixes. However, I have yet to hear
> from anyone any legitimate reason for using longer prefixes to begin with.
> Nobody has yet stated any benefit to doing so.
> >
>                 I've already agreed that I accept this. However, that's
> /128s and /64s. Not /60s and /56s vs. /48s.
>
>         A few others:
>                 This isn't a benefit. This is fear mongering. The solution
> to this is, IMHO, Let's try it liberal until
>                 we're 50 years down the road or until 2000::/3 is fully
> allocated to RIRs, whichever comes first.
>                 If we fully allocate 2000::/3 to RIRs in less than 50
> years, then we have plenty of time to talk
> If you've seen someone stating an actual benefit (outside of "it covers
> for the bugs"), then please share... I really have literally missed it. If
> someone can show a truly valid reason for longer prefixes that involves
> either a benefit or a real downside to shorter ones, I really am open to
> being convinced.
>

There is a small but non-negligible matter of cost.

For example, at APNIC, based around 2^24 customers
a /32 costs AUD 1,994 ==
http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=&ipv6=%2F32&action=Calculate
and a /24 costs AUD 16,267 ==
http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=&ipv6=%2F24&action=Calculate

So, the difference between offering /56's to home users and /48's to home
users could be $14k per year.
Looking at it a different way, for AUD 1,994, they could provide 2^24 /56's
_or_ 2^16 /48's.

Somebody would have to sign off on the extra cost, or reduced customer goal.

> I have a certain amount of sympathy for "don't waste space". However,
> providing bits to allow radical new autoconfiguration mechanisms for
> autonomous topological hierarchies in the residential environment is not a
> waste IMHO. Providing enough bits that residential end users are not
> treated as second class citizens for addressing purposes compared to
> businesses is not a waste IMHO.
>
> If we define "wasted addresses" as "addresses not utilized to number
> hosts", then, no matter what we do, IPv6 is designed for and depends on
> huge amounts of waste. However, if we seriously consider the numbers, we
> see that the waste of giving out /48s to everyone still doesn't really have
> much of an impact.
>
> UN's highest estimate of world population for 2100 is just under
> 16,000,000,000 (16 Billion). Let's assume that every single person
> represents a household that needs a /48 and that each person also has their
> own business that also needs a /48 (obviously a ridiculous
> over-estimation). That's a total need for 32 Billion (32,000,000,000) /48s.
> 2000::/3 provides 2^45 or 35,184,372,088,832, so we would still have more
> than 35,150,000,000,000 /48s remaining in 2000::/3 with which we can
> number ISPs, infrastructure, servers, etc.
>

I don't think it is a simple matter of raw numbers.
Any address plan will have unallocated space, internal fragmentation etc.

>From your numbers -- 2^35 /48's out of 2^45 possible /48's allows for 10
bits of slack.

If we assume the address plan is hierarchical on nibble boundaries, then
that may allow for 3 levels of hierarchy with 2/16ths or 3/16ths
utilisation at each level.
  RIR -> ISP; ISP -> region; region -> customer
With care, seems doable.

> Given that there are hard and fast opinions on both sides of this debate,
> and neither group is likely to change their mind, the compromise I propose
> covers all the bases. Then 10 or 20 years from now we'll have a much better
> idea about who was right.
>
> As I said, your compromise is better than what is being done today.
> However, both have distinct drawbacks and there are at least potential
> benefits to providing /48s (or at least /48s on request). Since there are
> no drawbacks (potential or actual) to issuing shorter prefixes, I really am
> at a loss as to how the other side justifies its position.
>
> Owen

Thanks,
    John

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 27 Feb 2013 09:30:26 +0900

> either a benefit or a real downside to shorter ones, I really am open to

Note that a least as far as my message went, I wasn't trying to convince
you that assigning longer prefixes is right. I was trying to convince you
that that it is what happening in the real world.

---

From: Owen DeLong <[email-masked]>
Date: Tue, 26 Feb 2013 16:25:59 -0800

On Feb 26, 2013, at 3:42 PM, John Mann <[email-masked]> wrote:

> a /32 costs AUD 1,994 == http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=&ipv6=%2F32&action=Calculate
> and a /24 costs AUD 16,267 == http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=&ipv6=%2F24&action=Calculate
> 

Admittedly, some RIRs have (unfortunate) linear pricing models, but, let's look at the difference in cost per subscriber. A /24 is 16.7 Million subscribers at /48 (and a /32 is 16.7 million at /56), so we're dallying about
a difference per subscriber of $0.00085073711 per subscriber per year.

If you ask me, I'll happily pay an extra $0.01 per year to cover appropriate addressing for me and my
closest 99+ neighbors.

If you want to argue that at the low end of customers, you can handle ~65,000 customers from your /32
getting /48s before you have to incur any cost above your base /32, so that's still only $0.22 per customer
per year. Do you really think that most customers would be sensitive to a $0.25/year increase (<$0.03/month)
increase to their internet bill? I bet most of them wouldn't notice the difference between $19.95 and $19.98.

> So, the difference between offering /56's to home users and /48's to home users could be $14k per year.
> Looking at it a different way, for AUD 1,994, they could provide 2^24 /56's _or_ 2^16 /48's.
> 

Yes, look at the above math on the actual difference that would need sign-off. I bet the customers would
accept the difference.

Heck, even if you want to mark it up 10x, the worst case price increase is $2.50/year.

As such, I think that the cost argument doesn't really hold water.

> From your numbers -- 2^35 /48's out of 2^45 possible /48's allows for 10 bits of slack.
> 
> If we assume the address plan is hierarchical on nibble boundaries, then that may allow for 3 levels of hierarchy with 2/16ths or 3/16ths utilisation at each level.

Right… Also note that I think I allowed for a lot of unallocated space and slack by assuming a world population almost 3x the current population and then assuming that every individual represented a complete household and a complete business. In reality, the average is something like 4.5 people per household IIRC and a much larger multiplier for business end-sites.  We probably recover another whole nibble there.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 27 Feb 2013 14:22:41 +1100

In message <CA+OBy1PTovO5AaGuyAPnouL=5iw=[email-masked]>
, John Mann writes:
> If we assume the address plan is hierarchical on nibble boundaries,

Which is a bad assumption.  Nibble boundaries are there for rDNS.
The only place, generally, without enough clue to do non-nibble
boundaries in the DNS is the end customer delegation.  ISP's have
worked with non byte aligned delegations from RIRs for years.  These
is no reason to expect that this needs to change.

> then that may allow for 3 levels of hierarchy with 2/16ths or 3/16ths

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Owen DeLong <[email-masked]>
Date: Tue, 26 Feb 2013 20:00:39 -0800

That depends.

There is value to nibble-alignment of aggregation points where it makes sense and they are
(somewhat) supported in ARIN policy at this point.

Doing so does improve the human-factors aspects of network management and the space to do so is, generally, readily available at least at one or two levels of hierarchy.

Owen

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 27 Feb 2013 05:51:09 +0100 (CET)

On Tue, 26 Feb 2013, Owen DeLong wrote:

> However, there's zero benefit to issuing /60s, /56s, etc. vs. issuing 
> /48s.

When I say this to some people, they quote financial benefit because 
supposedly ARIN charges more money if they want more addresses.

---

From: John Curran <[email-masked]>
Date: Wed, 27 Feb 2013 13:32:32 +0800

On Feb 27, 2013, at 12:51 PM, Mikael Abrahamsson <[email-masked]> wrote:

>> However, there's zero benefit to issuing /60s, /56s, etc. vs. issuing /48s.
> 
> When I say this to some people, they quote financial benefit because supposedly ARIN charges more money if they want more addresses.

ARIN current fees are available here:
  <https://www.arin.net/fees/fee_schedule.html>

I will note that they go up at sub-linear rate, and while that does mean that 
an service provider that issues /48's (rather than /60s, /56's) to customers 
is more likely to bump a category, the cost per customer prefix drops very
quickly in higher fee categories.  We have a new fee schedule which has 
similar properties, and I'll use that one as the example as it is a uniform
step function: <https://www.arin.net/fees/pending_fee_schedule.html>
...
Small	$2,000	Larger than /36, up to and including /32 
               (means $.0305175/year per /48)
Medium	$4,000	Larger than /32, up to and including /28 
               (means $.0038146/year per /48)
Large	$8,000	Larger than /28, up to and including /24
               (means $.000476/year per /48)

Now obviously the utilization is going to be far less efficient, due to
sparse allocation, per-pop pools, etc, but the the claim that issuing
/48's to customers will increase your fees applies at most _once_ (due
to boundary condition) and then the next category change is only going
to occur due to some widely successful IPv6 customer growth by that ISP.

FYI,
/John

John Curran
President and CEO
ARIN

---

From: joel jaeggli <[email-masked]>
Date: Tue, 26 Feb 2013 21:47:48 -0800

> supposedly ARIN charges more money if they want more addresses.
the fee schedule is generally congruent with the ipv4 fee schedule until 
you need a prefix shorter than /22

A /22 is enough for 67 million /48s 17 billion /56s or 274 trillion /60s

---

From: David Conrad <[email-masked]>
Date: Tue, 26 Feb 2013 22:10:03 -0800

John,

>  <https://www.arin.net/fees/fee_schedule.html>

So, is this a commitment on the part of all RIRs to permanently fix the fees?  :)

More seriously, I think it would be a mistake to tailor protocol specs to take advantage of a particular RIR's fee schedule.

Regards,
-drc

---

From: Owen DeLong <[email-masked]>
Date: Tue, 26 Feb 2013 22:14:27 -0800

> So, is this a commitment on the part of all RIRs to permanently fix the fees?  :)

Rather it is an expression that the fees do not actually change meaningfully per subscriber as you move from /60 to /56 to /48.

> More seriously, I think it would be a mistake to tailor protocol specs to take advantage of a particular RIR's fee schedule.

True. However, it's also  a mistake to do stupid things to protocol specs just to save a few $$ in RIR fees.

Owen

---

From: Mark Andrews <[email-masked]>
Date: Wed, 27 Feb 2013 17:25:48 +1100

> More seriously, I think it would be a mistake to tailor protocol specs to take advantage of a particular RIR's fee schedule.

Whatever the rate is it is "chump change" per /48.

3c/annum out of $720.00 assuming $60/m.

.0041% of the cost is address rental from ARIN.
The ISP will be paying 1000x more to MC and Visa than this
just processing the payments.

---

From: Nathalie Trenaman <[email-masked]>
Date: Wed, 27 Feb 2013 13:12:12 +0100

> If you've seen someone stating an actual benefit (outside of "it covers for the bugs"), then please share... I really have literally missed it. If someone can show a truly valid reason for longer p…

This is why, in our IPv6 for LIRs courses, we spend an incredible amount of time getting people to understand the concepts of larger blocks and why they should assign them to customers. It is a hard struggle for people who are just starting with IPv6 to get their heads around this. Sometimes I have to explain the attendees that it is half a psychology course rather than a technical course ;). In the feedback we get after the courses, we can tell this is one of the hardest subjects for them to understand.....

Nathalie Trenaman
RIPE NCC Trainer

---

From: Philipp Kern <[email-masked]>
Date: Wed, 27 Feb 2013 14:14:29 +0100

Nathalie,

am Wed, Feb 27, 2013 at 01:12:12PM +0100 hast du folgendes geschrieben:
> This is why, in our IPv6 for LIRs courses, we spend an incredible amount of
> time getting people to understand the concepts of larger blocks and why they
> should assign them to customers. It is a hard struggle for people who are
> just starting with IPv6 to get their heads around this. Sometimes I have to
> explain the attendees that it is half a psychology course rather than a
> technical course ;). In the feedback we get after the courses, we can tell
> this is one of the hardest subjects for them to understand.....

are we talking about /48 here?

Kind regards
Philipp Kern

---

From: Nathalie Trenaman <[email-masked]>
Date: Wed, 27 Feb 2013 14:24:40 +0100

Philipp,

> are we talking about /48 here?

/48 for businesses, /48 or /52 or /56 for residentials.

Kind regards,

Nathalie Trenaman
RIPE NCC Trainer

---

From: Tim Chown <[email-masked]>
Date: Wed, 27 Feb 2013 13:56:15 +0000

> enabled broadband today, ~3%.

Congratulations, btw. That must be a large number when converted to real customers :)

The homenet architecture assumes a CPE rather than a single host. It discusses ISP allocations in section 3.4.1 of http://tools.ietf.org/html/draft-ietf-homenet-arch-07.  As that text is in WGLC, any comments on that section would be welcome (preferably on the homenet list).

Tim

---

From: Gert Doering <[email-masked]>
Date: Wed, 27 Feb 2013 19:19:08 +0100

Hi,

> http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=&ipv6=%2F24&action=Calculate

Ouch...

This is exactly the sort of incentive the RIRs should *not* give (and
we don't do that in RIPE land).

OTOH, I don't have an issue with "/56s to residential customers", as I'm 
still waiting for someone to explain to me why 256 subnets in the home 
is "too small".  /60 feels a bit too small, though.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Feb 2013 09:39:25 +1100

> > http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=&ipv6=%2F24&action=Calculat

3c/annum and 0.1c/annum per /48 respectively
 
> we don't do that in RIPE land).

or .01c/annum/56 and 0.1c/annum/48 assumuming you need 16M customer
allocations.   Both of those are less than the cost of getting the
ethernet address that the CPE vendor paid to the IEEE.

> is "too small".  /60 feels a bit too small, though.

Because it stiffles development.   When you have a people wearing
a couple of subnets each it doesn't take long to use up 256 subnets.
Today I have family and friends come over and grab a address
wirelessly.  It is not a long stretch to also have a prefix delegation
or two occur in the future at the same time.  256 is suddenly very
small.

Mark

---

From: Bill Jouris <[email-masked]>
Date: Thu, 28 Feb 2013 07:01:29 -0800 (PST)

It may be that, for some individuals, 256 subnets really is "very small".  But is that really anything like the norm?  Or likely to become the norm?

And for that minority who, like you, might be constrained, why couldn't they simply get a second 256?  It's not like we are looking at mandating a restriction on giving anyone more than a single allocation.

Bill Jouris
Inside Products, Inc.
www.insidethestack.com
831-659-8360
925-855-9512 (direct)

--- On Wed, 2/27/13, Mark Andrews <[email-masked]> wrote:

From: Mark Andrews <[email-masked]>
Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt
To: "Gert Doering" <[email-masked]>
Cc: [email-masked]
Date: Wednesday, February 27, 2013, 2:39 PM

 

Mark

---

From: "Ackermann, Michael" <[email-masked]>
Date: Thu, 28 Feb 2013 16:42:38 +0000

And not to mention 18 quintillion hosts, in each of those 256 subnets.

I hate to not be thinking "Long term" or "Out of the box", but that is certainly not small by today's standards!

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bill Jouris
Sent: Thursday, February 28, 2013 10:01 AM
To: Mark Andrews
Cc: [email-masked]
Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt

Bill Jouris
Inside Products, Inc.
www.insidethestack.com<http://www.insidethestack.com>
831-659-8360
925-855-9512 (direct)

--- On Wed, 2/27/13, Mark Andrews <[email-masked]<mailto:[email-masked]>> wrote:

From: Mark Andrews <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt
To: "Gert Doering" <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Date: Wednesday, February 27, 2013, 2:39 PM

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]</mc/compose?to=[email-masked]>
_______________________________________________
v6ops mailing list
[email-masked]</mc/compose?to=[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 28 Feb 2013 17:57:25 +0100 (CET)

> And not to mention 18 quintillion hosts, in each of those 256 subnets.

When I introduce people to IPv6 I tell them to stop thinking in terms of 
number of addresses and instead think of /64 per subnet. It's my opinion 
that the 2^64 addresses per subnet is irrelevant.

---

From: joel jaeggli <[email-masked]>
Date: Thu, 28 Feb 2013 09:07:17 -0800

On 2/28/13 8:57 AM, Mikael Abrahamsson wrote:
> When I introduce people to IPv6 I tell them to stop thinking in terms 
> of number of addresses and instead think of /64 per subnet. It's my 
> opinion that the 2^64 addresses per subnet is irrelevant.
The upper bound number of L2 adjacencies/nexthops that most of these 
devices are capable of handling on a subnet are on the order of 10^3 to 
10^5 so there are distinct scaling limits to subnet size that are 
consistent across v4/v6 and fact dual stack deployment dramatically 
reduces your capacity relative to one or the other.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Feb 2013 17:09:58 +0000

> that the 2^64 addresses per subnet is irrelevant.

It's liberating. You can imagine things that were impossible before.

   Brian

---

From: "Ackermann, Michael" <[email-masked]>
Date: Thu, 28 Feb 2013 17:21:43 +0000

Thanks Mikael.  Interesting!
We are new and just now preparing to deploy IPv6.   We are approaching the subnet and host address relationship in a similar fashion to what we have in V4.   That is, that a subnet might be a floor, quadrant, or small office, etc.,   and then some number of hosts within that subnet.   V6 just would give us much, much more of each and hence some more flexibility if/where needed.    

As such, the host addresses end up being the important and useable entity to us.   We can just have many more per interface, device, etc. and many more devices (mobile, lowpan, etc.).     Again, if needed.  

Of course the architectural capability is there to have many more hosts per subnet in v6, but I don't see that being exploited at all.   (at least by us).  

So ultimately our focus is on the actual host addresses more so than the associated subnets.   Is that the wrong approach for IPv6 in your view?   Should it be more of each device having it's own subnet?  

Thanks,

Mike

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Thursday, February 28, 2013 11:57 AM
To: Ackermann, Michael
Cc: [email-masked]
Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt

> And not to mention 18 quintillion hosts, in each of those 256 subnets.

When I introduce people to IPv6 I tell them to stop thinking in terms of number of addresses and instead think of /64 per subnet. It's my opinion that the 2^64 addresses per subnet is irrelevant.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 28 Feb 2013 18:44:44 +0100 (CET)

On Thu, 28 Feb 2013, Ackermann, Michael wrote:

> So ultimately our focus is on the actual host addresses more so than the 
> associated subnets.  Is that the wrong approach for IPv6 in your view? 
> Should it be more of each device having it's own subnet?

Keeping strict "one host per subnet" might be needed in some situations, 
but I'd say this is not the norm. It might make sense to have one subnet 
per customer or per service, or per cluster of servers or alike.

The important thing is to not think that there can be 2^64 hosts per 
subnet, as explained Joel Jaeggli this just doesn't work.

---

From: james woodyatt <[email-masked]>
Date: Thu, 28 Feb 2013 12:00:00 -0800

> It's liberating. You can imagine things that were impossible before.

Now imagine how liberating it would be if we still had consensus that one-/48-per-subscriber is a good idea.

Yes, most subscribers won't actually have more than one, or a handful of subnets, at any given point in time, but having a sufficiently large space from which to pull random subnet identifiers so that collisions are statistically unlikely would have been a valuable technical feature of IPv6, if only we had managed to retain the strategic foresight to keep it.

Oh well. Bygones.

--
james woodyatt <[email-masked]>
core os networking

---

From: Owen DeLong <[email-masked]>
Date: Thu, 28 Feb 2013 12:58:13 -0800

I think it is very likely to become the norm.

Giving out two allocations is exactly what we would prefer to avoid in IPv6 because that puts unnecessary growth into the routing table. It's far better to give everyone a /48 than to give a few (or eventually a lot) of people more than 1 /56.

Think of it this way:

10,000,000 households with /48s == 10,000,000 routes.
10,000,000 households with /56s and 10% need two /56s and 5% need 3 is 10,000,000+1,000,000+2(500,000) = 12,000,000 routes.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 28 Feb 2013 12:58:56 -0800

Counting hosts at all is IPv4-think.

It's about how many subnets you need, not how many hosts are on a subnet.

Owen

On Feb 28, 2013, at 8:42 AM, "Ackermann, Michael" <[email-masked]> wrote:

> I hate to not be thinking “Long term” or “Out of the box”, but that is certainly not small by today’s standards!  
>

---

From: "Brzozowski, John" <[email-masked]>
Date: Thu, 28 Feb 2013 21:54:00 +0000

>Not /60s and /56s vs. /48s.
We support all of the above on this list depending on the type of service
you have with the exception of /56s.  Stay tuned for some news on this
front soon, Comcast will then have this entire list covered.

---

From: "Brzozowski, John" <[email-masked]>
Date: Thu, 28 Feb 2013 22:21:02 +0000

In general I agree that is not desirable to delegate multiple prefixes for
typical Internet access.  However, operators may choose to delegated more
than one prefix and if this were to be the case it does not necessarily
mean that the routing table will grow for everyone, it may impact the
specific provider.

I never agreed with a /48 for everyone is better and I still do not.
Different strokes for different folks, one size does not fit all here.

John

-----Original Message-----
From: Owen DeLong <[email-masked]>
Date: Thursday, February 28, 2013 12:58 PM
To: Bill Jouris <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt

>Giving out two allocations is exactly what we would prefer to avoid in
>IPv6 because that puts unnecessary growth into the routing table. It's
>far better to give everyone a /48 than to give a few (or eventually a
>lot) of people more than 1 /56.
>
>
>Think of it this way:
>
>
>10,000,000 households with /56s and 10% need two /56s and 5% need 3 is
>10,000,000+1,000,000+2(500,000) = 12,000,000 routes.
>
>
>Owen
>
>It may be that, for some individuals, 256 subnets really is "very small".
> But is that really anything like the norm?  Or likely to become the norm?
>
>And for that minority who, like you, might be constrained, why couldn't
>they simply get a second 256?  It's not like we are looking at mandating
>a restriction on giving anyone more than a single allocation.
>
>Bill Jouris
>Inside Products, Inc.
>www.insidethestack.com <http://www.insidethestack.com>
>831-659-8360
>925-855-9512 (direct)
>
>
>
>In message <[email-masked]
><x-msg://14317/mc/compose?to=[email-masked]>>, Gert
>Doering writes:
>> Hi,
>> 
>http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=&ipv6=%2F32&action=Calcula
>t 
><http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=&ipv6=%2F32&action=Calcul
>at>
>> e
>http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=&ipv6=%2F24&action=Calcula
>t 
><http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=&ipv6=%2F24&action=Calcul
>at>
>> e
>> 
>> Ouch...
>
>PHONE: +61 2 9871 4742                 INTERNET:
>[email-masked] <x-msg://14317/mc/compose?to=[email-masked]>
>[email-masked] <x-msg://14317/mc/compose?to=[email-masked]>

---

From: joel jaeggli <[email-masked]>
Date: Thu, 28 Feb 2013 16:21:50 -0800

> 10,000,000+1,000,000+2(500,000) = 12,000,000 routes.
sticking with the residential case,

If for 10,000,000 customers I have pops (or aggregation devices) with 
10,000 households aggregated  behind them then, I have 1000 pop routes 
in the backbone and 10-12,000 customer routes in a pop or aggregation 
device.

being generous to allow for growth it could be double that and it's 
still not really a big deal on the sort of hardware that can do dhcp-pd 
for 10,000 cutomers today.
>
> Owen
>
> On Feb 28, 2013, at 7:01 AM, Bill Jouris 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> It may be that, for some individuals, 256 subnets really is "very 
>> small".  But is that really anything like the norm?  Or likely to 
>> become the norm?
>>
>> And for that minority who, like you, might be constrained, why 
>> couldn't they simply get a second 256?  It's not like we are looking 
>> at mandating a restriction on giving anyone more than a single 
>> allocation.
>>
>> Bill Jouris
>> Inside Products, Inc.
>> --- On *Wed, 2/27/13, Mark Andrews /<[email-masked] 
>> <mailto:[email-masked]>>/* wrote:
>>
>>
>>     From: Mark Andrews <[email-masked] <mailto:[email-masked]>>
>>     To: "Gert Doering" <[email-masked] <mailto:[email-masked]>>
>>     Cc: [email-masked] <mailto:[email-masked]>
>>     <x-msg://14317/mc/compose?to=[email-masked]>>,
>>     Gert Doering writes:
>>     > Hi,
>>     >
>>     <x-msg://14317/mc/compose?to=[email-masked]>
>> [email-masked] <mailto:[email-masked]>