yes! by ALL means, hand out /48s. There is huge benefit to announcing all that dark space, esp. when virtually no one practices BCP-38, esp in IPv6 land. /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 8October2014Wednesday, at 18:31, Mark Andrews <marka@isc.org> wrote:

Give them a /48. This is IPv6 not IPv4. Take the IPv4 glasses off and put on the IPv6 glasses. Stop constraining your customers because you feel that it is a waste. It is not a waste!!!! It will also reduce the number of exceptions you need to process and make over all administration easier.

As for only two subnets, I expect lots of equipment to request prefixes in the future not just traditional routers. It will have descrete internal components which communicate using IPv6 and those components need to talk to each other and the world. In a IPv4 world they would be NAT'd. In a IPv6 world the router requests a prefix.

Mark

In message <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads>, Erik Sun dberg writes:

...

I am planning out our IPv6 deployment right now and I am trying to figure o= ut our default allocation for customer LAN blocks. So what is everyone givi= ng for a default LAN allocation for IPv6 Customers. I guess the idea of ha= nding a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me cring= e at the waste. Especially when you know 90% of customers will never have m= ore than 2 or 3 subnets. As I see it the customer can always ask for more I= Pv6 Space.

/64 /60 /56 /48

Small Customer? Medium Customer? Large Customer?

Thanks

Erik

________________________________

CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files = or previous e-mail messages attached to it may contain confidential informa= tion that is legally privileged. If you are not the intended recipient, or = a person responsible for delivering it to the intended recipient, you are h= ereby notified that any disclosure, copying, distribution or use of any of = the information contained in or attached to this transmission is STRICTLY P= ROHIBITED. If you have received this transmission in error please notify th= e sender immediately by replying to this e-mail. You must destroy the origi= nal transmission and its attachments without reading or saving in any manne= r. Thank you. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

makes more sense to hand out /48s imho. theres only a mere 65k /48s per /32 (or something like that), though. On 10/09/14 12:29, Mark Andrews wrote:

In message <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu>, manning bill writes:

...

yes! by ALL means, hand out /48s. There is huge benefit to announcing = all that dark space, esp. when virtually no one practices BCP-38, esp in IPv6 land.

/bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 and if everyone hands out /48's you just filter /48's. With a mix of /56 and /48 you need to filter at the /56 level. Given enterpises are getting /48's it will be simpler overall for everyone to get /48's.

...

On 8October2014Wednesday, at 18:31, Mark Andrews <marka@isc.org> wrote:

...

...

I am planning out our IPv6 deployment right now and I am trying to =

=20 Give them a /48. This is IPv6 not IPv4. Take the IPv4 glasses off and put on the IPv6 glasses. Stop constraining your customers because you feel that it is a waste. It is not a waste!!!! It will also reduce the number of exceptions you need to process and make over all administration easier. =20 As for only two subnets, I expect lots of equipment to request prefixes in the future not just traditional routers. It will have descrete internal components which communicate using IPv6 and those components need to talk to each other and the world. In a IPv4 world they would be NAT'd. In a IPv6 world the router requests a prefix. =20 Mark =20 In message <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads>, = Erik Sun dberg writes: figure o=3D

...

ut our default allocation for customer LAN blocks. So what is = everyone givi=3D ng for a default LAN allocation for IPv6 Customers. I guess the idea = of ha=3D nding a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me = cring=3D e at the waste. Especially when you know 90% of customers will never = have m=3D ore than 2 or 3 subnets. As I see it the customer can always ask for = more I=3D Pv6 Space. =20 /64 /60 /56 /48 =20 Small Customer? Medium Customer? Large Customer? =20 Thanks =20 Erik =20 ________________________________ =20 CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, = files =3D or previous e-mail messages attached to it may contain confidential = informa=3D tion that is legally privileged. If you are not the intended = recipient, or =3D a person responsible for delivering it to the intended recipient, you = are h=3D ereby notified that any disclosure, copying, distribution or use of = any of =3D the information contained in or attached to this transmission is = STRICTLY P=3D ROHIBITED. If you have received this transmission in error please = notify th=3D e sender immediately by replying to this e-mail. You must destroy the = origi=3D nal transmission and its attachments without reading or saving in any = manne=3D r. Thank you. --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

Mark Andrews <marka@isc.org> writes:

In message <54366AB9.3040504@gmail.com>, Paige Thompson writes:

...

makes more sense to hand out /48s imho. theres only a mere 65k /48s per /32 (or something like that), though.

A /32 is the minimum allocation to a ISP. If you have more customers or will have more customers request a bigger block from the RIRs.

Mark

Has anyone successfully gotten a RIR to assign anything bigger than a /32? I seem to recall in recent history someone tried to obtain a /31 through ARIN and got smacked down. Even if you're assigning a /56 to every end user, that's still on the order of 16 million allocations. I can't imagine anyone but the truly behemoth access network operators being able to justify a larger allocation with a straight face.

On Thu, Oct 9, 2014 at 10:34 AM, Karsten Elfenbein <karsten.elfenbein@gmail.com> wrote:

Ripe is handing out /29 without any additional documentation current IPv4 usage documentation should do the trick to request larger blocks for deployment of /48 to customers

And /19s with documentation. Europe will by God not end up with fewer IPv6 addresses than the U.S. like has happened with IPv4. -Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/> May I solve your unusual networking challenges?

On Thu, 2014-10-09 at 10:22 -0400, Daniel Corbe wrote:

...

Has anyone successfully gotten a RIR to assign anything bigger than a /32? I seem to recall in recent history someone tried to obtain a /31 through ARIN and got smacked down.

Yes; ISTR several /20s and even a /19 were the largest ... until the US DoD got the equivalent of a /13. Quick looks: https://www.sixxs.net/tools/grh/dfp/ http://www.nanog.org/mailinglist/mailarchives/old_archive/2008-05/msg00276.h... /TJ

On Oct 9, 2014, at 8:45 AM, TJ <trejrco@gmail.com> wrote:

...

On Thu, 2014-10-09 at 10:22 -0400, Daniel Corbe wrote:

...

Has anyone successfully gotten a RIR to assign anything bigger than a /32? I seem to recall in recent history someone tried to obtain a /31 through ARIN and got smacked down.

Yes; ISTR several /20s and even a /19 were the largest ... until the US DoD got the equivalent of a /13.

Quick looks: https://www.sixxs.net/tools/grh/dfp/ http://www.nanog.org/mailinglist/mailarchives/old_archive/2008-05/msg00276.h...

/TJ

What DoD actually got as AIUI was a slew of allocations throughout a /13, but not an actual /13. Owen

On Oct 9, 2014, at 7:22 AM, Daniel Corbe <corbe@corbe.net> wrote:

Mark Andrews <marka@isc.org> writes:

...

In message <54366AB9.3040504@gmail.com>, Paige Thompson writes:

...

makes more sense to hand out /48s imho. theres only a mere 65k /48s per /32 (or something like that), though.

A /32 is the minimum allocation to a ISP. If you have more customers or will have more customers request a bigger block from the RIRs.

Mark

Has anyone successfully gotten a RIR to assign anything bigger than a /32? I seem to recall in recent history someone tried to obtain a /31 through ARIN and got smacked down.

I think I answered this before you asked it, but yes,easily on multiple occasions. The largest two allocations I have worked on were /24s, but I’m sure those are not ARIN’s largest allocations.

Even if you're assigning a /56 to every end user, that's still on the order of 16 million allocations. I can't imagine anyone but the truly behemoth access network operators being able to justify a larger allocation with a straight face.

You should, however, be assigning a /48 to every end user and that’s only 65,536 allocations. Further, you want to be able to aggregate at least one level in your network, so you may not be able to get anything close to 100% efficiency in that distribution. ARIN policy, for example, defines what is known as a Provider Allocation Unit (PAU). Your PAU is the smallest allocation you give to your customers, so if you’re giving out /64s, then your PAU becomes /64. If you’re giving out /56s, then your PAU is /56. As such, you’re better off to give /48s to everyone because that sets your PAU at /48. All of your utilization is measured in terms of PAUs. You then pick an aggregation level in your network to use as your “serving center” definition. It could be the POP, or some higher level of aggregation containing multiple POPs. Look at the number of end sites served by the largest of those “serving centers” and round that up to a power of 16 (a nibble boundary, e.g. 16, 256, 4096, 65536) such that the number of end sites is not more than 75% of the chosen poser of 16. Then take the number of “serving centers” you expect to have in ~5 years (though the exact forward looking time is not actually specified in policy) and round that up to a nibble boundary as well. That is the size of allocation you can get from ARIN. So, for example, if you have 800,000 end-sites served from your largest POP and you have 400 POPs, then, 800,000 would be rounded up to 16,777,216 (24 bits) and your 400 POPs would be rounded up to 4096 (12 bits) so you would end up needing 36 bits. If your PAU is /48, you would apply for and receive a /12. Obviously this is an unusually large example. At a more realistic large ISP scale, let’s say you’ve got 5,000,000 subscribers in your largest serving center, but only 25 serving centers. This would, again, round up to 16,777,216 (24 bits) subscribers per serving center. But your 25 serving centers would round up to 256 (8 bits). That’s 32 bits, so instead of a /12, you’d get a /16. I hope that clarifies things for people. Owen

Sixty replies and no one linked to the BCOP? Is there a reason we are ignoring it?

http://bcop.nanog.org/index.php/IPv6_Subnetting

Speaking for myself, I did review that doc, and had some confusion about allocating /64 to Resi-Subscribers. However the broader discussion seems to evolved into a /48 vs /56 discussion, and looks like there is a decent compelling case being made for /48 and not to bother with /56's ... :) Faisal Imtiaz Snappy Internet & Telecom ----- Original Message -----

From: "Richard Hicks" <richard.hicks@gmail.com> To: nanog@nanog.org Sent: Thursday, October 9, 2014 12:29:21 PM Subject: Re: IPv6 Default Allocation - What size allocation are you giving out

Sixty replies and no one linked to the BCOP? Is there a reason we are ignoring it?

http://bcop.nanog.org/index.php/IPv6_Subnetting

As we recently discovered ARIN is handing out IPv6 allocations on nibble boundaries.

Either a /32 or /28 for service providers. A justification and utilization plan is need to get a /28. It is also double the cost per year.

On Thu, Oct 9, 2014 at 9:01 AM, Owen DeLong <owen@delong.com> wrote:

...

On Oct 9, 2014, at 7:22 AM, Daniel Corbe <corbe@corbe.net> wrote:

...

Mark Andrews <marka@isc.org> writes:

...

In message <54366AB9.3040504@gmail.com>, Paige Thompson writes:

...

makes more sense to hand out /48s imho. theres only a mere 65k /48s per /32 (or something like that), though.

A /32 is the minimum allocation to a ISP. If you have more customers or will have more customers request a bigger block from the RIRs.

Mark

Has anyone successfully gotten a RIR to assign anything bigger than a /32? I seem to recall in recent history someone tried to obtain a /31 through ARIN and got smacked down.

I think I answered this before you asked it, but yes,easily on multiple occasions. The largest two allocations I have worked on were /24s, but I’m sure those are not ARIN’s largest allocations.

...

Even if you're assigning a /56 to every end user, that's still on the order of 16 million allocations. I can't imagine anyone but the truly behemoth access network operators being able to justify a larger allocation with a straight face.

You should, however, be assigning a /48 to every end user and that’s only 65,536 allocations.

Further, you want to be able to aggregate at least one level in your network, so you may not be able to get anything close to 100% efficiency in that distribution.

ARIN policy, for example, defines what is known as a Provider Allocation Unit (PAU).

Your PAU is the smallest allocation you give to your customers, so if you’re giving out /64s, then your PAU becomes /64. If you’re giving out /56s, then your PAU is /56. As such, you’re better off to give /48s to everyone because that sets your PAU at /48.

All of your utilization is measured in terms of PAUs.

You then pick an aggregation level in your network to use as your “serving center” definition. It could be the POP, or some higher level of aggregation containing multiple POPs.

Look at the number of end sites served by the largest of those “serving centers” and round that up to a power of 16 (a nibble boundary, e.g. 16, 256, 4096, 65536) such that the number of end sites is not more than 75% of the chosen poser of 16.

Then take the number of “serving centers” you expect to have in ~5 years (though the exact forward looking time is not actually specified in policy) and round that up to a nibble boundary as well.

That is the size of allocation you can get from ARIN.

So, for example, if you have 800,000 end-sites served from your largest POP and you have 400 POPs, then, 800,000 would be rounded up to 16,777,216 (24 bits) and your 400 POPs would be rounded up to 4096 (12 bits) so you would end up needing 36 bits. If your PAU is /48, you would apply for and receive a /12.

Obviously this is an unusually large example.

At a more realistic large ISP scale, let’s say you’ve got 5,000,000 subscribers in your largest serving center, but only 25 serving centers.

This would, again, round up to 16,777,216 (24 bits) subscribers per serving center. But your 25 serving centers would round up to 256 (8 bits). That’s 32 bits, so instead of a /12, you’d get a /16.

I hope that clarifies things for people.

Owen

On Thu, Oct 9, 2014 at 10:40 AM, William Herrin <bill@herrin.us> wrote:

On Thu, Oct 9, 2014 at 12:29 PM, Richard Hicks <richard.hicks@gmail.com> wrote:

...

Sixty replies and no one linked to the BCOP? Is there a reason we are ignoring it?

Hi Richard,

It's dated (a *lot* about IPv6 has changed since 2011) and a we've learned enough to know some of the things in there are dubious. For example:

"Regardless of the number of hosts on an individual LAN or WAN segment, every multi-access network (non-point-to-point) requires at least one /64 prefix."

But using /64s on WAN links invites needless problems with neighbor discovery when an attacker decides to send one ping each to half a million adresses all of which happen to land on that WAN link. WAN links should really use something whose size is much closer to the number of routers on the link, in the same order of magnitude anyway. So /64s for LANs, sure, but size the WAN links small to make them less vulnerable to attack.

The BCOP specfically addresses this in 4b: " *b. Point-to-point links should be allocated a /64 and configured with a /126 or /127*"

And:

"Only subnet on nibble boundaries" is not reasonable. When I need two LANs in a building I should burn 14 more to get to a nibble boundary? Really?

"Only delegate on nibble boundaries" is a more reasonable statement. When you assign addresses to your customer or to a different internal team's control, THAT should be on a nibble boundary for the customer's convenience understanding the written-down version of what network is theirs and for your convenience when it comes time to delegate reverse DNS.

Inside your network under control of the same engineers, subnet and route just as you would with IPv4.

Regards, Bill Herrin

-- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/> May I solve your unusual networking challenges?

On 9 October 2014 19:55, Richard Hicks <richard.hicks@gmail.com> wrote:

The BCOP specfically addresses this in 4b: " *b. Point-to-point links should be allocated a /64 and configured with a /126 or /127*"

Why do people assign addresses to point-to-point links at all? You can just use a host /128 route to the loopback address of the peer. Saves you the hassle of coming up with new addresses for every link. Same trick works for IPv4 too. Regards, Baldur

On Oct 9, 2014, at 11:34 AM, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:

On 9 October 2014 19:55, Richard Hicks <richard.hicks@gmail.com> wrote:

...

The BCOP specfically addresses this in 4b: " *b. Point-to-point links should be allocated a /64 and configured with a /126 or /127*"

Why do people assign addresses to point-to-point links at all? You can just use a host /128 route to the loopback address of the peer. Saves you the hassle of coming up with new addresses for every link. Same trick works for IPv4 too.

Regards,

Baldur

<SARCASM> And it makes your trace-routes across parallel links oh so easy to identify which of them is at fault for the packet loss, too. </SARCASM> There are a number of good technical reasons to want distinct addresses on point to point links. Owen

On Oct 10, 2014, at 3:25 AM, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:

I am sure there are. Tell me about them.

This issue has been discussed on all the various operational lists many, many times over the years. <http://tools.ietf.org/html/rfc6752> ---------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Equo ne credite, Teucri. -- Laocoön

On Thu, Oct 9, 2014 at 4:32 PM, Roland Dobbins <rdobbins@arbor.net> wrote:

On Oct 10, 2014, at 3:25 AM, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:

...

I am sure there are. Tell me about them.

This issue has been discussed on all the various operational lists many, many times over the years.

<http://tools.ietf.org/html/rfc6752>

Hi Roland, 6752 isn't germane; it has to do with using private IP addresses on routers, which borks things up when the router has to generate an ICMP type 3. Baldur want's to know: why not just use one public IP address per router and use it on all interfaces? Baldur, one IP per router can work just as well as one subnet per interface. But there are some gotchas: Your router has one IP. Your customer has a subnet. Do you add an extra deaggregated single IP to your routing table for his router? There are more routers than links, so if you assign subnets to routers instead of links you'll have to carry more routes. If you borrow the customer LAN-side IP for the WAN side you'll get grief when his equipment is one of those that doesn't respond if the LAN-side interface is down (e.g. Cisco). That gets kind of nasty when troubleshooting and remediating problems. And of course the more knowledge you can gather from diagnostic tools like traceroute, the more quickly you can identify the problem when something doesn't work right.. In my own networks... I want to keep as many IPv4 addresses as I can, so my router interfaces borrow their ip from loop0. In IPv6 where I can have a functionally infinite number of /124's I want to put one on each interface and gain the mild extra benefit. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/> May I solve your unusual networking challenges?

Hi Bill Thanks for you response. About customer routers: For IPv6 that answer is simple. The customer is using us as default gateway and that always uses the IPv6 link local address. He has no need to know the public IPv6 address of the uplink router, so we don't tell him. The link local address is learned automatically from the RA packets. The customer router needs an IP address. I do that by allocating a small prefix, typically a /120, which covers all the users on the same access switch. The IP, a /128, is assigned by DHCPv6 and he gets his /48 by prefix delegation. There is no way to avoid a route for that /48. This works great with asymmetric bridges (isolated vlans etc). For IPv4 I do have an IP address on the customer facing interface. Typically a /24 for users on the same access switch using MFF (MAC Forced Forwarding). I do wonder if I could get away with using a /32 and push out a host route through DHCP, but I am unsure if clients generally support that. But all this are customer facing interfaces, which do not really qualify for "point to point" links. I might consider adding interface addressing for IPv6, but for me IPv4 was the primary design parameter. Having IPv6 mirror the IPv4 setup means I have to think less about the setup. And we are really constrained to use as few IPv4 addresses as possible. We only got 1024 from RIPE and have to buy any additional at great expense. My colleges wanted to completely drop using public IP addressing in the infrastructure. I am wondering if all the nay sayers would not agree that is it better to have a single public loopback address shared between all my interfaces, than to go with private addressing completely? Because frankly, that is the alternative. Regards, Baldur On 9 October 2014 22:49, William Herrin <bill@herrin.us> wrote:

On Thu, Oct 9, 2014 at 4:32 PM, Roland Dobbins <rdobbins@arbor.net> wrote:

...

On Oct 10, 2014, at 3:25 AM, Baldur Norddahl <baldur.norddahl@gmail.com>

wrote:

...

...

I am sure there are. Tell me about them.

This issue has been discussed on all the various operational lists many,

many times over the years.

...

<http://tools.ietf.org/html/rfc6752>

Hi Roland,

6752 isn't germane; it has to do with using private IP addresses on routers, which borks things up when the router has to generate an ICMP type 3. Baldur want's to know: why not just use one public IP address per router and use it on all interfaces?

Baldur, one IP per router can work just as well as one subnet per interface. But there are some gotchas:

Your router has one IP. Your customer has a subnet. Do you add an extra deaggregated single IP to your routing table for his router? There are more routers than links, so if you assign subnets to routers instead of links you'll have to carry more routes.

If you borrow the customer LAN-side IP for the WAN side you'll get grief when his equipment is one of those that doesn't respond if the LAN-side interface is down (e.g. Cisco). That gets kind of nasty when troubleshooting and remediating problems.

And of course the more knowledge you can gather from diagnostic tools like traceroute, the more quickly you can identify the problem when something doesn't work right..

In my own networks... I want to keep as many IPv4 addresses as I can, so my router interfaces borrow their ip from loop0. In IPv6 where I can have a functionally infinite number of /124's I want to put one on each interface and gain the mild extra benefit.

Regards, Bill Herrin

-- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/> May I solve your unusual networking challenges?

On 9 October 2014 23:18, Roland Dobbins <rdobbins@arbor.net> wrote:

On Oct 10, 2014, at 4:13 AM, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:

...

My colleges wanted to completely drop using public IP addressing in the infrastructure.

Your colleagues are wrong. Again, see RFC6752.

Yes, for using private IP addressing RFC 6752 applies and it is why we are not doing it. But you seem to completely fail to understand that RFC 6752 does not apply to the proposed solution. NONE of the problems listed in RFC 6752 are a problem with using unnumbered interfaces. Traceroute works. ICMP works. There are no private IP addresses that gets filtered.

I am wondering if all the nay sayers would not agree that is it better to have a single public loopback address shared between all my interfaces, than to go with private addressing completely?

This is a false dichotomy.

...

Because frankly, that is the alternative.

It isn't the only alternative. The *optimal* alternative is to use publicly-routable link addresses, and then protect your infrastructure using iACLs, GTSM, CoPP, et. al.

I will as soon as you send me the check to buy addresses for all my links. I got a few. But it appears you do not realize that we ARE using public IPs for our infrastructure. And we ARE using ACLs for protecting it. We are not using addresses for LINKS, neither public nor private. And it is not for security but to conserve expensive address space. The thing is that we will only use ONE public address for a router. And the router will be using that address for traceroute, ICMP et al. And therefore RFC 6752 does not apply. What started this thread was the simple observation that you can do the same with IPv6. In that case I am doing it because it is simpler to do the same thing on both protocols. And frankly I am not seeing the disadvantages put fourth so far as being anything worth taking extra management work for. What I am mostly getting from the responses here are not much useful, other than a lot of people screaming he his doing something different so he must be an idiot :-(. Well aside from Bill, which is apparently doing the same thing for the same reason (cost). Regards, Baldur

On 10 October 2014 00:37, Roland Dobbins <rdobbins@arbor.net> wrote:

On Oct 10, 2014, at 5:04 AM, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:

...

NONE of the problems listed in RFC 6752 are a problem with using unnumbered interfaces.

As far as Section 8 goes, you're even worse off than if you were using private IP addresses.

I see nothing in section 8 that is broken in my network. My public loopback address is in DNS and reverse DNS works fine too.

And see Section 9.

I see nothing in section 9 that is broken in my network. Traceroute works perfectly. You do not get a string of * * * back. You get the IP of the loopback which in turn goes through reverse DNS to tell you what router is processing that step. The only difference between a traceroute using unnumbered interfaces and using numbered interfaces, is that you only get information about the router and not the link.

My point is that *analogous* issues arise with unnumbered interfaces. Loopback-only addressing isn't sufficient for troubleshooting purposes and other routine operational activities.

That is really up to me? 99% of my interfaces are unnumbered by the virtue of being on access switches that simply have no layer 3 capability other than management. Nobody is crazy enough to assign /30s to end users anymore anyway. It is not my business to sell backbone links. I sell end user links and those are unnumbered in my network and everyone else too. I claim this argument is mostly BS. Information about link in traceroute is nice to have. It is not need to have. I have never been in doubt of what traceroute was telling me. Besides I have more effective methods to troubleshoot my links.

...

The thing is that we will only use ONE public address for a router. And the router will be using that address for traceroute, ICMP et al. And therefore RFC 6752 does not apply.

Again, see Section 9. *Analogous* issues arise in networks with unnumbered interfaces. I'm aware that PMTU-D will work with the setup you propose.

That is not the only thing that works. Everything works. The only "problem" anyone has been able to point to is that you lose link information in traceroute and get host information in its stead. It is a small loss.

You might want to take a look at Appendix A, too.

What about it? That is incorrect. You've been told repeatedly that troubleshooting

unnumbered links is highly suboptimal; you've merely dismissed those arguments for reasons best known to yourself.

Maybe because on that one topic I am more an expert than you: I have experience troubleshooting my network, you don't. Regards, Baldur

On Oct 11, 2014, at 12:41 PM, Faisal Imtiaz <faisal@snappytelecom.net> wrote:

For Router Loopback Address .... what is wisdom in allocating a /64 vs /128 ?

In the BCOP, this is noted so that those who suboptimally address their p-t-p links with /64s can be consistently suboptimal by doing the same with their loopbacks, so that *all* their interfaces are sinkholes. But the BCOP also talks about /128s. ---------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Equo ne credite, Teucri. -- Laocoön

On Oct 11, 2014, at 1:33 PM, Faisal Imtiaz <faisal@snappytelecom.net> wrote:

I am trying to understand what is sub-optimal about doing so...Waste of Ipv6 space ? or some other technical reason ?

It's wasteful of address space, but more importantly, it turns your router into a sinkole.

(is a /64 address are a 'sinkhole' the only reason ? )

That's a pretty big reason not to use /64s. ---------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Equo ne credite, Teucri. -- Laocoön

On Oct 11, 2014, at 2:09 PM, Tim Raphael <raphael.timothy@gmail.com> wrote:

From my research, various authorities have recommended that a single /64 be allocated to router loopbacks with /128s assigned on interfaces.

Yes, this is what I advocate for loopbacks. ---------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Equo ne credite, Teucri. -- Laocoön

Hi, On Sun, Oct 12, 2014 at 02:53:36PM +0200, Sander Steffann wrote:

Hi,

...

Op 11 okt. 2014, om 23:00 heeft Roland Dobbins <rdobbins@arbor.net> het volgende geschreven:

...

On Oct 11, 2014, at 2:09 PM, Tim Raphael <raphael.timothy@gmail.com> wrote:

...

From my research, various authorities have recommended that a single /64 be allocated to router loopbacks with /128s assigned on interfaces.

Yes, this is what I advocate for loopbacks.

I often use the first /64 for loopbacks.

I'm not a big fan of using all-zero third or fourth quarters of $PREFIX at all (at least not if one follows RFC 5952 & uses static, short IIDs, which will be case for loopbacks). On a crowded visio diagram it might not be easy to spot that 2001:db8::1, 2001:db8:0:1::1, 2001:db8:1::1 and 2001:db8:1:1::1 are all different addresses, potentially on the same hierarchy level. Hence we prefer to use FFFF or just FF "at some point within the prefix" for loopbacks, e.g. 2001:db8:FF::1 etc. best Enno Loopbacks are often used for management, iBGP etc and having short and easy to read addresses can be helpful. Something like 2001:db8::1 is easier to remember and type correctly than e.g. 2001:db8:18ba:ff42::1 :)

Cheers, Sander

-- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator =======================================================

On 10/11/2014 8:41 AM, Faisal Imtiaz wrote:

For Router Loopback Address .... what is wisdom in allocating a /64 vs /128 ?

The number of IPs addresses used on them subnets on them loopbacks is as far as I can foresee only one [for each loopback]. So a subnet of size "one address" should do it. And that seems to be the same in v4 and v6 Frank

On 10/12/14 3:00 PM, William Herrin wrote:

On Sat, Oct 11, 2014 at 1:41 AM, Faisal Imtiaz <faisal@snappytelecom.net> wrote:

...

A follow up question on this topic..

For Router Loopback Address .... what is wisdom in allocating a /64 vs /128 ? (the BCOP document suggests this, but does not offer any explanation or merits of one over the other).

Hi Faisal,

One of the viewpoints held by some in the IETF is that an IPv6 address is not 128 bits. Rather, it is 64 bits of network space and 64 bits of host space. I'm told this viewpoint is responsible for the existence of a 128 bit address instead of IPv6 using 64 bit addresses.

If you follow that reasoning, the subnet mask should always be /64, no matter where the address is assigned.

https://tools.ietf.org/html/rfc6164 Is a standards track document. it is imho a repudiation of the assumptions about the dimensions of the host field.

There are, of course, excellent operational reasons not to religiously follow that plan.

Regards, Bill Herrin

On Oct 9, 2014, at 3:04 PM, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:

On 9 October 2014 23:18, Roland Dobbins <rdobbins@arbor.net> wrote:

...

On Oct 10, 2014, at 4:13 AM, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:

...

My colleges wanted to completely drop using public IP addressing in the infrastructure.

Your colleagues are wrong. Again, see RFC6752.

Yes, for using private IP addressing RFC 6752 applies and it is why we are not doing it. But you seem to completely fail to understand that RFC 6752 does not apply to the proposed solution. NONE of the problems listed in RFC 6752 are a problem with using unnumbered interfaces. Traceroute works. ICMP works. There are no private IP addresses that gets filtered.

...

I am wondering if all the nay sayers would not agree that is it better to have a single public loopback address shared between all my interfaces, than to go with private addressing completely?

This is a false dichotomy.

...

Because frankly, that is the alternative.

It isn't the only alternative. The *optimal* alternative is to use publicly-routable link addresses, and then protect your infrastructure using iACLs, GTSM, CoPP, et. al.

I will as soon as you send me the check to buy addresses for all my links. I got a few.

But it appears you do not realize that we ARE using public IPs for our infrastructure. And we ARE using ACLs for protecting it. We are not using addresses for LINKS, neither public nor private. And it is not for security but to conserve expensive address space.

Addresses are not expensive. You can get up to a /40 from ARIN for $500 one-tim and $100/year. Are you really trying to convince me that you have ore than 16.7 million links? (and that’s assuming you assign a /64 per link). I’m sorry, but this argument utterly fails under any form of analysis. Owen

On Thu, Oct 9, 2014 at 5:13 PM, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:

But all this are customer facing interfaces, which do not really qualify for "point to point" links. I might consider adding interface addressing for IPv6, but for me IPv4 was the primary design parameter. Having IPv6 mirror the IPv4 setup means I have to think less about the setup. And we are really constrained to use as few IPv4 addresses as possible. We only got 1024 from RIPE and have to buy any additional at great expense.

Hi Baldur, If that's convenient, more power to you. I can think of nothing which breaks doing it that way, just a couple things that might be easier if you do it the other way.

My colleges wanted to completely drop using public IP addressing in the infrastructure.

This, however, is positively 100% broken. Do not use private IPs on your routers. The TCP protocol depends on receiving ICMP type 3 (destination unreachable) messages from your router. Without ICMP messages needed for path MTU detection, TCP connections somewhat randomly drop into a black hole. Have a customer who connects to your web server but never receives the web page? Look for the firewall blocking ICMP. If those ICMP messages originate from private IP addresses, they will not reach their destination. Private IPs tend to be dropped at multiple locations out on the public Internet. So don't use private IPs on routers. Routers must be able to generate ICMP destination unreachables with the expectation that they _will_ get through. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/> May I solve your unusual networking challenges?

I am sorry if I stepped on something sore. I am not dismissing any arguments, and I am genuinely interested in any advantages and disadvantages to the approach. There is more than one way to design a network and all I am saying is this far it is working great for me. The two disadvantages put forward so far have not been of any consequences in my network. But I am concerned that you say that I am still vulnerable to NDP attacks. Could you elaborate on that please? About loopback not being an unique identifier, please remember that none of the IP addresses on a host is that. An IP address belongs to the host, not the interface. Creating addresses on interfaces is just an alias for creating the same address as loopback and adding a net route on the interface. Don't believe me? Try it out! "I can’t help that your equipment is ill-behaved at best." That is not ill-behaved. It is the correct behavior. Try unplugging the netcable from your computer - you will NOT lose the IP-address unless you have a DHCP daemon that takes it away. Regards, Baldur On 9 October 2014 22:38, Owen DeLong <owen@delong.com> wrote:

On Oct 9, 2014, at 1:25 PM, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:

...

On 9 October 2014 22:01, Owen DeLong <owen@delong.com> wrote:

...

...

Why do people assign addresses to point-to-point links at all? You can just use a host /128 route to the loopback address of the peer. Saves you the hassle of coming up with new addresses for every link. Same trick works for IPv4 too.

Regards,

Baldur

<SARCASM>

And it makes your trace-routes across parallel links oh so easy to identify which of them is at fault for the packet loss, too.

</SARCASM>

There are a ton of other technologies with the same problem. Do you never use link aggregation? My "parallel links" are all link aggregations, so I would not have a way to identify links by traceroute anyway.

Your design problems don’t have to be mine.

Just because you have created that problem through another mechanism doesn’t pose a reason anyone else should accept the same problem in a different circumstance.

...

There are a number of good technical reasons to want distinct addresses on

...

point to point links.

I am sure there are. Tell me about them.

I gave you one. You decided to dismiss it on the basis of “it wouldn’t help me anyway because I use this other thing that is broken that way regardless.”

Some others (not a conclusive list by any means): Having public addresses in trace-routes, ideally with good reverse DNS is actually useful. Clarity is almost always an advantage over obscurity when one is troubleshooting something. Being able to ping the link address is useful for troubleshooting. Being able to source packets from a particular link address can be useful for troubleshooting.

...

I am not disputing that there are many reasons to sometimes use link addresses. My question is why do you do it by default?

...

So far we have heard two arguments:

1) You can ping the link address. I assume his equipment will down the address if the link is down. My equipment does not do this, I can ping it as long it is administrative up no matter link status. So this test is useless to me. I am monitoring links by SNMP anyway.

I can’t help that your equipment is ill-behaved at best. Perhaps you should consider alternatives. I certainly don’t think that designing everyone else’s network to the level of brokenness in your particular environment is particularly valid.

...

2) Parallel links. I don't have many of those, and the ones I have are

link

...

aggregations. MPLS interferes with this too.

On the other hand not using link addresses has some advantages:

1) You don't need to assign and document them.

Sure you do, it’s just harder. You’re now using essentially an “unnumbered interface” which needs to be documented as such so that people know that when a given loopback shows up, it’s not a unique identifier, but ambiguous across several interfaces.

...

2) It is easy to think about: Router A talks to Router B on link AB. Every router has only one address so you don't need to remember which address to use.

I don’t have to remember which address to use normally. This is not an advantage. I can always use the loopback address to talk to a router if my environment is correctly functioning. If it is not, removing the ambiguity of unnumbered link addresses is more helpful than being able to use one address for each router while unable to know how traffic is actually flowing as a result.

...

3) You avoid having a lot of addresses configured on your router.

I don’t see this as an advantage. For a number of reasons (some of which I have expressed above) it is, in fact, a disadvantage.

...

4) You are immune to all the NDP attacks.

No you aren’t. You just change the nature of those attacks.

...

5) You are immune to the monthly NANOG debate about using /127 vs /126 vs /124 vs /64. The correct answer is clearly use /128 :-).

Except that it’s clearly an incorrect answer, IMHO.

Owen

* Baldur Norddahl

Why do people assign addresses to point-to-point links at all? You can just use a host /128 route to the loopback address of the peer. Saves you the hassle of coming up with new addresses for every link.

Why do you need those host routes? Most IPv6 IGPs work just fine without global addresses or host routes. https://tools.ietf.org/html/draft-ietf-opsec-lla-only-11 Tore

Policy allows any ISP (LIR) with need greater than /32 to easily qualify for what they need up to /12. I know of at least two entities that have applied for and with minimal effort and appropriate justification, received /24 allocations and many with /28s. Owen

On Oct 9, 2014, at 07:00, Paige Thompson <paigeadele@gmail.com> wrote:

makes more sense to hand out /48s imho. theres only a mere 65k /48s per /32 (or something like that), though.

...

On 10/09/14 12:29, Mark Andrews wrote: In message <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu>, manning bill writes:

...

yes! by ALL means, hand out /48s. There is huge benefit to announcing = all that dark space, esp. when virtually no one practices BCP-38, esp in IPv6 land.

/bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 and if everyone hands out /48's you just filter /48's. With a mix of /56 and /48 you need to filter at the /56 level. Given enterpises are getting /48's it will be simpler overall for everyone to get /48's.

...

...

On 8October2014Wednesday, at 18:31, Mark Andrews <marka@isc.org> wrote:

...

I am planning out our IPv6 deployment right now and I am trying to =

=20 Give them a /48. This is IPv6 not IPv4. Take the IPv4 glasses off and put on the IPv6 glasses. Stop constraining your customers because you feel that it is a waste. It is not a waste!!!! It will also reduce the number of exceptions you need to process and make over all administration easier. =20 As for only two subnets, I expect lots of equipment to request prefixes in the future not just traditional routers. It will have descrete internal components which communicate using IPv6 and those components need to talk to each other and the world. In a IPv4 world they would be NAT'd. In a IPv6 world the router requests a prefix. =20 Mark =20 In message <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads>, = Erik Sun dberg writes: figure o=3D

...

ut our default allocation for customer LAN blocks. So what is = everyone givi=3D ng for a default LAN allocation for IPv6 Customers. I guess the idea = of ha=3D nding a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me = cring=3D e at the waste. Especially when you know 90% of customers will never = have m=3D ore than 2 or 3 subnets. As I see it the customer can always ask for = more I=3D Pv6 Space. =20 /64 /60 /56 /48 =20 Small Customer? Medium Customer? Large Customer? =20 Thanks =20 Erik =20 ________________________________ =20 CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, = files =3D or previous e-mail messages attached to it may contain confidential = informa=3D tion that is legally privileged. If you are not the intended = recipient, or =3D a person responsible for delivering it to the intended recipient, you = are h=3D ereby notified that any disclosure, copying, distribution or use of = any of =3D the information contained in or attached to this transmission is = STRICTLY P=3D ROHIBITED. If you have received this transmission in error please = notify th=3D e sender immediately by replying to this e-mail. You must destroy the = origi=3D nal transmission and its attachments without reading or saving in any = manne=3D r. Thank you. --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

...

Selection of a default prefix is easy. Here are the steps.

4. Keeping in mind

4.1 Prefixes longer than somewhere around /48 to /56 may be excluded from the global routing table

4.1a Prefix cutouts of any size (including /48) from inside your /32 or larger block may be excluded from the global routing table. Folks who are multihomed and thus need to advertise their own block with BGP should be referred to ARIN for a direct assignment. Folks who aren't multihomed, well, until given evidence otherwise I claim there are no single-homed entities who will use 65,000 LANs, let alone more. =============================================

This brings up another interesting question... We operate Two separate networks in two geographical locations (Two ASN), we have a single /32 allocation from ARIN. Question: Should we be asking ARIN for another /32 so that each network has it's own /32 or should be break out the /32 into /36 and use these in each of the geographies ? Regards Faisal Imtiaz Snappy Internet & Telecom

On Oct 9, 2014, at 7:31 AM, Faisal Imtiaz <faisal@snappytelecom.net> wrote:

...

...

Selection of a default prefix is easy. Here are the steps.

4. Keeping in mind

4.1 Prefixes longer than somewhere around /48 to /56 may be excluded from the global routing table

4.1a Prefix cutouts of any size (including /48) from inside your /32 or larger block may be excluded from the global routing table. Folks who are multihomed and thus need to advertise their own block with BGP should be referred to ARIN for a direct assignment. Folks who aren't multihomed, well, until given evidence otherwise I claim there are no single-homed entities who will use 65,000 LANs, let alone more. =============================================

This brings up another interesting question...

We operate Two separate networks in two geographical locations (Two ASN), we have a single /32 allocation from ARIN.

Question: Should we be asking ARIN for another /32 so that each network has it's own /32 or should be break out the /32 into /36 and use these in each of the geographies ?

Depends on your needs… Either is a viable solution, depending on your circumstances. ARIN has an MDN policy which would facilitate your acquisition of a second /32. Owen

In message <126729399.131320.1412825855138.JavaMail.zimbra@snappytelecom.net>, Faisal Imtiaz writes:

We are going thru a similar process.. from all of my reading, best practice d iscussions etc..

Here is what i have understood so far:-

Residential Customers: /64

NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Small & Medium size Business Customers: /56

Large Business size or a multi-location Business Customer: /48

Don't skimp on allocating the subnets like we do on IPv4 Better to be 'wasteful' than have to come back to re-number or re-allocate .

Regards

Faisal Imtiaz Snappy Internet & Telecom

----- Original Message -----

...

From: "Erik Sundberg" <ESundberg@nitelusa.com> To: nanog@nanog.org Sent: Wednesday, October 8, 2014 9:18:16 PM Subject: IPv6 Default Allocation - What size allocation are you giving out

I am planning out our IPv6 deployment right now and I am trying to figure o ut our default allocation for customer LAN blocks. So what is everyone giving for a default LAN allocation for IPv6 Customers. I guess the idea of handing a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me cringe at the waste. Especially when you know 90% of customers will never have more than 2 or 3 subnets. As I see it the customer can always ask for more IPv6 Space.

/64 /60 /56 /48

Small Customer? Medium Customer? Large Customer?

Thanks

Erik

________________________________

CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential informatio n that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.

-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

Like I said, this was my understanding.... I am glad that it is being pointed out to be in-correct.... I don't have a reason for why a /64 as much as I also don't have any reason Why NOT.... So, let me ask the question in a different manner... What is the wisdom / reasoning behind needing to give a /56 to a Residential customer (vs a /64). Regards. Faisal Imtiaz Snappy Internet & Telecom ----- Original Message -----

From: "Sam Silvester" <sam.silvester@gmail.com> To: "Faisal Imtiaz" <faisal@snappytelecom.net> Cc: "Erik Sundberg" <ESundberg@nitelusa.com>, "NANOG" <nanog@nanog.org> Sent: Wednesday, October 8, 2014 11:47:01 PM Subject: Re: IPv6 Default Allocation - What size allocation are you giving out

Why would you only allocate a residential customer a single /64?

That's totally short sighted in my view.

On Thu, Oct 9, 2014 at 2:07 PM, Faisal Imtiaz < faisal@snappytelecom.net > wrote:

...

We are going thru a similar process.. from all of my reading, best practice discussions etc..

...

Here is what i have understood so far:-

...

Residential Customers: /64

...

Small & Medium size Business Customers: /56

...

Large Business size or a multi-location Business Customer: /48

...

Don't skimp on allocating the subnets like we do on IPv4

...

Better to be 'wasteful' than have to come back to re-number or re-allocate .

...

Regards

...

Faisal Imtiaz

...

Snappy Internet & Telecom

...

----- Original Message -----

...

...

From: "Erik Sundberg" < ESundberg@nitelusa.com >

...

...

To: nanog@nanog.org

...

...

Sent: Wednesday, October 8, 2014 9:18:16 PM

...

...

Subject: IPv6 Default Allocation - What size allocation are you giving out

...

...

...

...

I am planning out our IPv6 deployment right now and I am trying to figure out

...

...

our default allocation for customer LAN blocks. So what is everyone giving

...

...

for a default LAN allocation for IPv6 Customers. I guess the idea of

...

...

handing a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me

...

...

cringe at the waste. Especially when you know 90% of customers will never

...

...

have more than 2 or 3 subnets. As I see it the customer can always ask for

...

...

more IPv6 Space.

...

...

...

...

/64

...

...

/60

...

...

/56

...

...

/48

...

...

...

...

Small Customer?

...

...

Medium Customer?

...

...

Large Customer?

...

...

...

...

Thanks

...

...

...

...

Erik

...

...

...

...

________________________________

...

...

...

...

CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or

...

...

previous e-mail messages attached to it may contain confidential information

...

...

that is legally privileged. If you are not the intended recipient, or a

...

...

person responsible for delivering it to the intended recipient, you are

...

...

hereby notified that any disclosure, copying, distribution or use of any of

...

...

the information contained in or attached to this transmission is STRICTLY

...

...

PROHIBITED. If you have received this transmission in error please notify

...

...

the sender immediately by replying to this e-mail. You must destroy the

...

...

original transmission and its attachments without reading or saving in any

...

...

manner. Thank you.

...

...

Awesome, Thank you Royce, the missing piece has clicked in place... :) Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support@Snappytelecom.net ----- Original Message -----

From: "Royce Williams" <royce@techsolvency.com> To: "Faisal Imtiaz" <faisal@snappytelecom.net> Cc: "Sam Silvester" <sam.silvester@gmail.com>, "NANOG" <nanog@nanog.org> Sent: Thursday, October 9, 2014 12:14:51 AM Subject: Re: IPv6 Default Allocation - What size allocation are you giving out

On Wed, Oct 8, 2014 at 8:07 PM, Faisal Imtiaz < faisal@snappytelecom.net > wrote:

...

Like I said, this was my understanding.... I am glad that it is being pointed out to be in-correct....

...

I don't have a reason for why a /64 as much as I also don't have any reason Why NOT....

...

So, let me ask the question in a different manner...

...

What is the wisdom / reasoning behind needing to give a /56 to a Residential customer (vs a /64).

Quoting RFC6177 (successor to RFC3177):

While the /48 recommendation does simplify address space management for end sites, it has also been widely criticized as being wasteful. For example, a large business (which may have thousands of employees) would, by default, receive the same amount of address space as a home user, who today typically has a single (or small number of) LAN and a small number of devices (dozens or less). While it seems likely that the size of a typical home network will grow over the next few decades, it is hard to argue that home sites will make use of 65K subnets within the foreseeable future. At the same time, it might be tempting to give home sites a single /64, since that is already significantly more address space compared with today's IPv4 practice. However, this precludes the expectation that even home sites will grow to support multiple subnets going forward. Hence, it is strongly intended that even home sites be given multiple subnets worth of space, by default. Hence, this document still recommends giving home sites significantly more than a single /64, but does not recommend that every home site be given a /48 either.

A change in policy (such as above) would have a significant impact on address consumption projections and the expected longevity for IPv6. For example, changing the default assignment from a /48 to /56 (for the vast majority of end sites, e.g., home sites) would result in a savings of up to 8 bits, reducing the "total projected address consumption" by (up to) 8 bits or two orders of magnitude. (The exact amount of savings depends on the relative number of home users compared with the number of larger sites.)

The above-mentioned goals of RFC 3177 can easily be met by giving home users a default assignment of less than /48, such as a /56.

Royce

Yep, understood....... in the ipv6 world we are looking at needing a significantly more 'routing' connectivity, than we do in the current ipv4 world. Thank you. Faisal Imtiaz Snappy Internet & Telecom ----- Original Message -----

From: "Kenneth Finnegan" <kennethfinnegan2007@gmail.com> To: "Faisal Imtiaz" <faisal@snappytelecom.net>, nanog@nanog.org Sent: Thursday, October 9, 2014 12:16:59 AM Subject: Re: IPv6 Default Allocation - What size allocation are you giving out

...

What is the wisdom / reasoning behind needing to give a /56 to a Residential customer (vs a /64).

What happens when the resident pulls their car into their garage and their car requests a unique /64 so the various computers on the CAN can start syncing with the Internet? Car's media center starts downloading new music, engine controller uploads diagnostics, GPS navigator starts downloading new maps, etc.

Different example: people like Jim Gettys and Dave Taht are pushing for consumer routers to start routing between WiFi and Ethernet instead of bridging the two out of the box, since WiFi tends to fall over so hard on multicast/broadcast traffic. Suddenly their router needs two subnets, and either one of them doesn't work, or they have to live with reduced WiFi performance. -- Kenneth Finnegan http://blog.thelifeofkenneth.com/

A /60, /56, /52 or /48 allows the client to run multiple SLAAC subnets (16, 256, 4096 or 65536) and to have the reverse ip6.arpa zone delegated on a nibble boundary.

Understood...

There is plenty of address space even handing out /48's to everyone.

Also Understood.

Only short sighted ISP's hand out /56's to residential customers.

I am curious as to why you say it is short sighted? what is the technical or otherwise any other reasoning for such statement ? Faisal Imtiaz Snappy Internet & Telecom ----- Original Message -----

From: "Mark Andrews" <marka@isc.org> To: "Faisal Imtiaz" <faisal@snappytelecom.net> Cc: "Sam Silvester" <sam.silvester@gmail.com>, "NANOG" <nanog@nanog.org> Sent: Thursday, October 9, 2014 12:25:28 AM Subject: Re: IPv6 Default Allocation - What size allocation are you giving out

In message <1627782497.131675.1412827629110.JavaMail.zimbra@snappytelecom.net>, Faisal Imtiaz writes:

...

Like I said, this was my understanding.... I am glad that it is being pointed out to be in-correct....

I don't have a reason for why a /64 as much as I also don't have any reason W hy NOT....

Because /64 only allows for a single subnet running SLAAC with currently defined specifications.

...

So, let me ask the question in a different manner... What is the wisdom / reasoning behind needing to give a /56 to a Residential customer (vs a /64).

A /60, /56, /52 or /48 allows the client to run multiple SLAAC subnets (16, 256, 4096 or 65536) and to have the reverse ip6.arpa zone delegated on a nibble boundary. There is plenty of address space even handing out /48's to everyone. Only short sighted ISP's hand out /56's to residential customers.

...

Regards.

Faisal Imtiaz Snappy Internet & Telecom ----- Original Message -----

...

From: "Sam Silvester" <sam.silvester@gmail.com> To: "Faisal Imtiaz" <faisal@snappytelecom.net> Cc: "Erik Sundberg" <ESundberg@nitelusa.com>, "NANOG" <nanog@nanog.org> Sent: Wednesday, October 8, 2014 11:47:01 PM Subject: Re: IPv6 Default Allocation - What size allocation are you giving out

...

Why would you only allocate a residential customer a single /64?

...

That's totally short sighted in my view.

...

On Thu, Oct 9, 2014 at 2:07 PM, Faisal Imtiaz < faisal@snappytelecom.net

...

wrote:

...

...

We are going thru a similar process.. from all of my reading, best practi ce discussions etc..

...

...

Here is what i have understood so far:-

...

...

Residential Customers: /64

...

...

Small & Medium size Business Customers: /56

...

...

Large Business size or a multi-location Business Customer: /48

...

...

Don't skimp on allocating the subnets like we do on IPv4

...

Better to be 'wasteful' than have to come back to re-number or re-allocat e .

...

...

Regards

...

...

Faisal Imtiaz

...

Snappy Internet & Telecom

...

...

----- Original Message -----

...

...

From: "Erik Sundberg" < ESundberg@nitelusa.com >

...

...

To: nanog@nanog.org

...

...

Sent: Wednesday, October 8, 2014 9:18:16 PM

...

...

Subject: IPv6 Default Allocation - What size allocation are you giving out

...

...

...

...

I am planning out our IPv6 deployment right now and I am trying to figu re out

...

...

our default allocation for customer LAN blocks. So what is everyone giving

...

...

for a default LAN allocation for IPv6 Customers. I guess the idea of

...

...

handing a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me

...

...

cringe at the waste. Especially when you know 90% of customers will nev er

...

...

have more than 2 or 3 subnets. As I see it the customer can always ask for

...

...

more IPv6 Space.

...

...

...

...

/64

...

...

/60

...

...

/56

...

...

/48

...

...

...

...

Small Customer?

...

...

Medium Customer?

...

...

Large Customer?

...

...

...

...

Thanks

...

...

...

...

Erik

...

...

...

...

________________________________

...

...

...

...

CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or

...

...

previous e-mail messages attached to it may contain confidential information

...

...

that is legally privileged. If you are not the intended recipient, or a

...

...

person responsible for delivering it to the intended recipient, you are

...

...

hereby notified that any disclosure, copying, distribution or use of an y of

...

...

the information contained in or attached to this transmission is STRICT LY

...

...

PROHIBITED. If you have received this transmission in error please noti fy

...

...

the sender immediately by replying to this e-mail. You must destroy the

...

...

original transmission and its attachments without reading or saving in any

...

...

manner. Thank you.

...

...

-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

======================================

...

...

Only short sighted ISP's hand out /56's to residential customers.

I am curious as to why you say it is short sighted? what is the technical or otherwise any other reasoning for such statement ?

256 is *not* a big number of subnets. By restricting the number of subnets residences get you restrict what >developers will design for. Subnets don't need to be scares resource. ISP's that default to /56 are making them a >scares resource. =======================================

So, this is more of a 'opinion' / 'feel' (with all due respect) comment, and not something which has a (presently) compelling technical reasoning behind it ? Regards Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support@Snappytelecom.net ----- Original Message -----

From: "Mark Andrews" <marka@isc.org> To: "Faisal Imtiaz" <faisal@snappytelecom.net> Cc: "Sam Silvester" <sam.silvester@gmail.com>, "NANOG" <nanog@nanog.org> Sent: Thursday, October 9, 2014 12:40:07 AM Subject: Re: IPv6 Default Allocation - What size allocation are you giving out

In message <482678376.131852.1412829159356.JavaMail.zimbra@snappytelecom.net>, Faisal Imtiaz writes:

...

...

A /60, /56, /52 or /48 allows the client to run multiple SLAAC subnets (16, 256, 4096 or 65536) and to have the reverse ip6.arpa zone delegated on a nibble boundary.

Understood...

...

There is plenty of address space even handing out /48's to everyone.

Also Understood.

...

Only short sighted ISP's hand out /56's to residential customers.

I am curious as to why you say it is short sighted? what is the technical or otherwise any other reasoning for such statement ?

256 is *not* a big number of subnets. By restricting the number of subnets residences get you restrict what developers will design for. Subnets don't need to be scares resource. ISP's that default to /56 are making them a scares resource.

Mark

...

Faisal Imtiaz Snappy Internet & Telecom -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

To paraphrase a post on this list a while ago (my apologies for lack of reference). There are two kinds of waste: - the first kind of waste is providing 'too many' subnets for someone; - the second kind of waste is leaving the space unallocated forever. If we choose the first option and somehow burn through the 35 trillion /48's out of the first /3 we're drawing from (ie, almost 5000 /48's for every person on the planet) then we can always reconsider how to be more conservative with the remaining 88% of unallocated IPv6 space. -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Faisal Imtiaz Sent: October-09-14 12:45 AM To: Mark Andrews Cc: NANOG Subject: Re: IPv6 Default Allocation - What size allocation are you giving out ======================================

...

...

Only short sighted ISP's hand out /56's to residential customers.

I am curious as to why you say it is short sighted? what is the technical or otherwise any other reasoning for such statement ?

256 is *not* a big number of subnets. By restricting the number of subnets residences get you restrict what >developers will design for. Subnets don't need to be scares resource. ISP's that default to /56 are making them a >scares resource. =======================================

So, this is more of a 'opinion' / 'feel' (with all due respect) comment, and not something which has a (presently) compelling technical reasoning behind it ? Regards Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support@Snappytelecom.net ----- Original Message -----

From: "Mark Andrews" <marka@isc.org> To: "Faisal Imtiaz" <faisal@snappytelecom.net> Cc: "Sam Silvester" <sam.silvester@gmail.com>, "NANOG" <nanog@nanog.org> Sent: Thursday, October 9, 2014 12:40:07 AM Subject: Re: IPv6 Default Allocation - What size allocation are you giving out

In message <482678376.131852.1412829159356.JavaMail.zimbra@snappytelecom.net>, Faisal Imtiaz writes:

...

...

A /60, /56, /52 or /48 allows the client to run multiple SLAAC subnets (16, 256, 4096 or 65536) and to have the reverse ip6.arpa zone delegated on a nibble boundary.

Understood...

...

There is plenty of address space even handing out /48's to everyone.

Also Understood.

...

Only short sighted ISP's hand out /56's to residential customers.

I am curious as to why you say it is short sighted? what is the technical or otherwise any other reasoning for such statement ?

256 is *not* a big number of subnets. By restricting the number of subnets residences get you restrict what developers will design for. Subnets don't need to be scares resource. ISP's that default to /56 are making them a scares resource.

Mark

...

Faisal Imtiaz Snappy Internet & Telecom -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

In message <2083423091.131955.1412829918586.JavaMail.zimbra@snappytelecom.net>, Faisal Imtiaz writes:

======================================

...

...

...

Only short sighted ISP's hand out /56's to residential customers.

I am curious as to why you say it is short sighted? what is the technical or otherwise any other reasoning for such statement ?

256 is *not* a big number of subnets. By restricting the number of subnets residences get you restrict what >developers will design for. Subnets don't need to be scares resource. ISP's that default to /56 are making them a >sc ares resource. =======================================

So, this is more of a 'opinion' / 'feel' (with all due respect) comment, and not something which has a (presently) compelling technical reasoning behind i t ?

There are thousands of examples of things being designed for the lowest common denominator. There are thousand of examples of "this will never be reached" only to have the thing be reached. Every time this happens it becomes expensive to correct. It causes operational issues for those on the leading edge. Your home router should support thousands of internal routes and be able to hand out thousands of prefixes all in a $50 box. Memory is cheap. It doesn't require lots of cpu to support something like a house even with thousands of subnets. If /56 becomes the norm the boxes will end up being designed for 256 subnets rather than the thousands it should be designed for thousands the hardware is capable of supporting. This unfortunately is human nature.

Regards

Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232

Help-desk: (305)663-5518 Option 2 or Email: Support@Snappytelecom.net

----- Original Message -----

...

From: "Mark Andrews" <marka@isc.org> To: "Faisal Imtiaz" <faisal@snappytelecom.net> Cc: "Sam Silvester" <sam.silvester@gmail.com>, "NANOG" <nanog@nanog.org> Sent: Thursday, October 9, 2014 12:40:07 AM Subject: Re: IPv6 Default Allocation - What size allocation are you giving out

In message <482678376.131852.1412829159356.JavaMail.zimbra@snappytelecom.net>, Faisal Imtiaz writes:

...

...

A /60, /56, /52 or /48 allows the client to run multiple SLAAC subnets (16, 256, 4096 or 65536) and to have the reverse ip6.arpa zone delegated on a nibble boundary.

Understood...

...

There is plenty of address space even handing out /48's to everyone.

Also Understood.

...

Only short sighted ISP's hand out /56's to residential customers.

I am curious as to why you say it is short sighted? what is the technical or otherwise any other reasoning for such statement ?

256 is *not* a big number of subnets. By restricting the number of subnets residences get you restrict what developers will design for. Subnets don't need to be scares resource. ISP's that default to /56 are making them a scares resource.

Mark

...

Faisal Imtiaz Snappy Internet & Telecom -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

Mark,

...

...

Only short sighted ISP's hand out /56's to residential customers.

...

I am curious as to why you say it is short sighted? what is the technical or otherwise any other reasoning for such statement ?

256 is *not* a big number of subnets. By restricting the number of subnets residences get you restrict what developers will design for. Subnets don't need to be scares resource. ISP's that default to /56 are making them a scares resource.

The excerpt Royce quoted from RFC6177 (requoted below) seems to back away from /48s by default to all resi users and land in a somewhat vague "more than a /64 please, but we're not specifically recommending /48s across the board for residential" before specifically mentioning /56 assignments. The general push in the community is towards /48 across the board. Any comments on why the RFC backs away from that? Is this just throwing a bone to the masses complaining about "waste"? btw: hat tip to Peter Rocca for a kind of scale we're talking about for allocatable space. -- Hugo

Quoting RFC6177 (successor to RFC3177):

While the /48 recommendation does simplify address space management for end sites, it has also been widely criticized as being wasteful. For example, a large business (which may have thousands of employees) would, by default, receive the same amount of address space as a home user, who today typically has a single (or small number of) LAN and a small number of devices (dozens or less). While it seems likely that the size of a typical home network will grow over the next few decades, it is hard to argue that home sites will make use of 65K subnets within the foreseeable future. At the same time, it might be tempting to give home sites a single /64, since that is already significantly more address space compared with today's IPv4 practice. However, this precludes the expectation that even home sites will grow to support multiple subnets going forward. Hence, it is strongly intended that even home sites be given multiple subnets worth of space, by default. Hence, this document still recommends giving home sites significantly more than a single /64, but does not recommend that every home site be given a /48 either.

A change in policy (such as above) would have a significant impact on address consumption projections and the expected longevity for IPv6. For example, changing the default assignment from a /48 to /56 (for the vast majority of end sites, e.g., home sites) would result in a savings of up to 8 bits, reducing the "total projected address consumption" by (up to) 8 bits or two orders of magnitude. (The exact amount of savings depends on the relative number of home users compared with the number of larger sites.)

The above-mentioned goals of RFC 3177 can easily be met by giving home users a default assignment of less than /48, such as a /56.

On 9 October 2014 05:40, Mark Andrews <marka@isc.org> wrote:

In message < 482678376.131852.1412829159356.JavaMail.zimbra@snappytelecom.net>, Faisal Imtiaz writes:

...

...

Only short sighted ISP's hand out /56's to residential customers.

I am curious as to why you say it is short sighted? what is the technical or otherwise any other reasoning for such statement ?

256 is *not* a big number of subnets. By restricting the number of subnets residences get you restrict what developers will design for. Subnets don't need to be scares resource. ISP's that default to /56 are making them a scares resource.

My moment of clarity came when I got a /56 routed to my house and started using it. I started off thinking that 256 was a huge number of subnets, more than I could ever need. What I realised was that (sticking to best practices) a /56 only allows you one further level of delegation, and I found that to be more of a barrier than the number of subnets. In the same way that you stop thinking "/64 is a lot of addresses" and start thinking "/64 is a network" I find it helps to stop thinking "/48 is 65536 subnets" and start thinking "/48 allows you up to 4 levels of delegation." Dan

On (2014-10-09 15:25 +1100), Mark Andrews wrote: Hi,

Because /64 only allows for a single subnet running SLAAC with currently defined specifications.

I fully agree that larger than 64 must be allocation, in mobile internet, residental DSL, everywhere. I don't think it will happen, but I think it should and I'm happy to say that I was able to impact the national regulatory authority to include this in their recommendation for how IPv6 should be provided. Having routable network is only benefit of IPv6 over IPv4, and if we just give customers connected /64 network, without routing /56 there, then customers will need NAT. However, technically SLAAC is happy with arbitrarily small network, and some kit support this (like Cisco). You're going to have to do DAD anyhow, because uniqueness is not guaranteed. -- ++ytti

On (2014-10-09 00:37 -0700), Owen DeLong wrote:

Sadly there are pieces of 3GPP that limit LTE to single /64 already. These should, IMHO, be fixed.

According to the national IPv6 residential recommendation 3GPP release 10 offers prefix delegation, which will facilitate this.

...

Having routable network is only benefit of IPv6 over IPv4, and if we just give customers connected /64 network, without routing /56 there, then customers will need NAT.

It’s not the only benefit, it is one of many benefits.

Yeah mailing list volume is the other one. -- ++ytti

I’ll go a step further… If you give a residential customer the /48 that they should be getting, then as DHCP-PD and automatic topologies become more widespread, you have enabled flexibility in the breadth and depth of the bit patterns used to facilitate such hierarchies in the home network environment. If you limit them to 8 bits of subnetting, you are very limited in the constructs (1x8, 2x4, 4x2, or 8x1) which can be achieved. Further, there’s really no advantage to keeping so much extra IPv6 address space on the shelves long past the expiration of the protocol’s useful life. I guarantee you that unless we start doing really stupid things (like using IPv6 /48s as serial numbers for cars), giving /48s to residential customers will not exhaust the current /3 (1/8th of the total IPv6 space) before we hit some other limitation of the protocol. Owen On Oct 8, 2014, at 9:07 PM, Faisal Imtiaz <faisal@snappytelecom.net> wrote:

Like I said, this was my understanding.... I am glad that it is being pointed out to be in-correct....

I don't have a reason for why a /64 as much as I also don't have any reason Why NOT....

So, let me ask the question in a different manner... What is the wisdom / reasoning behind needing to give a /56 to a Residential customer (vs a /64).

Regards.

Faisal Imtiaz Snappy Internet & Telecom ----- Original Message -----

...

From: "Sam Silvester" <sam.silvester@gmail.com> To: "Faisal Imtiaz" <faisal@snappytelecom.net> Cc: "Erik Sundberg" <ESundberg@nitelusa.com>, "NANOG" <nanog@nanog.org> Sent: Wednesday, October 8, 2014 11:47:01 PM Subject: Re: IPv6 Default Allocation - What size allocation are you giving out

...

Why would you only allocate a residential customer a single /64?

...

That's totally short sighted in my view.

...

On Thu, Oct 9, 2014 at 2:07 PM, Faisal Imtiaz < faisal@snappytelecom.net > wrote:

...

...

We are going thru a similar process.. from all of my reading, best practice discussions etc..

...

...

Here is what i have understood so far:-

...

...

Residential Customers: /64

...

...

Small & Medium size Business Customers: /56

...

...

Large Business size or a multi-location Business Customer: /48

...

...

Don't skimp on allocating the subnets like we do on IPv4

...

Better to be 'wasteful' than have to come back to re-number or re-allocate .

...

...

Regards

...

...

Faisal Imtiaz

...

Snappy Internet & Telecom

...

...

----- Original Message -----

...

...

From: "Erik Sundberg" < ESundberg@nitelusa.com >

...

...

To: nanog@nanog.org

...

...

Sent: Wednesday, October 8, 2014 9:18:16 PM

...

...

Subject: IPv6 Default Allocation - What size allocation are you giving out

...

...

...

...

I am planning out our IPv6 deployment right now and I am trying to figure out

...

...

our default allocation for customer LAN blocks. So what is everyone giving

...

...

for a default LAN allocation for IPv6 Customers. I guess the idea of

...

...

handing a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me

...

...

cringe at the waste. Especially when you know 90% of customers will never

...

...

have more than 2 or 3 subnets. As I see it the customer can always ask for

...

...

more IPv6 Space.

...

...

...

...

/64

...

...

/60

...

...

/56

...

...

/48

...

...

...

...

Small Customer?

...

...

Medium Customer?

...

...

Large Customer?

...

...

...

...

Thanks

...

...

...

...

Erik

...

...

...

...

________________________________

...

...

...

...

CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or

...

...

previous e-mail messages attached to it may contain confidential information

...

...

that is legally privileged. If you are not the intended recipient, or a

...

...

person responsible for delivering it to the intended recipient, you are

...

...

hereby notified that any disclosure, copying, distribution or use of any of

...

...

the information contained in or attached to this transmission is STRICTLY

...

...

PROHIBITED. If you have received this transmission in error please notify

...

...

the sender immediately by replying to this e-mail. You must destroy the

...

...

original transmission and its attachments without reading or saving in any

...

...

manner. Thank you.

...

...

You should probably increase those allocations. Residential & Small Business Customers: /56 Medium & Large size Business Customers: /48 Multi-location Business Customer: /48 per site On Wed, Oct 8, 2014 at 10:37 PM, Faisal Imtiaz <faisal@snappytelecom.net> wrote:

We are going thru a similar process.. from all of my reading, best practice discussions etc..

Here is what i have understood so far:-

Residential Customers: /64

Small & Medium size Business Customers: /56

Large Business size or a multi-location Business Customer: /48

Don't skimp on allocating the subnets like we do on IPv4 Better to be 'wasteful' than have to come back to re-number or re-allocate .

Regards

Faisal Imtiaz Snappy Internet & Telecom

The biggest issue I see with only giving a /64 is that many residential customers may have have two routers, if the modem is not bridged and does not have WiFi. Another issue would be for people who want to use the guest SSID of many routers. With IPv6 I could see each SSID getting a /64.

(PS If I wake up in the morning and find out that someone has hacked my CatGenie litter boxes, I will hunt you down). "NANOG: From Cat Poo to IPv6, We've Got It Covered" On Thu, Oct 9, 2014 at 12:09 AM, jamie rishaw <j@arpa.com> wrote:

This makes no sense.

I have two /48s routed to my house.

..to my house.

The idea that anyone is giving anything less than a 64 is unreasonable and will lead to an exponential growth in routing tables.. it's asinine and very short sighted.

Sure, back in the day, I had a server, a couple desktops and a BRI and wow who would need more than an ipv4 /28--but let's face reality here--every thing, every switch, every night bulb, every door, every window, every skylight, every temperature sensor, every tv, every device that a friend brings over or even any device that I allow public access to.. every cat, every dog, every hamster is going to be microchipped and every single unit is going to need to be accessible.... Hell, I have two ips/one each for each of my two cat boxes that tell me current status, c'mon.

My TiVos, my game consoles, my cable boxes, my two printers.. all have their own address.

To think in an unframed context that you know what everyone everywhere will need is nothing short of naive and is everything elementarily assumptive of (ahem) The Internet of Things.

The examples I gave are just for my house.. now multiply that times a small, medium, large, xl, enterprise or global entity and do the math

These arguments and debates make me sad. I suppose it's my own fault for assuming that everyone in this ML is a forward thinker. -j

On Wed, Oct 8, 2014 at 8:18 PM, Erik Sundberg <ESundberg@nitelusa.com> wrote:

...

I am planning out our IPv6 deployment right now and I am trying to figure out our default allocation for customer LAN blocks. So what is everyone giving for a default LAN allocation for IPv6 Customers. I guess the idea of handing a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me cringe at the waste. Especially when you know 90% of customers will never have more than 2 or 3 subnets. As I see it the customer can always ask for more IPv6 Space.

/64 /60 /56 /48

Small Customer? Medium Customer? Large Customer?

Thanks

Erik

________________________________

CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.

-- jamie rishaw // .com.arpa@j <- reverse it. ish.

"...let's consider this world like a family and care about each other..." -Malala Yousafzai

-- jamie rishaw // .com.arpa@j <- reverse it. ish. "...let's consider this world like a family and care about each other..." -Malala Yousafzai

On Thu, Oct 9, 2014 at 5:09 AM, jamie rishaw <j@arpa.com> wrote: .....

These arguments and debates make me sad. I suppose it's my own fault for assuming that everyone in this ML is a forward thinker.

Get used to disappointment.

Nanites, window blinds, and soda cans, I can believe. Molecules, I tend to doubt. I think we will see larger network segments, but I think we will also see greater separation of networks into segments along various administrative and/or automatic aggregation boundaries. The virtual topologies you describe will likely also have related prefix consequences. Owen On Oct 9, 2014, at 7:39 AM, Roland Dobbins <rdobbins@arbor.net> wrote:

On Oct 9, 2014, at 2:15 PM, Owen DeLong <owen@delong.com> wrote:

...

Also, claiming that 90% will never have more than 2 or 3 subnets simply displays a complete lack of imagination.

On the contrary, I believe that the increase in the potential address pool size will lead to much flatter, less hierarchical networks - while at the same time leading to most nodes being highly multi-homed into various virtual topologies, thereby leading to significant increases of addresses per node.

A 'node' being things like molecules, nanites, window blinds, soda cans, etc.

---------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>

Equo ne credite, Teucri.

-- Laocoön

On Oct 9, 2014, at 10:04 AM, Roland Dobbins <rdobbins@arbor.net> wrote:

On Oct 9, 2014, at 11:31 PM, Owen DeLong <owen@delong.com> wrote:

...

Nanites, window blinds, and soda cans, I can believe. Molecules, I tend to doubt.

Various controlled compounds have been chemically tagged for years. NFC or something similar is the logical next step (it also holds a lot of promise and implications for supply-chains in general, physical security applications, transportation, etc.).

But those chemical tags are generally multiple, not single molecules. NFC still requires something with a unique radiographic property, so not likely in a single molecule.

...

I think we will see larger network segments, but I think we will also see greater separation of networks into segments along various administrative and/or automatic aggregation boundaries. The virtual topologies you describe will likely also have related prefix consequences.

Concur, but my guess is that they will be essentially superimposed, without any increase in hierarchy - in fact, quite the opposite.

Indeed, I think we will end up agreeing to disagree about this, but it will be interesting to see what happens over years to come. I suspect that the answer to which way this goes will be somewhat context sensitive. In some cases, hierarchies will be collapsed. In others, they will expand. Owen