Who out there is using production-scale NAT64? What solution are you using? Thanks, Jawaid
On Thu, Aug 20, 2015 at 9:44 AM, Jawaid Shell2 <jb@forethought.net> wrote:
Who out there is using production-scale NAT64? What solution are you using?
You used "NAT64" and "production" in the same sentence. Good one. Seriously though, if you want to run a v6-only network and still support access to IPv4 Internet resources, consider 464XLAT or DS-Lite. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
On Thu, Aug 20, 2015 at 9:36 AM, William Herrin <bill@herrin.us> wrote:
On Thu, Aug 20, 2015 at 9:44 AM, Jawaid Shell2 <jb@forethought.net> wrote:
Who out there is using production-scale NAT64? What solution are you using?
You used "NAT64" and "production" in the same sentence. Good one.
Seriously though, if you want to run a v6-only network and still support access to IPv4 Internet resources, consider 464XLAT or DS-Lite.
NAT64 is a required component of 464XLAT. And, it runs at very meaningful production scale in non-trivial network deployments. CB
Regards, Bill Herrin
-- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
On Thu, Aug 20, 2015 at 1:22 PM, Ca By <cb.list6@gmail.com> wrote:
On Thu, Aug 20, 2015 at 9:36 AM, William Herrin <bill@herrin.us> wrote:
Seriously though, if you want to run a v6-only network and still support access to IPv4 Internet resources, consider 464XLAT or DS-Lite.
NAT64 is a required component of 464XLAT.
Sort of, technically, but not really. NAT64 on its own implies DNS64 and IPv6 client software. Funky gyrations in the DNS64 server cause the IPv6 software on the client to originate with IPv6 addresses that the NAT64 server knows how to convert to IPv4 addresses. 464XLAT does not require DNS64 and provides client software with an IPv4 interface. IPv4 software that has no idea IPv6 exists sends IPv4 packets which get translated to IPv6 packets. Those packets are routed to the carrier NAT box which then translates these specially crafted IPv6 packets back to IPv4 packets. Functionally, 464XLAT is an IPv6 VPN between your IPv4 client software and an IPv4 carrier NAT box. Don't let the fact that it's double-translating instead of encapsulating and decapsulating fool you -- it's a VPN. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
* William Herrin
On Thu, Aug 20, 2015 at 1:22 PM, Ca By <cb.list6@gmail.com> wrote:
On Thu, Aug 20, 2015 at 9:36 AM, William Herrin <bill@herrin.us> wrote:
Seriously though, if you want to run a v6-only network and still support access to IPv4 Internet resources, consider 464XLAT or DS-Lite.
NAT64 is a required component of 464XLAT.
Sort of, technically, but not really.
Yes really. See below.
464XLAT does not require DNS64 and provides client software with an IPv4 interface. IPv4 software that has no idea IPv6 exists sends IPv4 packets which get translated to IPv6 packets. Those packets are routed to the carrier NAT box which then translates these specially crafted IPv6 packets back to IPv4 packets.
What do you think the «carrier NAT box» in 464XLAT is, exactly? No need to guess, we can check the 464XLAT specification: http://tools.ietf.org/html/rfc6877#section-2
PLAT: PLAT is provider-side translator (XLAT) that complies with [RFC6146]. It translates N:1 global IPv6 addresses to global IPv4 addresses, and vice versa.
Let's check that reference: http://tools.ietf.org/html/rfc6146#section-1
This document specifies stateful NAT64, a mechanism for IPv4-IPv6 transition and IPv4-IPv6 coexistence.
Lo and behold! Your 464XLAT «carrier NAT box» (a.k.a. «PLAT») *is* a NAT64 box. Thus, if you intend to deploy 464XLAT in production, you'll going to need a production scale NAT64 implementation. To answer the Jawaid's original question, I'm very happy with Jool (http://jool.mx) for my NAT64 (and SIIT) needs, which is a open-source Linux-based software solution. It has no problems handling several Gb/s of traffic using a couple of years old x86 server without any tuning, so if the capacity required is moderate this might be a cost-effective alternative to a dedicated boxes from the one of the router/network appliance vendors. Tore
On 20/Aug/15 15:44, Jawaid Shell2 wrote:
Who out there is using production-scale NAT64? What solution are you using?
NAT64/DNS64 on Cisco ASR1006's distributed across the network. Boxes deployed, traffic minimal as we still have IPv4 addresses as well (AFRINIC region). Mark.
On 26 August 2015 at 00:55, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 20/Aug/15 15:44, Jawaid Shell2 wrote:
Who out there is using production-scale NAT64? What solution are you using?
NAT64/DNS64 on Cisco ASR1006's distributed across the network.
We're doing NAT64/DNS64 with Cisco ASR1002s, although it's for a IPv6-only server network, not for user eyeballs. The biggest downside has been the lack of SNMP (or similar) support for monitoring the NAT64 traffic and pool usage, at least on the IOS XE versions we're running. -Tom
On Thu, Aug 20, 2015 at 07:44:10AM -0600, Jawaid Shell2 wrote:
Who out there is using production-scale NAT64? What solution are you using?
Yes, I'm curious about this too. I'd like a solid list of providers to avoid. -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__
On 26/Aug/15 16:13, Izaac wrote:
Yes, I'm curious about this too. I'd like a solid list of providers to avoid.
NAT64 is opt-in. It will mostly be used for customers that can no longer obtain IPv4 addresses. Service providers do not like NAT64 anymore than you do, but there needs to be some way to bridge both protocols in the interim. What you should be more interested in is which service providers have deployed it at scale where it is not causing problems, as those are the ones you want to be connected to when the IPv4-hell hiteth the faneth! Mark.
On Wed, Aug 26, 2015 at 7:19 AM, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 26/Aug/15 16:13, Izaac wrote:
Yes, I'm curious about this too. I'd like a solid list of providers to avoid.
NAT64 is opt-in.
It will mostly be used for customers that can no longer obtain IPv4 addresses.
Service providers do not like NAT64 anymore than you do, but there needs to be some way to bridge both protocols in the interim.
What you should be more interested in is which service providers have deployed it at scale where it is not causing problems, as those are the ones you want to be connected to when the IPv4-hell hiteth the faneth!
Mark.
From largish deployment ...
Another relevant metric, less than 25% of my mobile subscribers traffic require NAT64 translating. 75+% of bits flows through end-to-end IPv6 (thanks Google/Youtube, Facebook, Netflix, Yahoo, Linkedin and so on ...).
On Aug 26, 2015, at 10:28 AM, Ca By <cb.list6@gmail.com> wrote:
From largish deployment ...
Another relevant metric, less than 25% of my mobile subscribers traffic require NAT64 translating. 75+% of bits flows through end-to-end IPv6 (thanks Google/Youtube, Facebook, Netflix, Yahoo, Linkedin and so on ...).
This for me is an important note, because if your site only gives out an A address, it’s going to be slowed by the NAT process. I have noticed the IPv4 penalty getting worse with many locations. - Jared
On 26/Aug/15 16:32, Jared Mauch wrote:
This for me is an important note, because if your site only gives out an A address, it’s going to be slowed by the NAT process. I have noticed the IPv4 penalty getting worse with many locations.
But you only need to hit the NAT64 gateway "if" you are IPv6-only. If you're dual-stacked, your route to an A record will not hit the NAT64 gateway. Mark.
On Wed, Aug 26, 2015 at 04:39:11PM +0200, Mark Tinka wrote:
On 26/Aug/15 16:32, Jared Mauch wrote:
This for me is an important note, because if your site only gives out an A address, it’s going to be slowed by the NAT process. I have noticed the IPv4 penalty getting worse with many locations.
But you only need to hit the NAT64 gateway "if" you are IPv6-only.
Sure... For DS, I could send IPv6 native and IPv4 via NAT. I suspect this actually the most common home setup at this point. It's certainly the way mine looks. I have noticed that IPv4 "feels" slow on my t-mobile usa connected devices. This is only a problem when interacting with legacy players on the network, eg: financials, opensrs, airlines. I suspect this is a 64 CGN tax. Waiting to see my other devices/sims see IPv6 on them via VZ and AT&T.
If you're dual-stacked, your route to an A record will not hit the NAT64 gateway.
Sure, but your v4 is likely to have issues regardless and face this penalty/tax. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
On 27/Aug/15 03:21, Jared Mauch wrote:
Sure...
For DS, I could send IPv6 native and IPv4 via NAT. I suspect this actually the most common home setup at this point. It's certainly the way mine looks.
I have noticed that IPv4 "feels" slow on my t-mobile usa connected devices. This is only a problem when interacting with legacy players on the network, eg: financials, opensrs, airlines. I suspect this is a 64 CGN tax.
Waiting to see my other devices/sims see IPv6 on them via VZ and AT&T.
If your IPv4 is public, you should not "feel slow". Of course, if your IPv4 is private, then yes, some NAT44 may happen somewhere along the path.
Sure, but your v4 is likely to have issues regardless and face this penalty/tax.
But that would be a function of NAT44 if you're on private IPv4, and have nothing to do with the NAT64. In our deployment, we do not offer customers private IPv4 addresses. I suppose we can afford to do this because a) we still have lots of public IPv4, b) we are not a mobile carrier. So any of our customers with IPv4 will never hit the NAT64 gateway. When we do run out of public IPv4 addresses (and cannot get anymore from AFRINIC), all new customers will be assigned IPv6 addresses. These will hit a NAT64 gateway if they want to talk to legacy resources on the Internet. Mark.
Hi Mark, * Mark Tinka <mark.tinka@seacom.mu>
In our deployment, we do not offer customers private IPv4 addresses. I suppose we can afford to do this because a) we still have lots of public IPv4, b) we are not a mobile carrier. So any of our customers with IPv4 will never hit the NAT64 gateway.
When we do run out of public IPv4 addresses (and cannot get anymore from AFRINIC), all new customers will be assigned IPv6 addresses.
Why wait until then? Any particular reason why you cannot already today provide IPv6 addresses to your [new] customers in parallel with IPv4? Tore
On 27/Aug/15 06:53, Tore Anderson wrote:
Why wait until then?
I didn't say that we're waiting :-)...
Any particular reason why you cannot already today provide IPv6 addresses to your [new] customers in parallel with IPv4?
As a standard delivery of service, all our customers (BGP- and non-BGP-based) are assigned IPv6 addresses by default. Point-to-point for the BGP-based customers, and point-to-point + onward LAN assignments for the non-BGP-based customers. We do (and configure) this regardless of whether customers have asked for it or not. In reality, 70% of the time it's like pulling teeth getting customers to configure their end of the IPv6 point-to-point address, much less turn-up an IPv6 BGP session. Reasons range from, "We do not have a /32 IPv6 allocation yet", "Our router does not support IPv6 yet", "We shall get to it in time, we are busy with other things now", "It is not important to us", "We only have one interface in our whole network with IPv6, so let's forget about it for now", "What is IPv6? Oh, that - no thanks", and so on and so on. 30% of the time, however, we are dealing with a switched-on customer that is happy to turn it up, and would even chase us for the same. We like these types of customers. You won't find a customer order or port in our network that does not have IPv6 enabled. It's just all about getting their side sorted out. And the team have been going out of their way to help them turn-up, e.g., recommending the minimum software they should upgrade to to support IPv6, helping them reach out to AFRINIC to apply for their /32 IPv6 allocation, helping them set things up on their end, nagging them weekly on when they will get their side up, e.t.c. It's never-ending work. Same things goes for peering - we always ask peers to turn-up both IPv4 and IPv6 at the same time. For the majority of peers, once the IPv4 session is up, they disappear. But we keep nagging, and nagging and nagging, and many times we are successful in getting IPv6 going. Sometimes, however, it's all falling on deaf ears. But it is good work, so we do not let up. All I was saying before is that when we can no longer hand out public IPv4 addresses to new customers in the future, those customers will require the NAT64 gateway to speak to IPv4-only resources. Hopefully, by the time that happens, the demand on the NAT64 gateways is as close to 0% as possible. Mark.
In message <20150827065346.58554fa7@echo.ms.redpill-linpro.com>, Tore Anderson writes:
Hi Mark,
* Mark Tinka <mark.tinka@seacom.mu>
In our deployment, we do not offer customers private IPv4 addresses. I suppose we can afford to do this because a) we still have lots of public IPv4, b) we are not a mobile carrier. So any of our customers with IPv4 will never hit the NAT64 gateway.
When we do run out of public IPv4 addresses (and cannot get anymore from AFRINIC), all new customers will be assigned IPv6 addresses.
Why wait until then?
Any particular reason why you cannot already today provide IPv6 addresses to your [new] customers in parallel with IPv4?
Tore
Or why you are looking at NAT64 instead of DS-Lite, MAP-E, or MAP-T all of which are better solutions than NAT64. NAT64 + DNS64 which breaks DNSSEC. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 27/Aug/15 07:16, Mark Andrews wrote:
Or why you are looking at NAT64 instead of DS-Lite, MAP-E, or MAP-T all of which are better solutions than NAT64. NAT64 + DNS64 which breaks DNSSEC.
Because with NAT64/DNS64/464XLAT, there isn't any "undo work" after the dust settles. There is value in that. Mark.
* Mark Tinka <mark.tinka@seacom.mu>
On 27/Aug/15 07:16, Mark Andrews wrote:
Or why you are looking at NAT64 instead of DS-Lite, MAP-E, or MAP-T all of which are better solutions than NAT64. NAT64 + DNS64 which breaks DNSSEC.
Because with NAT64/DNS64/464XLAT, there isn't any "undo work" after the dust settles.
Hi Mark, There's not much difference between 464XLAT and MAP-*/DS-Lite/lw4o6 in this respect, the way I see it. In all cases you need four things: 0) Native IPv6. 1) A central component connected to the IPv4 internet and the IPv6. access network (464XLAT: "PLAT", MAP-*: "BR", DS-Lite/lw4o6: "AFTR") 2) Signalling to client that #1 exists and can be used (464XLAT: DNS64, others: DHCPv6 options). 3) A distributed component at the customer premise/nodes that acts on #2 and connects an isolated IPv4 network to the IPv6 access network (464XLAT: "CLAT", MAP-*: "CE", DS-Lite/lw4o6: "B4"). The necessary "undo work" in all cases is to disable #2. At that point components #1 and #3 will become un-used and can be removed if you care. My guess is that you'll care about removing #1 because it probably uses power and space in your PoP, but that you won't care about #3 because that's just an unused software function residing in a customer device you might not even have management access to. I'll grant you that with NAT64/DNS64 *without* 464XLAT there is no #3 to remove as part of your "undo work", but as I mentioned above I doubt you'll care about that particular distinction. Besides, since a CLAT is included by default in multiple client platforms, you can't really prevent your users from using 464XLAT if you're providing NAT64/DNS64 to begin with, unless you're doing something really weird like disabling DNS64 for the "ipv4only.arpa." hostname specifically. Tore
On 27/Aug/15 08:34, Tore Anderson wrote:
Hi Mark,
There's not much difference between 464XLAT and MAP-*/DS-Lite/lw4o6 in this respect, the way I see it. In all cases you need four things:
0) Native IPv6. 1) A central component connected to the IPv4 internet and the IPv6. access network (464XLAT: "PLAT", MAP-*: "BR", DS-Lite/lw4o6: "AFTR") 2) Signalling to client that #1 exists and can be used (464XLAT: DNS64, others: DHCPv6 options). 3) A distributed component at the customer premise/nodes that acts on #2 and connects an isolated IPv4 network to the IPv6 access network (464XLAT: "CLAT", MAP-*: "CE", DS-Lite/lw4o6: "B4").
The necessary "undo work" in all cases is to disable #2. At that point components #1 and #3 will become un-used and can be removed if you care. My guess is that you'll care about removing #1 because it probably uses power and space in your PoP, but that you won't care about #3 because that's just an unused software function residing in a customer device you might not even have management access to.
I'll grant you that with NAT64/DNS64 *without* 464XLAT there is no #3 to remove as part of your "undo work", but as I mentioned above I doubt you'll care about that particular distinction. Besides, since a CLAT is included by default in multiple client platforms, you can't really prevent your users from using 464XLAT if you're providing NAT64/DNS64 to begin with, unless you're doing something really weird like disabling DNS64 for the "ipv4only.arpa." hostname specifically.
Agree that with 464XLAT, the situation is not that different. The issue with 464XLAT for a service provider such as ourselves is that the majority of our customer's CPE and terminal equipment does not have 464XLAT support. You are mostly seeing 464XLAT support in mobile phones, and on specific mobile OS's (iOS does not support 464XLAT today, for example - unless this has changed or is changing). In that situation, our particular use-case could use more DNS64 for the signaling than 464XLAT or equivalent. You can't have it all - each network will have to choose the least of the various evils that can apply to it. Mark.
On Thu, 27 Aug 2015, Mark Tinka wrote:
If your IPv4 is public, you should not "feel slow". Of course, if your IPv4 is private, then yes, some NAT44 may happen somewhere along the path.
I strongly advise you to not assume that just because an IPv4 address is "public" (which I'm reading as RFC1918) means that it's not NATed. I learned the hard way that Tmobile, for one, squats on other organization's public IP space on their mobile network and NATs it to address space they are actually assigned. What you really mean is if your IPv4 is not NATed, then it should not "feel slow", the type of address isn't necessarily an indicator. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross
On 27/Aug/15 17:57, Brandon Ross wrote:
I strongly advise you to not assume that just because an IPv4 address is "public" (which I'm reading as RFC1918) means that it's not NATed.
I learned the hard way that Tmobile, for one, squats on other organization's public IP space on their mobile network and NATs it to address space they are actually assigned. What you really mean is if your IPv4 is not NATed, then it should not "feel slow", the type of address isn't necessarily an indicator.
If we're being pedantic, yes. Mark.
in my experience, differences in latency between ipv4 and ipv6 are mostly due to non-congruent peering/transit. sometimes, one or the other has to actually go farther. randy
On 26/Aug/15 16:28, Ca By wrote:
From largish deployment ...
Another relevant metric, less than 25% of my mobile subscribers traffic require NAT64 translating. 75+% of bits flows through end-to-end IPv6 (thanks Google/Youtube, Facebook, Netflix, Yahoo, Linkedin and so on ...).
And trust me, Cameron knows what's on about... And just in case it's not obvious, fewer and fewer bits will need to hit the NAT64 gateways as more and more of the Internet turns up IPv6. And the beauty of it all, NAT64-based service providers don't have to decommission anything in the future; this is one of the key points around using NAT64 as transition tech. Mark.
On Wed, 26 Aug 2015 07:28:08 -0700, Ca By said:
Another relevant metric, less than 25% of my mobile subscribers traffic require NAT64 translating. 75+% of bits flows through end-to-end IPv6 (thanks Google/Youtube, Facebook, Netflix, Yahoo, Linkedin and so on ...).
So I'm guessing that 75% of the traffic flows with better latency than the 25% IPvhorse-n-buggy traffic? ;)
On Wed, Aug 26, 2015 at 8:16 AM, <Valdis.Kletnieks@vt.edu> wrote:
On Wed, 26 Aug 2015 07:28:08 -0700, Ca By said:
Another relevant metric, less than 25% of my mobile subscribers traffic require NAT64 translating. 75+% of bits flows through end-to-end IPv6 (thanks Google/Youtube, Facebook, Netflix, Yahoo, Linkedin and so on ...).
So I'm guessing that 75% of the traffic flows with better latency than the 25% IPvhorse-n-buggy traffic? ;)
Facebook says IPv6 is 20-40% faster http://www.internetsociety.org/deploy360/blog/2015/04/facebook-news-feeds-lo... Another way to look at it, IPv4 is 20-40% slower than IPv6.
On 26 Aug 2015, at 15:23 , Ca By <cb.list6@gmail.com> wrote:
On Wed, Aug 26, 2015 at 8:16 AM, <Valdis.Kletnieks@vt.edu> wrote:
On Wed, 26 Aug 2015 07:28:08 -0700, Ca By said:
Another relevant metric, less than 25% of my mobile subscribers traffic require NAT64 translating. 75+% of bits flows through end-to-end IPv6 (thanks Google/Youtube, Facebook, Netflix, Yahoo, Linkedin and so on ...).
So I'm guessing that 75% of the traffic flows with better latency than the 25% IPvhorse-n-buggy traffic? ;)
Facebook says IPv6 is 20-40% faster
http://www.internetsociety.org/deploy360/blog/2015/04/facebook-news-feeds-lo...
Another way to look at it, IPv4 is 20-40% slower than IPv6.
The question I have not seen the answer yet to is “why?” Is this really because of the network, e.g., separate pipes in some places still, with forwarding devices handling a lot less pps? Is it because of people having done a newer cleaner-cut network stack implementation and lately cared about its performance? Is it about middle nodes? Has anyone done the research on this?
On 27/Aug/15 14:59, Bjoern A. Zeeb wrote:
The question I have not seen the answer yet to is “why?”
Is this really because of the network, e.g., separate pipes in some places still, with forwarding devices handling a lot less pps?
Is it because of people having done a newer cleaner-cut network stack implementation and lately cared about its performance?
Is it about middle nodes?
Has anyone done the research on this?.
The life of an IPv4 packet on the Internet is very likely to undergo some NAT at some point in its travels. I haven't yet heard of many doing NAT66, hence IPv6 not undergoing NAT means any slow-downs caused by NAT44 are missed (gladly) on IPv6. This might not necessarily be immediately visible on regular networks, but the large content players could count this quite easily due to the significant volumes of traffic their networks are having to aggregate and process. Mark.
On Thu, Aug 27, 2015 at 5:59 AM, Bjoern A. Zeeb < bzeeb-lists@lists.zabbadoz.net> wrote:
On 26 Aug 2015, at 15:23 , Ca By <cb.list6@gmail.com> wrote:
On Wed, Aug 26, 2015 at 8:16 AM, <Valdis.Kletnieks@vt.edu> wrote:
On Wed, 26 Aug 2015 07:28:08 -0700, Ca By said:
Another relevant metric, less than 25% of my mobile subscribers traffic require NAT64 translating. 75+% of bits flows through end-to-end IPv6 (thanks Google/Youtube, Facebook, Netflix, Yahoo, Linkedin and so on ...).
So I'm guessing that 75% of the traffic flows with better latency than the 25% IPvhorse-n-buggy traffic? ;)
Facebook says IPv6 is 20-40% faster
http://www.internetsociety.org/deploy360/blog/2015/04/facebook-news-feeds-lo...
Another way to look at it, IPv4 is 20-40% slower than IPv6.
The question I have not seen the answer yet to is “why?”
Is this really because of the network, e.g., separate pipes in some places still, with forwarding devices handling a lot less pps?
Is it because of people having done a newer cleaner-cut network stack implementation and lately cared about its performance?
Is it about middle nodes?
Has anyone done the research on this?
I too do not know, and i do not care. Looking in the rear view mirror at why NAT encumbered IPv4 sucks is not a priority of mine, but may be an interesting pedantic project for internet historians. We know that NAT causes very minor latency (session setup and matching per packet) and very minor loss (state management chaos), but i can hardly believe that is a 20-40% speedup. Then again, TCP is a sensitive thing. Either way, Twitter and Amazon seem a tad slow... perhaps they should enable IPv6. Or maybe they have plenty of IPv4 and don't care much about the 20-40% performance gain that Facebook has seen. CB
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 26/Aug/15 17:16, Valdis.Kletnieks@vt.edu wrote:
So I'm guessing that 75% of the traffic flows with better latency than the 25% IPvhorse-n-buggy traffic? ;)
Practically, when we've tested NAT64 at reasonable scale, it does not add any noticeable slow-down provided your hardware is decent and you're operating the forwarding plane within the limits supported by the vendor. Yes, I know this can quickly become a cost run-away problem, but for better or worse, that is what separates the wheat from the other thing... The point is you need a transition tech. solution if you are serious about providing a service to your customers. Assuming you don't is living in denial. Mark. -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJV3eJcAAoJEGcZuYTeKm+G2nUP/14tVjKaorUddJPaIfa3qm5y GQ7EGq343ssihW1Vy335xtmXwUX2ti/WelavXBZD8WEU/17wYdy0Yoq7PcnKVk/+ 8NufD9Zp6dDjugIDMczjZbn6NQ/aQjwQ9TVk3SAH90iAgBMkT3SfE3NJE9CqK+LD 90+7wIwNUdY53z8x8xBfPqu6Mf1HSkbngifyJ9piDsAs3Pdki++k8IXJEjDeysop 5EPeCeQydgIMzj2v4dxLhbAI8BGYmPG5501eJbmyoehB3mWtFp3be0wE8RtAHwMY ABUT6dyYAr/yu7lt52ALQUOyN9avodagZR5tRbAck/Ah/0hYpsOErvEo3ZiuUrPE FV0t4Gp6hXcG4/7tgThaFMGWWYomZXCFvO9vSPzMd+CI30dVJ4qtCFLHYQy3PoM+ a9S9ZAvN6qrL+aPANbkg2IIUBv2EiSVQ8tdISf5urQtbyGByEd/31LCaMJZGRnRa Rg38C9K/NtHimGXADR1NZ1KjfrN4tECFXydEYS59FNf29oR0F/jAD4lZPmTTXDXK o5rmfXdLR37Llwr2MStPM41EOQB9tLY+rxwjHIxgl5ZVm6yv3727IAufXDG7gGVk YZJBtVvH63wZEK6o+ki2HdAA2QLr4gdxcsN2KWzQtnwbA3E5tZeyd8jSdDe3Hfze rNX7Ccr2hwkAEH65bLmx =nQN9 -----END PGP SIGNATURE-----
On Wed, 26 Aug 2015 17:59:24 +0200, Mark Tinka said:
The point is you need a transition tech. solution if you are serious about providing a service to your customers. Assuming you don't is living in denial.
Actually, the point is that if you're a content provider, there's a good chance that turning up IPv6 will result in happier eyeballs, which can probably be leveraged into a competitive advantage. And the more content providers do that, the smaller your transition problem becomes.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 26/Aug/15 18:42, Valdis.Kletnieks@vt.edu wrote:
Actually, the point is that if you're a content provider, there's a good chance that turning up IPv6 will result in happier eyeballs, which can probably be leveraged into a competitive advantage. And the more content providers do that, the smaller your transition problem becomes.
I can't argue with you there. But the problem has to be attacked from all sides. We can't just sit back and hope for the best; that's already nearly 2x decades in the making... Mark. -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJV3e0WAAoJEGcZuYTeKm+G6DQP/iXbz6v6xWqAOyLU4TyVWJLa xcf0GBajZ7GR2iHNIqJ/usYAZg1nVvApoaBPd1tCegp8QWM2nzrAz1hRYFZnTZVY LTm40+6UD37/tMML9WgXyXw3qk/23LR0bY2IQZcwBtzscpStAEWCB304GPmyRS1X JFtunFTxE8zP1iD1ErE8CgHvJMN5vRGyJpASxWyk7ZS3UFWDfH1TVur+U9PsqiuZ av0tobjp+/tLgkMYTU2jRhnVbgnhXrkawS0uvT8uyt8ivn8Igf/f15SkM+X4DIJs Ck1Bu2cTtNW8QLuLbu/ue8M9S1JU/jHKS18LN0medoByqPJ1fLL1Ur3Xl2SzBDkm Fr9IZftTvLnpNvyP/FXLF6XH/CyzU1+lChOvhZ8Bmy305ETZFNz177fsjpcdVogg NiZ6GzHhA7wZ1NWrkqSVwdvCcg9kd413MKbhnWPi7cKB1Yi6Tewcam8+xCWH56T7 j2+2qhT3FPQHO5viVgfFEAhCB7PW2p9HRzf7mlpq7ykFIZG4t0oYpXqlBNuVd07o 7qKRIDFM8Ym8Po4edKxQLoW3w0yk8HDfcb8ByiDuoyDHX/ZcrKZY2ME6WTyUBgKf 58w/0IbSJaeTHTjyAaZu/MwgP/WFBzul6sKnXh3aQrdrVOo6xrcW0EvvN+wZGD5D AjhpcWdteKjf/Smv/HlG =igCd -----END PGP SIGNATURE-----
participants (15)
-
Bjoern A. Zeeb -
Brandon Ross -
Ca By -
Clinton Work -
Izaac -
Jared Mauch -
Jared Mauch
-
Jawaid Shell2 -
Mark Andrews -
Mark Tinka -
Randy Bush -
Tom Lanyon -
Tore Anderson -
Valdis.Kletnieks＠vt.edu -
William Herrin