RE: IPv6 Ignorance
Or just use their IP address as a useful universal identifier, which is kind of the point of V6. Whether you can be routed to isn't the point. It's that, if/when you can, there is an address, and it's easy to assign/divine, that you can be reached at, is. -Original Message- From: George Herbert [mailto:george.herb...@gmail.com] Sent: Friday, September 28, 2012 11:17 PM To: John R. Levine; George Herbert Cc: Tomas L. Byrnes; nanog@nanog.org Subject: Re: IPv6 Ignorance My customer the Dark Matter local galaxy group beg to disagree; just because you cannot see them does not mean that you cannot feel them gravitationally. Or route to them. George William Herbert Sent from my iPhone On Sep 28, 2012, at 10:31 PM, John R. Levine jo...@iecc.com wrote: You won't have enough addresses for Dark Matter, Neutrinos, etc. Atoms wind up using up about 63 bits (2^10^82) based on the current SWAG. The missing mass is 84% of the universe. Fortunately, until we find it, it doesn't need addresses. -Original Message- From: Randy Bush [mailto:ra...@psg.com] Sent: Monday, September 17, 2012 8:30 PM To: John Levine Cc: nanog@nanog.org Subject: Re: IPv6 Ignorance In technology, not much. But I'd be pretty surprised if the laws of arithmetic were to change, or if we were to find it useful to assign IP addresses to objects smaller than a single atom. we assign them /64s Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly
Re: IPv6 Ignorance
On Sat, 2012-09-29 at 16:53 +1000, Jason Leschnik wrote: To address everything in the Universe wouldn't you then get stuck in some kinda of loop of having to address the matter that is used by the addresses... i.e. to address everything in the Universe you need more matter than the Universe? *brain* pop You just have to have a mechanism to NAT the quarks... or wait 'til IPv8 comes out. 512 bits should be big enough to allow hierarchical routing for alternate universes, yes? -- Bruce H. McIntoshb...@ufl.edu Senior Network Engineer http://net-services.ufl.edu University of Florida CNS/Network Services 352-273-1066
Re: IPv6 Ignorance
My customer the Dark Matter local galaxy group beg to disagree; just because you cannot see them does not mean that you cannot feel them gravitationally. Or route to them. George William Herbert Sent from my iPhone On Sep 28, 2012, at 10:31 PM, John R. Levine jo...@iecc.com wrote: You won't have enough addresses for Dark Matter, Neutrinos, etc. Atoms wind up using up about 63 bits (2^10^82) based on the current SWAG. The missing mass is 84% of the universe. Fortunately, until we find it, it doesn't need addresses. -Original Message- From: Randy Bush [mailto:ra...@psg.com] Sent: Monday, September 17, 2012 8:30 PM To: John Levine Cc: nanog@nanog.org Subject: Re: IPv6 Ignorance In technology, not much. But I'd be pretty surprised if the laws of arithmetic were to change, or if we were to find it useful to assign IP addresses to objects smaller than a single atom. we assign them /64s Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly
Re: IPv6 Ignorance
To address everything in the Universe wouldn't you then get stuck in some kinda of loop of having to address the matter that is used by the addresses... i.e. to address everything in the Universe you need more matter than the Universe? *brain* pop On Sat, Sep 29, 2012 at 4:17 PM, George Herbert george.herb...@gmail.comwrote: My customer the Dark Matter local galaxy group beg to disagree; just because you cannot see them does not mean that you cannot feel them gravitationally. Or route to them. George William Herbert Sent from my iPhone On Sep 28, 2012, at 10:31 PM, John R. Levine jo...@iecc.com wrote: You won't have enough addresses for Dark Matter, Neutrinos, etc. Atoms wind up using up about 63 bits (2^10^82) based on the current SWAG. The missing mass is 84% of the universe. Fortunately, until we find it, it doesn't need addresses. -Original Message- From: Randy Bush [mailto:ra...@psg.com] Sent: Monday, September 17, 2012 8:30 PM To: John Levine Cc: nanog@nanog.org Subject: Re: IPv6 Ignorance In technology, not much. But I'd be pretty surprised if the laws of arithmetic were to change, or if we were to find it useful to assign IP addresses to objects smaller than a single atom. we assign them /64s Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly -- Regards, Jason Leschnik. [m] 0432 35 4224 [w@] jason dot leschnik at ansto dot gov dot aujason.lesch...@ansto.gov.au [U@] jml...@uow.edu.au
RE: IPv6 Ignorance
You won't have enough addresses for Dark Matter, Neutrinos, etc. Atoms wind up using up about 63 bits (2^10^82) based on the current SWAG. The missing mass is 84% of the universe. -Original Message- From: Randy Bush [mailto:ra...@psg.com] Sent: Monday, September 17, 2012 8:30 PM To: John Levine Cc: nanog@nanog.org Subject: Re: IPv6 Ignorance In technology, not much. But I'd be pretty surprised if the laws of arithmetic were to change, or if we were to find it useful to assign IP addresses to objects smaller than a single atom. we assign them /64s
RE: IPv6 Ignorance
You won't have enough addresses for Dark Matter, Neutrinos, etc. Atoms wind up using up about 63 bits (2^10^82) based on the current SWAG. The missing mass is 84% of the universe. Fortunately, until we find it, it doesn't need addresses. -Original Message- From: Randy Bush [mailto:ra...@psg.com] Sent: Monday, September 17, 2012 8:30 PM To: John Levine Cc: nanog@nanog.org Subject: Re: IPv6 Ignorance In technology, not much. But I'd be pretty surprised if the laws of arithmetic were to change, or if we were to find it useful to assign IP addresses to objects smaller than a single atom. we assign them /64s Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
* Adrian Bool On 24 Sep 2012, at 22:42, Mike Jones m...@mikejones.in wrote: While you could do something similar without the encapsulation this would require that every router on your network support routing on port numbers, Well, not really. As the video pointed out, the system was designed to leverage hierarchy to reduce routing complexity. Using the hierarchy, port number routing is only required at the level where a routes diverge on a port basis - which if you're being sensible about such a deployment would only be at the edge of the access layer. While that might be true, the access network would normally be the largest part of an SP's network, when it comes to router count. The access part might have 100s or 1000s of times more routers than the core/border. The cone gets wider the closer to the customer edge you get. Slide 6 illustrates this well. By not doing translation or encapsulation of the IPv4 packets, instead relying on the access routers to natively route based on A+P, we would have made sure that the ISPs that have already deployed IPv6 could not use the technology, and that ISPs that have not yet deployed IPv6 and think the technology looks interesting have a huge incentive to put off the entire project for several years, while they wait for new router products or software images that support A+P to be made available. Not exactly desirable. There are also other problems with the idea - not only do you need the router to be able to forward based on A+P, you would also need to distribute these A+P routes in the network. Which means we would need to update OSPFv2, IS-IS, or whatever else the SP might be using. We would have to update DHCPv4 (both the protocol and the SP's server) too, as there is currently no way it can give you a lease for a partial IPv4 address. This would also touch on layer 2 devices doing layer 3 inspection and policing, such as DHCP Snooping. You'd also need to update ARP, as there is currently no way to send an ARP who-has 192.0.2.1 port 1234 request, which you would have to do. The amount of changes required is so large that you might as well call the result IPv4½ instead of MAP. Finally, operating a single-stack network (regardless of that single stack being IPv4 or IPv6) is much preferable to operating a dual-stack one. Less complexity, less things to trouble-shoot, less things to set up, less things to monitor, less things to train staff in, and so forth. That MAP (and DS-Lite) means single-stack IPv6 in the vast majority of the network is a very desirable trait, in my opinion. Your proposal would remove this benefit, instead we'd end up with a dual-stack IPv4½/IPv6 network. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com
Re: Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
Adrian, MAP facilitates both IPv6 deployment and IPv4 address exhaustion without involving any CGN mess in the network. This allows the home networks to stay dual-stack, use IPv6 as possible, and resort to IPv4 if IPv6 is not feasible for the intended destinations. One could promote the intent being that as more and more traffic goes over IPv6, less and less IPv4 will be needed (thereby shrinking the reliance on IPv4 ports sharing). Note that MAP Translation mode (i.e. MAP-T) does not involve any encapsulation, so, any QoS or Security or LI or DPI or Caching needing access to Layer4 info (i.e. UDP/TCP ports) would work just fine anywhere in the network. In case of MAP-E (Encapsulation mode), layer4 info (i.e. UDP/TCP ports) is not available in the network (until at boundary of the network where decapsulation is done). * The ISP's router to which the user connects being able to route packets on routes that go beyond the IP address and into the port number field of TCP/UDP. Nope. The routers still follow the dynamic IPv4 and IPv6 routing for packet forwarding. That is UNCHANGED. The routers (expected to the boundary routers/ASBR, not the PE routers connecting the users) must have to look at the ports for IPv4-IPv6 stateless translation. Once translated, routing lookup as usual. * A CE router being instructed to constrain itself to using a limited set of ports on the WAN side in its NAT44 implementation. Indeed. And it is not much different from how it works today. Almost all CPEs (I.e. Residential routers) work with limited set of ports (typically 2000) for dynamic NAT44 anyway. Of course, when MAP is enabled, the range would no longer be the default (as is the case today), rather something that is assigned using DHCP or TR069. That's in the control plane. Cheers, Rajiv -Original Message- From: nanog-requ...@nanog.org nanog-requ...@nanog.org Reply-To: nanog@nanog.org nanog@nanog.org Date: Tuesday, September 25, 2012 12:08 AM To: nanog@nanog.org nanog@nanog.org Subject: NANOG Digest, Vol 56, Issue 84 Date: Mon, 24 Sep 2012 22:42:46 +0100 From: Mike Jones m...@mikejones.in To: Adrian Bool a...@logic.org.uk Cc: nanog@nanog.org nanog@nanog.org Subject: Re: Throw me a IPv6 bone (sort of was IPv6 ignorance) Message-ID: CAAAas8H8ERETrcnn0TaFD3cNToAfpdy12G6goNP5e=2cyth...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 On 24 September 2012 21:11, Adrian Bool a...@logic.org.uk wrote: On 24 Sep 2012, at 17:57, Tore Anderson tore.ander...@redpill-linpro.com wrote: * Tore Anderson I would pay very close attention to MAP/4RD. FYI, Mark Townsley had a great presentation about MAP at RIPE65 today, it's 35 minutes you won't regret spending: https://ripe65.ripe.net/archives/video/5 https://ripe65.ripe.net/presentations/91-townsley-map-ripe65-ams-sept-24 -2012.pdf Interesting video; thanks for posting the link. This does seem a strange proposal though. My understanding from the video is that it is a technology to help not with the deployment of IPv6 but with the scarcity of IPv4 addresses. In summary; it simply allows a number of users (e.g. 1024) to share a single public IPv4 address. My feeling is therefore, why are the IPv4 packets to/from the end user being either encapsulated or translated into IPv6 - why do they not simply remain as IPv4 packets? If the data is kept as IPv4, this seems to come down to just two changes, * The ISP's router to which the user connects being able to route packets on routes that go beyond the IP address and into the port number field of TCP/UDP. * A CE router being instructed to constrain itself to using a limited set of ports on the WAN side in its NAT44 implementation. Why all the IPv6 shenanigans complicating matters? While you could do something similar without the encapsulation this would require that every router on your network support routing on port numbers, by using IPv6 packets it can be routed around your network by existing routers. And it's not like anyone is going to be deploying such a system without also deploying IPv6, so it's not adding any additional requirements doing it that way. - Mike -- Message: 3 Date: Mon, 24 Sep 2012 23:34:30 +0100 From: Adrian Bool a...@logic.org.uk To: nanog@nanog.org nanog@nanog.org Subject: Re: Throw me a IPv6 bone (sort of was IPv6 ignorance) Message-ID: 8beebcda-b6fa-4407-bf95-e122b26f4...@logic.org.uk Content-Type: text/plain; charset=us-ascii On 24 Sep 2012, at 22:42, Mike Jones m...@mikejones.in wrote: While you could do something similar without the encapsulation this would require that every router on your network support routing on port numbers, Well, not really. As the video pointed out, the system was designed to leverage hierarchy to reduce routing complexity. Using the hierarchy, port number routing is only required at the level where a routes diverge on a port basis - which if you're being sensible about such a deployment would only
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
* Tore Anderson I would pay very close attention to MAP/4RD. FYI, Mark Townsley had a great presentation about MAP at RIPE65 today, it's 35 minutes you won't regret spending: https://ripe65.ripe.net/archives/video/5 https://ripe65.ripe.net/presentations/91-townsley-map-ripe65-ams-sept-24-2012.pdf Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
On 24 Sep 2012, at 17:57, Tore Anderson tore.ander...@redpill-linpro.com wrote: * Tore Anderson I would pay very close attention to MAP/4RD. FYI, Mark Townsley had a great presentation about MAP at RIPE65 today, it's 35 minutes you won't regret spending: https://ripe65.ripe.net/archives/video/5 https://ripe65.ripe.net/presentations/91-townsley-map-ripe65-ams-sept-24-2012.pdf Interesting video; thanks for posting the link. This does seem a strange proposal though. My understanding from the video is that it is a technology to help not with the deployment of IPv6 but with the scarcity of IPv4 addresses. In summary; it simply allows a number of users (e.g. 1024) to share a single public IPv4 address. My feeling is therefore, why are the IPv4 packets to/from the end user being either encapsulated or translated into IPv6 - why do they not simply remain as IPv4 packets? If the data is kept as IPv4, this seems to come down to just two changes, * The ISP's router to which the user connects being able to route packets on routes that go beyond the IP address and into the port number field of TCP/UDP. * A CE router being instructed to constrain itself to using a limited set of ports on the WAN side in its NAT44 implementation. Why all the IPv6 shenanigans complicating matters? Cheers, aid
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
On 24 September 2012 21:11, Adrian Bool a...@logic.org.uk wrote: On 24 Sep 2012, at 17:57, Tore Anderson tore.ander...@redpill-linpro.com wrote: * Tore Anderson I would pay very close attention to MAP/4RD. FYI, Mark Townsley had a great presentation about MAP at RIPE65 today, it's 35 minutes you won't regret spending: https://ripe65.ripe.net/archives/video/5 https://ripe65.ripe.net/presentations/91-townsley-map-ripe65-ams-sept-24-2012.pdf Interesting video; thanks for posting the link. This does seem a strange proposal though. My understanding from the video is that it is a technology to help not with the deployment of IPv6 but with the scarcity of IPv4 addresses. In summary; it simply allows a number of users (e.g. 1024) to share a single public IPv4 address. My feeling is therefore, why are the IPv4 packets to/from the end user being either encapsulated or translated into IPv6 - why do they not simply remain as IPv4 packets? If the data is kept as IPv4, this seems to come down to just two changes, * The ISP's router to which the user connects being able to route packets on routes that go beyond the IP address and into the port number field of TCP/UDP. * A CE router being instructed to constrain itself to using a limited set of ports on the WAN side in its NAT44 implementation. Why all the IPv6 shenanigans complicating matters? While you could do something similar without the encapsulation this would require that every router on your network support routing on port numbers, by using IPv6 packets it can be routed around your network by existing routers. And it's not like anyone is going to be deploying such a system without also deploying IPv6, so it's not adding any additional requirements doing it that way. - Mike
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
On 24 Sep 2012, at 22:42, Mike Jones m...@mikejones.in wrote: While you could do something similar without the encapsulation this would require that every router on your network support routing on port numbers, Well, not really. As the video pointed out, the system was designed to leverage hierarchy to reduce routing complexity. Using the hierarchy, port number routing is only required at the level where a routes diverge on a port basis - which if you're being sensible about such a deployment would only be at the edge of the access layer. aid
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
You can avoid the giant NAT box as long as you don't have to add a new customer for whom you don't have an available IPv4 address. At that point, you either have to implement the giant NAT box for your future (and possibly an increasing percentage of your existing) customers, or, stop adding new customers. In terms of the CPE situation, until you solve that, IPv6-only isn't going to work for them, either, so the CPE issues simply can't be avoided no matter what. We need to find a way to get the vendors to make that float. Owen On Sep 21, 2012, at 12:42 , Mark Radabaugh m...@amplex.net wrote: On 9/21/12 9:40 AM, Jeroen Massar wrote: On 2012-09-21 15:31 , Mark Radabaugh wrote: The part of IPv6 that I am unclear on and have not found much documentation on is how to run IPv6 only to end users. Anyone care to point me in the right direction? Can we assign IPv6 only to end users? What software/equipment do we need in place as a ISP to ensure these customers can reach IPv4 only hosts? The Interwebs are full of advice on setting up IPv6 tunnels for your house (nice but...). There is lots of really old documentation out there for IPv6 mechanisms that are depreciated or didn't fly. What is current best practice? The IETF BCP is to deploy Dual Stack, thus both IPv4 and IPv6 at the same time. When that is not possible, as you ran out of IPv4 addresses, you should look at Dual Stack Lite (DS Lite) eg as supplied by ISC's AFTR and other such implementations. Depending on your business model you can of course also stick everybody behind a huge NAT or require them to use HTTP proxies to get to the Internet as most people define it... Do note that if you are asking any of these questions today you are years late in reading up and you missed your chance to be prepared for this in all kinds of ways. Greets, Jeroen We can already do dual stack - that's not really a problem. I was really rather hoping to avoid the giant NAT box. I'll take a look at DS Lite and or NAT64/DNS64 and see if that makes any sense. Dual stack isn't all that hard to deploy in the enterprise, perhaps even IPv6 only with NAT for backward compatibility. Running dual stack to residential consumers still has huge issues with CPE. It's not an environment where we have control over the router the customer picks up at Walmart. There is really very little point in spending a lot of resources on something the consumer can't currently use. I don't think saying we missed the boat really applies - and the consumer CPE ship is sinking at the dock. -- Mark Radabaugh Amplex m...@amplex.net 419.837.5015
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
* Mark Radabaugh We can already do dual stack - that's not really a problem. I was really rather hoping to avoid the giant NAT box. I'll take a look at DS Lite and or NAT64/DNS64 and see if that makes any sense. Both DS-Lite and NAT64 contain some form of a «giant NAT box» as part of the solution, I'm afraid. Same shit, different wrapping. You might want to look into MAP, which to the best of my knowledge is the only solution that facilitates IPv4 address sharing between subscribers without any form of (centralised) NAT. Running dual stack to residential consumers still has huge issues with CPE. It's not an environment where we have control over the router the customer picks up at Walmart. In that case, running IPv6-only to your subscribers isn't a realistic proposition at this point in time. Unfortunately. If you're running out of IPv4 addresses, you better try to get your hands on more of them, somehow, or start planning for the «giant NAT box» you're going to need. Alternatively, you could begin providing all your *new* subscribers with managed CPEs that support DS-Lite, MAP, NAT64/DNS64/464XLAT (or whichever other IPv4 life-support technology you end up choosing), while at the same time letting your old subscribers with their IPv4-only Walmart CPEs hang on to their public IPv4 address for as long as they need it. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
Both DS-Lite and NAT64 contain some form of a «giant NAT box» as part of the solution, I'm afraid. Same shit, different wrapping. ds-lite is in the provider core. talk to the telco's lawyers when you want to use a new protocol. nat64 is at my cpe border. randy
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
In message m28vc2fglk.wl%ra...@psg.com, Randy Bush writes: Both DS-Lite and NAT64 contain some form of a =ABgiant NAT box=BB as part of the solution, I'm afraid. Same shit, different wrapping. ds-lite is in the provider core. talk to the telco's lawyers when you want to use a new protocol. DS-lite can be deployed between between customer and anyone that wants to provide IPv4 service for that customer. I would expect DS-lite to be out sourced by ISPs. nat64 is at my cpe border. randy -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
* Randy Bush Both DS-Lite and NAT64 contain some form of a «giant NAT box» as part of the solution, I'm afraid. Same shit, different wrapping. ds-lite is in the provider core. talk to the telco's lawyers when you want to use a new protocol. nat64 is at my cpe border. Mark was asking about how to run IPv6-only to his subscribers. I don't see how doing NAT64 in the CPE could possibly help him with that, as the NAT64 function would require an IPv4 address for its outside interface. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
On 9/22/12 4:03 AM, Tore Anderson wrote: * Mark Radabaugh We can already do dual stack - that's not really a problem. I was really rather hoping to avoid the giant NAT box. I'll take a look at DS Lite and or NAT64/DNS64 and see if that makes any sense. Both DS-Lite and NAT64 contain some form of a «giant NAT box» as part of the solution, I'm afraid. Same shit, different wrapping. You might want to look into MAP, which to the best of my knowledge is the only solution that facilitates IPv4 address sharing between subscribers without any form of (centralised) NAT. Running dual stack to residential consumers still has huge issues with CPE. It's not an environment where we have control over the router the customer picks up at Walmart. In that case, running IPv6-only to your subscribers isn't a realistic proposition at this point in time. Unfortunately. If you're running out of IPv4 addresses, you better try to get your hands on more of them, somehow, or start planning for the «giant NAT box» you're going to need. Alternatively, you could begin providing all your *new* subscribers with managed CPEs that support DS-Lite, MAP, NAT64/DNS64/464XLAT (or whichever other IPv4 life-support technology you end up choosing), while at the same time letting your old subscribers with their IPv4-only Walmart CPEs hang on to their public IPv4 address for as long as they need it. Best regards, Thanks for the help. We are actually in decent shape with respect to IPv4, probably at least 1 if not 2 years at current growth rate. We can deliver dual stack with public IPv4/6 to customers now. This is the planning stage for giant NAT box, assuming there are no better options. We are starting to provide some customers with managed CPE and your alternative suggestion may be the way to go. There are several other business/management/support advantages to Amplex supplying the CPE. This may be reason enough to expand that program. I didn't really think we would be able to run IPv6 only in the near future but wanted to make sure I wasn't missing something obvious. -- Mark Radabaugh Amplex m...@amplex.net 419.837.5015
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
* Mark Radabaugh Thanks for the help. We are actually in decent shape with respect to IPv4, probably at least 1 if not 2 years at current growth rate. We can deliver dual stack with public IPv4/6 to customers now. This is the planning stage for giant NAT box, assuming there are no better options. We are starting to provide some customers with managed CPE and your alternative suggestion may be the way to go. There are several other business/management/support advantages to Amplex supplying the CPE. This may be reason enough to expand that program. I didn't really think we would be able to run IPv6 only in the near future but wanted to make sure I wasn't missing something obvious. Okay. In this case I would pay very close attention to MAP/4RD. Here are some drafts to get you started: http://tools.ietf.org/html/draft-mdt-softwire-map-encapsulation-00 http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01 http://tools.ietf.org/html/draft-despres-softwire-4rd-u-06 There are different flavours, but as I understand it, the basic idea is the same... You won't find shipping products today, but there will probably be by the time you need it. Like DS-Lite, it assumes an IPv6-only access network, with the CPE communicating with a centralised component over IPv6 to provision IPv4 service for the subscriber's LAN. Unlike DS-Lite, however, the central component does not perform NAT or any other stateful translations - what it essentially does is to steal bits from the TCP/UDP port space for routing, so (oversimplified) subscriber A gets ports 2000-2999, B gets 3000-3999, and so forth. The subscriber will be able to receive internet-initiated traffic to his assigned port range. The NAT44 function in the CPE works pretty much like today, except that it must ensure the source ports are rewritten to fall inside its assigned range. You can also provision an «entire IPv4» to a single CPE also, for example as a premium service. The central component is operating in stateless mode, so it'll be easier to scale than any centralised NAT, and you can also anycast it, load balance between several instances using ECMP, and so on. In my opinion, it looks like a much better approach than DS-Lite, both for the subscriber and the service provider - as long as you can wait for it a little while. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/
Throw me a IPv6 bone (sort of was IPv6 ignorance)
The part of IPv6 that I am unclear on and have not found much documentation on is how to run IPv6 only to end users. Anyone care to point me in the right direction? Can we assign IPv6 only to end users? What software/equipment do we need in place as a ISP to ensure these customers can reach IPv4 only hosts? The Interwebs are full of advice on setting up IPv6 tunnels for your house (nice but...). There is lots of really old documentation out there for IPv6 mechanisms that are depreciated or didn't fly. What is current best practice? -- Mark Radabaugh Amplex m...@amplex.net 419.837.5015
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
On 2012-09-21 15:31 , Mark Radabaugh wrote: The part of IPv6 that I am unclear on and have not found much documentation on is how to run IPv6 only to end users. Anyone care to point me in the right direction? Can we assign IPv6 only to end users? What software/equipment do we need in place as a ISP to ensure these customers can reach IPv4 only hosts? The Interwebs are full of advice on setting up IPv6 tunnels for your house (nice but...). There is lots of really old documentation out there for IPv6 mechanisms that are depreciated or didn't fly. What is current best practice? The IETF BCP is to deploy Dual Stack, thus both IPv4 and IPv6 at the same time. When that is not possible, as you ran out of IPv4 addresses, you should look at Dual Stack Lite (DS Lite) eg as supplied by ISC's AFTR and other such implementations. Depending on your business model you can of course also stick everybody behind a huge NAT or require them to use HTTP proxies to get to the Internet as most people define it... Do note that if you are asking any of these questions today you are years late in reading up and you missed your chance to be prepared for this in all kinds of ways. Greets, Jeroen
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
On Sep 21, 2012, at 9:31 AM, Mark Radabaugh wrote: The part of IPv6 that I am unclear on and have not found much documentation on is how to run IPv6 only to end users. Anyone care to point me in the right direction? This all depends on how your manage your last-mile and terminate users now. I have a friend with a local WISP here and he gives everyone a /24 out of 172.16/12 and dumps them through his load-balancer for his few connections. His CGN box seems to handle this fine. Can we assign IPv6 only to end users? What software/equipment do we need in place as a ISP to ensure these customers can reach IPv4 only hosts? I would say you want to do dual-stack, but shift the users that don't *need* public IPs into 1918 space and deliver v6 native as feasible. If you have a server lan, you can do this with SLAAC, but to get the other information to your hosts, either via RA's and otherwise, it's just becoming easier to do. PPPo* you can get IPv6 IPCP up and going, but the device has to support it. The Interwebs are full of advice on setting up IPv6 tunnels for your house (nice but...). There is lots of really old documentation out there for IPv6 mechanisms that are depreciated or didn't fly. ASR1K and other devices can serve as nat64.. (I think Juniper does the same, but I don't recall their roadmap/product set). I'm sure you can do it with a Linux or *BSD box as well. What is current best practice? I would say there is none as it largely depends on how you terminate that transport, and there are a few ways one can do that. Hope this helps, - Jared
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
The folks that have done the most work in enabling IPv6-only end users seem to be CERNET2 in China. To let people get to v4, they're using what they call IVI (get it?), which is basically NAT64+DNS64. http://tools.ietf.org/html/rfc6219 http://en.wikipedia.org/wiki/NAT64 If you don't mind running IPv4 in a tunnel over that IPv6 network, you can do DSlite or 4rd http://tools.ietf.org/html/rfc6333 http://tools.ietf.org/html/draft-despres-intarea-4rd-01 http://en.wikipedia.org/wiki/IPv6_transition_mechanisms#Dual-Stack_Lite_.28DS-Lite.29 On Friday, September 21, 2012, Mark Radabaugh wrote: The part of IPv6 that I am unclear on and have not found much documentation on is how to run IPv6 only to end users. Anyone care to point me in the right direction? Can we assign IPv6 only to end users? What software/equipment do we need in place as a ISP to ensure these customers can reach IPv4 only hosts? The Interwebs are full of advice on setting up IPv6 tunnels for your house (nice but...). There is lots of really old documentation out there for IPv6 mechanisms that are depreciated or didn't fly. What is current best practice? -- Mark Radabaugh Amplex m...@amplex.net 419.837.5015
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
On 9/21/12 6:40 AM, Jeroen Massar wrote: On 2012-09-21 15:31 , Mark Radabaugh wrote: The part of IPv6 that I am unclear on and have not found much documentation on is how to run IPv6 only to end users. Anyone care to point me in the right direction? Can we assign IPv6 only to end users? What software/equipment do we need in place as a ISP to ensure these customers can reach IPv4 only hosts? The Interwebs are full of advice on setting up IPv6 tunnels for your house (nice but...). There is lots of really old documentation out there for IPv6 mechanisms that are depreciated or didn't fly. What is current best practice? The IETF BCP is to deploy Dual Stack, thus both IPv4 and IPv6 at the same time. That's likely to be congruent with the expectations of residential customers but it's not the sole model we've seen, at some point IPv4 backward compatibility plays second fiddle to your ipv6 deployment. the alternatives do get discussed, e.g. http://tools.ietf.org/html/rfc6180 When that is not possible, as you ran out of IPv4 addresses, you should look at Dual Stack Lite (DS Lite) eg as supplied by ISC's AFTR and other such implementations. Depending on your business model you can of course also stick everybody behind a huge NAT or require them to use HTTP proxies to get to the Internet as most people define it... Do note that if you are asking any of these questions today you are years late in reading up and you missed your chance to be prepared for this in all kinds of ways. Greets, Jeroen
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
On 9/21/12 9:40 AM, Jeroen Massar wrote: On 2012-09-21 15:31 , Mark Radabaugh wrote: The part of IPv6 that I am unclear on and have not found much documentation on is how to run IPv6 only to end users. Anyone care to point me in the right direction? Can we assign IPv6 only to end users? What software/equipment do we need in place as a ISP to ensure these customers can reach IPv4 only hosts? The Interwebs are full of advice on setting up IPv6 tunnels for your house (nice but...). There is lots of really old documentation out there for IPv6 mechanisms that are depreciated or didn't fly. What is current best practice? The IETF BCP is to deploy Dual Stack, thus both IPv4 and IPv6 at the same time. When that is not possible, as you ran out of IPv4 addresses, you should look at Dual Stack Lite (DS Lite) eg as supplied by ISC's AFTR and other such implementations. Depending on your business model you can of course also stick everybody behind a huge NAT or require them to use HTTP proxies to get to the Internet as most people define it... Do note that if you are asking any of these questions today you are years late in reading up and you missed your chance to be prepared for this in all kinds of ways. Greets, Jeroen We can already do dual stack - that's not really a problem. I was really rather hoping to avoid the giant NAT box. I'll take a look at DS Lite and or NAT64/DNS64 and see if that makes any sense. Dual stack isn't all that hard to deploy in the enterprise, perhaps even IPv6 only with NAT for backward compatibility. Running dual stack to residential consumers still has huge issues with CPE. It's not an environment where we have control over the router the customer picks up at Walmart. There is really very little point in spending a lot of resources on something the consumer can't currently use. I don't think saying we missed the boat really applies - and the consumer CPE ship is sinking at the dock. -- Mark Radabaugh Amplex m...@amplex.net 419.837.5015
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
Op 21-9-2012 21:42, Mark Radabaugh schreef: Running dual stack to residential consumers still has huge issues with CPE. It's not an environment where we have control over the router the customer picks up at Walmart. There is really very little point in spending a lot of resources on something the consumer can't currently use. I don't think saying we missed the boat really applies - and the consumer CPE ship is sinking at the dock. Enable dual stack per default, the old routers ignore it anyhow. The new ones that do support it, and really, Linksys and D-Link as well as Netgear do support it now will use it and should just work. I recommend DHCP-PD, it seems to work well with relatively low overhead. AVM seems to know just how to make these relatively cheap all-in-ones with a great feature set and reasonable quality. There is a lot of room for improvement, there always have been. It's not like the original Linksys WRT54G was really _that_ good, was it? The other good news is that there is a new Wifi standard! You'll see a new surge of people swapping out 30$ routers because they are convinced that the new 30$ router will be a lot better then the previous one. Maybe it is. I know it's a chicken and egg problem, and shoving it out further means you just decided for the ISP that you need a far beefier CGN box in the future. I am not totally convinced that was your long term plan. Most ISPs in asia that are now pouring significant monetary resources into a CGN box that might be almost pointless in 5 years is not the investment they were looking for.
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
On Fri, 21 Sep 2012 15:42:20 -0400, Mark Radabaugh said: Running dual stack to residential consumers still has huge issues with CPE. It's not an environment where we have control over the router the customer picks up at Walmart. There is really very little point in spending a lot of resources on something the consumer can't currently use. You *do* realize that the reason my site runs like 60% IPv6 traffic *now* is because we spend the resources 5 and 10 years ago getting ready for when Microsoft and Apple shipped stuff that worked for the end user, right? Of course, if you want to wait to get *started* on the deployment curve until everybody's replaced their stuff, that's fine by me. But I'd double-check if you have any competitors that have an earlier schedule. pgpWeTzEVALKZ.pgp Description: PGP signature
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
Running dual stack to residential consumers still has huge issues with CPE. It's not an environment where we have control over the router the customer picks up at Walmart. There is really very little point in spending a lot of resources on something the consumer can't currently use. Note: Some of us regular, residential customers can and do have native IPv6 at home ... off the shelf gear, default configs, etc.
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
On Fri, 21 Sep 2012 19:22:18 -0400, TJ said: Running dual stack to residential consumers still has huge issues with CPE. It's not an environment where we have control over the router the customer picks up at Walmart. There is really very little point in spending a lot of resources on something the consumer can't currently use. Note: Some of us regular, residential customers can and do have native IPv6 at home ... off the shelf gear, default configs, etc. But you have to admit it works a lot better if you're a customer of an ISP that isn't waiting to spend the resources... :) pgpUScnDkORu5.pgp Description: PGP signature
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
Dhcpv6, radius .. take your pick --srs (htc one x) On Sep 21, 2012 7:04 PM, Mark Radabaugh m...@amplex.net wrote: The part of IPv6 that I am unclear on and have not found much documentation on is how to run IPv6 only to end users. Anyone care to point me in the right direction? Can we assign IPv6 only to end users? What software/equipment do we need in place as a ISP to ensure these customers can reach IPv4 only hosts? The Interwebs are full of advice on setting up IPv6 tunnels for your house (nice but...). There is lots of really old documentation out there for IPv6 mechanisms that are depreciated or didn't fly. What is current best practice? -- Mark Radabaugh Amplex m...@amplex.net 419.837.5015
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
On 22/09/2012, at 12:04 AM, Jared Mauch ja...@puck.nether.net wrote: Can we assign IPv6 only to end users? What software/equipment do we need in place as a ISP to ensure these customers can reach IPv4 only hosts? I would say you want to do dual-stack, but shift the users that don't *need* public IPs into 1918 space and deliver v6 native as feasible. If you have a server lan, you can do this with SLAAC, but to get the other information to your hosts, either via RA's and otherwise, it's just becoming easier to do No. Use RFC 6598 space which was allocated for this purpose. Mark
Re: IPv6 Burgers (was: IPv6 Ignorance)
On 2012-09-17 13:48, Richard Brown wrote: Another measure of the size of the IPv6 address space... Back on World IPv6 Day in June 2011, Dartware had a barbecue. (Why? Because the burgers had 128 (bacon) bits and we served IP(A) to drink :-) You can see some photos at: http://www.networkworld.com/community/blog/scenes-ipv6-day-barbecue But we came up with another interesting measure for the vastness of the IPv6 address space: If an IPv4 hamburger patty has 2^32 (4.2 billion) unique addresses in its 1/4 inch thickness, how thick would an IPv6 hamburger be (with 2^128 unique addresses)? The answer is... 53 billion light-years. Just got to playing with this today, trying to put it in some sort of perspective. First off, lets bring that down to human-sized numbers, using standard units used in astronomy: 2^94 inches = 16 gigaparsecs + 304 megaparsecs + 322 kiloparsecs + 752 parsecs + 2 lightyears + 57101 au + 23233 earthradius (Gigaparsecs isn't very common, but that's because it's a bit big.) So... How big is that? What can we compare it to? Well, let's start at the top: does this thing actually fit in our universe? The size of the observable universe is set by the Hubble Constant and lightspeed: The Hubble Constant is the rate of growth of expansion in the universe - the redshift phenomena. The further away you look, the faster things are moving away from us. At a certain point, they are moving away from us faster than light, meaning that light coming from them would never reach us. That's about 14 gigaparsecs away. (Adjusting for such things as how much they will have moved since you measured them. There's a whole rabbit hole to go down for this, on Wikipedia alone.) Which means the observable universe is about 28 gigaprsecs across. (Now you can see why gigaparsecs isn't a common unit.) So our hamburger patty would fit inside it - but you wouldn't be able to see one end from the other. Ever. In fact, while someone at the center could reach either end, once they got there they'd never be able to reach the other. They wouldn't even be able to get back to where they started. Which of course means that even if you ate at lightspeed, you'd never be able to eat it. (Oh, and if it still has a radius of 3 inches - standard 1/4 pound burger at 1/4 inch thick - it's got a volume around that of 11,000 Earths, and a mass of about 1,400 Earths, about 4.6 times the mass of Jupiter.) It's straightforward unit conversions. There are 2^96 IPv4 Hamburgers at a quarter-inch apiece. That's 2^96 inches/4 (2^94 inches). Switching to decimal units, 1.98x10^32 inches; 1.65x10^27 feet; 3.13x10^23 miles; and then continuing to convert to light-years. A good tool for this kind of wacky unit conversion is Frink (http://futureboy.us/fsp/frink.fsp?fromVal=2%5E94+inchestoVal=lightyears), which can do this in one shot. Simply enter: I prefer the 'units' program, which is usually a standard utility on Unix-like boxes. (If not in your distro of choice, finding the GNU or BSD versions is left as an exercise for the reader. ;) ) Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ---
Re: IPv6 Burgers (was: IPv6 Ignorance)
On Mon, Sep 17, 2012 at 1:48 PM, Richard Brown richard.e.br...@dartware.com wrote: Another measure of the size of the IPv6 address space... Back on World IPv6 Day in June 2011, Dartware had a barbecue. (Why? Because the burgers had 128 (bacon) bits and we served IP(A) to drink :-) You can see some photos at: http://www.networkworld.com/community/blog/scenes-ipv6-day-barbecue But we came up with another interesting measure for the vastness of the IPv6 address space: If an IPv4 hamburger patty has 2^32 (4.2 billion) unique addresses in its 1/4 inch thickness, how thick would an IPv6 hamburger be (with 2^128 unique addresses)? The answer is... 53 billion light-years. Interesting. If a teeny dot of gristle at the edge of the patty is an IPv4 /28 LAN and the same LAN is /64 in IPv6, how big is IPv6 now? The 1/4 inch patty holds all the IPv4 LANs whose IPv4 capacity I'm calling 2^28. IPv6's in principle has 2^64 LANs, so an increase of 2^36 LANs. Patty was 1/4 inch, so our IPv6 patty is 2^32 inches or about 10 billionths of a lightyear. 68,000 miles, a little over a quarter of the distance to the moon. That's a big burger. But not so big as you thought. By 17 orders of magnitude. In point of fact, a mere 150,000 people put together will eat all that beef in their lifetimes. But for the distribution problem, the world population could chew through it in half a day. Worse, that's if we were managing IPv6 delegations the way we manage IPv4 delegations. We're not. We're using sparse allocation. And 6RD. And default customer allocations of 65,000 LANs. And other interesting stuff that drastically increases the consumption characteristics. Nice burger. Om nom nom nom. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: IPv6 Burgers (was: IPv6 Ignorance)
On Thu, Sep 20, 2012 at 4:29 PM, William Herrin b...@herrin.us wrote: The 1/4 inch patty holds all the IPv4 LANs whose IPv4 capacity I'm calling 2^28. IPv6's in principle has 2^64 LANs, so an increase of 2^36 LANs. Patty was 1/4 inch, so our IPv6 patty is 2^32 inches or about 10 billionths of a lightyear. 68,000 miles, a little over a quarter of the distance to the moon. 2^34, my bad. So you get a full moon burger out of it. -Bill -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: IPv6 Burgers (was: IPv6 Ignorance)
In message cap-gugvaksokeqevx7ayseyqrr7g2erreaasxnwayabqpqm...@mail.gmail.com, W illiam Herrin writes: Worse, that's if we were managing IPv6 delegations the way we manage IPv4 delegations. We're not. We're using sparse allocation. And 6RD. And default customer allocations of 65,000 LANs. And other interesting stuff that drastically increases the consumption characteristics. 6rd can be dense as native deployment. In fact it is not hard to do so and if you are using the shared /10 just allocated or RFC 1918 between you and your customers more than once simple map all of IPv4 space does not work. RFC 5969 does NOT say you must use 32 bits and actually lots of examples where it isn't done. Nice burger. Om nom nom nom. Regards, Bill Herrin --=20 William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 Burgers (was: IPv6 Ignorance)
On Thu, Sep 20, 2012 at 7:50 PM, Mark Andrews ma...@isc.org wrote: In message cap-gugvaksokeqevx7ayseyqrr7g2erreaasxnwayabqpqm...@mail.gmail.com, W illiam Herrin writes: Worse, that's if we were managing IPv6 delegations the way we manage IPv4 delegations. We're not. We're using sparse allocation. And 6RD. And default customer allocations of 65,000 LANs. And other interesting stuff that drastically increases the consumption characteristics. 6rd can be dense as native deployment. In fact it is not hard to Have you heard the one about the difference between theory and practice? Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: IPv6 Ignorance
On Mon, Sep 17, 2012 at 2:16 PM, Owen DeLong o...@delong.com wrote: We thought 32 bits was humongous in the context of a research project that would connect universities, research institutions and some military installations. In that context, 32 bits would still be humongous. Our estimation of humongous didn't change, the usage of the network changed dramatically. The experiment escaped from the laboratory and took on a life of its own. Once that happened, the realization that 32 bits wasn't enough was very nearly immediate. The IPv6 address space offers 61 bits of network numbers each of which holds up to 64 bits worth of hosts. Obviously you never want to fill one of those subnets (nor could you with any available hardware), but it means that you don't have to waste time thinking about rightsizing network assignments. Hi Owen, We think 64 bits is humongous on an IPv4 Internet where autoconfiguration is rarely bordering never larger than a single LAN. But, we want the fridge to get a /64 from the home automation controller for its internal sensor network. Which means the home automation controller will be holding something around a /58 or so in order to accommodate the various smart devices in the house. Which means the the cable router will be holding a /54 or more to accommodate the server lan, the home automation delegation, the PC lan, the VM delegation, the wifi lan, etc. And at a customer boundary we'll only break at a nibble boundary, so that brings us to /52. Which is inconvenient since we often have larger users so we'll just break at /48 for everybody. Then we need 32 bits to overlay the customer's IPv4 address for convenience within our 6RD network. So that leaves us 16 bits. But we don't want the native network to overlay the 6RD network because we want a real simple /16 route into the nearest 6rd encapsulator. And we don't want to advertise multiple BGP prefixes either. So we claim another bit and allocate our native infrastructure from the /16 that doesn't overlap the 6rd setup. 3 bits are held in reserve at the top; only 2000::/3 is available for public Internet use. So that drops us from 15 to 12 bits. Now we want to organize the BGP backbone and we've 12 bits left to work with. That's 4 bits less than the number of autonomous systems participating in BGP on Internet today. Of course this is in many ways a straw man. And I'm picking on you Owen because in the past you've advocated both /48's for end users and 6rd justifying 32 bits of allocation above that from the registry. But really, with the right (or maybe I mean wrong) hierarchic network auto-configuration technologies it's not hard to imagine how the IPv6 address space could be exhausted in 20 years. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: IPv6 Ignorance
Seth Mattinen se...@rollernet.us writes: I came across these threads today; the blind ignorance towards IPv6 from some of the posters is kind of shocking. There are actually a few good points mixed in there, like the guy who observes that dual stacking is of limited utility if there are no v4 addresses to be had. I keep performing this vendor monologue. It goes something like: What do I mean when I say it must support IPv6? I mean two things. First, full feature parity with IPv4. Everything that works under IPv4 must work under IPv6. If you have exceptions, you'd better document them and have a remediation plan (or work-around if it is a deficiency baked into the standard; there are a few of which I'm aware). Second, the device must function perfectly in an IPv6-only environment, with not a hint of IPv4 addressing around. Dual-stack capability is nice, but should be an easy thing to provide if you can handle the first two requirements. Furious scribbling in the 'ol Moleskine invariably ensues. I am not sure what it is about this set of requirements (which seems so plain to see that I felt as if I was belaboring the obvious the first time I brought it up) that seems like a revelation to people in the vendor space, but apparently it does. Are *you* doing *your* part? Taken your shoe off and banged it on the conference room table Khrushchev-style lately? -r
Re: IPv6 Ignorance
On Sep 17, 2012, at 23:35 , William Herrin b...@herrin.us wrote: On Mon, Sep 17, 2012 at 2:16 PM, Owen DeLong o...@delong.com wrote: We thought 32 bits was humongous in the context of a research project that would connect universities, research institutions and some military installations. In that context, 32 bits would still be humongous. Our estimation of humongous didn't change, the usage of the network changed dramatically. The experiment escaped from the laboratory and took on a life of its own. Once that happened, the realization that 32 bits wasn't enough was very nearly immediate. The IPv6 address space offers 61 bits of network numbers each of which holds up to 64 bits worth of hosts. Obviously you never want to fill one of those subnets (nor could you with any available hardware), but it means that you don't have to waste time thinking about rightsizing network assignments. Hi Owen, We think 64 bits is humongous on an IPv4 Internet where autoconfiguration is rarely bordering never larger than a single LAN. But, we want the fridge to get a /64 from the home automation controller for its internal sensor network. Which means the home automation controller will be holding something around a /58 or so in order to accommodate the various smart devices in the house. Which means the the cable router will be holding a /54 or more to accommodate the server lan, the home automation delegation, the PC lan, the VM delegation, the wifi lan, etc. And at a customer boundary we'll only break at a nibble boundary, so that brings us to /52. Which is inconvenient since we often have larger users so we'll just break at /48 for everybody. Correct. Then we need 32 bits to overlay the customer's IPv4 address for convenience within our 6RD network. So that leaves us 16 bits. But we don't want the native network to overlay the 6RD network because we want a real simple /16 route into the nearest 6rd encapsulator. And we don't want to advertise multiple BGP prefixes either. So we claim another bit and allocate our native infrastructure from the /16 that doesn't overlap the 6rd setup. No, you really don't. This absurdity (and the ridiculous design of 6RD) are so problematic in this area that I cannot begin to describe what a terrible idea it is. 3 bits are held in reserve at the top; only 2000::/3 is available for public Internet use. So that drops us from 15 to 12 bits. Now we want to organize the BGP backbone and we've 12 bits left to work with. That's 4 bits less than the number of autonomous systems participating in BGP on Internet today. Again, if you take the 6RD mess out of the equation and don't saddle IPv6 with this IPv4 baggage, this is a non-issue. Of course this is in many ways a straw man. And I'm picking on you Owen because in the past you've advocated both /48's for end users and 6rd justifying 32 bits of allocation above that from the registry. But really, with the right (or maybe I mean wrong) hierarchic network auto-configuration technologies it's not hard to imagine how the IPv6 address space could be exhausted in 20 years. I still advocate /48s and I have never advocated 6RD as a permanent solution, nor have I advocated giving ISPs /16s in support of 6RD. I have supported policy to allow for temporary allocations in support of 6RD giving customers more limited (/56) prefixes due to the constraints of 6RD, however, I have consistently referred to this as a degraded form of IPv6. Owen
Re: IPv6 Ignorance
On Tue, Sep 18, 2012 at 9:21 AM, Robert E. Seastrom r...@seastrom.com wrote: What do I mean when I say it must support IPv6? I mean two things. First, full feature parity with IPv4. Everything that works under IPv4 must work under IPv6. If you have exceptions, you'd better document them and have a remediation plan (or work-around if it is a deficiency baked into the standard; there are a few of which I'm aware). Second, the device must function perfectly in an IPv6-only environment, with not a hint of IPv4 addressing around. Dual-stack capability is nice, but should be an easy thing to provide if you can handle the first two requirements. Well spoken RS, I'm cutting and pasting this one to my account team(s). Far too many discussions about this with them recently. (really, you're just *now* getting v6 to work on bundled interfaces?) -Steve
Re: IPv6 Ignorance
On Sep 18, 2012, at 10:58 AM, Steve Meuse sme...@mara.org wrote: On Tue, Sep 18, 2012 at 9:21 AM, Robert E. Seastrom r...@seastrom.com wrote: What do I mean when I say it must support IPv6? I mean two things. First, full feature parity with IPv4. Everything that works under IPv4 must work under IPv6. If you have exceptions, you'd better document them and have a remediation plan (or work-around if it is a deficiency baked into the standard; there are a few of which I'm aware). Second, the device must function perfectly in an IPv6-only environment, with not a hint of IPv4 addressing around. Dual-stack capability is nice, but should be an easy thing to provide if you can handle the first two requirements. Well spoken RS, I'm cutting and pasting this one to my account team(s). Far too many discussions about this with them recently. (really, you're just *now* getting v6 to work on bundled interfaces?) We've been doing this for years on both Juniper IOS/IOS-XR devices. Must be someone else. We do run into this whole feature parity thing often. The vendors seem to be challenged in this space. I suspect a significant part of it is they don't actually *use* IPv6 internally or in their lab. We have been operating our network with IPv6 for many years now. I believe in most cases our connection to the management plane go IPv6 only as well. It's been fun to see the few SSH over IPv6 defects and other elements arise as time has passed, but those days are over. It's just tiring now and no longer amusing. (hey you kids, get off my lawn?). - Jared
Re: IPv6 Ignorance
On Tue, Sep 18, 2012 at 11:08 AM, Jared Mauch ja...@puck.nether.net wrote: We've been doing this for years on both Juniper IOS/IOS-XR devices. Must be someone else. I may be wrong, but IOS-XR on A9K only supported v6 on bundle-ether interfaces as of 4.1.2-ish. That, of course, leads to the conversation of keeping function parity between same software revs but different hardware platforms. I understand the issues there, but doesn't make deploying a feature any easier -Steve
Re: IPv6 Ignorance
It was supported before there. We were using it prior to that release. You needed a smu though. I can perhaps find details if they are that important for you. Jared Mauch On Sep 18, 2012, at 11:24 AM, Steve Meuse sme...@mara.org wrote: On Tue, Sep 18, 2012 at 11:08 AM, Jared Mauch ja...@puck.nether.net wrote: We've been doing this for years on both Juniper IOS/IOS-XR devices. Must be someone else. I may be wrong, but IOS-XR on A9K only supported v6 on bundle-ether interfaces as of 4.1.2-ish. That, of course, leads to the conversation of keeping function parity between same software revs but different hardware platforms. I understand the issues there, but doesn't make deploying a feature any easier -Steve
Re: IPv6 Ignorance
On Tue, 18 Sep 2012 02:35:43 -0400, William Herrin said: Then we need 32 bits to overlay the customer's IPv4 address for convenience within our 6RD network. Well yeah. You blow 32 bits for silly reasons, you run out of bits. Film at 11. pgpvFDJ2NdnzN.pgp Description: PGP signature
Re: IPv6 Ignorance
On 09/18/2012 08:08 AM, Jared Mauch wrote: We've been doing this for years on both Juniper IOS/IOS-XR devices. Must be someone else. We do run into this whole feature parity thing often. The vendors seem to be challenged in this space. I suspect a significant part of it is they don't actually *use* IPv6 internally or in their lab. We have been operating our network with IPv6 for many years now. I believe in most cases our connection to the management plane go IPv6 only as well. It's been fun to see the few SSH over IPv6 defects and other elements arise as time has passed, but those days are over. It's just tiring now and no longer amusing. (hey you kids, get off my lawn?). Of course they're challenged. There's a finite amount of dev they can do at any one time, and they go for what is going to make revenue. If you tell them that the way to your wallet is to implement some new feature in v4 and you're not emphatic that it be v6 also, they are going to do the utterly predictable thing. If you really want to make progress instead of bellyache, list off the features you need to run your network. Better yet, deploy v6 instead of saying that you'll only do it when it's perfect. That just tells your account critter that v6 isn't important to you. I'll bet you'll find features that you want that are v6 specific that you'd open your wallet for *way* before features that don't interest you that you're requiring in the name of parity. Mike
RE: IPv6 Ignorance
Orbits may not be important to this calculation, but just doing some quick head math, I believe large skyscrapers could already have close to this concentration of addresses, if you reduce them down to flat earth surface area. The point here is that breaking out the math based on the surface area of the earth is silly, as we do not utilize the surface of the earth in a flat manner... Davis Beeman On Mon, Sep 17, 2012 at 11:27:04AM -0700, Owen DeLong wrote: What technology are you planning to deploy that will consume more than 2 addresses per square cm? Easy. Think volume (as in: orbit), and think um^3 for a functional computers ;) I meant real-world application. Orbits are limited due to the required combination of speed and altitude. There are a limited number of achievable altitudes and collision avoidance also creates interesting problems in time-slotting for orbits which are not geostationary. Geostationary orbits are currently limited to one object per degree of earth surface, and even at 4x that, you could give every satellite a /48 and still not burn through a /32. Owen
Re: IPv6 Ignorance
H On Sep 18, 2012, at 11:01 AM, Beeman, Davis davis.bee...@integratelecom.com wrote: Orbits may not be important to this calculation, but just doing some quick head math, I believe large skyscrapers could already have close to this concentration of addresses, if you reduce them down to flat earth surface area. The point here is that breaking out the math based on the surface area of the earth is silly, as we do not utilize the surface of the earth in a flat manner... Davis Beeman On Mon, Sep 17, 2012 at 11:27:04AM -0700, Owen DeLong wrote: What technology are you planning to deploy that will consume more than 2 addresses per square cm? Easy. Think volume (as in: orbit), and think um^3 for a functional computers ;) I meant real-world application. Orbits are limited due to the required combination of speed and altitude. There are a limited number of achievable altitudes and collision avoidance also creates interesting problems in time-slotting for orbits which are not geostationary. Geostationary orbits are currently limited to one object per degree of earth surface, and even at 4x that, you could give every satellite a /48 and still not burn through a /32. Owen I wonder if the medical applications of addressing each cell isn't too far off. One could individually group each organ and system in a separate /48 and potentially get a /32... Just imagine the fun of that OID tree. -- Dan Wood
Re: IPv6 Ignorance
On 9/18/2012 11:01 AM, Beeman, Davis wrote: Orbits may not be important to this calculation, but just doing some quick head math, I believe large skyscrapers could already have close to this concentration of addresses, if you reduce them down to flat earth surface area. The point here is that breaking out the math based on the surface area of the earth is silly, as we do not utilize the surface of the earth in a flat manner... Davis Beeman On Mon, Sep 17, 2012 at 11:27:04AM -0700, Owen DeLong wrote: What technology are you planning to deploy that will consume more than 2 addresses per square cm? Easy. Think volume (as in: orbit), and think um^3 for a functional computers ;) I meant real-world application. Orbits are limited due to the required combination of speed and altitude. There are a limited number of achievable altitudes and collision avoidance also creates interesting problems in time-slotting for orbits which are not geostationary. Geostationary orbits are currently limited to one object per degree of earth surface, and even at 4x that, you could give every satellite a /48 and still not burn through a /32. Owen What about network-based objects outside of our orbit? If we're talking about IPv6 in the long-term, I think we have to assume we'll have networked devices on the moon or at other locations in space. Jason
Re: IPv6 Ignorance
On Sep 18, 2012, at 12:38 PM, Jason Baugher ja...@thebaughers.com wrote: What about network-based objects outside of our orbit? If we're talking about IPv6 in the long-term, I think we have to assume we'll have networked devices on the moon or at other locations in space. Jason Practical considerations (mostly latency issues) tend to minimize real-time point-to-point connections in these scenarios. I would expect that messaging/relay gateways would play a significant role in Really-Wide Area Networking. This would move inter-networking largely to an application layer, not the network layer. Thus, worrying about Layer 3 addressing limits is probably moot and just a fun waste of NANOG list bandwidth. James R. Cutler james.cut...@consultant.com
Re: IPv6 Ignorance
On 9/18/2012 11:47 AM, Cutler James R wrote: On Sep 18, 2012, at 12:38 PM, Jason Baugher ja...@thebaughers.com wrote: What about network-based objects outside of our orbit? If we're talking about IPv6 in the long-term, I think we have to assume we'll have networked devices on the moon or at other locations in space. Jason Practical considerations (mostly latency issues) tend to minimize real-time point-to-point connections in these scenarios. I would expect that messaging/relay gateways would play a significant role in Really-Wide Area Networking. This would move inter-networking largely to an application layer, not the network layer. Thus, worrying about Layer 3 addressing limits is probably moot and just a fun waste of NANOG list bandwidth. James R. Cutler james.cut...@consultant.com Considering the rather extensive discussion on this list of using quantum entanglement as a possible future communications medium that would nearly eliminate latency, I don't see how my comment is moot or a waste. Jason
Re: IPv6 Ignorance
On Sep 18, 2012, at 12:57 PM, Jason Baugher ja...@thebaughers.com wrote: On 9/18/2012 11:47 AM, Cutler James R wrote: On Sep 18, 2012, at 12:38 PM, Jason Baugher ja...@thebaughers.com wrote: What about network-based objects outside of our orbit? If we're talking about IPv6 in the long-term, I think we have to assume we'll have networked devices on the moon or at other locations in space. Jason Practical considerations (mostly latency issues) tend to minimize real-time point-to-point connections in these scenarios. I would expect that messaging/relay gateways would play a significant role in Really-Wide Area Networking. This would move inter-networking largely to an application layer, not the network layer. Thus, worrying about Layer 3 addressing limits is probably moot and just a fun waste of NANOG list bandwidth. James R. Cutler james.cut...@consultant.com Considering the rather extensive discussion on this list of using quantum entanglement as a possible future communications medium that would nearly eliminate latency, I don't see how my comment is moot or a waste. Jason Recent work (http://www.quantum.at/quest) has not yet established success over interplanetary distances. Other recent results from aircraft (http://www.extremetech.com/extreme/136312-first-air-to-ground-quantum-network-created-transmits-quantum-crypto-keys) show throughput results in relatively small bits per second. I'll reserve retraction for another year or so.
Re: IPv6 Ignorance
On 9/18/2012 12:07 PM, Cutler James R wrote: On Sep 18, 2012, at 12:57 PM, Jason Baugher ja...@thebaughers.com wrote: On 9/18/2012 11:47 AM, Cutler James R wrote: On Sep 18, 2012, at 12:38 PM, Jason Baugher ja...@thebaughers.com wrote: What about network-based objects outside of our orbit? If we're talking about IPv6 in the long-term, I think we have to assume we'll have networked devices on the moon or at other locations in space. Jason Practical considerations (mostly latency issues) tend to minimize real-time point-to-point connections in these scenarios. I would expect that messaging/relay gateways would play a significant role in Really-Wide Area Networking. This would move inter-networking largely to an application layer, not the network layer. Thus, worrying about Layer 3 addressing limits is probably moot and just a fun waste of NANOG list bandwidth. James R. Cutler james.cut...@consultant.com Considering the rather extensive discussion on this list of using quantum entanglement as a possible future communications medium that would nearly eliminate latency, I don't see how my comment is moot or a waste. Jason Recent work (http://www.quantum.at/quest) has not yet established success over interplanetary distances. Other recent results from aircraft (http://www.extremetech.com/extreme/136312-first-air-to-ground-quantum-network-created-transmits-quantum-crypto-keys) show throughput results in relatively small bits per second. I'll reserve retraction for another year or so. And last time I checked, IPv6 wasn't supposed to be designed to last for just another year or so. If we're expecting any kind of longevity out of IPv6, we need to expect that technology will solve these problems and plan for it. I'd rather not be sitting here 10 years from now wondering why I'm dual-stacking IPv7 on top of IPv6 because we didn't plan far enough ahead. Jason
Re: IPv6 Ignorance
On Tue, Sep 18, 2012 at 9:47 AM, Cutler James R wrote: ...waste of NANOG list bandwidth. I sure get a chuckle when I read this on a list for people that swing around 10Gb/s pipes all day. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474
Re: IPv6 Ignorance
On Sep 18, 2012, at 1:55 PM, Joe Hamelin j...@nethead.com wrote: On Tue, Sep 18, 2012 at 9:47 AM, Cutler James R wrote: ...waste of NANOG list bandwidth. I sure get a chuckle when I read this on a list for people that swing around 10Gb/s pipes all day. That's why I included a word you omitted from the quote -- …fun waste of NANOG list bandwidth. Works for me. Works for you. James R. Cutler james.cut...@consultant.com
Re: IPv6 Ignorance
On Tue, Sep 18, 2012 at 11:57:34AM -0500, Jason Baugher wrote: Considering the rather extensive discussion on this list of using quantum entanglement as a possible future communications medium that would nearly eliminate latency, I don't see how my comment is moot or a waste. You need a relativistic channel to be able to tell quantum signal from randomness.
Re: IPv6 Ignorance
In message 86lig7cvpw@seastrom.com, Robert E. Seastrom writes: Seth Mattinen se...@rollernet.us writes: I came across these threads today; the blind ignorance towards IPv6 from some of the posters is kind of shocking. There are actually a few good points mixed in there, like the guy who observes that dual stacking is of limited utility if there are no v4 addresses to be had. Dual stack w/ CGN for IPv4. That can be supplied a number of ways and it has more limitations for IPv4 that conventional CPE based NAT. Turning on dual stack, even at this late stage, lights up IPv6, moves most of the traffic to IPv6 so that CGN's don't need to be so beefy, and doesn't mean that you have to have perfect IPv6 everywhere when you turn on IPv6. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 Ignorance
On Tue, Sep 18, 2012 at 11:39 AM, valdis.kletni...@vt.edu wrote: On Tue, 18 Sep 2012 02:35:43 -0400, William Herrin said: Then we need 32 bits to overlay the customer's IPv4 address for convenience within our 6RD network. Well yeah. You blow 32 bits for silly reasons, you run out of bits. Film at 11. Silly reason? Hardly! 6RD lets you deploy IPv6 immediately to all customers. It's a stateless tunnel. Direct the packets into an encapsulator and any customer who wants them need only catch them on their IPv4 address. Without you having to change out anything else in your network. Hitch is: if you have a whole lot of discontiguous IPv4 prefixes, sorting which maps to where in a compact IPv6 prefix is challenging. Much easier to just map the entire IPv4 space and be done with it. Poor plan. But much easier. On Tue, Sep 18, 2012 at 10:01 AM, Owen DeLong o...@delong.com wrote: Then we need 32 bits to overlay the customer's IPv4 address for convenience within our 6RD network. So that leaves us 16 bits. But we don't want the native network to overlay the 6RD network because we want a real simple /16 route into the nearest 6rd encapsulator. And we don't want to advertise multiple BGP prefixes either. So we claim another bit and allocate our native infrastructure from the /16 that doesn't overlap the 6rd setup. No, you really don't. This absurdity (and the ridiculous design of 6RD) are so problematic in this area that I cannot begin to describe what a terrible idea it is. In http://lists.arin.net/pipermail/arin-ppml/2010-September/018180.html I complained about mapping the full 32-bits of IPv4 address into an IPv6 prefix. You responded, You say that like it's somehow a bad thing, and I'm simply not seeing a problem. Have you come around to my way of thinking that using 6RD with a full 32-bit IPv4 mapping is not such a hot idea? Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: IPv6 Ignorance
On Tue, 18 Sep 2012 18:18:28 -0400, William Herrin said: In http://lists.arin.net/pipermail/arin-ppml/2010-September/018180.html I complained about mapping the full 32-bits of IPv4 address into an IPv6 prefix. You responded, You say that like it's somehow a bad thing, and I'm simply not seeing a problem. Have you come around to my way of thinking that using 6RD with a full 32-bit IPv4 mapping is not such a hot idea? They're not in contradiction - you want a /28 so you can do 6RD, ARIN should let you do that. You want a /28 so you can do a non-6RD network plan, you should be allowed to do that too. But you don't get to deploy 6RD, and then complain that you don't have enough bits left when you try to do a non-6RD design. Or you could be a bit smarter and realize that you probably only actually *need* to use 16 or 20 bits of address for 6RD mapping and leave yourself 16 or 12 for other uses. AS1312 has 2 /16s, so we only need to map 16 bits of address and one more to indicate which /16 it was and the rest can be implicit. Which of course still loses if you have more than a /8 or so, or if you have 1,495 little prefixes that are scattered all over the /0 pgpmHhEZMFc8y.pgp Description: PGP signature
Re: IPv6 Ignorance
In message 34689.1348009...@turing-police.cc.vt.edu, valdis.kletni...@vt.edu wri tes: --==_Exmh_1348009609_2143P Content-Type: text/plain; charset=us-ascii On Tue, 18 Sep 2012 18:18:28 -0400, William Herrin said: In http://lists.arin.net/pipermail/arin-ppml/2010-September/018180.html I complained about mapping the full 32-bits of IPv4 address into an IPv6 prefix. You responded, You say that like it's somehow a bad thing, and I'm simply not seeing a problem. Have you come around to my way of thinking that using 6RD with a full 32-bit IPv4 mapping is not such a hot idea? They're not in contradiction - you want a /28 so you can do 6RD, ARIN should let you do that. You want a /28 so you can do a non-6RD network plan, you should be allowed to do that too. But you don't get to deploy 6RD, and then complain that you don't have enough bits left when you try to do a non-6RD design. Or you could be a bit smarter and realize that you probably only actually *need* to use 16 or 20 bits of address for 6RD mapping and leave yourself 16 or 12 for other uses. AS1312 has 2 /16s, so we only need to map 16 bits of address and one more to indicate which /16 it was and the rest can be implicit. Which o f course still loses if you have more than a /8 or so, or if you have 1,495 little prefixes that are scattered all over the /0 But given that 6rd is DHCP this is all fixed with a little bit of programming. It's not like it's new stuff anyway. It also only has to be done once for each address block. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 Ignorance
On Sep 18, 2012, at 09:38 , Jason Baugher ja...@thebaughers.com wrote: On 9/18/2012 11:01 AM, Beeman, Davis wrote: Orbits may not be important to this calculation, but just doing some quick head math, I believe large skyscrapers could already have close to this concentration of addresses, if you reduce them down to flat earth surface area. The point here is that breaking out the math based on the surface area of the earth is silly, as we do not utilize the surface of the earth in a flat manner... Davis Beeman On Mon, Sep 17, 2012 at 11:27:04AM -0700, Owen DeLong wrote: What technology are you planning to deploy that will consume more than 2 addresses per square cm? Easy. Think volume (as in: orbit), and think um^3 for a functional computers ;) I meant real-world application. Orbits are limited due to the required combination of speed and altitude. There are a limited number of achievable altitudes and collision avoidance also creates interesting problems in time-slotting for orbits which are not geostationary. Geostationary orbits are currently limited to one object per degree of earth surface, and even at 4x that, you could give every satellite a /48 and still not burn through a /32. Owen What about network-based objects outside of our orbit? If we're talking about IPv6 in the long-term, I think we have to assume we'll have networked devices on the moon or at other locations in space. Jason The IP protocol is not well suited to space travel. As such, I think there would be a non-address based scaling limit in IPv6 for that application and a new protocol would be needed. Owen
Re: IPv6 Ignorance
I won't dispute that, but let's look at some of the densest uses of it, factoring in the vertical aspects as well... Let's assume an 88 story sky scraper 1 city block square (based on an average of 17 city block/mile). That's 96,465 sq. feet (8,961,918 sq. cm.) total building foot print. Subtract roughly 1,000,000 sq. cm. for walls, power, elevators, risers, etc leaves us with 7,961,918 sq. cm. per floor. Figure in a building that large, you probably need 5 floors for generators, 8 floors for chiller plants, and another 2 floors or more for other mechanical gives us a total of 73 datacenter floors max. (Which I would argue is still unrealistic, but what the heck). Subtract 1/3rds of the datacenter area for PDUs and CRAC units puts us at 5,307,945 sq. cm. per floor. FIguring a typical cabinet occupancy area + aisles of 2'x6' (small on the aisles, actually) gives us 12 sq. ft per cabinet = 11,148 sq. cm. per cabinet so we get roughly 715 cabinets per floor (max) and let's assume each 1U server holds 1000 virtual hosts at 42 servers per cabinet, that's 30,030 addresses per cabinet. Multiplied by 75 floors, that's a building total of 2,252,250 total addresses needed. We haven't even blown out a single /64 (and that's without allowing for the lower address density on routers, core switches, etc.). Let's assume we want to give a /64 to each server full of virtual hosts, we're still only taliking about 53,625 /64s, so the whole building can still be addressed within a /48 pretty easily (unless you think you have more than 12,000 additional point-to-point/other administrative/infrastructure links within the building in which case, you might need as much as a /47.) In terms of total addresses per cm, 2,252,250 addresses spread over the building footprint of 8,961,918 sq. cm. is still only 0.25 addresses per sq. cm. so it falls well short of the proposed 2 addresses per sq. cm. To even achieve the suggested 2 addresses per sq. cm, you would need to make the building 704 stories tall and still dense-pack every possible sq. foot of the building with datacenter and you'd have to put these kinds of buildings EVERYWHERE on earth, including over the oceans. I'm willing to say that based on that math, there are more than enough addresses for virtually any rational addressing scheme. Owen On Sep 18, 2012, at 09:01 , Beeman, Davis davis.bee...@integratelecom.com wrote: Orbits may not be important to this calculation, but just doing some quick head math, I believe large skyscrapers could already have close to this concentration of addresses, if you reduce them down to flat earth surface area. The point here is that breaking out the math based on the surface area of the earth is silly, as we do not utilize the surface of the earth in a flat manner... Davis Beeman On Mon, Sep 17, 2012 at 11:27:04AM -0700, Owen DeLong wrote: What technology are you planning to deploy that will consume more than 2 addresses per square cm? Easy. Think volume (as in: orbit), and think um^3 for a functional computers ;) I meant real-world application. Orbits are limited due to the required combination of speed and altitude. There are a limited number of achievable altitudes and collision avoidance also creates interesting problems in time-slotting for orbits which are not geostationary. Geostationary orbits are currently limited to one object per degree of earth surface, and even at 4x that, you could give every satellite a /48 and still not burn through a /32. Owen
Re: IPv6 Ignorance
6rd itself isn't inherently silly. Mapping your customers onto an entire /32 is. You're much better off taking the size of your largest prefix and assigning a number of bis for the number of prefixes you have. For example, if you have /14, /14, /15, /16, /16, /16, /18, /19, /20, /22, /22, /22, /22, /23 and need to deploy 6rd, you could easily fit that into a 48-18=30 (round up to 28) - 4 (14 prefixes) = /24. Let's say your /24 is 2001:db00::/24. Your /14s would map to 2001:db00::/28 and 2001:db10::/28. Your 15 would map to 2001:db20::/28 Your 16s would map to 2001:db30::/28, 2001:db40::/28, 2001:db50::/28. The 18, 19, and 20 would get 2001:db60:::/28 - 2001:db80::/28. The 22s would get 2001:db90::/28 - 2001:dbc0::/28. The /23 would get 2001:dbd0::/28 and you'd still have 2001:dbe0 through 2001:dbff available. (2 extra /28s). Note, that's with the assumption of mapping 6rd onto /48s. If you want to map 32 bits, then, you need to degrade your customers 6rd experience and give them smaller blocks until you can give them real IPv6 service. I do not support address policy to make poor planning easier. Owen On Sep 18, 2012, at 15:18 , William Herrin b...@herrin.us wrote: On Tue, Sep 18, 2012 at 11:39 AM, valdis.kletni...@vt.edu wrote: On Tue, 18 Sep 2012 02:35:43 -0400, William Herrin said: Then we need 32 bits to overlay the customer's IPv4 address for convenience within our 6RD network. Well yeah. You blow 32 bits for silly reasons, you run out of bits. Film at 11. Silly reason? Hardly! 6RD lets you deploy IPv6 immediately to all customers. It's a stateless tunnel. Direct the packets into an encapsulator and any customer who wants them need only catch them on their IPv4 address. Without you having to change out anything else in your network. Hitch is: if you have a whole lot of discontiguous IPv4 prefixes, sorting which maps to where in a compact IPv6 prefix is challenging. Much easier to just map the entire IPv4 space and be done with it. Poor plan. But much easier. On Tue, Sep 18, 2012 at 10:01 AM, Owen DeLong o...@delong.com wrote: Then we need 32 bits to overlay the customer's IPv4 address for convenience within our 6RD network. So that leaves us 16 bits. But we don't want the native network to overlay the 6RD network because we want a real simple /16 route into the nearest 6rd encapsulator. And we don't want to advertise multiple BGP prefixes either. So we claim another bit and allocate our native infrastructure from the /16 that doesn't overlap the 6rd setup. No, you really don't. This absurdity (and the ridiculous design of 6RD) are so problematic in this area that I cannot begin to describe what a terrible idea it is. In http://lists.arin.net/pipermail/arin-ppml/2010-September/018180.html I complained about mapping the full 32-bits of IPv4 address into an IPv6 prefix. You responded, You say that like it's somehow a bad thing, and I'm simply not seeing a problem. Have you come around to my way of thinking that using 6RD with a full 32-bit IPv4 mapping is not such a hot idea? Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: IPv6 Ignorance
On 9/16/12 9:22 PM, Mikael Abrahamsson wrote: On Mon, 17 Sep 2012, Randy Bush wrote: and don't bs me with how humongous the v6 address space is. we once though 32 bits was humongous. Giving out a /48 to every person on earth uses approximately 2^33 networks, meaning we could cram it into a /15. So even if we have 10 /48s at home from different providers, we're still only using a small fraction of the first /3. If we get this wrong, we have several more /3s to get it right in. People aren't going to be the big consumers of address space relative to machines . You already know this, and I can't really believe that people sat down in the 70ties and 80ties and said there is never going to be more than 128 large corporations that need a /8 in IPv4 ? Emergent phenomena were not (and generaly are not) predicted. 32 bits was a lot more than 8 which was the previous go around.. I start to get worried when people want to map 32 bits into IPv6 in several places, for instance telling all ISPs that they can have a /24 so that we can produce IPv4 mapped /56 to end customer, and make this space permanent. Temporary is fine, permanent is not. or the application of semantic meaning to intermediate bits. and yeah the IPv6 bit field looks a lot smaller when you start carving off it in 24 bit or shorter chunks. So I agree with you that there is still a risk that this is going to get screwed up, but I don't feel too gloomy yet.
Re: IPv6 Ignorance
My biggest fear is that statements like this will take on a life of their own: I can dual stack, then I am not out of IPv4 addresses, and thus I have no need for IPv6. If I'm out of IPv4 then I need IPv6 and I can't dual stack. http://forum.ubnt.com/showthread.php?p=355722 Not true but it certainly sounds logical to the average person. What creates this impression is that there is no deadline. The IPv4 - Dual Stack - pure IPv6 transition is complex so everyone focuses on IPv4 - Dual Stack forgetting that it is a transition step. The final step seems so far off that people ignore it, and therefore the justification for the first step fades. (the remainder of this post is brainstorming; apply a grain of salt) There are ways to fix this. For example there was a deadline for when Dual Stack was to go away, a Dual Stack 10 year count-down would drive the point home. However nothing like this exists. This thread is making me think that I should change how I talk about IPv6 publicly. I need to put more emphasis on DS as being a temporary thing. It is in my mind but perhaps not in how I speak. The problem with picking a 10-year or 5-year campaign is that underestimating the amount of time makes us look like the sky is falling and too long gives people a reason to procrastinate. Then again... I believe what will make the biggest # of people adopt IPv6 will be if they see everyone else adopting it. That's why it is so important for IPv6 to be offered by default to all new ISP customers, that tech-savy enterprises need to deploy it, and so on. It is all about building a critical mass. Tom -- Speaking at MacTech Conference 2012. http://mactech.com/conference; http://EverythingSysadmin.com -- my blog http://www.TomOnTime.com -- my videos
Re: IPv6 Ignorance
I think people forget how humongous the v6 space is... Remember that the address space is 2^128 (or 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses) to put the in perspective (and a great sample that explained to me how large it was, you will still get 667 quadrillion address per square millimetre of the Earth’s Surface. There's a great article on the myths and debunks of the address space at http://rednectar.net/2012/05/24/just-how-many-ipv6-addresses-are-there-really/ one of the things it talks about is the /64 and /48 allocation. snip Given that the first 3 bits of a public IPv6 address are always 001, giving /48 allocations to customers means that service providers will only have 2^(48-3) or 2^45 allocations of /48 to hand out to a population of approximately 6 billion people. 2^33 is over 8 billion, so assuming a population of 2^33, there will be enough IPv6 /48 allocations to cater for 2^(45-33) or 2^12 or 4096 IPv6 address allocations per user in the world. /snip - Mitch - On 17/09/12 04:23, Randy Bush wrote: [ yes, there are a lot of idiots out there. this is not new. but ] We are totally convinced that the factors that made IPv4 run out of addresses will remanifest themselves once again and likely sooner than a lot of us might expect given the Reccomendations for Best Practice deployment. while i am not totally convinced, i am certainly concerned. we are doing many of the same things all over again. remember when rip forced a homogenous, often classful, mask length in a network and we chewed through /24s? think /64 in ipv6, except it's half the bits not 1/4 of them. remember when we gave out As and Bs willy nilly? look at the giant swaths of v6 we give out today in the hopes that someone will deploy it. and don't bs me with how humongous the v6 address space is. we once though 32 bits was humongous. randy
Re: IPv6 Ignorance
With current use cases at least, yes. What do we know of what's going to happen in a decade or two? --srs (htc one x) On Sep 17, 2012 5:58 PM, John Mitchell mi...@illuminati.org wrote: I think people forget how humongous the v6 space is... Remember that the address space is 2^128 (or 340,282,366,920,938,463,463,* *374,607,431,768,211,456 addresses) to put the in perspective (and a great sample that explained to me how large it was, you will still get 667 quadrillion address per square millimetre of the Earth’s Surface. There's a great article on the myths and debunks of the address space at http://rednectar.net/2012/05/**24/just-how-many-ipv6-** addresses-are-there-really/http://rednectar.net/2012/05/24/just-how-many-ipv6-addresses-are-there-really/one of the things it talks about is the /64 and /48 allocation. snip Given that the first 3 bits of a public IPv6 address are always 001, giving /48 allocations to customers means that service providers will only have 2^(48-3) or 2^45 allocations of /48 to hand out to a population of approximately 6 billion people. 2^33 is over 8 billion, so assuming a population of 2^33, there will be enough IPv6 /48 allocations to cater for 2^(45-33) or 2^12 or 4096 IPv6 address allocations per user in the world. /snip - Mitch - On 17/09/12 04:23, Randy Bush wrote: [ yes, there are a lot of idiots out there. this is not new. but ] We are totally convinced that the factors that made IPv4 run out of addresses will remanifest themselves once again and likely sooner than a lot of us might expect given the Reccomendations for Best Practice deployment. while i am not totally convinced, i am certainly concerned. we are doing many of the same things all over again. remember when rip forced a homogenous, often classful, mask length in a network and we chewed through /24s? think /64 in ipv6, except it's half the bits not 1/4 of them. remember when we gave out As and Bs willy nilly? look at the giant swaths of v6 we give out today in the hopes that someone will deploy it. and don't bs me with how humongous the v6 address space is. we once though 32 bits was humongous. randy
Re: IPv6 Ignorance
Has said forum guy never heard of a phased implementation? Or would he rather a big bang cut over, i'm sure that will work swell. The best way to summarise the feeling for IPv6 was expressed in the Packet Pushers Podcast and that is Network Administrators and System Administrators have forgotten what it means to run a multiple stack Network. I also think many people are seeing IPv6 as a unnecessary evil due to the way it has come around and that comes back to the whole your doomed theory and we are only upgrading because there is a depletion, This comes back to a lack of understanding and lack of interest in change. I cannot remember where i heard it, but someone said that it will take a killer IPv6 application that cannot occur on v4 to get people to jump. I'm sure if Facebook/Google decided they were sick of v4 for a week you would see I.T. departments agenda change quite rapidly (obviously this isn't sustainable) Education seems to be the key here... Rusty gears is the problem, people haven't had to worry about addressing for such a long time now. Feel kinda sorry for the guys who have to readdress IPv6 though *mwaha* On Mon, Sep 17, 2012 at 10:04 PM, Tom Limoncelli t...@whatexit.org wrote: My biggest fear is that statements like this will take on a life of their own: I can dual stack, then I am not out of IPv4 addresses, and thus I have no need for IPv6. If I'm out of IPv4 then I need IPv6 and I can't dual stack. http://forum.ubnt.com/showthread.php?p=355722 Not true but it certainly sounds logical to the average person. What creates this impression is that there is no deadline. The IPv4 - Dual Stack - pure IPv6 transition is complex so everyone focuses on IPv4 - Dual Stack forgetting that it is a transition step. The final step seems so far off that people ignore it, and therefore the justification for the first step fades. (the remainder of this post is brainstorming; apply a grain of salt) There are ways to fix this. For example there was a deadline for when Dual Stack was to go away, a Dual Stack 10 year count-down would drive the point home. However nothing like this exists. This thread is making me think that I should change how I talk about IPv6 publicly. I need to put more emphasis on DS as being a temporary thing. It is in my mind but perhaps not in how I speak. The problem with picking a 10-year or 5-year campaign is that underestimating the amount of time makes us look like the sky is falling and too long gives people a reason to procrastinate. Then again... I believe what will make the biggest # of people adopt IPv6 will be if they see everyone else adopting it. That's why it is so important for IPv6 to be offered by default to all new ISP customers, that tech-savy enterprises need to deploy it, and so on. It is all about building a critical mass. Tom -- Speaking at MacTech Conference 2012. http://mactech.com/conference; http://EverythingSysadmin.com -- my blog http://www.TomOnTime.com -- my videos -- Regards, Jason Leschnik. [m] 0432 35 4224 [w@] jason dot leschnik at ansto dot gov dot aujason.lesch...@ansto.gov.au [U@] jml...@uow.edu.au
Re: IPv6 Ignorance
On 17 Sep 2012, at 13:28, John Mitchell mi...@illuminati.org wrote: snip Given that the first 3 bits of a public IPv6 address are always 001, giving /48 allocations to customers means that service providers will only have 2^(48-3) or 2^45 allocations of /48 to hand out to a population of approximately 6 billion people. 2^33 is over 8 billion, so assuming a population of 2^33, there will be enough IPv6 /48 allocations to cater for 2^(45-33) or 2^12 or 4096 IPv6 address allocations per user in the world. /snip It seems a tad unfair that the bottom 80 bits are squandered away with a utilisation rate of something closely approximating zero; yet the upper 48 bits are assumed to have zero wastage... Regards, aid
Re: IPv6 Ignorance
That is a very fair point, however one would hope (and this is a big hope) that the upper bits are more regulated to stricter standards than the lower bits. In any system there is room for human error or oversight that is always going to be a concern, but standards, good practises and policies can help mitigate this risk, which is something the upper blocks normally adhere too.. but with the lower blocks its in the hands of the smaller companies and consumers who don't *always* have the same rigorous standards. On 17/09/12 14:37, Adrian Bool wrote: On 17 Sep 2012, at 13:28, John Mitchell mi...@illuminati.org wrote: snip Given that the first 3 bits of a public IPv6 address are always 001, giving /48 allocations to customers means that service providers will only have 2^(48-3) or 2^45 allocations of /48 to hand out to a population of approximately 6 billion people. 2^33 is over 8 billion, so assuming a population of 2^33, there will be enough IPv6 /48 allocations to cater for 2^(45-33) or 2^12 or 4096 IPv6 address allocations per user in the world. /snip It seems a tad unfair that the bottom 80 bits are squandered away with a utilisation rate of something closely approximating zero; yet the upper 48 bits are assumed to have zero wastage... Regards, aid
Re: IPv6 Ignorance
On Sep 17, 2012 5:04 AM, Tom Limoncelli t...@whatexit.org wrote: My biggest fear is that statements like this will take on a life of their own: I can dual stack, then I am not out of IPv4 addresses, and thus I have no need for IPv6. If I'm out of IPv4 then I need IPv6 and I can't dual stack. http://forum.ubnt.com/showthread.php?p=355722 Not true but it certainly sounds logical to the average person. What creates this impression is that there is no deadline. The IPv4 - Dual Stack - pure IPv6 transition is complex so everyone focuses on IPv4 - Dual Stack forgetting that it is a transition step. The final step seems so far off that people ignore it, and therefore the justification for the first step fades. (the remainder of this post is brainstorming; apply a grain of salt) There are ways to fix this. For example there was a deadline for when Dual Stack was to go away, a Dual Stack 10 year count-down would drive the point home. However nothing like this exists. This thread is making me think that I should change how I talk about IPv6 publicly. I need to put more emphasis on DS as being a temporary thing. It is in my mind but perhaps not in how I speak. I tell folks that if ipv4 run-out is the problem in eyeball networks, then DS cannot be the solution since it has the same problematic reliance on a scarce ipv4 resource. I spent a lot of time focusing on ipv6-only networking for mobile and in many cases, thanks to world v6 launch and ipv6-only based access network transition schemes (ds-lite, MAP, 464xlat) they can provide a solution for eyeball networks that is one step away from ipv6-only. Instead of DS, which is just one step beyond ipv4-only with a foggy road to getting off scarce / expensive / broken ipv4 Content networks are a different beast that must be dual-stack to reach all the eyeballs CB The problem with picking a 10-year or 5-year campaign is that underestimating the amount of time makes us look like the sky is falling and too long gives people a reason to procrastinate. Then again... I believe what will make the biggest # of people adopt IPv6 will be if they see everyone else adopting it. That's why it is so important for IPv6 to be offered by default to all new ISP customers, that tech-savy enterprises need to deploy it, and so on. It is all about building a critical mass. Tom -- Speaking at MacTech Conference 2012. http://mactech.com/conference; http://EverythingSysadmin.com -- my blog http://www.TomOnTime.com -- my videos
Re: IPv6 Ignorance
On 17/09/2012 14:37, Adrian Bool wrote: It seems a tad unfair that the bottom 80 bits are squandered away with a utilisation rate of something closely approximating zero You are thinking in ipv4 mode. In ipv6 mode, the consideration is not how many hosts you have, but how many subnets you are dealing with. Instead of thinking of 128 bits of addressing space, we talk about 64 bits of subnet space. So your statement comes down to: it seems a tad unfair that the bottom 16 bits are squandered away. This is a more difficult argument to make. Nick
Re: IPv6 Ignorance
Hi, On 17 Sep 2012, at 15:02, Nick Hilliard n...@foobar.org wrote: On 17/09/2012 14:37, Adrian Bool wrote: It seems a tad unfair that the bottom 80 bits are squandered away with a utilisation rate of something closely approximating zero You are thinking in ipv4 mode. In ipv6 mode, the consideration is not how many hosts you have, but how many subnets you are dealing with. Instead of thinking of 128 bits of addressing space, we talk about 64 bits of subnet space. So your statement comes down to: it seems a tad unfair that the bottom 16 bits are squandered away. This is a more difficult argument to make. I don't really agree with the IPv6 think concept - but let's put that aside for now... The default allocation size from an RIR* to an LIR is a /32. For an LIR providing /48 site allocations to their customers, they therefore have 16-bits of address space available to them to address their customers. So, even in IPv6 think, homes that typically have one subnet have an equal number of bits to address their single subnet as an LIR has to address all of their customers. It seems illogical to me that we've got an 128-bit address space, featuring numbers far larger than any human can comprehend, yet the default allocation to an LIR allows them to address such a feeble number as 65,536 customers - a number far smaller than the number of customers for medium to large ISPs. The default LIR allocation should be a several orders of magnitude greater than the typical customer base - not a smaller default allocation. Regards, Adrian * At least for RIPE.
RE: IPv6 Ignorance
RIPE 552 (I think), allows you to request up to a /29 without additional justification if needed. Mike -Original Message- From: Adrian Bool [mailto:a...@logic.org.uk] Sent: 17 September 2012 15:55 To: nanog@nanog.org Subject: Re: IPv6 Ignorance Hi, On 17 Sep 2012, at 15:02, Nick Hilliard n...@foobar.org wrote: On 17/09/2012 14:37, Adrian Bool wrote: It seems a tad unfair that the bottom 80 bits are squandered away with a utilisation rate of something closely approximating zero You are thinking in ipv4 mode. In ipv6 mode, the consideration is not how many hosts you have, but how many subnets you are dealing with. Instead of thinking of 128 bits of addressing space, we talk about 64 bits of subnet space. So your statement comes down to: it seems a tad unfair that the bottom 16 bits are squandered away. This is a more difficult argument to make. I don't really agree with the IPv6 think concept - but let's put that aside for now... The default allocation size from an RIR* to an LIR is a /32. For an LIR providing /48 site allocations to their customers, they therefore have 16-bits of address space available to them to address their customers. So, even in IPv6 think, homes that typically have one subnet have an equal number of bits to address their single subnet as an LIR has to address all of their customers. It seems illogical to me that we've got an 128-bit address space, featuring numbers far larger than any human can comprehend, yet the default allocation to an LIR allows them to address such a feeble number as 65,536 customers - a number far smaller than the number of customers for medium to large ISPs. The default LIR allocation should be a several orders of magnitude greater than the typical customer base - not a smaller default allocation. Regards, Adrian * At least for RIPE.
Re: IPv6 Ignorance
On Mon, Sep 17, 2012 at 9:55 AM, Adrian Bool a...@logic.org.uk wrote: I don't really agree with the IPv6 think concept - but let's put that aside for now... The default allocation size from an RIR* to an LIR is a /32. For an LIR providing /48 site allocations to their customers, they therefore have 16-bits of address space available to them to address their customers. So, even in IPv6 think, homes that typically have one subnet have an equal number of bits to address their single subnet as an LIR has to address all of their customers. It seems illogical to me that we've got an 128-bit address space, featuring numbers far larger than any human can comprehend, yet the default allocation to an LIR allows them to address such a feeble number as 65,536 customers - a number far smaller than the number of customers for medium to large ISPs. The default LIR allocation should be a several orders of magnitude greater than the typical customer base - not a smaller default allocation. Regards, Adrian * At least for RIPE. Note you say default, as in beginning point, not maximum. -Blake
Re: IPv6 Ignorance
On 17 Sep 2012, at 15:55, Adrian Bool a...@logic.org.uk wrote: Hi, On 17 Sep 2012, at 15:02, Nick Hilliard n...@foobar.org wrote: On 17/09/2012 14:37, Adrian Bool wrote: It seems a tad unfair that the bottom 80 bits are squandered away with a utilisation rate of something closely approximating zero You are thinking in ipv4 mode. In ipv6 mode, the consideration is not how many hosts you have, but how many subnets you are dealing with. Instead of thinking of 128 bits of addressing space, we talk about 64 bits of subnet space. So your statement comes down to: it seems a tad unfair that the bottom 16 bits are squandered away. This is a more difficult argument to make. I don't really agree with the IPv6 think concept - but let's put that aside for now... The default allocation size from an RIR* to an LIR is a /32. For an LIR providing /48 site allocations to their customers, they therefore have 16-bits of address space available to them to address their customers. So, even in IPv6 think, homes that typically have one subnet have an equal number of bits to address their single subnet as an LIR has to address all of their customers. It seems illogical to me that we've got an 128-bit address space, featuring numbers far larger than any human can comprehend, yet the default allocation to an LIR allows them to address such a feeble number as 65,536 customers - a number far smaller than the number of customers for medium to large ISPs. The default LIR allocation should be a several orders of magnitude greater than the typical customer base - not a smaller default allocation. Amen, brother! I was doing that particular computation about six months ago when we had our first request and arrived at the same conclusion. I've concluded that /48 for businesses and /56 for residential sites is the more reasonable approach until we start getting /24 IPv6 allocations for LIRs and I think many others have concluded the same. - Mark
Re: IPv6 Ignorance
On 9/17/2012 5:28 AM, John Mitchell wrote: I think people forget how humongous the v6 space is... Remember that the address space is 2^128 (or 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses) to put the in perspective (and a great sample that explained to me how large it was, you will still get 667 quadrillion address per square millimetre of the Earth’s Surface. Yes. But figure an average subnet has, what, maybe 5 hosts on it? (Sure, there's some bigger ones, but a whole lot of my router, my PC, and maybe my printer networks too. So even if you could use all the top bits (which you can't, as many combinations are reserved), that's more like 92,233,720,368,547,758,080. And if you lop off the top three bits and just count the space currently assigned to Global Unicast, that's 11,529,215,046,068,469,760. Which is 0.02 per square mm of the earth's surface. Or just over 2 per square centimeter. Powers of two get big fast... but they get small fast too. Matthew Kaufman
Re: IPv6 Ignorance
Hi Mike, On 17 Sep 2012, at 16:04, Mike Simkins mike.simk...@sungard.com wrote: RIPE 552 (I think), allows you to request up to a /29 without additional justification if needed. Sure, but you're just tinkering at the edges here. 32-bits would be a more sensible allocation size to LIRs, allowing them construct their addressing plan in a logical, hierarchal manner whilst allowing for growth - and most importantly ensuring they only advertise a single route into the global routing table. Kind regards, Adrian
Re: IPv6 Ignorance
On 9/17/12 8:23 AM, Adrian Bool wrote: Hi Mike, On 17 Sep 2012, at 16:04, Mike Simkins mike.simk...@sungard.com wrote: RIPE 552 (I think), allows you to request up to a /29 without additional justification if needed. Sure, but you're just tinkering at the edges here. 32-bits would be a more sensible allocation size to LIRs, allowing them construct their addressing plan in a logical, hierarchal manner whilst allowing for growth - and most importantly ensuring they only advertise a single route into the global routing table. Which fine except we have assignment practices that have the result requiring the allocation of much shorter prefixes. Just handing out /32s fails the objective reality test. Regarding the single route, no they don't. and nobody that I know is filtering on /32 or longer. Kind regards, Adrian
Re: IPv6 Burgers (was: IPv6 Ignorance)
Another measure of the size of the IPv6 address space... Back on World IPv6 Day in June 2011, Dartware had a barbecue. (Why? Because the burgers had 128 (bacon) bits and we served IP(A) to drink :-) You can see some photos at: http://www.networkworld.com/community/blog/scenes-ipv6-day-barbecue But we came up with another interesting measure for the vastness of the IPv6 address space: If an IPv4 hamburger patty has 2^32 (4.2 billion) unique addresses in its 1/4 inch thickness, how thick would an IPv6 hamburger be (with 2^128 unique addresses)? The answer is... 53 billion light-years. It's straightforward unit conversions. There are 2^96 IPv4 Hamburgers at a quarter-inch apiece. That's 2^96 inches/4 (2^94 inches). Switching to decimal units, 1.98x10^32 inches; 1.65x10^27 feet; 3.13x10^23 miles; and then continuing to convert to light-years. A good tool for this kind of wacky unit conversion is Frink (http://futureboy.us/fsp/frink.fsp?fromVal=2%5E94+inchestoVal=lightyears), which can do this in one shot. Simply enter: From: 2^94 inches To: lightyears and you'll see the answer! Rich Brownrichard.e.br...@dartware.com Dartware, LLC http://www.intermapper.com 66-7 Benning Street Telephone: 603-643-9600 West Lebanon, NH 03784-3407 Fax: 603-643-2289
Re: IPv6 Ignorance
On Sep 16, 2012, at 20:23 , Randy Bush ra...@psg.com wrote: [ yes, there are a lot of idiots out there. this is not new. but ] We are totally convinced that the factors that made IPv4 run out of addresses will remanifest themselves once again and likely sooner than a lot of us might expect given the Reccomendations for Best Practice deployment. while i am not totally convinced, i am certainly concerned. we are doing many of the same things all over again. remember when rip forced a homogenous, often classful, mask length in a network and we chewed through /24s? think /64 in ipv6, except it's half the bits not 1/4 of them. remember when we gave out As and Bs willy nilly? look at the giant swaths of v6 we give out today in the hopes that someone will deploy it. and don't bs me with how humongous the v6 address space is. we once though 32 bits was humongous. randy We thought 32 bits was humongous in the context of a research project that would connect universities, research institutions and some military installations. In that context, 32 bits would still be humongous. Our estimation of humongous didn't change, the usage of the network changed dramatically. The experiment escaped from the laboratory and took on a life of its own. Once that happened, the realization that 32 bits wasn't enough was very nearly immediate. The IPv6 address space offers 61 bits of network numbers each of which holds up to 64 bits worth of hosts. Obviously you never want to fill one of those subnets (nor could you with any available hardware), but it means that you don't have to waste time thinking about rightsizing network assignments. I won't say we will never run out of IPv6 address space, but I will say that I'll be surprised if IPv6 doesn't hit a different limit first. Guess what... If it turns out that our current behavior with respect to IPv6 addresses is ill-advised, then, we have 6+ more copies of the current IPv6 address space where we can try different allocation strategies. Rather than fretting about the perils of using the protocol as intended, let's deploy it, get a working end-to-end internet and see where we stand. Owen
Re: IPv6 Ignorance
On Sep 16, 2012, at 16:58 , John R. Levine jo...@iecc.com wrote: IPv6 has its problems, but running out of addresses is not one of them. For those of us worried about abuse management, the problem is the opposite, even the current tiny sliver of addresses is so huge that techniques from IPv4 to map who's doing what where don't scale. Well, in IPv4... NAT broke it, because networks implementing 1:many NAT could no longer easily identify what host was responsible for abuse. I realize that's a problem in theory, in practice it's not because it's still rare to have interestingly different hosts behind a single NAT. CGN should solve that and convert theory to practice quite effectively. Owen
Re: IPv6 Ignorance
Actually, as documented below, the assumption is merely that the waste will be less than 4095/4096ths of the address space. ;-) Owen On Sep 17, 2012, at 06:46 , John Mitchell mi...@illuminati.org wrote: That is a very fair point, however one would hope (and this is a big hope) that the upper bits are more regulated to stricter standards than the lower bits. In any system there is room for human error or oversight that is always going to be a concern, but standards, good practises and policies can help mitigate this risk, which is something the upper blocks normally adhere too.. but with the lower blocks its in the hands of the smaller companies and consumers who don't *always* have the same rigorous standards. On 17/09/12 14:37, Adrian Bool wrote: On 17 Sep 2012, at 13:28, John Mitchell mi...@illuminati.org wrote: snip Given that the first 3 bits of a public IPv6 address are always 001, giving /48 allocations to customers means that service providers will only have 2^(48-3) or 2^45 allocations of /48 to hand out to a population of approximately 6 billion people. 2^33 is over 8 billion, so assuming a population of 2^33, there will be enough IPv6 /48 allocations to cater for 2^(45-33) or 2^12 or 4096 IPv6 address allocations per user in the world. /snip It seems a tad unfair that the bottom 80 bits are squandered away with a utilisation rate of something closely approximating zero; yet the upper 48 bits are assumed to have zero wastage... Regards, aid
Re: IPv6 Ignorance
On Sep 17, 2012, at 07:55 , Adrian Bool a...@logic.org.uk wrote: Hi, On 17 Sep 2012, at 15:02, Nick Hilliard n...@foobar.org wrote: On 17/09/2012 14:37, Adrian Bool wrote: It seems a tad unfair that the bottom 80 bits are squandered away with a utilisation rate of something closely approximating zero You are thinking in ipv4 mode. In ipv6 mode, the consideration is not how many hosts you have, but how many subnets you are dealing with. Instead of thinking of 128 bits of addressing space, we talk about 64 bits of subnet space. So your statement comes down to: it seems a tad unfair that the bottom 16 bits are squandered away. This is a more difficult argument to make. I don't really agree with the IPv6 think concept - but let's put that aside for now... The default allocation size from an RIR* to an LIR is a /32. For an LIR providing /48 site allocations to their customers, they therefore have 16-bits of address space available to them to address their customers. So, even in IPv6 think, homes that typically have one subnet have an equal number of bits to address their single subnet as an LIR has to address all of their customers. It seems illogical to me that we've got an 128-bit address space, featuring numbers far larger than any human can comprehend, yet the default allocation to an LIR allows them to address such a feeble number as 65,536 customers - a number far smaller than the number of customers for medium to large ISPs. The default LIR allocation should be a several orders of magnitude greater than the typical customer base - not a smaller default allocation. Don't think of it as the default allocation, think of it as the minimum allocation. You can very easily get a much larger allocation if you have more than 30,000 customers. Owen
Re: IPv6 Ignorance
On Sep 17, 2012, at 08:18 , Matthew Kaufman matt...@matthew.at wrote: On 9/17/2012 5:28 AM, John Mitchell wrote: I think people forget how humongous the v6 space is... Remember that the address space is 2^128 (or 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses) to put the in perspective (and a great sample that explained to me how large it was, you will still get 667 quadrillion address per square millimetre of the Earth’s Surface. Yes. But figure an average subnet has, what, maybe 5 hosts on it? (Sure, there's some bigger ones, but a whole lot of my router, my PC, and maybe my printer networks too. So even if you could use all the top bits (which you can't, as many combinations are reserved), that's more like 92,233,720,368,547,758,080. And if you lop off the top three bits and just count the space currently assigned to Global Unicast, that's 11,529,215,046,068,469,760. Which is 0.02 per square mm of the earth's surface. Or just over 2 per square centimeter. Powers of two get big fast... but they get small fast too. Matthew Kaufman What technology are you planning to deploy that will consume more than 2 addresses per square cm? Owen
Re: IPv6 Ignorance
On Sep 17, 2012, at 08:16 , Mark Blackman m...@exonetric.com wrote: On 17 Sep 2012, at 15:55, Adrian Bool a...@logic.org.uk wrote: Hi, On 17 Sep 2012, at 15:02, Nick Hilliard n...@foobar.org wrote: On 17/09/2012 14:37, Adrian Bool wrote: It seems a tad unfair that the bottom 80 bits are squandered away with a utilisation rate of something closely approximating zero You are thinking in ipv4 mode. In ipv6 mode, the consideration is not how many hosts you have, but how many subnets you are dealing with. Instead of thinking of 128 bits of addressing space, we talk about 64 bits of subnet space. So your statement comes down to: it seems a tad unfair that the bottom 16 bits are squandered away. This is a more difficult argument to make. I don't really agree with the IPv6 think concept - but let's put that aside for now... The default allocation size from an RIR* to an LIR is a /32. For an LIR providing /48 site allocations to their customers, they therefore have 16-bits of address space available to them to address their customers. So, even in IPv6 think, homes that typically have one subnet have an equal number of bits to address their single subnet as an LIR has to address all of their customers. It seems illogical to me that we've got an 128-bit address space, featuring numbers far larger than any human can comprehend, yet the default allocation to an LIR allows them to address such a feeble number as 65,536 customers - a number far smaller than the number of customers for medium to large ISPs. The default LIR allocation should be a several orders of magnitude greater than the typical customer base - not a smaller default allocation. Amen, brother! I was doing that particular computation about six months ago when we had our first request and arrived at the same conclusion. I've concluded that /48 for businesses and /56 for residential sites is the more reasonable approach until we start getting /24 IPv6 allocations for LIRs and I think many others have concluded the same. - Mark LIRs which need /24s can get /24s. /32 was never a maximum, it was merely the minimum and as such is a reasonable starting point. The vast majority of ISPs in operation today can give all their customers /48s out of a /28 and still have lots of room to spare. For larger providers, they should have no trouble justifying a much larger block. I know from experience that it is possible to get /24s in the ARIN region with reasonable justification, for example. Owen
Re: IPv6 Ignorance
On Mon, Sep 17, 2012 at 11:27:04AM -0700, Owen DeLong wrote: What technology are you planning to deploy that will consume more than 2 addresses per square cm? Easy. Think volume (as in: orbit), and think um^3 for a functional computers ;)
RE: IPv6 Ignorance
On Sep 17, 2012, at 08:18 , Matthew Kaufman matt...@matthew.at wrote: On 9/17/2012 5:28 AM, John Mitchell wrote: I think people forget how humongous the v6 space is... Remember that the address space is 2^128 (or 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses) to put the in perspective (and a great sample that explained to me how large it was, you will still get 667 quadrillion address per square millimetre of the Earth's Surface. Yes. But figure an average subnet has, what, maybe 5 hosts on it? (Sure, there's some bigger ones, but a whole lot of my router, my PC, and maybe my printer networks too. So even if you could use all the top bits (which you can't, as many combinations are reserved), that's more like 92,233,720,368,547,758,080. And if you lop off the top three bits and just count the space currently assigned to Global Unicast, that's 11,529,215,046,068,469,760. Which is 0.02 per square mm of the earth's surface. Or just over 2 per square centimeter. Powers of two get big fast... but they get small fast too. Matthew Kaufman What technology are you planning to deploy that will consume more than 2 addresses per square cm? Owen http://xkcd.com/865/ -Davis
RE: IPv6 Ignorance
VMware vSphere on quad processor 1u servers with 768gb of RAM :) that should yield 80-140 VM's per host :) that gets you close on density. -Original Message- From: Eugen Leitl [mailto:eu...@leitl.org] Sent: Monday, September 17, 2012 1:55 PM To: nanog@nanog.org Subject: Re: IPv6 Ignorance On Mon, Sep 17, 2012 at 11:27:04AM -0700, Owen DeLong wrote: What technology are you planning to deploy that will consume more than 2 addresses per square cm? Easy. Think volume (as in: orbit), and think um^3 for a functional computers ;)
Re: IPv6 Ignorance
In message cad6ajgrbgk8fzlz-tpl3ogo4trez917sbvc_d9yhh9m28fn...@mail.gmail.com , Cameron Byrne writes: On Sep 17, 2012 5:04 AM, Tom Limoncelli t...@whatexit.org wrote: My biggest fear is that statements like this will take on a life of their own: I can dual stack, then I am not out of IPv4 addresses, and thus I have no need for IPv6. If I'm out of IPv4 then I need IPv6 and I can't dual stack. http://forum.ubnt.com/showthread.php?p=355722 Not true but it certainly sounds logical to the average person. What creates this impression is that there is no deadline. The IPv4 - Dual Stack - pure IPv6 transition is complex so everyone focuses on IPv4 - Dual Stack forgetting that it is a transition step. The final step seems so far off that people ignore it, and therefore the justification for the first step fades. (the remainder of this post is brainstorming; apply a grain of salt) There are ways to fix this. For example there was a deadline for when Dual Stack was to go away, a Dual Stack 10 year count-down would drive the point home. However nothing like this exists. This thread is making me think that I should change how I talk about IPv6 publicly. I need to put more emphasis on DS as being a temporary thing. It is in my mind but perhaps not in how I speak. s I tell folks that if ipv4 run-out is the problem in eyeball networks, then DS cannot be the solution since it has the same problematic reliance on a scarce ipv4 resource. You can go dual stack today and introduce CGN / DS-lite tomorrow. The point is to light up IPv6 *now* and the simplest way to do that is DS. No one ever said DS was a long term solution. It was always only the first step along the path. I spent a lot of time focusing on ipv6-only networking for mobile and in many cases, thanks to world v6 launch and ipv6-only based access network transition schemes (ds-lite, MAP, 464xlat) they can provide a solution for eyeball networks that is one step away from ipv6-only. Instead of DS, which is just one step beyond ipv4-only with a foggy road to getting off scarce / expensive / broken ipv4 And look at the extra hacks that are needed to tether with the current mobile solution of going IPv6 only and not supporting PD from day one. Mobile networks also have the advantage of tech refresh happening as you go from 2G - 3G - 4G. Most eyeball networks are different to mobile networks. You have a large base of IPv4 based networks connected to your network which contain some IPv4 equipement that cannot be upgraded. Content networks are a different beast that must be dual-stack to reach all the eyeballs CB The problem with picking a 10-year or 5-year campaign is that underestimating the amount of time makes us look like the sky is falling and too long gives people a reason to procrastinate. Then again... I believe what will make the biggest # of people adopt IPv6 will be if they see everyone else adopting it. That's why it is so important for IPv6 to be offered by default to all new ISP customers, that tech-savy enterprises need to deploy it, and so on. It is all about building a critical mass. Tom -- Speaking at MacTech Conference 2012. http://mactech.com/conference; http://EverythingSysadmin.com -- my blog http://www.TomOnTime.com -- my videos -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 Ignorance
In article caarzuotqwgpbw46+xb1ngmcn1yryttpygyymppxpqqug9k6...@mail.gmail.com you write: With current use cases at least, yes. What do we know of what's going to happen in a decade or two? In technology, not much. But I'd be pretty surprised if the laws of arithmetic were to change, or if we were to find it useful to assign IP addresses to objects smaller than a single atom. My current example of how bit IPv6 addresses are: my home LAN has a tunneled IPv6 network, and the web server on my laptop has an IPv6 address. Even though some of the stuff on the laptop is somewhat confidential, I haven't bothered to use any passwords. Why? Because guessing the random low 64 bits assigned to the web server (which are not the auto generated address from the LAN card) is at least as hard as any password scheme. R's, John
Re: IPv6 Ignorance
John Mitchell wrote: I think people forget how humongous the v6 space is... They don't. Instead, they suffer from it. Remember that the address space is 2^128 (or 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses) That is one of a major design flaw of IPv6 as a result of failed attempt to have SLAAC, which resulted in so stateful and time wasting mechanism. As it is virtually impossible to remember IPv6 addresses, IPv6 operation is a lot harder than necessary. Masataka Ohta
Re: IPv6 Ignorance
On 9/17/2012 4:32 PM, John Levine wrote: In article caarzuotqwgpbw46+xb1ngmcn1yryttpygyymppxpqqug9k6...@mail.gmail.com you write: With current use cases at least, yes. What do we know of what's going to happen in a decade or two? In technology, not much. But I'd be pretty surprised if the laws of arithmetic were to change, or if we were to find it useful to assign IP addresses to objects smaller than a single atom. My current example of how bit IPv6 addresses are: my home LAN has a tunneled IPv6 network, and the web server on my laptop has an IPv6 address. Even though some of the stuff on the laptop is somewhat confidential, I haven't bothered to use any passwords. Why? Because guessing the random low 64 bits assigned to the web server (which are not the auto generated address from the LAN card) is at least as hard as any password scheme. And so you never visit any websites from that laptop that might keep access logs either? You do know that lists of active IPv6 addresses are already not that hard to come by, and that'll just get more and more true over time, yes? Matthew Kaufman
Re: IPv6 Ignorance
I agree with the way you are looking at it. I know it sounds impressive to talk about hosts, but in ipv6 all that matters is how many subnets do I have and how clean are my aggregation levels to avoid large wastes of subnets. Host addressing is not an issue or concern. So to talk about 128 bits instead of the reality of the 64 is silly. Owen DeLong o...@delong.com wrote: On Sep 16, 2012, at 20:23 , Randy Bush ra...@psg.com wrote: [ yes, there are a lot of idiots out there. this is not new. but ] We are totally convinced that the factors that made IPv4 run out of addresses will remanifest themselves once again and likely sooner than a lot of us might expect given the Reccomendations for Best Practice deployment. while i am not totally convinced, i am certainly concerned. we are doing many of the same things all over again. remember when rip forced a homogenous, often classful, mask length in a network and we chewed through /24s? think /64 in ipv6, except it's half the bits not 1/4 of them. remember when we gave out As and Bs willy nilly? look at the giant swaths of v6 we give out today in the hopes that someone will deploy it. and don't bs me with how humongous the v6 address space is. we once though 32 bits was humongous. randy We thought 32 bits was humongous in the context of a research project that would connect universities, research institutions and some military installations. In that context, 32 bits would still be humongous. Our estimation of humongous didn't change, the usage of the network changed dramatically. The experiment escaped from the laboratory and took on a life of its own. Once that happened, the realization that 32 bits wasn't enough was very nearly immediate. The IPv6 address space offers 61 bits of network numbers each of which holds up to 64 bits worth of hosts. Obviously you never want to fill one of those subnets (nor could you with any available hardware), but it means that you don't have to waste time thinking about rightsizing network assignments. I won't say we will never run out of IPv6 address space, but I will say that I'll be surprised if IPv6 doesn't hit a different limit first. Guess what... If it turns out that our current behavior with respect to IPv6 addresses is ill-advised, then, we have 6+ more copies of the current IPv6 address space where we can try different allocation strategies. Rather than fretting about the perils of using the protocol as intended, let's deploy it, get a working end-to-end internet and see where we stand. Owen -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: IPv6 Ignorance
On Sep 17, 2012, at 12:54 , Eugen Leitl eu...@leitl.org wrote: On Mon, Sep 17, 2012 at 11:27:04AM -0700, Owen DeLong wrote: What technology are you planning to deploy that will consume more than 2 addresses per square cm? Easy. Think volume (as in: orbit), and think um^3 for a functional computers ;) I meant real-world application. Orbits are limited due to the required combination of speed and altitude. There are a limited number of achievable altitudes and collision avoidance also creates interesting problems in time-slotting for orbits which are not geostationary. Geostationary orbits are currently limited to one object per degree of earth surface, and even at 4x that, you could give every satellite a /48 and still not burn through a /32. Owen
Re: IPv6 Ignorance
True, but at a price that means this won't occur on very many of earth's many CM and even if it did, when you subtract the space required for cooling them and the space required to produce the power to drive them (and the cooling plants) and the space required to produce the fuels for the power plants and... you still come up short. Indeed, as you make the hosts more dense, you may come up even shorter due to the overhead of supporting them. Owen On Sep 17, 2012, at 14:04 , Blake Pfankuch bl...@pfankuch.me wrote: VMware vSphere on quad processor 1u servers with 768gb of RAM :) that should yield 80-140 VM's per host :) that gets you close on density. -Original Message- From: Eugen Leitl [mailto:eu...@leitl.org] Sent: Monday, September 17, 2012 1:55 PM To: nanog@nanog.org Subject: Re: IPv6 Ignorance On Mon, Sep 17, 2012 at 11:27:04AM -0700, Owen DeLong wrote: What technology are you planning to deploy that will consume more than 2 addresses per square cm? Easy. Think volume (as in: orbit), and think um^3 for a functional computers ;)
Re: IPv6 Ignorance
On Sep 17, 2012, at 16:41 , Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: John Mitchell wrote: I think people forget how humongous the v6 space is... They don't. Instead, they suffer from it. I find it quite useful, actually. I would not say I suffer from it at all. Remember that the address space is 2^128 (or 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses) That is one of a major design flaw of IPv6 as a result of failed attempt to have SLAAC, which resulted in so stateful and time wasting mechanism. As it is virtually impossible to remember IPv6 addresses, IPv6 operation is a lot harder than necessary. Masataka Ohta Hmmm... I find SLAAC quite useful so I'm not sure why you would call it time-wasting. I also have no more difficulty remembering IPv6 addresses in general than I had with IPv4. I can generally remember the prefixes I care about and the suffixes unless machine-generated are almost always easier to remember in IPv6 because there are enough bits to make them usefully meaningful instead of dense-packed meaningless numbers. YMMV. Owen
Re: IPv6 Ignorance
In technology, not much. But I'd be pretty surprised if the laws of arithmetic were to change, or if we were to find it useful to assign IP addresses to objects smaller than a single atom. we assign them /64s
Re: IPv6 Ignorance
Owen DeLong wrote: I also have no more difficulty remembering IPv6 addresses in general than I had with IPv4. I can generally remember You have already demonstrated your ability to remember things wrongly so many times in this ML, your statement is very convincing. the prefixes I care about and the suffixes unless machine-generated are almost always easier to remember in IPv6 because I'm afraid you forget to have stated: Hmmm... I find SLAAC quite useful YMMV. Your memory may vary. Masataka Ohta
Re: IPv6 Ignorance
http://www.antipope.org/charlie/blog-static/2012/08/how-low-power-can-you-go.html On 9/17/12 8:16 PM, Owen DeLong wrote: True, but at a price that means this won't occur on very many of earth's many CM and even if it did, when you subtract the space required for cooling them and the space required to produce the power to drive them (and the cooling plants) and the space required to produce the fuels for the power plants and... you still come up short. Indeed, as you make the hosts more dense, you may come up even shorter due to the overhead of supporting them. Owen On Sep 17, 2012, at 14:04 , Blake Pfankuch bl...@pfankuch.me wrote: VMware vSphere on quad processor 1u servers with 768gb of RAM :) that should yield 80-140 VM's per host :) that gets you close on density. -Original Message- From: Eugen Leitl [mailto:eu...@leitl.org] Sent: Monday, September 17, 2012 1:55 PM To: nanog@nanog.org Subject: Re: IPv6 Ignorance On Mon, Sep 17, 2012 at 11:27:04AM -0700, Owen DeLong wrote: What technology are you planning to deploy that will consume more than 2 addresses per square cm? Easy. Think volume (as in: orbit), and think um^3 for a functional computers ;)
IPv6 Ignorance
I came across these threads today; the blind ignorance towards IPv6 from some of the posters is kind of shocking. It's also pretty disappointing if these are the people providing internet access to end users. We focus our worries on the big guys like ATT going IPv6 (which I'm sure but they're slow), but these small operators are a much bigger problem. http://forum.ubnt.com/showthread.php?p=355722 http://forum.ubnt.com/showthread.php?t=53779 ~Seth
