On 2010-07-21 14:47, Marco Hogewoning wrote:

For a novice ? I wouldn't recommend it. From what I get back 'in the field' it's already hard enough to get people familliar to the whole concept of hexadecimal without going into bit level. But then again, if you are a fairly technical company maybe you can get away with it.

Not disagreeing, but here's a tool to make it easier: http://www.ipv6book.ca/allocation.html Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org

Hi! this page may be useful http://www.getipv6.info/index.php/IPv6_Addressing_Plans Rodolfo Simon Perreault <simon.perreault@ viagenie.ca> Para Marco Hogewoning 21/07/2010 22:02 <marcoh@marcoh.net> cc Nanog <nanog@nanog.org> Asunto Re: Addressing plan exercise for our IPv6 course On 2010-07-21 14:47, Marco Hogewoning wrote:

For a novice ? I wouldn't recommend it. From what I get back 'in the field' it's already hard enough to get people familliar to the whole concept of hexadecimal without going into bit level. But then again, if you are a fairly technical company maybe you can get away with it.

Not disagreeing, but here's a tool to make it easier: http://www.ipv6book.ca/allocation.html Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org _____________________________________________________________________ Mensaje analizado y protegido por Telefonica Empresas

Hi Antonio, That diagram looks interesting. We currently use slides with a bunch of animation to explain to this concept, but it may be nice to have something like this that people can keep as a printed version. By the way, this is what we think two possible answers are: http://bit.ly/9V5GfU There are more options, but these two are the most convenient weighing all the up and downsides. Does anyone disagree? Cheers, Alex On 22 Jul 2010, at 05:34, Antonio M. Moreiras wrote:

I think it is a very well planned exercise. I would suggest you not to be straight in its execution. In some point, you could ask if the decisions would be the same in cases with different conditions: more pops, more users, less users, etc...

We have a similar exercise in our training at NIC.br and we use this diagram to help the trainees understand the addresses: http://www.ipv6.br/pub/IPV6/MenuIPv6CursoPresencial/enderec-v6.pdf... Maybe it could be useful.

Moreiras.

Em 22/07/10 00:19, Mark Smith escreveu:

...

...

I'm curious to hear if you think it's clear and useful.

Cheers,

Alex Band RIPE NCC Trainer

(Big props go to Marco Hogewoning @XS4ALL)

On Fri, 23 Jul 2010 00:33:45 BST, Matthew Walster said:

I never saw the point of assigning a /48 to a DSL customer. Surely the better idea would be to assign your bog standard residential DSL customer a /64 and assign them a /56 or /48 if they request it, routed to an IP of their choosing.

If they're using autoconfigure for IPv6 addresses, what happens if they want to share that connection? Giving them a /64 off the bat means that a very sizable fraction of your users are going to call. Phrased differently - how screwed would you be if you engineered your IPv4 network so the default was "one device only", and the customer had to call you and ask for a network config change because they wanted to hook up a $50 home wifi router? If it doesn't make sense for IPv4, why would you want to do it for IPv6?

On Jul 22, 2010, at 5:37 PM, Matthew Kaufman wrote:

Valdis.Kletnieks@vt.edu wrote:

...

On Fri, 23 Jul 2010 00:33:45 BST, Matthew Walster said:

...

I never saw the point of assigning a /48 to a DSL customer. Surely the better idea would be to assign your bog standard residential DSL customer a /64 and assign them a /56 or /48 if they request it, routed to an IP of their choosing.

If they're using autoconfigure for IPv6 addresses, what happens if they want to share that connection? Giving them a /64 off the bat means that a very sizable fraction of your users are going to call.

Phrased differently - how screwed would you be if you engineered your IPv4 network so the default was "one device only", and the customer had to call you and ask for a network config change because they wanted to hook up a $50 home wifi router?

If it doesn't make sense for IPv4, why would you want to do it for IPv6?

"Home wifi router" vendors will do whatever it takes to make this work, so of course in your scenario they simply implement NAT66 (whether or not IETF folks think it is a good idea) however they see fit and nobody calls.

Matthew Kaufman

Well, wouldn't it be better if the provider simply issued enough space to make NAT66 unnecessary? Owen

On Thu, 22 Jul 2010 19:53:48 -0700 "Akyol, Bora A" <bora@pnl.gov> wrote:

As long as customers believe that having a NAT router/"firewall" in place is a security feature, I don't think anyone is going to get rid of the NAT box.

You need to separate the NAT function (or more specifically, Network Address Port Translation (NAPT)), and the side effect of that operation being a deny all for uninitiated inbound traffic. It is not a unique property to NAPT, and in fact, stateful firewalling using public addresses has been around as long as NAT (at least since 1995 IIRC).

In all reality, NAT boxes do work for 99% of customers out there.

So would a firewall with public addressing. It's worked for me for 10+ years with IPv4, and 4+ years with IPv6. Of course, it didn't protect me when I ran an email attachment that contained malware, or when I clicked on one of those "PC check" popups that installed an application. (well, not actually me, but a large number of people do this, helping the attacker completely bypass any "NAT security". Inviting the attacker in as though they were a trusted guest makes the best locks in the world on the door a waste of time.) It seems you haven't done much with NAT to have encountered it's limitations, or experienced the benefits of end-to-end connectivity (ever had to stuff around with port forwarding, TURN, STUN etc. to get VoIP working at home? I haven't, and I got to spend that time on something else much more useful than fiddling with NAT work arounds.)

Bora

On 7/22/10 7:34 PM, "Owen DeLong" <owen@delong.com> wrote:

Well, wouldn't it be better if the provider simply issued enough space to make NAT66 unnecessary?

Owen

In all reality: 1. NAT has nothing to do with security. Stateful inspection provides security, NAT just mangles addresses. 2. In the places where NAT works, it does so at a terrible cost. It breaks a number of things, and, applications like Skype are incredibly more complex pieces of code in order to solve NAT traversal. The elimination of NAT is one of the greatest features of IPv6. Most customers don't know or care what NAT is and wouldn't know the difference between a NAT firewall and a stateful inspection firewall. I do think that people will get rid of the NAT box by and large, or, at least in IPv6, the box won't be NATing. Whether or not they NAT it, it's still better to give the customer enough addresses that they don't HAVE to NAT. Owen On Jul 22, 2010, at 7:53 PM, Akyol, Bora A wrote:

As long as customers believe that having a NAT router/"firewall" in place is a security feature, I don't think anyone is going to get rid of the NAT box.

In all reality, NAT boxes do work for 99% of customers out there.

Bora

On 7/22/10 7:34 PM, "Owen DeLong" <owen@delong.com> wrote:

Well, wouldn't it be better if the provider simply issued enough space to make NAT66 unnecessary?

Owen

On Jul 23, 2010, at 2:50 AM, Jens Link wrote:

Owen DeLong <owen@delong.com> writes:

...

In all reality:

1. NAT has nothing to do with security. Stateful inspection provides security, NAT just mangles addresses.

You know that, I know that and (hopefully) all people on this list know that. But NAT == security was and still is sold by many people.

So is snake oil.

...

Most customers don't know or care what NAT is and wouldn't know the difference between a NAT firewall and a stateful inspection firewall.

I Agree. But there are also many people who want to believe in NAT as security feature.

After one of my talks about IPv6 the firewall admins of a company said something like: "So we can't use NAT as an excuse anymore and have to configure firewall rules? We don't want this."

So how did you answer him? The correct answer is "No, you don't have to configure rules, you just need one rule supplied by default which denies anything that doesn't have a corresponding outbound entry in the state table and it works just like NAT without the address mangling". In my experience, other than a small handful of religious zealots, that explanation is sufficient to get the point across to most such admins. Owen

On Mon, Jul 26, 2010 at 06:24:04AM +0200, Jens Link wrote:

Owen DeLong <owen@delong.com> writes:

...

The correct answer is "No, you don't have to configure rules, you just need one rule supplied by default which denies anything that doesn't have a corresponding outbound entry in the state table and it works just like NAT without the address mangling".

They used NAT as an excuse not to let some applications to the outside.

That's OK, if it's NAT unfriendly, chances are it requires deep packet inspection to make the state tables do the right thing anyway. - Matt -- Skippy was a wallaby. ... Wallabies are dumb and not very trainable... The *good* thing...is that one Skippy looks very much like all the rest, hence..."one-shot Skippy" and "plug-compatible Skippy". I don't think they ever had to go as far as "belt-fed Skippy" -- Robert Sneddon, ASR

On Jul 27, 2010, at 12:05 PM, Akyol, Bora A wrote:

Please see comments inline.

On 7/22/10 10:13 PM, "Owen DeLong" <owen@delong.com> wrote:

...

In all reality:

1. NAT has nothing to do with security. Stateful inspection provides security, NAT just mangles addresses. Of course, the problem is that there are millions of customers that believe that NAT == security. This needs to change.

2. In the places where NAT works, it does so at a terrible cost. It breaks a number of things, and, applications like Skype are incredibly more complex pieces of code in order to solve NAT traversal.

I look at this as water under the bridge. Yep, it was complicated code and now it works. I can run bittorrent just fine beyond an Apple wireless router and I did nothing to make that work. Micro-torrent just communicates with the router to make the port available.

It's only water under the bridge for IPv4. If we start putting NAT66 into play, it will be the same thing all over again. Additionally, it's only water under the bridge for existing applications. Each new application seems to go through the same exercise because for some reason, no two NAT gateways seem to have exactly the same traversal requirements and no two applications seem to implement the same set of traversal code.

...

The elimination of NAT is one of the greatest features of IPv6.

Most customers don't know or care what NAT is and wouldn't know the difference between a NAT firewall and a stateful inspection firewall.

I do think that people will get rid of the NAT box by and large, or, at least in IPv6, the box won't be NATing.

Whether or not they NAT it, it's still better to give the customer enough addresses that they don't HAVE to NAT.

Owen

Of course, no disagreement there. The real challenge is going to be education of customers so that they can actually configure a firewall policy to protect their now-suddenly-addressable-on-the-Internet home network. I would love to see how SOHO vendors are going to address this.

Not so much... SOHO gateways should implement stateful inspection with the same default policy a NAT box provides today... 1. Outbound packets create a state table entry. 2. Inbound packets are only forwarded if they match an existing state table entry. Pretty simple, actually. Owen

I look at this as water under the bridge. Yep, it was complicated code and now it works. I can run bittorrent just fine beyond an Apple wireless router and I did nothing to make that work. Micro-torrent just communicates with the router to make the port available.

So, the security model here is that arbitrary untrusted applications, running on an arbitrary untrusted OS, selected by people who have no understanding of computer or network security are allowed to update the security policy on the perimeter device. I can see why those secure NAT boxes have *totally* stopped the Windows botnet problem in its tracks...

Of course, no disagreement there. The real challenge is going to be education of customers so that they can actually configure a firewall policy to protect their now-suddenly-addressable-on-the-Internet home network. I would love to see how SOHO vendors are going to address this.

Permit any outbound Permit any inbound established Deny any inbound Achieves essentially the same functionality as a NAT device without the annoying mangling of addresses. Vendors could then continue to offer the UPnP "request a hole" functionality that they do today, or tweak the labels on their "forward this port" web GUI to say "permit the port" instead. For end-users who want to carry on doing exactly what they do today, the changes required for both them and their CPE vendor are trivial. For end-users who are currently frustrated by NAT, they have their real, honest-to-goodness end-to-end Internet restored. Everybody wins, apart those with a vested interest in "upselling" to "business" connectivity plans, or those who would prefer that the Internet is TV on new technology, and that end-users remain good little eyeballs, dutifully paying for their Big Business Content. Regards, Tim.

On (2010-07-24 03:50 -0400), Valdis.Kletnieks@vt.edu wrote:

Firewall != NAT. The former is still needed in IPv6, the latter is not. And I suspect that most Joe Sixpacks think of that little box they bought as a

Maybe you are talking strictly in context of residential DSL, in which case I would agree, NAT is killable, if we don't fsck-up in our DSL offerings. (Provide customer /64 and route /56 to ::c/64, so first /64 is bridged, if customer ever wants to start routing, they just add ::c/64 router to LAN.) However it is quite optimistic to think IPv6 would remove completely need for NAT. Enterprises of non-trivial size will likely use RFC4193 (and I fear we will notice PRNG returning 0 very often) and then NAT it to provider provided public IP addresses. I'm just hoping that we'll at least see 1:1 NAT instead of NAPT being used. This is to facilitate easy and cheap way to change provider. Getting PI address is even harder now, as at least RIPE will verify that you are multihomed, while many enterprises don't intent to be, they just need low cost ability to change operator. This is non-technical problem, enterprises of non-trivial size can't typically even tell without months of research all the devices and software where they've written down the IP addresses. RFC4193 + NAT quite simply is what they know and are comfortable with. It would be hard sell to ask them to design whole IPv6 infra so that they can confidently renumber it in 15min, like you can with RFC4193+NAT. -- ++ytti

On (2010-07-24 02:13 -0700), Owen DeLong wrote:

...

This is non-technical problem, enterprises of non-trivial size can't typically even tell without months of research all the devices and software where they've written down the IP addresses.

Sounds like they haven't written them down very well.

Exactly, unfortunately this is reality in many enterprises today. And it is optimistic to hope any technical change will fix the situation. It would be excessively easy to renumber IPv4 infrastructure if it was built with that goal, yet it can be multiyear MUSDs gig to integrator. -- ++ytti

On Sat, 2010-07-24 at 08:50 -0700, Matthew Kaufman wrote:

Even if all your hosts end up with external connectivity that works, the odds that they can reliably talk to each other is low.

I hope I'm not taking the above quote out of context, but why do you think this? How does the fact that interfaces on your host may have more than one public address translate into low odds that they can talk to each other? The only thing I can think of is that if an interface in your network has a public address from only one provider, and another interface in your network has a public address only from another provider, then the connection will go out through one provider and back in from the other, which would be less than optimal. On the other hand, there is no reason to think this would be particularly unreliable, and if such a situation existed it would either indicate a fault or be what you actually wanted. The discussion was in the context of a renumbering exercise. Using the simple method of having a period where both provider ranges are active and allowing the old provider range to "time out" may result in lost connections; there may also be caching difficulties with some applications. Neither situation is long-lived, and both can be mitigated by careful planning. Is that what you meant? Maybe I've missed your point. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF

On Jul 24, 2010, at 8:50 AM, Matthew Kaufman wrote:

Owen DeLong wrote:

...

Why on earth would you do that? Why not just put the provider-assigned addresses on the interfaces along side the ULA addresses? Using ULA in that manner is horribly kludgy and utterly unnecessary.

Because, although one of the original goals of IPv6 was for hosts to be easily multihomed at multiple addresses like this, host software (and even some of the required specifications) isn't really isn't there yet, and often the wrong thing happens.

Host software is there, but, it requires some education on how to configure it. You do have to properly set up the rules for which addresses to use for what communication properly. It breaks less if you forego the ULA brokenness, but, some people insist for whatever reason.

Never mind that the timescale for IPv6 deployment, no matter how long it is, will be shorter than the timescale for updating PCI, HIPPA, and SOX audit checklists to remove the requirements around "hide internal topology" and "do not use public addresses on any interface of critical hosts".

I expect the PCI changes to be out in less than a year. HIPPA and SOX may take closer to two years, maybe even three. I don't expect enterprise-wide adoption of IPv6 to be significant in less than 5 years. The big push for IPv6 right now needs to be on the public-facing services side which doesn't have hidden topology by definition.

...

Why is that easier/cheaper than changing your RAs to the new provider and letting the old provider addresses time out?

This would *also* require multihoming to actually work properly, only worse as the rules for selecting ULA vs PA routes are usually more right than the rules for selecting one PA vs another PA as an outbound interface, even if your host does multiple default routes properly. Even if all your hosts end up with external connectivity that works, the odds that they can reliably talk to each other is low.

Why use rules for selection... Simply have the RAs contain proper priorities for the ones you want to use at any particular moment and change the RA priorities as needed. Owen

On Sun, 25 Jul 2010 03:56:52 +1000 Karl Auer <kauer@biplane.com.au> wrote:

On Sat, 2010-07-24 at 10:42 -0700, Owen DeLong wrote:

...

You do have to properly set up the rules for which addresses to use for what communication properly. It breaks less if you forego the ULA brokenness, but, some people insist for whatever reason.

What is "the ULA brokenness"?

If it is address selection policy distribution, then this Internet Draft is aiming to solve that - "Distributing Address Selection Policy using DHCPv6" http://tools.ietf.org/html/draft-fujisaki-6man-addr-select-opt-00.html

Regards, K.

-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob)

GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF

Owen DeLong <owen@delong.com> writes:

...

for NAT. Enterprises of non-trivial size will likely use RFC4193 (and I fear we will notice PRNG returning 0 very often) and then NAT it to provider provided public IP addresses.

Why on earth would you do that? Why not just put the provider-assigned addresses on the interfaces along side the ULA addresses? Using ULA in that manner is horribly kludgy and utterly unnecessary.

To state the obvious: People are stupid.

...

This is to facilitate easy and cheap way to change provider. Getting PI address is even harder now, as at least RIPE will verify that you are multihomed, while many enterprises don't intent to be, they just need low cost ability to change operator.

Why is that easier/cheaper than changing your RAs to the new provider and letting the old provider addresses time out?

Well it's not cheaper but using NAT (and multiple NAT) leads to job security as nobody else will understand the network. BTST. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@guug.de | ------------------- | -------------------------------------------------------------------------

Owen DeLong wrote:

On Jul 22, 2010, at 5:37 PM, Matthew Kaufman wrote:

...

Valdis.Kletnieks@vt.edu wrote:

...

...

If it doesn't make sense for IPv4, why would you want to do it for IPv6?

"Home wifi router" vendors will do whatever it takes to make this work, so of course in your scenario they simply implement NAT66 (whether or not IETF folks think it is a good idea) however they see fit and nobody calls.

Matthew Kaufman

Well, wouldn't it be better if the provider simply issued enough space to make NAT66 unnecessary?

Owen

If the only reason the common denominator of internet service has not and does not come with more than minimum sufficient supply of IPv4 is due to scarcity, then it may be reasonable to hope that in the future the common denominator of internet service will include near limitless IPv6 addresses for its end users. Very likely, that is better. However, even then, there is no guarantee that the common denominator CPE for this service wont have NAT66 features, maybe even turned on by default. And if those CPE do have the feature on by default, then there is no reason for vendors to do more than supply the single /128 or even /64. Perhaps CPE will respond to a market condition of that nature by throwing out /64 subnetting rules and implementing their own divide-and-consume addressing scheme. And so it may go on and on. Action by action, reaction by reaction, the common scenario evolves, constantly. Automatic extension of dynamic routing protocols deep into the customers network may not be as sound a notion and as universally adoptable as is currently viewed. I believe it is way too early to predict with any confidence how this will play out. NAT44 did not become the method-du-jour until well after the scarcity was felt by the actual end users of the IPv4 network. Its increasing effect on network design and engineering came later yet. So any addressing plan that does not leave a hefty chunk of space reserved to be available for unknown future uses, a la IANA's other /3s, strikes me as unable or unwilling to withstand the test of time, by design. It would be an epic tragedy if down the road those other /3's were deemed as unusable as 240/4, maybe even for similar reasons. I suspect the perfect address plan is the holy grail of networking and just as locatable. Joe

Owen DeLong wrote:

Well, wouldn't it be better if the provider simply issued enough space to make NAT66 unnecessary?

The thing is, IPv6 is 128 bits of address space, so a /64 for your home *really* should be enough to have >1 machine online at a time. It'll be a lot easier to change the subnetting rules inside small networks, and we all know that DHCPv6 is far superior to SAA for almost all cases, but especially home users who need things like their DNS entries set up for them by their "router". Matthew Kaufman

JORDI PALET MARTINEZ wrote:

And then next you can say ok, so /32 bits is big enough for your home, so let's change it again, kill autoconfiguration, ask existing IPv6 users to redo their addressing plans, renumber, etc., and use all the rest of the bits for routing ?

I *really* don't understand why a /32 isn't big enough for a home. Even if you insist on SAA for getting the addresses. How many IPv6 devices is the guy going to plug in / attach wirelessly anyway?

And so on, of course, where is the limit ? You should propose this to 6man at the IETF.

You're not getting it. Autoconfiguration is a very good feature. No, no it isn't. It goes on the list of "interesting ideas for IPv6 that were good enough to be implemented, and refined (in this case as DHCP), for IPv4". Insisting on SAA is basically saying "well, you know all

The same IETF that until just a few months ago believed that DCCP and SCTP would be wildly successful as new IP protocols because NATs don't matter? those things we learned when we deployed DHCP... lets go ahead and forget them and pretend that home machine OS vendors *and* IT departments are wrong.

More bits for the user to subnet means more business for smart ISPs who don't want to sell addresses but instead services and applications much more easier to deploy thanks to a uniform /48 ways to address all end sites.

I fail to see how a household, even a really big one, is going to attach more bandwidth-consuming devices (which I presume is how the ISP does more business) to a link with a /48 on it vs a link with a /64 on it. A /64 allows more machines in your house than today's entire Internet has connected. Unless you have a new plan for electric power delivery to the home, there's no need to go beyond that. Matthew Kaufman

On 7/23/2010 9:07 AM, JORDI PALET MARTINEZ wrote:

It is not about how many devices, it is about how many subnets, because you may want to keep them isolated, for many reasons.

It is not just about devices consuming lots of bandwidth, it is also about many small sensors, actuators and so.

The ISP "new" business is not just about more bandwidth but also about offering new services, which they can charge for. Those services are very difficult to deploy in NATed scenarios such as the one that we have today with IPv4.

And I'm not saying to forget about what we have learn with DHCP, in fact DHCPv6 has many new and good features, but for many reasons, autonconfiguration is good enough, and much more simple.

Regards, Jordi

Jordi - the real issues are in guaranteed delivery of certain evidence-grade services and what it takes to offer those. Todd

...

From: Matthew Kaufman <matthew@matthew.at> Reply-To: <matthew@matthew.at> Date: Fri, 23 Jul 2010 07:22:53 -0700 To: Jordi Palet Martínez <jordi.palet@consulintel.es> Cc: <nanog@nanog.org> Subject: Re: Addressing plan exercise for our IPv6 course

JORDI PALET MARTINEZ wrote:

...

And then next you can say ok, so /32 bits is big enough for your home, so let's change it again, kill autoconfiguration, ask existing IPv6 users to redo their addressing plans, renumber, etc., and use all the rest of the bits for routing ?

I *really* don't understand why a /32 isn't big enough for a home. Even if you insist on SAA for getting the addresses. How many IPv6 devices is the guy going to plug in / attach wirelessly anyway?

...

And so on, of course, where is the limit ? You should propose this to 6man at the IETF.

...

You're not getting it. Autoconfiguration is a very good feature. No, no it isn't. It goes on the list of "interesting ideas for IPv6 that were good enough to be implemented, and refined (in this case as DHCP), for IPv4". Insisting on SAA is basically saying "well, you know all

The same IETF that until just a few months ago believed that DCCP and SCTP would be wildly successful as new IP protocols because NATs don't matter? those things we learned when we deployed DHCP... lets go ahead and forget them and pretend that home machine OS vendors *and* IT departments are wrong.

...

More bits for the user to subnet means more business for smart ISPs who don't want to sell addresses but instead services and applications much more easier to deploy thanks to a uniform /48 ways to address all end sites.

I fail to see how a household, even a really big one, is going to attach more bandwidth-consuming devices (which I presume is how the ISP does more business) to a link with a /48 on it vs a link with a /64 on it. A /64 allows more machines in your house than today's entire Internet has connected. Unless you have a new plan for electric power delivery to the home, there's no need to go beyond that.

Matthew Kaufman

********************************************** The IPv6 Portal: http://www.ipv6tf.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

sthaug@nethelp.no wrote:

...

It is not about how many devices, it is about how many subnets, because you may want to keep them isolated, for many reasons.

It is not just about devices consuming lots of bandwidth, it is also about many small sensors, actuators and so.

I have no problems with giving the customer several subnets. /56 is just fine for that. /56? How about /62? That certainly covers "several"... and if you're really worried they might have too many subnets for that to work, how about /60? I haven't seen any kind of realistic scenarios which require /48 for residential users *and* will actually use lots and lots of subnets - without requiring a similar amount of manual configuration on the part of the customer.

So we end up with /56 for residential users.

Only because people think that the boundaries need to happen at easy-to-type points given the textual representation. /56 is still overkill for a house. And there's several billion houses in the world to hook up. Matthew Kaufman

I tend to think a /60 is a reasonable allocation for a residential user. In my home I have two subnets and will in time likely add two more: - general network access - my office (required to be separate by Cisco Information Security policy) - (future) would likely want routable separate bandwidth for A/V at some point - (future) Smart Grid HAN will likely be its own subnet If my wife went to work for a company with an infosec policy like Cisco's, that becomes a fifth subnet. Yes, 16 to choose from seems reasonable. /56 seems appropriate to a small company, /48 for a larger company, and I could see a market for a /52. A company that needs more than a /48 is likely to also be using ULAs for some of its areas, which is an automatic extension, and could always justify another /48 (or one per continent) if it really needed them. Could I do all this within a /64? Of course, with some thought, and by getting the Smart Grid and office prefixes from other sources (Cisco, my utility) and running them over a VPN (which I do anyway). The question is why I should have to. Why four bit boundaries? Because we're using hexadecimal, and each character identifies four bits. It makes tracking numbers simple - no "remember to count by N" as in IPv4. It's not magic, but to my small mind - and especially for of non-technical residential customers - it seems reasonable. And yes, I think the logic behind a 48 bit MAC address is reasonable too. On Jul 24, 2010, at 7:50 AM, Mark Smith wrote:

On Fri, 23 Jul 2010 13:26:43 -0700 Matthew Kaufman <matthew@matthew.at> wrote:

...

sthaug@nethelp.no wrote:

...

...

It is not about how many devices, it is about how many subnets, because you may want to keep them isolated, for many reasons.

It is not just about devices consuming lots of bandwidth, it is also about many small sensors, actuators and so.

I have no problems with giving the customer several subnets. /56 is just fine for that. /56? How about /62? That certainly covers "several"... and if you're really worried they might have too many subnets for that to work, how about /60? I haven't seen any kind of realistic scenarios which require /48 for residential users *and* will actually use lots and lots of subnets - without requiring a similar amount of manual configuration on the part of the customer.

So we end up with /56 for residential users.

Only because people think that the boundaries need to happen at easy-to-type points given the textual representation. /56 is still overkill for a house. And there's several billion houses in the world to hook up.

So you're also strongly against 48 bit Ethernet MAC addresses? Dropping the two bits for group and local addresses, that's 70 368 744 177 664 nodes per LAN. How ridiculous! What were those idiots+ thinking!

"48-bit Absolute Internet and Ethernet Host Numbers", by Yogan K. Dalal, Robert S. Printis, *July 1981*

http://ethernethistory.typepad.com/papers/HostNumbers.pdf

+ not actually idiots

http://www.ipinc.net/IPv4.GIF

On Fri, 2010-07-23 at 17:53 +0200, sthaug@nethelp.no wrote:

...

And I'm not saying to forget about what we have learn with DHCP, in fact DHCPv6 has many new and good features, but for many reasons, autonconfiguration is good enough, and much more simple. [...] For our scenarios DHCPv6 is needed, autoconfiguration is *not* good enough. [...] I see no point in repeating the arguments for why autoconfiguration is not good enough - this has been beaten to death, repeatedly, on lots of IPv6 lists.

It's not like "there can be only one". If autoconf is good enough for your purposes, that's great! If not, there's DHCP. That's great too! Or use autoconf AND stateless DHCP - that's great too! Heck, some of us will be using static addressing in a lot of places and that's great too. Most of us will be using all four methods. Understanding the advantages and limitations of each method and combo is important, but just because something has a limitation doesn't make it completely useless for everybody. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF

-----Original Message----- From: Matthew Kaufman [mailto:matthew@matthew.at] Sent: Thursday, July 22, 2010 8:38 PM To: Valdis.Kletnieks@vt.edu Cc: nanog list Subject: Re: Addressing plan exercise for our IPv6 course

"Home wifi router" vendors will do whatever it takes to make this work, so of course in your scenario they simply implement NAT66 (whether or not IETF folks think it is a good idea) however they see fit and nobody calls.

If that's what you want, you'd better submit that feature request, because it's not in queue yet. IPv6 will be in production before that comes out. Re: NAT vs firewall: draft-ietf-v6ops-ipv6-cpe-router-06 says "Use draft-ietf-v6ops-cpe-simple-security" which says "Block bogons and have a stateful firewall." Lee

On 23 July 2010 01:45, Karl Auer <kauer@biplane.com.au> wrote:

Unless I've misunderstood Matthew, and he was suggesting that the /64 be the link network. That would indeed effectively give the customer a single address, unless it was being bridged rather than routed at the CPE. Not sure bridging it is such a good idea - most people will probably want their home networks to keep working even if the ISP has an outage.

Sorry for the week's delay - I meant delegating a /64 using DHCPv6 PD, I had assumed the link net would be based on provider preference - /64 would obviously make the most sense for the vast majority of scenarios. In my experience, I would have though well over 99% of residential users just require one subnet, if they require additional subnets they'll ask for them, and if it's standardised, a /56 could easily be quickly assigned and added to either the DHCPv6 PD or static routed if required. That would usually be a service the customer would pay extra for. I'm purely looking at residential use here, not SOHO nor SME. M M

On 29 July 2010 15:49, Owen DeLong <owen@delong.com> wrote:

If we give every household on the planet a /48 (approximately 3 billion /48s), we consume less than 1/8192 of 2000::/3.

There are 65,536 /48s in a /32. It's not about how available 2000::/3 is, it's hassle to keep requesting additional PA space. Some ISPs literally have millions of customers. All I'm saying is, why waste the space when they're only going to need 1 subnet? If they want more than one subnet, give them a /48,/56,/60 or whatever, as requested. M

On 29 Jul 2010, at 8:00, Matthew Walster wrote:

On 29 July 2010 15:49, Owen DeLong <owen@delong.com> wrote:

...

If we give every household on the planet a /48 (approximately 3 billion /48s), we consume less than 1/8192 of 2000::/3.

There are 65,536 /48s in a /32. It's not about how available 2000::/3 is, it's hassle to keep requesting additional PA space. Some ISPs literally have millions of customers.

Why would you initially request and receive a /32 if you know that you'll need far more space to assign subnets to all your customers?

All I'm saying is, why waste the space when they're only going to need 1 subnet? If they want more than one subnet, give them a /48,/56,/60 or whatever, as requested.

There's a good chance that you want to keep your customers for the long haul. There's a good chance that in the long run multi-subnet home networks will become the norm. Leo

On 2010-07-30 09:27, Matthew Walster wrote:

On 29 July 2010 18:08, Leo Vegoda <leo.vegoda@icann.org> wrote:

...

There's a good chance that in the long run multi-subnet home networks will become the norm.

With all due respect, I can't see it. Why would a home user need multiple subnets?

* Wireless * Wired * DMZ Those three I see a lot at various people's places. Also note that you should stop thinking of "today", think about what might be possible in 10, 20, 30, 40, 50 years... You don't have to bother your customers and your customers don't have to bother you anymore. The /48 for end-users might indeed be a bit on the much side, but a /56 is IMHO perfect fit for any home-site. The huge advantage of just giving out /48s though is that you don't have to care about if the connection is terminated at a home or a big corporation, as they say with shirts: one size fits all, simply as it is way too big. Greets, Jeroen

On Jul 30, 2010, at 1:13 AM, Matthew Walster wrote:

On 30 July 2010 08:32, Jeroen Massar <jeroen@unfix.org> wrote:

...

On 2010-07-30 09:27, Matthew Walster wrote:

...

On 29 July 2010 18:08, Leo Vegoda <leo.vegoda@icann.org> wrote:

...

There's a good chance that in the long run multi-subnet home networks will become the norm.

With all due respect, I can't see it. Why would a home user need multiple subnets?

* Wireless * Wired * DMZ

Those three I see a lot at various people's places.

I have *never* seen those three security zones separated outside of a business or the house of a nerd who runs his own Linux distro (Smoothwall etc). Furthermore, you're then pushing all that traffic into a $30 router which almost guaranteed will be underpowered.

If you'd like to come by my house, we can arrange that. I don't run linux on anything except one server. It doesn't do any routing. The routers that provide security boundaries are: 1. Juniper SRX-100 2. Apple Airport Extreme

Look at it this way: When I signed up at tunnelbroker.net, I received a /64. I was happy, and I went about my business. I wanted to have a play with something a bit bigger, I pressed "Assign /48" and it was ready to go in under a second. That's how it *should* work, or at least, in my opinion.

That's certainly one way to do it. However, I'm not sure it's how we would do it if we were starting today knowing what we know now. It does add a certain amount of complexity to our address planning and to our systems to make it work that way. IMHO, that complexity is unnecessary.

...

Also note that you should stop thinking of "today", think about what might be possible in 10, 20, 30, 40, 50 years...

I'm not thinking of today, I'm thinking about the people who use these services. They don't know about networking, they don't know about security apart from "install this virus checker". Most of them will laboriously transfer files from system to system using a USB drive (or floppy disk!) even though there's a big flashing icon on their desktop saying "put files here and they'll magically appear on your other machine". These people don't know and don't *care* about networks. They care about the service they get. That isn't going to change in 50 years.

First, your assumption that their knowledge level remains constant is absurd, so, in that statement you are thinking only of today. 10 years ago, most of those users wouldn't know what a web site was. Most of the do today. Just 10 years ago, most of them didn't know what email was. Most of them use email on a daily basis today. Second, with DHCP-PD and likely future CPE products, they will be able to simply connect pre-defined security zones to the right ports on the CPE based on the port labels. There will likely be a reasonable default security policy pre-installed for each zone. Even my parents could handle plugging things like TiVo, the stereo, etc. into ports labeled "Home Entertainment" while plugging the Kids computers into "Nanny" ports and their own computers into "General Access" ports. It's not significantly harder than the current need to get the LAN and WAN ports right on today's CPE.

If you genuinely think that regular residential users need multiple subnets to create a zoned config... You're wrong. It *will* piss them off, even if transparent. It's not just because of the speed (which as you say, will improve over time) it's because suddenly their wired-in Xbox in front of the TV just won't talk to the wireless Xbox their mate just brought round to have a play with. If you say that's down to education, you've entirely missed the point.

Why wouldn't they be able to talk to each other? You make assumptions about the future implementations of CPE there that I don't think are entirely accurate. I don't even see a reason to expect that wireless devices wouldn't be able to register for an appropriate security zone by device type in some implementations. Alternatively, the wired Xbox may need to initiate the connection to the wireless, or, vice-versa depending on implementation, but, I would expect CPE vendors to be able to solve that problem in the future.

Owen

Matthew, On Jul 30, 2010, at 9:27 AM, Matthew Walster wrote:

On 29 July 2010 18:08, Leo Vegoda <leo.vegoda@icann.org> wrote:

...

There's a good chance that in the long run multi-subnet home networks will become the norm.

Why would a home user need multiple subnets?

Even today, people are deploying multiple subnets in their homes. For example, Apple's Airport allows you to trivially set up a "guest" network that uses a different prefix (192.168.0.0/24) and different SSID than your "normal" network (10.0.1.0/24).

Are they really likely to have CPE capable of routing between subnets at 21st Century LAN speeds?

Sure. Given time and Moore's law, I figure that's pretty much guaranteed.

Isn't that needlessly complicating the home environment?

It's really a question of time horizons. If you buy into a future world of sensornets and massive home automation, rooms in houses would have tens or hundreds of devices, all individually addressable. And that's ignoring devices hung off your body attached via a personal area network. In such an environment, I can easily imagine multiple subnets. Of course, not everyone buys into these ideas (and they're certainly not going to happen tomorrow), however I believe one of the rationales behind /48s is "why architect in impediments if you don't have to?".

It just seems *wasteful* to me.

It is (mindboggling so), in the sense of address utilization. However, there are a lot of /48s in IPv6 (if you multiply the current IPv4 address consumption rate by 1000, the 1/8th of the IPv6 address space currently used for global unicast allocations would last about 120 years), so people are suggesting we optimize for flexibility. As various people have noted, innovation is greatly facilitated when you have plentiful resources (mechanical power: industrial revolution, cpu power: GUIs, bandwidth: on-demand entertainment, etc). I gather the theory is that if you remove the need to be efficient with addresses, you'll see new innovations in the use of the network.

/32 is a lot of space, if most customers are only going to have a few machines on one subnet, why not just give them a /64 and have an easy way to just click on a button on your customer portal or similar to assign a /48 and get it routed to them.

Unless you allocate the /64 out of the /48 you'd assign to them (in which case, why not simply assign the /48), it would force the customer to renumber. Perhaps not that big a deal, but it seems like work for little benefit. Regards, -drc

Hi, * Matthew Walster

On 30 July 2010 09:20, David Conrad<drc@virtualized.org> wrote:

...

Even today, people are deploying multiple subnets in their homes. For example, Apple's Airport allows you to trivially set up a "guest" network that uses a different prefix (192.168.0.0/24) and different SSID than your "normal" network (10.0.1.0/24).

Clearly, you think you're in the right and that you're making a valid and salient point. I see the above as unreasonable rationale. The very definition of "trivial" I would contend here - I honestly don't know a single resi user who has even logged into their modem/router. They're shipped with the username/password already entered by many ISPs these days, so they don't even have to set it up, they just plug it an and "use the internet".

I can order VOIP and IP-TV services from the broadband provider I use at home. This is realised by using a separate subnet per service, so with VOIP+IPTV+Internet I'm already using three distinct subnets. I don't have to configure anything - that's all handled by my ISP. I just have to connect the IP telephone and IPTV tuner to the correct port on the CPE and I'm ready to go. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27

On 30 July 2010 09:53, Owen DeLong <owen@delong.com> wrote:

2.      Yes, they are already available. A moderate PC with 4 Gig-E        ports can actually route all four of them at near wire speed.        For 10/100Mbps, you can get full featured CPE like the SRX-100        for around $500. That's the upper end of the residential CPE        price range, but, it's a small fraction of the cost of that functionality        just 2 years ago.

A moderate PC is not a typical CPE. An SRX-100 is not a typical CPE. A Draytek DSL modem/router is not a typical CPE. Your typical CPE is, and always will be, a simple device. It will (and should) contain no user configuration that is required for operation. If it does, it's too complicated for the average user.

               Home sensor network and/or appliances

If it's really necessary to put these on a separate network, I highly doubt anyone but the true gadget geek will bother.

               Kids net (nanny software?)

Should be sorted at the PC-level, not the network level. If it really is going to be a network service, it should be off the home network and a managed service by an ISP somewhere.

               Home entertainment systems

Really? A separate network just for an HTPC?

               Guest wireless

Wireless is polluted enough. Supposing everything's fixed in the future and there is near-unlimited wireless spectrum, your average user is just going to give the encryption key to the router to the guest. Network management is not on the radar for 99.9% of resi users. Seriously, this is getting silly. I'm not even going to respond any more - if you genuinely think users care about network management, you're wrong. They treat it as a black box, and that isn't going to change for a long, long, long time. M

On Jul 30, 2010, at 3:11 AM, Matthew Walster wrote:

On 30 July 2010 09:53, Owen DeLong <owen@delong.com> wrote:

...

2. Yes, they are already available. A moderate PC with 4 Gig-E ports can actually route all four of them at near wire speed. For 10/100Mbps, you can get full featured CPE like the SRX-100 for around $500. That's the upper end of the residential CPE price range, but, it's a small fraction of the cost of that functionality just 2 years ago.

A moderate PC is not a typical CPE. An SRX-100 is not a typical CPE. A Draytek DSL modem/router is not a typical CPE.

Your typical CPE is, and always will be, a simple device. It will (and should) contain no user configuration that is required for operation. If it does, it's too complicated for the average user.

An Apple Airport Extreme is relatively typical CEP and meets your criteria. I have one forwarding packets at 800Mbps throughput between the LAN and WAN ports. On a gig-E network, that seems close enough to LAN speed. A lot of your "simple devices" are actually PCs running linux under the hood, so, in fact, a moderate PC today is likely to be tomorrows "toaster".

...

Home sensor network and/or appliances

If it's really necessary to put these on a separate network, I highly doubt anyone but the true gadget geek will bother.

Then you will be surprised.

...

Kids net (nanny software?)

Should be sorted at the PC-level, not the network level. If it really is going to be a network service, it should be off the home network and a managed service by an ISP somewhere.

We can agree to disagree about this.

...

Home entertainment systems

Really? A separate network just for an HTPC?

No. A separate network for: Playstation/Wii/etc. Amplifier (See Yamaha RXV-3900 for example) HTPCs Apple TVs TiVOs Mac Minis operating in that role (the new one rocks for that) DVD players Blue Ray players Monitors/Televisions etc. Just because the only home entertainment thing you have today with an ethernet port is an HTPC (which, btw, is way geekier than half the CPE you argued against at this point) does not mean that everyone will be subject to such limitations.

...

Guest wireless

Wireless is polluted enough. Supposing everything's fixed in the future and there is near-unlimited wireless spectrum, your average user is just going to give the encryption key to the router to the guest. Network management is not on the radar for 99.9% of resi users.

Again, we can agree to disagree. Lots of people I know, including non-technical ones have turned on the guest wireless capability with their Airport Extremes.

Seriously, this is getting silly. I'm not even going to respond any more - if you genuinely think users care about network management, you're wrong. They treat it as a black box, and that isn't going to change for a long, long, long time.

I don't think they care. I think it will be automated for them in the future. The argument wasn't about whether users care or not. The argument was about whether households would eventually come to a point where the norm was to require more than one subnet per household. You remain in denial, and, that's fine, but, I think enough use cases have been shown and enough people have told you that they already have multiple subnets in IPv4 as a result of default service they receive from their provider to prove that multiple subnets in the average home will be commonplace in the future. Owen

On Jul 29, 2010, at 8:00 AM, Matthew Walster wrote:

On 29 July 2010 15:49, Owen DeLong <owen@delong.com> wrote:

...

If we give every household on the planet a /48 (approximately 3 billion /48s), we consume less than 1/8192 of 2000::/3.

There are 65,536 /48s in a /32. It's not about how available 2000::/3 is, it's hassle to keep requesting additional PA space. Some ISPs literally have millions of customers.

If you have millions of customers, why get a /32? Why not take that fact and ask for the right amount of space? 1,000,000 customers should easily qualify you for a /24 or thereabouts. If you have 8,000,000 customers, you should probably be asking for a /20 or thereabouts. It's not rocket science to ask for enough address space, and, if you have the number of customers to justify it based on a /48 per customer, the RIRs will happily allocate it to you.

All I'm saying is, why waste the space when they're only going to need 1 subnet? If they want more than one subnet, give them a /48,/56,/60 or whatever, as requested.

For at least the following reasons: 1. A single subnet may be the norm today because residential users and there vendors have been in a scarcity of addresses mentality for so long that applications to take full advantage of internet as it should be haven't been possible. That will change. 2. A single subnet may be enough for many (definitely not all and possibly not even most) today, but, certainly won't be the norm for long once IPv6 is more ubiquitous. 3. It places unnecessary limitations on the user and makes it unnecessarily more difficult to deploy additional capabilities. 4. Your increasing the workload on your own staff as your customers realize that one subnet is no longer enough and come back to you for larger assignments. 5. It's short sighted and assumes that the current IPv4 model will permanently apply to IPv6. Why waste valuable people's time to conserve nearly valueless renewable resources? Owen

On 2010-07-29 19:32, Tim Franklin wrote:

...

Why waste valuable people's time to conserve nearly valueless renewable resources?

See my earlier comments on "upsell" and "control". While you have some ISPs starting from the mentality that gives us "accepting incoming connections is a chargeable extra", they're also going to be convinced that there's a revenue opportunity in segmenting customers who want N of some resource from those who want 2N, 4N, ... That the resource in question is, for all practical purposes, both free and infinite (cue someone with a 'tragedy of the commons' analysis) does not factor - if they want more, they must pay more!

Ever thought about this tiny thing called BANDWIDTH USAGE? It is what ISPs are charged by their transit providers / peers, thus why not do that do users? Oh yeah.. something with overselling capacity.... but that is not a big issue either, you can probably figure out what the average is, the lowest and the highest and come up with a good competitive pricing strategy from there. And there is another advantage there: the people who use a lot of bandwidth are actually paying for it then, thus you don't have to ratelimit these folks, as heck, they pay for it! Need more capacity in an area, well, no problem they paid for it already, thus do calculate that into your pricing too of course ;) Thus don't charge folks for the amount of IP addresses they have, that is not what you get charged for by your transit/peers either. Greets, Jeroen

On Jul 29, 2010, at 10:32 AM, Tim Franklin wrote:

...

Why waste valuable people's time to conserve nearly valueless renewable resources?

See my earlier comments on "upsell" and "control". While you have some ISPs starting from the mentality that gives us "accepting incoming connections is a chargeable extra", they're also going to be convinced that there's a revenue opportunity in segmenting customers who want N of some resource from those who want 2N, 4N, ... That the resource in question is, for all practical purposes, both free and infinite (cue someone with a 'tragedy of the commons' analysis) does not factor - if they want more, they must pay more!

If you want to build a business based on upsell and control by trying to convince users that they should give you extra money to provision a resource that costs you virtually nothing, then more power to you. However, I think this will, in the end, be as popular as american restaurants that charge for ice water. Consumers are moderately ignorant, but, not completely stupid. Address scarcity has allowed this model to succeed to some extent in IPv4, largely due to lack of alternatives and the fact that all consumer ISPs operate on this model. In IPv6, there is no scarcity, some ISPs will offer alternatives, and, consumers will rapidly learn about this disparity and I'm guessing that a model that says: Network Numbers Our Cost You Pay 1 $0.000000001 $0.00 2 $0.000000002 $1.00 4 $0.000000004 $2.00 etc. Is probably going to be at a significant competitive disadvantage vs. a model that says "You can have whatever address space you can justify. We'll start you with 65,536 networks which we believe is way more than enough for virtually any residential user. We don't charge you anything for address space. We think charging people for integers is illogical." However, if you think there is a competitive or revenue advantage, more power to you. Owen

On 29 Jul 2010 12:19, Owen DeLong wrote:

On Jul 29, 2010, at 8:00 AM, Matthew Walster wrote:

...

On 29 July 2010 15:49, Owen DeLong <owen@delong.com> wrote:

...

If we give every household on the planet a /48 (approximately 3 billion /48s), we consume less than 1/8192 of 2000::/3.

There are 65,536 /48s in a /32. It's not about how available 2000::/3 is, it's hassle to keep requesting additional PA space. Some ISPs literally have millions of customers.

If you have millions of customers, why get a /32? Why not take that fact and ask for the right amount of space? 1,000,000 customers should easily qualify you for a /24 or thereabouts. If you have 8,000,000 customers, you should probably be asking for a /20 or thereabouts.

... and paying sixteen times as much in assignment and maintenance fees. See the problem there?

It's not rocket science to ask for enough address space, and, if you have the number of customers to justify it based on a /48 per customer, the RIRs will happily allocate it to you.

Yes. However, I don't think the RIRs are as willing to give out address space for _potential_ customers, e.g. if a telco or cableco wanted to assign a single block to each CO/head end to account for future growth. OTOH, you can get address space based on a /48 per actual customer, then actually assign a /64 per potential customer and have enough for massive growth.

Why waste valuable people's time to conserve nearly valueless renewable resources?

By creating artificial scarcity, one can increase profits per unit of nearly-valueless, renewable resources. See also: De Beers and the demonizing of artificial diamonds. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking

On Fri, 23 Jul 2010 00:33:45 +0100 Matthew Walster <matthew@walster.org> wrote:

On 22 July 2010 14:11, Alex Band <alexb@ripe.net> wrote:

...

There are more options, but these two are the most convenient weighing all the up and downsides. Does anyone disagree?

I never saw the point of assigning a /48 to a DSL customer. Surely the better idea would be to assign your bog standard residential DSL customer a /64 and assign them a /56 or /48 if they request it, routed to an IP of their choosing.

I estimate that an addressing request will cost the ISP at least 15 minutes of time to process. When a minimum allocation of a /32 contains 16 777 216 /56s, do you really need to create that artificial addressing cost, eventually passed onto the customer? With more address space than we need, the value we get is addressing convenience (just like we've had in Ethernet addressing since 1982). There is no need to make IPv6 addressing artificially precious and as costly as IPv4 addressing is. There are a variety of scenarios where customers, including residential, will benefit from having multiple subnets. They may wish to separate the wired and wireless segments, to prevent multicast IPTV from degrading wireless performance. They may wish to segregate the children/family PC from the adult PC network or SOHO network, allowing the subnet boundary to be an additional Internet access policy enforcement point. They'll need separate subnets if they wish to use a different link layer technology, such as LoWPAN. They may wish to setup a separate subnet to act as a DMZ for Internet facing devices, such as a local web server for sharing photos with relatives. Game consoles may be put in a separate subnet to ensure file transfers don't interfere with game traffic latency, using the subnet ID as a QoS classifier.

For the rest of it, I largely agree, though.

M

On Jul 22, 2010, at 9:51 PM, Joe Maimon wrote:

Mark Smith wrote:

...

On Fri, 23 Jul 2010 00:33:45 +0100 Matthew Walster<matthew@walster.org> wrote:

...

On 22 July 2010 14:11, Alex Band<alexb@ripe.net> wrote:

...

There are more options, but these two are the most convenient weighing all the up and downsides. Does anyone disagree?

I never saw the point of assigning a /48 to a DSL customer. Surely the better idea would be to assign your bog standard residential DSL customer a /64 and assign them a /56 or /48 if they request it, routed to an IP of their choosing.

I estimate that an addressing request will cost the ISP at least 15 minutes of time to process. When a minimum allocation of a /32 contains 16 777 216 /56s, do you really need to create that artificial addressing cost, eventually passed onto the customer?

Funny how so much concern is given to eliminating the possibility of end users returning for more space, yet for ISP's we have no real concern with what will happen when they near depletion of their /32 what with /48s to some thousands customers, aggregation, churn, what have you.

There's no need to give it a lot of concern because that process is pretty well understood and not particularly different from the current process in IPv4. When an ISP runs out, they apply for more from either their upstream, or, their RIR. Just that simple.

The effort and cost of that on the organization is hard to predict, especially as how it may vary from size to size, organization to organization. Furthermore, everyone else pays with a DFZ slot.

Yeah, but, the number of DFZ slots consumed by this in IPv6 will be so much smaller than IPv4 that I really find it hard to take this argument seriously. Additionally, it's not necessarily true due to allocation by bisection.

/48 per customer gives the customer as many potential subnets as you have potential customers.

You say that like it is a bad thing.

...

With more address space than we need, the value we get is addressing convenience (just like we've had in Ethernet addressing since 1982). There is no need to make IPv6 addressing artificially precious and as costly as IPv4 addressing is.

A balance should be struck and for that to happen, weight must be given to both sides.

And it has. /32 is merely the default minimum allocation to an ISP. Larger blocks can be given, and, now that the RIRs are allocating by bisection, it should even be possible in most cases for that additional space to be an expansion of the existing allocation without changing the number of prefixes. e.g. 2001:db8::/32 could be expanded to 2001:db8::/28 16 times as much address space, same number of DFZ slots. Owen

On Fri, 23 Jul 2010 14:48:47 -0400 Joe Maimon <jmaimon@ttec.com> wrote:

Owen DeLong wrote:

...

On Jul 22, 2010, at 9:51 PM, Joe Maimon wrote:

...

...

...

Funny how so much concern is given to eliminating the possibility of end users returning for more space, yet for ISP's we have no real concern with what will happen when they near depletion of their /32 what with /48s to some thousands customers, aggregation, churn, what have you.

There's no need to give it a lot of concern because that process is pretty well understood and not particularly different from the current process in IPv4.

There are a whole lot of organizations who do not view getting IPv4 from ARIN as particularly easy or well understood. Whether IPv6 requests will be better or worse for more or less of the population is completely unpredictable at this time.

My point is that very little concern is being given to them and all of it to the end user, who all understand how to contact their service provider to request more service.

...

When an ISP runs out, they apply for more from either their upstream, or, their RIR. Just that simple.

When an end user runs out, they apply for more from either their upstream, or, their RIR. Just that simple.

Well my point isn't about how simple it is. It is how much that each request costs to handle. You could give each of residential your customers a single /64, and have some percentage of them come back every year for more subnets. Or you could give them all /56s, and likely have none of them come back at all for additional address space while they continue to be your customer. Up to a point (/56 seeming to be the common view at the moment) IPv6 address space is so plentiful that handling a request for more costs both or either the ISP or the customer more than if the customers were initially given enough to exceed their common and foreseeable requirements. There would be better things for an ISP to spend it's staff time on than dealing with low end customer IPv6 address space requests, when the ISP has the choice of giving all customers more than they'll likely need, resulting in additional address space requests to being a rare and exceptional occasion.

...

...

The effort and cost of that on the organization is hard to predict, especially as how it may vary from size to size, organization to organization. Furthermore, everyone else pays with a DFZ slot.

Yeah, but, the number of DFZ slots consumed by this in IPv6 will be so much smaller than IPv4 that I really find it hard to take this argument seriously.

Early days yet. And each IPv6 is worth four of IPv4. We are already proposing doubling the allocation rate for transitional mechanisms.

...

Additionally, it's not necessarily true due to allocation by bisection.

...

/48 per customer gives the customer as many potential subnets as you have potential customers.

You say that like it is a bad thing.

I say it as if it is a curious thing worthy of real consideration whether we are indeed following the wisest course of action.

...

...

...

With more address space than we need, the value we get is addressing convenience (just like we've had in Ethernet addressing since 1982). There is no need to make IPv6 addressing artificially precious and as costly as IPv4 addressing is.

A balance should be struck and for that to happen, weight must be given to both sides.

And it has. /32 is merely the default minimum allocation to an ISP. Larger blocks can be given, and, now that the RIRs are allocating by bisection, it should even be possible in most cases for that additional space to be an expansion of the existing allocation without changing the number of prefixes.

e.g. 2001:db8::/32 could be expanded to 2001:db8::/28

16 times as much address space, same number of DFZ slots.

Owen

Yes, the one saving grace of this system.

Joe

Well said. One more reason is transition mechanisms. For example, 6to4, TBs, manual tunnels, those are just a few examples, which use/provide /48. We have today many customers using /48, which have already their own internal addressing plans, or manual subnets configured internally. Are you going to tell them now that you provide a dual stack service with less subnets and they need to remake their addressing plan and/or renumber ? Those customers are smart, they will look to your competitors and look for a better provider. No economical reason to provide "less" subnets to customers, many economical reasons to provide them as many subnets as you can, avoid wasting time, renumbering, etc., and being able to provide more applications that may be easily deployed in different subnets. Yes, 16 bits subnets are a lot, but time cost more, announcing more prefixes per customer is even more expensive, even for residential customers that will use more and more applications and services requiring them. You don't want to manage again a more complex network specially if as Tony Hain calculated some time ago, providing /48 for every possible customer in the Earth will mean IPv6 will last 480 years. Do you really believe we will keep using IP (not talking about v4 or v6) as we know it today ? I bet in less than 100 years we will need, for other reasons different than the need for more addresses, a new protocol. Why we insist in making things complicated againg, I guess because humans like complicated life ! Regards, Jordi

From: Marco Hogewoning <marcoh@marcoh.net> Reply-To: <marcoh@marcoh.net> Date: Fri, 23 Jul 2010 10:06:43 +0200 To: Matthew Walster <matthew@walster.org> Cc: nanog list <nanog@nanog.org> Subject: Re: Addressing plan exercise for our IPv6 course

On 23 jul 2010, at 01:33, Matthew Walster wrote:

...

On 22 July 2010 14:11, Alex Band <alexb@ripe.net> wrote:

...

There are more options, but these two are the most convenient weighing all the up and downsides. Does anyone disagree?

I never saw the point of assigning a /48 to a DSL customer. Surely the better idea would be to assign your bog standard residential DSL customer a /64 and assign them a /56 or /48 if they request it, routed to an IP of their choosing.

/64 is too small, especially when sensornetworks take off you probably want multple ranges.

In fact the CPE we use at the moment already takes a /64 for internals like voip clients, dns resolver and management interfaces and assigns the second one to the LAN. Optionally you want people to create a seperate zone for wifi guests (it supports dual band radio). So in reallife you already need more then one.

Giving the way reverse DNS is designed I wouldn't recommend people to leave the 4 bit boundry on which it is organised unless you want to make your life miserable and complicated. So that would make it a /60 at minimum.

So why /48 and not /56 or /60 ? We'll first of all we, and I mean the collective group of people that tries to run the internet (which includes you reading this), screwed it up in marketing.

First of all we keep telling everybody there are so many addresses we will never run out of them. Now of course this is BS and we all know that someday we find 128 bits wasn't enough. By that time we probably realise that the current almost classfull system wasn't a smart choice and we introduce CIDR again to save our day.

Which brings me to the second point and that is introducing semi fixed borders like /64 for a subnet and the original wording 'if you think they ever need more then one subnet, assign a /48'. That amazingly got stuck in peoples head like classfull once did. I still have customers asking for a C-class and some of them are even born in the CIDR era. As far as the customer base understand what IPv6 is, all they ever hear is 'I'll get a /48' even in those cases where you say something else. We told them NATs are going away and we told them we had so many addresses there wasn't a problem at all. /64 subnet, /48 when you need more did the rest.

So assume I assign the mass that is unaware a /64, do I reserve some bits for future growth? I'll bet you when IPv6 does hit the market somebody will find an application for it and requires a second subnet (sensors for instance). What do I do when somebody requests this, assign a secondary /64 or renumber ? So maybe I should reserve a /60, but is that different from assigning it directly ? Takes up space anyway.

So now I assign a /60, unfortunately the /48 is stuck in people's head so I get people complaining about this. This is amplified by the fact that early adopters, even the ones with tunnels, got a /48. Remember those folks who got a /8 back in the days, did you ever thought 'what if I would have been there' ? So I get into discussions with customers and that has a cost, I at least have to pay for the guy who answers the phone on our end. Next to that, there is that risk that I lose business because the shop across the road does offer /56 or even /48.

Which brings me into the economics, we are in a hurry. We need to deploy and we need to deploy yesterday. In fact if you are not running IPv6 by now, you are too late. So I have the choice of creating a really complicated deployment scheme in which I can assign variable subnet lenghts to customers without breaking aggregation and without annoying them with renumbering. One-size-fits-all makes life easy and saves an huge pile of money and not only money but it saves time, time I need, beacuse we are already a bit late.

In short, why a /48 'Because we can!'. We had about 15 years to design a proper scheme, we failed. Now we can discuss a redesign, but then we need to squeeze another 10 years out of IPv4.

MarcoH

********************************************** The IPv6 Portal: http://www.ipv6tf.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.