Mailing List Archive: nsp: ipv6

Current Consensus on IPv6 Customer Allocation Size

1 2

View All

Index | Next | Previous | View Threaded

mch-v6ops at xs4all

Aug 2, 2012, 2:19 AM

Post #26 of 44 (733 views)
Permalink

Re: Current Consensus on IPv6 Customer Allocation Size [In reply to]

> I have read through multiple threads regarding this issue (though most of them are years old), and know it may be a can of worms, but I need some insight into what people are actually doing in 2012. ARIN "suggests" a /48 for all customers or sites as far as I can tell, though apparently in the past they also had language including /56 assignments in some docs. I'm trying to come up with a reasonable numbering plan that can accommodate /48 customer assignments from our /32.

The RIPE Database contains a bit of a hint on what people do in an attribute called "assignment-size". A quick, not very sophisticated, unix one liner on last night's dump gives the following distribution:

149 assignment-size: 48
10 assignment-size: 49
3 assignment-size: 52
2 assignment-size: 54
463 assignment-size: 56
13 assignment-size: 60
171 assignment-size: 64

Mind you, these are only a subset of the total amount of IPv6 assignments. The attribute is only mandatory when using the "AGGREGATED-BY-LIR" status to group large numbers of smaller assignments in one database object. Fair chance these are mostly broadband pools (or tunnels), but can't say for sure without going over all the descriptions.

Anyways, it looks like /56 is pretty popular followed by an almost even number of /48 and /64 assignments.

If there is interest, I can have a chat internally to see if we can come up with some more and better analysis of the numbers, possibly a nice topic for RIPE 65.

Marco
(full disclosure: RIPE NCC employee, co-chair of the RIPE IPv6 WG and "inventor" of the assignment-size attribute)

mch-v6ops at xs4all

Aug 2, 2012, 2:35 AM

Post #27 of 44 (730 views)
Permalink

Re: Current Consensus on IPv6 Customer Allocation Size [In reply to]

> "4 bits for home subnetting should be more than enough"
> - any takers?

Can I already pre-order the shirt somewhere?

Marco :)

mch-v6ops at xs4all

Aug 2, 2012, 2:41 AM

Post #28 of 44 (736 views)
Permalink

Re: Current Consensus on IPv6 Customer Allocation Size [In reply to]

> However, as you correctly point out Mark, hand a user a /48 and they're
> lost.

Surfnet (the Dutch NREN) wrote a nice little document on what to do with your /48 assignment. Not exactly aimed at residential users, but for b2b it might be helpful. The RIPE NCC translated it (with permission) and it is available on the website:

http://www.ripe.net/lir-services/training/material/IPv6-for-LIRs-Training-Course/IPv6_addr_plan4.pdf

HTH,

Marco

swmike at swm

Aug 2, 2012, 3:31 AM

Post #29 of 44 (736 views)
Permalink

Re: Current Consensus on IPv6 Customer Allocation Size [In reply to]

On Thu, 2 Aug 2012, Mark Blackman wrote:

> They're going to need a much bigger IPv6 allocation to give all ~2^26
> customers a /48 allocation, and they can't even quite give them all a
> /56 out of their current allocation.

It gets interesting if every mobile device should get a /48 as well, then
we're going to be spending a /14 on this (2^34 is 16G, 48-34=14.

Question, with growth and room for efficient routing, I'd imagine people
will need to start talking to their RIR to get larger subnets. Will the
RIRs accept these calculations and approve these sizes?

--
Mikael Abrahamsson email: swmike [at] swm

sander at steffann

Aug 2, 2012, 3:35 AM

Post #30 of 44 (730 views)
Permalink

Re: Current Consensus on IPv6 Customer Allocation Size [In reply to]

Hi Doug,

> Evidence please.
>
> I think (and no, I don't have hard facts here either, just experience)
> that the vast majority of home users have 1 network device, and could
> live quite happily with 1 v6 subnet.
>
> The people who buy, and use, multiple routers at the same time are us. :)

Unfortunately with IPv4 I have seen many cases where people buy routers with wireless interfaces instead of (layer-2) wireless access points. Usually because the routers are cheaper and easier to get. They then plug the WAN port of the second router into one of the LAN ports of the first router and do NAT twice. With IPv4 this usually works well enough for them.

I agree that this is an ugly solution and not a well-designed network, but these are just home users who plug devices together until it seems to work :-)

- Sander

gert at space

Aug 2, 2012, 3:44 AM

Post #31 of 44 (735 views)
Permalink

Re: Current Consensus on IPv6 Customer Allocation Size [In reply to]

Hi,

On Thu, Aug 02, 2012 at 12:31:19PM +0200, Mikael Abrahamsson wrote:
> On Thu, 2 Aug 2012, Mark Blackman wrote:
>
> > They're going to need a much bigger IPv6 allocation to give all ~2^26
> > customers a /48 allocation, and they can't even quite give them all a
> > /56 out of their current allocation.
>
> It gets interesting if every mobile device should get a /48 as well, then
> we're going to be spending a /14 on this (2^34 is 16G, 48-34=14.

Something tells me that you're not having 16 *billion* customers, but
more like 16 *million*. Right? That's 2^24, plus some :-) -> /24-ish
needed to give out /48s

I'm not sure I expect to see /48 (or /56, for that matter) on any
internet-enabled mobile device, though. Most of them will be happy
with a /64, as that's sufficient for providing WiFi access to your
Laptop... only "mobile routers" (like, LTE based connectivity for your
SoHo network, as an alternative to cable/dsl) will send DHCP-PD
requests with a bigger request size... but that's crystal balling,
of course.

> Question, with growth and room for efficient routing, I'd imagine people
> will need to start talking to their RIR to get larger subnets. Will the
> RIRs accept these calculations and approve these sizes?

The RIPE NCC will generally do so, if the calculations make sense. Up to
a /29 can be had without any calculations[*], just by asking for it - so
if you really need more, be prepared to have good numbers :-)

(*) and existing /32s can be extended up to a /29 by "just asking for it".

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

brian.e.carpenter at gmail

Aug 2, 2012, 3:49 AM

Post #32 of 44 (732 views)
Permalink

Re: Current Consensus on IPv6 Customer Allocation Size [In reply to]

Tim,

Just to underline this: please destroy your copy of RFC 3177 and read
RFC 6177 carefully. I say this as one of the people who drafted 3177.

That said, I think I will be happy at home when I get a /56, and it
might do for a small business, but any customer already known to subnet
in IPv4 should probably get a /48.

Regards
Brian Carpenter

On 01/08/2012 23:22, SM wrote:
> At 12:17 PM 8/1/2012, Tim Densmore wrote:
>> Is the current (again, 2012 - most threads and books that I have read
>> are al least a few years old) consensus that a /48
>> per-residential-user really justified? Opinions or pointers to
>> current Fine Manuals to read would be most appreciated.
>
> RFC 6177 clarifies the /48 recommendation. The Fine Manuals won't
> really explain why it has been argued that residential users should be
> given a /56.
>
> Justification is appropriate if you are dealing with a scare resource.
> There is a management overhead in dealing with that. It is easier to
> hand out ample address space so that people can do what they want
> without having to come back to you for additional address space. A /48
> keeps it simple.
>
> Regards,
> -sm
> .
>

swmike at swm

Aug 2, 2012, 3:56 AM

Post #33 of 44 (740 views)
Permalink

Re: Current Consensus on IPv6 Customer Allocation Size [In reply to]

On Thu, 2 Aug 2012, Gert Doering wrote:

> Hi,
>
> On Thu, Aug 02, 2012 at 12:31:19PM +0200, Mikael Abrahamsson wrote:
>> On Thu, 2 Aug 2012, Mark Blackman wrote:
>>
>>> They're going to need a much bigger IPv6 allocation to give all ~2^26
>>> customers a /48 allocation, and they can't even quite give them all a
>>> /56 out of their current allocation.
>>
>> It gets interesting if every mobile device should get a /48 as well, then
>> we're going to be spending a /14 on this (2^34 is 16G, 48-34=14.
>
> Something tells me that you're not having 16 *billion* customers, but
> more like 16 *million*. Right? That's 2^24, plus some :-) -> /24-ish
> needed to give out /48s

Well, I intended "the world as a whole", with each person having 1-2
mobile devices. I was unclear. I tried to make a point that this is
definitely possible to hand out /48 to everything, but are RIRs ready for
such requests?

--
Mikael Abrahamsson email: swmike [at] swm

sesse at google

Aug 2, 2012, 4:04 AM

Post #34 of 44 (734 views)
Permalink

Re: Current Consensus on IPv6 Customer Allocation Size [In reply to]

2012/8/2 Sander Steffann <sander [at] steffann>:
> Unfortunately with IPv4 I have seen many cases where people buy routers with wireless interfaces instead of (layer-2) wireless access points. Usually because the routers are cheaper and easier to get. They then plug the WAN port of the second router into one of the LAN ports of the first router and do NAT twice. With IPv4 this usually works well enough for them.

It's anecdotal evidence, but I also see this a lot; two or even three
layers of NAT is not uncommon.

/* Steinar */
--
Software Engineer, Google Switzerland

gert at space

Aug 2, 2012, 5:36 AM

Post #35 of 44 (736 views)
Permalink

Re: Current Consensus on IPv6 Customer Allocation Size [In reply to]

Hi,

On Thu, Aug 02, 2012 at 12:56:16PM +0200, Mikael Abrahamsson wrote:
> > Something tells me that you're not having 16 *billion* customers, but
> > more like 16 *million*. Right? That's 2^24, plus some :-) -> /24-ish
> > needed to give out /48s
>
> Well, I intended "the world as a whole", with each person having 1-2
> mobile devices. I was unclear. I tried to make a point that this is
> definitely possible to hand out /48 to everything,

True. My calculation for this sort of came from the other end - in
FP001, we have 45 bits to number /48, and that will give a 1000 /48s
"to every human earth can sustain".

OTOH, we'll not be able to tightly fill allocations, so it might *not*
actually work out nicely in the end - and that, I think, prompted
Geoff Huston to change the RIPE policies to move away from "a /48 for
every end site" (if subnetting is wanted) to something more flexible.

> but are RIRs ready for such requests?

Well, the RIRs today hold a /12 each, so there's some space to be given
out... and more /12s are sitting in IANA's storage.

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

dr at cluenet

Aug 2, 2012, 5:56 AM

Post #36 of 44 (731 views)
Permalink

Re: Current Consensus on IPv6 Customer Allocation Size [In reply to]

On Thu, Aug 02, 2012 at 12:31:19PM +0200, Mikael Abrahamsson wrote:
> Question, with growth and room for efficient routing, I'd imagine people
> will need to start talking to their RIR to get larger subnets. Will the
> RIRs accept these calculations and approve these sizes?

Unfortunately, at least RIPE NCC doesn't care about long-term planning
in IPv6. They (as I was told) care only about approx 2 years window. So
the addressing plan you have to present when asking for more than /32
(now more than /29) may only cover two years. And then you are supposed
to come back, ask for more and prove that you fulfil the draconic
HD-ratio of 0.94, which basically means around 1/3 of your allocation
fully utilized.

There is a big disconnect between real needs and policy for certain
larger scale residential ISPs today, if you actually want to leverage
operational advantages of IPv6 (read: having more bits for nice
addressing and aggregation schemes).

Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr [at] cluenet -- dr [at] IRCne -- PGP: 0xA85C8AA0

tdensmore at tarpit

Aug 2, 2012, 8:37 AM

Post #37 of 44 (728 views)
Permalink

Re: Current Consensus on IPv6 Customer Allocation Size [In reply to]

On 8/2/2012 12:30 AM, Mikael Abrahamsson wrote:
> On Wed, 1 Aug 2012, Tim Densmore wrote:
>
>> trying to come up with a reasonable numbering plan that can
>> accommodate /48 customer assignments from our /32.
>
> First of all, /32 is the default allocation you get without
> justification, right. So if you justify, you will get more. Do a
> proper justification now, not in 3 years, so you're on the right track
> by trying to find out.
>
> If you want a big subnet, planning to hand out /48 to everybody will
> give you a lot of addresses, increasing flexibility down the road.

Hi Mikael,

Based on my conversations with ARIN, my understanding is this -
currently ARIN usually only assigns two sizes of subnet which are /28
and /32. They will not allocate outside of a nibble boundary. They have
a fee schedule for multiple sizes of ORGs, but in reality are only
allocating "small" and "large." In our case, we would qualify as a
"medium" ORG so were offered the option of either allocation. The /32
came with no additional yearly dollar cost. The /28 would have been a
substantial increase in our yearly ARIN fees (something like $6k, but
that's based on memory, and might be inaccurate). This was not on the
table in my case.

Regardless of whether IPv6 is something that will be an absolute
requirement down the road, currently it's not something that's going to
generate any revenue (the majority of our agg gear and CPE don't have
any notion at all of IPv6), and with multiple other projects waiting for
funding which actually will be revenue generating, well, I'm guessing
you get the picture. I didn't push, but even personally, I'd rather
spend the ARIN fees on new gear, upgrades to pipes, etc.

Either way, thank you very much for your POV. Hopefully you understand
my POV. FWIW, I'm leaning towards the same sizes you (and a few others)
have discussed - /48 for biz/big/requesting customers, and sparsely
allocated /56 for residential.

TD

tdensmore at tarpit

Aug 2, 2012, 8:55 AM

Post #38 of 44 (730 views)
Permalink

Re: Current Consensus on IPv6 Customer Allocation Size [In reply to]

On 8/2/2012 4:49 AM, Brian E Carpenter wrote:
> Tim,
>
> Just to underline this: please destroy your copy of RFC 3177 and read
> RFC 6177 carefully. I say this as one of the people who drafted 3177.

Thanks. I missed the "obsoleted by" line at the top of the RCF page
when scraping the net for IPv6 allocation size arguments. I'll give
6177 a read.

TD

tdensmore at tarpit

Aug 2, 2012, 9:29 AM

Post #39 of 44 (737 views)
Permalink

Re: Current Consensus on IPv6 Customer Allocation Size [In reply to]

On 8/2/2012 6:56 AM, Daniel Roesen wrote:
> There is a big disconnect between real needs and policy for certain
> larger scale residential ISPs today, if you actually want to leverage
> operational advantages of IPv6 (read: having more bits for nice
> addressing and aggregation schemes).

Hi Daniel,

This point really hit the nail on the head (though we'er certainly not
"larger scale"), and is really the main reason for my concern. BCP seems
to dictate that we subnet at nibble boundaries and assign the smallest
POP the same block size as the largest. This is obviously an
inefficient use of resources, but it does make for a much cleaner and
more easily understood routing table. It seems unlikely that I'll be
able to summarize in IGP shorter than /40s in any case (based on current
network topology), and I've read some arguments that this is a good
reason to simply use /40 as a starting point, since it also allows for
fewer idle subnets at smaller POPs and does away with my concern that
I'd eventually run out of /48s in some POPs. I'd rather follow the /32
=> /36 => /40 scheme for my core/agg network, though. Still mulling it
over.

Thanks for your input!

TD

cloos at jhcloos

Aug 31, 2012, 12:10 PM

Post #40 of 44 (549 views)
Permalink

Re: Current Consensus on IPv6 Customer Allocation Size [In reply to]

>>>>> "MB" == Mark Blackman <mark [at] exonetric> writes:

MB> More than 256 subnets in the home? Who would want to manage all of that?

Don't be surprized to see (ether-)? peripheral lans hanging off general-purpose
boxen, each needing its own /64.

We also may end up with clusters-in-a-box replacing existing nodes;
they'll need /64s for their internal lans.

Virtual lans, conencting VMs w/in a node, could consume /64s, too.

65536 may be extreme, but I certainly see 257+ showing up.

-JimC
--
James Cloos <cloos [at] jhcloos> OpenPGP: 1024D/ED7DAEA6

farmer at umn

Aug 31, 2012, 12:43 PM

Post #41 of 44 (543 views)
Permalink

Re: Current Consensus on IPv6 Customer Allocation Size [In reply to]

The reall issue isn't how many subnets, and your right no one wants to
manage them.

So, If we can agree there is some likely hood of more than one subnet,
then the question is how many bit do you need for a algorithmic
allocation scheme for the devices to automatically pick their subnets.
Eight bits is more than enough for a human to manage putting all the
subnets of almost any house in. But, we just said no one want to manage
it. So eight bits is kind of small for algorithmic scheme that would
cover +95% of the possibilities. Its a lot tougher problem than most
people relise, it doesn't seem like it should be but it is. There is a
lot just wired into our brains, that makes it easy for a human to adapt
to the conditions, but algorithmic approches frequently aren't all that
adaptable.

On 8/31/12 14:10 CDT, James Cloos wrote:
>>>>>> "MB" == Mark Blackman <mark [at] exonetric> writes:
>
> MB> More than 256 subnets in the home? Who would want to manage all of that?
>
> Don't be surprized to see (ether-)? peripheral lans hanging off general-purpose
> boxen, each needing its own /64.
>
> We also may end up with clusters-in-a-box replacing existing nodes;
> they'll need /64s for their internal lans.
>
> Virtual lans, conencting VMs w/in a node, could consume /64s, too.
>
> 65536 may be extreme, but I certainly see 257+ showing up.
>
> -JimC
>

--
===============================================
David Farmer Email:farmer [at] umn
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815
Minneapolis, MN 55414-3029 Cell: 612-812-9952
===============================================

evyncke at cisco

Aug 31, 2012, 11:00 PM

Post #42 of 44 (546 views)
Permalink

RE: Current Consensus on IPv6 Customer Allocation Size [In reply to]

This is work in progress at the IETF: homenet working group. A lot of interesting ideas to have a multi-homed set of IPV6 networks, handling security & naming & service discovery.

All of this for 'Uncle Joe' who has no clue about what a DMZ is ;-)

-�ric

> -----Original Message-----
> From: ipv6-ops-bounces+evyncke=cisco.com [at] lists [mailto:ipv6-ops-
> bounces+evyncke=cisco.com [at] lists] On Behalf Of David Farmer
> Sent: vendredi 31 ao�t 2012 21:44
> To: James Cloos
> Cc: David Farmer; Tim Densmore; Chris Grundemann; IPv6 operators forum;
> Mark Blackman
> Subject: Re: Current Consensus on IPv6 Customer Allocation Size
>
> The reall issue isn't how many subnets, and your right no one wants to
> manage them.
>
> So, If we can agree there is some likely hood of more than one subnet, then
> the question is how many bit do you need for a algorithmic allocation
> scheme for the devices to automatically pick their subnets.
> Eight bits is more than enough for a human to manage putting all the
> subnets of almost any house in. But, we just said no one want to manage
> it. So eight bits is kind of small for algorithmic scheme that would cover
> +95% of the possibilities. Its a lot tougher problem than most people
> relise, it doesn't seem like it should be but it is. There is a lot just
> wired into our brains, that makes it easy for a human to adapt to the
> conditions, but algorithmic approches frequently aren't all that adaptable.
>
>
> On 8/31/12 14:10 CDT, James Cloos wrote:
> >>>>>> "MB" == Mark Blackman <mark [at] exonetric> writes:
> >
> > MB> More than 256 subnets in the home? Who would want to manage all of
> that?
> >
> > Don't be surprized to see (ether-)? peripheral lans hanging off
> > general-purpose boxen, each needing its own /64.
> >
> > We also may end up with clusters-in-a-box replacing existing nodes;
> > they'll need /64s for their internal lans.
> >
> > Virtual lans, conencting VMs w/in a node, could consume /64s, too.
> >
> > 65536 may be extreme, but I certainly see 257+ showing up.
> >
> > -JimC
> >
>
> --
> ===============================================
> David Farmer Email:farmer [at] umn
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE Phone: 612-626-0815
> Minneapolis, MN 55414-3029 Cell: 612-812-9952
> ===============================================

michael at rancid

Sep 4, 2012, 11:13 AM

Post #43 of 44 (547 views)
Permalink

Re: Current Consensus on IPv6 Customer Allocation Size [In reply to]

On 8/2/12 2:07 AM, Mark Blackman wrote:

> Comcast's only allocation that I can see is a /31,
> http://whois.arin.net/rest/net/NET6-2001-558-1.html

"that I can see" is the operative phrase.

In addition to the /31 that you can see (which is actually a /29),
Comcast also has a /28 (2601::/28). There may be more, but that's what
they're actually announcing now.

michael

jima at jima

Sep 5, 2012, 5:58 AM

Post #44 of 44 (551 views)
Permalink

Re: Current Consensus on IPv6 Customer Allocation Size [In reply to]

On 2012-09-04 12:13, Michael Sinatra wrote:
> On 8/2/12 2:07 AM, Mark Blackman wrote:
>
>> Comcast's only allocation that I can see is a /31,
>> http://whois.arin.net/rest/net/NET6-2001-558-1.html
>
> "that I can see" is the operative phrase.
>
> In addition to the /31 that you can see (which is actually a /29),
> Comcast also has a /28 (2601::/28). There may be more, but that's what
> they're actually announcing now.

Just clicking around the links (sorry ARIN!), I also found
http://whois.arin.net/rest/net/NET6-2001-55A-1.html -- basically another
3 /31s. Who'd have thought big business would have so many IP blocks!

They also appear to be announcing 2600:1403:0008::/48 -- a chunk off
Akamai's ARIN-based /27, it would seem.

Jima

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads