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 AT&T 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
On 9/16/2012 9:55 AM, Seth Mattinen wrote:
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 AT&T 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
Wow... my brain hurts after reading that. The saddest part is, there are folks with IPv6 allocations that simply refuse to implement dual stack. --John
On 9/16/12 10:06 AM, John T. Yocum wrote:
On 9/16/2012 9:55 AM, Seth Mattinen wrote:
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 AT&T 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
Wow... my brain hurts after reading that. The saddest part is, there are folks with IPv6 allocations that simply refuse to implement dual stack.
I think Owen's head may explode if he reads it. ~Seth
On Sun, 16 Sep 2012, John T. Yocum wrote:
Wow... my brain hurts after reading that. The saddest part is, there are folks with IPv6 allocations that simply refuse to implement dual stack.
Agreed. I'm dual-stacked at work, and things work just fine. The only gripe I heard when dual-stack was turned on was that some sites were a bit slower to respond, because some OSs were trying to resolve DNS requests serially. Beyond that, smooth sailing... jms
There are some pretty impressive quotes there to take away ..
"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."
If I am understanding this quote correctly the author is worried IPv6 will run out of addresses so won't make the switch... Granted only 1/8th of the IPv6 space has been allocated for internet use but that number is still so mind-boggling _huge_.. But what does worry me is a lot of peoples inability to future proof themselves, it seems a lot of people would rather wait until its too late or things are falling apart and react rather than protectively getting a migration or even support package in place in-case v4 just "stops working". And by "stops working" I mean some big service provider decides to shoot itself in the foot and just switch off IPv4 support for their services, not likely to happen any-time in the near future but still a possibility. -- mitch On 16/09/12 17:55, Seth Mattinen wrote:
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 AT&T 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
On 9/16/12, John Mitchell <mitch@illuminati.org> wrote:
If I am understanding this quote correctly the author is worried IPv6 will run out of addresses so won't make the switch... Granted only 1/8th of the IPv6 space has been allocated for internet use but that number is still so mind-boggling _huge_..
I would suggest it's irrational thinking resulting from negative experience with IPv4. The rate of IPv6 exhaustion depends on how the resource is managed, and the method of resource management can change, if the rate of consumption is higher than expected. There is not a coherent credible mathematical argument for exhaustion risk of IPv6 that has been made, you would have to make assumptions about what resource management policy and demands will be now and in the future, and there are no published models of IPv6 consumption i've seen. Anyways, if it becomes a problem in the future, there would be plenty of time to create a new protocol, or using an existing protocol using NSAP addresses. Right now, IPV6 is the coherent option we've got. It's not reasonable to infer IPv6 suffers the same address shortage problem within 100 years, until there is a coherent model. We have not even heard about 48-bit MAC addresses being on the verge of exhaustion yet, obviously because there is no apparent danger for the forseeable future, and IPv6 has 64 bits available for network identification and 128 bits available for host identification..... -- -JH
If I am understanding this quote correctly the author is worried IPv6 will run out of addresses so won't make the switch... Granted only 1/8th of the IPv6 space has been allocated for internet use but that number is still so mind-boggling _huge_..
I would suggest it's irrational thinking resulting from negative experience with IPv4.
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. R's, John PS: For anyone planning to suggest that we just ignore the low 64 bits, that doesn't help.
On 9/16/12, John Levine <johnl@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. What do you mean by suggesting IPv4 abuse management techniques to map whose doing what, where do not scale to IPv6's larger address space? There's no reason you can't provide accurate WHOIS information with the larger address space..
R's, John -- -JH
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.
What do you mean by suggesting IPv4 abuse management techniques to map whose doing what, where do not scale to IPv6's larger address space?
Large networks keep separate reputation for every address in the IPv4 address space based on the traffic they send. You can't do that in IPv6, particularly since hostile bots can easily hop around within a /64, which is bad news if that /64 also has some legit hosts. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly
On 9/16/12, John R. Levine <johnl@iecc.com> wrote:
Large networks keep separate reputation for every address in the IPv4 address space based on the traffic they send. You can't do that in IPv6,
That's true, but not an intended system for identifying and reporting abuse, and the same idea occurs with IPv4 -- bots can just grab other IP addresses in the subnet, if there are not local protections in place to ensure a host cannot ARP an IP that is not assigned to it... So keep track of reputation of legitimate hosts instead of "non-legitimate" hosts. Maintain negative reputation at a /64 or shorter prefix level, and favorable reputation at a /128 level. If you have abuse detected on a /64, then treat the entire /64 as having a damaged reputation, except for the /128s on the /64 that have a prior positive reputation. The identical thing cannot be done with IPv6, but reputation systems are still possible.
Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly -- -JH
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.
What do you mean by suggesting IPv4 abuse management techniques to map whose doing what, where do not scale to IPv6's larger address space?
Large networks keep separate reputation for every address in the IPv4 address space based on the traffic they send. You can't do that in IPv6,
On Sep 16, 2012 6:58 PM, "John R. Levine" <johnl@iecc.com> wrote: particularly since hostile bots can easily hop around within a /64, which is bad news if that /64 also has some legit hosts. Of course, as soon as CGN (or LSN or NAT444) is added to IPv4 the same problem exists in practice as well as theory. So old practices will have to be improved and replaced regardless.
On Sep 16, 2012, at 16:58 , John R. Levine <johnl@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
[ 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
On 9/16/12, Randy Bush <randy@psg.com> wrote:
and don't bs me with how humongous the v6 address space is. we once though 32 bits was humongous. [snip]
When you consider that IPv6 is a 64-bit address space, that is 64 bits are for addressing subnetworks, the "/64 spend" for addressing hosts within a network as compared to v4 is 0%, not 50%. And there are twice as many IPv6 bits for addressing such /64s, as the entire IPv4 address space. 2^64 minus 2^32 is a humongous number indeed, and we know numerically just how humongous it is. The RIRs can collectively hand out 450 /32s a day or one /24 and one /25's worth a day, for the next 100 years, before a single /8 would be exhausted. And if IPv6 addressing resources last 100 years, I would say, that the objective was more than met.
randy -- -JH
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. 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" ? 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. 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. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Mon, 17 Sep 2012, Randy Bush wrote:
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.
yep. but we dis some wisp hacker for saying so. not cool.
I have to admit I never read the forum text so I don't know exactly what was said. I don't see IPv6 getting screwed up the next 50-100 years (even humanity as it is can't be THAT wreckless?), so not adopting IPv6 and clinging to IPv4 for that reason is hard to understand from my point of view. We know IPv4 isn't enough for our needs, IPv6 might not be the "forever" solution, but it surely scales a lot better than IPv4. Otoh if I ran a low-cost operations on a shoestring budget I probably wouldn't be adopting IPv6 right now anyway, but for other reasons than IPv6 being "not scalable". -- Mikael Abrahamsson email: swmike@swm.pp.se
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
On 9/16/12 9:22 PM, Mikael Abrahamsson wrote: 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.
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
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-reall... one of the things it talks about is the /64 and /48 allocation. <snip> 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
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" <mitch@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.
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
<snip> 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
In article <CAArzuotqwgpBw46+xb1ngmcN1YrYTtpYgyYmPPxPQQuG9K6BdQ@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
On 9/17/2012 4:32 PM, John Levine wrote:
In article <CAArzuotqwgpBw46+xb1ngmcN1YrYTtpYgyYmPPxPQQuG9K6BdQ@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
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:randy@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
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:randy@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, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly
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" <johnl@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:randy@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, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly
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.herbert@gmail.com>wrote:
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" <johnl@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:randy@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, johnl@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 au<jason.leschnik@ansto.gov.au> [U@] jml974@uow.edu.au
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. McIntosh bhm@ufl.edu Senior Network Engineer http://net-services.ufl.edu University of Florida CNS/Network Services 352-273-1066
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.herbert@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" <johnl@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:randy@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, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly
On 17 Sep 2012, at 13:28, John Mitchell <mitch@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
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 <mitch@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
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 <mitch@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 <mitch@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
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
Hi, On 17 Sep 2012, at 15:02, Nick Hilliard <nick@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.
RIPE 552 (I think), allows you to request up to a /29 without additional justification if needed. Mike -----Original Message----- From: Adrian Bool [mailto:aid@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 <nick@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.
Hi Mike, On 17 Sep 2012, at 16:04, Mike Simkins <mike.simkins@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
On 9/17/12 8:23 AM, Adrian Bool wrote:
Hi Mike,
On 17 Sep 2012, at 16:04, Mike Simkins <mike.simkins@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
On Mon, Sep 17, 2012 at 9:55 AM, Adrian Bool <aid@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
On 17 Sep 2012, at 15:55, Adrian Bool <aid@logic.org.uk> wrote:
Hi,
On 17 Sep 2012, at 15:02, Nick Hilliard <nick@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
On Sep 17, 2012, at 08:16 , Mark Blackman <mark@exonetric.com> wrote:
On 17 Sep 2012, at 15:55, Adrian Bool <aid@logic.org.uk> wrote:
Hi,
On 17 Sep 2012, at 15:02, Nick Hilliard <nick@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
On Sep 17, 2012, at 07:55 , Adrian Bool <aid@logic.org.uk> wrote:
Hi,
On 17 Sep 2012, at 15:02, Nick Hilliard <nick@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
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
On Sep 17, 2012, at 08:18 , Matthew Kaufman <matthew@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
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:eugen@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 ;)
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 <blake@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:eugen@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 ;)
http://www.antipope.org/charlie/blog-static/2012/08/how-low-power-can-you-go... 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 <blake@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:eugen@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 ;)
On Sep 17, 2012, at 12:54 , Eugen Leitl <eugen@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
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
H On Sep 18, 2012, at 11:01 AM, "Beeman, Davis" <Davis.Beeman@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
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
On Sep 18, 2012, at 12:38 PM, Jason Baugher <jason@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.cutler@consultant.com
On 9/18/2012 11:47 AM, Cutler James R wrote:
On Sep 18, 2012, at 12:38 PM, Jason Baugher <jason@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.cutler@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
On Sep 18, 2012, at 12:57 PM, Jason Baugher <jason@thebaughers.com> wrote:
On 9/18/2012 11:47 AM, Cutler James R wrote:
On Sep 18, 2012, at 12:38 PM, Jason Baugher <jason@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.cutler@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-networ...) show throughput results in relatively small bits per second. I'll reserve retraction for another year or so.
On 9/18/2012 12:07 PM, Cutler James R wrote:
On Sep 18, 2012, at 12:57 PM, Jason Baugher <jason@thebaughers.com> wrote:
On 9/18/2012 11:47 AM, Cutler James R wrote:
On Sep 18, 2012, at 12:38 PM, Jason Baugher <jason@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.cutler@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-networ...) 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
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.
On Sep 18, 2012, at 1:55 PM, Joe Hamelin <joe@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.cutler@consultant.com
On Sep 18, 2012, at 09:38 , Jason Baugher <jason@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
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.Beeman@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
On Sep 17, 2012, at 08:18 , Matthew Kaufman <matthew@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
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
On Sep 17, 2012, at 16:41 , Masataka Ohta <mohta@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
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
On Sep 16, 2012, at 20:23 , Randy Bush <randy@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
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 <owen@delong.com> wrote:
On Sep 16, 2012, at 20:23 , Randy Bush <randy@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.
On Mon, Sep 17, 2012 at 2:16 PM, Owen DeLong <owen@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 ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Sep 17, 2012, at 23:35 , William Herrin <bill@herrin.us> wrote:
On Mon, Sep 17, 2012 at 2:16 PM, Owen DeLong <owen@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
On Tue, Sep 18, 2012 at 11:39 AM, <Valdis.Kletnieks@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 <owen@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 ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
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....
In message <34689.1348009609@turing-police.cc.vt.edu>, Valdis.Kletnieks@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: marka@isc.org
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 <bill@herrin.us> wrote:
On Tue, Sep 18, 2012 at 11:39 AM, <Valdis.Kletnieks@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 <owen@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 ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
You will always have someone who doesn't understand. But every network operator should have a sense of responsibility to learn IPv6 and implement dual stacking. To be honest, in 2004/2005 I decided not to dive into IPv6 heavily but everyone has a "wake up" call. All we can do is keep stressing the urgency to implement IPv6 period. Not all UBNT users have a want to implement IPv4. Considering, that its easy, simple, affordable wireless gear. The result, pretty much anyone wanting to start a WISP and make money with none to little network experience, let alone the responsibility period to implement BCPs or follow RFCs. Further, most o f the users that use UBNT gear, IMHO mostly have space from their upstreams and not PI. Although, is probably a small point but it still adds to the IPv4 table end of day. I'd have to say there are moderators and users pushing IPv6 on the forum. It was a good move for UBNT on the latest release of firmware. So, I guess that's the "wake up" call those operators using UBNT (not IPv6 already) needed. But then again you will have those that say "if it ain't broke, don't fix it". Otis -----Original Message----- From: Seth Mattinen [mailto:sethm@rollernet.us] Sent: Sunday, September 16, 2012 11:55 AM To: nanog@nanog.org Subject: 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 AT&T 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
We should support dual stack, as someone may stop supporting IPv4 in addition to IPv6, because dual stack costs so much. :-) Masataka Ohta
On 9/16/12 9:55 AM, Seth Mattinen wrote:
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 AT&T going IPv6 (which I'm sure but they're slow), but these small operators are a much bigger problem.
It was brought to my attention that the second link isn't open to the public, sorry about that, I forgot to check them in a separate browser. The attitudes are the same though. ~Seth
Let me shed some light here..... (Being familiar with both communities... Nanog and WISP's ) WISP's are a very special breed of folks. There are a few common attributes that one has to recognize about them. 1. Most WISP's are not Technical Folks. (Most of them are Farmers or from other totally non-technical fields). 2. Most of them became operators not because they wanted to or it made business sense. but simply because there was not Service available in that area. 3. They are very hardworking, innovative group, but at the same time they are also a bit on the 'eccentric' side when comes to technology, and understanding technology. 4. Most of them have outsourced folks managing their networks. (these folks are very qualified and familiar with networking) So, in contrast, while NANOG community is full of folks who develop / write RFC's for Global networks, WISP community is mostly Rural folks who were forced to 'piece a network' together because no-one would serve them.... Don't be alarmed by the discussion on UBNT list or any other WISP list.....Most WISP's are typically very small network operators (sub 500 subscribers, there are some large ones too but their opinions and technical understanding is very different.) and tend to setup their network the 'Easy way'.... You will find them to be about the very last folks to adapt IPv6...(to make my case and point .... A lot of them are still running Bridge Networks, and just starting to convert to Routed Networks). They are not known for Leading Edge network operators with the exception of when it comes to 'Wireless Radios'. A lot of them are very comfortable with using Private IP's and NAT to provide service to their customers. Worry about them .... No need. Need for Education on IPv6 ... Absolutely Yes.... We all can use as much as we can get. And, we all are also hampered by IPv6 support / or lack of it, from the equipment mfg. that we are using in our networks. Hope this makes sense. Faisal Imtiaz Snappy Internet & Telecom On 9/16/2012 1:43 PM, Seth Mattinen wrote:
On 9/16/12 9:55 AM, Seth Mattinen wrote:
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 AT&T going IPv6 (which I'm sure but they're slow), but these small operators are a much bigger problem.
It was brought to my attention that the second link isn't open to the public, sorry about that, I forgot to check them in a separate browser. The attitudes are the same though.
~Seth
Very good points. Having been in the WISP industry for more than 10 years now. I know WISPs who have thousands of customers and only 1 or 2 class C addresses. The need for public routable IP addresses is not that much of a concern for them. Plus, a good majority of WISP equipment does not support IPV6. Sure a WISP is technically an ISP but, like Faisal says, its a much different business. Justin -----Original Message----- From: Faisal Imtiaz <faisal@snappydsl.net> Reply-To: <Faisal@snappydsl.net> Date: Sunday, September 16, 2012 2:29 PM To: <nanog@nanog.org> Subject: Re: IPv6 Ignorance
Let me shed some light here..... (Being familiar with both communities... Nanog and WISP's )
WISP's are a very special breed of folks. There are a few common attributes that one has to recognize about them. 1. Most WISP's are not Technical Folks. (Most of them are Farmers or from other totally non-technical fields). 2. Most of them became operators not because they wanted to or it made business sense. but simply because there was not Service available in that area. 3. They are very hardworking, innovative group, but at the same time they are also a bit on the 'eccentric' side when comes to technology, and understanding technology. 4. Most of them have outsourced folks managing their networks. (these folks are very qualified and familiar with networking)
So, in contrast, while NANOG community is full of folks who develop / write RFC's for Global networks, WISP community is mostly Rural folks who were forced to 'piece a network' together because no-one would serve them....
Don't be alarmed by the discussion on UBNT list or any other WISP list.....Most WISP's are typically very small network operators (sub 500 subscribers, there are some large ones too but their opinions and technical understanding is very different.) and tend to setup their network the 'Easy way'.... You will find them to be about the very last folks to adapt IPv6...(to make my case and point .... A lot of them are still running Bridge Networks, and just starting to convert to Routed Networks). They are not known for Leading Edge network operators with the exception of when it comes to 'Wireless Radios'.
A lot of them are very comfortable with using Private IP's and NAT to provide service to their customers.
Worry about them .... No need. Need for Education on IPv6 ... Absolutely Yes.... We all can use as much as we can get. And, we all are also hampered by IPv6 support / or lack of it, from the equipment mfg. that we are using in our networks.
Hope this makes sense.
Faisal Imtiaz Snappy Internet & Telecom
On 9/16/2012 1:43 PM, Seth Mattinen wrote:
On 9/16/12 9:55 AM, Seth Mattinen wrote:
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 AT&T going IPv6 (which I'm sure but they're slow), but these small operators are a much bigger problem.
It was brought to my attention that the second link isn't open to the public, sorry about that, I forgot to check them in a separate browser. The attitudes are the same though.
~Seth
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
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 <tal@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 au<jason.leschnik@ansto.gov.au> [U@] jml974@uow.edu.au
On Sep 17, 2012 5:04 AM, "Tom Limoncelli" <tal@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
In message <CAD6AjGRbGK8FZLz-TpL3OGO4trEZ917SBVC_D9YhH9M28fN5oQ@mail.gmail.com> , Cameron Byrne writes:
On Sep 17, 2012 5:04 AM, "Tom Limoncelli" <tal@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: marka@isc.org
Seth Mattinen <sethm@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
On Tue, Sep 18, 2012 at 9:21 AM, Robert E. Seastrom <rs@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
On Sep 18, 2012, at 10:58 AM, Steve Meuse <smeuse@mara.org> wrote:
On Tue, Sep 18, 2012 at 9:21 AM, Robert E. Seastrom <rs@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
On Tue, Sep 18, 2012 at 11:08 AM, Jared Mauch <jared@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
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 <smeuse@mara.org> wrote:
On Tue, Sep 18, 2012 at 11:08 AM, Jared Mauch <jared@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
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
In message <86lig7cvpw.fsf@seastrom.com>, "Robert E. Seastrom" writes:
Seth Mattinen <sethm@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: marka@isc.org
participants (44)
-
Adrian Bool -
Beeman, Davis -
Blake Dunlap -
Blake Pfankuch -
Bruce H McIntosh -
Cameron Byrne -
Cutler James R -
Dan Wood -
Eugen Leitl -
Faisal Imtiaz -
George Herbert -
Jared Mauch -
Jason Baugher -
Jason Leschnik -
Jimmy Hess -
Joe Hamelin -
joel jaeggli -
John Levine -
John Mitchell -
John R. Levine
-
John T. Yocum -
joseph.snyder＠gmail.com -
Justin M. Streiner -
Justin Wilson -
Mark Andrews -
Mark Blackman -
Masataka Ohta -
Matthew Kaufman -
Michael Thomas -
Mikael Abrahamsson -
Mike Simkins -
Nick Hilliard -
Otis L. Surratt, Jr. -
Owen DeLong -
Randy Bush -
Robert E. Seastrom -
Seth Mattinen -
Steve Meuse -
Suresh Ramasubramanian -
Timothy Morizot -
Tom Limoncelli -
Tomas L. Byrnes -
Valdis.Kletnieks＠vt.edu -
William Herrin