BCP / Guidance on IPv6 prefix size to provide to customers

newer
Fwd: Re: [mailop] Wildcarding of...

older
Re: [nznog] Whole of Domain Web...

Alexander Neilson

31 Dec 2014 31 Dec '14

5:33 p.m.

I wondered if anyone on here had any guidance on any current BCP (or BCOP) or some general guidance on IPv6 allocations to customers (I am speaking here only for casual day to day allocations to customers) Looking through email archives and discussions that have seen around there was fairly vigorous discussions but no real resolutions. I have seen suggestions of /48, /50, /56. I am inclined to allocate /56’s to each customer (providing 256 /64’s). I don’t want to prevent customers from having the flexibility to do what they need / want to do nor stymie future use cases. If there is some good guidance on a need for /48’s then I will look at it and will use those if needed. Also, is current operating practice amongst others for all links to be /64’s even for p2p links? It seems a lot of documentation / reference texts are a few years old now and some providers have told me that this advice is no longer current but I haven’t yet seen this codified. My /32 allocation is provisionally as follows: 16 bits of /56 allocations - 65,535 customer allocations 8 bits for internal (leaves me 255 /64’s for p2p links between routers) Currently using PPPoE for IPv4 authentication for bulk customers and bespoke routed configurations for the rest. I intend to continue the PPPoE at this stage and just provide dual stack to every customer when connecting. I am still open to any input people have or feedback about what contributed to their deployments. I have looked into archives but was unable to find clear guidance that wasn’t discussed at length to be out of date / disputed so I am primarily looking for what the current best practice is so I can take advantage of the best advise for rolling out the deployment (I know we are late to this party but better late than never) Regards Alexander Alexander Neilson Neilson Productions Limited alexander(a)neilson.net.nz 021 329 681 022 456 2326

Attachments:

smime.p7s (application/pkcs7-signature — 4.0 KB)

Show replies by date

Roland Dobbins

31 Dec 31 Dec

6:30 p.m.

New subject: BCP / Guidance on IPv6 prefix size to provide to customers

On Jan 1, 2015, at 7:33 PM, Alexander Neilson wrote: If there is some good guidance on a need for /48’s then I will look at it and will use those if needed. This is commonplace. Also, is current operating practice amongst others for all links to be /64’s even for p2p links? The consensus of the operational community is to use /127s, so as to avoid turning one's routers into sinkholes. ----------------------------------- Roland Dobbins

Jeremy Visser

11:34 p.m.

New subject: BCP / Guidance on IPv6 prefix size to provide to customers

On 2 Jan 2015, at 02:30, Roland Dobbins wrote:

...

On Jan 1, 2015, at 7:33 PM, Alexander Neilson mailto:alexander(a)neilson.net.nz> wrote:

...
Also, is current operating practice amongst others for all links to be /64’s even for p2p links?

The consensus of the operational community is to use /127s, so as to avoid turning one's routers into sinkholes.

Can you elaborate on this scenario?

Roland Dobbins

1 Jan 1 Jan

2:37 a.m.

On 2 Jan 2015, at 1:34, Jeremy Visser wrote:

...

Can you elaborate on this scenario?

https://tools.ietf.org/html/rfc6164 ----------------------------------- Roland Dobbins

Brian E Carpenter

31 Dec 31 Dec

11:58 p.m.

New subject: BCP / Guidance on IPv6 prefix size to provide to customers

Hi, On 02/01/2015 01:33, Alexander Neilson wrote:

...

I wondered if anyone on here had any guidance on any current BCP (or BCOP) or some general guidance on IPv6 allocations to customers (I am speaking here only for casual day to day allocations to customers)

The BCP is http://tools.ietf.org/html/rfc6177

...

Looking through email archives and discussions that have seen around there was fairly vigorous discussions but no real resolutions. I have seen suggestions of /48, /50, /56. I am inclined to allocate /56’s to each customer (providing 256 /64’s). I don’t want to prevent customers from having the flexibility to do what they need / want to do nor stymie future use cases.

If there is some good guidance on a need for /48’s then I will look at it and will use those if needed.

RFC6177 suggests flexibility. /48s are not rare commodities - we have trillions of them, quite literally. So I've never seen any risk in handing them out to small customers, but unless you are fortunate enough to have a small customer grow into a very big customer, I guess there's no risk in /56s either.

...

Also, is current operating practice amongst others for all links to be /64’s even for p2p links? It seems a lot of documentation / reference texts are a few years old now and some providers have told me that this advice is no longer current but I haven’t yet seen this codified.

For that see http://tools.ietf.org/html/rfc6164 . As far as I know /127 has become the majority solution. Brian

...

My /32 allocation is provisionally as follows: 16 bits of /56 allocations - 65,535 customer allocations 8 bits for internal (leaves me 255 /64’s for p2p links between routers)

Currently using PPPoE for IPv4 authentication for bulk customers and bespoke routed configurations for the rest. I intend to continue the PPPoE at this stage and just provide dual stack to every customer when connecting.

I am still open to any input people have or feedback about what contributed to their deployments.

I have looked into archives but was unable to find clear guidance that wasn’t discussed at length to be out of date / disputed so I am primarily looking for what the current best practice is so I can take advantage of the best advise for rolling out the deployment (I know we are late to this party but better late than never)

Regards Alexander

Alexander Neilson Neilson Productions Limited

alexander(a)neilson.net.nz 021 329 681 022 456 2326

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

Ben

1 Jan 1 Jan

12:22 a.m.

On Fri, Jan 02, 2015 at 01:33:08AM +1300, Alexander Neilson wrote:

...

I wondered if anyone on here had any guidance on any current BCP (or BCOP) or some general guidance on IPv6 allocations to customers (I am speaking here only for casual day to day allocations to customers)

Looking through email archives and discussions that have seen around there was fairly vigorous discussions but no real resolutions. I have seen suggestions of /48, /50, /56. I am inclined to allocate /56???s to each customer (providing 256 /64???s). I don???t want to prevent customers from having the flexibility to do what they need / want to do nor stymie future use cases.

If there is some good guidance on a need for /48???s then I will look at it and will use those if needed.

Also, is current operating practice amongst others for all links to be /64???s even for p2p links? It seems a lot of documentation / reference texts are a few years old now and some providers have told me that this advice is no longer current but I haven???t yet seen this codified.

My /32 allocation is provisionally as follows: 16 bits of /56 allocations - 65,535 customer allocations 8 bits for internal (leaves me 255 /64???s for p2p links between routers)

Currently using PPPoE for IPv4 authentication for bulk customers and bespoke routed configurations for the rest. I intend to continue the PPPoE at this stage and just provide dual stack to every customer when connecting.

I am still open to any input people have or feedback about what contributed to their deployments.

I have looked into archives but was unable to find clear guidance that wasn???t discussed at length to be out of date / disputed so I am primarily looking for what the current best practice is so I can take advantage of the best advise for rolling out the deployment (I know we are late to this party but better late than never)

There are some posts on nanog about this. New Zealand doesn't really have much IPv6 usage. The general recommendation seems to be to give out /48s to users. Although you may only have a /32 at the moment, you can apply for more space in the future if you require it. It is generally given that /48 is the smallest allocation that one can advertise over the internet. And if a customer wants to multihome in multiple locations then each location should have a /48 at the least. I'm not really sure how much harm there is in giving out /56s to home and small business users who are unlikely to want to multihome but at the least it shortens allocations when giving out more space. There's a bit more information at http://bcop.nanog.org/index.php/IPv6_Subnetting There is an arguement of going to something in between /64 and /127. But allocating a /64 and using a /126 on it isn't a bad thing, giving odd upstream, even downstream, although some people like the idea of making it /124 or such, to allow for things like VRRP etc you can always extend later. There is a concern if people don't liberally give out IP addresses users will try and conserve IP addresses and do things like share IP adddresses within a subnet instead of routing them. And one of the visions of IPv6 sems to be to get away from NAT, and the conservation of IP addresses. Ben.

Roland Dobbins

2:34 a.m.

On 2 Jan 2015, at 2:22, Ben wrote:

...

There is an arguement of going to something in between /64 and /127.

Actually, /127 has pretty much won that argument amongst responsible operators. ;> ----------------------------------- Roland Dobbins

Ben

2:35 a.m.

i mean something like /126, /124 etc. On Fri, Jan 02, 2015 at 04:34:11AM +0700, Roland Dobbins wrote:

...

On 2 Jan 2015, at 2:22, Ben wrote:

...
There is an arguement of going to something in between /64 and /127.

Actually, /127 has pretty much won that argument amongst responsible operators.

;>

----------------------------------- Roland Dobbins _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

Roland Dobbins

3:05 a.m.

On 2 Jan 2015, at 4:35, Ben wrote:

...

i mean something like /126, /124 etc.

There's no benefit to doing it, and considerable drawbacks. ----------------------------------- Roland Dobbins

Jeremy Visser

12:56 p.m.

New subject: BCP / Guidance on IPv6 prefix size to provide to customers

On 2 Jan 2015, at 08:22, Ben wrote:

...

The general recommendation seems to be to give out /48s to users. Although you may only have a /32 at the moment, you can apply for more space in the future if you require it.

It is generally given that /48 is the smallest allocation that one can advertise over the internet. And if a customer wants to multihome in multiple locations then each location should have a /48 at the least.

The latter isn’t a valid reason for the former, as space assigned to customers by ISPs is by definition non-portable. Not arguing against /48’s or anything, though.

Brian E Carpenter

11:59 p.m.

New subject: BCP / Guidance on IPv6 prefix size to provide to customers

On 02/01/2015 20:56, Jeremy Visser wrote:

...

On 2 Jan 2015, at 08:22, Ben wrote:

...
The general recommendation seems to be to give out /48s to users. Although you may only have a /32 at the moment, you can apply for more space in the future if you require it.

It is generally given that /48 is the smallest allocation that one can advertise over the internet. And if a customer wants to multihome in multiple locations then each location should have a /48 at the least.

The latter isn’t a valid reason for the former, as space assigned to customers by ISPs is by definition non-portable.

There was an argument, which I think was in (obsolete) RFC 3177, that if all providers hand out the same length prefix, customers would never have to redesign their site addressing plan if they switched providers and had to accept a longer prefix. The more recent recommendation is that site numbering plans should simply number subnets compactly rather than sparsely, to avoid needing a short prefix when it isn't strictly necessary. All the same, handing out /56s means assuming that your customers never need 257 subnets. That may sound like a lot, but think about possibilities such as large numbers of virtual subnets. Brian

...

Not arguing against /48’s or anything, though.

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

Fraser McGlinn

2 Jan 2 Jan

3:54 a.m.

New subject: BCP / Guidance on IPv6 prefix size to provide to customers

I also believed a valid argument at the same time is that if a customer is legitimately using an entire /48-56 (I’d say its somewhere within this range - Open to debate on this.) and is requesting more, perhaps you should be redirecting them to APNIC to apply for their own PI address space. From a growth perspective it makes sense for the customer, however at the same time it doesn’t give you quite so much vendor lock into your services. Obviously the flip side of this is if they refuse to get PI Addressing you should of course allocate them appropriate addressing. At the end of the day I see this as the right approach because I want large customers to design their network right regardless of vendor providing the services. Cheers, Fraser

...

On 3/01/2015, at 7:59 am, Brian E Carpenter wrote:

On 02/01/2015 20:56, Jeremy Visser wrote:

...
On 2 Jan 2015, at 08:22, Ben wrote:

...
The general recommendation seems to be to give out /48s to users. Although you may only have a /32 at the moment, you can apply for more space in the future if you require it.

It is generally given that /48 is the smallest allocation that one can advertise over the internet. And if a customer wants to multihome in multiple locations then each location should have a /48 at the least.

The latter isn’t a valid reason for the former, as space assigned to customers by ISPs is by definition non-portable.

There was an argument, which I think was in (obsolete) RFC 3177, that if all providers hand out the same length prefix, customers would never have to redesign their site addressing plan if they switched providers and had to accept a longer prefix. The more recent recommendation is that site numbering plans should simply number subnets compactly rather than sparsely, to avoid needing a short prefix when it isn't strictly necessary.

All the same, handing out /56s means assuming that your customers never need 257 subnets. That may sound like a lot, but think about possibilities such as large numbers of virtual subnets.

Brian

...
Not arguing against /48’s or anything, though.

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

Jed Laundry

4:21 a.m.

New subject: BCP / Guidance on IPv6 prefix size to provide to customers

Hey, On 3 Jan 2015 07:59, "Brian E Carpenter" wrote:

...

All the same, handing out /56s means assuming that your customers never need 257 subnets. That may sound like a lot, but think about possibilities such as large numbers of virtual subnets.

I'm not a "large" customer, but I'm a lazy one. With a /48 I can encode the VLAN tag directly in the address and never worry about lookup spreadsheets again. (my cloud providers hand over traffic at L2 at both ends of the VLAN numbering range, and VLAN translation implementations are buggy at best) Thanks, Jed. Sent from a small screen.

Alexander Neilson

5:03 a.m.

New subject: BCP / Guidance on IPv6 prefix size to provide to customers

This has been my difficulty with the advice on IPv6. I do not have any intention to limit customers to the /56, however for passive customers who don’t request more and whom just get their dynamic IP Address from the PPPoE Response should we just hand out /48’s and give everyone their 65,535 subnets. Thinking about the management probably indicates that /48’s everywhere, keep some static pools, and split my /32 in half to reserve internal space and customer space. If I really get to 32k customers then I can probably justify more space for more pops etc. Regards Alexander Alexander Neilson Neilson Productions Limited alexander(a)neilson.net.nz 021 329 681 022 456 2326

...

On 3/01/2015, at 12:21 pm, Jed Laundry wrote:

Hey,

On 3 Jan 2015 07:59, "Brian E Carpenter" mailto:brian.e.carpenter(a)gmail.com> wrote:

...
All the same, handing out /56s means assuming that your customers never need 257 subnets. That may sound like a lot, but think about possibilities such as large numbers of virtual subnets.

I'm not a "large" customer, but I'm a lazy one. With a /48 I can encode the VLAN tag directly in the address and never worry about lookup spreadsheets again.

(my cloud providers hand over traffic at L2 at both ends of the VLAN numbering range, and VLAN translation implementations are buggy at best)

Thanks, Jed.

Sent from a small screen. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

3642

Age (days ago)

3644

Last active (days ago)

List overview

Download

13 comments

7 participants

participants (7)

Alexander Neilson
Ben
Brian E Carpenter
Fraser McGlinn
Jed Laundry
Jeremy Visser
Roland Dobbins