APNIC just got another IPv4 /8 thus only 5 left: http://www.nro.net/media/remaining-ipv4-address-below-5.html (And the spammers will take the rest...) So, if your company is not doing IPv6 yet, you really are really getting late now. Greets, Jeroen (PS: There seems to be a trend for people calling themselves"IPv6 Pioneers" as they recently did something with IPv6, if you didn't play in the 6bone/early-RIR allocs you are not a pioneer as you are 10 years late)
Jeroen Massar wrote:
APNIC just got another IPv4 /8 thus only 5 left:
http://www.nro.net/media/remaining-ipv4-address-below-5.html (And the spammers will take the rest...)
Just for clarification, that article says 5% left, not 5x /8. According to Leo's E-mail earlier, they have 12 /8s left in the free pool. And +1 on the "pioneers" comment too. Paul.
On Oct 18, 2010, at 5:28 AM, Curtis Maurand wrote:
On 10/18/2010 8:16 AM, ML wrote:
And +1 on the "pioneers" comment too.
Paul.
IPv6 Hipsters..Doing it before it was cool.
IPV4 ->easy(); IPV6->really().Really().Difficult();
Have you done IPv6? I have... It's not even difficult(), let alone really().Really().Difficult(). Owen
* Owen DeLong <owen@delong.com> [2010-10-18 17:27]:
Have you done IPv6? I have... It's not even difficult(), let alone really().Really().Difficult().
maybe not from a users standpoint (that comes later when it misbehaves again). from an implementors (I have written a lot of kernel-side networking code and networking related daemons, including a full-blown bgpd, and that unfortunately included having to deal with v6) viewpoint - IPv6 is a desaster. Why people take up that crap is beyond me, instead of working on a viable alternative that doesn't suck. Which is certainly possible. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
On Oct 18, 2010, at 11:35 AM, Henning Brauer wrote:
* Owen DeLong <owen@delong.com> [2010-10-18 17:27]:
Have you done IPv6? I have... It's not even difficult(), let alone really().Really().Difficult().
maybe not from a users standpoint (that comes later when it misbehaves again). from an implementors (I have written a lot of kernel-side networking code and networking related daemons, including a full-blown bgpd, and that unfortunately included having to deal with v6) viewpoint - IPv6 is a desaster. Why people take up that crap is beyond me, instead of working on a viable alternative that doesn't suck. Which is certainly possible.
Most of that junk can honestly be ignored. :) - Jared
-----Original Message----- From: Henning Brauer Sent: Monday, October 18, 2010 8:36 AM To: nanog@nanog.org Subject: Re: Only 5x IPv4 /8 remaining at IANA
instead of working on a viable alternative that doesn't suck. Which is certainly possible.
I would say that at this point it is too late to resist v6 deployment but it might be a good time to work on the "next thing" and use v6 as an example of how not to do it next time. It certainly is going to present some security challenges for some folks, particularly the ones that have been using dynamic nat pools to, in effect, block inbound connections. Firewall vendors are going to see a windfall from v6, I think. G
On Oct 18, 2010, at 8:47 AM, George Bonser wrote:
-----Original Message----- From: Henning Brauer Sent: Monday, October 18, 2010 8:36 AM To: nanog@nanog.org Subject: Re: Only 5x IPv4 /8 remaining at IANA
instead of working on a viable alternative that doesn't suck. Which is certainly possible.
I would say that at this point it is too late to resist v6 deployment but it might be a good time to work on the "next thing" and use v6 as an example of how not to do it next time.
It certainly is going to present some security challenges for some folks, particularly the ones that have been using dynamic nat pools to, in effect, block inbound connections. Firewall vendors are going to see a windfall from v6, I think.
G
Nobody is using dynamic nat pools to block inbound connections. Many people are using dynamic NAT on top of stateful inspection where stateful inspection blocks inbound connections. The good news is that stateful inspection doesn't go away in IPv6. It works just fine. All that goes away is the header mangling. It's really unfortunate that most people don't understand the distinction. If they did, it would help them to realize that NAT doesn't actually do anything for security, it just helps with address conservation (although it has some limits there, as well). IPv6 with SI is no less secure than IPv4 with SI+NAT. If you're worried about address and/or topological obfuscation, then, IPv6 offers you privacy addresses with rotating numbers. However, that's more a privacy issue than a security issue, unless you believe in the idea of security through obscurity which is pretty well proven false. Owen
Owen DeLong wrote:
...
It's really unfortunate that most people don't understand the distinction. If they did, it would help them to realize that NAT doesn't actually do anything for security, it just helps with address conservation (although it has some limits there, as well).
Actually nat does something for security, it decimates it. Any 'real' security system (physical, technology, ...) includes some form of audit trail. NAT explicitly breaks any form of audit trail, unless you are the one operating the header mangling device. Given that there is no limit to the number of nat devices along a path, there can be no limit to the number of people operating them. This means there is no audit trail, and therefore NO SECURITY.
IPv6 with SI is no less secure than IPv4 with SI+NAT. If you're worried about address and/or topological obfuscation, then, IPv6 offers you privacy addresses with rotating numbers. However, that's more a privacy issue than a security issue, unless you believe in the idea of security through obscurity which is pretty well proven false.
A different way to look at this is less about obscurity, and more about reducing your overall attack surface. A node using a temporal address is vulnerable while that address is live, but as soon as it is released that attack vector goes away. Attackers that harvest addresses through the variety of transactions that a node my conduct will have a limited period of time to try to exploit that. This is not to say that you don't want stateful controls, just that if something inside the stateful firewall has been compromised there will be a limited period of time to use the dated knowledge. Tony
-----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Monday, October 18, 2010 9:25 AM To: George Bonser Cc: Henning Brauer; nanog@nanog.org Subject: Re: Only 5x IPv4 /8 remaining at IANA
Nobody is using dynamic nat pools to block inbound connections.
Many people are using dynamic NAT on top of stateful inspection where stateful inspection blocks inbound connections.
The good news is that stateful inspection doesn't go away in IPv6. It works just fine. All that goes away is the header mangling.
Exactly true but there are people out there who experience it as "dynamic nat prevents inbound connections". And the extent to which state is inspected varies widely on different gear (is it just looking for an ACK flag to determine an "established" connection or is it making sure that at least one packet has gone in the other direction first?). At least with dynamic (overload) NAT, a packet had to travel in the opposite (outbound) direction in order to establish the NAT in the first place. Then with an "established" acl, the two things give you fairly decent assurance that things went as planned but are still not a substitute for packet inspection.
It's really unfortunate that most people don't understand the distinction.
Concur.
IPv6 with SI is no less secure than IPv4 with SI+NAT.
Yup, the difference is going to be the extent to which the state is inspected in various gear. Again, I believe firewall vendors are going to see a windfall here. And to address your comment in an email subsequent to this one about accounting, I wholeheartedly agree. NAT can make it much more difficult to find what is causing a problem or even who is talking to whom.
On Oct 18, 2010, at 10:52 AM, George Bonser wrote:
-----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Monday, October 18, 2010 9:25 AM To: George Bonser Cc: Henning Brauer; nanog@nanog.org Subject: Re: Only 5x IPv4 /8 remaining at IANA
Nobody is using dynamic nat pools to block inbound connections.
Many people are using dynamic NAT on top of stateful inspection where stateful inspection blocks inbound connections.
The good news is that stateful inspection doesn't go away in IPv6. It works just fine. All that goes away is the header mangling.
Exactly true but there are people out there who experience it as "dynamic nat prevents inbound connections". And the extent to which state is inspected varies widely on different gear (is it just looking for an ACK flag to determine an "established" connection or is it making sure that at least one packet has gone in the other direction first?).
Looking for an ACK flag isn't Stateful inspection. Stateful inspection involves comparison against a state table of known connections. People perceive many things that are combined as having the systemic effect without understanding which component actually performs which underlying function. In cases where that doesn't matter, it's not an issue. In IPv4, it didn't matter if people understood the difference between security provided by stateful inspection and security eliminated by NAT. Now, it matters because some people are claiming IPv6 is less secure as a result of the lack of NAT. This claim comes from the misunderstanding you have restated above.
At least with dynamic (overload) NAT, a packet had to travel in the opposite (outbound) direction in order to establish the NAT in the first place. Then with an "established" acl, the two things give you fairly
This is true of stateful inspection as well. Stateful inspection != static packet filters. It's not the same thing. The ACK flag test you describe above is a static packet filter, not stateful inspection.
decent assurance that things went as planned but are still not a substitute for packet inspection.
Again, this doesn't come form the overloaded NAT. It comes from the state table mechanism and the comparison of the packet against known flows in the state table. While NAT requires this underlying state table to function, there is nothing preventing implementation of that state table without NAT. Such an implementation is equally secure without NAT. In fact, it's slightly better because NAT destroys audit trail while SI without NAT does not.
It's really unfortunate that most people don't understand the distinction.
Concur.
IPv6 with SI is no less secure than IPv4 with SI+NAT.
Yup, the difference is going to be the extent to which the state is inspected in various gear. Again, I believe firewall vendors are going to see a windfall here.
You are confusing SI with Packet Filters. The technologies are different and it is, also, important to understand this distinction as well.
And to address your comment in an email subsequent to this one about accounting, I wholeheartedly agree. NAT can make it much more difficult to find what is causing a problem or even who is talking to whom.
Actually, that was Tony Hain's comment, but, yes, he's correct. Owen
You are confusing SI with Packet Filters. The technologies are different and it is, also, important to understand this distinction as well.
I don't think I am "confusing" the two. I am saying that I have seen people use them and think they are secure when they aren't. IPv6 is going to make it a little harder for people to make this mistake (or easier to make it, I haven't decided yet which way it will go) and you will see more people purchasing equipment that does real state inspection which is my reason for predicting an increase in firewall sales. They won't have that dynamic NAT that lulls some into a false sense of security. Also, I believe the "fire suit" approach will become more important to people rather than the "fire wall" approach with IPv6. G
On Mon, 18 Oct 2010 11:41:09 -0700 "George Bonser" <gbonser@seven.com> wrote:
You are confusing SI with Packet Filters. The technologies are different and it is, also, important to understand this distinction as well.
I don't think I am "confusing" the two. I am saying that I have seen people use them and think they are secure when they aren't. IPv6 is going to make it a little harder for people to make this mistake (or easier to make it, I haven't decided yet which way it will go) and you will see more people purchasing equipment that does real state inspection which is my reason for predicting an increase in firewall sales. They won't have that dynamic NAT that lulls some into a false sense of security.
Also, I believe the "fire suit" approach will become more important to people rather than the "fire wall" approach with IPv6.
That's a great way of saying "host based security". With mobile Internet devices (smart phones, laptops (which outsold desktops last year apparently) etc.) becoming the dominant Internet access device, I think host based firewalling will become the primary "firewalling" mechanism. Network located firewalls will perform a secondary and assistant role, because hosts can't be sure they're there when the hosts have wired, wifi, bluetooth etc. interfaces that can all be actively connected to the Internet at the same time. Regards, Mark.
On Mon, 18 Oct 2010 10:52:18 PDT, George Bonser said:
From: Owen DeLong [mailto:owen@delong.com] The good news is that stateful inspection doesn't go away in IPv6. It works just fine. All that goes away is the header mangling.
Exactly true but there are people out there who experience it as "dynamic nat prevents inbound connections".
Those people are next on my hit list, after we've finally eliminated those who still talk about class A/B/C addresses. :)
On 10/18/2010 5:46 PM, Valdis.Kletnieks@vt.edu wrote:
On Mon, 18 Oct 2010 10:52:18 PDT, George Bonser said: Those people are next on my hit list, after we've finally eliminated those who still talk about class A/B/C addresses. :)
IPv6 isn't going to make class-based routing obsolete... is it? *ducks* cheers! Andrew
Valdis.Kletnieks@vt.edu writes:
Those people are next on my hit list, after we've finally eliminated those who still talk about class A/B/C addresses. :)
You are going to kill about 90% of all net-/sysadmins? SCNR Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@guug.de | ------------------- | -------------------------------------------------------------------------
On Tue, 19 Oct 2010 13:49:10 +0200, Jens Link said:
Valdis.Kletnieks@vt.edu writes:
Those people are next on my hit list, after we've finally eliminated those who still talk about class A/B/C addresses. :)
You are going to kill about 90% of all net-/sysadmins?
Do you *really* want somebody working on your network that gets confused by a reference to 213/8 because it's in Class-C space? Either they haven't taken the 20 minutes it takes to learn how CIDR works, or they're unable to learn it. Either way, they shouldn't be working on your network. And "Cisco is still teaching it" is *not* an excuse - I'd expect a competent network engineer to show enough intellectual curiosity to say "I keep seeing references to 199.14/19, what the heck is that?" Heck, I've had Oracle DBAs ask me about "What's this /22 network mask all about?" and explained it in under 5 minutes. (Hint to Cisco and others - any training course that includes 'Class A/B/C' is likely to be perceived as "dangerously last-century oriented". We had a 3rd-party training class on some Cisco fiberchannel directors, and the instructor mentioned class A/B/C - and immediately lost a whole chunk of credibility, making us wonder what *else* was being mis-taught). Class A/B/C - modern networking's version of a brown M&M backstage at a Van Halen concert.
Do you *really* want somebody working on your network that gets confused by a reference to 213/8 because it's in Class-C space?
Or spots an address which uses letters and colons and looks syntactically incorrect to them? Do you really want untrained people working on your network? -- David Freedman Group Network Engineering Claranet Group
On 19 October 2010 14:12, <Valdis.Kletnieks@vt.edu> wrote:
Do you *really* want somebody working on your network that gets confused by a reference to 213/8 because it's in Class-C space?
I've met people who just assume anything with a 24-bit netmask is a Class C network. For instance: "Can I have another Class C out of 83.x please?" No, and neither can anyone else... What's more is that they'll not use .0, .255, .1 (because apparently only routers are supposed to use that), .254 (who knows...) M
I would say for most of our customers, especially in the hosting space, a "class C" is a /24, they just don't know networking at all and build their hosting lans using /24s for each vlan. Very few of the requests that we get are submitted using CIDR notation. Personally, I think this is a big reason for random table bloat, I have had so many arguments about customers being able to aggregate announcements for BGP it is not even funny... the "I want to announce the blocks as a class Cs" request is irritatingly common. John -----Original Message----- From: Matthew Walster [mailto:matthew@walster.org] Sent: Tuesday, October 19, 2010 7:53 AM To: nanog list Subject: Re: Only 5x IPv4 /8 remaining at IANA On 19 October 2010 14:12, <Valdis.Kletnieks@vt.edu> wrote:
Do you *really* want somebody working on your network that gets confused by a reference to 213/8 because it's in Class-C space?
I've met people who just assume anything with a 24-bit netmask is a Class C network. For instance: "Can I have another Class C out of 83.x please?" No, and neither can anyone else... What's more is that they'll not use .0, .255, .1 (because apparently only routers are supposed to use that), .254 (who knows...) M
On 10/19/2010 10:15 AM, John van Oppen wrote:
I would say for most of our customers, especially in the hosting space, a "class C" is a /24, they just don't know networking at all and build their hosting lans using /24s for each vlan.
Very few of the requests that we get are submitted using CIDR notation. Personally, I think this is a big reason for random table bloat, I have had so many arguments about customers being able to aggregate announcements for BGP it is not even funny... the "I want to announce the blocks as a class Cs" request is irritatingly common.
It's been our general policy to always respond in CIDR notation whenever we get a request in class notation and to hope that our customers either figure out what that means on their own or ask us for clarification and learn something. IPv6 is helping because a lot of people seem to be making the connection that the "slash" notation is related between the two. -- Kevin Stange Chief Technology Officer Steadfast Networks http://steadfast.net Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867
On 20/10/10 01:52, Matthew Walster wrote:
No, and neither can anyone else... What's more is that they'll not use .0, .255, .1 (because apparently only routers are supposed to use that), .254 (who knows...)
There's actually a good reason for that. MS Windows (at least 2k3 server) will simply drop packets with a source address of .0 or .255 coming from the legacy class C space, this hit us with some Win 2k3 servers that for a bunch of stupid reasons needed to be connected to from natted hosts, and the next pool IP off the pile was a .255 address somewhere in 192.168.0.0/16. Took quite a while to diagnose as wireshark on the host wouldn't see the packet, but eventually we could verify the packet made it all the way to the machine. The fact that this may be UI in 2010 is very depressing, and a prime example of why there's no way the "class-E" space will ever be generally usable. Julien
On Wed, 2010-10-20 at 11:18 +1100, Julien Goodwin wrote:
MS Windows (at least 2k3 server) will simply drop packets with a source address of .0 or .255 coming from the legacy class C space, this hit us with some Win 2k3 servers that for a bunch of stupid reasons needed to be connected to from natted hosts, and the next pool IP off the pile was a .255 address somewhere in 192.168.0.0/16. Took quite a while to
thanks for explaining the reason for a total waste of 3 hours of my life recently, on a /22 in my case, after a large-scale merger of 1918's I had to replace it with a netinst + Postfix install to get stuff moving again. Did MS understand classless in '03? do they now?
Valdis.Kletnieks@vt.edu writes:
You are going to kill about 90% of all net-/sysadmins?
Do you *really* want somebody working on your network that gets confused by a reference to 213/8 because it's in Class-C space?
Don't get me wrong. I like the idea. Especially after the discussion I had with someone this afternoon.
And "Cisco is still teaching it" is *not* an excuse
Windows and Linux ifconfig are still using it. Enter a Class-A/B/C address and take a look at the mask they suggest. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@guug.de | ------------------- | -------------------------------------------------------------------------
On Tue, 19 Oct 2010 22:24:02 +0200 Jens Link <lists@quux.de> wrote:
Valdis.Kletnieks@vt.edu writes:
You are going to kill about 90% of all net-/sysadmins?
Do you *really* want somebody working on your network that gets confused by a reference to 213/8 because it's in Class-C space?
Don't get me wrong. I like the idea. Especially after the discussion I had with someone this afternoon.
And "Cisco is still teaching it" is *not* an excuse
Windows and Linux ifconfig are still using it. Enter a Class-A/B/C address and take a look at the mask they suggest.
Under Linux, ifconfig is probably deprecated, and just being left around for people who're used to it. iproute2 a.k.a. the 'ip' utility is the way to access/configure far more of the IP stack settings under linux. Regards, Mark.
On 10/19/10 9:24 PM, Mark Smith wrote:
On Tue, 19 Oct 2010 22:24:02 +0200 Jens Link <lists@quux.de> wrote:
Valdis.Kletnieks@vt.edu writes:
You are going to kill about 90% of all net-/sysadmins?
Do you *really* want somebody working on your network that gets confused by a reference to 213/8 because it's in Class-C space?
Don't get me wrong. I like the idea. Especially after the discussion I had with someone this afternoon.
And "Cisco is still teaching it" is *not* an excuse
Windows and Linux ifconfig are still using it. Enter a Class-A/B/C address and take a look at the mask they suggest.
Of course ifconfig will also happily take whatever mask you feed it in your choice of notation so it's not exactly a bronze age tool.
Under Linux, ifconfig is probably deprecated, and just being left around for people who're used to it. iproute2 a.k.a. the 'ip' utility is the way to access/configure far more of the IP stack settings under linux.
Regards, Mark.
On Tue, Oct 19, 2010 at 10:01:48PM -0700, Joel Jaeggli wrote:
Of course ifconfig will also happily take whatever mask you feed it in your choice of notation so it's not exactly a bronze age tool.
first - IPv6 isn't 5x IPv4, its only 4x... :) and the idea f "bronze-age" tools is generally appealing. I'm tempted to make the argument that when we are fulling using the IPv4 space, we make the general statement that the "Internet" is fully deployed. IPv4 == the Internet. IPv6 == the next big thing... to borrow a phrase - the polyphonic-net IPv4 has many decades of work, refinement, and general ammalgamation into/with what many/most of us are comfortable with wrt business models. IPv6 - while it has just over a decade of work, still has a long way to go to fulfill its promise. For the oldtimers, remember that it took IP a couple of decades to "gel" at version 4. Sure, we can (and in some cases - MUST) cram the "Internet" model on IPv6, but that is a genuine waste of opportunity. So ... can we let an IPv6-based "polyphonic-net" embrace, and subsume the old, last century Internet? Or is that asking too much of the sales/marketing droids? --bill manning
-----Original Message-----
IPv6 - while it has just over a decade of work, still has a long way to go to fulfill its promise. For the oldtimers, remember that it took IP a couple of decades to "gel" at version 4. Sure, we can (and in some cases - MUST) cram the "Internet" model on IPv6, but that is a genuine waste of opportunity.
So ... can we let an IPv6-based "polyphonic-net" embrace, and subsume the old, last century Internet? Or is that asking too much of the sales/marketing droids?
Most of the problems I have seen with v6 really aren't v6 problems. Programs and their various libraries, for example, that parse an address with a colon as a hostname is one example. Now I could even work around that by populating the local default dns domain with records that resolve to AAAA records ... if I could put a colon in a hostname (e.g. someone enters fe80::1e:dead:beef:cafe, the program looks up fe80::1e:dead:beef:cafe.my.local-domain rather than trying to connect to fe80:1e:dead:beef:cafe and dns returns with the AAAA record, that problem fixed, but I can't, so it isn't.) And even that would only work for a few commonly accessed hosts. Programs that rely on multicast will be a little different but that can be handled in dual-stack, at least in the local internal net. Now the problems with things like load balancing is real. Our vendor supports front end v6 VIPs balanced to backend v4 servers, but it requires a code update that must be tested before deployment and an outage scheduled once it has been tested. It isn't something that can just be thrown out there on a whim. The biggest cultural change is coming out of RFC1918 dungeons into the light of internet routable space and how people deal with that. It will be a very interesting time for networks, their vendors, and the engineers/techs/administrators.
On Oct 19, 2010, at 11:37 PM, George Bonser wrote:
-----Original Message-----
IPv6 - while it has just over a decade of work, still has a long way to go to fulfill its promise. For the oldtimers, remember that it took IP a couple of decades to "gel" at version 4. Sure, we can (and in some cases - MUST) cram the "Internet" model on IPv6, but that is a genuine waste of opportunity.
So ... can we let an IPv6-based "polyphonic-net" embrace, and subsume the old, last century Internet? Or is that asking too much of the sales/marketing droids?
Most of the problems I have seen with v6 really aren't v6 problems. Programs and their various libraries, for example, that parse an address with a colon as a hostname is one example. Now I could even work around that by populating the local default dns domain with records that resolve to AAAA records ... if I could put a colon in a hostname (e.g. someone enters fe80::1e:dead:beef:cafe, the program looks up fe80::1e:dead:beef:cafe.my.local-domain rather than trying to connect to fe80:1e:dead:beef:cafe and dns returns with the AAAA record, that problem fixed, but I can't, so it isn't.) And even that would only work for a few commonly accessed hosts.
Most likely a program that parses a : as a host name indicator wouldn't be able to handle the return of an AAAA record anyway. There are code changes required for IPv6 support and it is unlikely that any software which has been thus updated would have the problem you describe.
Now the problems with things like load balancing is real. Our vendor supports front end v6 VIPs balanced to backend v4 servers, but it requires a code update that must be tested before deployment and an outage scheduled once it has been tested. It isn't something that can just be thrown out there on a whim.
Sure, it lies somewhere between whim and major undertaking. Where on that path depends on the quality of your vendors' support for IPv6 and how early you start planning.
The biggest cultural change is coming out of RFC1918 dungeons into the light of internet routable space and how people deal with that. It will be a very interesting time for networks, their vendors, and the engineers/techs/administrators.
The light is good. Yes, it requires some adaptation if you've been living in the darkness of 1918 space for some time, but, once you adapt (and the adaptation is not that painful), it's actually a very useful thing. Owen
-----Original Message----- From: Owen DeLong Sent: Wednesday, October 20, 2010 12:16 AM To: George Bonser Subject: Re: Only 5x IPv4 ... WRONG! :)
On Oct 19, 2010, at 11:37 PM, George Bonser wrote: Sure, it lies somewhere between whim and major undertaking. Where on that path depends on the quality of your vendors' support for IPv6 and how early you start planning.
Even that really isn't a v6 issue so much as other changes that are often tossed in when a vendor issues a new release. Sometimes commands are deprecated, new features added, old features might clash with new ones, or features behave in slightly different ways in a new release. Sometimes the entire command syntax will change and any automation that has been done to manage/generate configurations needs to change. Again, those aren't really v6 issues, just the other odds and ends that surround upgrading stuff in order to get the needed v6 support than can impact an operation in unexpected ways. The point being that it can turn into a can of worms when you simply need the v6 feature on a bunch of stuff (hey, ever been through migrating to 8.3 Cisco ASA configuration changes?) Then there's other odds and ends like DAD not working on Ubuntu kernel 2.6.32-24-server #41 but it worked fine on 2.6.32-24-server #39 (machine responds to its own DAD probes and reports any IP you attempt to program as being "in use"). So you want to solve just one problem ... just get IPv6 on the darned net, and pretty soon you have a half-dozen projects blocking deployment. It isn't "easy" but it isn't the fault of "v6" in most cases.
-----Original Message----- From: George Bonser Sent: Wednesday, October 20, 2010 12:30 AM To: Owen DeLong Cc: nanog@nanog.org Subject: RE: Only 5x IPv4 ... WRONG! :)
It isn't "easy" but it isn't the fault of "v6" in most cases.
Put another way, the set of challenges facing the enterprise/production operator (the people who use that network to facilitate the delivery of a product ... either on the transmitting or receiving end of that delivery) is quite different from the set of challenges that face a pure network operator. And what seems so easy for one may not be so easy for the other. Dual stacking network gear is less of a problem than dual stacking hundreds or thousands of servers, special purpose appliances, software, etc. of different vendors, ages, and complexity.
On Oct 20, 2010, at 2:09 AM, George Bonser wrote:
-----Original Message----- From: George Bonser Sent: Wednesday, October 20, 2010 12:30 AM To: Owen DeLong Cc: nanog@nanog.org Subject: RE: Only 5x IPv4 ... WRONG! :)
It isn't "easy" but it isn't the fault of "v6" in most cases.
Put another way, the set of challenges facing the enterprise/production operator (the people who use that network to facilitate the delivery of a product ... either on the transmitting or receiving end of that delivery) is quite different from the set of challenges that face a pure network operator. And what seems so easy for one may not be so easy for the other.
Dual stacking network gear is less of a problem than dual stacking hundreds or thousands of servers, special purpose appliances, software, etc. of different vendors, ages, and complexity.
I'm not sure why you assume that network operators don't have hundreds or thousands of servers, special purpose appliances, software, etc. of different vendors, ages, and complexity. Yes, it's easier to dual-stack the backbone of an ISP than the entire enterprise of an ISP. That's no surprise since dual-stacking the backbone of an enterprise would be easier than dual-stacking the entire enterprise as well. However, other than some very limited exceptions, HE has dual-stacked their entire enterprise, not just their backbone. All of our public facing servers are fully dual-stacked with published AAAA records. Our customers can freely run IPv4, IPv6, or both on our managed servers and/or their own equipment in our colos. All of our IP connectivity clients have access to dual-stack services, and, we actually provide economic incentives for customers to do dual-stack rather than IPv4 only connections to us. Migrating from IPv4 to dual stack isn't going to get significantly easier by procrastinating at this point. It's only going to get more urgent. Doing something hard on a schedule is hard. Doing something hard in a rush because you failed to schedule it is harder. Owen
-----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Wednesday, October 20, 2010 2:50 AM To: George Bonser Cc: nanog@nanog.org Subject: Re: Only 5x IPv4 ... WRONG! :)
On Oct 20, 2010, at 2:09 AM, George Bonser wrote:
-----Original Message----- From: George Bonser Sent: Wednesday, October 20, 2010 12:30 AM To: Owen DeLong Cc: nanog@nanog.org Subject: RE: Only 5x IPv4 ... WRONG! :)
It isn't "easy" but it isn't the fault of "v6" in most cases.
Put another way, the set of challenges facing the
operator (the people who use that network to facilitate the delivery of a product ... either on the transmitting or receiving end of that delivery) is quite different from the set of challenges that face a
enterprise/production pure
network operator. And what seems so easy for one may not be so easy for the other.
Dual stacking network gear is less of a problem than dual stacking hundreds or thousands of servers, special purpose appliances, software, etc. of different vendors, ages, and complexity.
I'm not sure why you assume that network operators don't have hundreds or thousands of servers, special purpose appliances, software, etc. of different vendors, ages, and complexity.
Huh? I didn't assume anything. I simply said that an operation that is a pure network play is going have a different experience than an operation that has a lot of other stuff and where network is a smaller part of the overall picture. And even that is going to vary from one organization or even at different locations within an organization. A location with older gear might have a more difficult time of it.
However, other than some very limited exceptions, HE has dual-stacked their entire enterprise, not just their backbone. All of our public facing servers are fully dual-stacked with published AAAA records. Our customers can freely run IPv4, IPv6, or both on our managed servers and/or their own equipment in our colos. All of our IP connectivity clients have access to dual-stack services, and, we actually provide economic incentives for customers to do dual-stack rather than IPv4 only connections to us.
Yes, HE has made considerable investment in v6 and is a tremendous asset to the community in raising awareness, offering encouragement, education, and support in getting people to move to v6 and they "eat their own dog food". All great attributes. It is very apparent that HE "gets it" and has made a major commitment in that area. Other organizations are going to see varying amounts of traction. Hearing things like "we aren't fork lifting all the gear, it isn't like v4 is going away, that facility isn't growing, we will worry about v6 on our next buildout" aren't uncommon. I also hear things like "oh, yeah, we have talked about v6 but don't have a specific plan".
Migrating from IPv4 to dual stack isn't going to get significantly easier by procrastinating at this point. It's only going to get more urgent.
Absolutely agree. Everything anyone builds new at this point should be v6 capable. At least one shouldn't, in my opinion, let things get worse.
Doing something hard on a schedule is hard.
Particularly true if you already run a lean shop and have aggressive work schedules as it is for managing the operation. Telling another department that they are going to need to upgrade the OS (or OSes) on several hundred machines in order to accommodate what they might not perceive as a pressing need is going to depend on the level of support the effort has from the top levels of management. Other organizations are going to see the value in getting it done earlier rather than later. Fundamentally it seems that the extent to which an organization moves on this will depend on many factors and one that is pretty important is their current rate of change in relation to their current size. A large operation that is cruising along with what they have or is maybe shrinking might not want to invest a lot of time, effort, money into changing. One that is growing quickly will have less of a problem rolling out v6 in their new facilities and installing it in the older ones as they quickly outgrow that infrastructure.
Doing something hard in a rush because you failed to schedule it is harder.
Absolutely. What is driving this is an understanding on my part that the extent to which organizations adopt v6 is going to vary widely and so will the reasons for it. I interface with other organizations on a daily basis and I see the entire spectrum of v6 readiness and reasons why it is where it is with those organizations. When I hear someone say "v6 is ..." followed by something or another it has to be tempered with the understanding that while they might be making an absolute statement, that statement is relative to their situation and that same "truth" isn't going to hold for someone else. I would join you in encouraging people get things moving. If you don't at least have a plan, you need one. Now. Really. Because an increasingly large number of customers, peers, and partners are going to be operating v6 native or at least v6 capable and accommodating v4 is going to become an increasingly large pain in the hips for them.
Owen
G
On Wed, Oct 20, 2010 at 1:17 AM, <bmanning@vacation.karoshi.com> wrote:
first - IPv6 isn't 5x IPv4, its only 4x... :)
Couldn't let this one slide... Bits grow exponentially. Saying IPv6 is 4x IPv4 isn't really accurate unless you're counting bits. A 128-bit address space gives you over 340 undecillion (3.4 * 10^38) unique values compared to the pathetic 6 billion or so of a 32-bit address space. Certainly more than 4 or 5x ;-) -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
On Thu, Oct 21, 2010 at 04:43:37PM -0400, Ray Soucy wrote:
On Wed, Oct 20, 2010 at 1:17 AM, <bmanning@vacation.karoshi.com> wrote:
first - IPv6 isn't 5x IPv4, its only 4x... :)
Couldn't let this one slide...
Bits grow exponentially. Saying IPv6 is 4x IPv4 isn't really accurate unless you're counting bits.
tada! 128 == 4x32 --bill
Couldn't let this one slide...
Bits grow exponentially. Saying IPv6 is 4x IPv4 isn't really accurate unless you're counting bits.
Yep. IPv6 is 128 bits and IPv4 is 32 bits. Lots of folks can get an IPv4 /16 which gives then 16 bits to play with for subnetting. But only network operators can play this game and get this kind of allocation. Switch to IPv6 with its /64 Interface Identifier and every mom and pop can get a /48 which gives them 16 bits to play with for subnetting. In fact, their ISP with a /32 or better, also gets 16 bits for subnetting no matter how small their business. Riches upon riches for everyone to use as they please. We are all oil millionaires with IPv6 and must learn to forget the hardships of living in the dusty dunes of IPv4. There are enough bits for almost everyone to build a network that makes the most sense for their physical topology without worrying about growth, because you can leave space for growth at every level of your addressing architecture. It is only the very largest organizations who still have to be careful not to run out of subnetting bits because they can reasonably expect to justify a /20 today, but require a /18 in 5 years of growth and acquisition. On the other hand, they tend to have better people and already know how to manage IPv6. There is not much that we can teach them in this discussion, but the smaller network operators and enterprise folks would do well to pay attention and shift their thinking out of the IPv4 world and into the abundant world of IPv6. In the IPv4 world, people had to deal with the results of their own mistakes. In the IPv6 world, it will be your grandchildren and great-grandchildren who will have to deal with your mistakes and they will thank you for leaving them some real challenges and not trying to engineer away their choices. --Michael Dillon
In the IPv4 world, people had to deal with the results of their own mistakes. In the IPv6 world, it will be your grandchildren and great-grandchildren who will have to deal with your mistakes and they will thank you for leaving them some real challenges and not trying to engineer away their choices.
Nah, they'll be routing their packets over facebook. http://tools.ietf.org/html/rfc5514 -B
* Owen DeLong <owen@delong.com> [2010-10-18 18:29]:
The good news is that stateful inspection doesn't go away in IPv6.
that is right.
It works just fine. All that goes away is the header mangling.
that is partially true. it can work just fine, but all the bloat in v6 makes it way harder to implement the state tracking than it should be.
It's really unfortunate that most people don't understand the distinction. If they did, it would help them to realize that NAT doesn't actually do anything for security, it just helps with address conservation (although it has some limits there, as well).
right.
IPv6 with SI is no less secure than IPv4 with SI+NAT.
well, it is. the extension headers are horrible. the v4 mapping horror is an insane trap, too. link-local is the most horrid concept ever. all hail 160 bit addresses. all that leads to bugs in the implementations (while the bugs are really in the specification, I'd claim). the RH0 desaster was just the beginning. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
On 10/18/2010 11:19, Henning Brauer wrote:
* Owen DeLong <owen@delong.com> [2010-10-18 18:29]:
The good news is that stateful inspection doesn't go away in IPv6.
that is right.
It works just fine. All that goes away is the header mangling.
that is partially true. it can work just fine, but all the bloat in v6 makes it way harder to implement the state tracking than it should be.
What bloat? Larger address space? ~Seth
On Oct 18, 2010, at 11:19 AM, Henning Brauer wrote:
* Owen DeLong <owen@delong.com> [2010-10-18 18:29]:
The good news is that stateful inspection doesn't go away in IPv6.
that is right.
It works just fine. All that goes away is the header mangling.
that is partially true. it can work just fine, but all the bloat in v6 makes it way harder to implement the state tracking than it should be.
Actually, the state tracking in IPv6 requires a little more memory, but, it's actually easier on the silicon and has significant improvements over IPv4 for ASIC parsing of the headers.
It's really unfortunate that most people don't understand the distinction. If they did, it would help them to realize that NAT doesn't actually do anything for security, it just helps with address conservation (although it has some limits there, as well).
right.
IPv6 with SI is no less secure than IPv4 with SI+NAT.
well, it is. the extension headers are horrible. the v4 mapping horror is an insane trap, too. link-local is the most horrid concept ever. all hail 160 bit addresses.
We can agree to disagree. Owen
On 10/18/10 8:35 AM, Henning Brauer wrote:
* Owen DeLong <owen@delong.com> [2010-10-18 17:27]:
Have you done IPv6? I have... It's not even difficult(), let alone really().Really().Difficult().
maybe not from a users standpoint (that comes later when it misbehaves again). from an implementors (I have written a lot of kernel-side networking code and networking related daemons, including a full-blown bgpd, and that unfortunately included having to deal with v6) viewpoint - IPv6 is a desaster. Why people take up that crap is beyond me, instead of working on a viable alternative that doesn't suck. Which is certainly possible.
Wait, and OpenBSD developer that thinks everyone else's work is crap? Shocking... I encourage you to build and deploy your viable alternative... thanks joel
Owen, He did not display the return values of these functions. I think his IPv6 one returns FALSE; - Jared On Oct 18, 2010, at 11:18 AM, Owen DeLong wrote:
On Oct 18, 2010, at 5:28 AM, Curtis Maurand wrote:
On 10/18/2010 8:16 AM, ML wrote:
And +1 on the "pioneers" comment too.
Paul.
IPv6 Hipsters..Doing it before it was cool.
IPV4 ->easy(); IPV6->really().Really().Difficult();
Have you done IPv6?
I have... It's not even difficult(), let alone really().Really().Difficult().
Owen
On Mon, 18 Oct 2010 08:18:57 -0700 Owen DeLong <owen@delong.com> wrote:
On Oct 18, 2010, at 5:28 AM, Curtis Maurand wrote:
On 10/18/2010 8:16 AM, ML wrote:
And +1 on the "pioneers" comment too.
Paul.
IPv6 Hipsters..Doing it before it was cool.
IPV4 ->easy(); IPV6->really().Really().Difficult();
Have you done IPv6?
I have... It's not even difficult(), let alone really().Really().Difficult().
A lot of things are hard if you've never dealt with anything else. If, OTOH, you'd dealt with IPX or Appletalk before IPv4, then IPv4 was quite hard (why the complexity?! I do know now, but only after having looked into the history of IPv4 - it's a just series of neat hacks!) ... Regards, Mark.
Jeroen Massar <jeroen@unfix.org> writes:
So, if your company is not doing IPv6 yet, you really are really getting late now.
They won't listen. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@guug.de | ------------------- | -------------------------------------------------------------------------
I'll listen, but I need my vendors, carriers, etc. to all get on board first. Jeff On Mon, Oct 18, 2010 at 5:11 PM, Jens Link <lists@quux.de> wrote:
Jeroen Massar <jeroen@unfix.org> writes:
So, if your company is not doing IPv6 yet, you really are really getting late now.
They won't listen.
Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@guug.de | ------------------- | -------------------------------------------------------------------------
-- Jeffrey Lyon, Leadership Team jeffrey.lyon@blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions
Nah... Get IPv6 for your clients today, think about your servers for later... Then you will be able to ask all the right questions and apply the right pressure to your vendors, carriers, etc.... ----- Original Message ----- From: "Jeffrey Lyon" <jeffrey.lyon@blacklotus.net> To: "Jens Link" <lists@quux.de> Cc: nanog@nanog.org Sent: Tuesday, 19 October, 2010 1:15:16 AM Subject: Re: Only 5x IPv4 /8 remaining at IANA I'll listen, but I need my vendors, carriers, etc. to all get on board first. Jeff On Mon, Oct 18, 2010 at 5:11 PM, Jens Link <lists@quux.de> wrote:
Jeroen Massar <jeroen@unfix.org> writes:
So, if your company is not doing IPv6 yet, you really are really getting late now.
They won't listen.
My clients can't use IPv6 when my infrastructure and carriers don't support it. Jeff On Mon, Oct 18, 2010 at 5:52 PM, Franck Martin <franck@genius.com> wrote:
Nah...
Get IPv6 for your clients today, think about your servers for later...
Then you will be able to ask all the right questions and apply the right pressure to your vendors, carriers, etc....
----- Original Message ----- From: "Jeffrey Lyon" <jeffrey.lyon@blacklotus.net> To: "Jens Link" <lists@quux.de> Cc: nanog@nanog.org Sent: Tuesday, 19 October, 2010 1:15:16 AM Subject: Re: Only 5x IPv4 /8 remaining at IANA
I'll listen, but I need my vendors, carriers, etc. to all get on board first.
Jeff
On Mon, Oct 18, 2010 at 5:11 PM, Jens Link <lists@quux.de> wrote:
Jeroen Massar <jeroen@unfix.org> writes:
So, if your company is not doing IPv6 yet, you really are really getting late now.
They won't listen.
-- Jeffrey Lyon, Leadership Team jeffrey.lyon@blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions
On Oct 18, 2010, at 9:39 AM, Jeffrey Lyon wrote:
My clients can't use IPv6 when my infrastructure and carriers don't support it.
Smells like a business opportunity to steal your customers. Thanx! -- TTFN, patrick
On Mon, Oct 18, 2010 at 5:52 PM, Franck Martin <franck@genius.com> wrote:
Nah...
Get IPv6 for your clients today, think about your servers for later...
Then you will be able to ask all the right questions and apply the right pressure to your vendors, carriers, etc....
----- Original Message ----- From: "Jeffrey Lyon" <jeffrey.lyon@blacklotus.net> To: "Jens Link" <lists@quux.de> Cc: nanog@nanog.org Sent: Tuesday, 19 October, 2010 1:15:16 AM Subject: Re: Only 5x IPv4 /8 remaining at IANA
I'll listen, but I need my vendors, carriers, etc. to all get on board first.
Jeff
On Mon, Oct 18, 2010 at 5:11 PM, Jens Link <lists@quux.de> wrote:
Jeroen Massar <jeroen@unfix.org> writes:
So, if your company is not doing IPv6 yet, you really are really getting late now.
They won't listen.
-- Jeffrey Lyon, Leadership Team jeffrey.lyon@blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions
Only if you're prepared for the bloody onslaught of DDoS. Jeff On Mon, Oct 18, 2010 at 6:27 PM, Patrick W. Gilmore <patrick@ianai.net> wrote:
On Oct 18, 2010, at 9:39 AM, Jeffrey Lyon wrote:
My clients can't use IPv6 when my infrastructure and carriers don't support it.
Smells like a business opportunity to steal your customers.
Thanx!
-- TTFN, patrick
On Mon, Oct 18, 2010 at 5:52 PM, Franck Martin <franck@genius.com> wrote:
Nah...
Get IPv6 for your clients today, think about your servers for later...
Then you will be able to ask all the right questions and apply the right pressure to your vendors, carriers, etc....
----- Original Message ----- From: "Jeffrey Lyon" <jeffrey.lyon@blacklotus.net> To: "Jens Link" <lists@quux.de> Cc: nanog@nanog.org Sent: Tuesday, 19 October, 2010 1:15:16 AM Subject: Re: Only 5x IPv4 /8 remaining at IANA
I'll listen, but I need my vendors, carriers, etc. to all get on board first.
Jeff
On Mon, Oct 18, 2010 at 5:11 PM, Jens Link <lists@quux.de> wrote:
Jeroen Massar <jeroen@unfix.org> writes:
So, if your company is not doing IPv6 yet, you really are really getting late now.
They won't listen.
-- Jeffrey Lyon, Leadership Team jeffrey.lyon@blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions
-- Jeffrey Lyon, Leadership Team jeffrey.lyon@blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions
How do you want to do that without IPv6 connectivity? :-) -Jonas Am Montag, den 18.10.2010, 18:42 +0430 schrieb Jeffrey Lyon:
Only if you're prepared for the bloody onslaught of DDoS.
Jeff
On Mon, Oct 18, 2010 at 6:27 PM, Patrick W. Gilmore <patrick@ianai.net> wrote:
On Oct 18, 2010, at 9:39 AM, Jeffrey Lyon wrote:
My clients can't use IPv6 when my infrastructure and carriers don't support it.
Smells like a business opportunity to steal your customers.
Thanx!
-- TTFN, patrick
On Mon, Oct 18, 2010 at 5:52 PM, Franck Martin <franck@genius.com> wrote:
Nah...
Get IPv6 for your clients today, think about your servers for later...
Then you will be able to ask all the right questions and apply the right pressure to your vendors, carriers, etc....
----- Original Message ----- From: "Jeffrey Lyon" <jeffrey.lyon@blacklotus.net> To: "Jens Link" <lists@quux.de> Cc: nanog@nanog.org Sent: Tuesday, 19 October, 2010 1:15:16 AM Subject: Re: Only 5x IPv4 /8 remaining at IANA
I'll listen, but I need my vendors, carriers, etc. to all get on board first.
Jeff
On Mon, Oct 18, 2010 at 5:11 PM, Jens Link <lists@quux.de> wrote:
Jeroen Massar <jeroen@unfix.org> writes:
So, if your company is not doing IPv6 yet, you really are really getting late now.
They won't listen.
-- Jeffrey Lyon, Leadership Team jeffrey.lyon@blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions
Tunnels! OECD and many others recommends to do tunnels if your upstream is "uncooperative" They work well... This is why I say, get your clients first, think servers later... ----- Original Message ----- From: "Jonas Frey (Probe Networks)" <jf@probe-networks.de> To: "Jeffrey Lyon" <jeffrey.lyon@blacklotus.net> Cc: "NANOG list" <nanog@nanog.org> Sent: Tuesday, 19 October, 2010 5:03:06 AM Subject: Re: Only 5x IPv4 /8 remaining at IANA How do you want to do that without IPv6 connectivity? :-) -Jonas
Servers work just fine over tunnels if necessary too. Get your public-facing content and services on IPv6 as fast as possible. Make IPv6 available to your customers as quickly as possible too. Finally, your internal IT resources (other than your support department(s)) can probably wait a little while. Owen On Oct 18, 2010, at 1:41 PM, Franck Martin wrote:
Tunnels!
OECD and many others recommends to do tunnels if your upstream is "uncooperative"
They work well...
This is why I say, get your clients first, think servers later...
----- Original Message ----- From: "Jonas Frey (Probe Networks)" <jf@probe-networks.de> To: "Jeffrey Lyon" <jeffrey.lyon@blacklotus.net> Cc: "NANOG list" <nanog@nanog.org> Sent: Tuesday, 19 October, 2010 5:03:06 AM Subject: Re: Only 5x IPv4 /8 remaining at IANA
How do you want to do that without IPv6 connectivity? :-)
-Jonas
No, no.... Putting your servers on IPv6 is a major task. Load balancers, proprietary code, log analysis, database records... all that needs to be reviewed to see if it is compatible with IPv6 (and a few equipments need recent upgrades if even they can do IPv6 today). Putting your client machines (ie internal network) to IPv6 is relatively easy. Enable IPv6 on the border router, you don't need failover (can built it later) as anyhow the clients will failover to IPv4 if IPv6 fails... So as failover is not needed you can have a separate simple IPv6 network infrastructure on top of your IPv4 Infrastructure. So my advocacy, is get your client (I'm not talking about customers here, but client as client/server) machines on IPv6, get your engineers, support staff,.. to be familiar with IPv6, then all together you can better understand how to migrate your servers infrastructure to IPv6 (and your customers to IPv6 if you are an ISP). If you do that, you will see migration to IPv6 is made much easier, and much faster. ----- Original Message ----- From: "Owen DeLong" <owen@delong.com> To: "Franck Martin" <franck@genius.com> Cc: "Jonas Frey (Probe Networks)" <jf@probe-networks.de>, "Jeffrey Lyon" <jeffrey.lyon@blacklotus.net>, "NANOG list" <nanog@nanog.org> Sent: Tuesday, 19 October, 2010 8:55:56 PM Subject: Re: Only 5x IPv4 /8 remaining at IANA Servers work just fine over tunnels if necessary too. Get your public-facing content and services on IPv6 as fast as possible. Make IPv6 available to your customers as quickly as possible too. Finally, your internal IT resources (other than your support department(s)) can probably wait a little while. Owen On Oct 18, 2010, at 1:41 PM, Franck Martin wrote:
On Oct 19, 2010, at 11:30 AM, Franck Martin wrote:
No, no....
Putting your servers on IPv6 is a major task. Load balancers, proprietary code, log analysis, database records... all that needs to be reviewed to see if it is compatible with IPv6 (and a few equipments need recent upgrades if even they can do IPv6 today).
No, it really isn't so bad in most cases. Yes, if you're using load balancers, you need IPv6 capable LB. That's about 90% of the LB market now. Log analysis, yeah, you're going to need to update your parsers, OR, configure your LB to do 6->4 translation. (Of course you lose something in the translation in that case). Yes, you _MAY_ need to update database records, but, most servers don't actually.
Putting your client machines (ie internal network) to IPv6 is relatively easy. Enable IPv6 on the border router, you don't need failover (can built it later) as anyhow the clients will failover to IPv4 if IPv6 fails... So as failover is not needed you can have a separate simple IPv6 network infrastructure on top of your IPv4 Infrastructure.
Depends on your environment, actually. Most IT environments it turns out to be a pretty major challenge, if, for no other reason than the fact that most Firewall/IDS/IPS vendors are terribly lagging in their IPv6 products.
So my advocacy, is get your client (I'm not talking about customers here, but client as client/server) machines on IPv6, get your engineers, support staff,.. to be familiar with IPv6, then all together you can better understand how to migrate your servers infrastructure to IPv6 (and your customers to IPv6 if you are an ISP).
We can agree to disagree. I have found that it is far more important (and generally easier) to get your servers on to IPv6 so that when the first IPv6-only eyeballs start to emerge (approximately June, 2011, btw), you're able to serve those customers without having to limit them to LSN/CGN/NAT64/etc. access to your services.
If you do that, you will see migration to IPv6 is made much easier, and much faster.
Hasn't been my experience doing a number of IPv6 migrations. Owen
----- Original Message ----- From: "Owen DeLong" <owen@delong.com> To: "Franck Martin" <franck@genius.com> Cc: "Jonas Frey (Probe Networks)" <jf@probe-networks.de>, "Jeffrey Lyon" <jeffrey.lyon@blacklotus.net>, "NANOG list" <nanog@nanog.org> Sent: Tuesday, 19 October, 2010 8:55:56 PM Subject: Re: Only 5x IPv4 /8 remaining at IANA
Servers work just fine over tunnels if necessary too.
Get your public-facing content and services on IPv6 as fast as possible. Make IPv6 available to your customers as quickly as possible too.
Finally, your internal IT resources (other than your support department(s)) can probably wait a little while.
Owen
On Oct 18, 2010, at 1:41 PM, Franck Martin wrote:
If you run Cisco ACE load balancers and start with your web server farm I can assure you that you will be stuck because ACE loaad balancers do not support v6 and don't plan to until mid next year and not without a new card/cost. If you run ACE in non routed mode then you a doubly stuck because you can't even by bypass the loadbalancer to reach one of your webservers since the ACE doesn't pass v6 traffic! So I agree, don't start there instead get the corporate LAN, learn from it then move onto your production facing networks. Also get white listed for Google NS so you can see more user traffic. Zaid On 10/19/10 11:30 AM, "Franck Martin" <franck@genius.com> wrote:
No, no....
Putting your servers on IPv6 is a major task. Load balancers, proprietary code, log analysis, database records... all that needs to be reviewed to see if it is compatible with IPv6 (and a few equipments need recent upgrades if even they can do IPv6 today).
Putting your client machines (ie internal network) to IPv6 is relatively easy. Enable IPv6 on the border router, you don't need failover (can built it later) as anyhow the clients will failover to IPv4 if IPv6 fails... So as failover is not needed you can have a separate simple IPv6 network infrastructure on top of your IPv4 Infrastructure.
So my advocacy, is get your client (I'm not talking about customers here, but client as client/server) machines on IPv6, get your engineers, support staff,.. to be familiar with IPv6, then all together you can better understand how to migrate your servers infrastructure to IPv6 (and your customers to IPv6 if you are an ISP).
If you do that, you will see migration to IPv6 is made much easier, and much faster.
----- Original Message ----- From: "Owen DeLong" <owen@delong.com> To: "Franck Martin" <franck@genius.com> Cc: "Jonas Frey (Probe Networks)" <jf@probe-networks.de>, "Jeffrey Lyon" <jeffrey.lyon@blacklotus.net>, "NANOG list" <nanog@nanog.org> Sent: Tuesday, 19 October, 2010 8:55:56 PM Subject: Re: Only 5x IPv4 /8 remaining at IANA
Servers work just fine over tunnels if necessary too.
Get your public-facing content and services on IPv6 as fast as possible. Make IPv6 available to your customers as quickly as possible too.
Finally, your internal IT resources (other than your support department(s)) can probably wait a little while.
Owen
On Oct 18, 2010, at 1:41 PM, Franck Martin wrote:
On 10/19/2010 2:27 PM, Zaid Ali wrote:
If you run Cisco ACE load balancers and start with your web server farm I can assure you that you will be stuck because ACE loaad balancers do not
That's not the only product with issues. As previously discussed on list, there's also issues with DR support for v6 in a variety of v6 ready load balancers. Shifting from DR to NAT is an undertaking and often not desired. We have a long ways to go. Jack
In message <C8E33F22.6369D%zaid@zaidali.com>, Zaid Ali writes:
If you run Cisco ACE load balancers and start with your web server farm I can assure you that you will be stuck because ACE loaad balancers do not support v6 and don't plan to until mid next year and not without a new card/cost.
So stick a router in parallel and just route IPv6 over it. So stick in a IPv6->IPv4 proxy and send that traffic through the load balancer.
If you run ACE in non routed mode then you a doubly stuck because you can't even by bypass the loadbalancer to reach one of your webservers since the ACE doesn't pass v6 traffic! So I agree, don't start there instead get the corporate LAN, learn from it then move onto your production facing networks. Also get white listed for Google NS so you can see more user traffic.
Zaid
On 10/19/10 11:30 AM, "Franck Martin" <franck@genius.com> wrote:
No, no....
Putting your servers on IPv6 is a major task. Load balancers, proprietary code, log analysis, database records... all that needs to be reviewed to se e if it is compatible with IPv6 (and a few equipments need recent upgrades if even they can do IPv6 today).
Putting your client machines (ie internal network) to IPv6 is relatively ea sy. Enable IPv6 on the border router, you don't need failover (can built it lat er) as anyhow the clients will failover to IPv4 if IPv6 fails... So as failover is not needed you can have a separate simple IPv6 network infrastructure on to p of your IPv4 Infrastructure.
So my advocacy, is get your client (I'm not talking about customers here, b ut client as client/server) machines on IPv6, get your engineers, support staff,.. to be familiar with IPv6, then all together you can better underst and how to migrate your servers infrastructure to IPv6 (and your customers to I Pv6 if you are an ISP).
If you do that, you will see migration to IPv6 is made much easier, and muc h faster.
----- Original Message ----- From: "Owen DeLong" <owen@delong.com> To: "Franck Martin" <franck@genius.com> Cc: "Jonas Frey (Probe Networks)" <jf@probe-networks.de>, "Jeffrey Lyon" <jeffrey.lyon@blacklotus.net>, "NANOG list" <nanog@nanog.org> Sent: Tuesday, 19 October, 2010 8:55:56 PM Subject: Re: Only 5x IPv4 /8 remaining at IANA
Servers work just fine over tunnels if necessary too.
Get your public-facing content and services on IPv6 as fast as possible. Make IPv6 available to your customers as quickly as possible too.
Finally, your internal IT resources (other than your support department(s)) can probably wait a little while.
Owen
On Oct 18, 2010, at 1:41 PM, Franck Martin wrote:
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 10/19/10 2:37 PM, "Mark Andrews" <marka@isc.org> wrote:
So stick a router in parallel and just route IPv6 over it. So stick in a IPv6->IPv4 proxy and send that traffic through the load balancer.
Nah considering v6 traffic is small I have a simpler solution, I prefer to set up a temporary web service running v6 native outside LB's and offer experimental service, that way I can keep yelling at Vendors to get their act together because if they don't hear user requests then v6 will not be a priority for them. The last thing you want to go is build a kluge and stay silent. Zaid
In message <C8E36161.636F0%zaid@zaidali.com>, Zaid Ali writes:
On 10/19/10 2:37 PM, "Mark Andrews" <marka@isc.org> wrote:
So stick a router in parallel and just route IPv6 over it. So stick in a IPv6->IPv4 proxy and send that traffic through the load balancer.
Nah considering v6 traffic is small I have a simpler solution, I prefer to set up a temporary web service running v6 native outside LB's and offer experimental service, that way I can keep yelling at Vendors to get their act together because if they don't hear user requests then v6 will not be a priority for them. The last thing you want to go is build a kluge and stay silent.
Zaid
I wasn't saying don't complain. Adding is seperate IPv6 server is a work around and runs the risk of being overloaded. A proxy should be able to handle a much bigger load as it is just shuffling bits. You should be able to just turn on the IPv6 interfaces on your existing web servers and have them service request over IPv4 and IPv6. That way it doesn't matter about which transport the client picked, they get the same level of service. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 10/19/10 3:58 PM, "Mark Andrews" <marka@isc.org> wrote:
Adding is seperate IPv6 server is a work around and runs the risk of being overloaded.
And what a wonderful problem to have! You can show a CFO a nice cacti graph of IPv6 growth so you can justify him/her to sign off on IPv6 expenses. A CFO will never act unless there is a real business problem. There are some of us here who have management with clue but there are many that don't, sadly this is the majority and a large contributor to the slow adoption of IPv6. Zaid
On Tue, Oct 19, 2010 at 4:25 PM, Zaid Ali <zaid@zaidali.com> wrote:
On 10/19/10 3:58 PM, "Mark Andrews" <marka@isc.org> wrote:
Adding is seperate IPv6 server is a work around and runs the risk of being overloaded.
And what a wonderful problem to have! You can show a CFO a nice cacti graph of IPv6 growth so you can justify him/her to sign off on IPv6 expenses. A CFO will never act unless there is a real business problem. There are some of us here who have management with clue but there are many that don't, sadly this is the majority and a large contributor to the slow adoption of IPv6.
Zaid
I fully expect to see information about IPv6 readiness start becoming a required item on quarterly SEC filings for publicly owned companies that depend on additional IP space being available in order to grow their business. In light of the recent financial meltdowns, and post-Enron SOx compliance requirements, no public company is going to want to face charges that they knowingly mislead their shareholders about the future viability of their company, and of their stock, if they based their business growth around the availability of IPv4 addresses, knowing that supply was on the verge of running out. I'll wager that within 18 months, if you're at a publicly traded company, your CFO will be coming to *you* (or your IP administrator) on a quarterly basis to validate the viability of your IP address plan before signing off on the SEC filings and annual audits of the company, to make sure they're not the ones holding the bag in case the company suddenly can't sign on any new customers. Matt
On Tue, 19 Oct 2010 16:25:12 -0700 Zaid Ali <zaid@zaidali.com> wrote:
On 10/19/10 3:58 PM, "Mark Andrews" <marka@isc.org> wrote:
Adding is seperate IPv6 server is a work around and runs the risk of being overloaded.
And what a wonderful problem to have! You can show a CFO a nice cacti graph of IPv6 growth so you can justify him/her to sign off on IPv6 expenses. A CFO will never act unless there is a real business problem.
When did CFOs run the company? If you're taking this decision to C level management, the CIO, CTO or the CEO should be the ones making the decision. They direct where money goes, not the CFO. The easy business case for IPv6 is insurance. At some point in the relatively near future there may be content or services that are only available over IPv6. Investing in IPv6 deployment now is insurance against not being able to access that content when you may need to in the future. Do your management want to miss out on being able to access the next IPv6-only Google, Salesforce.com, etc., when it is critical to the business? Somebody in the organisation will have responsibility for ensuring continued and reliable access to services the company needs, and if that includes Internet access, then IPv6 is going to become an essential part of that continued and reliable Internet access.
There are some of us here who have management with clue but there are many that don't, sadly this is the majority and a large contributor to the slow adoption of IPv6.
Zaid
On Tue, Oct 19, 2010 at 5:05 PM, Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
On Tue, 19 Oct 2010 16:25:12 -0700 Zaid Ali <zaid@zaidali.com> wrote:
On 10/19/10 3:58 PM, "Mark Andrews" <marka@isc.org> wrote:
Adding is seperate IPv6 server is a work around and runs the risk of being overloaded.
And what a wonderful problem to have! You can show a CFO a nice cacti graph of IPv6 growth so you can justify him/her to sign off on IPv6 expenses. A CFO will never act unless there is a real business problem.
When did CFOs run the company? If you're taking this decision to C level management, the CIO, CTO or the CEO should be the ones making the decision. They direct where money goes, not the CFO.
True. But, i will say, at my employer, the CFO does control the corporate risk management group that oversees the business continuity strategy. Without IP addresses, we can't grow the business, and that's a problem. So, the CFO is a stake holder where i work. Along the lines of IPv6 for business continuity, i usually point people to this ARIN link which is very official and makes it clear the IPv4 addresses are running out, there is a risk to manage. The CFO tries to make sure the money we spend is spent wisely, IPv6 does not directly drive new revenues, but it does diffuse the IP exhaust crisis. It's simply about business continuity. That is something all the CxOs can understand clearly. https://www.arin.net/knowledge/about_resources/ceo_letter.pdf
The easy business case for IPv6 is insurance. At some point in the relatively near future there may be content or services that are only available over IPv6. Investing in IPv6 deployment now is insurance against not being able to access that content when you may need to in the future. Do your management want to miss out on being able to access the next IPv6-only Google, Salesforce.com, etc., when it is critical to the business? Somebody in the organisation will have responsibility for ensuring continued and reliable access to services the company needs, and if that includes Internet access, then IPv6 is going to become an essential part of that continued and reliable Internet access.
Agreed. But, I'll flip it around on you. Same idea, but many mobile eyeballs are going IPv6-only. If you are a content provider and you want to make sure people can see your website, then you will want to be on IPv6.
There are some of us here who have management with clue but there are many that don't, sadly this is the majority and a large contributor to the slow adoption of IPv6.
It's the old story, pay a little now to have an IPv6 plan and get the wheels moving. Or, be caught flat footed, and pay a lot later in forklift upgrades and lost customers. Cameron ====== http://groups.google.com/group/tmoipv6beta ======
If you aren't telling your existing vendors that you need IPv6 now, you need to be. If your vendors aren't getting the message, it's well past time to take action and start looking for other vendors. Owen On Oct 18, 2010, at 6:15 AM, Jeffrey Lyon wrote:
I'll listen, but I need my vendors, carriers, etc. to all get on board first.
Jeff
On Mon, Oct 18, 2010 at 5:11 PM, Jens Link <lists@quux.de> wrote:
Jeroen Massar <jeroen@unfix.org> writes:
So, if your company is not doing IPv6 yet, you really are really getting late now.
They won't listen.
Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@guug.de | ------------------- | -------------------------------------------------------------------------
-- Jeffrey Lyon, Leadership Team jeffrey.lyon@blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions
Uh.... that would be 12 left -- 7 general distribution and 5 reserved for the global end allocation policy. That's 5%, not 5 /8s. Owen On Oct 18, 2010, at 4:44 AM, Jeroen Massar wrote:
APNIC just got another IPv4 /8 thus only 5 left:
http://www.nro.net/media/remaining-ipv4-address-below-5.html (And the spammers will take the rest...)
So, if your company is not doing IPv6 yet, you really are really getting late now.
Greets, Jeroen
(PS: There seems to be a trend for people calling themselves"IPv6 Pioneers" as they recently did something with IPv6, if you didn't play in the 6bone/early-RIR allocs you are not a pioneer as you are 10 years late)
I'm wondering how long it'll be until HE starts spamming their IPv6 service... Tim Burke (815) 556-2000 Sent from my iPhone On Oct 18, 2010, at 6:44, Jeroen Massar <jeroen@unfix.org> wrote:
APNIC just got another IPv4 /8 thus only 5 left:
http://www.nro.net/media/remaining-ipv4-address-below-5.html (And the spammers will take the rest...)
So, if your company is not doing IPv6 yet, you really are really getting late now.
Greets, Jeroen
(PS: There seems to be a trend for people calling themselves"IPv6 Pioneers" as they recently did something with IPv6, if you didn't play in the 6bone/early-RIR allocs you are not a pioneer as you are 10 years late)
Jeroen Massar wrote:
(And the spammers will take the rest...)
I am afraid so too.
(PS: There seems to be a trend for people calling themselves"IPv6 Pioneers" as they recently did something with IPv6, if you didn't play in the 6bone/early-RIR allocs you are not a pioneer as you are 10 years late)
Who died and made you boss of "Pioneer Naming Authority"? Greetings, Jeroen (IPv6 Pioneer, Network Engineer, Software Engineer, Linux Guru, Steve Jobs fanboy (ok, that was a lie ;-)) -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
On 10/20/10 12:51 PM, Jeroen van Aart wrote:
Jeroen Massar wrote:
(And the spammers will take the rest...)
I am afraid so too.
(PS: There seems to be a trend for people calling themselves"IPv6 Pioneers" as they recently did something with IPv6, if you didn't play in the 6bone/early-RIR allocs you are not a pioneer as you are 10 years late)
Oddly the nameserver in my closet seems to still have /var/named/reverse/3.1.8.e.f.f.3.ip6.arpa in it's collection of zones.
Who died and made you boss of "Pioneer Naming Authority"?
If you remember it, you weren't there.
Greetings, Jeroen (IPv6 Pioneer, Network Engineer, Software Engineer, Linux Guru, Steve Jobs fanboy (ok, that was a lie ;-))
On Wed, Oct 20, 2010 at 01:19:43PM -0700, Joel Jaeggli wrote:
On 10/20/10 12:51 PM, Jeroen van Aart wrote:
Jeroen Massar wrote:
(And the spammers will take the rest...)
I am afraid so too.
(PS: There seems to be a trend for people calling themselves"IPv6 Pioneers" as they recently did something with IPv6, if you didn't play in the 6bone/early-RIR allocs you are not a pioneer as you are 10 years late)
Oddly the nameserver in my closet seems to still have /var/named/reverse/3.1.8.e.f.f.3.ip6.arpa in it's collection of zones.
uncoving old battle scars... f.5.ip6.int. is still hanging around..
Who died and made you boss of "Pioneer Naming Authority"?
If you remember it, you weren't there.
i may not remember, but the zone files are still here. --bill
On 2010-10-20 22:19, Joel Jaeggli wrote:
On 10/20/10 12:51 PM, Jeroen van Aart wrote:
Jeroen Massar wrote:
(And the spammers will take the rest...)
I am afraid so too.
(PS: There seems to be a trend for people calling themselves"IPv6 Pioneers" as they recently did something with IPv6, if you didn't play in the 6bone/early-RIR allocs you are not a pioneer as you are 10 years late)
Oddly the nameserver in my closet seems to still have /var/named/reverse/3.1.8.e.f.f.3.ip6.arpa in it's collection of zones.
That must be a pretty new nameserver then you have there, seeing that first of all it all started out with ip6.int and 3ffe::/16 was the second interration of the 6bone, before that we actually used 5f00::/8 with, if I recall correctly, the 16 bit ASN going after the first 8 bits and then some reserved bits and the IPv4 /24 where the host was, some bits for the subnet and then finally 48bits for the MAC (not EUI-64) address. Thanks for Surfnet.nl for giving me a chunk out of that and hooking me up to the rest of the 6bone ;) And the e.f.f.3.ip6.arpa took a long time to materialize actually, thus it is a miracle that you have a zone file for that as it was only used for only a year or so.
Who died and made you boss of "Pioneer Naming Authority"?
If you remember it, you weren't there.
(I don't see how one can forget a death when you are present at the location) Nevertheless, the internet is a global thing, thus 'there' is what we call Earth. The answer is much simpler, there is no boss, just a lot of people who are doing a lot of things for a long time already. But as you wonder who died in the process of IPv6 getting here while doing major contributions: Jun-ichiro "itojun" Itoh Hagino - the IPv6 Samurai Jim Bound - who did an amazing amount of work for IPv6 RIP guys... Greets, Jeroen
On 10/18/2010 7:44 AM, Jeroen Massar wrote:
APNIC just got another IPv4 /8 thus only 5 left:
http://www.nro.net/media/remaining-ipv4-address-below-5.html (And the spammers will take the rest...)
So, if your company is not doing IPv6 yet, you really are really getting late now.
Actually for those of my clients in one location, it served as an impetus to extend a contract with Level3 for another 3 years - with their existing allocation of a /24 of IPv4 addresses included. IPv6 is for those who are "late" in getting IPv4 space! ( grinning, ducking, and running )... --Patrick
On Oct 20, 2010, at 8:36 PM, Patrick Giagnocavo wrote:
On 10/18/2010 7:44 AM, Jeroen Massar wrote:
APNIC just got another IPv4 /8 thus only 5 left:
http://www.nro.net/media/remaining-ipv4-address-below-5.html (And the spammers will take the rest...)
So, if your company is not doing IPv6 yet, you really are really getting late now.
Actually for those of my clients in one location, it served as an impetus to extend a contract with Level3 for another 3 years - with their existing allocation of a /24 of IPv4 addresses included.
All well and good until some of their customers are on IPv6... Then what? Owen
Owen DeLong <owen@delong.com> writes:
All well and good until some of their customers are on IPv6... Then what?
Someone will build an appliance to deal with this problem. ;-) Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@guug.de | ------------------- | -------------------------------------------------------------------------
On Oct 21, 2010, at 4:59 AM, Jens Link wrote:
Owen DeLong <owen@delong.com> writes:
All well and good until some of their customers are on IPv6... Then what?
Someone will build an appliance to deal with this problem. ;-)
And I estimate that the user experience through such appliances will be poor or worse, driving their former customers to their competitors that implemented native IPv6. Owen
-----Original Message----- From: Owen DeLong Sent: Thursday, October 21, 2010 5:12 AM To: Jens Link Cc: NANOG Subject: Re: Only 5x IPv4 /8 remaining at IANA
On Oct 21, 2010, at 4:59 AM, Jens Link wrote:
Owen DeLong writes:
All well and good until some of their customers are on IPv6... Then what?
Someone will build an appliance to deal with this problem. ;-)
And I estimate that the user experience through such appliances will be poor or worse, driving their former customers to their competitors that implemented native IPv6.
Owen
And it will be an expensive operation when someone is pushing multiple gigabits or tens of gigabits of traffic. NAT is probably one of the more expensive operations in a large network facing the Internet that handles a lot of traffic.
On 10/21/2010 4:28 AM, Owen DeLong wrote:
Actually for those of my clients in one location, it served as an impetus to extend a contract with Level3 for another 3 years - with their existing allocation of a /24 of IPv4 addresses included.
All well and good until some of their customers are on IPv6... Then what?
I'm sorry, can you expand on exactly what you mean by this? Are IPv6 connected machines unable to access IPv4 addresses? Or is this more IPV6 fanboi-ism? --Patrick
Hi, Showing my ignorance here, but this is one of the things I have wondered, given that we run both v4 and v6 for a period of time on the Internet, presumably at one time or another a particular resource may only be able in v4 land, then v4 and v6, then finally v6 only. I have never been particularly clear how an end network that exists only in v4 or v6 address space is able to access a resource that only exists in the other. Is can sort of see some freaking huge NAT box type thing that summarizes v6 in a v4 address scope or contains the v4 address range at some point inside the v6 address space - but how can a v4 host get to a hot in v6 world that sits outside this without going through some form of proxy / nat gateway between the two. Or are the two simply not inter-communicable? Ben -----Original Message----- From: Patrick Giagnocavo [mailto:patrick@zill.net] Sent: 21 October 2010 15:59 To: Owen DeLong; NANOG Subject: Re: Only 5x IPv4 /8 remaining at IANA On 10/21/2010 4:28 AM, Owen DeLong wrote:
Actually for those of my clients in one location, it served as an impetus to extend a contract with Level3 for another 3 years - with their existing allocation of a /24 of IPv4 addresses included.
All well and good until some of their customers are on IPv6... Then what?
I'm sorry, can you expand on exactly what you mean by this? Are IPv6 connected machines unable to access IPv4 addresses? Or is this more IPV6 fanboi-ism? --Patrick -------------------------------------------------------------------------- BODY { MARGIN: 0px}.footerdark { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #001a35; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.blackcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.bluecopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #29aae2; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.address { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; TEXT-DECORATION: none}.footerlight { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #667891; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.pinkcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #ed174d; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none} Ben Butler Director Tel: 0333 666 3332 Fax: 0333 666 3331 C2 Business Networking Ltd The Paddock, London Road, Nantwich, Cheshire, CW5 7JL http://www.c2internet.net/ Part of the Atlas Business Group of Companies plc Registered in England: 07102986 Registered Address: Datum House, Electra Way, Crewe CW1 6ZF Vat Registration No: 712 9503 48 This message is confidential and intended for the use only of the person to whom it is addressed. If you are not the intended recipient you are strictly prohibited from reading, disseminating, copying, printing, re-transmitting or using this message or its contents in any way. Opinions, conclusions and other information expressed in this message are not given or authorised by the Company unless otherwise indicated by an authorised representative independent of this message. The Company does not accept liability for any data corruption, interception or amendment to any e-mail or the consequences thereof.Emails addressed to individuals may not necessarily be read by that person unless they are in the office.Calls to and from any of the Atlas Business Group of Companies may be recorded for the purposes of training, monitoring of quality and customer services.
On 21/10/10 16:07 +0100, Ben Butler wrote:
Hi,
Showing my ignorance here, but this is one of the things I have wondered, given that we run both v4 and v6 for a period of time on the Internet, presumably at one time or another a particular resource may only be able in v4 land, then v4 and v6, then finally v6 only.
I have never been particularly clear how an end network that exists only in v4 or v6 address space is able to access a resource that only exists in the other. Is can sort of see some freaking huge NAT box type thing that summarizes v6 in a v4 address scope or contains the v4 address range at some point inside the v6 address space - but how can a v4 host get to a hot in v6 world that sits outside this without going through some form of proxy / nat gateway between the two.
Or are the two simply not inter-communicable?
I think that's the $64K question. Do you wait to roll out v6 until you start seeing v6-only hosts start popping up? From an accounting and cost recovery stand point, that probably makes sense in some environments. However, consider the fact that there will be v6 only hosts popping up after IANA/RIR/ISP exhaustion. There will be new entrants in the public internet space that cannot obtain v4 addresses and will be reachable via v6 only. That date is starting to become a bit more predictable too. Those v6 only sites won't be Google or Yahoo, but they will be entrepreneurs with good ideas and new services that your customers will be asking to get access to. We're pursuing a dual stacking model today because we anticipate that the dual-stacking process itself will take a while to deploy, and we want to anticipate customer demand for access to v6 only sites. We could hold off on that deployment, and then spend money on work at the moment of truth, but that approach is not very appealing to us. -- Dan White
Hi, I can live with running dual stack for a number of years as long as IPv4 has a turn off date, much like analogue TV services, thus putting onus of responsibility onto the customer to also have a vested interest in migrating from v4 to v6. If there is no end data - then all the service providers are going to get stuck running dual stack and providing 4to6 and 6to4 gateways to bridge traffic to the pool of established v4 only customers. Presumably the evil that is NAT will have to be run on these gateways meaning we have to endure yet more decades of many applications being undeployable for practical purposes as stun cant fix everything in the mish mash of different NAT implementations. The problem is there is no commercial incentive for the v4 customer to want to move to v6 and there is no way for the ISP to force them to without loosing the customer. However, if the RIRs or IANA turned around and said as of xxxx date we are revoking all ipv4 allocations. Then we might be able to transition to a v6 only network in some decent timeframe without ending up going down the road of a broken dual level 4/6 half way in between broken internet for the next 25 years. You either cross the bridge and get to the other side, or you tell all the people waiting to cross they are too late and tough luck but we have run out and you cant join the party, but the last thing we want to do is get half way across the bridge and need to straddle both sides of the river. My 2c. Ben -----Original Message----- From: Dan White [mailto:dwhite@olp.net] Sent: 21 October 2010 16:30 To: Ben Butler Cc: 'Patrick Giagnocavo'; Owen DeLong; NANOG Subject: Re: Only 5x IPv4 /8 remaining at IANA On 21/10/10 16:07 +0100, Ben Butler wrote:
Hi,
Showing my ignorance here, but this is one of the things I have wondered, given that we run both v4 and v6 for a period of time on the Internet, presumably at one time or another a particular resource may only be able in v4 land, then v4 and v6, then finally v6 only.
I have never been particularly clear how an end network that exists only in v4 or v6 address space is able to access a resource that only exists in the other. Is can sort of see some freaking huge NAT box type thing that summarizes v6 in a v4 address scope or contains the v4 address range at some point inside the v6 address space - but how can a v4 host get to a hot in v6 world that sits outside this without going through some form of proxy / nat gateway between the two.
Or are the two simply not inter-communicable?
I think that's the $64K question. Do you wait to roll out v6 until you start seeing v6-only hosts start popping up? From an accounting and cost recovery stand point, that probably makes sense in some environments. However, consider the fact that there will be v6 only hosts popping up after IANA/RIR/ISP exhaustion. There will be new entrants in the public internet space that cannot obtain v4 addresses and will be reachable via v6 only. That date is starting to become a bit more predictable too. Those v6 only sites won't be Google or Yahoo, but they will be entrepreneurs with good ideas and new services that your customers will be asking to get access to. We're pursuing a dual stacking model today because we anticipate that the dual-stacking process itself will take a while to deploy, and we want to anticipate customer demand for access to v6 only sites. We could hold off on that deployment, and then spend money on work at the moment of truth, but that approach is not very appealing to us. -- Dan White -------------------------------------------------------------------------- BODY { MARGIN: 0px}.footerdark { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #001a35; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.blackcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.bluecopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #29aae2; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.address { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; TEXT-DECORATION: none}.footerlight { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #667891; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.pinkcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #ed174d; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none} Ben Butler Director Tel: 0333 666 3332 Fax: 0333 666 3331 C2 Business Networking Ltd The Paddock, London Road, Nantwich, Cheshire, CW5 7JL http://www.c2internet.net/ Part of the Atlas Business Group of Companies plc Registered in England: 07102986 Registered Address: Datum House, Electra Way, Crewe CW1 6ZF Vat Registration No: 712 9503 48 This message is confidential and intended for the use only of the person to whom it is addressed. If you are not the intended recipient you are strictly prohibited from reading, disseminating, copying, printing, re-transmitting or using this message or its contents in any way. Opinions, conclusions and other information expressed in this message are not given or authorised by the Company unless otherwise indicated by an authorised representative independent of this message. The Company does not accept liability for any data corruption, interception or amendment to any e-mail or the consequences thereof.Emails addressed to individuals may not necessarily be read by that person unless they are in the office.Calls to and from any of the Atlas Business Group of Companies may be recorded for the purposes of training, monitoring of quality and customer services.
On Oct 21, 2010, at 12:34 PM, Ben Butler wrote:
Hi,
I can live with running dual stack for a number of years as long as IPv4 has a turn off date, much like analogue TV services, thus putting onus of
And how would you propose to achieve that ? Regards Marshall
responsibility onto the customer to also have a vested interest in migrating from v4 to v6. If there is no end data - then all the service providers are going to get stuck running dual stack and providing 4to6 and 6to4 gateways to bridge traffic to the pool of established v4 only customers. Presumably the evil that is NAT will have to be run on these gateways meaning we have to endure yet more decades of many applications being undeployable for practical purposes as stun cant fix everything in the mish mash of different NAT implementations.
The problem is there is no commercial incentive for the v4 customer to want to move to v6 and there is no way for the ISP to force them to without loosing the customer. However, if the RIRs or IANA turned around and said as of xxxx date we are revoking all ipv4 allocations. Then we might be able to transition to a v6 only network in some decent timeframe without ending up going down the road of a broken dual level 4/6 half way in between broken internet for the next 25 years.
You either cross the bridge and get to the other side, or you tell all the people waiting to cross they are too late and tough luck but we have run out and you cant join the party, but the last thing we want to do is get half way across the bridge and need to straddle both sides of the river.
My 2c.
Ben
-----Original Message----- From: Dan White [mailto:dwhite@olp.net] Sent: 21 October 2010 16:30 To: Ben Butler Cc: 'Patrick Giagnocavo'; Owen DeLong; NANOG Subject: Re: Only 5x IPv4 /8 remaining at IANA
On 21/10/10 16:07 +0100, Ben Butler wrote:
Hi,
Showing my ignorance here, but this is one of the things I have wondered, given that we run both v4 and v6 for a period of time on the Internet, presumably at one time or another a particular resource may only be able in v4 land, then v4 and v6, then finally v6 only.
I have never been particularly clear how an end network that exists only in v4 or v6 address space is able to access a resource that only exists in the other. Is can sort of see some freaking huge NAT box type thing that summarizes v6 in a v4 address scope or contains the v4 address range at some point inside the v6 address space - but how can a v4 host get to a hot in v6 world that sits outside this without going through some form of proxy / nat gateway between the two.
Or are the two simply not inter-communicable?
I think that's the $64K question. Do you wait to roll out v6 until you start seeing v6-only hosts start popping up? From an accounting and cost recovery stand point, that probably makes sense in some environments.
However, consider the fact that there will be v6 only hosts popping up after IANA/RIR/ISP exhaustion. There will be new entrants in the public internet space that cannot obtain v4 addresses and will be reachable via v6 only. That date is starting to become a bit more predictable too. Those v6 only sites won't be Google or Yahoo, but they will be entrepreneurs with good ideas and new services that your customers will be asking to get access to.
We're pursuing a dual stacking model today because we anticipate that the dual-stacking process itself will take a while to deploy, and we want to anticipate customer demand for access to v6 only sites. We could hold off on that deployment, and then spend money on work at the moment of truth, but that approach is not very appealing to us.
-- Dan White
-------------------------------------------------------------------------- BODY { MARGIN: 0px}.footerdark { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #001a35; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.blackcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.bluecopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #29aae2; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.address { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; TEXT-DECORATION: none}.footerlight { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #667891; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.pinkcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #ed174d; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none} Ben Butler Director Tel: 0333 666 3332 Fax: 0333 666 3331 C2 Business Networking Ltd The Paddock, London Road, Nantwich, Cheshire, CW5 7JL http://www.c2internet.net/
Part of the Atlas Business Group of Companies plc Registered in England: 07102986 Registered Address: Datum House, Electra Way, Crewe CW1 6ZF Vat Registration No: 712 9503 48 This message is confidential and intended for the use only of the person to whom it is addressed. If you are not the intended recipient you are strictly prohibited from reading, disseminating, copying, printing, re-transmitting or using this message or its contents in any way. Opinions, conclusions and other information expressed in this message are not given or authorised by the Company unless otherwise indicated by an authorised representative independent of this message. The Company does not accept liability for any data corruption, interception or amendment to any e-mail or the consequences thereof.Emails addressed to individuals may not necessarily be read by that person unless they are in the office.Calls to and from any of the Atlas Business Group of Companies may be recorded for the purposes of training, monitoring of quality and customer services.
Hi, What is the consequence of not managing to transition the v4 network and having to maintain it indefinitely. I think if the cost / limitations that this may place on things is great enough then the "how" will reveal itself with the interested parties. Is there a downside to being stuck with both address spaces rather than just 6, idk, you tell me, but there seems to be from what I can tell. I am not suggesting any form of timeframe in the exact number of years / decades, just that a timeframe should exist where after a certain date - whatever that is - we can say ok, now we are turning off v4. In the absence of any form of timeframe what is the operational benefit of any existing v4 user migrating to v6 if the service provider is going to make magic happen that enables them to talk to v6 only host via some mysterious bridging box. I can see none, which tells me they are not going to bother spending there time and money renumbering and deploying v6 - ever! There needs to be a technical, commercial or operational reason for them to want to go through the change. Ben -----Original Message----- From: Marshall Eubanks [mailto:tme@americafree.tv] Sent: 21 October 2010 18:09 To: Ben Butler Cc: 'Dan White'; NANOG Subject: Re: Only 5x IPv4 /8 remaining at IANA On Oct 21, 2010, at 12:34 PM, Ben Butler wrote:
Hi,
I can live with running dual stack for a number of years as long as IPv4 has a turn off date, much like analogue TV services, thus putting onus of
And how would you propose to achieve that ? Regards Marshall
responsibility onto the customer to also have a vested interest in migrating from v4 to v6. If there is no end data - then all the service providers are going to get stuck running dual stack and providing 4to6 and 6to4 gateways to bridge traffic to the pool of established v4 only customers. Presumably the evil that is NAT will have to be run on these gateways meaning we have to endure yet more decades of many applications being undeployable for practical purposes as stun cant fix everything in the mish mash of different NAT implementations.
The problem is there is no commercial incentive for the v4 customer to want to move to v6 and there is no way for the ISP to force them to without loosing the customer. However, if the RIRs or IANA turned around and said as of xxxx date we are revoking all ipv4 allocations. Then we might be able to transition to a v6 only network in some decent timeframe without ending up going down the road of a broken dual level 4/6 half way in between broken internet for the next 25 years.
You either cross the bridge and get to the other side, or you tell all the people waiting to cross they are too late and tough luck but we have run out and you cant join the party, but the last thing we want to do is get half way across the bridge and need to straddle both sides of the river.
My 2c.
Ben
-----Original Message----- From: Dan White [mailto:dwhite@olp.net] Sent: 21 October 2010 16:30 To: Ben Butler Cc: 'Patrick Giagnocavo'; Owen DeLong; NANOG Subject: Re: Only 5x IPv4 /8 remaining at IANA
On 21/10/10 16:07 +0100, Ben Butler wrote:
Hi,
Showing my ignorance here, but this is one of the things I have wondered, given that we run both v4 and v6 for a period of time on the Internet, presumably at one time or another a particular resource may only be able in v4 land, then v4 and v6, then finally v6 only.
I have never been particularly clear how an end network that exists only in v4 or v6 address space is able to access a resource that only exists in the other. Is can sort of see some freaking huge NAT box type thing that summarizes v6 in a v4 address scope or contains the v4 address range at some point inside the v6 address space - but how can a v4 host get to a hot in v6 world that sits outside this without going through some form of proxy / nat gateway between the two.
Or are the two simply not inter-communicable?
I think that's the $64K question. Do you wait to roll out v6 until you start seeing v6-only hosts start popping up? From an accounting and cost recovery stand point, that probably makes sense in some environments.
However, consider the fact that there will be v6 only hosts popping up after IANA/RIR/ISP exhaustion. There will be new entrants in the public internet space that cannot obtain v4 addresses and will be reachable via v6 only. That date is starting to become a bit more predictable too. Those v6 only sites won't be Google or Yahoo, but they will be entrepreneurs with good ideas and new services that your customers will be asking to get access to.
We're pursuing a dual stacking model today because we anticipate that the dual-stacking process itself will take a while to deploy, and we want to anticipate customer demand for access to v6 only sites. We could hold off on that deployment, and then spend money on work at the moment of truth, but that approach is not very appealing to us.
-- Dan White
-------------------------------------------------------------------------- BODY { MARGIN: 0px}.footerdark { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #001a35; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.blackcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.bluecopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #29aae2; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.address { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; TEXT-DECORATION: none}.footerlight { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #667891; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.pinkcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #ed174d; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none} Ben Butler Director Tel: 0333 666 3332 Fax: 0333 666 3331 C2 Business Networking Ltd The Paddock, London Road, Nantwich, Cheshire, CW5 7JL http://www.c2internet.net/
Part of the Atlas Business Group of Companies plc Registered in England: 07102986 Registered Address: Datum House, Electra Way, Crewe CW1 6ZF Vat Registration No: 712 9503 48 This message is confidential and intended for the use only of the person to whom it is addressed. If you are not the intended recipient you are strictly prohibited from reading, disseminating, copying, printing, re-transmitting or using this message or its contents in any way. Opinions, conclusions and other information expressed in this message are not given or authorised by the Company unless otherwise indicated by an authorised representative independent of this message. The Company does not accept liability for any data corruption, interception or amendment to any e-mail or the consequences thereof.Emails addressed to individuals may not necessarily be read by that person unless they are in the office.Calls to and from any of the Atlas Business Group of Companies may be recorded for the purposes of training, monitoring of quality and customer services.
How would you respond if that were announced? Carriers have been doing technology transitions for years. Cidr to classless. Amps to CDMA or gsm... This is not new. I do agree the incentives and technology don't exist in a desirable environment but the "ip" feature creep we've seen make a solution for everyone difficult without breaking something. If I were king for a day, there are many things along these lines that I would consider. Sent from my iThing On Oct 21, 2010, at 1:17 PM, Ben Butler <ben.butler@c2internet.net> wrote:
Hi,
What is the consequence of not managing to transition the v4 network and having to maintain it indefinitely. I think if the cost / limitations that this may place on things is great enough then the "how" will reveal itself with the interested parties.
Is there a downside to being stuck with both address spaces rather than just 6, idk, you tell me, but there seems to be from what I can tell.
I am not suggesting any form of timeframe in the exact number of years / decades, just that a timeframe should exist where after a certain date - whatever that is - we can say ok, now we are turning off v4.
In the absence of any form of timeframe what is the operational benefit of any existing v4 user migrating to v6 if the service provider is going to make magic happen that enables them to talk to v6 only host via some mysterious bridging box. I can see none, which tells me they are not going to bother spending there time and money renumbering and deploying v6 - ever! There needs to be a technical, commercial or operational reason for them to want to go through the change.
Ben
-----Original Message----- From: Marshall Eubanks [mailto:tme@americafree.tv] Sent: 21 October 2010 18:09 To: Ben Butler Cc: 'Dan White'; NANOG Subject: Re: Only 5x IPv4 /8 remaining at IANA
On Oct 21, 2010, at 12:34 PM, Ben Butler wrote:
Hi,
I can live with running dual stack for a number of years as long as IPv4 has a turn off date, much like analogue TV services, thus putting onus of
And how would you propose to achieve that ?
Regards Marshall
responsibility onto the customer to also have a vested interest in migrating from v4 to v6. If there is no end data - then all the service providers are going to get stuck running dual stack and providing 4to6 and 6to4 gateways to bridge traffic to the pool of established v4 only customers. Presumably the evil that is NAT will have to be run on these gateways meaning we have to endure yet more decades of many applications being undeployable for practical purposes as stun cant fix everything in the mish mash of different NAT implementations.
The problem is there is no commercial incentive for the v4 customer to want to move to v6 and there is no way for the ISP to force them to without loosing the customer. However, if the RIRs or IANA turned around and said as of xxxx date we are revoking all ipv4 allocations. Then we might be able to transition to a v6 only network in some decent timeframe without ending up going down the road of a broken dual level 4/6 half way in between broken internet for the next 25 years.
You either cross the bridge and get to the other side, or you tell all the people waiting to cross they are too late and tough luck but we have run out and you cant join the party, but the last thing we want to do is get half way across the bridge and need to straddle both sides of the river.
My 2c.
Ben
-----Original Message----- From: Dan White [mailto:dwhite@olp.net] Sent: 21 October 2010 16:30 To: Ben Butler Cc: 'Patrick Giagnocavo'; Owen DeLong; NANOG Subject: Re: Only 5x IPv4 /8 remaining at IANA
On 21/10/10 16:07 +0100, Ben Butler wrote:
Hi,
Showing my ignorance here, but this is one of the things I have wondered, given that we run both v4 and v6 for a period of time on the Internet, presumably at one time or another a particular resource may only be able in v4 land, then v4 and v6, then finally v6 only.
I have never been particularly clear how an end network that exists only in v4 or v6 address space is able to access a resource that only exists in the other. Is can sort of see some freaking huge NAT box type thing that summarizes v6 in a v4 address scope or contains the v4 address range at some point inside the v6 address space - but how can a v4 host get to a hot in v6 world that sits outside this without going through some form of proxy / nat gateway between the two.
Or are the two simply not inter-communicable?
I think that's the $64K question. Do you wait to roll out v6 until you start seeing v6-only hosts start popping up? From an accounting and cost recovery stand point, that probably makes sense in some environments.
However, consider the fact that there will be v6 only hosts popping up after IANA/RIR/ISP exhaustion. There will be new entrants in the public internet space that cannot obtain v4 addresses and will be reachable via v6 only. That date is starting to become a bit more predictable too. Those v6 only sites won't be Google or Yahoo, but they will be entrepreneurs with good ideas and new services that your customers will be asking to get access to.
We're pursuing a dual stacking model today because we anticipate that the dual-stacking process itself will take a while to deploy, and we want to anticipate customer demand for access to v6 only sites. We could hold off on that deployment, and then spend money on work at the moment of truth, but that approach is not very appealing to us.
-- Dan White
-------------------------------------------------------------------------- BODY { MARGIN: 0px}.footerdark { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #001a35; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.blackcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.bluecopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #29aae2; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.address { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; TEXT-DECORATION: none}.footerlight { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #667891; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.pinkcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #ed174d; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none} Ben Butler Director Tel: 0333 666 3332 Fax: 0333 666 3331 C2 Business Networking Ltd The Paddock, London Road, Nantwich, Cheshire, CW5 7JL http://www.c2internet.net/
Part of the Atlas Business Group of Companies plc Registered in England: 07102986 Registered Address: Datum House, Electra Way, Crewe CW1 6ZF Vat Registration No: 712 9503 48 This message is confidential and intended for the use only of the person to whom it is addressed. If you are not the intended recipient you are strictly prohibited from reading, disseminating, copying, printing, re-transmitting or using this message or its contents in any way. Opinions, conclusions and other information expressed in this message are not given or authorised by the Company unless otherwise indicated by an authorised representative independent of this message. The Company does not accept liability for any data corruption, interception or amendment to any e-mail or the consequences thereof.Emails addressed to individuals may not necessarily be read by that person unless they are in the office.Calls to and from any of the Atlas Business Group of Companies may be recorded for the purposes of training, monitoring of quality and customer services.
On 10/21/2010 10:42 AM, Jared Mauch wrote:
How would you respond if that were announced? ... If I were king for a day,
But you aren't. No one is. The core requirement for such announcements is that there be a real enforcement arm. The best that can be done with respect to declaring a IPv4 sunset date is localized pockets of such control. One could, of course, imagine a federation of such pockets... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
On Thu, Oct 21, 2010 at 10:52:19AM -0700, Dave CROCKER wrote:
But you aren't. No one is.
The core requirement for such announcements is that there be a real enforcement arm.
If a couple of large carriers set their own flag dates, and turn off v4 at that point, it will be effectively enforced. Plenty of people aren't particularly 'local' pockets of control. You don't need an enforcement arm -- it just needs to stop making economic sense to support two parallel networks. Since it's automatically wasteful, once enough of the traffic is v6, that may come sooner than you realize. Or, just start charging an arm and a leg for v4 transit until people take the hint... --msa
On Thu, Oct 21, 2010 at 10:59:38AM -0700, Majdi S. Abbas wrote:
On Thu, Oct 21, 2010 at 10:52:19AM -0700, Dave CROCKER wrote:
But you aren't. No one is.
The core requirement for such announcements is that there be a real enforcement arm.
If a couple of large carriers set their own flag dates, and turn off v4 at that point, it will be effectively enforced. Plenty of people aren't particularly 'local' pockets of control.
They would be out of business the day they turn IPv4 off. So it will not happen.
You don't need an enforcement arm -- it just needs to stop making economic sense to support two parallel networks. Since it's automatically wasteful, once enough of the traffic is v6, that may come sooner than you realize.
I doubt it.
Or, just start charging an arm and a leg for v4 transit until people take the hint...
and change the ISP. Before you can even start to think about moving away from v4 you need to ensure that everybody is reachable via v6. The problem is that the key organizations try everything to make this not happen. -- :wq Claudio
They would be out of business the day they turn IPv4 off. So it will not happen.
IMO, this will not be a decision made by ICANN or a network provider. This will be made by a platform/OS company. Basically, once IPv6 is presumed ubiquitous (it doesn't have to be actually ubiquitous) -- just if you can't reach something by IPv6 you assume it's the far-side's problem -- IPv4 becomes a relic from a business point-of-view, because anyone who doesn't support it is not presumed to be at fault. Microsoft, Apple, or gee-whiz-new-gadget guy simply has to come out with the next revision of their killer product that has dropped support for it. Many may complain, but with those that have sufficient market power to not see a significant affect (and can justify retasking their internal development resources who no longer have to regression test IPv4 stuff against any perceived customer loss) will do it -- they'll probably call it an upgrade. It's been done before. It'll happen again. This doesn't mean IPv4 will disappear. Just like the 20+ year old machines that are still on the net via IPv4 -> legacy protocol gateways, pockets of IPv4 may exist for decades via similar devices -- but at that point, we just dismiss those guys as crackpots. Anyone have an IPv6 coke machine yet? Deepak
This doesn't mean IPv4 will disappear. Just like the 20+ year old machines that are still on the net via IPv4 -> legacy protocol gateways, pockets of IPv4 may exist for decades via similar devices -- but at that point, we just dismiss those guys as crackpots.
Maybe not quite crackpots, but you are right that a sunset date is really a marketing device, and if done as a manifesto, would gain a lot of publicity. If the manifesto has a clause that allows a signatory to keep running IPv4 for specialist purposes that are not core to the public Internet, then what will happen is that the public will force the sunset to happen. But behind the scenes people will still be using it just as they are still running X.25 networks today, out of the glare of the public eye. For this to work you need a team of sensible people to put some effort into crafting a workable manifesto that network operators would actually be willing to sign. 2019 seems like a date the people could actually commit to, in fact even 2016 may be workable and is perhaps desirable because it will be within the planning horizon of a lot of folks starting next year. --Michael Dillon
On Thu, Oct 21, 2010 at 2:19 PM, Claudio Jeker <cjeker@diehard.n-r-g.com> wrote:
On Thu, Oct 21, 2010 at 10:59:38AM -0700, Majdi S. Abbas wrote:
On Thu, Oct 21, 2010 at 10:52:19AM -0700, Dave CROCKER wrote:
But you aren't. No one is.
The core requirement for such announcements is that there be a real enforcement arm.
<snip>
I doubt it.
Or, just start charging an arm and a leg for v4 transit until people take the hint...
and change the ISP. Before you can even start to think about moving away from v4 you need to ensure that everybody is reachable via v6. The problem is that the key organizations try everything to make this not happen.
;; QUESTION SECTION: ;bbiw.net. IN ANY ;; ANSWER SECTION: bbiw.net. 285 IN A 72.52.113.67 indeed....
Well, if the DNS root servers ceased IPv4 service it'd be pretty much a fait accompli as far as the public internet is concerned. And, of course, the RIRs could just cancel all the IPv4 route announcements, whatever they do if someone doesn't pay or whatever. I'm not sure why any would do that since both versions of the protocol can exist on the same wire. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
* bzs@world.std.com (Barry Shein) [Thu 21 Oct 2010, 22:59 CEST]:
And, of course, the RIRs could just cancel all the IPv4 route announcements, whatever they do if someone doesn't pay or whatever.
I think you're mistaking the default-free zone for Usenet. The DFZ doesn't have 'cmsg cancel' messages. -- Niels. -- "It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account." -- roy edroso, alicublog.blogspot.com
On 10/21/2010 7:53 PM, Niels Bakker wrote:
* bzs@world.std.com (Barry Shein) [Thu 21 Oct 2010, 22:59 CEST]:
And, of course, the RIRs could just cancel all the IPv4 route announcements, whatever they do if someone doesn't pay or whatever.
I think you're mistaking the default-free zone for Usenet. The DFZ doesn't have 'cmsg cancel' messages.
The "whatever they do if someone doesn't pay" is a nightmare. I suspect such a recourse wouldn't work for stopping IPv4. Jack
On October 21, 2010 at 20:13 jbates@brightok.net (Jack Bates) wrote:
On 10/21/2010 7:53 PM, Niels Bakker wrote:
* bzs@world.std.com (Barry Shein) [Thu 21 Oct 2010, 22:59 CEST]:
And, of course, the RIRs could just cancel all the IPv4 route announcements, whatever they do if someone doesn't pay or whatever.
I think you're mistaking the default-free zone for Usenet. The DFZ doesn't have 'cmsg cancel' messages.
The "whatever they do if someone doesn't pay" is a nightmare. I suspect such a recourse wouldn't work for stopping IPv4.
Well, along with no more IPv4 DNS and it'd be pretty effective (I suggested both for a reason.) The idea isn't to make it impossible to run an ipv4 connection, tho at some point it'd have to be encapsulated in IPv6 to get routed across the public infrastructure, the idea is to declare it dead and stop expending (shared) resources on it. I guess I just answered my own question: "Why bother?" So we can stop expending resources on IPv4 like managing address space allocations, route announcements, firefighting, DNS, all the wonky this inside that encapsulation schemes, etc. I'd let folks like the RIRs and DNS root managers speak to how much of a win that would be tho it would affect others, particularly the firefighting part. If IPv4 is maintained forever then one presumes it works reasonably well forever and that's kinda why everyone here is here, no? Anyhow, it might be an interesting topic to discuss in the appropriate venues, IETF, "What is the cost of maintaining IPv4 forever?" but it's getting a little ahead of ourselves in terms of any pressing need. So...it wasn't a dumb question to raise, just perhaps a bit premature. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
On Oct 21, 2010, at 9:51 PM, Barry Shein wrote:
Anyhow, it might be an interesting topic to discuss in the appropriate venues, IETF, "What is the cost of maintaining IPv4 forever?" but it's getting a little ahead of ourselves in terms of any pressing need.
This is an interesting question. In talking to your vendors with your checklist of capabilities a device CAN/SHOULD/MUST have, what if you no longer needed to carry 350k/512k routes of IPv4 and only needed 256k of IPv6 ? Instead of 6pe think of 4pe with ipv6 core. I've been reminding vendors that IPv6 should get new features *first* vs IPv4. The end of IPv4 is near, but that doesn't mean the end of the Internet is here. The next chapter gets a new page turned. Maybe we will determine that IPv6 needs to go the way of IPX/Decnet/AppleTalk and some new system (non-IP even) will take over the world. Either way, it's an interesting time to be an edge operator that worries about CPE stuff. those that think mostly about core this is a big fat *yawn* imho. Expect application developers to face some interesting challenges. me? I'm waiting until I see the "NOW WITH IPv6" sticker on things at the store. - Jared
On 10/21/2010 9:09 PM, Jared Mauch wrote:
Either way, it's an interesting time to be an edge operator that worries about CPE stuff. those that think mostly about core this is a big fat *yawn* imho. Expect application developers to face some interesting challenges. me? I'm waiting until I see the "NOW WITH IPv6" sticker on things at the store.
1. Core routing/BGP check 2. Servers check 3. load balancers? oops, semi-check 4. edge check 5. Telco maintained CPE check (There's a reason we didn't do pppoe), for others, fail 6. Customer provided CPE/routers/etc fail It took off the shelf CPEs some time to get it right at autodetecting and handling the numerous Provider Edge setups. v6 actually adds a whole new arsenal of setups that can exist at the Provider Edge. People are crazy if they think the provider will adjust to a billion different setups. The cheap routers have a long ways to go to support this new variety of setups. I'm personally partial to DHCPv6 TA addressing (SLAAC at provider edge is cool, but there are too many issues with it, especially when trying to track users) with 86400 preferred and 172800 valid and NAK the renewal, combined with DHCPv6-PD with 86400 preferred and 172800 valid and NAK the renewal. This gives a 24 hour prefix rotation for new connections and a 24 hour hold time for old connections. Combined with privacy extensions, it should pollute geo IP databases with horribly wrong information and make it more difficult for certain types of malicious network attacks. :) Jack
On Thu, Oct 21, 2010 at 10:09:39PM -0400, Jared Mauch wrote:
On Oct 21, 2010, at 9:51 PM, Barry Shein wrote:
Anyhow, it might be an interesting topic to discuss in the appropriate venues, IETF, "What is the cost of maintaining IPv4 forever?" but it's getting a little ahead of ourselves in terms of any pressing need.
This is an interesting question.
In talking to your vendors with your checklist of capabilities a device CAN/SHOULD/MUST have, what if you no longer needed to carry 350k/512k routes of IPv4 and only needed 256k of IPv6 ?
Instead of 6pe think of 4pe with ipv6 core.
when did Cisco stop supporting DECNET? Chaosnet? why?
I've been reminding vendors that IPv6 should get new features *first* vs IPv4.
it will, when/if there are things IPv6 can do that IPv4 can't. the problem is, most folks have tied down, castrated and otherwise crippled IPv6 unique capabilities so that it would be "IPv4 with larger addresses".
The end of IPv4 is near, but that doesn't mean the end of the Internet is here. The next chapter gets a new page turned. Maybe we will determine that IPv6 needs to go the way of IPX/Decnet/AppleTalk and some new system (non-IP even) will take over the world.
you predict the end of IPv4 ... and someone will take your money unless you go out a few years.
Either way, it's an interesting time to be an edge operator that worries about CPE stuff. those that think mostly about core this is a big fat *yawn* imho. Expect application developers to face some interesting challenges. me? I'm waiting until I see the "NOW WITH IPv6" sticker on things at the store.
IPv6-ready logos exist.
- Jared
The end of IPv4 is near, but that doesn't mean the end of the Internet is here. The next chapter gets a new page turned. Maybe we will determine that IPv6 needs to go the way of IPX/Decnet/AppleTalk and some new system (non-IP even) will take over the world.
IMHO, there is no such thing like "the end of IPv4 is near", what is near is the exhaustion of the IPv4 address space for new allocations. Unfortunately, as Bill mentioned, IPv6 does not offer much more than an expanded address space, quite a different situation with the proprietary protocols you mentioned, then there is no much benefit/motivation for many to switch in a hurry. No doubt that we need to move forward and keep pushing to get IPv6 deployed, but it will coexist for many many years with IPv4 which will probably never go 100% away. My .02 Jorge
On Thu, 21 Oct 2010 22:09:39 -0400 Jared Mauch <jared@puck.nether.net> wrote:
On Oct 21, 2010, at 9:51 PM, Barry Shein wrote:
Anyhow, it might be an interesting topic to discuss in the appropriate venues, IETF, "What is the cost of maintaining IPv4 forever?" but it's getting a little ahead of ourselves in terms of any pressing need.
This is an interesting question.
In talking to your vendors with your checklist of capabilities a device CAN/SHOULD/MUST have, what if you no longer needed to carry 350k/512k routes of IPv4 and only needed 256k of IPv6 ?
Instead of 6pe think of 4pe with ipv6 core.
I've been reminding vendors that IPv6 should get new features *first* vs IPv4. The end of IPv4 is near, but that doesn't mean the end of the Internet is here. The next chapter gets a new page turned. Maybe we will determine that IPv6 needs to go the way of IPX/Decnet/AppleTalk and some new system (non-IP even) will take over the world.
Either way, it's an interesting time to be an edge operator that worries about CPE stuff. those that think mostly about core this is a big fat *yawn* imho. Expect application developers to face some interesting challenges. me? I'm waiting until I see the "NOW WITH IPv6" sticker on things at the store.
If you go into the right store, you'll see one. http://forums.whirlpool.net.au/forum-replies.cfm?t=1470849&p=5#r83
- Jared
I think the words you're looking for are "revoked", "reclaimed", and "returned" address space. On October 22, 2010 at 02:53 niels=nanog@bakker.net (Niels Bakker) wrote:
* bzs@world.std.com (Barry Shein) [Thu 21 Oct 2010, 22:59 CEST]:
And, of course, the RIRs could just cancel all the IPv4 route announcements, whatever they do if someone doesn't pay or whatever.
I think you're mistaking the default-free zone for Usenet. The DFZ doesn't have 'cmsg cancel' messages.
-- Niels.
-- "It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account." -- roy edroso, alicublog.blogspot.com
-- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
On 10/21/2010 1:56 PM, Barry Shein wrote:
Well, if the DNS root servers ceased IPv4 service it'd be pretty much a fait accompli as far as the public internet is concerned.
Given the reality of fragmenting the DNS -- including its root -- that's an action that well might backfire. Current fragmentation is constrained; this could plausibly motivate more people to pursue other paths and thereby blow things up. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Dave CROCKER wrote:
On 10/21/2010 1:56 PM, Barry Shein wrote:
Well, if the DNS root servers ceased IPv4 service it'd be pretty much a fait accompli as far as the public internet is concerned.
Given the reality of fragmenting the DNS -- including its root -- that's an action that well might backfire. Current fragmentation is constrained; this could plausibly motivate more people to pursue other paths and thereby blow things up.
d/
Luckily we have already prepared the cure for that disease. Apparently DNSSEC is catching on right about now. Joe
On October 22, 2010 at 08:48 dhc2@dcrocker.net (Dave CROCKER) wrote:
On 10/21/2010 1:56 PM, Barry Shein wrote:
Well, if the DNS root servers ceased IPv4 service it'd be pretty much a fait accompli as far as the public internet is concerned.
Given the reality of fragmenting the DNS -- including its root -- that's an action that well might backfire. Current fragmentation is constrained; this could plausibly motivate more people to pursue other paths and thereby blow things up.
I wouldn't suggest doing it without A LOT of coordination with stakeholders. While we're on the subject, someone else suggested that one source of authority would be the Tier-1 vendors, the other would be governments. Tying the two sub-threads together I believe there's sufficient authority vested in the DNS management and RIRs to accomplish a transition to an, effectively, all-IPv6 internet without either of the above leading tho they would have to follow of course. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
How would you respond if that were announced?
If I were king for a day,
But you aren't. No one is.
The core requirement for such announcements is that there be a real enforcement arm.
Not necessarily. If you announce that YOU will treat that date as a sunset date for IPv4 and invite other organizations to sign up for the declaration, you might be able to get a movement going. Alice's Restaurant comes to mind as does the Cluetrain Manifesto.
The best that can be done with respect to declaring a IPv4 sunset date is localized pockets of such control.
One could, of course, imagine a federation of such pockets...
That is too top down, and sounds too much like the ITU, a federation of governments. I don't think that would work but a voluntary manifesto that people could sign up to would work. --Michael Dillon
Putting a sunset clause will happen but when it won't matter much. We are not there yet. However, I could see it also coming from a vendor as a way to get customers to upgrade (after that date we will not support IPv4 anymore and provide patches for IPv4). ----- Original Message ----- From: "Michael Dillon" <wavetossed@googlemail.com> To: "NANOG" <nanog@nanog.org> Sent: Friday, 22 October, 2010 9:24:57 AM Subject: Re: IPv4 sunset date set for 2019-12-31
How would you respond if that were announced?
If I were king for a day,
But you aren't. No one is.
The core requirement for such announcements is that there be a real enforcement arm.
Not necessarily. If you announce that YOU will treat that date as a sunset date for IPv4 and invite other organizations to sign up for the declaration, you might be able to get a movement going. Alice's Restaurant comes to mind as does the Cluetrain Manifesto.
The best that can be done with respect to declaring a IPv4 sunset date is localized pockets of such control.
One could, of course, imagine a federation of such pockets...
That is too top down, and sounds too much like the ITU, a federation of governments. I don't think that would work but a voluntary manifesto that people could sign up to would work. --Michael Dillon
On Thu, 21 Oct 2010, Jared Mauch wrote:
How would you respond if that were announced? Carriers have been doing technology transitions for years. Cidr to classless. Amps to CDMA or gsm... This is not new.
My next question would be "How many times will that get extended/pushed back because somebody screams loudly enough?". It will probably sunset around the time that v6 starts to run out of gas and people start thinking about IPv8 (assuming IPv7 would be treated like odd-numbered Linux kernel releases like 2.3.x, 2.5.x, etc - never to see the light of day) :) jms
My next question would be "How many times will that get extended/pushed back because somebody screams loudly enough?". It will probably sunset around the time that v6 starts to run out of gas and people start
"Justin M. Streiner" <streiner@cluebyfour.org> wrote on 10/21/2010 01:58:46 PM: thinking
about IPv8 ...
Oooh. Did someone say IPv8? http://mailman.apnic.net/mailing-lists/apnic-talk/archive/1998/02/msg00030.h... Joe
On Oct 21, 2010, at 10:58 AM, Justin M. Streiner wrote:
On Thu, 21 Oct 2010, Jared Mauch wrote:
How would you respond if that were announced? Carriers have been doing technology transitions for years. Cidr to classless. Amps to CDMA or gsm... This is not new.
My next question would be "How many times will that get extended/pushed back because somebody screams loudly enough?". It will probably sunset around the time that v6 starts to run out of gas and people start thinking about IPv8 (assuming IPv7 would be treated like odd-numbered Linux kernel releases like 2.3.x, 2.5.x, etc - never to see the light of day) :)
jms
I'll point out that the FCC sort of tried that with the NTSC->ATSC move. Finally the broadcasters said "Screw that... You can tell us when we have to turn on ATSC, but, you can't actually prevent us from turning off NTSC. Click!" Owen
The IPv4 space here was retired in 2009. We love the IVI translator code. Whats keeping the rest of you? --bill
On Fri, Oct 22, 2010, bmanning@vacation.karoshi.com wrote:
The IPv4 space here was retired in 2009. We love the IVI translator code. Whats keeping the rest of you?
Just hazarding a guess: router# conf t router(config)# ipv6 ivi enable router(config)# ^Z Adrian
On Fri, Oct 22, 2010 at 11:40:29AM +0800, Adrian Chadd wrote:
On Fri, Oct 22, 2010, bmanning@vacation.karoshi.com wrote:
The IPv4 space here was retired in 2009. We love the IVI translator code. Whats keeping the rest of you?
Just hazarding a guess:
router# conf t router(config)# ipv6 ivi enable router(config)# ^Z
not so much - it runs on linux instead of a closed OS. #ifconfig eth0 <v4 from upstream> #ifconfig eth0 <v6 fm RIR> #ifconfig eth1 <ULA> #ivi eth0 eth1 & gets me native IPv6 to IPv6 speakers and translates back into the Internet for those stuck in the smallisher Internet. --bill
Adrian
On 10/21/2010 10:48 PM, bmanning@vacation.karoshi.com wrote:
not so much - it runs on linux instead of a closed OS.
I think you missed the point. Many are waiting for it to be supported on their brand of routers. Not everyone has huge numbers of servers sitting around acting as translation gateways (or spying on traffic). Jack
On Thu, Oct 21, 2010 at 10:52:32PM -0500, Jack Bates wrote:
On 10/21/2010 10:48 PM, bmanning@vacation.karoshi.com wrote:
not so much - it runs on linux instead of a closed OS.
I think you missed the point. Many are waiting for it to be supported on their brand of routers. Not everyone has huge numbers of servers sitting around acting as translation gateways (or spying on traffic).
true dat. but there was also a subtext on CPE kit. not all of us are big telcos or buy IP service from same. to paraphrase Dave, if ATT decides to drop IPv4 support, sigh its a pita, but I don't -NEED- ATT IP services. I can get much/most of what I want/need w/ a little work/elbow greese. if the goal was to scare people w/ a very public "retirement" date for IPv4 - then maybe it worked. As for me, the retirement date was a year or so back. No worries here. if folks fit the model described above, the rock is new/untested code (IPv6 support) and the hard place is NAT (still going to need it in a mixed v4/v6 world) ... If there are NAT functions w/ tested code paths that have already passed QA, then that becomes an easier sell to mgmt - no? And ATT realises that 99.982% of its customers could care less if its IPv4 or IPv6 or IPX... They just know (cause ATT told them) that the Internet grew out of the World Wide Web... and that is what they need with their i[fone/pad/pod/tv]. ATT will find a way to keep its costs down and provide the functionality demanded by its customers.
Jack
On Oct 22, 2010, at 12:10 AM, bmanning@vacation.karoshi.com wrote:
On Thu, Oct 21, 2010 at 10:52:32PM -0500, Jack Bates wrote:
On 10/21/2010 10:48 PM, bmanning@vacation.karoshi.com wrote:
not so much - it runs on linux instead of a closed OS.
I think you missed the point. Many are waiting for it to be supported on their brand of routers. Not everyone has huge numbers of servers sitting around acting as translation gateways (or spying on traffic).
true dat. but there was also a subtext on CPE kit.
not all of us are big telcos or buy IP service from same.
to paraphrase Dave, if ATT decides to drop IPv4 support, sigh its a pita, but I don't -NEED- ATT IP services. I can get much/most of what I want/need w/ a little work/elbow greese.
if the goal was to scare people w/ a very public "retirement" date for IPv4 - then maybe it worked. As for me, the retirement date was a year or so back. No worries here.
if folks fit the model described above, the rock is new/untested code (IPv6 support) and the hard place is NAT (still going to need it in a mixed v4/v6 world) ... If there are NAT functions w/ tested code paths that have already passed QA, then that becomes an easier sell to mgmt - no?
And ATT realises that 99.982% of its customers could care less if its IPv4 or IPv6 or IPX... They just know (cause ATT told them) that the Internet grew out of the World Wide Web... and that is what they need with their i[fone/pad/pod/tv].
ATT will find a way to keep its costs down and provide the functionality demanded by its customers.
It seems to me that it would be very scary for AT&T for AT&T to say, "we will shut off IPv4 in X years, prepare now" - what if provider X starts running ads saying "AT&T doesn't want your business, but we do and will keep you happy." So, unless one provider really becomes dominate in 10-15 years, I don't see that happening. If providers X, Y and Z band together to do this, I see anti-Trust issues (although IANAL). I can't see an SDO like the IETF doing this (and the IETF is not immune to anti-trust, either). So, if we go down this road, the only real path I see involves some government (US, EU, maybe in 15 years even the PRC) or some set of governments mandating it. Whether that would be a good thing is left as an exercise to the reader. Regards Marshall
Jack
(bill is a tease) On Thu, Oct 21, 2010 at 11:48 PM, <bmanning@vacation.karoshi.com> wrote:
On Fri, Oct 22, 2010 at 11:40:29AM +0800, Adrian Chadd wrote:
On Fri, Oct 22, 2010, bmanning@vacation.karoshi.com wrote:
The IPv4 space here was retired in 2009. We love the IVI translator code. Whats keeping the rest of you?
Just hazarding a guess:
router# conf t router(config)# ipv6 ivi enable router(config)# ^Z
not so much - it runs on linux instead of a closed OS.
#ifconfig eth0 <v4 from upstream> #ifconfig eth0 <v6 fm RIR> #ifconfig eth1 <ULA>
#ivi eth0 eth1 &
neat! I can install that on my ubuntu machine! <http://packages.ubuntu.com/dapper/electronics/ivi> wee! (now I'm teasing.. .Bill where's your docs on this fantastic new teknowlogie?)
gets me native IPv6 to IPv6 speakers and translates back into the Internet for those stuck in the smallisher Internet.
--bill
Adrian
-----Original Message----- From: Christopher Morrow > Sent: Thursday, October 21, 2010 9:49 PM To: bmanning Cc: NANOG Subject: Re: IPv4 sunset date revised : 2009-02-05
(now I'm teasing.. .Bill where's your docs on this fantastic new teknowlogie?)
I found it here: http://www.ivi2.org/ But the readme is a bit confusing: http://www.ivi2.org/code/00-ivi0.5-README Trying to figure out how they map a /70 v6 prefix to a /30 v4 prefix assuming the mapping is to be 1-1 It seems the docs are a bit sparse and the kernel version is rather ancient (patches against 2.6.18)
On Thu, Oct 21, 2010 at 10:20 PM, George Bonser <gbonser@seven.com> wrote:
-----Original Message----- From: Christopher Morrow > Sent: Thursday, October 21, 2010 9:49 PM To: bmanning Cc: NANOG Subject: Re: IPv4 sunset date revised : 2009-02-05
(now I'm teasing.. .Bill where's your docs on this fantastic new teknowlogie?)
I found it here:
But the readme is a bit confusing:
http://www.ivi2.org/code/00-ivi0.5-README
Trying to figure out how they map a /70 v6 prefix to a /30 v4 prefix assuming the mapping is to be 1-1
Right, 1 to 1 does not solve any IPv4 exhaustion problems. Going back to the title of the thread, IVI does not help you sunset IPv4 since the same amount of IPv4 is required. NAT64 is the protocol that helps you "sunset" IPv4 by providing native IPv6 to the user and doing a protocol translation similar to NAPT to IPv4 destination. Thusly, IPv6 end to end applications benefit from not having a middle box and experience more features (e2e) and less flaky NAPT, ... keep in mind that NAPT is the status quo in many places, especially in mobile wireless, end to end IPv6 is an upgrade. This is pretty impactful since major internet destinations like Google, Netflix, Facebook have IPv6 deployments in place today. For many, this is a ~50% reduction in NAT which is ~50% increase in E2E communication (less cost, better quality). Since economics and user experience are involved, this is a real path to migrating from IPv4 to IPv6. The right incentive structure is in place for both the service provider who is out of addresses and the consumer who wants rich e2e communication. Shameless plug, i have it working here for over 9 months http://groups.google.com/group/tmoipv6beta Cameron
It occurs to me that there is some pressing need to investigate this all-IPv6 internet -- motivated by the cost of (not) maintaining IPv4 forever. Right now we can observe essentially an all-IPv4 internet (99%, whatever.) In a very few years, possibly as few as two, the picture might become much more muddied and it could become more difficult to extract IPv4 specific costs from mixed IPv4/IPv6 costs. For example, I'd imagine the RIRs are just at the cusp of ceasing to spend all their address management efforts on IPv4. In two years more and more of their expenses might be difficult to distinguish as exclusively IPv4 or IPv6. Also, when IPv4 addresses do run out then more effort will be spent on that new environment where they move from fulfilling needs (i.e., just making new IPv4 allocations) to mitigating needs -- revocation, reclamation, and return, and subsequent allocation no doubt by new policies. So, this might be roughly our last chance to get some measurements on the management of an all IPv4 network, and monitor the transition as it happens. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
On Fri, Oct 22, 2010 at 01:28:24PM -0400, Barry Shein wrote:
It occurs to me that there is some pressing need to investigate this all-IPv6 internet -- motivated by the cost of (not) maintaining IPv4 forever.
Right now we can observe essentially an all-IPv4 internet (99%, whatever.)
-- -Barry Shein
For this, you need to leave the comfort of NANOG and look at the CERNnet network over the past ten years. They have been running a large, all IPv6 network for some time now. http://www.authorstream.com/Presentation/Cannes-19148-IPv6-development-China... www.cs.princeton.edu/~yiwang/papers/iscc05.pdf http://www.cernet2.edu.cn/en/char.htm --bill
The idea was to observe and measure an (almost) all IPv4 network and its management/infrastructure costs, namely the one we got, not an IPv6 one, before the transition starts to muddy the waters significantly. -b On October 22, 2010 at 18:03 bmanning@vacation.karoshi.com (bmanning@vacation.karoshi.com) wrote:
On Fri, Oct 22, 2010 at 01:28:24PM -0400, Barry Shein wrote:
It occurs to me that there is some pressing need to investigate this all-IPv6 internet -- motivated by the cost of (not) maintaining IPv4 forever.
Right now we can observe essentially an all-IPv4 internet (99%, whatever.)
-- -Barry Shein
For this, you need to leave the comfort of NANOG and look at the CERNnet network over the past ten years. They have been running a large, all IPv6 network for some time now.
http://www.authorstream.com/Presentation/Cannes-19148-IPv6-development-China...
www.cs.princeton.edu/~yiwang/papers/iscc05.pdf
http://www.cernet2.edu.cn/en/char.htm
--bill
-- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
On Fri, Oct 22, 2010 at 09:42:50AM -0700, Cameron Byrne wrote:
On Thu, Oct 21, 2010 at 10:20 PM, George Bonser <gbonser@seven.com> wrote:
-----Original Message----- From: Christopher Morrow > Sent: Thursday, October 21, 2010 9:49 PM To: bmanning Cc: NANOG Subject: Re: IPv4 sunset date revised : 2009-02-05
(now I'm teasing.. .Bill where's your docs on this fantastic new teknowlogie?)
I found it here:
But the readme is a bit confusing:
http://www.ivi2.org/code/00-ivi0.5-README
Trying to figure out how they map a /70 v6 prefix to a /30 v4 prefix assuming the mapping is to be 1-1
Right, 1 to 1 does not solve any IPv4 exhaustion problems.
ah... but the trick is to only need enough IPv4 in the pool to dynamically talk to the Internet. Native v6 to Native v6 never has to drop back to the Internet, It uses native v6 paths. So the larger the v6 uptake, the fewer Internet addreses you'll need to keep around in your pool.
Going back to the title of the thread, IVI does not help you sunset IPv4 since the same amount of IPv4 is required.
See above.
Cameron
On Fri, Oct 22, 2010 at 10:54 AM, <bmanning@vacation.karoshi.com> wrote:
On Fri, Oct 22, 2010 at 09:42:50AM -0700, Cameron Byrne wrote:
On Thu, Oct 21, 2010 at 10:20 PM, George Bonser <gbonser@seven.com> wrote:
-----Original Message----- From: Christopher Morrow > Sent: Thursday, October 21, 2010 9:49 PM To: bmanning Cc: NANOG Subject: Re: IPv4 sunset date revised : 2009-02-05
(now I'm teasing.. .Bill where's your docs on this fantastic new teknowlogie?)
I found it here:
But the readme is a bit confusing:
http://www.ivi2.org/code/00-ivi0.5-README
Trying to figure out how they map a /70 v6 prefix to a /30 v4 prefix assuming the mapping is to be 1-1
Right, 1 to 1 does not solve any IPv4 exhaustion problems.
ah... but the trick is to only need enough IPv4 in the pool to dynamically talk to the Internet. Native v6 to Native v6 never has to drop back to the Internet, It uses native v6 paths. So the larger the v6 uptake, the fewer Internet addreses you'll need to keep around in your pool.
Going back to the title of the thread, IVI does not help you sunset IPv4 since the same amount of IPv4 is required.
See above.
So works, just not at a large scale. For larger scale, you need address sharing like NAT64.
On Fri, Oct 22, 2010 at 11:21:36AM -0700, Cameron Byrne wrote:
On Fri, Oct 22, 2010 at 10:54 AM, <bmanning@vacation.karoshi.com> wrote:
On Fri, Oct 22, 2010 at 09:42:50AM -0700, Cameron Byrne wrote:
On Thu, Oct 21, 2010 at 10:20 PM, George Bonser <gbonser@seven.com> wrote:
-----Original Message----- From: Christopher Morrow > Sent: Thursday, October 21, 2010 9:49 PM To: bmanning Cc: NANOG Subject: Re: IPv4 sunset date revised : 2009-02-05
(now I'm teasing.. .Bill where's your docs on this fantastic new teknowlogie?)
I found it here:
But the readme is a bit confusing:
http://www.ivi2.org/code/00-ivi0.5-README
Trying to figure out how they map a /70 v6 prefix to a /30 v4 prefix assuming the mapping is to be 1-1
Right, 1 to 1 does not solve any IPv4 exhaustion problems.
ah... but the trick is to only need enough IPv4 in the pool to dynamically talk to the Internet. Native v6 to Native v6 never has to drop back to the Internet, It uses native v6 paths. So the larger the v6 uptake, the fewer Internet addreses you'll need to keep around in your pool.
Going back to the title of the thread, IVI does not help you sunset IPv4 since the same amount of IPv4 is required.
See above.
So works, just not at a large scale. For larger scale, you need address sharing like NAT64.
depends on your definition of "large" scale. for cernet2 --- "The grid over IPv6 covers 20 universities distributed in 13 cities, and the aggregation capability is high above 15 trillion time/sec, and the storage capability above 150TB." "CNGI-CERNET2 backbone runs IPv6 protocol and connects 25 PoPs distributed in 20 cities in China with the speed of 2.5Gbps/10Gbps. Meanwhile, the transmission rate of Beijing-Wuhan-Guangzhou and Wuhan-Nanjing-Shanghai is 10Gbps. Each PoP provides the 1Gbps/2.5Gbps/10Gbps access capacity for the access network. "Since the opening in 2004, CNGI-CERNET2 backbone has connected more than 200 IPv6 access networks of universities and R&D institutes in China, supported technical trials and application demonstration, and provided excellent environment for world-wide next generation Internet research." So, yeah... for these smaller, regional networks, its a good fit. For you big guys, you may need something else. --bill
From: bmanning@vacation.karoshi.com
ah... but the trick is to only need enough IPv4 in the pool to dynamically talk to the Internet. Native v6 to Native v6 never has to drop back to the Internet, It uses native v6 paths. So the larger the v6 uptake, the fewer Internet addreses you'll need to keep around in your pool.
Ok, it wasn't clear in the docs that it was a dynamic translation from v6 to a smaller pool of v4 IPs, it implied it was a direct translation. G
On Fri, Oct 22, 2010 at 12:20:45PM -0700, George Bonser wrote:
From: bmanning@vacation.karoshi.com
ah... but the trick is to only need enough IPv4 in the pool to dynamically talk to the Internet. Native v6 to Native v6 never has to drop back to the Internet, It uses native v6 paths. So the larger the v6 uptake, the fewer Internet addreses you'll need to keep around in your pool.
Ok, it wasn't clear in the docs that it was a dynamic translation from v6 to a smaller pool of v4 IPs, it implied it was a direct translation.
G
i think it started out that way. one of my students tweeked DHCP to do the right thing wrt IP assignment from the pool (can't use the MAC, must use the v6 address) and then dynamic DNS update. Others have looked at and built higher capacity tools - you could ask Charlie Perkins about his experiences. End of the day, this isn't rocket science, isn't new, and there are communities of folks who have, in their own quiet way, made the switch already. for some, a flag day may occur. I think it will be rare, but it could happen. for the aware, moving to IPv6 was something we planned on and executed over the past few years. for the less aware, they are just waking up and are concerned. some are still sleeping. paraphrasing N.Maxwell; "$Diety does not use the voice of thunder when a still small voice will do." anyone still not paying attention? (read the CERNET2 reports on the costs of dual-stack...) Native may be your best long term bet. --bill
Sent: Friday, October 22, 2010 1:37 PM To: George Bonser Cc: bmanning Subject: Re: IPv4 sunset date revised : 2009-02-05
anyone still not paying attention? (read the CERNET2 reports on the costs of dual-stack...) Native may be your best long term bet.
--bill
That is a point I have made with people at times, too. If you are struggling holding the current table of 32-bit routes, what is the addition of a bunch of 128-bit routes going to do? Full routes dual-stack is going to hurt people in a lot of places. This was another reason for aggressively reclaiming unused IP addresses without issuing any new, it would reduce the extent to which v4 could continue to frag. It will be sort of like a bulge moving through a snake for a while as the v6 table begins to grow with multihomed /48's and the v4 table also grows with increased fragmentation. And "Katy, bar the door" if they take away the multihomed restriction for GU /48's.
From: Ben Butler Sent: Thursday, October 21, 2010 10:18 AM To: 'Marshall Eubanks' Cc: NANOG Subject: RE: Only 5x IPv4 /8 remaining at IANA
Hi,
What is the consequence of not managing to transition the v4 network and having to maintain it indefinitely. I think if the cost / limitations that this may place on things is great enough then the "how" will reveal itself with the interested parties.
Is there a downside to being stuck with both address spaces rather
than
just 6, idk, you tell me, but there seems to be from what I can tell.
I am not suggesting any form of timeframe in the exact number of years / decades, just that a timeframe should exist where after a certain date - whatever that is - we can say ok, now we are turning off v4.
The first step will be a registrar saying "after this date, we will no longer issue any IPv4 addresses for whatever reason" and at the same time, getting very aggressive in reclaiming space from dead entities, hijackers, etc. As time goes by, the amount of v4 space being routed declines through natural attrition. It is a combination of liberal v6 assignment coupled with aggressive v4 reclamation. At some point the network operators themselves will announce their own "drop dead" dates for supporting v4. When the amount of v4 traffic drops to some point where the infrastructure required to support it becomes unreasonable, they will stop supporting it. As v4 becomes harder to route, it will become harder to find v4 providers ... sort of like v6 is not available from *all* providers in a native sense today. Sure, there will probably be people out there who will offer v4 over v6 tunnels long after most providers have stopped routing it sort of like 6 over 4 is offered today, but even those will become scarce at some point. Once no more addresses are issued for any reason and once people stop handling the traffic natively, it will die its own natural death and kids entering the networking field will look at a v4 config and wonder why it is even there.
In the absence of any form of timeframe what is the operational benefit of any existing v4 user migrating to v6 if the service provider is going to make magic happen that enables them to talk to v6 only host via some mysterious bridging box.
Yeah, that does delay things but is required glue for the moment.
I can see none, which tells me they are not going to bother spending there time and money renumbering and deploying v6 - ever!
Yes they will, see above.
There needs to be a technical, commercial or operational reason for them to want to go through the change.
Ben
Yeah, the "we decided to make a completely incompatible protocol with really no other immediate technical benefit other than more address space ... and each route takes up 4x more router resources" decision was probably a bad call. Heck, simply expanding the number of ports from 16 bit to 32 bit would have greatly reduced ip address requirements from people having to add IPs to NAT pools and other source NATs due to port exhaustion.
On Thu, Oct 21, 2010 at 12:53 PM, George Bonser <gbonser@seven.com> wrote:
The first step will be a registrar saying "after this date, we will no longer issue any IPv4 addresses for whatever reason" and at the same time, getting very aggressive in reclaiming space from dead entities, hijackers, etc. As time goes by, the amount of v4 space being routed declines through natural attrition. It is a combination of liberal v6 assignment coupled with aggressive v4 reclamation.
Why on earth would a registrar aggressively reclaim space from entities if they're no longer issuing it back out? Are we planning on recommending policies into the ARIN AC that turn ARIN into an IPv4 space reclamation entity, to hoard up v4 addresses? As it now stands, the amount of v4 space being routed will trend towards the asymptote of maximal organizational utilization, and will *not* decline. Any organization that moves resources off v4 and frees up address space will either hold that space as an ongoing resource to be used for future expansions, or will sell it off on the transfer market for short-term cash infusions; the new holders, having paid good cash for it, will have a strong incentive to get it routed and carrying traffic as quickly as possible, to pay back their investment. There is *nothing* in the system driving towards a natural attrition of IPv4 usage, even after runout; we simply change the allocation model from purely needs based, to needs+cash based. Unless ISPs state that they will charge additional money to assign v4 addresses to customers, over what they charge to v6 customers, there is no real pressure in the marketplace for the amount of v4 routing to decline. So long as the end user sees the same cost, and same service for using v4 as v6, there is no pressure towards a v6-only world. So...uh...who's going to be first to step up and tell their customers "look, you get a v6 /56 for free with your account, but if you want v4 addresses, it's going to cost an extra $50/month." ?? Matt
Matthew Petach wrote:
So...uh...who's going to be first to step up and tell their customers "look, you get a v6 /56 for free with your account, but if you want v4 addresses, it's going to cost an extra $50/month." ??
Matt
Either the telephone company or the cable company. Probably both. Give me a harder one. Joe
On Oct 21, 2010, at 3:29 PM, Joe Maimon wrote:
Matthew Petach wrote:
So...uh...who's going to be first to step up and tell their customers "look, you get a v6 /56 for free with your account, but if you want v4 addresses, it's going to cost an extra $50/month." ??
Matt
Either the telephone company or the cable company. Probably both. Give me a harder one.
Joe
ROFL, Comcast is already telling their residential customers that if they want a static IPv4 address it will cost them an extra ~$60/month. (Delta between residential and business: ~$55/month, single static IPv4 address on business circuit: $5/month) Owen
Step 1: On 21/10/10 18:34 -0700, Owen DeLong wrote:
ROFL, Comcast is already telling their residential customers that if they want a static IPv4 address it will cost them an extra ~$60/month.
(Delta between residential and business: ~$55/month, single static IPv4 address on business circuit: $5/month)
Owen
Step 2: http://lists.arin.net/pipermail/arin-issued/2010-October/000675.html ~$ whois 50.128.0.0 | grep 'NetRange\|OrgName' NetRange: 50.128.0.0 - 50.255.255.255 OrgName: Comcast Cable Communications Holdings, Inc Step 3: Profit! -- Dan White
On Thu, Oct 21, 2010 at 6:34 PM, Owen DeLong <owen@delong.com> wrote:
On Oct 21, 2010, at 3:29 PM, Joe Maimon wrote:
Matthew Petach wrote:
So...uh...who's going to be first to step up and tell their customers "look, you get a v6 /56 for free with your account, but if you want v4 addresses, it's going to cost an extra $50/month." ??
Matt
Either the telephone company or the cable company. Probably both. Give me a harder one.
Joe
ROFL, Comcast is already telling their residential customers that if they want a static IPv4 address it will cost them an extra ~$60/month.
(Delta between residential and business: ~$55/month, single static IPv4 address on business circuit: $5/month)
Owen
*sigh* But what's the delta for getting the equivalent IPv6 resource? You're comparing apples to oranges. If comcast says "you get a static /56 of v6 for free, but a static v4 address costs $55/month", then I can see you point. But right now, the delta is between dynamic v4 (free) and static v4 ($55), with no delta between dynamic v4 (free) and dynamic v6 (free), and no option that I've seen for static v4 ($55) vs static v6 ($???). It's those last two cases that would drive the deprecation of v4 over time; and *that* is the step I don't foresee any provider wanting to do; certainly, not being first up to the plate to do. Matt
Matthew Petach wrote:
On Thu, Oct 21, 2010 at 6:34 PM, Owen DeLong<owen@delong.com> wrote:
On Oct 21, 2010, at 3:29 PM, Joe Maimon wrote:
Matthew Petach wrote:
So...uh...who's going to be first to step up and tell their customers "look, you get a v6 /56 for free with your account, but if you want v4 addresses, it's going to cost an extra $50/month." ??
Matt
Either the telephone company or the cable company. Probably both. Give me a harder one.
Joe
ROFL, Comcast is already telling their residential customers that if they want a static IPv4 address it will cost them an extra ~$60/month.
(Delta between residential and business: ~$55/month, single static IPv4 address on business circuit: $5/month)
Owen
*sigh*
But what's the delta for getting the equivalent IPv6 resource? You're comparing apples to oranges.
If comcast says "you get a static /56 of v6 for free, but a static v4 address costs $55/month", then I can see you point.
But right now, the delta is between dynamic v4 (free) and static v4 ($55), with no delta between dynamic v4 (free) and dynamic v6 (free), and no option that I've seen for static v4 ($55) vs static v6 ($???).
It's those last two cases that would drive the deprecation of v4 over time; and *that* is the step I don't foresee any provider wanting to do; certainly, not being first up to the plate to do.
Matt
How about when they put new users behind CGN/LSN? Depending on how successful that is (for them), the delta can change dramatically. It would be private v4 free, public v6 free (we hope), public v4 (static or dynamic) for $(?+). Further dependent is what they will do to existing users. I can see them choosing to be fair and making all users suffer equivalently. I can further see a potential result of huge swathes of v4 resources reusable by these companies, probably dwarfing the reclaimable resources most any other provider without a similar customer profile will have. Joe
" see a potential result of huge swathes of v4 resources reusable by these companies, probably dwarfing the reclaimable resources most any other provider without a similar customer profile will have." See this is at the hub of it as well, is it a reusable resource, or is it an obsolete one? Should it be getting resused for multi-homeing or content providers, or should it be retired by the ISP that has migrated their subs onto v6? I think if we continue with a mind set that v4 is a previous resource and once I have freed it up by moving to v6 I must hang onto it and of course if I have got some free I best deploy it again for a new customer - this seems completely circular to me. I think the question is: 1> Are we attempting to migrate from IPv4 to IPv6 and end up at a place ultimately where IPv4 is fully intended to be retired. Or 2> Are we simply intending to extend the address space with IPv6 and continue to pretty much carry on business as normal with existing IPv4 deployments in any meaningly foreseeable time frame and run a dual stack network. Further more that it is ok to reutilize any free up IPv4 space along the way as we are never planning on retiring it anyway. I personally think it should be the first of those, but my opinion doesn't really count for squat. Ultimately I would rather we be clear about what we are wishing / aspiring / trying to achieve and then set about achieving it collectively. If the collective view is that it is not a migration but a co-existence that we are aiming for then ok, lets stop pretending otherwise, if however the collective direction is migration then can we please collectively do our best to facilitate and encourage the migration. As opposed to having various tactics to drag out the migration as long as possible as some think that if they drag their feet in perpetuity that the v4 to v6 bridging magic will become the duty of the service provider to make it work for content providers and subscribers that don't want to update CPE routers or rewrite code where nessacery. If we, as a community of operators are going to get on and deploy IPv6 and we agree it's a migration the lets get doing and set some targets dates / BCP for when it is reasonably expected that net/sys admins will have completed the rollout and by whatever contractual or commercial / technical means migrated their customers. If, however, we as a community don't want migration but cohabitation then lets do that. Which one do we ultimately want? Ben -----Original Message----- From: Joe Maimon [mailto:jmaimon@ttec.com] Sent: 22 October 2010 14:25 To: Matthew Petach Cc: NANOG Subject: Re: Only 5x IPv4 /8 remaining at IANA -------------------------------------------------------------------------- BODY { MARGIN: 0px}.footerdark { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #001a35; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.blackcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.bluecopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #29aae2; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.address { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; TEXT-DECORATION: none}.footerlight { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #667891; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.pinkcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #ed174d; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none} Ben Butler Director Tel: 0333 666 3332 Fax: 0333 666 3331 C2 Business Networking Ltd The Paddock, London Road, Nantwich, Cheshire, CW5 7JL http://www.c2internet.net/ Part of the Atlas Business Group of Companies plc Registered in England: 07102986 Registered Address: Datum House, Electra Way, Crewe CW1 6ZF Vat Registration No: 712 9503 48 This message is confidential and intended for the use only of the person to whom it is addressed. If you are not the intended recipient you are strictly prohibited from reading, disseminating, copying, printing, re-transmitting or using this message or its contents in any way. Opinions, conclusions and other information expressed in this message are not given or authorised by the Company unless otherwise indicated by an authorised representative independent of this message. The Company does not accept liability for any data corruption, interception or amendment to any e-mail or the consequences thereof.Emails addressed to individuals may not necessarily be read by that person unless they are in the office.Calls to and from any of the Atlas Business Group of Companies may be recorded for the purposes of training, monitoring of quality and customer services.
Ben Butler wrote:
If we, as a community of operators are going to get on and deploy IPv6 and we agree it's a migration the lets get doing and set some targets dates / BCP for when it is reasonably expected that net/sys admins will have completed the rollout and by whatever contractual or commercial / technical means migrated their customers. If, however, we as a community don't want migration but cohabitation then lets do that. Which one do we ultimately want?
Ben
The key word in the phrase collective self interest is self. Solve that first, the rest comes along for the ride. There is no cabal. Joe
-----Original Message----- From: Ben Butler [mailto:ben.butler@c2internet.net] Sent: Friday, October 22, 2010 8:40 AM To: NANOG Subject: RE: Only 5x IPv4 /8 remaining at IANA
" see a potential result of huge swathes of v4 resources reusable by these companies, probably dwarfing the reclaimable resources most any other provider without a similar customer profile will have."
See this is at the hub of it as well, is it a reusable resource, or is it an obsolete one? Should it be getting resused for multi-homeing or content providers, or should it be retired by the ISP that has migrated their subs onto v6?
I think if we continue with a mind set that v4 is a previous resource and once I have freed it up by moving to v6 I must hang onto it and of course if I have got some free I best deploy it again for a new customer - this seems completely circular to me. I think the question is:
1> Are we attempting to migrate from IPv4 to IPv6 and end up at a place ultimately where IPv4 is fully intended to be retired.
Or
2> Are we simply intending to extend the address space with IPv6 and continue to pretty much carry on business as normal with existing IPv4 deployments in any meaningly foreseeable time frame and run a dual stack network. Further more that it is ok to reutilize any free up IPv4 space along the way as we are never planning on retiring it anyway.
If, after run out, most new deployments are done in v6 and if end users are being migrated to v6 wholesale by such organizations as the Comcasts of the world, who would *want* to deploy a new operation in v4 space? If the native packets of the users need to be translated in some way to v4 in order to reach you, the apparent performance of someone's operation is ultimately limited by the performance of whatever is doing that translation, wherever that device is (either at your end or the other end). The migration out of v4 will go pretty quickly once there is a compelling business reason for that to take place such as the people buying your product or the people who you want to buy your product are on v6 or your partners with whom you need to transact are on v6. Once a few large groups of users are native v6, once v4 has run out, once enough popular destinations are v6 capable, there is no longer a justification for deploying v4 in new operations. The problem changes from having to justify v6 to having to justify v4. Once THAT takes place, there is no need to issue more v4 space as the total v4 traffic across the internet will quickly drop and people who are not v6 capable at that point will be scrambling to catch up.
Sent: Thursday, October 21, 2010 3:08 PM To: George Bonser Cc: Ben Butler; NANOG Subject: Re: Only 5x IPv4 /8 remaining at IANA
On Thu, Oct 21, 2010 at 12:53 PM, George Bonser <gbonser@seven.com> wrote:
The first step will be a registrar saying "after this date, we will no longer issue any IPv4 addresses for whatever reason" and at the same time, getting very aggressive in reclaiming space from dead entities, hijackers, etc. As time goes by, the amount of v4 space being routed declines through natural attrition. It is a combination of liberal v6 assignment coupled with aggressive v4 reclamation.
Why on earth would a registrar aggressively reclaim space from entities if they're no longer issuing it back out?
To reduce the pool of available IPs, to reduce the reselling, transfer, hijacking of the space. As the amount of available v4 space declines, it becomes harder to obtain those resources for an operator either refusing to move or not wanting to move. It increases the incentive to move to v6 by making it increasingly difficult to operate in v4. I wouldn't recommend stopping the issuing of v4 space NOW, but maybe 5 years after runout.
Are we planning on recommending policies into the ARIN AC that turn ARIN into an IPv4 space reclamation entity, to hoard up v4 addresses?
Ok, lets say runout occurs in 2011. Set a date, say 2016 after which ARIN will allocate IPv6 only. The idea isn't to hoard v4 addresses, the idea is to stop the allocation of new blocks.
As it now stands, the amount of v4 space being routed will trend towards the asymptote of maximal organizational utilization, and will *not* decline. Any organization that moves resources off v4 and frees up address space will either hold that space as an ongoing resource to be used for future expansions, or will sell it off on the transfer market for short-term cash infusions; the new holders, having paid good cash for it, will have a strong incentive to get it routed and carrying traffic as quickly as possible, to pay back their investment.
For a while that is true. But what will the traffic look like 5 years from now? If most of the major user networks are migrated to v6 by that time and most of the major content providers are v6, and the amount of native v4 traffic declines, who is going to want v4 space for anything new? Servicing legacy stuff makes sense but in 2016 who is going to roll out new deployments in v4 space? And ARIN wouldn't be preventing them from doing that, they just wouldn't be able to get the addresses from ARIN. In other words, it would be a PITA to do that and much easier to roll out a new deployment with v6. By continuing to allocate v4 space, they would be enabling the running of v4 forever.
There is *nothing* in the system driving towards a natural attrition of IPv4 usage, even after runout; we simply change the allocation model from purely needs based, to needs+cash based.
Unless ISPs state that they will charge additional money to assign v4 addresses to customers, over what they charge to v6 customers, there is no real pressure in the marketplace for the amount of v4 routing to decline. So long as the end user sees the same cost, and same service for using v4 as v6, there is no pressure towards a v6-only world.
Maybe. But look at it this way. Imagine 5 years from now a provider notices that only 1% of their traffic in a particular data center is v4. Rather than having to maintain dual-stack configurations on all the gear, they decide to allocate a pair of routers to v4 and go pure native v6 on all their customer facing stuff. Now maybe if the few people still using v4 want it, they can have it by tunneling 4 over 6 to that pair of routers. Now the vast majority of stuff in that provider's network is v6 only with only a couple of internal routers running v4 carrying the tunnels to their users who still use that space. Maybe 5 years after THAT in 2021 the amount of v4 traffic no longer justifies running v4 at all. Customers can still run v4 if they wish by tunneling to a v4 provider someplace else. Maybe even give the customers 5 MORE years to return their PA blocks, so now we are at 15 years from runout, the provider has reclaimed all their v4 space from their customers and returns it (maybe they have returned portions of that space before then) to ARIN and the provider no longer offers v4 services. So I wasn't talking about doing such a thing immediately, I had more of a phased approach in mind. 5 years from runout, ARIN stops issuing IPs. Within 10 years of runout, providers begin to shrink their v4 support, possibly tunneling the traffic to a single pair of routers in their network, 15 years after runout, most providers can't be bothered with v4 support but if you absolutely have to have it, someone can get it to you over a tunnel from someplace. 20 years from runout most providers have reclaimed all their PA space and have returned it to ARIN.
So...uh...who's going to be first to step up and tell their customers "look, you get a v6 /56 for free with your account, but if you want v4 addresses, it's going to cost an extra $50/month." ??
I wasn't talking about PA space allocated to a provider who in turn allocates that to customers. Providers could still issue/reclaim their own space as they wish. At some point, though, the tiny amount of traffic in that space begins to make it hard to justify having full v4 BGP tables at so many places. When the traffic dies to the point where all the provider's v4 traffic can be handled on a single pair of routers, it probably will be which will free up resources on the rest of the routers running native v6.
I think what you will see is ever increasing fees for IPv4 transit rather than a hard deprecation date. As IPv4 becomes more expensive than IPv6, people will migrate to save money. Owen On Oct 21, 2010, at 9:34 AM, Ben Butler wrote:
Hi,
I can live with running dual stack for a number of years as long as IPv4 has a turn off date, much like analogue TV services, thus putting onus of responsibility onto the customer to also have a vested interest in migrating from v4 to v6. If there is no end data - then all the service providers are going to get stuck running dual stack and providing 4to6 and 6to4 gateways to bridge traffic to the pool of established v4 only customers. Presumably the evil that is NAT will have to be run on these gateways meaning we have to endure yet more decades of many applications being undeployable for practical purposes as stun cant fix everything in the mish mash of different NAT implementations.
The problem is there is no commercial incentive for the v4 customer to want to move to v6 and there is no way for the ISP to force them to without loosing the customer. However, if the RIRs or IANA turned around and said as of xxxx date we are revoking all ipv4 allocations. Then we might be able to transition to a v6 only network in some decent timeframe without ending up going down the road of a broken dual level 4/6 half way in between broken internet for the next 25 years.
You either cross the bridge and get to the other side, or you tell all the people waiting to cross they are too late and tough luck but we have run out and you cant join the party, but the last thing we want to do is get half way across the bridge and need to straddle both sides of the river.
My 2c.
Ben
-----Original Message----- From: Dan White [mailto:dwhite@olp.net] Sent: 21 October 2010 16:30 To: Ben Butler Cc: 'Patrick Giagnocavo'; Owen DeLong; NANOG Subject: Re: Only 5x IPv4 /8 remaining at IANA
On 21/10/10 16:07 +0100, Ben Butler wrote:
Hi,
Showing my ignorance here, but this is one of the things I have wondered, given that we run both v4 and v6 for a period of time on the Internet, presumably at one time or another a particular resource may only be able in v4 land, then v4 and v6, then finally v6 only.
I have never been particularly clear how an end network that exists only in v4 or v6 address space is able to access a resource that only exists in the other. Is can sort of see some freaking huge NAT box type thing that summarizes v6 in a v4 address scope or contains the v4 address range at some point inside the v6 address space - but how can a v4 host get to a hot in v6 world that sits outside this without going through some form of proxy / nat gateway between the two.
Or are the two simply not inter-communicable?
I think that's the $64K question. Do you wait to roll out v6 until you start seeing v6-only hosts start popping up? From an accounting and cost recovery stand point, that probably makes sense in some environments.
However, consider the fact that there will be v6 only hosts popping up after IANA/RIR/ISP exhaustion. There will be new entrants in the public internet space that cannot obtain v4 addresses and will be reachable via v6 only. That date is starting to become a bit more predictable too. Those v6 only sites won't be Google or Yahoo, but they will be entrepreneurs with good ideas and new services that your customers will be asking to get access to.
We're pursuing a dual stacking model today because we anticipate that the dual-stacking process itself will take a while to deploy, and we want to anticipate customer demand for access to v6 only sites. We could hold off on that deployment, and then spend money on work at the moment of truth, but that approach is not very appealing to us.
-- Dan White
-------------------------------------------------------------------------- BODY { MARGIN: 0px}.footerdark { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #001a35; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.blackcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.bluecopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #29aae2; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.address { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; TEXT-DECORATION: none}.footerlight { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #667891; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.pinkcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #ed174d; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none} Ben Butler Director Tel: 0333 666 3332 Fax: 0333 666 3331 C2 Business Networking Ltd The Paddock, London Road, Nantwich, Cheshire, CW5 7JL http://www.c2internet.net/
Part of the Atlas Business Group of Companies plc Registered in England: 07102986 Registered Address: Datum House, Electra Way, Crewe CW1 6ZF Vat Registration No: 712 9503 48 This message is confidential and intended for the use only of the person to whom it is addressed. If you are not the intended recipient you are strictly prohibited from reading, disseminating, copying, printing, re-transmitting or using this message or its contents in any way. Opinions, conclusions and other information expressed in this message are not given or authorised by the Company unless otherwise indicated by an authorised representative independent of this message. The Company does not accept liability for any data corruption, interception or amendment to any e-mail or the consequences thereof.Emails addressed to individuals may not necessarily be read by that person unless they are in the office.Calls to and from any of the Atlas Business Group of Companies may be recorded for the purposes of training, monitoring of quality and customer services.
Dan White wrote:
Or are the two simply not inter-communicable?
I think that's the $64K question. Do you wait to roll out v6 until you start seeing v6-only hosts start popping up?
When do you think that will happen and in what percentages of your target populations to matter?
From an accounting and cost recovery stand point, that probably makes sense in some environments.
However, consider the fact that there will be v6 only hosts popping up after IANA/RIR/ISP exhaustion.
There is a phase you are missing between depletion and v6 only hosts. That would be continual and increasing difficulties of obtaining new v4 access and degradation of the quality of that service, hopefully along with a direct inverse effect on the quality and resultant value of v6 service. The time line and gradations of that phase are far less clear than depletion. That would explain why so many do not concern themselves with it at this time. Especially those who do not consider themselves to be the party initially responsible for resolving those issues. http://www.dilbert.com/fast/2006-07-30/ Joe
On 21/10/10 14:53 -0400, Joe Maimon wrote:
Dan White wrote:
Or are the two simply not inter-communicable?
I think that's the $64K question. Do you wait to roll out v6 until you start seeing v6-only hosts start popping up?
When do you think that will happen and in what percentages of your target populations to matter?
I could guess, but I'd probably be wrong. I'd like to be wrong in the right direction :)
From an accounting and cost recovery stand point, that probably makes sense in some environments.
However, consider the fact that there will be v6 only hosts popping up after IANA/RIR/ISP exhaustion.
There is a phase you are missing between depletion and v6 only hosts.
That would be continual and increasing difficulties of obtaining new v4 access and degradation of the quality of that service, hopefully along with a direct inverse effect on the quality and resultant value of v6 service.
You're thinking in the big picture. I'm thinking of the specific scenario where my customers start calling me up because they can't get to *one* really important site that couldn't get v4 addresses. I view that as the drop dead date for implementing dual-stack for us.
The time line and gradations of that phase are far less clear than depletion.
That would explain why so many do not concern themselves with it at this time. Especially those who do not consider themselves to be the party initially responsible for resolving those issues.
I understand the idea that there's going to be a sliding curve of adoption for those with the resources to purchase v4 transfer. I just don't buy into the idea that that's going to push back v6 adoption very much. That's going to be a game for the rich and the richer. In a way, it's kind of like the credit crunch of a year or two ago. The large banks and federal reserve colluded to make sure that credit kept flowing for small businesses and entrepreneurs, even though the current conditions of the market couldn't support it, because restricted access to credit by startups with good ideas would have been a rock to the head of the economy. I think the press are going to rip into the 'dinosaurs' and 'monopolies' who don't move quickly enough to support the nimble expansion of new services based around v6. -- Dan White
On Oct 21, 2010, at 11:53 AM, Joe Maimon wrote:
Dan White wrote:
Or are the two simply not inter-communicable?
I think that's the $64K question. Do you wait to roll out v6 until you start seeing v6-only hosts start popping up?
When do you think that will happen and in what percentages of your target populations to matter?
Shortly after runout and that depends on the nature of the growth in your userbase.
From an accounting and cost recovery stand point, that probably makes sense in some environments.
However, consider the fact that there will be v6 only hosts popping up after IANA/RIR/ISP exhaustion.
There is a phase you are missing between depletion and v6 only hosts.
Not really.
That would be continual and increasing difficulties of obtaining new v4 access and degradation of the quality of that service, hopefully along with a direct inverse effect on the quality and resultant value of v6 service.
That phase will be short-lived and steep.
The time line and gradations of that phase are far less clear than depletion.
Less clear, yes. Far less? I'm not so sure about that.
That would explain why so many do not concern themselves with it at this time. Especially those who do not consider themselves to be the party initially responsible for resolving those issues.
I think a more accurate explanation would be a behavior common to Ostriches when experiencing fear. Tony Hain has a pretty good slide on the stages of IPv6 grief. It seems many engineers and organizations are somehow still in denial and few have moved to rationalization or acceptance.
Cute, but, remember, Mr. Adams used to be a Pacific Bell employee. Not exactly the shining example of a forward thinking or innovative company. So much not so that they ended up being acquired by SBC which later bought and renamed itself AT&T. Owen
From: Dan White Sent: Thursday, October 21, 2010 8:30 AM To: Ben Butler Cc: NANOG Subject: Re: Only 5x IPv4 /8 remaining at IANA
I think that's the $64K question. Do you wait to roll out v6 until you start seeing v6-only hosts start popping up? From an accounting and cost recovery stand point, that probably makes sense in some environments.
However, consider the fact that there will be v6 only hosts popping up after IANA/RIR/ISP exhaustion. There will be new entrants in the
And so everyone is waiting for everyone else to see IPv6 traffic. Which is sort of where we are now. Everyone is standing around the pool waiting for everyone else to jump in. The usual "early adopters" are in there but people are still waiting for "Mikey" to see if he likes it. public
internet space that cannot obtain v4 addresses and will be reachable via v6 only ...
Yep, you can't do NAT64 if you don't have "4". But that said, just because ARIN is exhausted doesn't mean PA space is exhausted so there will be addresses available though it will be tight.
On 10/21/2010 09:25 PM, George Bonser wrote:
However, consider the fact that there will be v6 only hosts popping up after IANA/RIR/ISP exhaustion. There will be new entrants in the public internet space that cannot obtain v4 addresses and will be reachable via v6 only ... Yep, you can't do NAT64 if you don't have "4". But that said, just because ARIN is exhausted doesn't mean PA space is exhausted so there will be addresses available though it will be tight.
That is exactly what the last 5 /8's are for as I understand it. The last 5 /8's will be allocated to each RIR immediately and I think by now every RIR has a policy for that last /8 which pretty much says: only for transitional purposes
On Oct 21, 2010, at 12:33 PM, Leen Besselink wrote:
On 10/21/2010 09:25 PM, George Bonser wrote:
However, consider the fact that there will be v6 only hosts popping up after IANA/RIR/ISP exhaustion. There will be new entrants in the public internet space that cannot obtain v4 addresses and will be reachable via v6 only ... Yep, you can't do NAT64 if you don't have "4". But that said, just because ARIN is exhausted doesn't mean PA space is exhausted so there will be addresses available though it will be tight.
That is exactly what the last 5 /8's are for as I understand it.
Not necessarily. It's up to each RIR's policy. ARIN has no such policy. The other regions generally do not have such a policy.
The last 5 /8's will be allocated to each RIR immediately and I think by now every RIR has a policy for that last /8 which pretty much says: only for transitional purposes
Nope... No registry has such a policy that I know of. Owen
On 21 Oct 2010 10:07, Ben Butler wrote:
Showing my ignorance here, but this is one of the things I have wondered, given that we run both v4 and v6 for a period of time on the Internet, presumably at one time or another a particular resource may only be able in v4 land, then v4 and v6, then finally v6 only.
That's what NAT-PT is for. Oh wait, the IETF deprecated it... S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
On Thu, Oct 21, 2010 at 8:07 AM, Ben Butler <ben.butler@c2internet.net> wrote:
Hi,
Showing my ignorance here, but this is one of the things I have wondered, given that we run both v4 and v6 for a period of time on the Internet, presumably at one time or another a particular resource may only be able in v4 land, then v4 and v6, then finally v6 only.
I have never been particularly clear how an end network that exists only in v4 or v6 address space is able to access a resource that only exists in the other. Is can sort of see some freaking huge NAT box type thing that summarizes v6 in a v4 address scope or contains the v4 address range at some point inside the v6 address space - but how can a v4 host get to a hot in v6 world that sits outside this without going through some form of proxy / nat gateway between the two.
Or are the two simply not inter-communicable?
Ben
-----Original Message----- From: Patrick Giagnocavo [mailto:patrick@zill.net] Sent: 21 October 2010 15:59 To: Owen DeLong; NANOG Subject: Re: Only 5x IPv4 /8 remaining at IANA
On 10/21/2010 4:28 AM, Owen DeLong wrote:
Actually for those of my clients in one location, it served as an impetus to extend a contract with Level3 for another 3 years - with their existing allocation of a /24 of IPv4 addresses included.
All well and good until some of their customers are on IPv6... Then what?
I'm sorry, can you expand on exactly what you mean by this?
Are IPv6 connected machines unable to access IPv4 addresses?
IPv6->IPv4 is called NAT64, and it works today pretty well. Most things work very well (web, email, ...), somethings don't (skype ..) http://www.youtube.com/watch?v=AmjlptEva4Y#t=1h32m26s http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-12 http://ecdysis.viagenie.ca/ As your major NAT vendor, they probably have NAT64 in the road map for the next 6 to 12 months. IPv4->IPv6 initiated connection are a lost cause that cannot scale in any good way. Cameron
As long as there are IPv4 clients, you need IPv4 servers to serve them. Software written (well) for IPv6 can serve both IPv4 and IPv6 from the same socket, so long as you set the socket option IPV6_V6ONLY correctly (default except for errant BSD code), but, the machine needs to have a working IPv4 address to do this. In its natural state, IPv4 and IPv6 cannot talk to each other. They are separate protocols just as IP and IPX and Appletalk are separate. (ignoring the IPX/Appletalk over IP things for the time being). There are some ways to build some translation facilities, but, it's not trivial and there are no translation facilities that work even in all the same cases that NAT44 currently works. If you want to talk to both IPv4 and IPv6, you'll need dual stack. Thus, we should dual-stack as much of the existing infrastructure before IPv4 runout as possible and dual stack the rest as quickly as possible thereafter. After runout, all new stuff will be effectively IPv6 only, or, IPv6 with very degraded IPv4 capabilities. If you're stuff needs reachability with those new IPv6 only members of the internet (both clients and servers, although clients will dominate the numbers initially), then, you really need dual stack. Owen On Oct 21, 2010, at 8:07 AM, Ben Butler wrote:
Hi,
Showing my ignorance here, but this is one of the things I have wondered, given that we run both v4 and v6 for a period of time on the Internet, presumably at one time or another a particular resource may only be able in v4 land, then v4 and v6, then finally v6 only.
I have never been particularly clear how an end network that exists only in v4 or v6 address space is able to access a resource that only exists in the other. Is can sort of see some freaking huge NAT box type thing that summarizes v6 in a v4 address scope or contains the v4 address range at some point inside the v6 address space - but how can a v4 host get to a hot in v6 world that sits outside this without going through some form of proxy / nat gateway between the two.
Or are the two simply not inter-communicable?
Ben
-----Original Message----- From: Patrick Giagnocavo [mailto:patrick@zill.net] Sent: 21 October 2010 15:59 To: Owen DeLong; NANOG Subject: Re: Only 5x IPv4 /8 remaining at IANA
On 10/21/2010 4:28 AM, Owen DeLong wrote:
Actually for those of my clients in one location, it served as an impetus to extend a contract with Level3 for another 3 years - with their existing allocation of a /24 of IPv4 addresses included.
All well and good until some of their customers are on IPv6... Then what?
I'm sorry, can you expand on exactly what you mean by this?
Are IPv6 connected machines unable to access IPv4 addresses?
Or is this more IPV6 fanboi-ism?
--Patrick
-------------------------------------------------------------------------- BODY { MARGIN: 0px}.footerdark { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #001a35; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.blackcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.bluecopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #29aae2; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.address { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; TEXT-DECORATION: none}.footerlight { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #667891; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.pinkcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #ed174d; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none} Ben Butler Director Tel: 0333 666 3332 Fax: 0333 666 3331 C2 Business Networking Ltd The Paddock, London Road, Nantwich, Cheshire, CW5 7JL http://www.c2internet.net/
Part of the Atlas Business Group of Companies plc Registered in England: 07102986 Registered Address: Datum House, Electra Way, Crewe CW1 6ZF Vat Registration No: 712 9503 48 This message is confidential and intended for the use only of the person to whom it is addressed. If you are not the intended recipient you are strictly prohibited from reading, disseminating, copying, printing, re-transmitting or using this message or its contents in any way. Opinions, conclusions and other information expressed in this message are not given or authorised by the Company unless otherwise indicated by an authorised representative independent of this message. The Company does not accept liability for any data corruption, interception or amendment to any e-mail or the consequences thereof.Emails addressed to individuals may not necessarily be read by that person unless they are in the office.Calls to and from any of the Atlas Business Group of Companies may be recorded for the purposes of training, monitoring of quality and customer services.
On 2010-10-21 16:59, Patrick Giagnocavo wrote:
On 10/21/2010 4:28 AM, Owen DeLong wrote:
Actually for those of my clients in one location, it served as an impetus to extend a contract with Level3 for another 3 years - with their existing allocation of a /24 of IPv4 addresses included.
All well and good until some of their customers are on IPv6... Then what?
I'm sorry, can you expand on exactly what you mean by this?
Are IPv6 connected machines unable to access IPv4 addresses?
Unless you put a application/protocol translation in the middle IPv6 can't talk to IPv4. yahoo("IVI","Ecdysis NAT64") for two possibilities one have for that, oh and yahoo("IPv6Gate") for a ready-to-use HTTP specific one. But if you didn't know that fact, you might want to invest in a proper book about IPv6 and read up quite a bit. As this is NANOG, a good operational book is "Running IPv6". Greets, Jeroen
On 10/21/2010 11:08 AM, Jeroen Massar wrote:
On 2010-10-21 16:59, Patrick Giagnocavo wrote: Are IPv6 connected machines unable to access IPv4 addresses?
Unless you put a application/protocol translation in the middle IPv6 can't talk to IPv4. yahoo("IVI","Ecdysis NAT64") for two possibilities one have for that, oh and yahoo("IPv6Gate") for a ready-to-use HTTP specific one.
But if you didn't know that fact, you might want to invest in a proper book about IPv6 and read up quite a bit. As this is NANOG, a good operational book is "Running IPv6".
Thank you for the book recommendation; however, I was trying to get an admission that any IPv6-connected end users or corporate connections, will be accessing IPv4-only resources for a long time to come, i.e. years and years. And that the responsibility for IPv6 to v4 connection won't have to be handled by my client with a few racks. Cordially Patrick
On Thu, Oct 21, 2010 at 8:26 AM, Patrick Giagnocavo <patrick@zill.net> wrote:
On 10/21/2010 11:08 AM, Jeroen Massar wrote:
On 2010-10-21 16:59, Patrick Giagnocavo wrote: Are IPv6 connected machines unable to access IPv4 addresses?
Unless you put a application/protocol translation in the middle IPv6 can't talk to IPv4. yahoo("IVI","Ecdysis NAT64") for two possibilities one have for that, oh and yahoo("IPv6Gate") for a ready-to-use HTTP specific one.
But if you didn't know that fact, you might want to invest in a proper book about IPv6 and read up quite a bit. As this is NANOG, a good operational book is "Running IPv6".
Thank you for the book recommendation; however, I was trying to get an admission that any IPv6-connected end users or corporate connections, will be accessing IPv4-only resources for a long time to come, i.e. years and years.
And that the responsibility for IPv6 to v4 connection won't have to be handled by my client with a few racks.
That depends if your clients application and content works well via NAT64. If you are just serving web pages and you always use FQDNS, great. You are pretty set for a long time. If not, you use IPv4 literals, you may end up on this list, http://groups.google.com/group/ipv4literals and you will have to either modify your application to work via NAT64 or enable IPv6 natively on your side or... have some portion of the internet not reach your services. The better long term strategy is to go ipv6 and take the risk out of all this hedging against the inevitable of LSN / CGN / AFTR. That is what Google, Facebook, and many others are already doing. If a major service provider rolls out IPv6-only devices and services (and they are / will, because IPv4 is out) they will not make a special case for you. So, what you really need to do is figure out if your applications and content work via NAT64 and come up with a good plan for going IPv6 in the long run. It's all about your risk tolerance Cameron ========= http://groups.google.com/group/tmoipv6beta =========
On Oct 21, 2010, at 8:26 AM, Patrick Giagnocavo wrote:
On 10/21/2010 11:08 AM, Jeroen Massar wrote:
On 2010-10-21 16:59, Patrick Giagnocavo wrote: Are IPv6 connected machines unable to access IPv4 addresses?
Unless you put a application/protocol translation in the middle IPv6 can't talk to IPv4. yahoo("IVI","Ecdysis NAT64") for two possibilities one have for that, oh and yahoo("IPv6Gate") for a ready-to-use HTTP specific one.
But if you didn't know that fact, you might want to invest in a proper book about IPv6 and read up quite a bit. As this is NANOG, a good operational book is "Running IPv6".
Thank you for the book recommendation; however, I was trying to get an admission that any IPv6-connected end users or corporate connections, will be accessing IPv4-only resources for a long time to come, i.e. years and years.
And that the responsibility for IPv6 to v4 connection won't have to be handled by my client with a few racks.
Noone can confirm that for you because it is largely untrue. IPv6-connected end users MAY have some ability to reach your IPv4-only site. This will be through something that looks like a LSN device at best so you won't have working things like: Geolocation UPNP reverse connection mapping Most forms of NAT-T Most forms of P2P Logs that represent unique IP addresses visiting your site in a meaningful manner. etc. Owen
participants (56)
-
Adrian Chadd -
Andrew Kirch -
Barry Shein -
Ben Butler -
bmanning＠vacation.karoshi.com -
Bryan Irvine -
Cameron Byrne -
Christopher Morrow -
Claudio Jeker -
Curtis Maurand -
Dan White -
Dave CROCKER -
David Freedman -
Deepak Jain -
Franck Martin -
George Bonser -
gordon b slater -
Henning Brauer -
Jack Bates -
Jared Mauch -
Jeffrey Lyon -
Jens Link -
Jeroen Massar -
Jeroen van Aart -
Joe Loiacono -
Joe Maimon -
Joel Jaeggli -
John van Oppen -
Jonas Frey (Probe Networks) -
Jorge Amodio -
Julien Goodwin -
Justin M. Streiner -
Kevin Stange -
Leen Besselink -
Majdi S. Abbas -
Mark Andrews -
Mark Smith -
Marshall Eubanks -
Matthew Petach -
Matthew Walster -
Michael Dillon -
ML -
Nathan Eisenberg -
Niels Bakker -
Owen DeLong -
Patrick Giagnocavo -
Patrick W. Gilmore -
Paul Thornton -
Ray Soucy -
Seth Mattinen -
Stephen D. Strowes -
Stephen Sprunk -
Tim Burke -
Tony Hain -
Valdis.Kletnieks＠vt.edu -
Zaid Ali