In reviewing IPv6 end user allocation policies, I can find little agreement on what prefix length is appropriate for residential end users. /64 and /56 seem to be the favorite candidates, with /56 being slightly preferred. I am most curious as to why a /60 prefix is not considered when trying to address this problem. It provides 16 /64 subnetworks, which seems like an adequate amount for an end user. Does anyone have opinions on the BCP for end user addressing in IPv6?
On Fri, 5 Aug 2011, Brian Mengel wrote:
In reviewing IPv6 end user allocation policies, I can find little agreement on what prefix length is appropriate for residential end users. /64 and /56 seem to be the favorite candidates, with /56 being slightly preferred.
Not slightly preferred, very much preferred. /56 is future proof and works for "everybody". /64 is short sighted and doesn't allow for multiple networks in the home.
I am most curious as to why a /60 prefix is not considered when trying to address this problem. It provides 16 /64 subnetworks, which seems like an adequate amount for an end user.
Why save on addresses, you can just get more IPv6 addresses if you need them. /56 is allowed per user from all the RIRs afaik.
Does anyone have opinions on the BCP for end user addressing in IPv6?
Yes, there are plenty of people with opinions. This has been hashed over and over and over again, please check the archives for lots of discussions on pros an cons. If you want to do it right, go for /56, it works. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Aug 5, 2011, at 9:29 AM, Mikael Abrahamsson wrote:
On Fri, 5 Aug 2011, Brian Mengel wrote:
In reviewing IPv6 end user allocation policies, I can find little agreement on what prefix length is appropriate for residential end users. /64 and /56 seem to be the favorite candidates, with /56 being slightly preferred.
Not slightly preferred, very much preferred. /56 is future proof and works for "everybody". /64 is short sighted and doesn't allow for multiple networks in the home.
I would say /56 is slightly preferred and that /48 is very much preferred.
I am most curious as to why a /60 prefix is not considered when trying to address this problem. It provides 16 /64 subnetworks, which seems like an adequate amount for an end user.
Why save on addresses, you can just get more IPv6 addresses if you need them. /56 is allowed per user from all the RIRs afaik.
All RIRs allow /48s actually. Some policies measure in increments of /56, BUT, even those policies consider issuing a customer a /48 to be a valid use of 256 /56s for measurement purposes.
Does anyone have opinions on the BCP for end user addressing in IPv6?
Yes, there are plenty of people with opinions.
This has been hashed over and over and over again, please check the archives for lots of discussions on pros an cons. If you want to do it right, go for /56, it works.
If you really want to do it right, go for /48… It works better. Owen
On Fri, 05 Aug 2011 12:17:48 EDT, Brian Mengel said:
In reviewing IPv6 end user allocation policies, I can find little agreement on what prefix length is appropriate for residential end users. /64 and /56 seem to be the favorite candidates, with /56 being slightly preferred.
I am most curious as to why a /60 prefix is not considered when trying to address this problem. It provides 16 /64 subnetworks, which seems like an adequate amount for an end user.
Basically, the thinking was a /56 is still "cheap" as far as allocating space, so if you need more than a /64, might as well go to /56 and avoid the mess if a user needs a 17th subnet. This isn't IPv4, where you have to actually worry about burning through your IP allocation doling it out to customers. Even a single /32 will service a *lot* of /56's, and I don't think *anybody* is big enough to actually burn through a /24 allocation (feel free to prove me wrong.. ;)
On 8/5/11 10:38 AM, Valdis.Kletnieks@vt.edu wrote:
and I don't think*anybody* is big enough to actually burn through a /24 allocation (feel free to prove me wrong.. ;)
Never doubt the ability of certain Asian countries to burn through IP space at blistering speed when their citizens can't even directly access the internet without going through a massive firewall and proxy system. :) -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org
On Fri, 05 Aug 2011 10:56:25 MDT, Brielle Bruns said:
On 8/5/11 10:38 AM, Valdis.Kletnieks@vt.edu wrote:
and I don't think*anybody* is big enough to actually burn through a /24 allocation (feel free to prove me wrong.. ;)
Never doubt the ability of certain Asian countries to burn through IP space at blistering speed when their citizens can't even directly access the internet without going through a massive firewall and proxy system. :)
Those cases are probably best handled as a /16 delegation from a regional RIR to a national RIR or similar. And they can just ULA themselves a /16 for inside the country if they really feel the need ;) And yes, I know a single /24 won't quite cover all of Comcast's customers if they give them all a /48. They're welcome to prove me wrong by turning up enough customers on IPv6 to need a second /24. ;)
/56 is definitely preferable to /64, but, /48 really is a better choice. /56 is very limiting for autonomous hierarchical deployments. It's not about number of subnets. It's about the ability to provide some flexibility in the breadth and depth of bit fields used for creating hierarchical topologies automatically. Owen On Aug 5, 2011, at 9:17 AM, Brian Mengel wrote:
In reviewing IPv6 end user allocation policies, I can find little agreement on what prefix length is appropriate for residential end users. /64 and /56 seem to be the favorite candidates, with /56 being slightly preferred.
I am most curious as to why a /60 prefix is not considered when trying to address this problem. It provides 16 /64 subnetworks, which seems like an adequate amount for an end user.
Does anyone have opinions on the BCP for end user addressing in IPv6?
Let's clarify -- /48 is much preferred by Owen, but most ISPs seem to be zeroing in on a /56 for production. Though some ISPs are using /64 for their trials. Frank -----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Friday, August 05, 2011 12:21 PM To: Brian Mengel Cc: nanog@nanog.org Subject: Re: IPv6 end user addressing /56 is definitely preferable to /64, but, /48 really is a better choice. /56 is very limiting for autonomous hierarchical deployments. It's not about number of subnets. It's about the ability to provide some flexibility in the breadth and depth of bit fields used for creating hierarchical topologies automatically. Owen On Aug 5, 2011, at 9:17 AM, Brian Mengel wrote:
In reviewing IPv6 end user allocation policies, I can find little agreement on what prefix length is appropriate for residential end users. /64 and /56 seem to be the favorite candidates, with /56 being slightly preferred.
I am most curious as to why a /60 prefix is not considered when trying to address this problem. It provides 16 /64 subnetworks, which seems like an adequate amount for an end user.
Does anyone have opinions on the BCP for end user addressing in IPv6?
Hi,
Let's clarify -- /48 is much preferred by Owen, but most ISPs seem to be zeroing in on a /56 for production. Though some ISPs are using /64 for their trials.
IIRC, there's RfC6177 - covering almost exactly what the original poster asked for. Not sure if it was mentioned already. /48 is what IPv6 was designed for, /48 per customer (or even per customer-site some might say) is supported by the RIR policies, and there are close to zero reasons not to use a /48. It also eases your administration processes and also operational things. Of course, if you only have John Average residential customers or whatever, use a /56 or /60. It's your choice. You know your customers best. We're not in a classful world again :-) But do your math, there is no address shortage, handing out a /48 to every type of customer as a single assignment size should be the sane choice. You waste precious time thinking too much about it. At least don't make your life miserable by experimenting with too many different assignment sizes, or advocate /64s or something, that's considered a design fault which will come back to you some day. Read the RfCs and RIR policy discussions in the archives some years ago. -- Mit freundlichen Grüßen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect
On Aug 6, 2011, at 12:47 AM, Sascha Lenz wrote:
Hi,
Let's clarify -- /48 is much preferred by Owen, but most ISPs seem to be zeroing in on a /56 for production. Though some ISPs are using /64 for their trials.
IIRC, there's RfC6177 - covering almost exactly what the original poster asked for. Not sure if it was mentioned already.
RFC6177 sort of appears to recommend /56 if you don't look at it too closely. What it really says is essentially "The IETF throws its hands up in the air and refuses to make any recommendations in this arena leaving the entire thing to RIRs and service providers where we probably should have put it in the first place."
/48 is what IPv6 was designed for, /48 per customer (or even per customer-site some might say) is supported by the RIR policies, and there are close to zero reasons not to use a /48. It also eases your administration processes and also operational things.
AMEN, Brother! ;-)
Of course, if you only have John Average residential customers or whatever, use a /56 or /60. It's your choice. You know your customers best. We're not in a classful world again :-) But do your math, there is no address shortage, handing out a /48 to every type of customer as a single assignment size should be the sane choice. You waste precious time thinking too much about it.
Yep. Even if you only have John Average residential customer. Residential customers today are not going to be the same as residential customers in 5, 15, or 25 years. Giving them /48s will save you (and them) a lot of heartache down the road. (and yes, I mean a /48 per end site structure or per tenant in a multi-tenant structure).
At least don't make your life miserable by experimenting with too many different assignment sizes, or advocate /64s or something, that's considered a design fault which will come back to you some day. Read the RfCs and RIR policy discussions in the archives some years ago.
Also, please don't make your life miserable by trying to align things on odd bit boundaries. Stick to nibbles. Owen
On Sat, Aug 6, 2011 at 5:21 AM, Owen DeLong <owen@delong.com> wrote:
At least don't make your life miserable by experimenting with too many different assignment sizes, or advocate /64s or something, that's considered a design fault which will come back to you some day. Read the RfCs and RIR policy discussions in the archives some years ago.
Note that in this thread, you advocate three things that are a little tough to make work together: * hierarchical addressing plan / routing * nibble-aligned addressing plan * minimum /48 per customer If I were, for example, a hosting company with IPv6 terminated at the layer-3 ToR switch, I would then use a /40 per rack of typical "dedicated servers." If you then want some bits to be a POP-locator field for your hierarchical routing scheme, you are already forced to request more than a /32. The number of customers per layer-3 device for typical end-user access networks was around the same into the late-1990s/early-2000s, as ISPs had racks of Portmasters or whatever box of choice for terminating dial-up. Densities have changed, but this doesn't necessarily win you an advantage when combining those three properties. This is especially true if you consider that density may change in a difficult-to-predict manner in the future -- a BRAS box with a couple thousand customers today might have three times as many in a couple of years (IPv6 is supposed to help us avoid renumbering or injecting additional routes into our network, right?) As an access provider, if I shared your view, I would be reserving a /36 or /32 per BRAS box. If I then want some additional bits for hierarchical routing ... I'm going to need a pretty large address block for perhaps a pretty small number of customers. After all, my scheme, applying your logic, dictates that I should use a /32 or perhaps a /28 per each POP or city (I need to plan for several BRAS each), even if I don't have a lot of customers today! I think /56 is more sensible than /48, given the above, for most end-users. Either way, the users will be gaining a lot more flexibility than they have with IPv4 today, where they probably get just one IP address and have to pay a fee for any extras. Giving the typical end-user 8 fewer bits worth of address space allows the ISP network more flexibility for hierarchical routing before they have to go to their RIR and figure out how to justify an out-sized allocation. Also, if folks would stop thinking that every subnet should be a /64, they will see that end-users, makers of set-top-gateways, or whatever, can certainly address a whole lot of devices in a whole lot of subnets even if the user is only given a /64. Do we think DHCPv6 won't be the most common way of assigning addresses on SOHO LANs, and that SLAAC will be essential? I, for one, think that some ISPs will be sick and twisted enough to hand out /128s so they can continue charging for more IP addresses; but certainly the makers of IPv6-enabled devices will foresee that end-user LANs might not be /64 and include the necessary functionality to work correctly with smaller subnets. Before you beat me to it, yes, we seem to have completely opposing views on this subject. I will change my mind when I can go to the RIR and get a IPv6 /24 for a small ISP with a few POPs and a few tens of thousands of customers. Should RIR policy permit that sort of thing? -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
On Aug 6, 2011, at 3:15 AM, Jeff Wheeler wrote:
On Sat, Aug 6, 2011 at 5:21 AM, Owen DeLong <owen@delong.com> wrote:
At least don't make your life miserable by experimenting with too many different assignment sizes, or advocate /64s or something, that's considered a design fault which will come back to you some day. Read the RfCs and RIR policy discussions in the archives some years ago.
Note that in this thread, you advocate three things that are a little tough to make work together: * hierarchical addressing plan / routing * nibble-aligned addressing plan * minimum /48 per customer
Hasn't been hard so far.
If I were, for example, a hosting company with IPv6 terminated at the layer-3 ToR switch, I would then use a /40 per rack of typical "dedicated servers." If you then want some bits to be a POP-locator field for your hierarchical routing scheme, you are already forced to request more than a /32. The number of customers per layer-3 device for typical end-user access networks was around the same into the late-1990s/early-2000s, as ISPs had racks of Portmasters or whatever box of choice for terminating dial-up.
I think we were talking about access customers. I don't see giving /48s to individual dedicated servers as I don't see them having hierarchy behind them. I would think that a /48 per TOR switch would be reasonable in that case. However, requesting more than a /32 is perfectly reasonable. In the ARIN region, policy 2011-3.
Densities have changed, but this doesn't necessarily win you an advantage when combining those three properties. This is especially true if you consider that density may change in a difficult-to-predict manner in the future -- a BRAS box with a couple thousand customers today might have three times as many in a couple of years (IPv6 is supposed to help us avoid renumbering or injecting additional routes into our network, right?) As an access provider, if I shared your view, I would be reserving a /36 or /32 per BRAS box. If I then want some additional bits for hierarchical routing ... I'm going to need a pretty large address block for perhaps a pretty small number of customers. After all, my scheme, applying your logic, dictates that I should use a /32 or perhaps a /28 per each POP or city (I need to plan for several BRAS each), even if I don't have a lot of customers today!
Correct… I think a /36 per BRAS seems about right, but if you want to put more than 3072 customers on a single BRAS and expect technology to eventually support that, sure, go for a /32 per BRAS. If you want to isolate your routing down to per BRAS (most providers I'm aware of that have multiple BRAS have it set up so any customer in a given POP may connect to any BRAS and they carry the customer prefixes within the POP's routing table), then, I think a /36 per BRAS is probably OK (up to 3072 customers at 75% utilization, 4096 max), but, if you really think you will have 6,000 customer BRAS units, then, yes, a /32 would be correct. However, I would be more likely to assign hierarchy per POP instead. Figure out how many customers are likely in my largest POP and allocate based on /48 per customer+growth in that POP. For example, if my largest POP would serve 2,000 customer end-sites, I'd be looking at a /36 per POP. If the largest POP served 3,073 customer end-sites or even 49,000 customer end-sites, I'd plan on a /32 per POP. Basically take the number of customer end-sites in your largest POP, divide by 0.75 (keep 25% headroom minimum) and then round up to the nearest nibble. If you really think you will have more than 786,432 customer sites served from your largest POP, then, I suppose a /28 per POP is a reasonable request. That seems like pretty unlikely density, even in 20 years. I realize that customer density in urban areas does tend to increase, but, assuming a maximum 50% market penetration, serving a city the size of Philadelphia out of a single POP still seems unlikely to me.
I think /56 is more sensible than /48, given the above, for most end-users. Either way, the users will be gaining a lot more flexibility than they have with IPv4 today, where they probably get just one IP address and have to pay a fee for any extras. Giving the typical end-user 8 fewer bits worth of address space allows the ISP network more flexibility for hierarchical routing before they have to go to their RIR and figure out how to justify an out-sized allocation.
Why? You point out that giving out /48s would require larger IPv6 allocations than /32, but, you don't give any reason to think this is bad. Let's look at the math. Let's assume a moderately large provider expects to serve 45,000 customer end-sites out of their largest POP (does anyone actually expect numbers this large in a single POP)? Now, let's say you have 50 POPs across your service region and expect to triple in size over the next 5 years. That's 150 total POPs planned. 45,000 customer end sites with 25% minfree is 60,000 which, when rounded up to a nibble is 16 bits for 65,536. 150 POPs with 25% minfree is 200 which, when rounded up to a nibble is 8 bits for 256 total POPs possible. 16+8 = 24, so, such a provider would need a /24 for their access network. There are 512 /24s in each of the /12s (what the IANA issues to RIRs).
Also, if folks would stop thinking that every subnet should be a /64, they will see that end-users, makers of set-top-gateways, or whatever, can certainly address a whole lot of devices in a whole lot of subnets even if the user is only given a /64. Do we think DHCPv6 won't be the most common way of assigning addresses on SOHO LANs, and that SLAAC will be essential? I, for one, think that some ISPs will be sick and
Yes.
twisted enough to hand out /128s so they can continue charging for more IP addresses; but certainly the makers of IPv6-enabled devices will foresee that end-user LANs might not be /64 and include the necessary functionality to work correctly with smaller subnets.
I think natural selection in the market will solve that problem relatively quickly.
Before you beat me to it, yes, we seem to have completely opposing views on this subject. I will change my mind when I can go to the RIR and get a IPv6 /24 for a small ISP with a few POPs and a few tens of thousands of customers. Should RIR policy permit that sort of thing?
OK… Start changing your mind… Read 2011-3. It's been adopted in the ARIN region. I'd also like to suggest you consider supporting APNIC proposal 98 which is essentially the same policy and will be discussed at the Busan meeting. Owen
On Sat, Aug 6, 2011 at 12:36 PM, Owen DeLong <owen@delong.com> wrote:
On Aug 6, 2011, at 3:15 AM, Jeff Wheeler wrote:
Note that in this thread, you advocate three things that are a little tough to make work together: * hierarchical addressing plan / routing * nibble-aligned addressing plan * minimum /48 per customer
Hasn't been hard so far.
Well, you aren't actually doing this on your network today. If you practiced what you are preaching, you would not be carrying aggregate routes to your tunnel broker gateways across your whole backbone. Perhaps you also wouldn't use one allocation on the tunnel broker gateway for /64s and another, a /37 in the case of Ashburn for example, for users who self-provision a /48 from it. Also, of course, your default assignment plan is /64, not /48, even though there are typically around, what, 10k tunnels active network-wide? To be clear, you don't do any of the three things you advocate above where Hurricane Electric's tunnel broker service is concerned.
I think we were talking about access customers. I don't see giving /48s to individual dedicated servers as I don't see them having hierarchy behind them. I would think that a /48 per TOR switch would be reasonable in that case.
I wish there was more discussion about IPv6 addressing plans in hosting environments on this list. I think that, rarely, customers will decide to tunnel from their home or office to their "dedicated server," co-lo rack, etc. My addressing policies provide for this type of customer to receive a /56 upon request without breaking my hierarchical addressing scheme. If they need more than that, the layer-3 aggregator has to inject an additional route into the POP area. If a whole bunch of customers on one aggregator ask for /56, then the aggregator needs an extra /48 (which might really mean growing its existing /48 to a shorter route.)
However, requesting more than a /32 is perfectly reasonable. In the ARIN region, policy 2011-3.
My read of that policy, and please correct me if I misunderstand, is that it recognizes only a two-level hierarchy. This would mean that an ISP could use some bits to represent a geographic region, a POP, or an aggregation router / address pool, but it does not grant them justification to reserve bits for all these purposes.
density, even in 20 years. I realize that customer density in urban areas does tend to increase, but, assuming a maximum 50% market penetration, serving a city the size of Philadelphia out of a single POP still seems unlikely to me.
AT&T serves some entire states out of a single POP, as far as layer-3 termination is concerned. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
On Aug 6, 2011, at 1:14 PM, Jeff Wheeler wrote:
On Sat, Aug 6, 2011 at 12:36 PM, Owen DeLong <owen@delong.com> wrote:
On Aug 6, 2011, at 3:15 AM, Jeff Wheeler wrote:
Note that in this thread, you advocate three things that are a little tough to make work together: * hierarchical addressing plan / routing * nibble-aligned addressing plan * minimum /48 per customer
Hasn't been hard so far.
Well, you aren't actually doing this on your network today. If you practiced what you are preaching, you would not be carrying aggregate routes to your tunnel broker gateways across your whole backbone.
Yes we would.
Perhaps you also wouldn't use one allocation on the tunnel broker gateway for /64s and another, a /37 in the case of Ashburn for example, for users who self-provision a /48 from it. Also, of course, your default assignment plan is /64, not /48, even though there are typically around, what, 10k tunnels active network-wide?
Those are artifacts of a small allocation (/32) from a prior RIR policy. The fact that those things haven't worked out so well for us was one of the motivations behind developing policy 2011-3.
To be clear, you don't do any of the three things you advocate above where Hurricane Electric's tunnel broker service is concerned.
Yes we do. We give a minimum /48 per customer with the small exception that customers who only want one subnet get a /64. We will be implementing a nibble-aligned addressing plan as soon as we can get enough space from the RIR. That's pending implementation of 2011-3. We do have a hierarchical addressing plan. I said nothing about routing, but, we certainly could implement hierarchical routing if we arrived at a point where it was advantageous because we have designed for it.
I think we were talking about access customers. I don't see giving /48s to individual dedicated servers as I don't see them having hierarchy behind them. I would think that a /48 per TOR switch would be reasonable in that case.
I wish there was more discussion about IPv6 addressing plans in hosting environments on this list. I think that, rarely, customers will decide to tunnel from their home or office to their "dedicated server," co-lo rack, etc. My addressing policies provide for this type of customer to receive a /56 upon request without breaking my hierarchical addressing scheme. If they need more than that, the layer-3 aggregator has to inject an additional route into the POP area. If a whole bunch of customers on one aggregator ask for /56, then the aggregator needs an extra /48 (which might really mean growing its existing /48 to a shorter route.)
Sounds like a mess. We'll stick with /48s for people that need more than a /64.
However, requesting more than a /32 is perfectly reasonable. In the ARIN region, policy 2011-3.
My read of that policy, and please correct me if I misunderstand, is that it recognizes only a two-level hierarchy. This would mean that an ISP could use some bits to represent a geographic region, a POP, or an aggregation router / address pool, but it does not grant them justification to reserve bits for all these purposes.
While that's theoretically true, the combination of 25% minfree , nibble boundaries, and equal sized allocations for all POPs based on your largest one allows for that in practical terms in most circumstances.
density, even in 20 years. I realize that customer density in urban areas does tend to increase, but, assuming a maximum 50% market penetration, serving a city the size of Philadelphia out of a single POP still seems unlikely to me.
AT&T serves some entire states out of a single POP, as far as layer-3 termination is concerned.
Are any of the states with populations larger than Philadelphia among them? Owen
On Sat, Aug 6, 2011 at 7:26 PM, Owen DeLong <owen@delong.com> wrote:
Well, you aren't actually doing this on your network today. If you practiced what you are preaching, you would not be carrying aggregate routes to your tunnel broker gateways across your whole backbone.
Yes we would.
No, if you actually had a hierarchical addressing scheme, you would issue tunnel broker customer /64s from the same aggregate prefix that is used for their /48s. You'd then summarize at your ABRs so the entire POP need only inject one route for customer addressing into the backbone. Of course, this is not what you do today, and not because of limited RIR allocation policies -- but because you simply did not design your network with such route aggregation in mind.
Those are artifacts of a small allocation (/32) from a prior RIR policy. The fact that those things haven't worked out so well for us was one of the motivations behind developing policy 2011-3.
There was nothing stopping you from using one /48 out of the /37s you use to issue customer /48 networks for issuing the default /64 blocks your tunnel broker hands out.
We give a minimum /48 per customer with the small exception that customers who only want one subnet get a /64.
You assign a /64 by default. Yes, customers can click a button and get themselves a /48 instantly, but let's tell the truth when talking about your current defaults -- customers are assigned a /64, not a /48.
We do have a hierarchical addressing plan. I said nothing about routing, but, we certainly could implement hierarchical routing if we arrived at a point where it was advantageous because we have designed for it.
How have you designed for it? You already missed easy opportunities to inject fewer routes into your backbone, simply by using different aggregate prefixes for customer /64s vs /48s.
However, requesting more than a /32 is perfectly reasonable. In the ARIN region, policy 2011-3.
My read of that policy, and please correct me if I misunderstand, is that it recognizes only a two-level hierarchy. This would mean that an ISP could use some bits to represent a geographic region, a POP, or an aggregation router / address pool, but it does not grant them justification to reserve bits for all these purposes.
While that's theoretically true, the combination of 25% minfree , nibble boundaries, and equal sized allocations for all POPs based on your largest one allows for that in practical terms in most circumstances.
I don't think it does allow for that. I think it requires you to have at least one "POP prefix" 75% full before you can get any additional space from the RIR, where 75% full means routed to customers, not reserved for aggregation router pools. This is not a hierarchy, it is simply a scheme to permit ISPs to bank on having at least one level of summarization in their addressing and routing scheme. 2011-3 does not provide for an additional level to summarize on the aggregation routers themselves. It should, but my read is that the authors have a very different opinion about what "hierarchical" addressing means than I do. It should provide for route aggregation on both the ABR and the aggregation router itself.
AT&T serves some entire states out of a single POP, as far as layer-3 termination is concerned.
Are any of the states with populations larger than Philadelphia among them?
Yes, for example, Indiana. Pretty much every state in the former Ameritech service territory. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
This has probably been said before, but it makes me uncomfortable to think of everybody in the world being given /48 subnets by default. All of a sudden that wide expanse of 2^128 IP addresses shrinks to 2^48 sites. Sure that's still 65535 times more than 2^32 IPv4 addresses, but wouldn't it be wise to apply some conservatism now to allow the IPv6 address space to last for many more years? After all, there are only 4 bits of IP version field so the basic packet format won't last forever. Jonathon This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not be used,copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate an information system; and do not give rise to any liability for Kordia(R).
On Aug 7, 2011, at 3:09 PM, Jonathon Exley wrote:
This has probably been said before, but it makes me uncomfortable to think of everybody in the world being given /48 subnets by default. All of a sudden that wide expanse of 2^128 IP addresses shrinks to 2^48 sites. Sure that's still 65535 times more than 2^32 IPv4 addresses, but wouldn't it be wise to apply some conservatism now to allow the IPv6 address space to last for many more years?
2000::/3 is 1/8th of the address range. There are other things worth conserving not just /48s like the ability aggregate your whole assignment. 3.5 * 10^13 is a lot of /48s, but it's likely not enough so we'll get to crack the seal on 4000::/3 eventually and so on.
After all, there are only 4 bits of IP version field so the basic packet format won't last forever.
Jonathon
This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not be used,copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate an information system; and do not give rise to any liability for Kordia(R).
Jonathon, On Aug 7, 2011, at 12:09 PM, Jonathon Exley wrote:
This has probably been said before,
Once or twice :-)
but it makes me uncomfortable to think of everybody in the world being given /48 subnets by default.
This isn't where the worry should be. Do the math. Right now, we're allocating something like 300,000,000 IPv4 addresses per year with a reasonable (handwave) percentage being used as NAT endpoints. If you cross your eyes sufficiently, that can look a bit like 300,000,000 networks being added per year. Translate that to IPv6 and /48s: There are 35,184,372,088,832 /48s in the format specifier currently defined for "global unicast". For the sake of argument, let's increase the the 'network addition' rate by 3 orders of magnitude to 300,000,000,000 per year. At that rate, which is equivalent to allocating 42 /48s per person on the planet per year, the current format specifier will last about 100 years. And there are 7 more format specifiers.
but wouldn't it be wise to apply some conservatism now to allow the IPv6 address space to last for many more years?
The area to be more conservative is, perhaps unsurprisingly, in the network bureaucratic layer. I believe current allocation policy states an ISP gets a minimum of a /32 (allowing them to assign 65536 /48s), but "if justified" an ISP can get more. There have been allocations of all sorts of shorter prefixes, e.g., /19s, /18s, and even (much) shorter. An ISP that has received a /19 has the ability to allocate half a billion /48s. And of course, there are the same number of /19s, /18s, and even (much) shorter prefixes in IPv6 as there are in IPv4...
After all, there are only 4 bits of IP version field so the basic packet format won't last forever.
True. There is no finite resource poor policy making can't make scarce. Regards, -drc
On Sun, Aug 7, 2011 at 6:09 PM, Jonathon Exley <Jonathon.Exley@kordia.co.nz> wrote:
This has probably been said before, but it makes me uncomfortable to think of everybody in the world being given /48 subnets by default. All of a sudden that wide expanse of 2^128 IP addresses shrinks to 2^48 sites. Sure that's still 65535 times more than 2^32 IPv4 addresses, but wouldn't it be wise to apply some conservatism now to allow the IPv6 address space to last for many more years? After all, there are only 4 bits of IP version field so the basic packet format won't last forever.
Hi Jonathan, IPv6 uses a slightly different mental model when it comes to address allocation. In IPv4 you assigned blocks of 32-bit addresses. In IPv6 this is no longer the case. You do not assign blocks of 128-bit addresses. In IPv6 you assign blocks of 64-bit LANs. Each LAN is 64-bits long as required by technologies like SLAAC. So, a /48 is 65k LANs, _not_ however many bazillion addresses. The question you should be asking is: is it excessive or unwise to go around assigning 65,000 LANs to every customer? Would 256 (/56) or 1 (/64) be a better number? Assigning 1 LAN seems questionable. We're trying to avoid NAT with IPv6 which means a customer may want to spend a LAN on things like the interior network of a virtual machine server. It's hard to do this if you only have one LAN. On the other hand, a whole lot of folks have through this through before you and concluded that a /56 (256 LANs per customer) is a smarter starting point than a /48. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Aug 7, 2011, at 3:09 PM, Jonathon Exley wrote:
This has probably been said before, but it makes me uncomfortable to think of everybody in the world being given /48 subnets by default. All of a sudden that wide expanse of 2^128 IP addresses shrinks to 2^48 sites. Sure that's still 65535 times more than 2^32 IPv4 addresses, but wouldn't it be wise to apply some conservatism now to allow the IPv6 address space to last for many more years? After all, there are only 4 bits of IP version field so the basic packet format won't last forever.
Let's look at this realistically. In 30+ years of internet development, giving IP addresses to lots of things besides just single sites, we still haven't completely used up the 32 bit space. This includes reserving 1/16th of it for unknown purposes that are never to be. 65,536 times enough space for all the sites we deployed in 30+ years will more than likely outlast the lifetime of the protocol, so, yeah, I'm OK with giving every end-site in the world (note an end-site is not a person, it's a building, structure, or tenant in a multi-tenant building or structure). Owen P.S. Jonathon: If anything in your email was confidential, too bad. You posted it to a public list. Silly notice at the bottom to that effect removed.
Silly confidentiality notices are usually enforced by silly corporate IT departments and cannot be removed by mere mortal employees. They are an unavoidable part of life, like Outlook top posting and spam. Jonathon. -----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Tuesday, 9 August 2011 8:26 a.m. To: Jonathon Exley Cc: nanog@nanog.org Subject: Re: IPv6 end user addressing [snip] P.S. Jonathon: If anything in your email was confidential, too bad. You posted it to a public list. Silly notice at the bottom to that effect removed. This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not be used,copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate an information system; and do not give rise to any liability for Kordia(R).
On Aug 8, 6:24 pm, Jonathon Exley <Jonathon.Ex...@kordia.co.nz> wrote:
Silly confidentiality notices are usually enforced by silly corporate IT departments
Oh, no, it's the *legal* department (or maybe HR) that is to blame. I actually had a guardhouse lawyer kick and scream about us not putting disclaimers on our emails. I told him, "You do realize that email disclaimers have no legal standing, have never been successfully used in any litigation, do nothing to prevent loss of corporate assets, and actually increase our liability by outlining a corporate policy that may not be followed 100% internally by all employees, right?" It took a long while and an embarrassing number of meetings with senior management, but we eventually put a stop to the whole thing.
Silly confidentiality notices are usually enforced by silly corporate IT departments and cannot be removed by mere mortal employees. They are an unavoidable part of life, like Outlook top posting and spam.
Alternatively, if your corporate email imposes stupid policies and / or a stupid email client (note: it's possible to quote properly and not top-post with Outlook, it's just hard work), don't subscribe to mailing lists from your corporate email. Of all the mailing list communities, I'd expect this one not to struggle very much with arranging an alternative... Regards, Tim.
On Tue, 09 Aug 2011 11:24:03 +1200, Jonathon Exley said:
Silly confidentiality notices are usually enforced by silly corporate IT departments and cannot be removed by mere mortal employees. They are an unavoidable part of life, like Outlook top posting and spam.
They may all three be things that we continually receive from clueless netizens. However, it is not at all difficult for anybody clued enough to get subscribed to NANOG to find ways to avoid inflicting all three on the rest of us.
In message <CAPWAtbJtPMDx-NzU8UphoSy+97ygo4Fknz5_eSghsjp-aN9x_A@mail.gmail.com> , Jeff Wheeler writes:
On Sat, Aug 6, 2011 at 7:26 PM, Owen DeLong <owen@delong.com> wrote:
Well, you aren't actually doing this on your network today. =A0If you practiced what you are preaching, you would not be carrying aggregate routes to your tunnel broker gateways across your whole backbone.
Yes we would.
No, if you actually had a hierarchical addressing scheme, you would issue tunnel broker customer /64s from the same aggregate prefix that is used for their /48s. You'd then summarize at your ABRs so the entire POP need only inject one route for customer addressing into the backbone. Of course, this is not what you do today, and not because of limited RIR allocation policies -- but because you simply did not design your network with such route aggregation in mind.
Those are artifacts of a small allocation (/32) from a prior RIR policy. The fact that those things haven't worked out so well for us was one of the motivations behind developing policy 2011-3.
There was nothing stopping you from using one /48 out of the /37s you use to issue customer /48 networks for issuing the default /64 blocks your tunnel broker hands out.
So you want HE to force all their clients to renumber.
We give a minimum /48 per customer with the small exception that customers who only want one subnet get a /64.
You assign a /64 by default. Yes, customers can click a button and get themselves a /48 instantly, but let's tell the truth when talking about your current defaults -- customers are assigned a /64, not a /48.
The client can request a /48 or /64 as the initial allocation.
We do have a hierarchical addressing plan. I said nothing about routing, but, we certainly could implement hierarchical routing if we arrived at a point where it was advantageous because we have designed for it.
How have you designed for it? You already missed easy opportunities to inject fewer routes into your backbone, simply by using different aggregate prefixes for customer /64s vs /48s.
However, requesting more than a /32 is perfectly reasonable. In the ARIN region, policy 2011-3.
My read of that policy, and please correct me if I misunderstand, is that it recognizes only a two-level hierarchy. =A0This would mean that an ISP could use some bits to represent a geographic region, a POP, or an aggregation router / address pool, but it does not grant them justification to reserve bits for all these purposes.
While that's theoretically true, the combination of 25% minfree , nibble boundaries, and equal sized allocations for all POPs based on your largest one allows for that in practical terms in most circumstances.
I don't think it does allow for that. I think it requires you to have at least one "POP prefix" 75% full before you can get any additional space from the RIR, where 75% full means routed to customers, not reserved for aggregation router pools. This is not a hierarchy, it is simply a scheme to permit ISPs to bank on having at least one level of summarization in their addressing and routing scheme.
2011-3 does not provide for an additional level to summarize on the aggregation routers themselves. It should, but my read is that the authors have a very different opinion about what "hierarchical" addressing means than I do. It should provide for route aggregation on both the ABR and the aggregation router itself.
AT&T serves some entire states out of a single POP, as far as layer-3 termination is concerned.
Are any of the states with populations larger than Philadelphia among them?
Yes, for example, Indiana. Pretty much every state in the former Ameritech service territory.
--=20 Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator=A0 /=A0 Innovative Network Concepts
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Sun, Aug 7, 2011 at 6:58 PM, Mark Andrews <marka@isc.org> wrote:
So you want HE to force all their clients to renumber.
No. I am simply pointing out that Owen exaggerated when he stated that he implements the following three practices together on his own networks: * hierarchical addressing * nibble-aligned addressing * /48 per access customer You can simply read the last few messages in this thread to learn that his recommendations on this list are not even practical for his network today, because as Owen himself says, they are not yet able to obtain additional RIR allocations. HE certainly operates a useful, high-profile tunnel-broker service which is IMO a very great asset to the Internet at-large; but if you spend a few minutes looking at the publicly available statistics on this service, they average only around 10,000 active tunnels across all their tunnel termination boxes combined. They have not implemented the policies recommended by Owen because, as he states, a /32 is not enough. Do I think the position he advocates will cause the eventual exhaustion of IPv6? Well, let's do an exercise: There has been some rather simplistic arithmetic posted today, 300m new subnets per year, etc. with zero consideration of address/subnet utilization efficiency within ISP networks and individual aggregation router pools. That is foolish. We can all pull out a calculator and figure that 2000::/3 has space for 35 trillion /48 networks. That isn't how they will be assigned or routed. The effect of 2011-3 is that an out-sized ISP like AT&T has every justification for deciding to allocate 24 bits worth of subnet ID for their "largest POP," say, one that happens to terminate layer-3 services for all customers in an entire state. They then have policy support for allocating the same sized subnet for every other POP, no matter how small. After all, the RIR policy permits them to obtain additional allocations as soon as one POP subnet has become full. So now you have a huge ISP with a few huge POPs, and a lot of small ones, justified in assigning the same size aggregate prefix, suitable for 2^24 subnets, to all those small POPs as well. How many layer-3 POPs might this huge ISP have? Any number. It could be every central office with some kind of layer-3 customer aggregation router. It could even be every road-side hut for FTTH services. Perhaps they will decide to address ten thousand POPs this way. Now the nibble-aligned language in the policy permits them to round up from 10,000 POPs to 16 bits worth of address space for "POP ID." So AT&T is quite justified in requesting: 48 (customer subnet length) - 24 (largest POP subnet ID size) - 16 (POP ID) == a /8 subnet for themselves. Now you can see how this policy, and addressing scheme, is utterly brain-dead. It really does put you (and me, and everyone else) in real danger of exhausting the IPv6 address space. All it takes is a few out-sized ISPs, with one large POP each and a bunch of smaller ones, applying for the maximum amount of address space permitted them under 2011-3. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
On Aug 7, 2011, at 4:26 PM, Jeff Wheeler wrote:
On Sun, Aug 7, 2011 at 6:58 PM, Mark Andrews <marka@isc.org> wrote:
So you want HE to force all their clients to renumber.
No. I am simply pointing out that Owen exaggerated when he stated that he implements the following three practices together on his own networks: * hierarchical addressing * nibble-aligned addressing * /48 per access customer
You can simply read the last few messages in this thread to learn that his recommendations on this list are not even practical for his network today, because as Owen himself says, they are not yet able to obtain additional RIR allocations. HE certainly operates a useful, high-profile tunnel-broker service which is IMO a very great asset to the Internet at-large; but if you spend a few minutes looking at the publicly available statistics on this service, they average only around 10,000 active tunnels across all their tunnel termination boxes combined. They have not implemented the policies recommended by Owen because, as he states, a /32 is not enough.
Do I think the position he advocates will cause the eventual exhaustion of IPv6? Well, let's do an exercise:
There has been some rather simplistic arithmetic posted today, 300m new subnets per year, etc. with zero consideration of address/subnet utilization efficiency within ISP networks and individual aggregation router pools. That is foolish. We can all pull out a calculator and figure that 2000::/3 has space for 35 trillion /48 networks. That isn't how they will be assigned or routed.
The effect of 2011-3 is that an out-sized ISP like AT&T has every justification for deciding to allocate 24 bits worth of subnet ID for their "largest POP," say, one that happens to terminate layer-3 services for all customers in an entire state. They then have policy support for allocating the same sized subnet for every other POP, no matter how small. After all, the RIR policy permits them to obtain additional allocations as soon as one POP subnet has become full.
So now you have a huge ISP with a few huge POPs, and a lot of small ones, justified in assigning the same size aggregate prefix, suitable for 2^24 subnets, to all those small POPs as well. How many layer-3 POPs might this huge ISP have? Any number. It could be every central office with some kind of layer-3 customer aggregation router. It could even be every road-side hut for FTTH services. Perhaps they will decide to address ten thousand POPs this way.
Now the nibble-aligned language in the policy permits them to round up from 10,000 POPs to 16 bits worth of address space for "POP ID." So AT&T is quite justified in requesting: 48 (customer subnet length) - 24 (largest POP subnet ID size) - 16 (POP ID) == a /8 subnet for themselves.
Right up until you read: 6.5.3 (d): If an LIR has already reached a /12 or more, ARIN will allocate a single additional /12 rather than continue expanding nibble boundaries. As you can see, there is a safety valve in the policy at /12 for just this reason.
Now you can see how this policy, and addressing scheme, is utterly brain-dead. It really does put you (and me, and everyone else) in real danger of exhausting the IPv6 address space. All it takes is a few out-sized ISPs, with one large POP each and a bunch of smaller ones, applying for the maximum amount of address space permitted them under 2011-3.
Even by your calculations, it would take 256 such outsized ISPs without a safety valve. With the safety valve that is built into the policy at /12, it would take 4,096 such ISPs. I do not believe that there are more than about 20 such ISPs world wide at this time and would put the foreseeable likely maximum at less than 100 due to the need for customers to support such outsized ISPs and the limited base that would have to be divided among them. Owen
we assign /112 per "end user vlan (or server)" at this moment... works perfectly fine (and thats even "a bit too big"). - nobody wants to use dynamic ips on -servers- or -router links- anyway i -really- can't see why people don't just use subnets with just the required number of addresses. take one /64 (for /64's sake ;), split it up into subnets which each have the required number of addresses (lets say you have 2-4 addresses for each bgp/router link, so you simply split it up into subnets that size) etc. no need to use /64 for -everything- at all, just because it fits (ethernet) mac addresses (as if ethernet will be around longer than ipv6 ha-ha, someone will come up with something faster tomorrow and then its bye bye ethernet, the 10ge variant is getting slow, and the 100ge variant is not even standardized yet, and trunking is a bottleneck ;) we don't use /24's for -everything- on ipv4 now do we :P (oh wait, there once was a time where we did.. due to another retarded semi-automatic configuration thingy, called RIP , which also only seemed to understand /24 or bigger ;) -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. & Co. KG ========================================================================= Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: sven@cb3rob.net ========================================================================= <penpen> C3P0, der elektrische Westerwelle http://www.facebook.com/cb3rob ========================================================================= Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Mon, 8 Aug 2011, Owen DeLong wrote:
On Aug 7, 2011, at 4:26 PM, Jeff Wheeler wrote:
On Sun, Aug 7, 2011 at 6:58 PM, Mark Andrews <marka@isc.org> wrote:
So you want HE to force all their clients to renumber.
No. I am simply pointing out that Owen exaggerated when he stated that he implements the following three practices together on his own networks: * hierarchical addressing * nibble-aligned addressing * /48 per access customer
You can simply read the last few messages in this thread to learn that his recommendations on this list are not even practical for his network today, because as Owen himself says, they are not yet able to obtain additional RIR allocations. HE certainly operates a useful, high-profile tunnel-broker service which is IMO a very great asset to the Internet at-large; but if you spend a few minutes looking at the publicly available statistics on this service, they average only around 10,000 active tunnels across all their tunnel termination boxes combined. They have not implemented the policies recommended by Owen because, as he states, a /32 is not enough.
Do I think the position he advocates will cause the eventual exhaustion of IPv6? Well, let's do an exercise:
There has been some rather simplistic arithmetic posted today, 300m new subnets per year, etc. with zero consideration of address/subnet utilization efficiency within ISP networks and individual aggregation router pools. That is foolish. We can all pull out a calculator and figure that 2000::/3 has space for 35 trillion /48 networks. That isn't how they will be assigned or routed.
The effect of 2011-3 is that an out-sized ISP like AT&T has every justification for deciding to allocate 24 bits worth of subnet ID for their "largest POP," say, one that happens to terminate layer-3 services for all customers in an entire state. They then have policy support for allocating the same sized subnet for every other POP, no matter how small. After all, the RIR policy permits them to obtain additional allocations as soon as one POP subnet has become full.
So now you have a huge ISP with a few huge POPs, and a lot of small ones, justified in assigning the same size aggregate prefix, suitable for 2^24 subnets, to all those small POPs as well. How many layer-3 POPs might this huge ISP have? Any number. It could be every central office with some kind of layer-3 customer aggregation router. It could even be every road-side hut for FTTH services. Perhaps they will decide to address ten thousand POPs this way.
Now the nibble-aligned language in the policy permits them to round up from 10,000 POPs to 16 bits worth of address space for "POP ID." So AT&T is quite justified in requesting: 48 (customer subnet length) - 24 (largest POP subnet ID size) - 16 (POP ID) == a /8 subnet for themselves.
Right up until you read:
6.5.3 (d): If an LIR has already reached a /12 or more, ARIN will allocate a single additional /12 rather than continue expanding nibble boundaries. As you can see, there is a safety valve in the policy at /12 for just this reason.
Now you can see how this policy, and addressing scheme, is utterly brain-dead. It really does put you (and me, and everyone else) in real danger of exhausting the IPv6 address space. All it takes is a few out-sized ISPs, with one large POP each and a bunch of smaller ones, applying for the maximum amount of address space permitted them under 2011-3.
Even by your calculations, it would take 256 such outsized ISPs without a safety valve. With the safety valve that is built into the policy at /12, it would take 4,096 such ISPs. I do not believe that there are more than about 20 such ISPs world wide at this time and would put the foreseeable likely maximum at less than 100 due to the need for customers to support such outsized ISPs and the limited base that would have to be divided among them.
Owen
On Mon, Aug 8, 2011 at 6:52 PM, Sven Olaf Kamphuis <sven@cb3rob.net> wrote:
we assign /112 per "end user vlan (or server)" at this moment... works perfectly fine (and thats even "a bit too big").
- nobody wants to use dynamic ips on -servers- or -router links- anyway
i -really- can't see why people don't just use subnets with just the required number of addresses.
Hi Sven, Stateless autoconfiguration (which is NOT dynamic IP addresses; the IP address is static but tied to the ethernet card) does not work unless the subnet mask is exactly /64. Even on a server lan you'll occasionally want to plug in a PC for diagnostics without having to poke in an IP address by hand. There are some great reasons to use a /112s or even smaller blocks for some applications. Use them that way, sure. But IMHO it's short-sighted to _assign_ address blocks at that size -- it means the person downstream has to come back to you and waste your time when they want to do anything else. And your choice delays them and wastes their time as well -- a fine "customer service" indeed. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
Once upon a time, William Herrin <bill@herrin.us> said:
Stateless autoconfiguration (which is NOT dynamic IP addresses; the IP address is static but tied to the ethernet card) does not work unless the subnet mask is exactly /64.
Even on a server lan you'll occasionally want to plug in a PC for diagnostics without having to poke in an IP address by hand.
Actually, nobody should be plugging any random device into my server LANs, and I certainly don't want to encourage it by having it work (even if just for IPv6). -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On Mon, Aug 8, 2011 at 11:43 PM, Chris Adams <cmadams@hiwaay.net> wrote:
Once upon a time, William Herrin <bill@herrin.us> said:
Even on a server lan you'll occasionally want to plug in a PC for diagnostics without having to poke in an IP address by hand.
Actually, nobody should be plugging any random device into my server LANs, and I certainly don't want to encourage it by having it work (even if just for IPv6).
When I send someone on site to do work for me, I don't want to have to prepare excessive instructions on how to connect their laptop to the local LAN. I want to say, "This switch, this port" and then move on to the actual work I sent them there to do. You're welcome to run your shop your way. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
-----Original Message----- From: William Herrin [mailto:bill@herrin.us] Sent: Tuesday, 9 August 2011 2:30 PM To: Chris Adams; nanog@nanog.org Subject: Re: IPv6 end user addressing
When I send someone on site to do work for me, I don't want to have to prepare excessive instructions on how to connect their laptop to the local LAN. I want to say, "This switch, this port" and then move on to the actual work I sent them there to do.
To be fair, if you're sending someone to site who isn't familiar with putting a static address on their laptop then you're probably doing things wrong to begin with. This line of argument isn't going to get us anywhere as for server networks, the benefits of using a /64 are not necessarily beneficial given the environment.
You're welcome to run your shop your way.
Regards, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
When I send someone on site to do work for me, I don't want to have to prepare excessive instructions on how to connect their laptop to the local LAN. I want to say, "This switch, this port" and then move on to the actual work I sent them there to do.
when i am allowed, i put up open wireless and dhcp. my job is to deliver packets. randy
On Mon, Aug 8, 2011 at 10:43 PM, Chris Adams <cmadams@hiwaay.net> wrote:
Even on a server lan you'll occasionally want to plug in a PC for diagnostics without having to poke in an IP address by hand. Actually, nobody should be plugging any random device into my server LANs, and I certainly don't want to encourage it by having it work (even if just for IPv6).
If you must not have someone plugging into your server LAN without permission, you turn unused ports off, or preferably, place them in a VLAN island with no topological connection to anything. Because it's going to be easier to turn the port back on, than to give someone a 128-bit IP6 address, IPv6 netmask, IPv6 DNS servers, and IPv6 default gateway address set to manually key into their machine. If someone can get to a live port, assuming it's not protected by 802.1x port security or similar; IPv6 will "just work" for fe80:: network link-local connectivity, whether you deploy stateless auto-config or not, which is enough connectivity to find and mess with servers in the LAN. And probably enough connectivity to say "that's too much connectivity", if the LAN is indeed restricted. Similar to how IPv4 has rfc3927, except IPv6 link local addresses get assigned, even to devices that have global IPv6 IPs, so the link local 'subnet' is active even on fully connected devices.
Chris Adams <cmadams@hiwaay.net>
Regards, -- -JH
Once upon a time, Jimmy Hess <mysidia@gmail.com> said:
If you must not have someone plugging into your server LAN without permission, you turn unused ports off, or preferably, place them in a VLAN island with no topological connection to anything.
That's about what I do; unused ports are in a different VLAN. I have a separate LAN for notebooks, etc. that has DHCP (and will have a v6 /64 when I get v6 to that point). -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
I heard at one time that hardware manufacturers were likely to route in hardware only down to a /64, and that any smaller subnets would be subject to the "slow path" as ASICs were being designed with 64-bit address tables. I have no idea of the validity of that claim. Does anyone have any concrete evidence for or against this argument? If true, it would make /64s even more attractive. -Randy ----- Original Message -----
we assign /112 per "end user vlan (or server)" at this moment... works perfectly fine (and thats even "a bit too big").
- nobody wants to use dynamic ips on -servers- or -router links- anyway
i -really- can't see why people don't just use subnets with just the required number of addresses.
take one /64 (for /64's sake ;), split it up into subnets which each have the required number of addresses (lets say you have 2-4 addresses for each bgp/router link, so you simply split it up into subnets that size)
etc.
no need to use /64 for -everything- at all, just because it fits (ethernet) mac addresses (as if ethernet will be around longer than ipv6 ha-ha, someone will come up with something faster tomorrow and then its bye bye ethernet, the 10ge variant is getting slow, and the 100ge variant is not even standardized yet, and trunking is a bottleneck ;)
we don't use /24's for -everything- on ipv4 now do we :P
(oh wait, there once was a time where we did.. due to another retarded semi-automatic configuration thingy, called RIP , which also only seemed to understand /24 or bigger ;)
-- Greetings,
Sven Olaf Kamphuis, CB3ROB Ltd. & Co. KG ========================================================================= Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: sven@cb3rob.net ========================================================================= <penpen> C3P0, der elektrische Westerwelle http://www.facebook.com/cb3rob =========================================================================
Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited.
On Mon, 8 Aug 2011, Owen DeLong wrote:
On Aug 7, 2011, at 4:26 PM, Jeff Wheeler wrote:
On Sun, Aug 7, 2011 at 6:58 PM, Mark Andrews <marka@isc.org> wrote:
So you want HE to force all their clients to renumber.
No. I am simply pointing out that Owen exaggerated when he stated that he implements the following three practices together on his own networks: * hierarchical addressing * nibble-aligned addressing * /48 per access customer
You can simply read the last few messages in this thread to learn that his recommendations on this list are not even practical for his network today, because as Owen himself says, they are not yet able to obtain additional RIR allocations. HE certainly operates a useful, high-profile tunnel-broker service which is IMO a very great asset to the Internet at-large; but if you spend a few minutes looking at the publicly available statistics on this service, they average only around 10,000 active tunnels across all their tunnel termination boxes combined. They have not implemented the policies recommended by Owen because, as he states, a /32 is not enough.
Do I think the position he advocates will cause the eventual exhaustion of IPv6? Well, let's do an exercise:
There has been some rather simplistic arithmetic posted today, 300m new subnets per year, etc. with zero consideration of address/subnet utilization efficiency within ISP networks and individual aggregation router pools. That is foolish. We can all pull out a calculator and figure that 2000::/3 has space for 35 trillion /48 networks. That isn't how they will be assigned or routed.
The effect of 2011-3 is that an out-sized ISP like AT&T has every justification for deciding to allocate 24 bits worth of subnet ID for their "largest POP," say, one that happens to terminate layer-3 services for all customers in an entire state. They then have policy support for allocating the same sized subnet for every other POP, no matter how small. After all, the RIR policy permits them to obtain additional allocations as soon as one POP subnet has become full.
So now you have a huge ISP with a few huge POPs, and a lot of small ones, justified in assigning the same size aggregate prefix, suitable for 2^24 subnets, to all those small POPs as well. How many layer-3 POPs might this huge ISP have? Any number. It could be every central office with some kind of layer-3 customer aggregation router. It could even be every road-side hut for FTTH services. Perhaps they will decide to address ten thousand POPs this way.
Now the nibble-aligned language in the policy permits them to round up from 10,000 POPs to 16 bits worth of address space for "POP ID." So AT&T is quite justified in requesting: 48 (customer subnet length) - 24 (largest POP subnet ID size) - 16 (POP ID) == a /8 subnet for themselves.
Right up until you read:
6.5.3 (d): If an LIR has already reached a /12 or more, ARIN will allocate a single additional /12 rather than continue expanding nibble boundaries. As you can see, there is a safety valve in the policy at /12 for just this reason.
Now you can see how this policy, and addressing scheme, is utterly brain-dead. It really does put you (and me, and everyone else) in real danger of exhausting the IPv6 address space. All it takes is a few out-sized ISPs, with one large POP each and a bunch of smaller ones, applying for the maximum amount of address space permitted them under 2011-3.
Even by your calculations, it would take 256 such outsized ISPs without a safety valve. With the safety valve that is built into the policy at /12, it would take 4,096 such ISPs. I do not believe that there are more than about 20 such ISPs world wide at this time and would put the foreseeable likely maximum at less than 100 due to the need for customers to support such outsized ISPs and the limited base that would have to be divided among them.
Owen
I'm sure there will be platforms that end up on both sides of this question. YES: We made a less expensive box by cutting the width of the TCAM required in half. NO: We spared no expense and passed the costs (and a nice profit margin) on to you so that you can do whatever you like in IPv6 at wire speed. I'm sure the market will chose products from both sides of the line for the same reasons. Owen On Aug 8, 2011, at 4:34 PM, Randy Carpenter wrote:
I heard at one time that hardware manufacturers were likely to route in hardware only down to a /64, and that any smaller subnets would be subject to the "slow path" as ASICs were being designed with 64-bit address tables. I have no idea of the validity of that claim. Does anyone have any concrete evidence for or against this argument?
If true, it would make /64s even more attractive.
-Randy
----- Original Message -----
we assign /112 per "end user vlan (or server)" at this moment... works perfectly fine (and thats even "a bit too big").
- nobody wants to use dynamic ips on -servers- or -router links- anyway
i -really- can't see why people don't just use subnets with just the required number of addresses.
take one /64 (for /64's sake ;), split it up into subnets which each have the required number of addresses (lets say you have 2-4 addresses for each bgp/router link, so you simply split it up into subnets that size)
etc.
no need to use /64 for -everything- at all, just because it fits (ethernet) mac addresses (as if ethernet will be around longer than ipv6 ha-ha, someone will come up with something faster tomorrow and then its bye bye ethernet, the 10ge variant is getting slow, and the 100ge variant is not even standardized yet, and trunking is a bottleneck ;)
we don't use /24's for -everything- on ipv4 now do we :P
(oh wait, there once was a time where we did.. due to another retarded semi-automatic configuration thingy, called RIP , which also only seemed to understand /24 or bigger ;)
-- Greetings,
Sven Olaf Kamphuis, CB3ROB Ltd. & Co. KG ========================================================================= Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: sven@cb3rob.net ========================================================================= <penpen> C3P0, der elektrische Westerwelle http://www.facebook.com/cb3rob =========================================================================
Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited.
On Mon, 8 Aug 2011, Owen DeLong wrote:
On Aug 7, 2011, at 4:26 PM, Jeff Wheeler wrote:
On Sun, Aug 7, 2011 at 6:58 PM, Mark Andrews <marka@isc.org> wrote:
So you want HE to force all their clients to renumber.
No. I am simply pointing out that Owen exaggerated when he stated that he implements the following three practices together on his own networks: * hierarchical addressing * nibble-aligned addressing * /48 per access customer
You can simply read the last few messages in this thread to learn that his recommendations on this list are not even practical for his network today, because as Owen himself says, they are not yet able to obtain additional RIR allocations. HE certainly operates a useful, high-profile tunnel-broker service which is IMO a very great asset to the Internet at-large; but if you spend a few minutes looking at the publicly available statistics on this service, they average only around 10,000 active tunnels across all their tunnel termination boxes combined. They have not implemented the policies recommended by Owen because, as he states, a /32 is not enough.
Do I think the position he advocates will cause the eventual exhaustion of IPv6? Well, let's do an exercise:
There has been some rather simplistic arithmetic posted today, 300m new subnets per year, etc. with zero consideration of address/subnet utilization efficiency within ISP networks and individual aggregation router pools. That is foolish. We can all pull out a calculator and figure that 2000::/3 has space for 35 trillion /48 networks. That isn't how they will be assigned or routed.
The effect of 2011-3 is that an out-sized ISP like AT&T has every justification for deciding to allocate 24 bits worth of subnet ID for their "largest POP," say, one that happens to terminate layer-3 services for all customers in an entire state. They then have policy support for allocating the same sized subnet for every other POP, no matter how small. After all, the RIR policy permits them to obtain additional allocations as soon as one POP subnet has become full.
So now you have a huge ISP with a few huge POPs, and a lot of small ones, justified in assigning the same size aggregate prefix, suitable for 2^24 subnets, to all those small POPs as well. How many layer-3 POPs might this huge ISP have? Any number. It could be every central office with some kind of layer-3 customer aggregation router. It could even be every road-side hut for FTTH services. Perhaps they will decide to address ten thousand POPs this way.
Now the nibble-aligned language in the policy permits them to round up from 10,000 POPs to 16 bits worth of address space for "POP ID." So AT&T is quite justified in requesting: 48 (customer subnet length) - 24 (largest POP subnet ID size) - 16 (POP ID) == a /8 subnet for themselves.
Right up until you read:
6.5.3 (d): If an LIR has already reached a /12 or more, ARIN will allocate a single additional /12 rather than continue expanding nibble boundaries. As you can see, there is a safety valve in the policy at /12 for just this reason.
Now you can see how this policy, and addressing scheme, is utterly brain-dead. It really does put you (and me, and everyone else) in real danger of exhausting the IPv6 address space. All it takes is a few out-sized ISPs, with one large POP each and a bunch of smaller ones, applying for the maximum amount of address space permitted them under 2011-3.
Even by your calculations, it would take 256 such outsized ISPs without a safety valve. With the safety valve that is built into the policy at /12, it would take 4,096 such ISPs. I do not believe that there are more than about 20 such ISPs world wide at this time and would put the foreseeable likely maximum at less than 100 due to the need for customers to support such outsized ISPs and the limited base that would have to be divided among them.
Owen
On Aug 8, 2011, at 5:14 PM, Owen DeLong wrote:
I'm sure there will be platforms that end up on both sides of this question.
I know of no asic in a switch that claims to support ipv6 that does it this way... That would tend to place you at a competitive disadvantage to broadcom/marvell/fulcrum/juniper/cisco if you implemented it that way... it's easier I imagine to simply reduce the size of the fib... given that switches routinely have to forward to neighbors on /126 or /127 prefix links I think that would be something of a mistake.
YES: We made a less expensive box by cutting the width of the TCAM required in half
NO: We spared no expense and passed the costs (and a nice profit margin) on to you so that you can do whatever you like in IPv6 at wire speed.
I'm sure the market will chose products from both sides of the line for the same reasons.
Owen
On Aug 8, 2011, at 4:34 PM, Randy Carpenter wrote:
I heard at one time that hardware manufacturers were likely to route in hardware only down to a /64, and that any smaller subnets would be subject to the "slow path" as ASICs were being designed with 64-bit address tables. I have no idea of the validity of that claim. Does anyone have any concrete evidence for or against this argument?
If true, it would make /64s even more attractive.
-Randy
----- Original Message -----
we assign /112 per "end user vlan (or server)" at this moment... works perfectly fine (and thats even "a bit too big").
- nobody wants to use dynamic ips on -servers- or -router links- anyway
i -really- can't see why people don't just use subnets with just the required number of addresses.
take one /64 (for /64's sake ;), split it up into subnets which each have the required number of addresses (lets say you have 2-4 addresses for each bgp/router link, so you simply split it up into subnets that size)
etc.
no need to use /64 for -everything- at all, just because it fits (ethernet) mac addresses (as if ethernet will be around longer than ipv6 ha-ha, someone will come up with something faster tomorrow and then its bye bye ethernet, the 10ge variant is getting slow, and the 100ge variant is not even standardized yet, and trunking is a bottleneck ;)
we don't use /24's for -everything- on ipv4 now do we :P
(oh wait, there once was a time where we did.. due to another retarded semi-automatic configuration thingy, called RIP , which also only seemed to understand /24 or bigger ;)
-- Greetings,
Sven Olaf Kamphuis, CB3ROB Ltd. & Co. KG ========================================================================= Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: sven@cb3rob.net ========================================================================= <penpen> C3P0, der elektrische Westerwelle http://www.facebook.com/cb3rob =========================================================================
Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited.
On Mon, 8 Aug 2011, Owen DeLong wrote:
On Aug 7, 2011, at 4:26 PM, Jeff Wheeler wrote:
On Sun, Aug 7, 2011 at 6:58 PM, Mark Andrews <marka@isc.org> wrote:
So you want HE to force all their clients to renumber.
No. I am simply pointing out that Owen exaggerated when he stated that he implements the following three practices together on his own networks: * hierarchical addressing * nibble-aligned addressing * /48 per access customer
You can simply read the last few messages in this thread to learn that his recommendations on this list are not even practical for his network today, because as Owen himself says, they are not yet able to obtain additional RIR allocations. HE certainly operates a useful, high-profile tunnel-broker service which is IMO a very great asset to the Internet at-large; but if you spend a few minutes looking at the publicly available statistics on this service, they average only around 10,000 active tunnels across all their tunnel termination boxes combined. They have not implemented the policies recommended by Owen because, as he states, a /32 is not enough.
Do I think the position he advocates will cause the eventual exhaustion of IPv6? Well, let's do an exercise:
There has been some rather simplistic arithmetic posted today, 300m new subnets per year, etc. with zero consideration of address/subnet utilization efficiency within ISP networks and individual aggregation router pools. That is foolish. We can all pull out a calculator and figure that 2000::/3 has space for 35 trillion /48 networks. That isn't how they will be assigned or routed.
The effect of 2011-3 is that an out-sized ISP like AT&T has every justification for deciding to allocate 24 bits worth of subnet ID for their "largest POP," say, one that happens to terminate layer-3 services for all customers in an entire state. They then have policy support for allocating the same sized subnet for every other POP, no matter how small. After all, the RIR policy permits them to obtain additional allocations as soon as one POP subnet has become full.
So now you have a huge ISP with a few huge POPs, and a lot of small ones, justified in assigning the same size aggregate prefix, suitable for 2^24 subnets, to all those small POPs as well. How many layer-3 POPs might this huge ISP have? Any number. It could be every central office with some kind of layer-3 customer aggregation router. It could even be every road-side hut for FTTH services. Perhaps they will decide to address ten thousand POPs this way.
Now the nibble-aligned language in the policy permits them to round up from 10,000 POPs to 16 bits worth of address space for "POP ID." So AT&T is quite justified in requesting: 48 (customer subnet length) - 24 (largest POP subnet ID size) - 16 (POP ID) == a /8 subnet for themselves.
Right up until you read:
6.5.3 (d): If an LIR has already reached a /12 or more, ARIN will allocate a single additional /12 rather than continue expanding nibble boundaries. As you can see, there is a safety valve in the policy at /12 for just this reason.
Now you can see how this policy, and addressing scheme, is utterly brain-dead. It really does put you (and me, and everyone else) in real danger of exhausting the IPv6 address space. All it takes is a few out-sized ISPs, with one large POP each and a bunch of smaller ones, applying for the maximum amount of address space permitted them under 2011-3.
Even by your calculations, it would take 256 such outsized ISPs without a safety valve. With the safety valve that is built into the policy at /12, it would take 4,096 such ISPs. I do not believe that there are more than about 20 such ISPs world wide at this time and would put the foreseeable likely maximum at less than 100 due to the need for customers to support such outsized ISPs and the limited base that would have to be divided among them.
Owen
It's at least true of how some of the Cisco platforms cope with IPv6 access lists. Owen On Aug 8, 2011, at 11:54 PM, Joel Jaeggli wrote:
On Aug 8, 2011, at 5:14 PM, Owen DeLong wrote:
I'm sure there will be platforms that end up on both sides of this question.
I know of no asic in a switch that claims to support ipv6 that does it this way... That would tend to place you at a competitive disadvantage to broadcom/marvell/fulcrum/juniper/cisco if you implemented it that way... it's easier I imagine to simply reduce the size of the fib...
given that switches routinely have to forward to neighbors on /126 or /127 prefix links I think that would be something of a mistake.
YES: We made a less expensive box by cutting the width of the TCAM required in half
NO: We spared no expense and passed the costs (and a nice profit margin) on to you so that you can do whatever you like in IPv6 at wire speed.
I'm sure the market will chose products from both sides of the line for the same reasons.
Owen
On Aug 8, 2011, at 4:34 PM, Randy Carpenter wrote:
I heard at one time that hardware manufacturers were likely to route in hardware only down to a /64, and that any smaller subnets would be subject to the "slow path" as ASICs were being designed with 64-bit address tables. I have no idea of the validity of that claim. Does anyone have any concrete evidence for or against this argument?
If true, it would make /64s even more attractive.
-Randy
----- Original Message -----
we assign /112 per "end user vlan (or server)" at this moment... works perfectly fine (and thats even "a bit too big").
- nobody wants to use dynamic ips on -servers- or -router links- anyway
i -really- can't see why people don't just use subnets with just the required number of addresses.
take one /64 (for /64's sake ;), split it up into subnets which each have the required number of addresses (lets say you have 2-4 addresses for each bgp/router link, so you simply split it up into subnets that size)
etc.
no need to use /64 for -everything- at all, just because it fits (ethernet) mac addresses (as if ethernet will be around longer than ipv6 ha-ha, someone will come up with something faster tomorrow and then its bye bye ethernet, the 10ge variant is getting slow, and the 100ge variant is not even standardized yet, and trunking is a bottleneck ;)
we don't use /24's for -everything- on ipv4 now do we :P
(oh wait, there once was a time where we did.. due to another retarded semi-automatic configuration thingy, called RIP , which also only seemed to understand /24 or bigger ;)
-- Greetings,
Sven Olaf Kamphuis, CB3ROB Ltd. & Co. KG ========================================================================= Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: sven@cb3rob.net ========================================================================= <penpen> C3P0, der elektrische Westerwelle http://www.facebook.com/cb3rob =========================================================================
Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited.
On Mon, 8 Aug 2011, Owen DeLong wrote:
On Aug 7, 2011, at 4:26 PM, Jeff Wheeler wrote:
On Sun, Aug 7, 2011 at 6:58 PM, Mark Andrews <marka@isc.org> wrote: > So you want HE to force all their clients to renumber.
No. I am simply pointing out that Owen exaggerated when he stated that he implements the following three practices together on his own networks: * hierarchical addressing * nibble-aligned addressing * /48 per access customer
You can simply read the last few messages in this thread to learn that his recommendations on this list are not even practical for his network today, because as Owen himself says, they are not yet able to obtain additional RIR allocations. HE certainly operates a useful, high-profile tunnel-broker service which is IMO a very great asset to the Internet at-large; but if you spend a few minutes looking at the publicly available statistics on this service, they average only around 10,000 active tunnels across all their tunnel termination boxes combined. They have not implemented the policies recommended by Owen because, as he states, a /32 is not enough.
Do I think the position he advocates will cause the eventual exhaustion of IPv6? Well, let's do an exercise:
There has been some rather simplistic arithmetic posted today, 300m new subnets per year, etc. with zero consideration of address/subnet utilization efficiency within ISP networks and individual aggregation router pools. That is foolish. We can all pull out a calculator and figure that 2000::/3 has space for 35 trillion /48 networks. That isn't how they will be assigned or routed.
The effect of 2011-3 is that an out-sized ISP like AT&T has every justification for deciding to allocate 24 bits worth of subnet ID for their "largest POP," say, one that happens to terminate layer-3 services for all customers in an entire state. They then have policy support for allocating the same sized subnet for every other POP, no matter how small. After all, the RIR policy permits them to obtain additional allocations as soon as one POP subnet has become full.
So now you have a huge ISP with a few huge POPs, and a lot of small ones, justified in assigning the same size aggregate prefix, suitable for 2^24 subnets, to all those small POPs as well. How many layer-3 POPs might this huge ISP have? Any number. It could be every central office with some kind of layer-3 customer aggregation router. It could even be every road-side hut for FTTH services. Perhaps they will decide to address ten thousand POPs this way.
Now the nibble-aligned language in the policy permits them to round up from 10,000 POPs to 16 bits worth of address space for "POP ID." So AT&T is quite justified in requesting: 48 (customer subnet length) - 24 (largest POP subnet ID size) - 16 (POP ID) == a /8 subnet for themselves.
Right up until you read:
6.5.3 (d): If an LIR has already reached a /12 or more, ARIN will allocate a single additional /12 rather than continue expanding nibble boundaries. As you can see, there is a safety valve in the policy at /12 for just this reason.
Now you can see how this policy, and addressing scheme, is utterly brain-dead. It really does put you (and me, and everyone else) in real danger of exhausting the IPv6 address space. All it takes is a few out-sized ISPs, with one large POP each and a bunch of smaller ones, applying for the maximum amount of address space permitted them under 2011-3.
Even by your calculations, it would take 256 such outsized ISPs without a safety valve. With the safety valve that is built into the policy at /12, it would take 4,096 such ISPs. I do not believe that there are more than about 20 such ISPs world wide at this time and would put the foreseeable likely maximum at less than 100 due to the need for customers to support such outsized ISPs and the limited base that would have to be divided among them.
Owen
On Aug 8, 2011, at 3:52 PM, Sven Olaf Kamphuis wrote:
we assign /112 per "end user vlan (or server)" at this moment... works perfectly fine (and thats even "a bit too big").
Sigh… Too big for what?
- nobody wants to use dynamic ips on -servers- or -router links- anyway
True… Guess what… Static addresses work in /64s as well. Better yet, your /64 will support adding troubleshooting equipment rapidly without having to hunt for an available address.
i -really- can't see why people don't just use subnets with just the required number of addresses.
Because we see real advantages to sparse addressing? Because it would make our lives unnecessarily more complicated? Because it will lead to additional human factors issues in most environments with more than a single administrator and likely even in cases where it is a single administrator? Because it reduces the potential for better automation? I'm sure there are more reasons, but, these are just a few that come to mind off the top of my head.
take one /64 (for /64's sake ;), split it up into subnets which each have the required number of addresses (lets say you have 2-4 addresses for each bgp/router link, so you simply split it up into subnets that size)
The point of this being? What do you gain by doing this? I've shown you at least a few things you lose.
etc.
no need to use /64 for -everything- at all, just because it fits (ethernet) mac addresses (as if ethernet will be around longer than ipv6 ha-ha, someone will come up with something faster tomorrow and then its bye bye ethernet, the 10ge variant is getting slow, and the 100ge variant is not even standardized yet, and trunking is a bottleneck ;)
The /64 was chosen because it fits EUI-64 addresses. Ethernet MAC addresses are EUI-48. Examples of network technologies that use EUI-64 include Firewire, Zigbee, 6lowpan, etc. So this argument is rather specious and orthogonal to your supposed point.
we don't use /24's for -everything- on ipv4 now do we :P
Right.. We ran out of IPv4 and stopped doing that in order to artificially extend its life.
(oh wait, there once was a time where we did.. due to another retarded semi-automatic configuration thingy, called RIP , which also only seemed to understand /24 or bigger ;)
The issuance of /24s was _NOT_ driven by RIP. Rather, the architecture of RIP was driven by glassful addressing assumptions. There were many other reasons for classful addressing and it still retains some of those advantages. Owen
Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited.
Guess you shouldn't have published it to a public list then.
On Mon, 8 Aug 2011, Owen DeLong wrote:
On Aug 7, 2011, at 4:26 PM, Jeff Wheeler wrote:
On Sun, Aug 7, 2011 at 6:58 PM, Mark Andrews <marka@isc.org> wrote:
So you want HE to force all their clients to renumber.
No. I am simply pointing out that Owen exaggerated when he stated that he implements the following three practices together on his own networks: * hierarchical addressing * nibble-aligned addressing * /48 per access customer
You can simply read the last few messages in this thread to learn that his recommendations on this list are not even practical for his network today, because as Owen himself says, they are not yet able to obtain additional RIR allocations. HE certainly operates a useful, high-profile tunnel-broker service which is IMO a very great asset to the Internet at-large; but if you spend a few minutes looking at the publicly available statistics on this service, they average only around 10,000 active tunnels across all their tunnel termination boxes combined. They have not implemented the policies recommended by Owen because, as he states, a /32 is not enough.
Do I think the position he advocates will cause the eventual exhaustion of IPv6? Well, let's do an exercise:
There has been some rather simplistic arithmetic posted today, 300m new subnets per year, etc. with zero consideration of address/subnet utilization efficiency within ISP networks and individual aggregation router pools. That is foolish. We can all pull out a calculator and figure that 2000::/3 has space for 35 trillion /48 networks. That isn't how they will be assigned or routed.
The effect of 2011-3 is that an out-sized ISP like AT&T has every justification for deciding to allocate 24 bits worth of subnet ID for their "largest POP," say, one that happens to terminate layer-3 services for all customers in an entire state. They then have policy support for allocating the same sized subnet for every other POP, no matter how small. After all, the RIR policy permits them to obtain additional allocations as soon as one POP subnet has become full.
So now you have a huge ISP with a few huge POPs, and a lot of small ones, justified in assigning the same size aggregate prefix, suitable for 2^24 subnets, to all those small POPs as well. How many layer-3 POPs might this huge ISP have? Any number. It could be every central office with some kind of layer-3 customer aggregation router. It could even be every road-side hut for FTTH services. Perhaps they will decide to address ten thousand POPs this way.
Now the nibble-aligned language in the policy permits them to round up from 10,000 POPs to 16 bits worth of address space for "POP ID." So AT&T is quite justified in requesting: 48 (customer subnet length) - 24 (largest POP subnet ID size) - 16 (POP ID) == a /8 subnet for themselves.
Right up until you read:
6.5.3 (d): If an LIR has already reached a /12 or more, ARIN will allocate a single additional /12 rather than continue expanding nibble boundaries. As you can see, there is a safety valve in the policy at /12 for just this reason.
Now you can see how this policy, and addressing scheme, is utterly brain-dead. It really does put you (and me, and everyone else) in real danger of exhausting the IPv6 address space. All it takes is a few out-sized ISPs, with one large POP each and a bunch of smaller ones, applying for the maximum amount of address space permitted them under 2011-3.
Even by your calculations, it would take 256 such outsized ISPs without a safety valve. With the safety valve that is built into the policy at /12, it would take 4,096 such ISPs. I do not believe that there are more than about 20 such ISPs world wide at this time and would put the foreseeable likely maximum at less than 100 due to the need for customers to support such outsized ISPs and the limited base that would have to be divided among them.
Owen
AT&T serves some entire states out of a single POP, as far as layer-3 termination is concerned.
Are any of the states with populations larger than Philadelphia among them?
Yes, for example, Indiana. Pretty much every state in the former Ameritech service territory.
Does AT&T seriously serve the entire state of Indiana from a single POP??? Sounds crazy to me. I have a few customers in Indiana that are small ILECs and they each have multiple (2-3) POPs even though they have no more than about 1,000 customers. -Randy
On Sun, 07 Aug 2011 20:47:48 EDT, Randy Carpenter said:
Does AT&T seriously serve the entire state of Indiana from a single POP??? Sounds crazy to me.
It makes sense if they're managing to bill customers by the cable mile from their location to the POP. Imagine a POP in Terre Haute or Indianapolis and 1,500+ customers in the Gary area and another 1K in the South Bend and Fort Wayne areas... Of course, some other provider would get a clue and and offer the same price per mile "your location to our POP" - after putting a POP in Gary, South Bend, and Fort Wayne. :)
On Sun, Aug 07, 2011 at 09:45:31PM -0400, Valdis.Kletnieks@vt.edu wrote:
On Sun, 07 Aug 2011 20:47:48 EDT, Randy Carpenter said:
Does AT&T seriously serve the entire state of Indiana from a single POP??? Sounds crazy to me.
It makes sense if they're managing to bill customers by the cable mile from their location to the POP. Imagine a POP in Terre Haute or Indianapolis and 1,500+ customers in the Gary area and another 1K in the South Bend and Fort Wayne areas... Of course, some other provider would get a clue and and offer the same price per mile "your location to our POP" - after putting a POP in Gary, South Bend, and Fort Wayne. :)
AT&T doesn't serve the entire state of Indiana from a single POP. The question at hand was how many POPs *with layer 3 service* they had. I don't know the answer to that question and don't claim that it is or is not "one", but the TDM or L2 backhaul from the nearest POP to whatever other POP has the Layer 3 service isn't paid for by the customer. It's also not clear if they were talking about AT&T the LEC (offering services like DSL) or AT&T the IXC (offering things like business Internet service, V4VPN services, etc). If the latter, it's not at all surprising; legacy IXCs often have more POPs than POPs w/ Layer 3 services, and they backhaul L3 services over their legacy TDM and/or Layer 2 (ATM or FR) networks to a POP that has a router. This was a way for them to get IP service everywhere without installing routers everywhere; as the service took off, more POPs could be IP enabled to reduce the about of TDM (etc.) backhaul. But large legacy IXCs have a lot of POPs and, in general, still don't have routers (customer facing routers, anyway) in all of them. -- Brett
On Aug 7, 2011, at 12:00 PM, Jeff Wheeler wrote:
On Sat, Aug 6, 2011 at 7:26 PM, Owen DeLong <owen@delong.com> wrote:
Well, you aren't actually doing this on your network today. If you practiced what you are preaching, you would not be carrying aggregate routes to your tunnel broker gateways across your whole backbone.
Yes we would.
No, if you actually had a hierarchical addressing scheme, you would issue tunnel broker customer /64s from the same aggregate prefix that is used for their /48s. You'd then summarize at your ABRs so the entire POP need only inject one route for customer addressing into the backbone. Of course, this is not what you do today, and not because of limited RIR allocation policies -- but because you simply did not design your network with such route aggregation in mind.
You are, once again, conflating two related, but, not identical terms. A hierarchical addressing scheme is NOT a hierarchical routing structure and vice versa. Yes, a hierarchical routing scheme requires a hierarchical addressing scheme, but, a hierarchical addressing scheme does NOT require a hierarchical routing scheme. We have a hierarchical addressing scheme. The fact that you dont' like our idea of having two parallel hierarchies for two different addressing structures is also getting in the way here. For us, using parallel similar hierarchies for the /64 and /48 prefix blocks works quite well and produces certain scaling advantages in our system. As to the details of how our IGP works. I'm not going to debate that with you because it is an internal matter and not really part of this discussion. If you want to talk in the abstract about good ways to structure routing, I'm happy to do that. However, it's a different (though related as described above) subject from hierarchical addressing.
Those are artifacts of a small allocation (/32) from a prior RIR policy. The fact that those things haven't worked out so well for us was one of the motivations behind developing policy 2011-3.
There was nothing stopping you from using one /48 out of the /37s you use to issue customer /48 networks for issuing the default /64 blocks your tunnel broker hands out.
I was talking about the fact we were using /37s. We have actually recognized significant advantages from using different prefix blocks to assign /48s and /64s in the environment and I don't expect us to change that practice even when we do get enough address space to build out the hierarchy the way we want. Those advantages, however, may well be unique to our tunnelbroker structure and may not be applicable to other networks.
We give a minimum /48 per customer with the small exception that customers who only want one subnet get a /64.
You assign a /64 by default. Yes, customers can click a button and get themselves a /48 instantly, but let's tell the truth when talking about your current defaults -- customers are assigned a /64, not a /48.
We assign a /64 by default only to tunnelbroker customers and to customers without routers in our datacenters. I believe all others default to a /48 per site. I told the truth... We give a minimum /48 per customer with the small exception that customers who only want one subnet get a /64. If you didn't want only one subnet, presumably you would click the button to get your instant /48.
We do have a hierarchical addressing plan. I said nothing about routing, but, we certainly could implement hierarchical routing if we arrived at a point where it was advantageous because we have designed for it.
How have you designed for it? You already missed easy opportunities to inject fewer routes into your backbone, simply by using different aggregate prefixes for customer /64s vs /48s.
You are correct... With present hind-sight, we could have designed things in such a way that we could have cut the number of aggregates to be injected into the backbone from 50 to 25. Assuming that our network doubles in size every year for the next 4 years, that would take us to a total of 800 routes that could be 400. OTOH, since we get some other advantages from this relatively small increment in prefixes, I think we'll probably stick with the architecture we have for the advantages it offers in other areas. Reducing prefix count is not the only consideration in running a network.
However, requesting more than a /32 is perfectly reasonable. In the ARIN region, policy 2011-3.
My read of that policy, and please correct me if I misunderstand, is that it recognizes only a two-level hierarchy. This would mean that an ISP could use some bits to represent a geographic region, a POP, or an aggregation router / address pool, but it does not grant them justification to reserve bits for all these purposes.
While that's theoretically true, the combination of 25% minfree , nibble boundaries, and equal sized allocations for all POPs based on your largest one allows for that in practical terms in most circumstances.
I don't think it does allow for that. I think it requires you to have at least one "POP prefix" 75% full before you can get any additional space from the RIR, where 75% full means routed to customers, not reserved for aggregation router pools. This is not a hierarchy, it is simply a scheme to permit ISPs to bank on having at least one level of summarization in their addressing and routing scheme.
No, it requires you to have 75% full over all or have at least one POP that is 90% full. However, in this case, you can use POP to mean your most distal aggregation point rather than something more proximal to your core. The term in the policy is "serving site" and is defined with sufficient flexibility to allow virtually any aggregation point to be considered a "serving site". Since you're allowed for a 5 year projection on your number of serving sites, unless you have rather radical diversity in the sizes of your upstream aggregations (this superpop serves 1000 pops, the other one serves 3), I think you'll find that the math does, in fact, work out OK.
2011-3 does not provide for an additional level to summarize on the aggregation routers themselves. It should, but my read is that the authors have a very different opinion about what "hierarchical" addressing means than I do. It should provide for route aggregation on both the ABR and the aggregation router itself.
Can you present an example of a network where this wouldn't work out within policy? It can be fictitious and/or anonymous, but, show me a setup where you think it doesn't work out well and I bet I can show you how to work it. If not, I'll be the first to write an amendment. As one of the authors, I have to say, I don't think our opinions of what a "hierarchical" addressing plan means are all that different. I think mine is perhaps a bit more flexible than yours, but, I wouldn't say "radically different".
AT&T serves some entire states out of a single POP, as far as layer-3 termination is concerned.
Are any of the states with populations larger than Philadelphia among them?
Yes, for example, Indiana. Pretty much every state in the former Ameritech service territory.
Philadelphia 1,526,006 (2010 census) Indiana 6,4383,802 (2010 census) OK.. just barely 4x, but, I would bet if you look at the definition of the term serving site, Indiana would have smaller units than the layer 3 termination physical address that would apply in Indiana. Owen
I'm not the only person who prefers /48 and hopefully most ISPs will eventually come around and realize that /56s don't really benefit anyone vs. /48s. Hurricane Electric has been handing out /48s upon request to our customers and users of our IPv6 tunnel services. We do not anticipate changing that policy. Owen On Aug 5, 2011, at 3:56 PM, Frank Bulk wrote:
Let's clarify -- /48 is much preferred by Owen, but most ISPs seem to be zeroing in on a /56 for production. Though some ISPs are using /64 for their trials.
Frank
-----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Friday, August 05, 2011 12:21 PM To: Brian Mengel Cc: nanog@nanog.org Subject: Re: IPv6 end user addressing
/56 is definitely preferable to /64, but, /48 really is a better choice.
/56 is very limiting for autonomous hierarchical deployments.
It's not about number of subnets. It's about the ability to provide some flexibility in the breadth and depth of bit fields used for creating hierarchical topologies automatically.
Owen
On Aug 5, 2011, at 9:17 AM, Brian Mengel wrote:
In reviewing IPv6 end user allocation policies, I can find little agreement on what prefix length is appropriate for residential end users. /64 and /56 seem to be the favorite candidates, with /56 being slightly preferred.
I am most curious as to why a /60 prefix is not considered when trying to address this problem. It provides 16 /64 subnetworks, which seems like an adequate amount for an end user.
Does anyone have opinions on the BCP for end user addressing in IPv6?
On Aug 6, 2011 2:11 AM, "Owen DeLong" <owen@delong.com> wrote:
I'm not the only person who prefers /48 and hopefully most ISPs will
come around and realize that /56s don't really benefit anyone vs. /48s.
Hurricane Electric has been handing out /48s upon request to our customers and users of our IPv6 tunnel services. We do not anticipate changing that
eventually policy.
Owen
A lot of good that /48 will do while HE rides out their on going peering war and customers are missing a wide swath of the ipv6 routing table. Cb
On Aug 5, 2011, at 3:56 PM, Frank Bulk wrote:
Let's clarify -- /48 is much preferred by Owen, but most ISPs seem to be zeroing in on a /56 for production. Though some ISPs are using /64 for their trials.
Frank
-----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Friday, August 05, 2011 12:21 PM To: Brian Mengel Cc: nanog@nanog.org Subject: Re: IPv6 end user addressing
/56 is definitely preferable to /64, but, /48 really is a better choice.
/56 is very limiting for autonomous hierarchical deployments.
It's not about number of subnets. It's about the ability to provide some flexibility in the breadth and depth of bit fields used for creating hierarchical topologies automatically.
Owen
On Aug 5, 2011, at 9:17 AM, Brian Mengel wrote:
In reviewing IPv6 end user allocation policies, I can find little agreement on what prefix length is appropriate for residential end users. /64 and /56 seem to be the favorite candidates, with /56 being slightly preferred.
I am most curious as to why a /60 prefix is not considered when trying to address this problem. It provides 16 /64 subnetworks, which seems like an adequate amount for an end user.
Does anyone have opinions on the BCP for end user addressing in IPv6?
On Aug 5, 2011, at 3:56 PM, Frank Bulk wrote:
Let's clarify -- /48 is much preferred by Owen,
It's is also supported by RIR policy, and the RFC series. It would unfair to characterize owen as the only holder of that preference.
but most ISPs seem to be zeroing in on a /56 for production. Though some ISPs are using /64 for their trials.
Frank
-----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Friday, August 05, 2011 12:21 PM To: Brian Mengel Cc: nanog@nanog.org Subject: Re: IPv6 end user addressing
/56 is definitely preferable to /64, but, /48 really is a better choice.
/56 is very limiting for autonomous hierarchical deployments.
It's not about number of subnets. It's about the ability to provide some flexibility in the breadth and depth of bit fields used for creating hierarchical topologies automatically.
Owen
On Aug 5, 2011, at 9:17 AM, Brian Mengel wrote:
In reviewing IPv6 end user allocation policies, I can find little agreement on what prefix length is appropriate for residential end users. /64 and /56 seem to be the favorite candidates, with /56 being slightly preferred.
I am most curious as to why a /60 prefix is not considered when trying to address this problem. It provides 16 /64 subnetworks, which seems like an adequate amount for an end user.
Does anyone have opinions on the BCP for end user addressing in IPv6?
On 08/05/2011 09:17, Brian Mengel wrote:
In reviewing IPv6 end user allocation policies, I can find little agreement on what prefix length is appropriate for residential end users. /64 and /56 seem to be the favorite candidates, with /56 being slightly preferred.
I am most curious as to why a /60 prefix is not considered when trying to address this problem. It provides 16 /64 subnetworks, which seems like an adequate amount for an end user.
Does anyone have opinions on the BCP for end user addressing in IPv6?
You've had a lot of good opinions already, but here's one more vote for /56 being the absolute minimum. That said, the strategy I've suggested in the past is to reserve for each customer the largest block that your RIR will recognize as reasonable (note, that's reasonable, not theoretically justifiable) for end user assignment. Then if down the road it turns out that you need more space and for some unimaginable reason you can't get more from the RIR you can go back and start bifurcating the blocks you've reserved. For example, if you reserve a /48 per customer but actually use the first /56 out of it, you are safe if _you_ need the other /56 for some reason, or if the customer needs to expand into the full /48. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
On Fri, Aug 5, 2011 at 11:18 PM, Doug Barton <dougb@dougbarton.us> wrote:
For example, if you reserve a /48 per customer but actually use the first /56 out of it, you are safe if _you_ need the other /56 for some reason, or if the customer needs to expand into the full /48.
+1. Be generous in planning and then assign what makes operational sense. Be sure to make sure that as you dole out smaller than blocks to customers that requested from your RIR, you preserve your ability to give a client a second block from the same aggregatable range. -- Mukom Akong Tamon _______________ "A man owns nothing, not land or money, only his character, the loyalty & courage in his heart" - Commander Chakotay - StarTrek Voyager [In Search of Excellence & Perfection] - http://perfexcellence.org [Moments of TechXcellence] - http://techexcellence.net [ICT Business Integration] - http://ibiztech.wordpress.com [Leadership Lessons from Movies] - http://thbs.wordpress.com
On Aug 6, 2011, at 3:40 AM, Mukom Akong Tamon wrote:
On Fri, Aug 5, 2011 at 11:18 PM, Doug Barton <dougb@dougbarton.us> wrote:
For example, if you reserve a /48 per customer but actually use the first /56 out of it, you are safe if _you_ need the other /56 for some reason, or if the customer needs to expand into the full /48.
+1. Be generous in planning and then assign what makes operational sense. Be sure to make sure that as you dole out smaller than blocks to customers that requested from your RIR, you preserve your ability to give a client a second block from the same aggregatable range.
The way to address this better is to use allocation by bisection to your customers rather than giving them /56s. If you give a site a /48, it is very unlikely they will ever need an additional prefix for that site. Of course if you're talking about a customer that is using a single connection to you to feed multiple sites, that's a different issue and will require additional planning. For anyone that already understands allocation by bisection, you can skip the rest of this message. What I mean by allocation by bisection is simply issuing prefixes such that each issued prefix has the largest possible contiguous aligned space available for expansion. Let's assume 2001:db8::/32 as our starting point and that we are assigning /48s to 50 end sites from it. (I'm skipping the whole hierarchy to fit inside a /32 and keep the example simple). We'd assign 2001:db8::/48 for our own infrastructure and support machines. The first customer would get 2001:db8:8000::/48. The next customer would get 2001:db8:4000::/48, then 2001:db8:c000::/48. In the next round, we'd assign 2001:db8:2000::/48, 2001:db8:6000::/48, 2001:db8:a000::/48 and 2001:db8:e000::/48 This would be followed by …1000::/48, …3000::/48, …5000::/48, …7000::/48, …9000::/48, …b000::/48, …d000::/48, and …f000::/48. At this point, we've assigned 15 customers, and each of them could be expanded from /48 to /36 without invading any of our existing assignments. Continuing, we would assign the next 16 customers as: 2001:db8:0800::/48, 2001:db8:1800::/48, 2001:db8:2800::/48, 2001:db8:3800::/48, 2001:db8:4800::/48, 2001:db8:5800::/48, 2001:db8:6800::/48, 2001:db8:7800::/48, 2001:db8:8800::/48, 2001:db8:9800::/48, 2001:db8:a800::/48, 2001:db8:b800::/48, 2001:db8:c800::/48, 2001:db8:d800::/48, 2001:dbu:e800::/48, 2001:db8:f800::/48 That brings us to 31 customers all of whom have room to expand their /48 up to a /37 (though I wouldn't recommend doing /37s as they are not nibble-aligned, so, outside of exceptional circumstances, you would be unlikely to expand in place beyond /40 at this point.) The next 32 customers would fill in the 2001:db8:?400::/48 ranges and the 2001:db8:?c00::/48 ranges. This limits those customers now to /38s. Owen
On Fri, Aug 5, 2011 at 12:17 PM, Brian Mengel <bmengel@gmail.com> wrote:
In reviewing IPv6 end user allocation policies, I can find little agreement on what prefix length is appropriate for residential end users. /64 and /56 seem to be the favorite candidates, with /56 being slightly preferred.
Hi Brian, /64 is *strongly* discouraged. I'd go so far as to say that when we look back 3 years from now, anybody who assigned /64's to end user networks will be considered short-sighted bordering on foolish. Assign a /128 if you know the downstream is exactly 1 host (not a LAN, not a PC with virtual machines, exactly one computer) or else assign at least a /60.
I am most curious as to why a /60 prefix is not considered when trying to address this problem. It provides 16 /64 subnetworks, which seems like an adequate amount for an end user.
Every time someone needs more than the standard assignment, you have to make a custom assignment with the manpower cost to make it and maintain it. This will happen often with /64, occasionally with /60 and rarely with /56. On the flip side, /56 allows for 16M end-users in your /32 ISP allocation. After which you can trivially get as many additional /32's as you want. Is there any reason you want to super-optimize to get 268M end-users squashed in that /32? Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Sat, Aug 6, 2011 at 1:28 PM, William Herrin <bill@herrin.us> wrote:
On Fri, Aug 5, 2011 at 12:17 PM, Brian Mengel <bmengel@gmail.com> wrote:
On the flip side, /56 allows for 16M end-users in your /32 ISP allocation. After which you can trivially get as many additional /32's as you want. Is there any reason you want to super-optimize to get 268M end-users squashed in that /32?
Arguably, if you only have one /32, and you ever get 65,536 customers each with a /48, getting as many /32s as you need should be no problem, also. But you might want to give them /56s, so you have more bits to logically divide those customers by region, or some other criteria to enable more efficient aggregation. That's the problem with the RIR's choice of issuing only /32s from which /48s are to be assigned. The customer has 80 bits to work with in organizing their hosts. But the ISP has only 16 bits in a /32 to work with. -- -JH
On Aug 6, 2011, at 11:44 AM, Jimmy Hess wrote:
On Sat, Aug 6, 2011 at 1:28 PM, William Herrin <bill@herrin.us> wrote:
On Fri, Aug 5, 2011 at 12:17 PM, Brian Mengel <bmengel@gmail.com> wrote:
On the flip side, /56 allows for 16M end-users in your /32 ISP allocation. After which you can trivially get as many additional /32's as you want. Is there any reason you want to super-optimize to get 268M end-users squashed in that /32?
Arguably, if you only have one /32, and you ever get 65,536 customers each with a /48, getting as many /32s as you need should be no problem, also.
But you might want to give them /56s, so you have more bits to logically divide those customers by region, or some other criteria to enable more efficient aggregation.
Policy supports you getting those bits left of the /32 instead now. Look at ARIN 2011-3 which was adopted and ratified by the board and is awaiting implementation by staff. If you like this idea, support APNIC prop 98, too, please.
That's the problem with the RIR's choice of issuing only /32s from which /48s are to be assigned. The customer has 80 bits to work with in organizing their hosts.
The /32 is only the default minimum for an ISP. A small ISP can probably work with 16 bits. Larger ISPs were always expected to get more than a /32.
But the ISP has only 16 bits in a /32 to work with.
Only if they're very small or not very intelligent in their RIR application. Owen
On Aug 5, 2011, at 9:17 AM, Brian Mengel wrote:
In reviewing IPv6 end user allocation policies, I can find little agreement on what prefix length is appropriate for residential end users. /64 and /56 seem to be the favorite candidates, with /56 being slightly preferred.
I am most curious as to why a /60 prefix is not considered when trying to address this problem. It provides 16 /64 subnetworks, which seems like an adequate amount for an end user.
Does anyone have opinions on the BCP for end user addressing in IPv6?
When you have a device that delegates, e.g. a cpe taking it's assigned prefix, and delegating a fraction of it to a downstream device, you need enough bits that you can make them out, possibly more than once. if you want that to happen automatically you want enough bits that user-intervention is never (for small values of never) required in to subnet when connecting devices together... the homenet wg is exploring how devices in the home might address the issue of topology discovery in conjunction with delegation, which realistically home networks are going to have to do... https://www.ietf.org/mailman/listinfo/homenet
On Fri, 5 Aug 2011, Brian Mengel wrote:
In reviewing IPv6 end user allocation policies, I can find little agreement on what prefix length is appropriate for residential end users. /64 and /56 seem to be the favorite candidates, with /56 being slightly preferred.
I am most curious as to why a /60 prefix is not considered when trying to address this problem. It provides 16 /64 subnetworks, which seems like an adequate amount for an end user.
Does anyone have opinions on the BCP for end user addressing in IPv6?
For business customers I would give /48 and home users who might have 1-2 subnet I would give /56 or /60. Reasons: - Business customers night grow where you have to provide bigger amount of subnet - allow space for future extension - - Home users - they usually don't know what is subnet. Setting up different subnets in their SOHO router can be difficult. Usually the simple 1 subnet for every device is enough for them. Separating some devices into a separate subnets is usually enough for the most sophisticated home users. If not then he can opt for business service.... Just my 2 cents.... Best Regards, Janos Mohacsi
On Mon, 08 Aug 2011 10:15:17 +0200, Mohacsi Janos said:
- Home users - they usually don't know what is subnet. Setting up different subnets in their SOHO router can be difficult. Usually the simple 1 subnet for every device is enough for them. Separating some devices into a separate subnets is usually enough for the most sophisticated home users. If not then he can opt for business service....
You don't want to make the assumption that just because Joe Sixpack doesn't know what a subnet is, that Joe Sixpack's CPE doesn't know either. And remember that if it's 3 hops from one end of Joe Sixpack's internal net to the other, you're gonna burn a few bits to support heirarchical routing so you don't need a routing protocol. So if Joe's exterior-facing CPU gets handed a /56 by the provider, and it hands each device it sees a /60 in case it's a device that routes too, it can only support 14 devices. And if one of the things that got handed a /60 is a wireless access point or something, it's only going to be able to support 15 or so subnets. So a simple topology of only a half dozen devices can burn up 8 bits of subnet addressing real fast. Yes, you can conserve bits by being more clever, but then you probably need an IGP of some sort....
On Mon, 8 Aug 2011, Valdis.Kletnieks@vt.edu wrote:
On Mon, 08 Aug 2011 10:15:17 +0200, Mohacsi Janos said:
- Home users - they usually don't know what is subnet. Setting up different subnets in their SOHO router can be difficult. Usually the simple 1 subnet for every device is enough for them. Separating some devices into a separate subnets is usually enough for the most sophisticated home users. If not then he can opt for business service....
You don't want to make the assumption that just because Joe Sixpack doesn't know what a subnet is, that Joe Sixpack's CPE doesn't know either.
And remember that if it's 3 hops from one end of Joe Sixpack's internal net to the other, you're gonna burn a few bits to support heirarchical routing so you don't need a routing protocol. So if Joe's exterior-facing CPU gets handed a /56 by the provider, and it hands each device it sees a /60 in case it's a device that routes too, it can only support 14 devices. And if one of the
more exactly 16 routing devices. You don't have to count the all 0 and all 1 as reserved.... maybe each deeice can see /57 or /58 or /59.... depending of capabilities your devices.... I think daisy chaining of CPE routers is bad idea - as probably done in several IPv4 home networks. Why would you build several hierarchy into you network if it is unnecessary? Best Regards, Janos Mohacsi
On Mon, 08 Aug 2011 16:12:00 +0200, Mohacsi Janos said:
You don't have to count the all 0 and all 1 as reserved.... maybe each deeice can see /57 or /58 or /59.... depending of capabilities your devices....
As I said further down the note - you can conserve bits but then it gets more complicated. You don't want to go to a static "subdivide whatever you got 16 ways if you can", you have to get more clever. Sure, that one device may only need a /61 right now because there's only 3 devices behind it. So the upstream bridge allocates the first /61 to that device, and allocates the next /63 to the next device that comes online. Then somebody adds a 4th device to that first router and now it needs a /60, but you can't just expand the allocation to a /60 because somebody is in the way. Somebody's gonna have to renumber. Or you can just say "I can support 16 devices so I need 4 bits of space". Or you can bite the bullet and do something more clever.
I think daisy chaining of CPE routers is bad idea - as probably done in several IPv4 home networks. Why would you build several hierarchy into you network if it is unnecessary?
Because we're talking Joe Sixpack here - and he can't *spell* hierarchy. All he knows is that he's got one box that his cable company sent him, then he plugged his wireless access point into the cable company box, then he plugged all the stuff in the media center into a box and connected that box to the cable company box (He couldn't plug it all into the cable company box because that only had 4 RJ45's, and one got used for the wireless, and he's got 9(*) things in the media center that have RJ45s). You're at 2 levels of heirarchy already. Now if he decides to get lazy and not run a cable to the upstairs bedroom he wants to use as a home office, and gets another box that's really similar to the on in his media center except it will do wirelesss, he just added a third level of heirarchy. And I don't think that's an at all unreasonable scenario. Feel free to redesign that network to get rid of one level, let me know what you ended up doing. Oh, and explain it in terms Joe Sixpack can understand. ;) (*) Yes, 9 isn't at all unreasonable - I know plenty of people that have a Wii, a PS/2, a PS/3, an XBox, a TV that will talk to the Internet, a DVR that wants to talk to the Internet, and a PC. That's 7 already. On Tue, 09 Aug 2011 00:18:57 +1000, Mark Andrews said:
In message <174561.1312807412@turing-police.cc.vt.edu>, Valdis.Kletnieks@vt.edu
half dozen devices can burn up 8 bits of subnet addressing real fast. Yes, you can conserve bits by being more clever, but then you probably need an IGP of some sort....
Which is why CPE devices shouldn't do heirarchical assignment by default. PD supports multiple upstream requests.
As I said - you can conserve bits using PD or similar, but then you need a routing solution - you can use PD to hand out prefixes, but then you still need routing. Consider the case above - the wireless box asks for a prefix delegation, then the media center box asks for one. Then the home office asks for one - and now you need to make sure there's a way for the stuff behind the media center box to know that to get to the printer that''s hanging off the home office box, it has to route to the wireless box. Anybody got gear that can do that and is ready for Joe Sixpack?
On Aug 8, 2011, at 7:12 AM, Mohacsi Janos wrote:
On Mon, 8 Aug 2011, Valdis.Kletnieks@vt.edu wrote:
On Mon, 08 Aug 2011 10:15:17 +0200, Mohacsi Janos said:
- Home users - they usually don't know what is subnet. Setting up different subnets in their SOHO router can be difficult. Usually the simple 1 subnet for every device is enough for them. Separating some devices into a separate subnets is usually enough for the most sophisticated home users. If not then he can opt for business service....
You don't want to make the assumption that just because Joe Sixpack doesn't know what a subnet is, that Joe Sixpack's CPE doesn't know either.
And remember that if it's 3 hops from one end of Joe Sixpack's internal net to the other, you're gonna burn a few bits to support heirarchical routing so you don't need a routing protocol. So if Joe's exterior-facing CPU gets handed a /56 by the provider, and it hands each device it sees a /60 in case it's a device that routes too, it can only support 14 devices. And if one of the
more exactly 16 routing devices. You don't have to count the all 0 and all 1 as reserved.... maybe each deeice can see /57 or /58 or /59.... depending of capabilities your devices....
I think daisy chaining of CPE routers is bad idea - as probably done in several IPv4 home networks. Why would you build several hierarchy into you network if it is unnecessary?
I can see things like wanting to have an entertainment systems network that is fronted by a router with additional networks for each entertainment system fronted by their own router, segmentation of various appliance networks with possibly an appliance front-end router, etc. There are lots of possibilities we haven't thought of here yet. Limiting end-users to /56 or worse will only stifle the innovation that will help us identify the possibilities. For this, if no other reason, (and I cite the limitations under which we have begun to frame our assumptions about how the internet works as a result of NAT as an example), I think we should avoid preserving this cultural conditioning in IPv6. Owen
On Monday 08 Aug 2011 22:00:52 Owen DeLong wrote:
On Aug 8, 2011, at 7:12 AM, Mohacsi Janos wrote:
On Mon, 8 Aug 2011, Valdis.Kletnieks@vt.edu wrote:
On Mon, 08 Aug 2011 10:15:17 +0200, Mohacsi Janos said:
- Home users - they usually don't know what is subnet. Setting up different subnets in their SOHO router can be difficult. Usually
simple 1 subnet for every device is enough for them. Separating some devices into a separate subnets is usually enough for the most sophisticated home users. If not then he can opt for business service....
You don't want to make the assumption that just because Joe Sixpack doesn't know what a subnet is, that Joe Sixpack's CPE doesn't know either.
And remember that if it's 3 hops from one end of Joe Sixpack's internal net to the other, you're gonna burn a few bits to support heirarchical routing so you don't need a routing protocol. So if Joe's exterior-facing CPU gets handed a /56 by the provider, and it hands each device it sees a /60 in case it's a device that routes too, it can only support 14 devices. And if one of the
more exactly 16 routing devices. You don't have to count the all 0 and all 1 as reserved.... maybe each deeice can see /57 or /58 or /59.... depending of capabilities your devices....
I think daisy chaining of CPE routers is bad idea - as probably done in several IPv4 home networks. Why would you build several hierarchy into you network if it is unnecessary?
I can see things like wanting to have an entertainment systems network
the that is fronted
by a router with additional networks for each entertainment system fronted by their own router, segmentation of various appliance networks with possibly an appliance front-end router, etc.
There are lots of possibilities we haven't thought of here yet. Limiting end-users to /56 or worse will only stifle the innovation that will help us identify the possibilities. For this, if no other reason, (and I cite the limitations under which we have begun to frame our assumptions about how the internet works as a result of NAT as an example), I think we should avoid preserving this cultural conditioning in IPv6.
Owen
Thinking about the CPE thread, isn't this a case for bridging as a feature in end-user devices? If Joe's media-centre box etc would bridge its downstream ports to the upstream port, the devices on them could just get an address, whether by DHCPv6 from the CPE router's delegation or by SLAAC, and then register in local DNS or more likely do multicast- DNS so they could find each other. And then it really doesn't matter; everything gets its address, nothing is NATted, every address is mapped to a meaningful hostname. Perhaps you'd need more aggregation and routing in the glorious one-IP- per-nanite-and-Facebook-fridges future, but that's for another day once we've got fusion and a rational system of government out of the way:-) Joe's network as described isn't big enough or clever enough to need multiple routers. It's just a small LAN and it's only Joe's weirdness in using a $500 Roku as a $5 hank of cat5e and a $20 4-port switch that prevents it from being so. Not all problems should be solved by routing - but a list full of "router people" is inherently likely to try to solve all its problems with more routers and routing. -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them
Thinking about the CPE thread, isn't this a case for bridging as a feature in end-user devices? If Joe's media-centre box etc would bridge its downstream ports to the upstream port, the devices on them could just get an address, whether by DHCPv6 from the CPE router's delegation or by SLAAC, and then register in local DNS or more likely do multicast- DNS so they could find each other.
Why do I want my kid's network seeing all the multicast packets that are streaming the adult video from the player to the TV and the Amp in the master bedroom? Why do I want my appliance network's multicast packets getting tossed around on the guest wireless? Bridging eliminates the multicast isolation that you get from routing. This is not a case for bridging, it's a case for making it possible to do real routing in the home and we now have the space and the technology to actually do it in a meaningful and sufficiently automatic way as to be applicable to Joe 6-Mac.
And then it really doesn't matter; everything gets its address, nothing is NATted, every address is mapped to a meaningful hostname.
This assumption that an entire household should be a single broadcast (or multicast) domain is fundamentally broken and needs to change going forward.
Perhaps you'd need more aggregation and routing in the glorious one-IP- per-nanite-and-Facebook-fridges future, but that's for another day once we've got fusion and a rational system of government out of the way:-) Joe's network as described isn't big enough or clever enough to need multiple routers. It's just a small LAN and it's only Joe's weirdness in using a $500 Roku as a $5 hank of cat5e and a $20 4-port switch that prevents it from being so.
I think that the nanites and fridges that talk to other kitchen storage systems will actually happen well before fusion or rational government. Just because what you describe of today's situation is an accurate picture of today does not mean it is how we should plan IPv6. Remember, we don't want to have to replan IPv6 or switch to yet another numbering system for several years, if not decades. In case you hadn't noticed, doing so at today's scale is hard. Imagine what it will be like next time.
Not all problems should be solved by routing - but a list full of "router people" is inherently likely to try to solve all its problems with more routers and routing.
There are reasons to route and reasons to switch. I don't consider myself a router person, but, I do consider myself a network engineer, so, I try to use the right tool for the right job. In the case of LAN isolation which I can see several desirable applications for in a home, I think routing is a better choice than switching. Remember, the multicast scopes in IPv6 are interface, link, and larger. There's no scope in between everything on this interface and everything on this link. (link == layer 3 network). Owen
On 2011-08-10 15:02 , Owen DeLong wrote: [..]
Why do I want my appliance network's multicast packets getting tossed around on the guest wireless?
Even wikipedia knows the answer to that: http://en.wikipedia.org/wiki/IGMP_snooping which is the first hit for IGMP snooping, which is generally a feature that is present in the better (and thus more expensive) switching gear (and thus probably not present in every home, but those homes probably also don't care about that). Granted, routing is the better and more appropriate way to isolate these kind of packets and definitely more appropriate for broadcast nastyness (mDNS is such a nice one there too...). That said, /56 or /48 to the home should be what is happening. The whole point of settling on a single prefix btw is so that networks can at least keep the same numbering plan when they switch from one PA prefix to another. Greets, Jeroen PS: the more power to your kids if they can sniff the network for your 'adult content', decode it, and then actually watch it (though if they are technically inclined actually not too difficult, but heck, is that not where crypto comes into play, as when they can pull that off on your kiddienetwork they can also just plug something into the kiddie-'adult content'-network and sniff it off there... something with 802.1x comes to mind to solve that step.
On Wednesday 10 Aug 2011 14:57:54 Jeroen Massar wrote:
PS: the more power to your kids if they can sniff the network for your 'adult content', decode it, and then actually watch it
Indeed; I'd be more interested in making sure that, say, you can efficiently multicast the live footy to two different screens in the house, and things work automatically so they get used. I think we're operating on radically different Bayesian priors here and I wonder if a European/American issue is involved. (PS, can you buy a switch that will do production grade IPv6, i.e. with things like RA guard, and not do IGMP-snooping?) -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them
On Aug 10, 2011, at 6:57 AM, Jeroen Massar wrote:
On 2011-08-10 15:02 , Owen DeLong wrote: [..]
Why do I want my appliance network's multicast packets getting tossed around on the guest wireless?
Even wikipedia knows the answer to that: http://en.wikipedia.org/wiki/IGMP_snooping which is the first hit for IGMP snooping, which is generally a feature that is present in the better (and thus more expensive) switching gear (and thus probably not present in every home, but those homes probably also don't care about that).
That would be the answer to why I DON'T want that happening, but, why would I WANT it to happen when, as you said, the better and more appropriate solution is to route. Unless you have some benefit to offer from NOT Routing, I stand by my statement.
Granted, routing is the better and more appropriate way to isolate these kind of packets and definitely more appropriate for broadcast nastyness (mDNS is such a nice one there too...).
That said, /56 or /48 to the home should be what is happening.
That said, /48 to the home should be what is happening, and /56 is a better compromise than anything smaller.
The whole point of settling on a single prefix btw is so that networks can at least keep the same numbering plan when they switch from one PA prefix to another.
That would be nice as well, but, unfortunately, it is obvious at this point that some ISPs will unfortunately refuse to give home users /48s.
Greets, Jeroen
PS: the more power to your kids if they can sniff the network for your 'adult content', decode it, and then actually watch it (though if they are technically inclined actually not too difficult, but heck, is that not where crypto comes into play, as when they can pull that off on your kiddienetwork they can also just plug something into the kiddie-'adult content'-network and sniff it off there... something with 802.1x comes to mind to solve that step.
The chances of the average amplifier and television supporting that level of encryption in a way that the hypothetical kids in this situation would be unable to decrypt a stream that does work between the source and the television and amplifier are pretty slim IMHO. Heck, I can't even get any one of those devices to speak IPv6 yet, let alone all of them and with cryptography to boot. Owen
On Wed, Aug 10, 2011 at 2:03 PM, Owen DeLong <owen@delong.com> wrote:
That said, /48 to the home should be what is happening, and /56 is a better compromise than anything smaller.
Is hierarchical routing within the SOHO network the reason you believe /48 is useful? You don't really imagine that end-users will require more than 2^8 subnets, but that they will want several levels of very simple, nibble-aligned routers within their network? This is perhaps a good discussion to have. I, for one, see CPE vendors still shipping products without IPv6 support at all, let alone any mechanism for creating an address or routing hierarchy within the home without the end-user configuring it himself. I am not aware of any automatic means to do this, or even any working group trying to produce that feature. Is it true that there is no existing work on this? If that is the case, why would we not try to steer any such future work in such a way that it can manage to do what the end-user wants without requiring a /48 in their home? -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
On Aug 10, 2011, at 11:17 AM, Jeff Wheeler wrote:
On Wed, Aug 10, 2011 at 2:03 PM, Owen DeLong <owen@delong.com> wrote:
That said, /48 to the home should be what is happening, and /56 is a better compromise than anything smaller.
Is hierarchical routing within the SOHO network the reason you believe /48 is useful? You don't really imagine that end-users will require more than 2^8 subnets, but that they will want several levels of very simple, nibble-aligned routers within their network?
Not necessarily nibble aligned, but, multiple bits per level, yes.
This is perhaps a good discussion to have. I, for one, see CPE vendors still shipping products without IPv6 support at all, let alone any mechanism for creating an address or routing hierarchy within the home without the end-user configuring it himself. I am not aware of any automatic means to do this, or even any working group trying to produce that feature.
If we are stingy in address allocations, it will stifle such innovations as the vendors tend to develop to the lowest common denominator. If we make the allocations available, innovative ideas will make use of them.
Is it true that there is no existing work on this? If that is the case, why would we not try to steer any such future work in such a way that it can manage to do what the end-user wants without requiring a /48 in their home?
No, it is not true. I suppose that limiting enough households to too small an allocation will have that effect. I would rather we steer the internet deployment towards liberal enough allocations to avoid such disability for the future. Have we learned nothing from the way NAT shaped the (lack of) innovation in the home? Owen
On Wed, Aug 10, 2011 at 7:12 PM, Owen DeLong <owen@delong.com> wrote:
Is it true that there is no existing work on this? If that is the case, why would we not try to steer any such future work in such a way that it can manage to do what the end-user wants without requiring a /48 in their home?
No, it is not true.
Can you give any example of a product, or on-going work? I have read two posts from you today saying that something either exists already, or is being worked on. I haven't read this anywhere else.
I suppose that limiting enough households to too small an allocation will have that effect. I would rather we steer the internet deployment towards liberal enough allocations to avoid such disability for the future.
Have we learned nothing from the way NAT shaped the (lack of) innovation in the home?
I am afraid we may not have learned from exhausting IPv4. If I may use the Hurricane Electric tunnel broker as an example again, supposing that is an independent service with no relation to your hosting, transit, etc. operations, it can justify a /24 allocation immediately under 2011-3, without even relying on growth projections. That's a middle ground figure that we can all live with, but it is based on you serving (at this moment) only 8000 tunnels at your busiest tunnel gateway. If your tunnel gateways could serve 12,288 + 1 users each, then your /24 justification grows to a /20. So you would have a pretty significant chunk of the available IPv6 address space for a fairly small number of end-users -- about 72,543 at present. It isn't hard to do some arithmetic and guess that if every household in the world had IPv6 connectivity from a relatively low-density service like the above example, we would still only burn through about 3% of the IPv6 address space on end-users (nothing said about server farms, etc. here) but what does bother me is that the typical end-user today has one, single IP address; and now we will be issuing them 2^16 subnets; yet it is not too hard to imagine a future where the global IPv6 address pool becomes constrained due to service-provider inefficiency. I would like to have innovations in SOHO devices, too; who knows what these may be. But I fear we may repeat the mistake that caused NAT to be a necessity in IPv4 -- exhausting address space -- by foolishly assuming that every household is going to need twenty-four orders of magnitude more public addresses than it has today. That is what these practices do -- they literally give end-users twenty-four orders of magnitude more addresses, while it is easy to imagine that we will come within one order of magnitude of running completely out of IPv6 addresses for issuing to service providers. I didn't know what the digit "1" followed by twenty-four zeroes was called. I had to look it up. So our end-users will be receiving about one-Septillion addresses to use in their home, but no one seems to be asking what future technology we may be harming by possibly constraining the global address pool. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
In message <CAPWAtbJ0kgzAbCjUGvBCE3_njawMDu3AZqLi3JQV4ZP6ivX5KA@mail.gmail.com> , Jeff Wheeler writes:
On Wed, Aug 10, 2011 at 7:12 PM, Owen DeLong <owen@delong.com> wrote:
Is it true that there is no existing work on this? =A0If that is the case, why would we not try to steer any such future work in such a way that it can manage to do what the end-user wants without requiring a /48 in their home?
No, it is not true.
Can you give any example of a product, or on-going work? I have read two posts from you today saying that something either exists already, or is being worked on. I haven't read this anywhere else.
I suppose that limiting enough households to too small an allocation will have that effect. I would rather we steer the internet deployment towards liberal enough allocations to avoid such disability for the future.
Have we learned nothing from the way NAT shaped the (lack of) innovation in the home?
I am afraid we may not have learned from exhausting IPv4. If I may use the Hurricane Electric tunnel broker as an example again, supposing that is an independent service with no relation to your hosting, transit, etc. operations, it can justify a /24 allocation immediately under 2011-3, without even relying on growth projections. That's a middle ground figure that we can all live with, but it is based on you serving (at this moment) only 8000 tunnels at your busiest tunnel gateway. If your tunnel gateways could serve 12,288 + 1 users each, then your /24 justification grows to a /20. So you would have a pretty significant chunk of the available IPv6 address space for a fairly small number of end-users -- about 72,543 at present.
It isn't hard to do some arithmetic and guess that if every household in the world had IPv6 connectivity from a relatively low-density service like the above example, we would still only burn through about 3% of the IPv6 address space on end-users (nothing said about server farms, etc. here) but what does bother me is that the typical end-user today has one, single IP address; and now we will be issuing them 2^16 subnets; yet it is not too hard to imagine a future where the global IPv6 address pool becomes constrained due to service-provider inefficiency.
No. A typical user has 10 to 20 addresses NAT'd to one public address. My household has * game consoles * laptops * desktops * cell phones * voip phones * printers all connected to the net. It doesn't yet have a media server but otherwise it is pretty typical. Someday, I expect the pantry to have a barcode reader on it connected back a computer setup for the kitchen someday. Most of us already use barcode readers when we shop so its not a big step to home use. Just about anything with fireware in it will eventually connect to the net. The typical household already has 1 or 2 subnets.
I would like to have innovations in SOHO devices, too; who knows what these may be. But I fear we may repeat the mistake that caused NAT to be a necessity in IPv4 -- exhausting address space -- by foolishly assuming that every household is going to need twenty-four orders of magnitude more public addresses than it has today.
That is what these practices do -- they literally give end-users twenty-four orders of magnitude more addresses, while it is easy to imagine that we will come within one order of magnitude of running completely out of IPv6 addresses for issuing to service providers.
Housholds can get as much internal addressing as they need today and as many nets as they need today with RFC1918. 10/8 broken up into to /24 is equivalent to a /48 broken up into /64s. A /56 is equivalent to 192.168/16 broken up into its class C's.
I didn't know what the digit "1" followed by twenty-four zeroes was called. I had to look it up. So our end-users will be receiving about one-Septillion addresses to use in their home, but no one seems to be asking what future technology we may be harming by possibly constraining the global address pool.
There was a concious decision made a decade and a half ago to got to 128 bits instead of 64 bits and give each subnet 64 bits so we would never have to worry about the size of a subnet again. IPv6 is about managing networks not managing addresses.
--=20 Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator=A0 /=A0 Innovative Network Concepts
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Someday, I expect the pantry to have a barcode reader on it connected back a computer setup for the kitchen someday. Most of us already use barcode readers when we shop so its not a big step to home use.
Nah... That's short-term thinking. The future holds advanced pantries with RFID sensors that know what is in the pantry and when they were manufactured, what their expiration date is, etc. The refrigerator will have not only the necessary RFID sensors, but, multiple pressure transducers capable of recognizing not only that there is a carton of milk in the refrigerator, but, how much milk is remaining. You'll be able to scan a QR code in the grocery store that links to a recipe for something you thought would be good for dinner, pass the ingredient list to the web server in the refrigerator and get back a nearly instant reply containing the relevant inventory list and a list of items you need to buy to complete the recipe.
Just about anything with fireware in it will eventually connect to the net.
I think you meant firmware, and, I'd say that a lot of things (cans, jars, milk cartons, etc.) that don't currently connect to the net will actually form IP adjacencies in the future.
The typical household already has 1 or 2 subnets.
Or even more in some cases (LAN, WLAN, WLAN Guest, DMZ for example).
I would like to have innovations in SOHO devices, too; who knows what these may be. But I fear we may repeat the mistake that caused NAT to be a necessity in IPv4 -- exhausting address space -- by foolishly assuming that every household is going to need twenty-four orders of magnitude more public addresses than it has today.
That is what these practices do -- they literally give end-users twenty-four orders of magnitude more addresses, while it is easy to imagine that we will come within one order of magnitude of running completely out of IPv6 addresses for issuing to service providers.
Housholds can get as much internal addressing as they need today and as many nets as they need today with RFC1918. 10/8 broken up into to /24 is equivalent to a /48 broken up into /64s.
A /56 is equivalent to 192.168/16 broken up into its class C's.
Good point.
I didn't know what the digit "1" followed by twenty-four zeroes was called. I had to look it up. So our end-users will be receiving about one-Septillion addresses to use in their home, but no one seems to be asking what future technology we may be harming by possibly constraining the global address pool.
There was a concious decision made a decade and a half ago to got to 128 bits instead of 64 bits and give each subnet 64 bits so we would never have to worry about the size of a subnet again. IPv6 is about managing networks not managing addresses.
Yep. Owen
On Wed, Aug 10, 2011 at 9:32 PM, Owen DeLong <owen@delong.com> wrote:
Someday, I expect the pantry to have a barcode reader on it connected back a computer setup for the kitchen someday. Most of us already use barcode readers when we shop so its not a big step to home use.
Nah... That's short-term thinking. The future holds advanced pantries with RFID sensors that know what is in the pantry and when they were manufactured, what their expiration date is, etc.
And since your can of creamed corn is globally addressable, the rest of the world knows what's in your pantry too. ;) Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Aug 10, 2011, at 6:46 PM, William Herrin wrote:
On Wed, Aug 10, 2011 at 9:32 PM, Owen DeLong <owen@delong.com> wrote:
Someday, I expect the pantry to have a barcode reader on it connected back a computer setup for the kitchen someday. Most of us already use barcode readers when we shop so its not a big step to home use.
Nah... That's short-term thinking. The future holds advanced pantries with RFID sensors that know what is in the pantry and when they were manufactured, what their expiration date is, etc.
And since your can of creamed corn is globally addressable, the rest of the world knows what's in your pantry too. ;)
This definitely helps explain your misconceptions about NAT as a security tool. Globally addressable != globally reachable. Things can have global addresses without having global reachability. There are these tools called access control lists and routing policies. Perhaps you've heard of them. They can be quite useful. Owen
Owen wrote:
-----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Wednesday, August 10, 2011 9:58 PM To: William Herrin Cc: nanog@nanog.org Subject: Re: IPv6 end user addressing
On Aug 10, 2011, at 6:46 PM, William Herrin wrote:
Someday, I expect the pantry to have a barcode reader on it connected back a computer setup for the kitchen someday. Most of us already use barcode readers when we shop so its not a big step to home use.
Nah... That's short-term thinking. The future holds advanced
On Wed, Aug 10, 2011 at 9:32 PM, Owen DeLong <owen@delong.com> wrote: pantries with
RFID sensors that know what is in the pantry and when they were manufactured, what their expiration date is, etc.
And since your can of creamed corn is globally addressable, the rest of the world knows what's in your pantry too. ;)
This definitely helps explain your misconceptions about NAT as a security tool.
Globally addressable != globally reachable.
Things can have global addresses without having global reachability. There are these tools called access control lists and routing policies. Perhaps you've heard of them. They can be quite useful.
And your average home user, whose WiFi network is an open network named "linksys" is going to do that how? Jamie
On Aug 11, 2011, at 5:41 AM, Jamie Bowden wrote:
Owen wrote:
-----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Wednesday, August 10, 2011 9:58 PM To: William Herrin Cc: nanog@nanog.org Subject: Re: IPv6 end user addressing
On Aug 10, 2011, at 6:46 PM, William Herrin wrote:
Someday, I expect the pantry to have a barcode reader on it connected back a computer setup for the kitchen someday. Most of us already use barcode readers when we shop so its not a big step to home use.
Nah... That's short-term thinking. The future holds advanced
On Wed, Aug 10, 2011 at 9:32 PM, Owen DeLong <owen@delong.com> wrote: pantries with
RFID sensors that know what is in the pantry and when they were manufactured, what their expiration date is, etc.
And since your can of creamed corn is globally addressable, the rest of the world knows what's in your pantry too. ;)
This definitely helps explain your misconceptions about NAT as a security tool.
Globally addressable != globally reachable.
Things can have global addresses without having global reachability. There are these tools called access control lists and routing policies. Perhaps you've heard of them. They can be quite useful.
And your average home user, whose WiFi network is an open network named "linksys" is going to do that how?
Because the routers that come on pantries and refrigerators will probably be made by people smarter than the folks at Linksys? Owen
And your average home user, whose WiFi network is an open network named "linksys" is going to do that how?
Because the routers that come on pantries and refrigerators will probably be made by people smarter than the folks at Linksys?
One could argue that routing and access control is even less of a core business feature for pantry and refrigerator manufacturers than it is for Linksys. So I wouldn't rule this out - but I'm definitely in the sceptical camp. Steinar Haug, Nethelp consulting, sthaug@nethelp.no
On Aug 11, 2011, at 10:41 AM, sthaug@nethelp.no wrote:
And your average home user, whose WiFi network is an open network named "linksys" is going to do that how?
Because the routers that come on pantries and refrigerators will probably be made by people smarter than the folks at Linksys?
One could argue that routing and access control is even less of a core business feature for pantry and refrigerator manufacturers than it is for Linksys. So I wouldn't rule this out - but I'm definitely in the sceptical camp.
Steinar Haug, Nethelp consulting, sthaug@nethelp.no
Let's face it... CPE security needs are going to be radically different and consumer expectations are going to rise quickly in this area with IPv6. I suspect both refrigerator/pantry makers _AND_ Linksys et. al. will be forced to adapt. Owen
On 08/11/2011 11:18 AM, Owen DeLong wrote:
On Aug 11, 2011, at 10:41 AM, sthaug@nethelp.no wrote:
And your average home user, whose WiFi network is an open network named "linksys" is going to do that how?
Because the routers that come on pantries and refrigerators will probably be made by people smarter than the folks at Linksys?
One could argue that routing and access control is even less of a core business feature for pantry and refrigerator manufacturers than it is for Linksys. So I wouldn't rule this out - but I'm definitely in the sceptical camp.
Steinar Haug, Nethelp consulting, sthaug@nethelp.no
Let's face it... CPE security needs are going to be radically different and consumer expectations are going to rise quickly in this area with IPv6.
I suspect both refrigerator/pantry makers _AND_ Linksys et. al. will be forced to adapt.
Radically? How so? I have little confidence that the urge to do as little as possible about security is going to change just because of IPv6. The goal of router manufacturers is to turn a profit, not save the world. Mike
On Aug 11, 2011, at 1:04 PM, Owen DeLong wrote:
On Aug 11, 2011, at 5:41 AM, Jamie Bowden wrote:
Owen wrote:
-----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Wednesday, August 10, 2011 9:58 PM To: William Herrin Cc: nanog@nanog.org Subject: Re: IPv6 end user addressing
On Aug 10, 2011, at 6:46 PM, William Herrin wrote:
Someday, I expect the pantry to have a barcode reader on it connected back a computer setup for the kitchen someday. Most of us already use barcode readers when we shop so its not a big step to home use.
Nah... That's short-term thinking. The future holds advanced
On Wed, Aug 10, 2011 at 9:32 PM, Owen DeLong <owen@delong.com> wrote: pantries with
RFID sensors that know what is in the pantry and when they were manufactured, what their expiration date is, etc.
And since your can of creamed corn is globally addressable, the rest of the world knows what's in your pantry too. ;)
This definitely helps explain your misconceptions about NAT as a security tool.
Globally addressable != globally reachable.
Things can have global addresses without having global reachability. There are these tools called access control lists and routing policies. Perhaps you've heard of them. They can be quite useful.
And your average home user, whose WiFi network is an open network named "linksys" is going to do that how?
Because the routers that come on pantries and refrigerators will probably be made by people smarter than the folks at Linksys?
Owen
I respectfully disagree. If appliance manufacturers jump on the bandwagon to make their device *Internet Ready!* we'll see appliance makers who have way less networking experience than Linksys/Cisco getting into the fray. I highly doubt the pontifications of these Good Morning America technology gurus who predict all these changes are coming to the home. Do we really think appliance manufacturers are going to agree on standards for keeping track of how much milk is in the fridge, especially as not just manufacturing but also engineering is moving to countries like China? How about the predictions that have been around for years about appliances which will alert the manufacturer about impending failure so they can call you and you can schedule the repair before there's a breakdown? Remember that one? We don't even have an "appliance about to break, call repairman" idiot light on appliances yet. But I predict the coming of IPv6 to the home in a big way will have unintended consequences. I think the big shock for home users regarding IPv6 will be suddenly having their IPv4 NAT firewall being gone and all their devices being exposed naked to everyone on the internet. Suddenly all their security shortcomings (no passwords, "password" for the password etc) are going to have catastrophic consequences. I foresee an exponential leap in the number of hacks of consumer devices which will have repercussions well beyond their local network. In my opinion that's going to be the biggest problem with IPv6, not all the concerns about the inner workings of the protocols. I'm guessing the manufacturers of consumer grade networkable devices are still thinking about security as it applies to LANs with rfc 1918 address space behind a firewall and haven't rethought security as it applies to IPv6. Greg
On Thu, Aug 11, 2011 at 10:52 AM, Greg Ihnen <os10rules@gmail.com> wrote:
On Aug 11, 2011, at 1:04 PM, Owen DeLong wrote:
On Aug 11, 2011, at 5:41 AM, Jamie Bowden wrote:
Owen wrote:
-----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Wednesday, August 10, 2011 9:58 PM To: William Herrin Cc: nanog@nanog.org Subject: Re: IPv6 end user addressing
On Aug 10, 2011, at 6:46 PM, William Herrin wrote:
> Someday, I expect the pantry to have a barcode reader on it connected back > a computer setup for the kitchen someday. Most of us already use barcode > readers when we shop so its not a big step to home use.
Nah... That's short-term thinking. The future holds advanced
On Wed, Aug 10, 2011 at 9:32 PM, Owen DeLong <owen@delong.com> wrote: pantries with
RFID sensors that know what is in the pantry and when they were manufactured, what their expiration date is, etc.
And since your can of creamed corn is globally addressable, the rest of the world knows what's in your pantry too. ;)
This definitely helps explain your misconceptions about NAT as a security tool.
Globally addressable != globally reachable.
Things can have global addresses without having global reachability. There are these tools called access control lists and routing policies. Perhaps you've heard of them. They can be quite useful.
And your average home user, whose WiFi network is an open network named "linksys" is going to do that how?
Because the routers that come on pantries and refrigerators will probably
be
made by people smarter than the folks at Linksys?
Owen
I respectfully disagree. If appliance manufacturers jump on the bandwagon to make their device *Internet Ready!* we'll see appliance makers who have way less networking experience than Linksys/Cisco getting into the fray. I highly doubt the pontifications of these Good Morning America technology gurus who predict all these changes are coming to the home. Do we really think appliance manufacturers are going to agree on standards for keeping track of how much milk is in the fridge, especially as not just manufacturing but also engineering is moving to countries like China? How about the predictions that have been around for years about appliances which will alert the manufacturer about impending failure so they can call you and you can schedule the repair before there's a breakdown? Remember that one? We don't even have an "appliance about to break, call repairman" idiot light on appliances yet.
But I predict the coming of IPv6 to the home in a big way will have unintended consequences.
I think the big shock for home users regarding IPv6 will be suddenly having their IPv4 NAT firewall being gone and all their devices being exposed naked to everyone on the internet. Suddenly all their security shortcomings (no passwords, "password" for the password etc) are going to have catastrophic consequences. I foresee an exponential leap in the number of hacks of consumer devices which will have repercussions well beyond their local network. In my opinion that's going to be the biggest problem with IPv6, not all the concerns about the inner workings of the protocols. I'm guessing the manufacturers of consumer grade networkable devices are still thinking about security as it applies to LANs with rfc 1918 address space behind a firewall and haven't rethought security as it applies to IPv6.
Greg
+1 I think this is currently the biggest hole in IPV6 adoption. We need a drop in firewall appliance along the lines of IPCOP for IPV6. This type of closed unless tinkered with protection would encourage people to try it out and not be too scared to move forward. This is a huge opportunity for some Company/Open Source Developers Group to grab a huge chucnk of an emerging market... hint hint :) cheers Jeff
I respectfully disagree. If appliance manufacturers jump on the bandwagon to make their device *Internet Ready!* we'll see appliance makers who have way less networking experience than Linksys/Cisco getting into the fray. I highly doubt the pontifications of these Good Morning America technology gurus who predict all these changes are coming to the home. Do we really think appliance manufacturers are going to agree on standards for keeping track of how much milk is in the fridge, especially as not just manufacturing but also engineering is moving to countries like China? How about the predictions that have been around for years about appliances which will alert the manufacturer about impending failure so they can call you and you can schedule the repair before there's a breakdown? Remember that one? We don't even have an "appliance about to break, call repairman" idiot light on appliances yet.
What standards? The RFID tag on the milk carton will, essentially, replace the bar code once RFID tags become cheap enough. It'll be like an uber-barcode with a bunch more information. For keeping track of how much, cheap sensitive pressure transducers will know by the position of the RFID tag combined with the weight of the thing at that location in the refrigerator. There's no new standard required. The technology to do this exists today. The integration and mainstream acceptance is still years, if not decades off, but, IPv6 should last for decades, so, if we don't plan for at least the things we can see coming today and already know feasible ways to implement, we're doomed for the other unexpected things we don't see coming.
But I predict the coming of IPv6 to the home in a big way will have unintended consequences.
Definitely.
I think the big shock for home users regarding IPv6 will be suddenly having their IPv4 NAT firewall being gone and all their devices being exposed naked to everyone on the internet. Suddenly all their security shortcomings (no passwords, "password" for the password etc) are going to have catastrophic consequences. I foresee an exponential leap in the number of hacks of consumer devices which will have repercussions well beyond their local network. In my opinion that's going to be the biggest problem with IPv6, not all the concerns about the inner workings of the protocols. I'm guessing the manufacturers of consumer grade networkable devices are still thinking about security as it applies to LANs with rfc 1918 address space behind a firewall and haven't rethought security as it applies to IPv6.
Sigh... Continuing to propagate this myth doesn't make it any more true than it was 10 years ago. NAT != Security End-to-End addressing != End-to-End connectivity It will not be long before the average residential IPv6 gateway comes with a default deny all inbound stateful firewall built in. Once you have that, your hosts are not exposed naked to everyone on the internet. In fact, they are no more exposed than with NAT with the key difference being that if you choose to expose one or more hosts, you have the option of deliberately doing so. Actually, I know for certain that most of the CPE manufacturers are participating in the effort to draft better security requirements for residential gateways as a current ID and hopefully an RFC soon. I believe, as a matter of fact, that this is a BIS document being intended as a more comprehensive improvement over the initial version. Owen
On Aug 11, 2011, at 5:05 PM, Owen DeLong wrote:
I respectfully disagree. If appliance manufacturers jump on the bandwagon to make their device *Internet Ready!* we'll see appliance makers who have way less networking experience than Linksys/Cisco getting into the fray. I highly doubt the pontifications of these Good Morning America technology gurus who predict all these changes are coming to the home. Do we really think appliance manufacturers are going to agree on standards for keeping track of how much milk is in the fridge, especially as not just manufacturing but also engineering is moving to countries like China? How about the predictions that have been around for years about appliances which will alert the manufacturer about impending failure so they can call you and you can schedule the repair before there's a breakdown? Remember that one? We don't even have an "appliance about to break, call repairman" idiot light on appliances yet.
What standards? The RFID tag on the milk carton will, essentially, replace the bar code once RFID tags become cheap enough. It'll be like an uber-barcode with a bunch more information.
For keeping track of how much, cheap sensitive pressure transducers will know by the position of the RFID tag combined with the weight of the thing at that location in the refrigerator. There's no new standard required.
The technology to do this exists today. The integration and mainstream acceptance is still years, if not decades off, but, IPv6 should last for decades, so, if we don't plan for at least the things we can see coming today and already know feasible ways to implement, we're doomed for the other unexpected things we don't see coming.
What reads the RFID's and the pressure sensors? What server or application receives this data and deals with it according to the user's desires? How does that data or the information and alerts this system would generate get to the user's devices? There has to be a device in the home or a server somewhere for a service the home owner subscribes to which keeps an inventory of all these things and acts on it. Do you really think it's going to be common place for people to have this kind of technology and more importantly use it? I think the kitchen you foresee is the kind of dream kitchen the kind of people who imbed RFID chips in themselves so they can have a house that opens the doors and turns on the lights as they approach. You don't have a chip in you, do you?
But I predict the coming of IPv6 to the home in a big way will have unintended consequences.
Definitely.
I think the big shock for home users regarding IPv6 will be suddenly having their IPv4 NAT firewall being gone and all their devices being exposed naked to everyone on the internet. Suddenly all their security shortcomings (no passwords, "password" for the password etc) are going to have catastrophic consequences. I foresee an exponential leap in the number of hacks of consumer devices which will have repercussions well beyond their local network. In my opinion that's going to be the biggest problem with IPv6, not all the concerns about the inner workings of the protocols. I'm guessing the manufacturers of consumer grade networkable devices are still thinking about security as it applies to LANs with rfc 1918 address space behind a firewall and haven't rethought security as it applies to IPv6.
Sigh...
Continuing to propagate this myth doesn't make it any more true than it was 10 years ago.
I'm sorry, what was the myth there? The public overall uses bad passwords and knowingly does not comply with security best practices? More connectivity is going to bring more problems and exploits? Those myths?
NAT != Security End-to-End addressing != End-to-End connectivity It will not be long before the average residential IPv6 gateway comes with a default deny all inbound stateful firewall built in. Once you have that, your hosts are not exposed naked to everyone on the internet. In fact, they are no more exposed than with NAT with the key difference being that if you choose to expose one or more hosts, you have the option of deliberately doing so.
We'll see.
Actually, I know for certain that most of the CPE manufacturers are participating in the effort to draft better security requirements for residential gateways as a current ID and hopefully an RFC soon. I believe, as a matter of fact, that this is a BIS document being intended as a more comprehensive improvement over the initial version.
Owen
On Thu, Aug 11, 2011 at 05:49:03PM -0430, Greg Ihnen wrote:
What standards? The RFID tag on the milk carton will, essentially, replace the bar code once RFID tags become cheap enough. It'll be like an uber-barcode with a bunch more information.
For keeping track of how much, cheap sensitive pressure transducers will know by the position of the RFID tag combined with the weight of the thing at that location in the refrigerator. There's no new standard required.
The technology to do this exists today. The integration and mainstream acceptance is still years, if not decades off, but, IPv6 should last for decades, so, if we don't plan for at least the things we can see coming today and already know feasible ways to implement, we're doomed for the other unexpected things we don't see coming.
What reads the RFID's and the pressure sensors? What server or application receives this data and deals with it according to the user's desires? How does that data or the information and alerts this system would generate get to the user's devices? There has to be a device in the home or a server somewhere for a service the home owner subscribes to which keeps an inventory of all these things and acts on it.
Do you really think it's going to be common place for people to have this kind of technology and more importantly use it?
And why do you think the fridge manufacturers will get it right in cheaply-made consumer-grade products, when it's not being done right in muh pricier automated self-check-out checkstands? I avoid self-check-out checkstands because they fail in one way or another so damnably often. My last encounter had the software failing to realize that a package of 100 nuts and 100 screws weighed a significan amount; the result was that for each such package I tried to check out, I had to have someone from the store come over, log in, do something, and log out again. Five times total. *Not* satisfactory. I don't expect that the fridge makers will do any better. -- Mike Andrews, W5EGO mikea@mikea.ath.cx Tired old sysadmin
And why do you think the fridge manufacturers will get it right in cheaply-made consumer-grade products, when it's not being done right in muh pricier automated self-check-out checkstands? I avoid self-check-out checkstands because they fail in one way or another so damnably often. My last encounter had the software failing to realize that a package of 100 nuts and 100 screws weighed a significan amount; the result was that for each such package I tried to check out, I had to have someone from the store come over, log in, do something, and log out again. Five times total.
*Not* satisfactory.
I don't expect that the fridge makers will do any better.
That doesn't sound like a software problem. All the automated self-serve stands I've seen use weight as a primary factor, but this requires that the data on the acceptable weight-range be properly encoded in its database. When that happens, a 5 pound box of hardware with the UPC 0-12345-67890-1 will scan fine as long as it's within the listed acceptable weight range for the product, like maybe 4.9-5.1 pounds. Hey but you don't mind going over to the register manned by a clerk and letting him/her scan your purchases, now, do you? Because THAT was a total train wreck when it first came out. The early systems never really panned out, and many stores who invested early on in the technology found themselves reinvesting in newer technology within a decade. Those that didn't tended to suffer as they coped with limits inherent in the systems. Customers were distrusting of the technology; some stores handed out markers so that customers could write the prices of the items on the items so that they could verify their receipts later. Problems were so common that many states implemented laws about scanner accuracy. But today, thirty years later, this stuff mostly Just All Works Right. Actually it worked pretty well even fifteen years ago. Consumer technologies may change faster. For example, it wasn't that long ago that we were keeping a written grocery list on the fridge. Today, it's all electronic. The kids can scan(!!!) an item that we need, and it magically forwards to my phone and my wife's phone, and we can even shop cooperatively in a store with realtime updates of the list. The technology isn't 100% perfect, but it's way awesomely better than a paper list. It'd be nice to be able to query the fridge to see what's in it. So I don't expect that the fridge makers will do better ... this year, or next. But in five or ten years? Yeah, maybe, probably even. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
You are assuming (as many, many people do) that public addresses equal no firewall, and that IPv6 CPEs will have no stateful firewalling. The thing is, just as they have a stateful firewall now for IPv4 they will have one for IPv6 as well. The fact that your addressing is public (or let's say, routeable) does not make a difference. Again, it is not the NAT layer of your IPv4 CPE that protects you, it's the stateful firewall. regards Carlos On Thu, Aug 11, 2011 at 2:52 PM, Greg Ihnen <os10rules@gmail.com> wrote:
On Aug 11, 2011, at 1:04 PM, Owen DeLong wrote:
On Aug 11, 2011, at 5:41 AM, Jamie Bowden wrote:
Owen wrote:
-----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Wednesday, August 10, 2011 9:58 PM To: William Herrin Cc: nanog@nanog.org Subject: Re: IPv6 end user addressing
On Aug 10, 2011, at 6:46 PM, William Herrin wrote:
> Someday, I expect the pantry to have a barcode reader on it connected back > a computer setup for the kitchen someday. Most of us already use barcode > readers when we shop so its not a big step to home use.
Nah... That's short-term thinking. The future holds advanced
On Wed, Aug 10, 2011 at 9:32 PM, Owen DeLong <owen@delong.com> wrote: pantries with
RFID sensors that know what is in the pantry and when they were manufactured, what their expiration date is, etc.
And since your can of creamed corn is globally addressable, the rest of the world knows what's in your pantry too. ;)
This definitely helps explain your misconceptions about NAT as a security tool.
Globally addressable != globally reachable.
Things can have global addresses without having global reachability. There are these tools called access control lists and routing policies. Perhaps you've heard of them. They can be quite useful.
And your average home user, whose WiFi network is an open network named "linksys" is going to do that how?
Because the routers that come on pantries and refrigerators will probably be made by people smarter than the folks at Linksys?
Owen
I respectfully disagree. If appliance manufacturers jump on the bandwagon to make their device *Internet Ready!* we'll see appliance makers who have way less networking experience than Linksys/Cisco getting into the fray. I highly doubt the pontifications of these Good Morning America technology gurus who predict all these changes are coming to the home. Do we really think appliance manufacturers are going to agree on standards for keeping track of how much milk is in the fridge, especially as not just manufacturing but also engineering is moving to countries like China? How about the predictions that have been around for years about appliances which will alert the manufacturer about impending failure so they can call you and you can schedule the repair before there's a breakdown? Remember that one? We don't even have an "appliance about to break, call repairman" idiot light on appliances yet.
But I predict the coming of IPv6 to the home in a big way will have unintended consequences.
I think the big shock for home users regarding IPv6 will be suddenly having their IPv4 NAT firewall being gone and all their devices being exposed naked to everyone on the internet. Suddenly all their security shortcomings (no passwords, "password" for the password etc) are going to have catastrophic consequences. I foresee an exponential leap in the number of hacks of consumer devices which will have repercussions well beyond their local network. In my opinion that's going to be the biggest problem with IPv6, not all the concerns about the inner workings of the protocols. I'm guessing the manufacturers of consumer grade networkable devices are still thinking about security as it applies to LANs with rfc 1918 address space behind a firewall and haven't rethought security as it applies to IPv6.
Greg
-- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =========================
Hi, The CPE we're providing to our customers from Billion (78xxN/NL, 74xxNX etc) and AVM (Fritz!Box 7290 and 7390) that have IPv6 code do have IPv6 stateful firewalls. Our requirement was that, as much as possible that the IPv4 and IPv6 outcome should be similar (with obvious exceptions around NAT). Without IPv6 having a firewall in the CPE it'd be a difficult thing to convince people to do. And here I'm speaking about "normal" customers. The people who've taken up our IPv6 service so far are not typical customers but people who are, well, fairly switched on to this stuff. So we had to look beyond the initial desires of our customers to what the general population would want. (ie. someone who's regularly attending IETF meetings typically has a different outlook on what they want in a CPE vs what my Dad wants). MMC On 14/08/2011, at 5:49 AM, Carlos Martinez-Cagnazzo wrote: You are assuming (as many, many people do) that public addresses equal no firewall, and that IPv6 CPEs will have no stateful firewalling. The thing is, just as they have a stateful firewall now for IPv4 they will have one for IPv6 as well. The fact that your addressing is public (or let's say, routeable) does not make a difference. Again, it is not the NAT layer of your IPv4 CPE that protects you, it's the stateful firewall. regards Carlos On Thu, Aug 11, 2011 at 2:52 PM, Greg Ihnen <os10rules@gmail.com<mailto:os10rules@gmail.com>> wrote: On Aug 11, 2011, at 1:04 PM, Owen DeLong wrote: On Aug 11, 2011, at 5:41 AM, Jamie Bowden wrote: Owen wrote: -----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Wednesday, August 10, 2011 9:58 PM To: William Herrin Cc: nanog@nanog.org<mailto:nanog@nanog.org> Subject: Re: IPv6 end user addressing On Aug 10, 2011, at 6:46 PM, William Herrin wrote: On Wed, Aug 10, 2011 at 9:32 PM, Owen DeLong <owen@delong.com<mailto:owen@delong.com>> wrote: Someday, I expect the pantry to have a barcode reader on it connected back a computer setup for the kitchen someday. Most of us already use barcode readers when we shop so its not a big step to home use. Nah... That's short-term thinking. The future holds advanced pantries with RFID sensors that know what is in the pantry and when they were manufactured, what their expiration date is, etc. And since your can of creamed corn is globally addressable, the rest of the world knows what's in your pantry too. ;) This definitely helps explain your misconceptions about NAT as a security tool. Globally addressable != globally reachable. Things can have global addresses without having global reachability. There are these tools called access control lists and routing policies. Perhaps you've heard of them. They can be quite useful. And your average home user, whose WiFi network is an open network named "linksys" is going to do that how? Because the routers that come on pantries and refrigerators will probably be made by people smarter than the folks at Linksys? Owen I respectfully disagree. If appliance manufacturers jump on the bandwagon to make their device *Internet Ready!* we'll see appliance makers who have way less networking experience than Linksys/Cisco getting into the fray. I highly doubt the pontifications of these Good Morning America technology gurus who predict all these changes are coming to the home. Do we really think appliance manufacturers are going to agree on standards for keeping track of how much milk is in the fridge, especially as not just manufacturing but also engineering is moving to countries like China? How about the predictions that have been around for years about appliances which will alert the manufacturer about impending failure so they can call you and you can schedule the repair before there's a breakdown? Remember that one? We don't even have an "appliance about to break, call repairman" idiot light on appliances yet. But I predict the coming of IPv6 to the home in a big way will have unintended consequences. I think the big shock for home users regarding IPv6 will be suddenly having their IPv4 NAT firewall being gone and all their devices being exposed naked to everyone on the internet. Suddenly all their security shortcomings (no passwords, "password" for the password etc) are going to have catastrophic consequences. I foresee an exponential leap in the number of hacks of consumer devices which will have repercussions well beyond their local network. In my opinion that's going to be the biggest problem with IPv6, not all the concerns about the inner workings of the protocols. I'm guessing the manufacturers of consumer grade networkable devices are still thinking about security as it applies to LANs with rfc 1918 address space behind a firewall and haven't rethought security as it applies to IPv6. Greg -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= -- Matthew Moyle-Croft Peering Manager and Team Lead - Commercial and DSLAMs Internode /Agile Level 5, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc@internode.com.au<mailto:mmc@internode.com.au> Web: http://www.on.net<http://www.on.net/> Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Once upon a time, Owen DeLong <owen@delong.com> said:
Because the routers that come on pantries and refrigerators will probably be made by people smarter than the folks at Linksys?
That's highly doubtful, especially when Linksys is the "best" networking equipment the average person will buy (at Best Buy, Wal-Mart, etc.). -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On 8/11/2011 1:34 PM, Owen DeLong wrote:
On Aug 11, 2011, at 5:41 AM, Jamie Bowden wrote:
Owen wrote:
-----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Wednesday, August 10, 2011 9:58 PM To: William Herrin Cc: nanog@nanog.org Subject: Re: IPv6 end user addressing
On Aug 10, 2011, at 6:46 PM, William Herrin wrote:
Someday, I expect the pantry to have a barcode reader on it connected back a computer setup for the kitchen someday. Most of us already use barcode readers when we shop so its not a big step to home use.
Nah... That's short-term thinking. The future holds advanced
On Wed, Aug 10, 2011 at 9:32 PM, Owen DeLong<owen@delong.com> wrote: pantries with
RFID sensors that know what is in the pantry and when they were manufactured, what their expiration date is, etc.
And since your can of creamed corn is globally addressable, the rest of the world knows what's in your pantry too. ;)
This definitely helps explain your misconceptions about NAT as a security tool.
Globally addressable != globally reachable.
Things can have global addresses without having global reachability. There are these tools called access control lists and routing policies. Perhaps you've heard of them. They can be quite useful.
And your average home user, whose WiFi network is an open network named "linksys" is going to do that how?
Because the routers that come on pantries and refrigerators will probably be made by people smarter than the folks at Linksys?
But they'll still be operated by end users that are so smart, that when they get e-mail from "service@usps.gov" that says that FedEx couldn't deliver a package (that they're not expecting) to them they click on the password protected "UPS tracking.zip" file and manage to run the .exe file that is supposed to allow them to get the package delivered. -- Dave
On 8/10/2011 8:46 PM, William Herrin wrote:
On Wed, Aug 10, 2011 at 9:32 PM, Owen DeLong<owen@delong.com> wrote:
Someday, I expect the pantry to have a barcode reader on it connected back a computer setup for the kitchen someday. Most of us already use barcode readers when we shop so its not a big step to home use.
Nah... That's short-term thinking. The future holds advanced pantries with RFID sensors that know what is in the pantry and when they were manufactured, what their expiration date is, etc.
And since your can of creamed corn is globally addressable, the rest of the world knows what's in your pantry too. ;)
I can't believe no one has made a joke yet about a kernel. Sorry for the bad joke, -Michael
Regards, Bill Herrin
On Wed, Aug 10, 2011 at 8:40 PM, Mark Andrews <marka@isc.org> wrote:
No. A typical user has 10 to 20 addresses NAT'd to one public address.
I'd say this is fair. Amazingly enough, it all basically works right with one IP address today. It will certainly be nice to have the option to give all these devices public IP addresses, or even have a few public subnets; but it does require more imagination than any of us have demonstrated to figure out how any end-user will need more than 2^8 subnets. That's still assuming that device-makers won't decide they need to be able to operate with subnets of arbitrary size, rather than fixed-size /64 subnets.
There was a concious decision made a decade and a half ago to got to 128 bits instead of 64 bits and give each subnet 64 bits so we would never have to worry about the size of a subnet again. IPv6 is about managing networks not managing addresses.
Thanks for the explanation of how to subnet IPv4 networks and use RFC1918. I hope most readers are already familiar with these concepts. You should note that IPv6 was not, in fact, originally envisioned with /64 subnets; that figure was to be /80 or /96. In the mid-1990s, it was believed that dramatically increasing the number of bits available for ISP routing flexibility was very beneficial, as well as making access subnets so big that they should never need to grow. Then SLAAC came along. Except SLAAC doesn't do necessary things that DHCPv6 does, and the cost of implementing things like DHCPv6 in very small, inexpensive devices has gone down dramatically. I am amazed that so few imagine we might, in within the lifetime of IPv6, like to have more bits of address space for routing structure within ISP networks; but these people do think that end-users need 1.2e+24 addresses for the devices they'll have in their home. I don't have to use my imagination to think of ways that additional bits on the network address side would have been advantageous -- all I need is my memory. In the 90s, it was suggested that a growing number of dual-homed networks cluttering the DFZ could be handled more efficiently by setting aside certain address space for customers who dual-homed to pairs of the largest ISPs. The customer routes would then not need to be carried by anyone except those two ISPs, who are earning money from the customer. This never happened for a variety of good reasons, but most of the technical reasons would have gone away with the adoption of IPv6, as it was envisioned in the mid-90s. There seems to be a lot of imagination being used for SOHO networks, and none on the ISP side. What a shame that is. Owen, I do agree with the point you made off-list, that if huge mistakes are made now and the IPv6 address space is consumed more rapidly than the community is comfortable with, there should be plenty of opportunity to fix that down the road. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
I don't have to use my imagination to think of ways that additional bits on the network address side would have been advantageous -- all I need is my memory. In the 90s, it was suggested that a growing number of dual-homed networks cluttering the DFZ could be handled more efficiently by setting aside certain address space for customers who dual-homed to pairs of the largest ISPs. The customer routes would then not need to be carried by anyone except those two ISPs, who are earning money from the customer. This never happened for a variety of good reasons, but most of the technical reasons would have gone away with the adoption of IPv6, as it was envisioned in the mid-90s.
I think that can still be very realistically achieved within the existing available address space.
There seems to be a lot of imagination being used for SOHO networks, and none on the ISP side. What a shame that is.
I disagree.
Owen, I do agree with the point you made off-list, that if huge mistakes are made now and the IPv6 address space is consumed more rapidly than the community is comfortable with, there should be plenty of opportunity to fix that down the road.
Precisely, so, let's risk a small chance of a mistake here now so that we don't cut off innovation so early. Owen
It isn't hard to do some arithmetic and guess that if every household in the world had IPv6 connectivity from a relatively low-density service like the above example, we would still only burn through about 3% of the IPv6 address space on end-users (nothing said about server farms, etc. here) but what does bother me is that the typical end-user today has one, single IP address; and now we will be issuing them 2^16 subnets; yet it is not too hard to imagine a future where the global IPv6 address pool becomes constrained due to service-provider inefficiency.
what is the life expectancy of IPv6? It won't live forever and we can't reasonably expect it too. I understand we don't want run out of addresses in the next 10-40 years but what about 100? 200? 300? We will run out and our decedents will go through re-numbering again. The question becomes what is the life expectancy of IPv6 and does the allocation plan make a reasonable attempt to run out of addresses around the end of the expected life of IPv6.
Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
james
In message <CADVasu5qev5gUX_oQ=LyJ2JZom=Vf5S56kgeQ4BYEq20gd7+1w@mail.gmail.com> , james machado writes:
It isn't hard to do some arithmetic and guess that if every household in the world had IPv6 connectivity from a relatively low-density service like the above example, we would still only burn through about 3% of the IPv6 address space on end-users (nothing said about server farms, etc. here) but what does bother me is that the typical end-user today has one, single IP address; and now we will be issuing them 2^16 subnets; yet it is not too hard to imagine a future where the global IPv6 address pool becomes constrained due to service-provider inefficiency.
what is the life expectancy of IPv6? It won't live forever and we can't reasonably expect it too. I understand we don't want run out of addresses in the next 10-40 years but what about 100? 200? 300?
We will run out and our decedents will go through re-numbering again. The question becomes what is the life expectancy of IPv6 and does the allocation plan make a reasonable attempt to run out of addresses around the end of the expected life of IPv6.
It really depends on whether the RIR's recover and, importantly, reallocate address space that is not being paid for or not. If they do this should last for the forseeable future. It would also be my recommendation that RIR's start doing this immediately, if they are not already doing so, so that there is no expectation that you can use address space forever without paying for it.
Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator=A0 /=A0 Innovative Network Concepts
james
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 2011-08-11 12:45, james machado wrote:
what is the life expectancy of IPv6? It won't live forever and we can't reasonably expect it too. I understand we don't want run out of addresses in the next 10-40 years but what about 100? 200? 300?
We will run out and our decedents will go through re-numbering again. The question becomes what is the life expectancy of IPv6 and does the allocation plan make a reasonable attempt to run out of addresses around the end of the expected life of IPv6.
Well, we know that the human population will stabilise somewhere below ten billion by around 2050. The current unicast space provides for about 15 trillion /48s. Let's assume that the RIRs and ISPs retain their current level of engineering common sense - i.e. the address space will begin to be really full when there are about 25% of those /48s being routed... that makes 3.75 trillion /48s routed for ten billion people, or 375 /48s per man, woman and child. (Or about 25 million /64s if you prefer.) At that point, IANA would have to release unicast space other than 2000::/3 and we could start again with a new allocation policy. I am *really* not worried about this. Other stuff, such as BGP4, will break irrevocably long before this. Brian
On Aug 10, 2011, at 6:52 PM, Brian E Carpenter wrote:
On 2011-08-11 12:45, james machado wrote:
what is the life expectancy of IPv6? It won't live forever and we can't reasonably expect it too. I understand we don't want run out of addresses in the next 10-40 years but what about 100? 200? 300?
We will run out and our decedents will go through re-numbering again. The question becomes what is the life expectancy of IPv6 and does the allocation plan make a reasonable attempt to run out of addresses around the end of the expected life of IPv6.
Well, we know that the human population will stabilise somewhere below ten billion by around 2050. The current unicast space provides for about 15 trillion /48s. Let's assume that the RIRs and ISPs retain their current level of engineering common sense - i.e. the address space will begin to be really full when there are about 25% of those /48s being routed... that makes 3.75 trillion /48s routed for ten billion people, or 375 /48s per man, woman and child. (Or about 25 million /64s if you prefer.)
It's not the humans that are going to soak up the address space, so it seems a little misguided to count up the humans a reference for the bounding properties on growth. That said I think 2000::/3 will last long enough, that we shouldn't be out rewriting policy anytime soon.
At that point, IANA would have to release unicast space other than 2000::/3 and we could start again with a new allocation policy.
I am *really* not worried about this. Other stuff, such as BGP4, will break irrevocably long before this.
We have a few problems to solve along the way. Running the current network is hard enough as it is.
Brian
On Aug 10, 2011, at 8:29 PM, Joel Jaeggli wrote:
On Aug 10, 2011, at 6:52 PM, Brian E Carpenter wrote:
On 2011-08-11 12:45, james machado wrote:
what is the life expectancy of IPv6? It won't live forever and we can't reasonably expect it too. I understand we don't want run out of addresses in the next 10-40 years but what about 100? 200? 300?
We will run out and our decedents will go through re-numbering again. The question becomes what is the life expectancy of IPv6 and does the allocation plan make a reasonable attempt to run out of addresses around the end of the expected life of IPv6.
Well, we know that the human population will stabilise somewhere below ten billion by around 2050. The current unicast space provides for about 15 trillion /48s. Let's assume that the RIRs and ISPs retain their current level of engineering common sense - i.e. the address space will begin to be really full when there are about 25% of those /48s being routed... that makes 3.75 trillion /48s routed for ten billion people, or 375 /48s per man, woman and child. (Or about 25 million /64s if you prefer.)
It's not the humans that are going to soak up the address space, so it seems a little misguided to count up the humans a reference for the bounding properties on growth. That said I think 2000::/3 will last long enough, that we shouldn't be out rewriting policy anytime soon.
I disagree. I think current policy in several RIRs (APNIC, especially) is far too conservative and that we do need to rewrite it. That's why I submitted prop-090 which has taken the feedback I received into account and become prop-098. Owen
On Thu, Aug 11, 2011 at 01:52:10PM +1200, Brian E Carpenter wrote:
Well, we know that the human population will stabilise somewhere below ten billion by around 2050. The current unicast space provides for about
How about the machine population? How about self-replicating systems? How about geography-based address allocation, to go away with global routing tables? How about InterPlaNet, such as LEO routers, solar power satellites, controlling industrial production on the Moon and elsewhere? I don't expect IPv6 will last much longer than IPv4. And that's probably a good thing.
15 trillion /48s. Let's assume that the RIRs and ISPs retain their current level of engineering common sense - i.e. the address space will begin to be really full when there are about 25% of those /48s being routed... that makes 3.75 trillion /48s routed for ten billion people, or 375 /48s per man, woman and child. (Or about 25 million /64s if you prefer.)
At that point, IANA would have to release unicast space other than 2000::/3 and we could start again with a new allocation policy.
I am *really* not worried about this. Other stuff, such as BGP4, will break irrevocably long before this.
-- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
Eugen, On 2011-08-11 21:53, Eugen Leitl wrote:
On Thu, Aug 11, 2011 at 01:52:10PM +1200, Brian E Carpenter wrote:
Well, we know that the human population will stabilise somewhere below ten billion by around 2050. The current unicast space provides for about
How about the machine population? How about self-replicating systems?
I think considering the size of such systems as a function of the size of the human population is quite reasonable, in terms of thinking about natural and economic limits to growth.
How about geography-based address allocation, to go away with global routing tables?
That is a whole discussion in itself, but in any case it surely won't be part of 2000::/3. Additionally, the number of prefixes needed for any reasonable geographic scheme is quite trivial compared to the trillions available.
How about InterPlaNet, such as LEO routers, solar power satellites, controlling industrial production on the Moon and elsewhere?
Probably also trivial numbers compared to 15 trillion /48s, but if not, again, we are not limited to 2000::/3 for ever. EOF for me on this sub-topic. Brian
On 11/08/2011, at 8:42 AM, Owen DeLong wrote:
I suppose that limiting enough households to too small an allocation will have that effect. I would rather we steer the internet deployment towards liberal enough allocations to avoid such disability for the future.
I see the lack of agreement on whether /48 or /56 or /60 is good for a home network to be a positive thing. As long as there's no firm consensus, router vendors will have to implement features which don't make silly hard-coded assumptions. Innovation will still happen, features will still be implemented, we'll still climb out of the NAT morass. But we'll do it with CPE that allows for a richer spectrum of variation than we would if we just said, "Dammit, /48 for everyone." It's all good. At this stage of the game, any amount of "moving forward" is better than staying where we are. (which reminds me: http://www.internode.on.net/news/2011/08/238.php It ain't that hard) - mark -- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223
On Aug 10, 2011 7:45 PM, "Mark Newton" <newton@internode.com.au> wrote:
On 11/08/2011, at 8:42 AM, Owen DeLong wrote:
I suppose that limiting enough households to too small an allocation will have that effect. I would rather we steer the internet deployment towards liberal enough allocations to avoid such disability for the future.
I see the lack of agreement on whether /48 or /56 or /60 is good for a home network to be a positive thing.
As long as there's no firm consensus, router vendors will have to
implement
features which don't make silly hard-coded assumptions.
Innovation will still happen, features will still be implemented, we'll still climb out of the NAT morass. But we'll do it with CPE that allows for a richer spectrum of variation than we would if we just said, "Dammit, /48 for everyone."
It's all good. At this stage of the game, any amount of "moving forward" is better than staying where we are.
(which reminds me: http://www.internode.on.net/news/2011/08/238.php It ain't that hard)
Finally a useful post in this thread. Good work on the deployment of real ipv6! Cb
- mark
-- Mark Newton Email: newton@internode.com.au(W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223
On 11/08/2011, at 12:30 PM, Cameron Byrne wrote:
Finally a useful post in this thread. Good work on the deployment of real ipv6!
Thanks. And thanks to Vendor-C for helping us through it. The IPv6 Broadband featureset on the ASR platform starting from IOS-XR 3.1 is a vast improvement on its predecessors. Biggest hassle with IPv6 in production right now: DNS support is woefully undercooked. I don't think anyone has put anywhere near as much effort into making it fluid, user-friendly, and automated. Simple questions like, "How are reverse mappings supposed to work when you can't predict an end-user's address?" have no good answer. If any systems folks want a nice meaty problem domain to focus their efforts on, DNS would be da shiznit. - mark -- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223
On 11/08/2011, at 12:41 PM, Mark Newton wrote:
On 11/08/2011, at 12:30 PM, Cameron Byrne wrote:
Finally a useful post in this thread. Good work on the deployment of real ipv6!
Thanks. And thanks to Vendor-C for helping us through it. The IPv6 Broadband featureset on the ASR platform starting from IOS-XR 3.1 is a vast improvement on its predecessors.
Oops. s/XR/XE/ - mark -- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223
On Aug 10, 2011, at 7:45 PM, Mark Newton wrote:
On 11/08/2011, at 8:42 AM, Owen DeLong wrote:
I suppose that limiting enough households to too small an allocation will have that effect. I would rather we steer the internet deployment towards liberal enough allocations to avoid such disability for the future.
I see the lack of agreement on whether /48 or /56 or /60 is good for a home network to be a positive thing.
As long as there's no firm consensus, router vendors will have to implement features which don't make silly hard-coded assumptions.
Yes and no. In terms of potential innovations, if enough of the market chooses /60, they will hard code the assumption that they cannot count on more than a /60 being available into their development process regardless of what gets into the router. Sure, they won't be able to assume you can't get a /48, but, they also won't necessarily implement features that would take advantage of a /48.
Innovation will still happen, features will still be implemented, we'll still climb out of the NAT morass. But we'll do it with CPE that allows for a richer spectrum of variation than we would if we just said, "Dammit, /48 for everyone."
We'll climb out of the NAT morass, yes. That's not innovation, that's recovery. Innovation of products that are capable of building significant automatic partitioning and hierarchy will not happen if ISPs choose not to supply enough addresses to facilitate use by a critical mass of customers. No router vendor is going to spend development resources building features that their customers will want but be unable to use because their ISP says no.
It's all good. At this stage of the game, any amount of "moving forward" is better than staying where we are.
True, but, there are degrees of better. Moving forward on a slightly wrong path is better than moving forward on a radically wrong path. Both are better than standing still or moving backward. If you try to get to a point that is 010º from your current position and 60 miles in front of you, it's better to travel 015º than 350º. Both are way better than 060º and 060º is way better than 090º which is still better than 180º. However, 015º will be slightly off until you basically pass your destination. However, 350º will have you fairly far off by the time you pass your destination. Obviously, 060º will never bring you very close to the destination, even if you will start out getting slightly closer to it. Even 090º will bring you closer to your destination for a little while before you start getting farther away again. It ends up looking like this: The thin lines are construction lines to show the computation of the closest point (the point where a line perpendicular to the course chosen intersects the destination waypoint). The black dots represent the actual closest points. Obviously, the closest point is closer the less off-course you are. However, more interestingly, the more off course you are, the sooner you reach a point where you are no longer heading towards, but, away from your destination. Obviously for lines 90º to 270º off of the desired course, you begin heading away immediately. (note that the 90º line above is only 80º off course). Perhaps far more than most of you wanted to know about navigation, but, at least worth considering when we think that all forward movement is good forward movement. Owen
On 11/08/2011, at 1:33 PM, Owen DeLong wrote:
Yes and no. In terms of potential innovations, if enough of the market chooses /60, they will hard code the assumption that they cannot count on more than a /60 being available into their development process regardless of what gets into the router. Sure, they won't be able to assume you can't get a /48, but, they also won't necessarily implement features that would take advantage of a /48.
They will on their "premium" high price point CPE and/or service provider offerings. It'll be a product differentiator. If enough customers are attracted to it, it'll win. If they aren't, it'll lose. The process of invention and innovation will happen anyway. We're not really talking about that here, we're talking about post-innovation marketing. Maybe ISP#2 in Australia will launch onto the market with /48's for everyone, and we'll respond competitively. Dunno. Whatever, it's all kinda arbitrary really. Not worth arguing about, and certainly not worth delaying implementation until you finish debating the "right" answer.
Perhaps far more than most of you wanted to know about navigation, but, at least worth considering when we think that all forward movement is good forward movement.
The 1-in-60 rule I learned during my pilots license training is a lot easier to explain, without diagrams and with no need for trigonometry. Another useful judgement call when you're flying is to understand that as long as you know where you are and where you want to be, any forward progress whatsoever is a positive when there's a growing thunderstorm behind you :-) - mark -- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223
On 11/08/2011, at 1:33 PM, Owen DeLong wrote:
On Aug 10, 2011, at 7:45 PM, Mark Newton wrote:
On 11/08/2011, at 8:42 AM, Owen DeLong wrote:
I suppose that limiting enough households to too small an allocation will have that effect. I would rather we steer the internet deployment towards liberal enough allocations to avoid such disability for the future.
I see the lack of agreement on whether /48 or /56 or /60 is good for a home network to be a positive thing.
As long as there's no firm consensus, router vendors will have to implement features which don't make silly hard-coded assumptions.
Yes and no. In terms of potential innovations, if enough of the market chooses /60, they will hard code the assumption that they cannot count on more than a /60 being available into their development process regardless of what gets into the router. Sure, they won't be able to assume you can't get a /48, but, they also won't necessarily implement features that would take advantage of a /48.
Abundance doesn't drive innovations. Scarcity does. IPv6 does not have a scarcity issue. I assert that IPv6 addressing is not going to now or ever do anything particularly innovative that can't be done better at other, more relevant, layers. The time for arguing about arbitrary things that make no difference to the end customers has passed. The navel gazing must cease and we must move forward on IPv6 to the home rather than continuing the confusion about this and other IPv6 arbitrary bit obsession stuff. We need to stop spending our time on rearranging the Titanic's deckchairs and get the <profanity> on with stopping the crashing into the iceberg by providing clear leadership on getting IPv6 to the masses to enable their APPLICATIONS and EXPERIENCE without the impending doom of IPv4 CGN. My name is Matthew, I HAVE given my customers the ability to get IPv6 and I don't give a flying one about the prefix length, I care about getting ANY prefix to the end users so they can use it and solve the issues at their end. I AM enabling innovation just by doing that. MMC
On Aug 11, 2011, at 5:08 PM, Matthew Moyle-Croft wrote:
On 11/08/2011, at 1:33 PM, Owen DeLong wrote:
On Aug 10, 2011, at 7:45 PM, Mark Newton wrote:
On 11/08/2011, at 8:42 AM, Owen DeLong wrote:
I suppose that limiting enough households to too small an allocation will have that effect. I would rather we steer the internet deployment towards liberal enough allocations to avoid such disability for the future.
I see the lack of agreement on whether /48 or /56 or /60 is good for a home network to be a positive thing.
As long as there's no firm consensus, router vendors will have to implement features which don't make silly hard-coded assumptions.
Yes and no. In terms of potential innovations, if enough of the market chooses /60, they will hard code the assumption that they cannot count on more than a /60 being available into their development process regardless of what gets into the router. Sure, they won't be able to assume you can't get a /48, but, they also won't necessarily implement features that would take advantage of a /48.
Abundance doesn't drive innovations. Scarcity does. IPv6 does not have a scarcity issue. I assert that IPv6 addressing is not going to now or ever do anything particularly innovative that can't be done better at other, more relevant, layers.
Abundance won't drive innovation, but, scarcity can block it. If enough providers limit their residential customers to /60s, then, that will become the defining limit to which vendors implement.
The time for arguing about arbitrary things that make no difference to the end customers has passed. The navel gazing must cease and we must move forward on IPv6 to the home rather than continuing the confusion about this and other IPv6 arbitrary bit obsession stuff.
On that I believe we are in complete agreement. Let's deploy IPv6 to end users and give them /48s and move on.
We need to stop spending our time on rearranging the Titanic's deckchairs and get the <profanity> on with stopping the crashing into the iceberg by providing clear leadership on getting IPv6 to the masses to enable their APPLICATIONS and EXPERIENCE without the impending doom of IPv4 CGN.
Again, no argument.
My name is Matthew, I HAVE given my customers the ability to get IPv6 and I don't give a flying one about the prefix length, I care about getting ANY prefix to the end users so they can use it and solve the issues at their end. I AM enabling innovation just by doing that.
My name is Owen. I work for an ISP that gives IPv6 to our customers and anyone else who cares to connect. We care about prefix length because we believe it will impact innovation for many years. Yes, getting something to end users is more important than how big of a prefix we give them. On that, MMC and I are in complete agreement. However, there are choices to be made in how we do it and giving out /48s costs virtually nothing and yields real potential benefits. There is no meaningful advantage to placing arbitrary limits below /48 on residential customers. Owen
On Aug 11, 2011 5:25 PM, "Owen DeLong" <owen@delong.com> wrote:
On Aug 11, 2011, at 5:08 PM, Matthew Moyle-Croft wrote:
On 11/08/2011, at 1:33 PM, Owen DeLong wrote:
On Aug 10, 2011, at 7:45 PM, Mark Newton wrote:
On 11/08/2011, at 8:42 AM, Owen DeLong wrote:
I suppose that limiting enough households to too small an allocation will have that effect. I would rather we steer the internet
towards liberal enough allocations to avoid such disability for the future.
I see the lack of agreement on whether /48 or /56 or /60 is good for a home network to be a positive thing.
As long as there's no firm consensus, router vendors will have to implement features which don't make silly hard-coded assumptions.
Yes and no. In terms of potential innovations, if enough of the market chooses /60, they will hard code the assumption that they cannot count on more
a /60 being available into their development process regardless of what gets into the router. Sure, they won't be able to assume you can't get a /48, but, they also won't necessarily implement features that would take advantage of a /48.
Abundance doesn't drive innovations. Scarcity does. IPv6 does not have a scarcity issue. I assert that IPv6 addressing is not going to now or ever do anything particularly innovative that can't be done better at other, more relevant, layers.
Abundance won't drive innovation, but, scarcity can block it.
If enough providers limit their residential customers to /60s, then, that will become the defining limit to which vendors implement.
The time for arguing about arbitrary things that make no difference to
On that I believe we are in complete agreement. Let's deploy IPv6 to end users and give them /48s and move on.
We need to stop spending our time on rearranging the Titanic's deckchairs and get the <profanity> on with stopping the crashing into the iceberg by providing clear leadership on getting IPv6 to the masses to enable their APPLICATIONS and EXPERIENCE without the impending doom of IPv4 CGN.
Again, no argument.
My name is Matthew, I HAVE given my customers the ability to get IPv6 and I don't give a flying one about the prefix length, I care about getting ANY prefix to the end users so they can use it and solve the issues at their end. I AM enabling innovation just by doing that.
My name is Owen. I work for an ISP that gives IPv6 to our customers and anyone else who cares to connect.
We care about prefix length because we believe it will impact innovation for many years.
Yes, getting something to end users is more important than how big of a
deployment than the end customers has passed. The navel gazing must cease and we must move forward on IPv6 to the home rather than continuing the confusion about this and other IPv6 arbitrary bit obsession stuff. prefix we give them. On that, MMC and I are in complete agreement.
However, there are choices to be made in how we do it and giving out /48s
costs virtually nothing and yields real potential benefits. There
is no meaningful advantage to placing arbitrary limits below /48 on residential customers.
I agree that this debate is confusing people and will not be solved here. Let's move on to a more productive topic. There is more than one way to deploy ipv6. Do what's right for your own users and network. Cb
Owen
On Wed, Aug 10, 2011 at 2:17 PM, Jeff Wheeler <jsw@inconcepts.biz> wrote:
On Wed, Aug 10, 2011 at 2:03 PM, Owen DeLong <owen@delong.com> wrote:
That said, /48 to the home should be what is happening, and /56 is a better compromise than anything smaller.
You don't really imagine that end-users will require more than 2^8 subnets, but that they will want several levels of very simple, nibble-aligned routers within their network?
Hi Jeff, In Owen's world, the refrigerator, toaster and microwave each request a /64 from the GE Home Appliance Controller, those /64's being necessary to address each appliance's internal button, light and sensor networks. To accommodate all of these appliances, the HAC has acquired a /59 for all the home appliances from the Home Automation System (HAS) which also has its own LAN and supplied a big block to the furnace and a smaller block to the security system. So, the HAS needed a /58 which it got from the Linksys Home Router. The Sony Home Entertainment Network (HEN) Controller also needed a /58 from the Home Router to accommodate the Playstation 5's need for a /62 (one /64 for its internal network, another for the PSN VPN and a third for the peripherals network). The Ultra-NES 512 only needed one /64, but the amplifier insisted on a /60 so it could delegate /64's to the cassette tape deck, cd player, mp3 player, etc. The Ford Home Automotive Network (HAN) also grabbed a block from which to delegate /62's to the three parked cars. Because you know: you need separate networks in each car for the life safety systems, the non-safety systems and the entertainment systems. I mean really, why wouldn't the life safety system in a car dynamically acquire its globally-addressable IPv6 addresses from the customer's cheap home Internet equipment? So they'll each need their /64's which means the car as a whole needs a /62. But the HAN only needed a /60 for for all of it since there were only 3 cars. Now, the Windows 9 PC sat on the /64 PC LAN directly connected to the Home Router, but it needed an additional /64 for its virtual machine network hosting the Windows XP VM needed to run older software. And the wireless LAN only ended up consuming a single /64. But after the two /58's, that meant the Home Router needed a full /56 from the Internet Router. Finally, the Internet Router connects two networks... the customer's web server DMZ (/64) and the home router (/56). So after you figure in the HAC, the HAN, the HAS, the HEN and all the other connections you need at least a /55... which doesn't fit in a /56 but does fit in a /48. Qed. * Now, in Bill's world, the appliances don't expose their internals. When they employ any form of IP networking inside, which they generally don't, they use fe80 link-local addresses inside or maybe a ULA prefix. So even you have a Smart Fridge within the time span that you care about for today's home user IPv6 assignments, it occupies a single public address on your home's flat /64. Ditto the game consoles and tape decks. With maybe two other /64's: one for servers and one for the wireless LAN. And that /62 need easily fits in your /56 assignment. Regards, Bill Herrin * I say this with trepidation. A quarter century ago I used a similar reductio ad absurdum with a friend who suggested making every road a toll road. "Back out of the driveway. Pay the toll. Turn on to main. Pay the toll. Left on 15th. Pay the toll." Wouldn't you know, E-Z Pass came along and brought it to the edge of possible. Then again, possible doesn't necessarily mean advisable. -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Aug 10, 2011, at 6:43 PM, William Herrin wrote:
On Wed, Aug 10, 2011 at 2:17 PM, Jeff Wheeler <jsw@inconcepts.biz> wrote:
On Wed, Aug 10, 2011 at 2:03 PM, Owen DeLong <owen@delong.com> wrote:
That said, /48 to the home should be what is happening, and /56 is a better compromise than anything smaller.
You don't really imagine that end-users will require more than 2^8 subnets, but that they will want several levels of very simple, nibble-aligned routers within their network?
Hi Jeff,
In Owen's world, the refrigerator, toaster and microwave each request a /64 from the GE Home Appliance Controller, those /64's being necessary to address each appliance's internal button, light and sensor networks. To accommodate all of these appliances, the HAC has acquired a /59 for all the home appliances from the Home Automation System (HAS) which also has its own LAN and supplied a big block to the furnace and a smaller block to the security system. So, the HAS needed a /58 which it got from the Linksys Home Router.
The Sony Home Entertainment Network (HEN) Controller also needed a /58 from the Home Router to accommodate the Playstation 5's need for a /62 (one /64 for its internal network, another for the PSN VPN and a third for the peripherals network). The Ultra-NES 512 only needed one /64, but the amplifier insisted on a /60 so it could delegate /64's to the cassette tape deck, cd player, mp3 player, etc.
The Ford Home Automotive Network (HAN) also grabbed a block from which to delegate /62's to the three parked cars. Because you know: you need separate networks in each car for the life safety systems, the non-safety systems and the entertainment systems. I mean really, why wouldn't the life safety system in a car dynamically acquire its globally-addressable IPv6 addresses from the customer's cheap home Internet equipment? So they'll each need their /64's which means the car as a whole needs a /62. But the HAN only needed a /60 for for all of it since there were only 3 cars.
Now, the Windows 9 PC sat on the /64 PC LAN directly connected to the Home Router, but it needed an additional /64 for its virtual machine network hosting the Windows XP VM needed to run older software. And the wireless LAN only ended up consuming a single /64. But after the two /58's, that meant the Home Router needed a full /56 from the Internet Router.
Finally, the Internet Router connects two networks... the customer's web server DMZ (/64) and the home router (/56). So after you figure in the HAC, the HAN, the HAS, the HEN and all the other connections you need at least a /55... which doesn't fit in a /56 but does fit in a /48. Qed. *
Thanks... An excellent write up, even if it was intended tongue in cheek. However, you left out the need for addressing for the RFID tags that will end up on most groceries, etc.
Now, in Bill's world, the appliances don't expose their internals. When they employ any form of IP networking inside, which they generally don't, they use fe80 link-local addresses inside or maybe a ULA prefix. So even you have a Smart Fridge within the time span that you care about for today's home user IPv6 assignments, it occupies a single public address on your home's flat /64. Ditto the game consoles and tape decks. With maybe two other /64's: one for servers and one for the wireless LAN. And that /62 need easily fits in your /56 assignment.
I'm glad I live in Owen's world and not Bill's. I think my appliance vendors will make much cooler and more useful products than yours. Owen
On Wed, Aug 10, 2011 at 8:56 PM, Owen DeLong <owen@delong.com> wrote:
I'm glad I live in Owen's world and not Bill's. I think my appliance vendors will make much cooler and more useful products than yours.
In Owen's world the fridge and pantry would know what they have, the amounts, and possibly location. The recipe book would be able to check what is in the fridge and pantry and tell if you need to buy more. It could then set the oven to the correct temperature when you reach the correct step in the recipe. Yes, all that could be done with servers on the pantry and fridge, but then there would be different implementations of each protocol and incompatibilities between the fridge, pantry, recipe book, and oven.
On 11/08/2011, at 12:04 PM, Philip Dorr wrote:
On Wed, Aug 10, 2011 at 8:56 PM, Owen DeLong <owen@delong.com> wrote:
I'm glad I live in Owen's world and not Bill's. I think my appliance vendors will make much cooler and more useful products than yours.
In Owen's world the fridge and pantry would know what they have, the amounts, and possibly location. The recipe book would be able to check what is in the fridge and pantry and tell if you need to buy more. It could then set the oven to the correct temperature when you reach the correct step in the recipe.
The wine cellar will know how much you drank last night, and communicate with the life-critical systems in the car to prevent engine start while you're over the limit. When the home BMS network notices that the flow sensor on the shower hasn't started at the usual time the next morning, it'll play an IVR out of your home PBX network to tell the boss you're too hungover to come to work. Owen's world has built in automated protection to help you through the fact that IPv6 subnetting will turn you to drink :-) - mark -- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223
On Aug 10, 2011, at 6:43 PM, William Herrin wrote:
I mean really, why wouldn't the life safety system in a car dynamically acquire its globally-addressable IPv6 addresses from the customer's cheap home Internet equipment? So they'll each need their /64's which means the car as a whole needs a /62. But the HAN only needed a /60 for for all of it since there were only 3 cars.
several cars on the road today have cellular radios on more than one network ( the nissan leaf for example) When you account for integration into the driver and passengers personal area networks (pans) as for example ford sync does today, and integration into home automation networks, (garage doors, lighting, media syncronization) and in the case of electric cars, the smart grid) why wouldn't a car, acquire addresses and be discoverable on the users home network? By the time this is fully realized, the car will be on quite a few networks, instead of just the two or three it's presently either supporting or attached to...
Neither of these are true, though in the future we _might_ have deployable technology that allows for automated routing setup (though I very seriously doubt it) in the home. Layer 2 isolation is both easier and more reliable than attempting it at layer 3 which is isolation by agreement, i.e. it doesn't really exist. On 8/10/2011 9:02 AM, Owen DeLong wrote:
Bridging eliminates the multicast isolation that you get from routing.
This is not a case for bridging, it's a case for making it possible to do real routing in the home and we now have the space and the technology to actually do it in a meaningful and sufficiently automatic way as to be applicable to Joe 6-Mac.
-- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------
On 10 Aug 2011, at 16:11, Scott Helms wrote:
Neither of these are true, though in the future we _might_ have deployable technology that allows for automated routing setup (though I very seriously doubt it) in the home. Layer 2 isolation is both easier and more reliable than attempting it at layer 3 which is isolation by agreement, i.e. it doesn't really exist.
Well, there is some new effort on this in the homenet WG in IETF. For snooping IPv6 multicast it's MLD snooping rather than IGMP. We use it in our enterprise since we have multiple multicast video channels in use. Tim
On 8/10/2011 9:02 AM, Owen DeLong wrote:
Bridging eliminates the multicast isolation that you get from routing.
This is not a case for bridging, it's a case for making it possible to do real routing in the home and we now have the space and the technology to actually do it in a meaningful and sufficiently automatic way as to be applicable to Joe 6-Mac.
-- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------
Tim, Hence the "might". I worry when people start throwing around terms like routing in the home that they don't understand the complexities of balancing the massive CPE installed base, technical features, end user support, ease of installation & managemenet, and (perhaps most importantly) the economics of mass adoption. This one of the choices that made DSL deployments more complex and expensive than DOCSIS cable deployments which in turn caused the CEO of AT&T to say their entire DSL network is obsolete. http://goo.gl/exwqu On 8/10/2011 12:57 PM, Tim Chown wrote:
On 10 Aug 2011, at 16:11, Scott Helms wrote:
Neither of these are true, though in the future we _might_ have deployable technology that allows for automated routing setup (though I very seriously doubt it) in the home. Layer 2 isolation is both easier and more reliable than attempting it at layer 3 which is isolation by agreement, i.e. it doesn't really exist. Well, there is some new effort on this in the homenet WG in IETF.
For snooping IPv6 multicast it's MLD snooping rather than IGMP. We use it in our enterprise since we have multiple multicast video channels in use.
Tim
On 8/10/2011 9:02 AM, Owen DeLong wrote:
Bridging eliminates the multicast isolation that you get from routing.
This is not a case for bridging, it's a case for making it possible to do real routing in the home and we now have the space and the technology to actually do it in a meaningful and sufficiently automatic way as to be applicable to Joe 6-Mac.
-- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------
-- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------
There is some deployable technology that allows some aspects of this today. Yes, it's in its infancy. Small prefix limitations will guarantee it never sees the light of day just as NAT precluded many useful innovations from getting deployed. Layer 3 isolation is only isolation by agreement if the hosts have some way to get on the same physical or logical LAN layer 2 segment. Otherwise, layer 3 isolation is as effective as any firewall. Layer 2 isolation, OTOH, is both harder to administer and no more effective than layer 3. If you can bypass layer 3 by connecting to the same LAN segment, chances are you can bypass layer 2 by making that LAN segment one which doesn't go through the enforcement switch between the two devices in question. Owen On Aug 10, 2011, at 8:11 AM, Scott Helms wrote:
Neither of these are true, though in the future we _might_ have deployable technology that allows for automated routing setup (though I very seriously doubt it) in the home. Layer 2 isolation is both easier and more reliable than attempting it at layer 3 which is isolation by agreement, i.e. it doesn't really exist.
On 8/10/2011 9:02 AM, Owen DeLong wrote:
Bridging eliminates the multicast isolation that you get from routing.
This is not a case for bridging, it's a case for making it possible to do real routing in the home and we now have the space and the technology to actually do it in a meaningful and sufficiently automatic way as to be applicable to Joe 6-Mac.
-- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------
On Wed, Aug 10, 2011 at 6:55 AM, Alexander Harrowell <a.harrowell@gmail.com> wrote:
Thinking about the CPE thread, isn't this a case for bridging as a feature in end-user devices? If Joe's media-centre box etc would bridge its downstream ports to the upstream port, the devices on them could just get an address, whether by DHCPv6 from the CPE router's delegation or by SLAAC, and then register in local DNS or more likely do multicast- DNS so they could find each other.
This would require the ISP gateway to have IPv6 ND entries for all of the end-user's devices. If that is only a few devices, like the typical SOHO LAN today, that's probably fine. It is not fine if I purchase some IPv6-connected nanobots. Given today's routers, it is probably not even fine if the average SOHO goes from 1 state entry to just 20 or 30. I have about 20 devices in my home that use the Internet -- TVs, DVRs, VoIP telephones, printer, mobile phones with Wi-Fi, a couple of video game consoles, etc. I imagine that is not atypical these days. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
In message <174561.1312807412@turing-police.cc.vt.edu>, Valdis.Kletnieks@vt.edu writes:
--==_Exmh_1312807411_38980P Content-Type: text/plain; charset=us-ascii
On Mon, 08 Aug 2011 10:15:17 +0200, Mohacsi Janos said:
- Home users - they usually don't know what is subnet. Setting up different subnets in their SOHO router can be difficult. Usually the simple 1 subnet for every device is enough for them. Separating some devices into a separate subnets is usually enough for the most sophisticated home users. If not then he can opt for business service....
You don't want to make the assumption that just because Joe Sixpack doesn't know what a subnet is, that Joe Sixpack's CPE doesn't know either.
And remember that if it's 3 hops from one end of Joe Sixpack's internal net t o the other, you're gonna burn a few bits to support heirarchical routing so yo u don't need a routing protocol. So if Joe's exterior-facing CPU gets handed a /56 by the provider, and it hands each device it sees a /60 in case it's a device that routes too, it can only support 14 devices. And if one of the things that got handed a /60 is a wireless access point or something, it's on ly going to be able to support 15 or so subnets. So a simple topology of only a half dozen devices can burn up 8 bits of subnet addressing real fast. Yes, yo u can conserve bits by being more clever, but then you probably need an IGP of some sort....
Which is why CPE devices shouldn't do heirarchical assignment by default. PD supports multiple upstream requests. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Aug 8, 2011, at 5:43 AM, Valdis.Kletnieks@vt.edu wrote:
On Mon, 08 Aug 2011 10:15:17 +0200, Mohacsi Janos said:
- Home users - they usually don't know what is subnet. Setting up different subnets in their SOHO router can be difficult. Usually the simple 1 subnet for every device is enough for them. Separating some devices into a separate subnets is usually enough for the most sophisticated home users. If not then he can opt for business service....
You don't want to make the assumption that just because Joe Sixpack doesn't know what a subnet is, that Joe Sixpack's CPE doesn't know either.
And remember that if it's 3 hops from one end of Joe Sixpack's internal net to the other, you're gonna burn a few bits to support heirarchical routing so you don't need a routing protocol. So if Joe's exterior-facing CPU gets handed a /56 by the provider, and it hands each device it sees a /60 in case it's a device that routes too, it can only support 14 devices. And if one of the things that got handed a /60 is a wireless access point or something, it's only going to be able to support 15 or so subnets. So a simple topology of only a half dozen devices can burn up 8 bits of subnet addressing real fast. Yes, you can conserve bits by being more clever, but then you probably need an IGP of some sort....
YOu lost a /60 somewhere in there… I understand 1 /60 for the primary device. You accounted for 14 /60s to other subordinate devices. Presumably the /64(s) that connect the other subordinate devices to the primary router are from within that first /60, so, where did the 16th /60 go? Finally, for things that are building automatic hierarchical topologies, it seems only sane to me that they would implement some form of OSPF to facilitate the routing. There's no reason that can't be equally automated. Owen
On Aug 8, 2011, at 1:15 AM, Mohacsi Janos wrote:
On Fri, 5 Aug 2011, Brian Mengel wrote:
In reviewing IPv6 end user allocation policies, I can find little agreement on what prefix length is appropriate for residential end users. /64 and /56 seem to be the favorite candidates, with /56 being slightly preferred.
I am most curious as to why a /60 prefix is not considered when trying to address this problem. It provides 16 /64 subnetworks, which seems like an adequate amount for an end user.
Does anyone have opinions on the BCP for end user addressing in IPv6?
For business customers I would give /48 and home users who might have 1-2 subnet I would give /56 or /60. Reasons: - Business customers night grow where you have to provide bigger amount of subnet - allow space for future extension -
- Home users - they usually don't know what is subnet. Setting up different subnets in their SOHO router can be difficult. Usually the simple 1 subnet for every device is enough for them. Separating some devices into a separate subnets is usually enough for the most sophisticated home users. If not then he can opt for business service….
This utterly ignores the reality of DHCPv6, DHCP-PD, and technologies currently being developed for rational automatic hierarchies of topology. Owen
Hi Brian,
From someone who's actually done this.
- Our customer base is primarily PPP connected broadband users (variety of technologies, mostly ADSL). - We do a DYNAMIC /64 on the PPP interface so that people who terminate directly on a PC can get IPv6 without DHCPv6 PD. - In addition for the subnet assigned via DHCPv6 Prefix delegation which is STATIC as that's what customers have been asking for: In our trial phase we did /60s to customers - this worked just fine. I don't recall anyone actually saying "I need more". (The /60 was the first nibble boundary and it allowed us to do some dumb things for allocation which didn't compromise the allocation strategy later). In production we've chosen a more conventional /56. At some point it becomes a little arbitrary. Our feeling is that at the point your have 256 /64s in production then ADSL is probably NOT what you need or want as a technology so we can do things differently for ethernet connected customers. We're getting there with support for customers bringing their own PI space. (For an idea of scale - we're tiny globally, but have around 250k customers across mainly Australia. We run our own global dualstack network). MMC On 06/08/2011, at 1:47 AM, Brian Mengel wrote: In reviewing IPv6 end user allocation policies, I can find little agreement on what prefix length is appropriate for residential end users. /64 and /56 seem to be the favorite candidates, with /56 being slightly preferred. I am most curious as to why a /60 prefix is not considered when trying to address this problem. It provides 16 /64 subnetworks, which seems like an adequate amount for an end user. Does anyone have opinions on the BCP for end user addressing in IPv6? -- Matthew Moyle-Croft Peering Manager and Team Lead - Commercial and DSLAMs Internode /Agile Level 5, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc@internode.com.au<mailto:mmc@internode.com.au> Web: http://www.on.net<http://www.on.net/> Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
participants (46)
-
Alexander Harrowell -
Brett Frankenberger -
Brian E Carpenter -
Brian Mengel -
Brielle Bruns -
Cameron -
Cameron Byrne -
Carlos Martinez-Cagnazzo -
Chris Adams -
David Conrad -
David Sparro -
Doug Barton -
Eugen Leitl -
Frank Bulk -
Greg Ihnen -
james machado -
Jamie Bowden -
Jeff Johnstone -
Jeff Wheeler -
Jeroen Massar -
Jimmy Hess -
Joe Greco -
Joel Jaeggli -
Jonathon Exley -
Mark Andrews -
Mark Newton -
Matthew Moyle-Croft -
Michael Hare -
Michael Thomas -
Mikael Abrahamsson -
mikea -
Mohacsi Janos -
Mukom Akong Tamon -
Owen DeLong -
Philip Dorr -
Randy Bush -
Randy Carpenter -
Ryan Malayter -
Sascha Lenz -
Scott Helms -
sthaug＠nethelp.no -
Sven Olaf Kamphuis -
Tim Chown -
Tim Franklin -
Valdis.Kletnieks＠vt.edu -
William Herrin