On 9/24/13 6:47 AM, Otis L. Surratt, Jr. wrote:

-----Original Message----- From: Nathanael C. Cariaga [mailto:nccariaga@stluke.com.ph] Sent: Tuesday, September 24, 2013 8:50 AM To: NANOG Mailing List Subject: minimum IPv6 announcement size

...

Hi,

Just wondering if anyone could shed light on my concern.....

I've been Google-ing about if there is such a standard that sets the minimum IPv6 advertisement on BGP. My concern is that I am running a network that is operating on multiple sites and currently rolling >out our IPv6 on the perimeter level. Having to get our /48 allocation from our RIR, I figured out I would it would be best for us to break down the /48 into smaller chunks (i.e /56s) and farm it out to our sites since a single /48 will be very big for our single site.

Your RIR ought to make a minimum allocation based on the number of sites you need to deploy to, so something shorter than a /48. clearly you should aim for the highest acheiveable aggregation but that's not always possible. the fact that it is "large for your site" isn't germain to the discussion of what's the minimally accepted size prefix.

...

Any advise will be very much appreciated.

Regards,

-- -nathan

Minimum announcement for IPv6 as I recall is /48. Some providers might accept less for their networks.

I've seen providers accept longer but not propigate them. we apply filters at the /48 level, That appears to be sufficiently common that it confers herd immunity to shorter prefixes.

-Otis

On Sep 24, 2013, at 11:00 AM, Randy Bush <randy@psg.com> wrote:

...

I am running a network that is operating on multiple sites and currently rolling out our IPv6 on the perimeter level. Having to get our /48 allocation from our RIR

excuse, but which rir handed out a /48 under which policy?

randy

ARIN will give out /48s to end users. AfriNIC will give out /48s to end users. I believe (but haven't verified) that this is also possible from APNIC and LACNIC. Someone else mentioned that RIPE will as well. Owen

Hi, I raised actually this concern during our IP resource application. On a personal note, I think /48 IPv6 allocation is more than enough for our organization to use for at least the next 5-10 years assuming that this can be farmed out to our multiple sites. What makes this complicated for us is that we are operating on a multiple sites (geographically) with each site is doing multi-homing and having a /48 in each site would be very big waste of IP resources. -nathan On 9/25/2013 2:36 AM, Bryan Socha wrote:

Everyone is following the same policies. a /48 PER SITE. did you request enough addresses from your RIR?

Bryan Socha

On Wed, 25 Sep 2013, Nathanael C. Cariaga wrote:

doing multi-homing and having a /48 in each site would be very big waste of IP resources.

IPv6 was designed with an expectation of having /48 per geographical site and this is perfectly fine. I have a /48 at home. What is more of a concern is to do aggregation in the DFZ, if every size got itself a /48 PI and announced it in the DFZ then the routing system would not be very happy... -- Mikael Abrahamsson email: swmike@swm.pp.se

Each site should get at least a /48. Stop worrying about dense-packing the IP space in IPv6. This is IPv4-think. IPv6 is intended to be sparsely allocated. Owen On Sep 24, 2013, at 8:10 PM, Nathanael C. Cariaga <nccariaga@stluke.com.ph> wrote:

Hi,

I raised actually this concern during our IP resource application.

On a personal note, I think /48 IPv6 allocation is more than enough for our organization to use for at least the next 5-10 years assuming that this can be farmed out to our multiple sites. What makes this complicated for us is that we are operating on a multiple sites (geographically) with each site is doing multi-homing and having a /48 in each site would be very big waste of IP resources.

-nathan

On 9/25/2013 2:36 AM, Bryan Socha wrote:

...

Everyone is following the same policies. a /48 PER SITE. did you request enough addresses from your RIR?

Bryan Socha

On 2013-09-26 08:52, bmanning@vacation.karoshi.com wrote:

sounds just like folks in 1985, talking about IPv4...

Yeah, but who doesn't run CIDR now? Get everyone in the IPv6 pool now; we'll inevitably add hacks later....

On 9/26/2013 1:52 AM, bmanning@vacation.karoshi.com wrote:

sounds just like folks in 1985, talking about IPv4...

The foundation of that, though, was ignorance of address space exhaustion. IPv4's address space was too small for such large thinking. IPv6 is far beyond enough to use such allocation policies.

On 9/26/2013 1:07 PM, joel jaeggli wrote:

On Sep 26, 2013, at 12:29 PM, Darren Pilgrim <nanog@bitfreak.org> wrote:

...

On 9/26/2013 1:52 AM, bmanning@vacation.karoshi.com wrote:

...

sounds just like folks in 1985, talking about IPv4...

The foundation of that, though, was ignorance of address space exhaustion. IPv4's address space was too small for such large thinking.

The first dicussion I could find about ipv4 runnout in email archives is circa 1983

...

IPv6 is far beyond enough to use such allocation policies.

There are certain tendencies towards profligacy that might prematurely influence the question of ipv6 exhaustion and we should be on guard against them… allocating enough /48s as part of direct assignments is probably not one of them.

That's just it, I really don't think we actually have an exhaustion risk with IPv6. IPv6 is massive beyond massive. Let me explain. We have this idea of the "/64 boundary". All those nifty automatic addressing things rely on it. We now have two generations of hardware and software that would more or less break if we did away with it. In essence, we've translated an IPv4 /32 into an IPv6 /64. Not great, but still quite large. Current science says Earth can support ten billion humans. If we let the humans proliferate to three times the theoretical upper limit for Earth's population, a /64 for each human would be at about a /35's worth of /64's. If we're generous with Earth's carrying capacity, a /36. If we handed out /48's instead so each human could give a /64 to each of their devices, it would all fit in a single /52. Those /48's would number existance at a rate of one /64 per human, one /64 per device, and a 65535:1 device:human ratio. That means we could allocate 4000::/3 just for Earth humans and devices and never need another block for that purpose. That's assuming a very high utilisation ratio, of course, but really no worse than IPv4 is currently. The problem isn't allocation density, but router hardware. We need room for route aggregation and other means of compartmentalisation. Is a 10% utilisation rate sparse enough? At 10% utilisation, keeping the allocations to just 4000::/3, we'd need less than a single /60 for all those /48's. If 10% isn't enough, we can go quite a bit farther: - 1% utilisation would fit all those /48's into a /62. - A full /64 of those /48's would be 0.2% utilisation. - 0.1%? We'd have to steal a bit and hand out /47's instead. - /47 is ugly. At /52, we'd get .024% (one per 4096). That's while maintaining a practice of one /64 per human or device with 65535 devices per human. Introduce one /64 per subnet and sub-ppm utilisation is possible. That would be giving a site a /44 and them only ever using the ::/64 of it. Even with sloppy, sparse allocation policies and allowing limitless human and device population growth, we very likely can not exhaust IPv6.

On Sep 26, 2013, at 1:18 PM, Darren Pilgrim <nanog@bitfreak.org> wrote:

On 9/26/2013 1:07 PM, joel jaeggli wrote:

...

On Sep 26, 2013, at 12:29 PM, Darren Pilgrim <nanog@bitfreak.org> wrote:

...

On 9/26/2013 1:52 AM, bmanning@vacation.karoshi.com wrote:

...

sounds just like folks in 1985, talking about IPv4...

The foundation of that, though, was ignorance of address space exhaustion. IPv4's address space was too small for such large thinking.

The first dicussion I could find about ipv4 runnout in email archives is circa 1983

...

IPv6 is far beyond enough to use such allocation policies.

There are certain tendencies towards profligacy that might prematurely influence the question of ipv6 exhaustion and we should be on guard against them… allocating enough /48s as part of direct assignments is probably not one of them.

That's just it, I really don't think we actually have an exhaustion risk with IPv6. IPv6 is massive beyond massive. Let me explain.

Instead of explaining to me how awesomely big ipv6 is you might figure out who you're talking to, or maybe consider the problem a bit more. Semantic addressing schemes can soak up as many bits as you're willing to give them. ISP(s) using (for example) 6rd or other automatic prefix mapping mechanisms can potentially use rather large prefixes. 128 bits is not so many that we can't trivially soak them all up and we should not pretend otherwise. We are stewards of the resource and we should manage it with care that reflect's long term thinking, both so that allocations we make now are not inappropriately small in the future and such that we are not again confronting the shortcomings of our decision-making again in 20 years.

We have this idea of the "/64 boundary". All those nifty automatic addressing things rely on it. We now have two generations of hardware and software that would more or less break if we did away with it. In essence, we've translated an IPv4 /32 into an IPv6 /64. Not great, but still quite large.

Current science says Earth can support ten billion humans. If we let the humans proliferate to three times the theoretical upper limit for Earth's population, a /64 for each human would be at about a /35's worth of /64's. If we're generous with Earth's carrying capacity, a /36.

If we handed out /48's instead so each human could give a /64 to each of their devices, it would all fit in a single /52. Those /48's would number existance at a rate of one /64 per human, one /64 per device, and a 65535:1 device:human ratio. That means we could allocate 4000::/3 just for Earth humans and devices and never need another block for that purpose.

That's assuming a very high utilisation ratio, of course, but really no worse than IPv4 is currently. The problem isn't allocation density, but router hardware. We need room for route aggregation and other means of compartmentalisation. Is a 10% utilisation rate sparse enough? At 10% utilisation, keeping the allocations to just 4000::/3, we'd need less than a single /60 for all those /48's. If 10% isn't enough, we can go quite a bit farther:

- 1% utilisation would fit all those /48's into a /62. - A full /64 of those /48's would be 0.2% utilisation. - 0.1%? We'd have to steal a bit and hand out /47's instead. - /47 is ugly. At /52, we'd get .024% (one per 4096).

That's while maintaining a practice of one /64 per human or device with 65535 devices per human. Introduce one /64 per subnet and sub-ppm utilisation is possible. That would be giving a site a /44 and them only ever using the ::/64 of it.

Even with sloppy, sparse allocation policies and allowing limitless human and device population growth, we very likely can not exhaust IPv6.

On Sep 26, 2013, at 13:18 , Darren Pilgrim <nanog@bitfreak.org> wrote:

On 9/26/2013 1:07 PM, joel jaeggli wrote:

...

On Sep 26, 2013, at 12:29 PM, Darren Pilgrim <nanog@bitfreak.org> wrote:

...

On 9/26/2013 1:52 AM, bmanning@vacation.karoshi.com wrote:

...

sounds just like folks in 1985, talking about IPv4...

The foundation of that, though, was ignorance of address space exhaustion. IPv4's address space was too small for such large thinking.

The first dicussion I could find about ipv4 runnout in email archives is circa 1983

...

IPv6 is far beyond enough to use such allocation policies.

There are certain tendencies towards profligacy that might prematurely influence the question of ipv6 exhaustion and we should be on guard against them… allocating enough /48s as part of direct assignments is probably not one of them.

That's just it, I really don't think we actually have an exhaustion risk with IPv6. IPv6 is massive beyond massive. Let me explain.

There are some (bizarre) ideas for using IPv6 in really stupid ways that would profligately waste /12 and larger blocks of IPv6. There are no more /12s in IPv6 than there are /12s in IPv4... Exactly 4096 of them. If we waste ~4000 /12s, we might be in trouble.

Current science says Earth can support ten billion humans. If we let the humans proliferate to three times the theoretical upper limit for Earth's population, a /64 for each human would be at about a /35's worth of /64's. If we're generous with Earth's carrying capacity, a /36.

But a /64 is nowhere near enough. You should, instead, be presuming the following: a /48 for each human's tablet a /48 for each human's phone a /48 for each human household (~1 /48 per 3 humans) a /48 for each human business site (hard to develop a good ratio here, but I'd guess something like 20 wouldn't be unreasonable, so that's another /48 for every 20 humans). Then, add to that network infrastructure, servers, etc. Additionally, we expect IPv6 to last long enough that you may not be able to depend on Earth as a bounding limitation, nor can you count on the limits of current science as a population limit.

If we handed out /48's instead so each human could give a /64 to each of their devices, it would all fit in a single /52. Those /48's would number existance at a rate of one /64 per human, one /64 per device, and a 65535:1 device:human ratio. That means we could allocate 4000::/3 just for Earth humans and devices and never need another block for that purpose.

You can't fit multiple /48s in a single /52, so that doesn't work. There are only 4096 /64s in a /52.

That's assuming a very high utilisation ratio, of course, but really no worse than IPv4 is currently. The problem isn't allocation density, but router hardware. We need room for route aggregation and other means of compartmentalisation. Is a 10% utilisation rate sparse enough? At 10% utilisation, keeping the allocations to just 4000::/3, we'd need less than a single /60 for all those /48's. If 10% isn't enough, we can go quite a bit farther:

This just doesn't work mathematically. You can't put multiple /48s into a /60... A /48 consists of 4096 /60s.

- 1% utilisation would fit all those /48's into a /62. - A full /64 of those /48's would be 0.2% utilisation. - 0.1%? We'd have to steal a bit and hand out /47's instead. - /47 is ugly. At /52, we'd get .024% (one per 4096).

It's really hard to follow what you are trying to claim given that you seem to have the bit math all backwards.

That's while maintaining a practice of one /64 per human or device with 65535 devices per human. Introduce one /64 per subnet and sub-ppm utilisation is possible. That would be giving a site a /44 and them only ever using the ::/64 of it.

I'm not sure what this is supposed to mean.

Even with sloppy, sparse allocation policies and allowing limitless human and device population growth, we very likely can not exhaust IPv6.

In terms of current allocation policies for humans, devices, and infrastructure, that is true. However, at one point, many ISPs wanted a /16 in order to be able to give each IPv4 subscriber a /48 based on their current IPv4 unicast address(es) for 6rd. There are only 65,536 /16s in IPv6. (Which is one of the many reasons this proposal did not make it into policy without moving some bits to the right). Fortunately, few operators actually implemented 6rd in such a profligate way anyway, so little harm was done. There are other proposals that have been made. One proposal was to map VIN numbers onto /48 prefixes and give each car manufactured a /48 that would be permanently allocated to the vehicle. Since these network numbers would not be reliably reclaimable at vehicle end-of-life, this usage pattern could become problematic over time. There have been others as well. It is these unusual "special" uses that I think Joel is referring to. Not traditional assignments for traditional internet purposes. Owen

On Thu, Sep 26, 2013 at 4:41 PM, Randy Bush <randy@psg.com> wrote:

...

...

sounds just like folks in 1985, talking about IPv4... The foundation of that, though, was ignorance of address space exhaustion.

no. ipv4 was the second time, not the first

Hi Randy, The first time they had 256 addresses (8 bits) right? That's where the original /8 assignments in IPv4 came from, the folks listed back in RFC 758 who had an IP address before IPv4. IPv4 jumped from 8 bits to 32 bits. Which when you think about it is the same ratio as jumping from 32 bits to 128 bits. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

On Mon, Sep 30, 2013 at 10:46 AM, TJ <trejrco@gmail.com> wrote:

On Mon, Sep 30, 2013 at 9:32 AM, William Herrin <bill@herrin.us> wrote:

...

IPv4 jumped from 8 bits to 32 bits. Which when you think about it is the same ratio as jumping from 32 bits to 128 bits.

Only insofar as the jump from 1 to 1000 is the same as the jump from 1000 is to 1000000 ... :)

If we're on an exponential growth curve, it's the same ratio. Are we? Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

William Herrin <bill@herrin.us> writes:

IPv4 jumped from 8 bits to 32 bits. Which when you think about it is the same ratio as jumping from 32 bits to 128 bits.

Sorry for the late reply, Bill, but you were snoozing when they taught logarithms in high school weren't you? Jumping from 8 bits to 32 bits (1:16mm) is the same ratio as would be jumping from 32 bits to 48 bits (also, 1:16mm). Going from 32 bits to 128 bits is 1:79228162514264337593543950336 which is not even remotely the same ratio. -r

On Oct 1, 2013, at 11:11 , William Herrin <bill@herrin.us> wrote:

On Tue, Oct 1, 2013 at 12:04 PM, Rob Seastrom <rs@seastrom.com> wrote:

...

William Herrin <bill@herrin.us> writes:

...

IPv4 jumped from 8 bits to 32 bits. Which when you think about it is the same ratio as jumping from 32 bits to 128 bits.

Jumping from 8 bits to 32 bits (1:16mm) is the same ratio as would be jumping from 32 bits to 48 bits (also, 1:16mm).

Hi Rob,

And yet we're allocating /19's where previously we allocated space that added up to /7's and /48's where previously we allocated /24's. My math may be flawed but the pattern is there all the same.

Not exactly... We're allocating /16s and/or /20s where previously we allocated space that added up to /7's, but, the holders of the /7s were coming back for more and more on a regular basis. I don't believe anyone holding a /16 or /20 of IPv6 has come back for another allocation at all and I would be surprised if such an organization were to do so in the next 5 years or so. We're allocating /48s where previously we allocated roughly /16-/24. Any effort at making direct comparisons between IPv4 and IPv6 number utilization is flawed because there is, by definition, nothing approximating a simple ratio between the two.

...

Going from 32 bits to 128 bits is 1:79228162514264337593543950336 which is not even remotely the same ratio.

You know enough about IPv6 to realize that we didn't go from 32 bits to 128 bits, we went from either 24ish bits to 48 or 28ish bits to 64, depending on how you look at it. While IPv6 is capable of working the same as IPv4, that's not how we're actually using it.

Both of those estimates are also flawed.

More, growth has not been linear since IPv4's advent and is not (by anyone reasonable) projected to be linear or sub-linear in IPv6. Computing a linear ratio as if that were representative of the expected lifetime of the new address space does not paint an honest picture.

Nor does any effort to apply a simple ratio between IPv4 and IPv6. There are sufficient differences in the allocation algorithms and counting methods between the two that an apples to apples comparison of allocation policies simply isn't possible. Owen

On Thu, Sep 26, 2013 at 12:29:17PM -0700, Darren Pilgrim wrote:

On 9/26/2013 1:52 AM, bmanning@vacation.karoshi.com wrote:

...

sounds just like folks in 1985, talking about IPv4...

The foundation of that, though, was ignorance of address space exhaustion. IPv4's address space was too small for such large thinking. IPv6 is far beyond enough to use such allocation policies.

when concevied, IPv4 was unimaginably large ... /8's were handed out to networks with fewer than 10 devices. Hindsight is 20/20. "those who ignore teh past are doomed to repeat it" /bill

*Beer* - sorry to take this further off topic. Regards Alexander Alexander Neilson Neilson Productions Limited alexander@neilson.net.nz 021 329 681 022 456 2326 Begin forwarded message:

From: Ben <ben+nanog@list-subs.com> Subject: Re: minimum IPv6 announcement size Date: 1 October 2013 1:05:01 AM NZDT To: nanog@nanog.org

On 26/09/2013 09:52, bmanning@vacation.karoshi.com wrote:

...

sounds just like folks in 1985, talking about IPv4...

Most people here were probably not of working age in 1985 ;-)

Working age?? some of us weren't even born yet.

Stop, you're giving me nightmares! Paul Lustgraaf grpjl@iastate.edu "Change is inevitable. Progress is not." Network Engineer, Iowa State University IT Services 515-294-0324 -----Original Message----- From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Monday, September 30, 2013 9:41 AM To: Ben Cc: nanog@nanog.org Subject: Re: minimum IPv6 announcement size On Mon, 30 Sep 2013 13:05:01 +0100, Ben said:

Most people here were probably not of working age in 1985 ;-)

"All you kids, get off my Proteon!" :)

-----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: September-24-13 12:19 To: Randy Bush Cc: NANOG Mailing List Subject: Re: minimum IPv6 announcement size

On Sep 24, 2013, at 11:00 AM, Randy Bush <randy@psg.com> wrote:

...

...

I am running a network that is operating on multiple sites and currently rolling out our IPv6 on the perimeter level. Having to get our /48 allocation from our RIR

excuse, but which rir handed out a /48 under which policy?

randy

ARIN will give out /48s to end users.

AfriNIC will give out /48s to end users.

I believe (but haven't verified) that this is also possible from APNIC and LACNIC.

APNIC: 7.2.1. Initial Assignments "APNIC will allocate a minimum of a /48 to organizations that can demonstrate..." LACNIC: 4.5.4. Direct Assignments to End Sites In a couple of subsections: "Assignments will be made in blocks smaller than or equal to a /32 but always greater than or equal to a /48." Steve

I believe you can get multiple /48 from APNIC. You will not be evaluated under HD ratio but as discrete network (no iBGP running among them). Here it is the policy [http://www.apnic.net/policy/ipv6-address-policy#5.5.2] Regards Roman On 25/09/13 11:42 AM, "Nathanael C. Cariaga" <nccariaga@stluke.com.ph> wrote:

We got our /48 from APNIC..

-nathan

On 9/25/2013 2:18 AM, Owen DeLong wrote:

...

On Sep 24, 2013, at 11:00 AM, Randy Bush <randy@psg.com> wrote:

...

...

I am running a network that is operating on multiple sites and currently rolling out our IPv6 on the perimeter level. Having to get our /48 allocation from our RIR excuse, but which rir handed out a /48 under which policy?

randy ARIN will give out /48s to end users.

AfriNIC will give out /48s to end users.

I believe (but haven't verified) that this is also possible from APNIC and LACNIC.

Someone else mentioned that RIPE will as well.

Owen

Subject: Re: minimum IPv6 announcement size Date: Tue, Sep 24, 2013 at 08:00:44AM -1000 Quoting Randy Bush (randy@psg.com):

...

I am running a network that is operating on multiple sites and currently rolling out our IPv6 on the perimeter level. Having to get our /48 allocation from our RIR

excuse, but which rir handed out a /48 under which policy?

Any of them? % Information related to '2001:67c:d8::/48' inet6num: 2001:67c:d8::/48 netname: SR-V6 descr: Sveriges Radio AB country: SE org: ORG-SR18-RIPE admin-c: MN1334-RIPE admin-c: LEW3-RIPE tech-c: MN1334-RIPE tech-c: LEW3-RIPE status: ASSIGNED PI mnt-by: RIPE-NCC-END-MNT mnt-lower: RIPE-NCC-END-MNT mnt-by: SR-MNT mnt-routes: SR-MNT mnt-domains: SR-MNT source: RIPE # Filtered -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Now, let's SEND OUT for QUICHE!!

Hi All, Thank you for these insights. We'll look into all of these and review again our options on how we can further proceed in our IPv6 deployment. Regards, -nathan On 9/25/2013 2:33 AM, William Herrin wrote:

On Tue, Sep 24, 2013 at 9:49 AM, Nathanael C. Cariaga <nccariaga@stluke.com.ph> wrote:

...

I've been Google-ing about if there is such a standard that sets the minimum IPv6 advertisement on BGP. My concern is that I am running a network that is operating on multiple sites and currently rolling out our IPv6 on the perimeter level. Having to get our /48 allocation from our RIR, I figured out I would it would be best for us to break down the /48 into smaller chunks (i.e /56s) and farm it out to our sites since a single /48 will be very big for our single site. Hi Nathanael,

Many if not most networks set a limit at /48. Verizon was the last player of consequence to filter at /32, and they moved to /48 a couple years ago. A few also try to limit advertisements within ISP space nearer to /32. Usually not at /32, but a /48 announcement within space allocated to an ISP won't necessarily be honored.

If you have distinct networks with distinct routing policies (or can make a reasonable claim to such) and your RIR is ARIN, you can request a block size large enough to provide a /48 to each distinct network. A /44 or whatever. Search through the ARIN NRPM for details. I don't know about the other RIRs; someone in your region (Asia Pacific?) will know.

Regards, Bill Herrin