Problems with removing NAT from a network
I've got a customer that is looking to multihome with upstreams in two POPs. Currently they multihome in one POP and utilize a single edge router for some one to one NAT and some PAT for their users. Before they turn up the BGP peer in the new POP I've advised them to abolish NAT once and for all in order to avoid issues with non-stateful NAT between network edges and possible asymmetric routing of their Internet traffic. The PAT can be removed easily enough. The tricky part is the one-one NAT. They have quite a few systems which have 1918 IPs which they claim "cannot be changed". At least not without some painful rebuilds of criticals systems which have these IPs deeply embedded in their configs. Has anyone here had to fix this kind of problem before? Is there a solution that would allow NAT to offloaded to a smaller device hanging off each edge router that can communicate state between each other in case traffic is asymmetrically routed?
On Jan 6, 2011, at 9:38 AM, ML wrote:
At least not without some painful rebuilds of criticals systems which have these IPs deeply embedded in their configs.
They shouldn't be using IP addresses in configs, they should be using DNS names. Time to bite the bullet and get this fixed prior to their eventual forced migration to IPv6. ------------------------------------------------------------------------ Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
On Wed, Jan 5, 2011 at 6:42 PM, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Jan 6, 2011, at 9:38 AM, ML wrote:
At least not without some painful rebuilds of criticals systems which have these IPs deeply embedded in their configs.
They shouldn't be using IP addresses in configs, they should be using DNS names. Time to bite the bullet and get this fixed prior to their eventual forced migration to IPv6.
Somebody should tell the nytimes.com about this being a bad practice, many of their images are linked to ip addresses directly and will certainly fail in the future (this year, mobile) networks that will use NAT64/DNS64. I am sure users will find other places to view their news when nytimes.com fails to work in these ipv6-only networks. Small summary of the problem of IPv4 literals and how they will break in certain IPv6 environments that will be deployed this year http://groups.google.com/group/ipv4literals Cameron ========= http://groups.google.com/group/tmoipv6beta =========
------------------------------------------------------------------------ Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.
-- Alan Kay
In message <AANLkTimkgPYKY_AkA5px4-ca-3=oufhGbnenRkPmpTE1@mail.gmail.com>, Came ron Byrne writes:
On Wed, Jan 5, 2011 at 6:42 PM, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Jan 6, 2011, at 9:38 AM, ML wrote:
At least not without some painful rebuilds of criticals systems which ha=
ve these IPs deeply embedded in their configs.
They shouldn't be using IP addresses in configs, they should be using DNS=
names. =A0Time to bite the bullet and get this fixed prior to their eventu= al forced migration to IPv6.
Somebody should tell the nytimes.com about this being a bad practice, many of their images are linked to ip addresses directly and will certainly fail in the future (this year, mobile) networks that will use NAT64/DNS64. I am sure users will find other places to view their news when nytimes.com fails to work in these ipv6-only networks.
Which is one of the reasons why DS-lite is a better solution for providing legacy access to the IPv4 Internet than NAT64/DNS64. DS-lite only breaks what NAT44 breaks. DS-lite doesn't break new things.
Small summary of the problem of IPv4 literals and how they will break in certain IPv6 environments that will be deployed this year http://groups.google.com/group/ipv4literals
Cameron =3D=3D=3D=3D=3D=3D=3D=3D=3D http://groups.google.com/group/tmoipv6beta =3D=3D=3D=3D=3D=3D=3D=3D=3D
------------------------------------------------------------------------ Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Alan Kay
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Wed, Jan 5, 2011 at 8:31 PM, Mark Andrews <marka@isc.org> wrote:
In message <AANLkTimkgPYKY_AkA5px4-ca-3=oufhGbnenRkPmpTE1@mail.gmail.com>, Came ron Byrne writes:
On Wed, Jan 5, 2011 at 6:42 PM, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Jan 6, 2011, at 9:38 AM, ML wrote:
At least not without some painful rebuilds of criticals systems which ha=
ve these IPs deeply embedded in their configs.
They shouldn't be using IP addresses in configs, they should be using DNS=
names. =A0Time to bite the bullet and get this fixed prior to their eventu= al forced migration to IPv6.
Somebody should tell the nytimes.com about this being a bad practice, many of their images are linked to ip addresses directly and will certainly fail in the future (this year, mobile) networks that will use NAT64/DNS64. I am sure users will find other places to view their news when nytimes.com fails to work in these ipv6-only networks.
Which is one of the reasons why DS-lite is a better solution for providing legacy access to the IPv4 Internet than NAT64/DNS64. DS-lite only breaks what NAT44 breaks. DS-lite doesn't break new things.
Thanks for the tip. But, there are legitimate business reason in various different types of networks for various strategies, thanks for plugging the one your organization makes. I am tired of the IPv6 transition flavor of the day war. The reality for content folks is that there will be IPv4 host, IPv6 hosts, and dual stack hosts. Content needs to be dual-stack to reach everyone the best way (native), but if they lack dual-stack and they use IPv4 literals, they are going to lose eyeballs. End of story. Content folks-- do yourself a favor and follow Roland's advice (also in RFC 1958) and don't use address literals, use names. And, you will notice that the list at http://groups.google.com/group/ipv4literals shows only a few web site, because there are only a few that have this design flaws. If you know others, strengthen your case and add them to the list so that all parties can benefit. Otherwise, it is just a few poorly designed internet services that will be in a rush to fix services when users complain.... or there web pages hits start trending down while their competitors trend up. Cameron
Small summary of the problem of IPv4 literals and how they will break in certain IPv6 environments that will be deployed this year http://groups.google.com/group/ipv4literals
Cameron =3D=3D=3D=3D=3D=3D=3D=3D=3D http://groups.google.com/group/tmoipv6beta =3D=3D=3D=3D=3D=3D=3D=3D=3D
------------------------------------------------------------------------ Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Alan Kay
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 1/5/2011 8:47 PM, Cameron Byrne wrote:
And, you will notice that the list at http://groups.google.com/group/ipv4literals shows only a few web site, because there are only a few that have this design flaws.
And the list looks like it does because the list only shows a *few* web sites. Other surveys have shown significantly more cases. ( http://tools.ietf.org/html/draft-wing-behave-http-ip-address-literals-02#app... "An examination of Alexa's top 1 million domains [Alexa] at the end of August, 2009, showed 2.38% of the HTML in their home pages contained IPv4 address literals." And the list looks like is does because the list only shows a few *web sites*. Quite a few network protocols, particularly peer-to-peer protocols, rely on moving around the IP address literals of peers via mechanisms other than DNS. This includes BitTorrent, Adobe's RTMFP, and Skype's proprietary protocol, and every VoIP system using STUN and/or ICE, to name just a few. Once users figure out that none of those will work when they use you as an ISP, they'll find one that's chosen a better transition technology. Also note that DNSSEC end-to-end and DNS64/NAT64 are mutually exclusive. Now that DNSSEC is actually getting some traction, that's just one more reason to chose a different way to transition. Matthew Kaufman
On Wed, Jan 5, 2011 at 9:10 PM, Matthew Kaufman <matthew@matthew.at> wrote:
On 1/5/2011 8:47 PM, Cameron Byrne wrote:
And, you will notice that the list at http://groups.google.com/group/ipv4literals shows only a few web site, because there are only a few that have this design flaws.
And the list looks like it does because the list only shows a *few* web sites. Other surveys have shown significantly more cases. ( http://tools.ietf.org/html/draft-wing-behave-http-ip-address-literals-02#app... "An examination of Alexa's top 1 million domains [Alexa] at the end of August, 2009, showed 2.38% of the HTML in their home pages contained IPv4 address literals."
And the list looks like is does because the list only shows a few *web sites*. Quite a few network protocols, particularly peer-to-peer protocols,
I understand my users pretty well, they only go to a few web pages ... its the nature of the net. I assure you, i am not taking any undue risk with regards to web. Try our friendly user trial and give me your feedback, thats why i am running it.
rely on moving around the IP address literals of peers via mechanisms other than DNS. This includes BitTorrent, Adobe's RTMFP, and Skype's proprietary
Ah Skype. According to your web page you work at Skype. Skype is a well known IPv6 spoiler application. In fact, in the IETF and many other circles, Skype is the only app that we can't seem to get to work with IPv6. Are you here to help with that or to tell us that we need to keep IPv4 around indefinitely? In fact, we were just talking about how Skype as a spoiler this morning http://www.ietf.org/mail-archive/web/v6ops/current/msg06837.html Here is a pointer to IPv6-only users who would love to use Skype on IPv6-only handsets. http://talk.maemo.org/showthread.php?t=60320&page=24 Looking at the last post, it looks like they were able to NAT46 Skype to then talk out the NAT64 ... ugly. But serious, get with me off list and lets collaborate. I can help from the networks side, and i am eager to make progress. Skype should not be the IPv6 spoiler app when NEARLY EVERYTHING ELSE WORKS. Read the thread i mentioned, real users, real developers, real network that is IPv6-only. Notice that things generally work, those folks have hacked their way to perhaps even making Skype work.
protocol, and every VoIP system using STUN and/or ICE, to name just a few. Once users figure out that none of those will work when they use you as an ISP, they'll find one that's chosen a better transition technology.
Seriously, 95+% of my traffic is web and email, and STUN and ICE don't matter much to grandma as long as m.v6.facebook.com loads.
Also note that DNSSEC end-to-end and DNS64/NAT64 are mutually exclusive. Now that DNSSEC is actually getting some traction, that's just one more reason to chose a different way to transition.
Strategy is done. Implementation is on-going. 3GPP and IETF joint meeting said dual-stack and IPv6-only + NAT64 are the 2 paths forward for mobile. http://www.3gpp.org/ftp/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs./IPW... Without going into too much detail, ds-lite does not live in mobile and likely never will. Any solution that requires IPv4 is not strategic. IPv4 addresses simply are not available at the scale of large mobile network operators, public, private, or bogon. Mobile must move to IPv6, and IPv6-only + NAT64 pushes the envelope in ways that dual-stack never has, and hence it just might work to *transition* to v6. As long as dual-stack is around, the app vendors don't have to move and network guys have to dream up hacks to support these legacy apps (CGN ....). Cameron
Matthew Kaufman
In message <AANLkTikS_EnACm2BfYx=B=M=khejAqJKvdbwX2hwmqHh@mail.gmail.com>, Came ron Byrne writes:
As long as dual-stack is around, the app vendors don't have to move and network guys have to dream up hacks to support these legacy apps (CGN ....).
NAT64 is CGN expecially when it is being implemented by the cellular carriers.
Cameron
Matthew Kaufman
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Wed, Jan 5, 2011 at 9:55 PM, Mark Andrews <marka@isc.org> wrote:
In message <AANLkTikS_EnACm2BfYx=B=M=khejAqJKvdbwX2hwmqHh@mail.gmail.com>, Came ron Byrne writes:
As long as dual-stack is around, the app vendors don't have to move and network guys have to dream up hacks to support these legacy apps (CGN ....).
NAT64 is CGN expecially when it is being implemented by the cellular carriers.
Agreed. And, the NAT44 that 99% of my customer use to today is also a CGN. It's status quo, all v4 flows require state in my network, NAT44 or NAT64. But, NAT64 has an exit strategy. With every new AAAA that comes out, that is one less destination requiring state in my network. Cameron
Cameron
Matthew Kaufman
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
In message <AANLkTik47D9ur2xTJTzhG3_izEq3oRK90ecVzkOtHY8k@mail.gmail.com>, Came ron Byrne writes:
On Wed, Jan 5, 2011 at 9:55 PM, Mark Andrews <marka@isc.org> wrote:
In message <AANLkTikS_EnACm2BfYx=3DB=3DM=3DkhejAqJKvdbwX2hwmqHh@mail.gmai=
l.com>, Came
ron Byrne writes:
As long as dual-stack is around, the app vendors don't have to move and network guys have to dream up hacks to support these legacy apps (CGN ....).
NAT64 is CGN expecially when it is being implemented by the cellular carriers.
Agreed. And, the NAT44 that 99% of my customer use to today is also a CGN.
It's status quo, all v4 flows require state in my network, NAT44 or NAT64.
But, NAT64 has an exit strategy. With every new AAAA that comes out, that is one less destination requiring state in my network.
I will give you that it is easy to see with NAT64 when the target space has moved. It also forces you to upgrade all client applications to support IPv6 from the start. Anyway its horses for courses. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 1/5/2011 9:39 PM, Cameron Byrne wrote:
I understand my users pretty well, they only go to a few web pages ... its the nature of the net. I assure you, i am not taking any undue risk with regards to web. Try our friendly user trial and give me your feedback, thats why i am running it.
I'm not particularly surprised that a mobile client platform has a different access pattern than desktop users... not a whole lot of mobile BitTorrent clients yet, for instance.
Ah Skype. According to your web page you work at Skype. Skype is a well known IPv6 spoiler application. In fact, in the IETF and many other circles, Skype is the only app that we can't seem to get to work with IPv6. Are you here to help with that or to tell us that we need to keep IPv4 around indefinitely?
Indeed, I work at Skype now and Adobe (developing RTMFP) before that. At this point (because not everyone has IPv6) this class of applications (along with BitTorrent and ICE-using VoIP apps) needs to be able to use your NAT64 to talk to peers that are IPv4-only. To do that, they need to be able to discover your NAT64 even though they're not doing DNS lookups to find the IPv4 addresses of peers. This will take 1) a way to do this and 2) upgrades of the apps to take advantage of it. It is impossible to do #2 until #1 is solved. There's been discussion in BEHAVE about this topic... draft-korhonen-behave-nat64-learn-analysis for instance. I even proposed a solution that wasn't raised in that or previous documents here: http://www.ietf.org/mail-archive/web/behave/current/msg09050.html (which I suppose, since it hasn't been mentioned elsewhere, should be written up as a draft if/when I have some free time)
Skype should not be the IPv6 spoiler app when NEARLY EVERYTHING ELSE WORKS. Read the thread i mentioned, real users, real developers, real network that is IPv6-only. Notice that things generally work, those folks have hacked their way to perhaps even making Skype work. There's lots of other apps that don't work. Skype is just the squeaky wheel because it is so popular.
Seriously, 95+% of my traffic is web and email, and STUN and ICE don't matter much to grandma as long as m.v6.facebook.com loads.
See my above comment about how I'm not surprised, given the specific client population.
As long as dual-stack is around, the app vendors don't have to move and network guys have to dream up hacks to support these legacy apps (CGN ....).
Dual-stack + NAT44 has a lot fewer unsolved corner cases *and* doesn't require apps to be upgraded to do discovery of the NAT64 prefix(es) (which, for some legacy apps that are no longer under development will never happen). NAT64/DNS64 is an interesting experiment that works for >95% of the web. But it isn't really a solution unless "the web" is all you care about. Matthew Kaufman
On Thu, Jan 6, 2011 at 9:18 AM, Matthew Kaufman <matthew@matthew.at> wrote:
On 1/5/2011 9:39 PM, Cameron Byrne wrote:
I understand my users pretty well, they only go to a few web pages ... its the nature of the net. I assure you, i am not taking any undue risk with regards to web. Try our friendly user trial and give me your feedback, thats why i am running it.
I'm not particularly surprised that a mobile client platform has a different access pattern than desktop users... not a whole lot of mobile BitTorrent clients yet, for instance.
Ah Skype. According to your web page you work at Skype. Skype is a well known IPv6 spoiler application. In fact, in the IETF and many other circles, Skype is the only app that we can't seem to get to work with IPv6. Are you here to help with that or to tell us that we need to keep IPv4 around indefinitely?
Indeed, I work at Skype now and Adobe (developing RTMFP) before that.
At this point (because not everyone has IPv6) this class of applications (along with BitTorrent and ICE-using VoIP apps) needs to be able to use your NAT64 to talk to peers that are IPv4-only. To do that, they need to be able to discover your NAT64 even though they're not doing DNS lookups to find the IPv4 addresses of peers.
This will take 1) a way to do this and 2) upgrades of the apps to take advantage of it. It is impossible to do #2 until #1 is solved.
There's been discussion in BEHAVE about this topic... draft-korhonen-behave-nat64-learn-analysis for instance. I even proposed a solution that wasn't raised in that or previous documents here: http://www.ietf.org/mail-archive/web/behave/current/msg09050.html (which I suppose, since it hasn't been mentioned elsewhere, should be written up as a draft if/when I have some free time)
Skype is not defined in an IETF RFC, so saying you need an RFC to move forward is bit confusing. There are several methods that just work today, I am all for standards, but a closed platforms generally find ways to progress without or in spite of standards. Skype is a closed platform.
Skype should not be the IPv6 spoiler app when NEARLY EVERYTHING ELSE WORKS. Read the thread i mentioned, real users, real developers, real network that is IPv6-only. Notice that things generally work, those folks have hacked their way to perhaps even making Skype work.
There's lots of other apps that don't work. Skype is just the squeaky wheel because it is so popular.
Please make a list and let us know. Otherwise, this is just hand waving like the IPv4 literals sites. I have had people on various mailing list tell me all things they think won't work, but in my own experience and in the experience of my beta users, who are publicly documenting their efforts on the support boards, things work well. Yes, some things don't work due the fact that it is a beta and something don't work due to the fact that it is IPv6-only, but they are not show stoppers for the business. As a user, i have been using IPv6-only on Symbian for 9 months without an issue. The service works as i would expect it to with IPv4, no user perceived differences. Skype is a squeaky wheel, but most (99%) things users do works fine. As mentioned, in mobile, 95+% of the traffic is web and email. And, most "apps", are also just web and email. My advice to Skype is to come up with a solution to work for IPv6-only clients. That is my advice to all apps and all content. IPv6-only clients are an obvious reality in an IPv4 exhausted world. You cannot seriously come to a network operators support mailing list and say that the network guys have to keep investing in network tweaks while you wait for a standards body to solve a problem for your closed non-standard applications. I won't go into my diatribe about why dual-stack is not an obvious choice in mobile, you can check the video of it at the google IPv6 conference in 2010. If you have further questions, i am glad to help you understand and entertain your ideas off list. The main point is the dual-stack and substantially more expensive and the IPv4 part of dual-stack is run out of addresses....private, public, bogon. http://www.youtube.com/watch?v=1GlRgaFriYU#t=15m38s
Seriously, 95+% of my traffic is web and email, and STUN and ICE don't matter much to grandma as long as m.v6.facebook.com loads.
See my above comment about how I'm not surprised, given the specific client population.
As long as dual-stack is around, the app vendors don't have to move and network guys have to dream up hacks to support these legacy apps (CGN ....).
Dual-stack + NAT44 has a lot fewer unsolved corner cases *and* doesn't require apps to be upgraded to do discovery of the NAT64 prefix(es) (which, for some legacy apps that are no longer under development will never happen).
Dual-stack cost the mobile network operator 2x in the packet core, check the Youtube video. It is not acceptable to ask the network operators to increase their cost by 2x while the apps sit and wait.
NAT64/DNS64 is an interesting experiment that works for >95% of the web. But it isn't really a solution unless "the web" is all you care about.
Experiment? Yes, the experiment part is over. As i mentioned, we are deploying. The 3GPP has adopted IPv6-Only + NAT64 as an official path nearly a year ago. I have tried to make it clear to folks that upgrading to IPv6 is the only way to ensure your apps and content continue to work as you expected. Otherwise, you traverse NAT64 CGN and some things won't work. The same is true for DS-lite and others, but in different ways. To that end, lets partner up and make Skype work with IPv6. I also assure you, many mobile operators are pursuing this NAT64 path for the same reason I am. Cameron
Matthew Kaufman
On 1/6/2011 10:07 AM, Cameron Byrne wrote:
Skype is not defined in an IETF RFC, so saying you need an RFC to move forward is bit confusing.
I don't see a disconnect at all. Skype also uses TCP and UDP, which are both subjects of RFCs. That said, it doesn't need to be an RFC... just *a reliable way* of discovering the appropriate NAT64 prefix.
There are several methods that just work today, Of the methods proposed in the survey draft, only one - the one that doesn't require the DNS64 spec or operator to make any changes (making an AAAA lookup for something you know only has an A record) - works but *only if* the mapping scheme is such that it is possible to successfully derive a functional prefix and the scheme from the results of that query.
So in other words, *if* the query results in an AAAA where, by inspection, you can guess where you'd need to stuff the IPv4 address bits *and* the resulting address causes the "right" NAT64 (if there's
1) to be used, then you're set. I am all for standards, but a closed platforms generally find ways to progress without or in spite of standards. Skype is a closed platform. No question. And for all you know we might be working on other ways around this problem, but none of them as elegant as a defined specification for how to discover the presence of a NAT64 and the mapping.
There's lots of other apps that don't work. Skype is just the squeaky wheel because it is so popular.
Please make a list and let us know. Otherwise, this is just hand waving like the IPv4 literals sites. I'll start with "peer to peer connectivity using RTMFP in Flash Player" and "BitTorrent". Both Flash Player and BitTorrent are fairly popular on desktop platforms.
My advice to Skype is to come up with a solution to work for IPv6-only clients. That is my advice to all apps and all content. IPv6-only clients are an obvious reality in an IPv4 exhausted world. That's not the problem... the problem is reaching the existing base of IPv4 clients from those IPv6-only clients without making Skype relay all
I'm sure there's more. the traffic via servers somewhere, as I'm sure you know.
You cannot seriously come to a network operators support mailing list and say that the network guys have to keep investing in network tweaks while you wait for a standards body to solve a problem for your closed non-standard applications. I've been on this list since approximately the time it was formed, so I'm not coming here to ask for something. Just pointing out what will break.
I also assure you, many mobile operators are pursuing this NAT64 path for the same reason I am. Randy Bush would encourage his competitors to do just as you've done, I'm sure.
Matthew Kaufman
Doesn't all of this become moot if Skype just develops a dual-stack capable client and servers? Owen On Jan 6, 2011, at 1:32 PM, Matthew Kaufman wrote:
On 1/6/2011 10:07 AM, Cameron Byrne wrote:
Skype is not defined in an IETF RFC, so saying you need an RFC to move forward is bit confusing.
I don't see a disconnect at all. Skype also uses TCP and UDP, which are both subjects of RFCs.
That said, it doesn't need to be an RFC... just *a reliable way* of discovering the appropriate NAT64 prefix.
There are several methods that just work today, Of the methods proposed in the survey draft, only one - the one that doesn't require the DNS64 spec or operator to make any changes (making an AAAA lookup for something you know only has an A record) - works but *only if* the mapping scheme is such that it is possible to successfully derive a functional prefix and the scheme from the results of that query.
So in other words, *if* the query results in an AAAA where, by inspection, you can guess where you'd need to stuff the IPv4 address bits *and* the resulting address causes the "right" NAT64 (if there's >1) to be used, then you're set.
I am all for standards, but a closed platforms generally find ways to progress without or in spite of standards. Skype is a closed platform. No question. And for all you know we might be working on other ways around this problem, but none of them as elegant as a defined specification for how to discover the presence of a NAT64 and the mapping.
There's lots of other apps that don't work. Skype is just the squeaky wheel because it is so popular.
Please make a list and let us know. Otherwise, this is just hand waving like the IPv4 literals sites. I'll start with "peer to peer connectivity using RTMFP in Flash Player" and "BitTorrent". Both Flash Player and BitTorrent are fairly popular on desktop platforms.
I'm sure there's more.
My advice to Skype is to come up with a solution to work for IPv6-only clients. That is my advice to all apps and all content. IPv6-only clients are an obvious reality in an IPv4 exhausted world. That's not the problem... the problem is reaching the existing base of IPv4 clients from those IPv6-only clients without making Skype relay all the traffic via servers somewhere, as I'm sure you know.
You cannot seriously come to a network operators support mailing list and say that the network guys have to keep investing in network tweaks while you wait for a standards body to solve a problem for your closed non-standard applications. I've been on this list since approximately the time it was formed, so I'm not coming here to ask for something. Just pointing out what will break.
I also assure you, many mobile operators are pursuing this NAT64 path for the same reason I am. Randy Bush would encourage his competitors to do just as you've done, I'm sure.
Matthew Kaufman
On Jan 6, 2011, at 8:48 12PM, Owen DeLong wrote:
Doesn't all of this become moot if Skype just develops a dual-stack capable client and servers?
Skype is an interesting case because of its peer-to-peer nature. Given the state of v6 deployment and operational experience[1], and especially given the fragility of tunneled IPv6 connections[2], there is potential for a lot of broken links. --Steve Bellovin, http://www.cs.columbia.edu/~smb [1] All concerned are mystified about why my office machines can't reach [major site] via v6, even though traceroute6 from both ends shows the packets reaching the same network. A couple of weeks earlier, I couldn't get anywhere via IPv6 because someone had connected a NAT+v6 tunneler in bridge mode, and my machine believe its RA messages. [2] See http://www.google.com/intl/en/ipv6/faq.html#tunnel
On 1/6/11 5:48 PM, Owen DeLong wrote:
Doesn't all of this become moot if Skype just develops a dual-stack capable client and servers?
Really, only some fraction of the supernodes and the login servers need to be dual stack.
Owen
On Jan 6, 2011, at 1:32 PM, Matthew Kaufman wrote:
On 1/6/2011 10:07 AM, Cameron Byrne wrote:
Skype is not defined in an IETF RFC, so saying you need an RFC to move forward is bit confusing.
I don't see a disconnect at all. Skype also uses TCP and UDP, which are both subjects of RFCs.
That said, it doesn't need to be an RFC... just *a reliable way* of discovering the appropriate NAT64 prefix.
There are several methods that just work today, Of the methods proposed in the survey draft, only one - the one that doesn't require the DNS64 spec or operator to make any changes (making an AAAA lookup for something you know only has an A record) - works but *only if* the mapping scheme is such that it is possible to successfully derive a functional prefix and the scheme from the results of that query.
So in other words, *if* the query results in an AAAA where, by inspection, you can guess where you'd need to stuff the IPv4 address bits *and* the resulting address causes the "right" NAT64 (if there's >1) to be used, then you're set.
I am all for standards, but a closed platforms generally find ways to progress without or in spite of standards. Skype is a closed platform. No question. And for all you know we might be working on other ways around this problem, but none of them as elegant as a defined specification for how to discover the presence of a NAT64 and the mapping.
There's lots of other apps that don't work. Skype is just the squeaky wheel because it is so popular.
Please make a list and let us know. Otherwise, this is just hand waving like the IPv4 literals sites. I'll start with "peer to peer connectivity using RTMFP in Flash Player" and "BitTorrent". Both Flash Player and BitTorrent are fairly popular on desktop platforms.
I'm sure there's more.
My advice to Skype is to come up with a solution to work for IPv6-only clients. That is my advice to all apps and all content. IPv6-only clients are an obvious reality in an IPv4 exhausted world. That's not the problem... the problem is reaching the existing base of IPv4 clients from those IPv6-only clients without making Skype relay all the traffic via servers somewhere, as I'm sure you know.
You cannot seriously come to a network operators support mailing list and say that the network guys have to keep investing in network tweaks while you wait for a standards body to solve a problem for your closed non-standard applications. I've been on this list since approximately the time it was formed, so I'm not coming here to ask for something. Just pointing out what will break.
I also assure you, many mobile operators are pursuing this NAT64 path for the same reason I am. Randy Bush would encourage his competitors to do just as you've done, I'm sure.
Matthew Kaufman
On 1/6/2011 6:34 PM, Joel Jaeggli wrote:
On 1/6/11 5:48 PM, Owen DeLong wrote:
Doesn't all of this become moot if Skype just develops a dual-stack capable client and servers? Really, only some fraction of the supernodes and the login servers need to be dual stack.
Without revealing too much about the architecture, I can tell you that it would need to be a significant fraction of the supernodes (due to how node-supernode mapping works in these types of P2P systems), the relay nodes (not mentioned) *and* the login servers. Not all of which are deployed and controlled by Skype, of course, as recent press about the most recent outage has reiterated for those who didn't know. Matthew Kaufman
On 01/07/2011 03:57 AM, Matthew Kaufman wrote:
On 1/6/2011 6:34 PM, Joel Jaeggli wrote:
On 1/6/11 5:48 PM, Owen DeLong wrote:
Doesn't all of this become moot if Skype just develops a dual-stack capable client and servers? Really, only some fraction of the supernodes and the login servers need to be dual stack.
Without revealing too much about the architecture, I can tell you that it would need to be a significant fraction of the supernodes (due to how node-supernode mapping works in these types of P2P systems), the relay nodes (not mentioned) *and* the login servers. Not all of which are deployed and controlled by Skype, of course, as recent press about the most recent outage has reiterated for those who didn't know.
Matthew Kaufman
Hello Mr. Kaufman, In the upcoming years, we will have no IPv6 in some places and badly performing IPv4 (CGN, etc.) with working IPv6 in others. If I was Skype I would make really sure that all my relay nodes and login servers have IPv6 with enough bandwidth or can easily upgrade the bandwidth where neede. And make sure atleast IPv6-client and IPv6-servers communication works everywhere where there is IPv6. Atleast get your servers and network ready with IPv6. Tell your suppliers that if they don't have IPv6 by 'deadline' (you decide) you will (have to) go somewhere else. Because if you still have to deploy, test and fix IPv6 to your servers when it turns out the transition workarounds you have created in software don't work as well as you hoped then you will have a real problem on your hands. For your customers it is really easy. When Skype does not work, people will jump ship where they can and maybe use Google Talk or whatever. I hear they also have a similair service like SkypeOut ? Judging by the amount of effort Google put in to making sure their network supports IPv6, I wouldn't be surprised if Google Talk 'just works'. They might even start including it with Google TV. I suggest making sure you include both IPv4 and IPv6 addresses in your protocol, maybe it needs to be extended. So that the client at the other end can choose what IP-version to use. Or can try both. Maybe the login-server can help to decide for the client. But those login servers will need to have good IPv6 connectivity to be able to do so. If you don't do these 2 things (maybe you already have I don't know) you might find that your business will suffer. I'm sorry if it sounds a bit like fear mongering, but to me it sounds like common sense that if a business is not prepared when the environment that business operates in changes and that business does not adapt to the changes in time that business might suffer. Have a nice weekend, Leen.
On 1/8/2011 3:16 AM, Leen Besselink wrote:
Hello Mr. Kaufman,
In the upcoming years, we will have no IPv6 in some places and badly performing IPv4 (CGN, etc.) with working IPv6 in others.
Right. So we're discussing just how "badly performing" the IPv4 can be and still be acceptable as "access to the IPv4 Internet for your customers". I am arguing that CGN (NAT44 to get additional IPv4 to dual-stack) doesn't break nearly as much as NAT64/DNS64 does, and that in fact NAT64/DNS64 breaks *so much* that you probably can't/shouldn't sell it to your customers as "access to the IPv4 Internet". Note that for a *very* long time... much longer than there will be new IPv4 addresses available... there will be a whole lot of places that have good IPv4 and no IPv6. (As you note above)
If I was Skype I would make really sure that all my relay nodes and login servers have IPv6 with enough bandwidth or can easily upgrade the bandwidth where neede. And make sure atleast IPv6-client and IPv6-servers communication works everywhere where there is IPv6. Clearly that would be needed to serve the IPv6-only users well.
For your customers it is really easy. When Skype does not work, people will jump ship where they can and maybe use Google Talk or whatever. Ah. But you're taking the bet that when Skype does not work on *your* network that provides IPv4 access via NAT64 people won't "jump ship" to a provider that uses CGN or even has enough native IPv4 addresses left around. I suggest making sure you include both IPv4 and IPv6 addresses in your protocol, maybe it needs to be extended. So that the client at the other end can choose what IP-version to use. Or can try both. Maybe the login-server can help to decide for the client. But those login servers will need to have good IPv6 connectivity to be able to do so. But none of that solves the problem of talking from an IPv6 client that has broken IPv4 access (NAT64) to a an IPv4 client that has no IPv6 access.
I'm sorry if it sounds a bit like fear mongering, but to me it sounds like common sense that if a business is not prepared when the environment that business operates in changes and that business does not adapt to the changes in time that business might suffer. But that's true of ISPs when they choose how to deal with the lack of additional IPv4 space but continued customer demand to reach the IPv4 Internet, too, isn't it?
Matthew Kaufman
On 01/09/2011 07:46 AM, Matthew Kaufman wrote:
On 1/8/2011 3:16 AM, Leen Besselink wrote:
Hello Mr. Kaufman,
In the upcoming years, we will have no IPv6 in some places and badly performing IPv4 (CGN, etc.) with working IPv6 in others.
Right. So we're discussing just how "badly performing" the IPv4 can be and still be acceptable as "access to the IPv4 Internet for your customers".
I am arguing that CGN (NAT44 to get additional IPv4 to dual-stack) doesn't break nearly as much as NAT64/DNS64 does, and that in fact NAT64/DNS64 breaks *so much* that you probably can't/shouldn't sell it to your customers as "access to the IPv4 Internet".
I think there will be CGN's and NAT64/DNS64 which will add extra latency and may be overloaded at times. But I also currently still see a fragmented IPv6 Internet where not everyone can reach everyone. So currently IPv6 isn't ready and IPv4 is still working, but for how long ?
Note that for a *very* long time... much longer than there will be new IPv4 addresses available... there will be a whole lot of places that have good IPv4 and no IPv6. (As you note above)
Personally I hope there be a lot of places where we have good IPv4 and good IPv6. Looking at the history of IPv6 I would have liked to see more of that today. Yes, it will be a long time before IPv4 will suck in a lot of places. But that is no reason for not deploying IPv6 in the network everywhere now. That is what we are doing.
If I was Skype I would make really sure that all my relay nodes and login servers have IPv6 with enough bandwidth or can easily upgrade the bandwidth where neede. And make sure atleast IPv6-client and IPv6-servers communication works everywhere where there is IPv6. Clearly that would be needed to serve the IPv6-only users well.
And the dual-stack customers, CGN with IPv6 customers and NAT64/DNS64 customers who want to talk to IPv6-only users.
For your customers it is really easy. When Skype does not work, people will jump ship where they can and maybe use Google Talk or whatever.
Ah. But you're taking the bet that when Skype does not work on *your* network that provides IPv4 access via NAT64 people won't "jump ship" to a provider that uses CGN or even has enough native IPv4 addresses left around.
I couldn't care less about what Skype does, it was just advice. I'm in the content-/hosting-business. Most of what we have on our network is websites. For that I can only choose between 2 things publish no AAAA record in DNS or publish an AAAA-record in DNS for our hosted websites. I could try to do this selectively or per network basis like Google does, but that is about it. As IPv6 is a reality, all I can do is choose when to add the AAAA-record.
I suggest making sure you include both IPv4 and IPv6 addresses in your protocol, maybe it needs to be extended. So that the client at the other end can choose what IP-version to use. Or can try both. Maybe the login-server can help to decide for the client. But those login servers will need to have good IPv6 connectivity to be able to do so. But none of that solves the problem of talking from an IPv6 client that has broken IPv4 access (NAT64) to a an IPv4 client that has no IPv6 access.
I'm just suggesting you add it to give you more flexibility. If you have more information and more paths to/from and between your customers you have more options to allow them to talk directly. I've seen a discussion about DNSSEC and DNS64/NAT64 as well and it would be really good to have some pointers maybe in the additional section of the DNS-response or something like EDNS0 to tell us that the DNS64-translation has happend. NAT64/DNS64 will suck if they do deploy it, I would rather see CGN too. To be honest I don't think that will be great either on the long run. I would like to see everyone deploy IPv6 already. Take for example the access-provider for my home connection, it looks like their network will be ready for IPv6 maybe next year. From my experience with deploying IPv6 their are always problems which need extra time. So next year might be on time, but who says they will make that 'deadline'.
I'm sorry if it sounds a bit like fear mongering, but to me it sounds like common sense that if a business is not prepared when the environment that business operates in changes and that business does not adapt to the changes in time that business might suffer. But that's true of ISPs when they choose how to deal with the lack of additional IPv4 space but continued customer demand to reach the IPv4 Internet, too, isn't it?
Yes, as a content-/hosting-provider or creator of a network application as yourself I hope that everywhere where IPv6 has been deployed it works well. If it is true what someone else mentioned that the mobile operators choose to all deploy NAT64/DNS64 then that sucks. But I fully understand it, if they as an industry can't get the equipment manufacturers to deliver them products which don't cost them twice as much if they deploy IPv4 and IPv6 at the same time then they have a hard choice to make. It looks like they already made their choice. The mobile stack has many parts and paying twice for a lot of those parts is a hard to sell to management.
Matthew Kaufman
On Jan 9, 2011, at 4:57 PM, Leen Besselink wrote:
On 01/09/2011 07:46 AM, Matthew Kaufman wrote:
On 1/8/2011 3:16 AM, Leen Besselink wrote:
Hello Mr. Kaufman,
In the upcoming years, we will have no IPv6 in some places and badly performing IPv4 (CGN, etc.) with working IPv6 in others.
Right. So we're discussing just how "badly performing" the IPv4 can be and still be acceptable as "access to the IPv4 Internet for your customers".
I am arguing that CGN (NAT44 to get additional IPv4 to dual-stack) doesn't break nearly as much as NAT64/DNS64 does, and that in fact NAT64/DNS64 breaks *so much* that you probably can't/shouldn't sell it to your customers as "access to the IPv4 Internet".
I think there will be CGN's and NAT64/DNS64 which will add extra latency and may be overloaded at times. But I also currently still see a fragmented IPv6 Internet where not everyone can reach everyone. So currently IPv6 isn't ready and IPv4 is still working, but for how long ?
We're trying to do everything we can to resolve the fragmentation. We have offered on numerous occasions to peer with both of the providers that are currently segmented from our ASN (6939), going even so far as baking a cake for Cogent (AS174). Our attempts to resolve this continue to this day and we remain willing to peer with anyone that is able to reach us physically. We have an aggressively open peering policy. If you are segmented from our network, we encourage you to either peer directly with us, encourage your upstream(s) to peer with us, or, connect to us with a fee BGP tunnel for the time being. If anyone is having trouble getting "unsegmented" from AS6939, they are welcome to send me email and I will make sure we do whatever we can to assist in resolving the matter. Owen
On Jan 8, 2011, at 10:46 PM, Matthew Kaufman wrote:
On 1/8/2011 3:16 AM, Leen Besselink wrote:
Hello Mr. Kaufman,
In the upcoming years, we will have no IPv6 in some places and badly performing IPv4 (CGN, etc.) with working IPv6 in others.
Right. So we're discussing just how "badly performing" the IPv4 can be and still be acceptable as "access to the IPv4 Internet for your customers".
I am arguing that CGN (NAT44 to get additional IPv4 to dual-stack) doesn't break nearly as much as NAT64/DNS64 does, and that in fact NAT64/DNS64 breaks *so much* that you probably can't/shouldn't sell it to your customers as "access to the IPv4 Internet".
NAT44 perhaps, but, the problem is that most CGNs proposed aren't NAT44, they're at best NAT444 and likely more like NAT44444 or worse in the real world. Today, we have NAT44->Internet<-NAT44 in many sessions (Skype, VOIP, etc.) which connect to each other via STUN, UPnP, etc. Once you move from NAT44 to NAT444, most of the working traversal mechanisms break in interesting ways and at NAT44444, virtually nothing peer-to-peer-ish gets through at all as you simply can't abstract UPnP or anything else through that many layers at either end. With CGN, the details look more like: NAT44->ISP->NAT44->Internet<-NAT44<-ISP<-NAT44 Giving us NAT44444.
Note that for a *very* long time... much longer than there will be new IPv4 addresses available... there will be a whole lot of places that have good IPv4 and no IPv6. (As you note above)
I think this "*very* long time" will be much shorter than you think for meaningful values of "whole lot of places".
If I was Skype I would make really sure that all my relay nodes and login servers have IPv6 with enough bandwidth or can easily upgrade the bandwidth where neede. And make sure atleast IPv6-client and IPv6-servers communication works everywhere where there is IPv6. Clearly that would be needed to serve the IPv6-only users well.
I think this is definitely the ideal first step, but, I confess I don't know the inner workings of Skype. Even this is probably a large effort in their codebase, so, I hope they've started working on it.
For your customers it is really easy. When Skype does not work, people will jump ship where they can and maybe use Google Talk or whatever.
Ah. But you're taking the bet that when Skype does not work on *your* network that provides IPv4 access via NAT64 people won't "jump ship" to a provider that uses CGN or even has enough native IPv4 addresses left around.
I'm betting Skype breaks just as bad in many CGN environments and that the most likely candidate to actually work will be B4/AFTR or DS-Lite. However, there are different problems that come up there as well.
I suggest making sure you include both IPv4 and IPv6 addresses in your protocol, maybe it needs to be extended. So that the client at the other end can choose what IP-version to use. Or can try both. Maybe the login-server can help to decide for the client. But those login servers will need to have good IPv6 connectivity to be able to do so. But none of that solves the problem of talking from an IPv6 client that has broken IPv4 access (NAT64) to a an IPv4 client that has no IPv6 access.
Nor will anything else and broken IPv4 access is an apt term to describe any of: NAT64 DS-LITE/B4/AFTR CGN/LSN They each have their own brand of broken IPv4. Let's face it, while the existing IPv4 internet isn't going to suddenly break when we run out of available addresses, it is going to slowly suffer from increased breakage as we attempt to recycle those addresses in ever more creative and unintended ways.
I'm sorry if it sounds a bit like fear mongering, but to me it sounds like common sense that if a business is not prepared when the environment that business operates in changes and that business does not adapt to the changes in time that business might suffer. But that's true of ISPs when they choose how to deal with the lack of additional IPv4 space but continued customer demand to reach the IPv4 Internet, too, isn't it?
Yep. Owen
On 1/9/2011 9:51 PM, Owen DeLong wrote:
On Jan 8, 2011, at 10:46 PM, Matthew Kaufman wrote:
On 1/8/2011 3:16 AM, Leen Besselink wrote:
Hello Mr. Kaufman,
In the upcoming years, we will have no IPv6 in some places and badly performing IPv4 (CGN, etc.) with working IPv6 in others. Right. So we're discussing just how "badly performing" the IPv4 can be and still be acceptable as "access to the IPv4 Internet for your customers".
I am arguing that CGN (NAT44 to get additional IPv4 to dual-stack) doesn't break nearly as much as NAT64/DNS64 does, and that in fact NAT64/DNS64 breaks *so much* that you probably can't/shouldn't sell it to your customers as "access to the IPv4 Internet".
NAT44 perhaps, but, the problem is that most CGNs proposed aren't NAT44, they're at best NAT444 and likely more like NAT44444 or worse in the real world.
Well yes, at the very least it'll be NAT444 because people won't throw their home boxes out just because their carrier can now give them more synthetic IPv4 space.
Today, we have NAT44->Internet<-NAT44 in many sessions (Skype, VOIP, etc.) which connect to each other via STUN, UPnP, etc.
Once you move from NAT44 to NAT444, most of the working traversal mechanisms break in interesting ways and at NAT44444, virtually nothing peer-to-peer-ish gets through at all as you simply can't abstract UPnP or anything else through that many layers at either end.
Maybe. It really depends on where you have nodes that can provide useful information about the topology. But yes, it gets uglier and uglier, eventually to the point of not working in some cases. But NAT64 is NAT too *and* makes the (incorrect) assumption that there's no good reason to pass IPv4 addresses around except in DNS.
Note that for a *very* long time... much longer than there will be new IPv4 addresses available... there will be a whole lot of places that have good IPv4 and no IPv6. (As you note above)
I think this "*very* long time" will be much shorter than you think for meaningful values of "whole lot of places".
Should we make a short list of countries and coffee shops and go test it out in two years?
If I was Skype I would make really sure that all my relay nodes and login servers have IPv6 with enough bandwidth or can easily upgrade the bandwidth where neede. And make sure atleast IPv6-client and IPv6-servers communication works everywhere where there is IPv6. Clearly that would be needed to serve the IPv6-only users well. I think this is definitely the ideal first step, but, I confess I don't know the inner workings of Skype. Even this is probably a large effort in their codebase, so, I hope they've started working on it. For your customers it is really easy. When Skype does not work, people will jump ship where they can and maybe use Google Talk or whatever. Ah. But you're taking the bet that when Skype does not work on *your* network that provides IPv4 access via NAT64 people won't "jump ship" to a provider that uses CGN or even has enough native IPv4 addresses left around. I'm betting Skype breaks just as bad in many CGN environments and that the most likely candidate to actually work will be B4/AFTR or DS-Lite.
This is probably a correct assessment. All NAT64 will fail unless there's discovery *and* the NAT64 behaves in a useful way, some CGN environments will fail and more so as both ends end up on different CGNs, and things like DS-Lite will do fairly well. At least that's how it looks to me, based on analysis I did for a different peer-to-peer protocol and these cases.
Nor will anything else and broken IPv4 access is an apt term to describe any of: NAT64 DS-LITE/B4/AFTR CGN/LSN
True. Though you get to choose in what way it is broken in each.
They each have their own brand of broken IPv4. Let's face it, while the existing IPv4 internet isn't going to suddenly break when we run out of available addresses, it is going to slowly suffer from increased breakage as we attempt to recycle those addresses in ever more creative and unintended ways.
No question.
I'm sorry if it sounds a bit like fear mongering, but to me it sounds like common sense that if a business is not prepared when the environment that business operates in changes and that business does not adapt to the changes in time that business might suffer. But that's true of ISPs when they choose how to deal with the lack of additional IPv4 space but continued customer demand to reach the IPv4 Internet, too, isn't it?
Yep.
So which technology are you choosing? :) Matthew Kaufman
One can still do DS-lite when the provider only offers NAT64. A B4 can connect to a AFTR which can be anywhere that is reachable via IPv6. I can see small ISPs and those that can't get IPv4 addresses for themselves out sourcing the DS-lite service. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Maybe HE would volunteer to host some Skype servers at their various POPS for this purpose. Skype has to start somewhere. While the v6-only population is still very small, why not dual-stack the clients now with a heavily weighted preference towards v4, track and understand the volume and capabilities of v6, and slowly de-preference v4 over time? Frank -----Original Message----- From: Matthew Kaufman [mailto:matthew@matthew.at] Sent: Thursday, January 06, 2011 8:57 PM To: Joel Jaeggli Cc: Nanog Operators' Group Subject: Re: Problems with removing NAT from a network On 1/6/2011 6:34 PM, Joel Jaeggli wrote:
On 1/6/11 5:48 PM, Owen DeLong wrote:
Doesn't all of this become moot if Skype just develops a dual-stack capable client and servers? Really, only some fraction of the supernodes and the login servers need to be dual stack.
Without revealing too much about the architecture, I can tell you that it would need to be a significant fraction of the supernodes (due to how node-supernode mapping works in these types of P2P systems), the relay nodes (not mentioned) *and* the login servers. Not all of which are deployed and controlled by Skype, of course, as recent press about the most recent outage has reiterated for those who didn't know. Matthew Kaufman
On 1/8/11 3:22 PM, Frank Bulk wrote:
Maybe HE would volunteer to host some Skype servers at their various POPS for this purpose.
skype has the the ability to deploy supernodes on demand using their own capacity. they've demonstrated that in the face of congestive collapse, buying ipv6 transit isn't hard.
Skype has to start somewhere. While the v6-only population is still very small, why not dual-stack the clients now with a heavily weighted preference towards v4, track and understand the volume and capabilities of v6, and slowly de-preference v4 over time?
Frank
-----Original Message----- From: Matthew Kaufman [mailto:matthew@matthew.at] Sent: Thursday, January 06, 2011 8:57 PM To: Joel Jaeggli Cc: Nanog Operators' Group Subject: Re: Problems with removing NAT from a network
On 1/6/2011 6:34 PM, Joel Jaeggli wrote:
On 1/6/11 5:48 PM, Owen DeLong wrote:
Doesn't all of this become moot if Skype just develops a dual-stack capable client and servers? Really, only some fraction of the supernodes and the login servers need to be dual stack.
Without revealing too much about the architecture, I can tell you that it would need to be a significant fraction of the supernodes (due to how node-supernode mapping works in these types of P2P systems), the relay nodes (not mentioned) *and* the login servers. Not all of which are deployed and controlled by Skype, of course, as recent press about the most recent outage has reiterated for those who didn't know.
Matthew Kaufman
On 1/6/2011 5:48 PM, Owen DeLong wrote:
Doesn't all of this become moot if Skype just develops a dual-stack capable client and servers?
Not really. Imagine the case where you're on IPv6 and you can only reach IPv4 via a NAT64, and there's no progress made on the detection problem. And your family member is on a Skype-enabled TV plugged into an IPv4-only ISP. Now you can't get a direct media path between you, even though their ISP is giving them IPv4 and your ISP is *claiming* you can "still reach the IPv4 Internet". Skype can still make this work by relaying, but in order to protect the relay machine's bandwidth it will rate-limit the traffic, and so your A/V experience will suffer. And that's assuming there's enough dual-stacked relays... if there aren't, it won't be possible to find a relay that they can reach over IPv4 and you can reach over IPv6 that has available bandwidth. Matthew Kaufman
-----Original Message----- From: Matthew Kaufman [mailto:matthew@matthew.at] Sent: Thursday, January 06, 2011 6:55 PM To: Owen DeLong Cc: Nanog Operators' Group Subject: Re: Problems with removing NAT from a network
On 1/6/2011 5:48 PM, Owen DeLong wrote:
Doesn't all of this become moot if Skype just develops a dual-stack capable client and servers?
Not really. Imagine the case where you're on IPv6 and you can only reach IPv4 via a NAT64, and there's no progress made on the detection problem. And your family member is on a Skype-enabled TV plugged into an IPv4-only ISP.
Now you can't get a direct media path between you, even though their ISP is giving them IPv4 and your ISP is *claiming* you can "still reach the IPv4 Internet".
Skype can still make this work by relaying,
Skype could make it work with direct UDP packets in about 92% of cases, per Google's published direct-to-direct statistic at http://code.google.com/apis/talk/libjingle/important_concepts.html -d
but in order to protect the relay machine's bandwidth it will rate-limit the traffic, and so your A/V experience will suffer. And that's assuming there's enough dual-stacked relays... if there aren't, it won't be possible to find a relay that they can reach over IPv4 and you can reach over IPv6 that has available bandwidth.
Matthew Kaufman
On 1/6/2011 9:28 PM, Dan Wing wrote:
-----Original Message----- From: Matthew Kaufman [mailto:matthew@matthew.at] Not really. Imagine the case where you're on IPv6 and you can only reach IPv4 via a NAT64, and there's no progress made on the detection problem. And your family member is on a Skype-enabled TV plugged into an IPv4-only ISP.
Now you can't get a direct media path between you, even though their ISP is giving them IPv4 and your ISP is *claiming* you can "still reach the IPv4 Internet".
Skype can still make this work by relaying, Skype could make it work with direct UDP packets in about 92% of cases, per Google's published direct-to-direct statistic at http://code.google.com/apis/talk/libjingle/important_concepts.html
If one end is behind a NAT64 and there is no mechanism for discovering the NAT64's IPv6 interface prefix and mapping algorithm (and at present there is not), there is no way to send IPv6 IP packets from the IPv6-only host to IPv4 literal addresses (that is to say, addresses learned via a mechanism other than DNS responses synthesized by the DNS64 part of the NAT64 "solution") on the IPv4 Internet through said NAT64. That's the case we're discussing here. It breaks Skype, Adobe's RTMFP, BitTorrent, ICE-based NAT traversal, etc. Even the protocol described in the referenced document, Jingle (as it essentially uses ICE) fails. The candidate IPv4 addresses for the end that's on the IPv4 Internet (local and STUN-derived) that are delivered over Jingle's XMPP path cannot be used by the host that is on IPv6 + NAT64 to reach the IPv4 Internet because it has no IPv4 sockets available to it and even if it knew that NAT64 existed (which would take a modification to the Jingle-based apps) and opened an IPv6 socket it wouldn't know what IPv6 address to use to reach the IPv4 host because there's no discovery mechanism. If you want we can take this back to the BEHAVE list now. Matthew Kaufman
On Thu, 6 Jan 2011, Matthew Kaufman wrote:
If one end is behind a NAT64 and there is no mechanism for discovering the NAT64's IPv6 interface prefix and mapping algorithm (and at present there is not), there is no way to send IPv6 IP packets from the IPv6-only host to IPv4 literal addresses (that is to say, addresses learned via a mechanism other than DNS responses synthesized by the DNS64 part of the NAT64 "solution") on the IPv4 Internet through said NAT64.
There has been discussions on v6ops mailinglist about BIH (Bump In Host) for mobile applications, so that one could create a client on the machine behind NAT64 and make it work work with programs that use v4 literals (or have no v6 support at all). It though seems there is considerable resistance within the IETF community against such solutions as (I've been told) history has shown there to be a lot of problems with this kind of double translation. Therefore the IETF seems to lean towards tunneling of IPv4 over IPv6 to give such a host literal IPv4 connextivity (could be called 4RD) instead of doing translation. For mobile applications, single stack on the access is to only realistic method in the next few years, therefore this needs to be solved somehow. 3GPP doesn't like tunnels though (since they already do tunneling), so right now there isn't really broad agreement on how to solve this. Personally I think we need some kind of transitioning mechanism to handle v4 only applications and v4 literals in the forseeable future, just like we needed trumped winsock in the 90ties, we're going to need full v4 connectivity for Windows XP (applications + dns transport) over v6only access. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Jan 7, 2011, at 12:39 AM, Matthew Kaufman wrote:
On 1/6/2011 9:28 PM, Dan Wing wrote:
Skype could make it work with direct UDP packets in about 92% of cases, per Google's published direct-to-direct statistic at http://code.google.com/apis/talk/libjingle/important_concepts.html
If one end is behind a NAT64 and there is no mechanism for discovering the NAT64's IPv6 interface prefix and mapping algorithm (and at present there is not), there is no way to send IPv6 IP packets from the IPv6-only host to IPv4 literal addresses (that is to say, addresses learned via a mechanism other than DNS responses synthesized by the DNS64 part of the NAT64 "solution") on the IPv4 Internet through said NAT64.
That's the case we're discussing here.
It breaks Skype, Adobe's RTMFP, BitTorrent, ICE-based NAT traversal, etc. Even the protocol described in the referenced document, Jingle (as it essentially uses ICE) fails. The candidate IPv4 addresses for the end that's on the IPv4 Internet (local and STUN-derived) that are delivered over Jingle's XMPP path cannot be used by the host that is on IPv6 + NAT64 to reach the IPv4 Internet because it has no IPv4 sockets available to it and even if it knew that NAT64 existed (which would take a modification to the Jingle-based apps) and opened an IPv6 socket it wouldn't know what IPv6 address to use to reach the IPv4 host because there's no discovery mechanism. If you want we can take this back to the BEHAVE list now.
To paraphrase what you're saying: stuff that embeds and passes around IPv4 addresses will break. I'm sorry to say this, but that's just reality. Embedded IP addresses has always been a Bad Idea (tm) in development and operations, and I don't think P2P protocols get a pass - building your own discovery and topology mechanisms don't insulate you from having to use the underlying network. The best chance anybody has, is to build dual-stack support and start using DNS names rather than IP numbers. Oh, and expect IPv4 to start breaking in the near future. We're trying to make IPv4 work long enough to survive the transition, but it's not a good bet for new protocols. Cheers, -Benson
On Jan 6, 2011, at 11:49 PM, Benson Schliesser wrote:
On Jan 7, 2011, at 12:39 AM, Matthew Kaufman wrote:
On 1/6/2011 9:28 PM, Dan Wing wrote:
Skype could make it work with direct UDP packets in about 92% of cases, per Google's published direct-to-direct statistic at http://code.google.com/apis/talk/libjingle/important_concepts.html
If one end is behind a NAT64 and there is no mechanism for discovering the NAT64's IPv6 interface prefix and mapping algorithm (and at present there is not), there is no way to send IPv6 IP packets from the IPv6-only host to IPv4 literal addresses (that is to say, addresses learned via a mechanism other than DNS responses synthesized by the DNS64 part of the NAT64 "solution") on the IPv4 Internet through said NAT64.
That's the case we're discussing here.
It breaks Skype, Adobe's RTMFP, BitTorrent, ICE-based NAT traversal, etc. Even the protocol described in the referenced document, Jingle (as it essentially uses ICE) fails. The candidate IPv4 addresses for the end that's on the IPv4 Internet (local and STUN-derived) that are delivered over Jingle's XMPP path cannot be used by the host that is on IPv6 + NAT64 to reach the IPv4 Internet because it has no IPv4 sockets available to it and even if it knew that NAT64 existed (which would take a modification to the Jingle-based apps) and opened an IPv6 socket it wouldn't know what IPv6 address to use to reach the IPv4 host because there's no discovery mechanism. If you want we can take this back to the BEHAVE list now.
To paraphrase what you're saying: stuff that embeds and passes around IPv4 addresses will break. I'm sorry to say this, but that's just reality. Embedded IP addresses has always been a Bad Idea (tm) in development and operations, and I don't think P2P protocols get a pass - building your own discovery and topology mechanisms don't insulate you from having to use the underlying network.
No, it hasn't always been a Bad Idea. It has been an idea fraught with peril since the deployment of overloaded NAT in IPv4. Fortunately, overloaded NAT will hopefully be a thing of the past in IPv6 and we may get a chance to return to a more functional end-to-end model of networking again.
The best chance anybody has, is to build dual-stack support and start using DNS names rather than IP numbers. Oh, and expect IPv4 to start breaking in the near future. We're trying to make IPv4 work long enough to survive the transition, but it's not a good bet for new protocols.
On this, at least we agree. Owen
On Jan 7, 2011, at 4:02 PM, Owen DeLong wrote:
No, it hasn't always been a Bad Idea.
Yes, it has. There're lots of issues with embedding IP addresses directly into apps and so forth which have nothing to do with NAT. ------------------------------------------------------------------------ Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
On 1/7/2011 4:44 AM, Dobbins, Roland wrote:
Yes, it has. There're lots of issues with embedding IP addresses directly into apps and so forth which have nothing to do with NAT.
Embedding into apps isn't the same as embedding into protocol packets. While NAT and stateful firewalls do tend to break with embedded addresses that they don't know to check for, it's still not a bad idea. I was fixing to complain that the IPv6 designers didn't take the chance to add the embedding to the Packet headers, when it occurs to me, they made the headers nice and extensible. It also baffles me as to why applications such as skype dealing with NAT64 can't use the compatibility addressing to start communicating with v4 hosts from a v6 only NIC. I thought this was already a fixed problem not requiring DNS to deal with. It's not like NAT46 (anyone actually publish such a hideous protocol?), which requires really messy state tables bidirectionally for everything and DNS rewrites. Jack
On Jan 7, 2011, at 6:32 AM, Jack Bates wrote:
On 1/7/2011 4:44 AM, Dobbins, Roland wrote:
Yes, it has. There're lots of issues with embedding IP addresses directly into apps and so forth which have nothing to do with NAT.
Embedding into apps isn't the same as embedding into protocol packets. While NAT and stateful firewalls do tend to break with embedded addresses that they don't know to check for, it's still not a bad idea. I was fixing to complain that the IPv6 designers didn't take the chance to add the embedding to the Packet headers, when it occurs to me, they made the headers nice and extensible.
It also baffles me as to why applications such as skype dealing with NAT64 can't use the compatibility addressing to start communicating with v4 hosts from a v6 only NIC. I thought this was already a fixed problem not requiring DNS to deal with. It's not like NAT46 (anyone actually publish such a hideous protocol?), which requires really messy state tables bidirectionally for everything and DNS rewrites.
Jack
Compatibility addresses don't work on the wire. They're not supposed to. It's a huge problem if they do. Compatibility addresses allow you to write an IPv6 application, run it on a dual-stacked host and talk to the IPv4 and IPv6 remote systems as if all of them are IPv6 hosts. The IPv4 hosts appear to come from the IPv6 range ::ffff:ip:v4 which is often presented to the user as ::ffff:i.p.v.4 . Hope that clarifies things. Owen
On Jan 7, 2011, at 5:44 AM, Dobbins, Roland wrote:
On Jan 7, 2011, at 4:02 PM, Owen DeLong wrote:
No, it hasn't always been a Bad Idea.
Yes, it has. There're lots of issues with embedding IP addresses directly into apps and so forth which have nothing to do with NAT.
Let me know when the products from Arbor no longer require this. Thanks. - Jared
-----Original Message----- From: Matthew Kaufman [mailto:matthew@matthew.at] Not really. Imagine the case where you're on IPv6 and you can only reach IPv4 via a NAT64, and there's no progress made on the detection problem. And your family member is on a Skype-enabled TV plugged into an IPv4-only ISP.
Now you can't get a direct media path between you, even though their ISP is giving them IPv4 and your ISP is *claiming* you can "still reach
On 1/6/2011 9:28 PM, Dan Wing wrote: the
IPv4 Internet".
Skype can still make this work by relaying, Skype could make it work with direct UDP packets in about 92% of cases, per Google's published direct-to-direct statistic at http://code.google.com/apis/talk/libjingle/important_concepts.html
If one end is behind a NAT64 and there is no mechanism for discovering the NAT64's IPv6 interface prefix and mapping algorithm (and at present there is not), there is no way to send IPv6 IP packets from the IPv6-only host to IPv4 literal addresses (that is to say, addresses learned via a mechanism other than DNS responses synthesized by the DNS64 part of the NAT64 "solution") on the IPv4 Internet through said NAT64.
That's the case we're discussing here.
There are a bunch of ideas for how to accomplish that. Several of the ideas don't require any support by the network infrastructure, draft-korhonen-behave-nat64-learn-analysis.
It breaks Skype, Adobe's RTMFP, BitTorrent, ICE-based NAT traversal, etc. Even the protocol described in the referenced document, Jingle (as it essentially uses ICE) fails. The candidate IPv4 addresses for the end that's on the IPv4 Internet (local and STUN-derived) that are delivered over Jingle's XMPP path cannot be used by the host that is on IPv6 + NAT64 to reach the IPv4 Internet because it has no IPv4 sockets available to it and even if it knew that NAT64 existed (which would take a modification to the Jingle-based apps) and opened an IPv6 socket it wouldn't know what IPv6 address to use to reach the IPv4 host because there's no discovery mechanism. If you want we can take this back to the BEHAVE list now.
Sure. -d
Matthew Kaufman
On 1/7/2011 12:39 AM, Matthew Kaufman wrote:
If one end is behind a NAT64 and there is no mechanism for discovering the NAT64's IPv6 interface prefix and mapping algorithm (and at present there is not), there is no way to send IPv6 IP packets from the IPv6-only host to IPv4 literal addresses (that is to say, addresses learned via a mechanism other than DNS responses synthesized by the DNS64 part of the NAT64 "solution") on the IPv4 Internet through said NAT64.
While a rather inelegant solution, it just popped into my head that one could do an AAAA query for a known-value A record (i.e., under skype.com), and based on a response (if any), replace the known IP value with the IP which with one wants to connect. A little weird, but it's a thought. Jima
On 1/8/2011 5:20 PM, Jima wrote:
On 1/7/2011 12:39 AM, Matthew Kaufman wrote:
If one end is behind a NAT64 and there is no mechanism for discovering the NAT64's IPv6 interface prefix and mapping algorithm (and at present there is not), there is no way to send IPv6 IP packets from the IPv6-only host to IPv4 literal addresses (that is to say, addresses learned via a mechanism other than DNS responses synthesized by the DNS64 part of the NAT64 "solution") on the IPv4 Internet through said NAT64.
While a rather inelegant solution, it just popped into my head that one could do an AAAA query for a known-value A record (i.e., under skype.com), and based on a response (if any), replace the known IP value with the IP which with one wants to connect. A little weird, but it's a thought.
Jima
That's one of the proposed solutions on the list of discovery technologies, IIRC. Matthew Kaufman
Relay nodes are always protecting themselves by rate-limiting, aren't they? And isn't most media traffic relayed? I'm not seeing how the NAT64 scenario would *dramatically* increase Skype's global relay traffic. NAT64 would currently be a very small percentage of all Skype traffic. We can always find examples of where things will break with v6. While the v6-only world is still very small, let's *start* somewhere, where intelligent clients like Skype can always "fall back" to v4. Lots of time to figure out the corner cases. Frank -----Original Message----- From: Matthew Kaufman [mailto:matthew@matthew.at] Sent: Thursday, January 06, 2011 8:55 PM To: Owen DeLong Cc: Nanog Operators' Group Subject: Re: Problems with removing NAT from a network On 1/6/2011 5:48 PM, Owen DeLong wrote:
Doesn't all of this become moot if Skype just develops a dual-stack capable client and servers?
<snip> Skype can still make this work by relaying, but in order to protect the relay machine's bandwidth it will rate-limit the traffic, and so your A/V experience will suffer. And that's assuming there's enough dual-stacked relays... if there aren't, it won't be possible to find a relay that they can reach over IPv4 and you can reach over IPv6 that has available bandwidth. Matthew Kaufman
Relay nodes are always protecting themselves by rate-limiting, aren't they? Yes. And isn't most media traffic relayed? No, not at all. Almost all media traffic goes directly end-to-end by using really good NAT traversal. I'm not seeing how the NAT64 scenario would *dramatically* increase Skype's global relay traffic. NAT64 would currently be a very small percentage of all Skype traffic. The relay issue isn't about that. If you can't discover the NAT64 and you can't discover the mapping algorithm, then you can't use IPv4
On 1/8/2011 3:22 PM, Frank Bulk wrote: literal addresses. If you can and the application is changed to use the discovery mechanism, then the traffic flows through the NAT64 and relay nodes aren't an issue. But if you can't then the only way for a future IPv6-enabled Skype client that has IPv6 + NAT64 to (not) reach the IPv4 Internet can talk to another Skype client that has IPv4 only would be to go through the relay node. That means that people who are on ISPs that use native IPv4 dual-stack, and people who are on ISPs that use CGN NAT44 to dual-stack both get the direct end-to-end experience when calling IPv4-only clients... but people who are on ISPs that use NAT64 instead of dual-stack end up having to go through (rate limited) relays to call IPv4-only clients. That means they'd have an excellent reason to choose an ISP that uses a different technology. Which they'll need to do to make their BitTorrent and everything else that uses IPv4 literals work anyway.
We can always find examples of where things will break with v6. While the v6-only world is still very small, let's *start* somewhere, where intelligent clients like Skype can always "fall back" to v4. Lots of time to figure out the corner cases. The point is that NAT64 creates a huge additional set of corner cases (all of the cases where IPv4 literal addresses are transported by anything other than DNS lookups) that none of the other transition choices do. (NAT64 has all the problems of CGN *plus* this issue, for instance.)
Matthew Kaufman
On Sat, Jan 8, 2011 at 10:55 PM, Matthew Kaufman <matthew@matthew.at> wrote:
On 1/8/2011 3:22 PM, Frank Bulk wrote:
Relay nodes are always protecting themselves by rate-limiting, aren't they?
Yes.
And isn't most media traffic relayed?
No, not at all. Almost all media traffic goes directly end-to-end by using really good NAT traversal.
I'm not seeing how the NAT64 scenario would *dramatically* increase Skype's global relay traffic. NAT64 would currently be a very small percentage of all Skype traffic.
The relay issue isn't about that. If you can't discover the NAT64 and you can't discover the mapping algorithm, then you can't use IPv4 literal addresses. If you can and the application is changed to use the discovery mechanism, then the traffic flows through the NAT64 and relay nodes aren't an issue.
But if you can't then the only way for a future IPv6-enabled Skype client that has IPv6 + NAT64 to (not) reach the IPv4 Internet can talk to another Skype client that has IPv4 only would be to go through the relay node.
That means that people who are on ISPs that use native IPv4 dual-stack, and people who are on ISPs that use CGN NAT44 to dual-stack both get the direct end-to-end experience when calling IPv4-only clients... but people who are on ISPs that use NAT64 instead of dual-stack end up having to go through (rate limited) relays to call IPv4-only clients.
That means they'd have an excellent reason to choose an ISP that uses a different technology. Which they'll need to do to make their BitTorrent and everything else that uses IPv4 literals work anyway.
We can always find examples of where things will break with v6. While the v6-only world is still very small, let's *start* somewhere, where intelligent clients like Skype can always "fall back" to v4. Lots of time to figure out the corner cases.
The point is that NAT64 creates a huge additional set of corner cases (all of the cases where IPv4 literal addresses are transported by anything other than DNS lookups) that none of the other transition choices do. (NAT64 has all the problems of CGN *plus* this issue, for instance.)
1. The companies that have selected NAT64 as a tool for rolling out IPv6 to address the IPv4 exhaustion business risk are aware of the various application trade offs. They select NAT64 because it makes business sense to aggressively go after IPv6 as the end-state and not provide patches and work-arounds in their network to make dual-stack work, which is not an end-state, it is a transition mechanism on the path to ipv6. Also, as i mentioned for mobile, dual-stack is MUCH more expensive. And ipv6-only works for the vast majority of my user and my traffic. 2. You can pass this FUD around about people leaving networks so that skype and bittorrent work. Last time i checked, many mobile network operators and handsets only begrudgingly supported skype and bittorent if at all. In fact, many networks spend considerable time and money to stop them. I also know that Skype has some mobile partners. I am not here to say if this is right or wrong, but i do not expect network providers to alter their ipv6 strategy of business decisions to accommodate Skype and Bittorrent. These applications have shown amazing resiliency over the years to bust through firewalls and NATs, and i am really amazed at how much opposition Skype is providing to the IPv6 transition. I imagine Skype would have a better hand if Skype was IPv6 enabled a long time ago and pushing dual-stack and waiting on the carriers, but Skype is IPv4-only just like all the rest of the slow moving world. If dual-stack had worked, we would not be here talking about NAT64. But, dual-stack did not work. We are out of IPv4 and the network still has to grow, hence IPv6-only + NAT64. And again, dual-stack is much more expensive in mobile networks than single stack so it won't happen with the Ipv4 side being endless duplication of RFC 1918 and bogon space. 3. I am just here to create awareness of this technology that the IETF as the protocol standardizer and the 3GPP as the mobile architecture standardizer have accepted and are moving forward. I want all applications to work with IPv6 and NAT64. In every email i have sent on this topic and off-list to Matthew, i have made the call to action to support ipv6 and to work together. From the network side, i am willing partner. But, not supporting IPv6 is not an option in my mind. That is where Skype stands today. IPv4 is really not a strategic path for any network, especially a mobile network that has a large and growing edge. There are several ways to work through making NAT64 work, as Matthew has acknowledge, and even hinted at having a better proprietary way. I am open to new ways and new partnerships to make this work. When you are ready to talk about moving forward, i am all ears. Until then, you can keep posturing while the clock ticks on committed deployments. If you know it's coming and don't have a solution, if you strategically choose to play that game of chicken, thats fine too, it's a calculated risk that my business has made. Cameron
Matthew Kaufman
On 1/9/2011 6:42 AM, Cameron Byrne wrote:
1. The companies that have selected NAT64 as a tool for rolling out IPv6 to address the IPv4 exhaustion business risk are aware of the various application trade offs. They select NAT64 because it makes business sense to aggressively go after IPv6 as the end-state and not provide patches and work-arounds in their network to make dual-stack work, which is not an end-state, it is a transition mechanism on the path to ipv6. Also, as i mentioned for mobile, dual-stack is MUCH more expensive. And ipv6-only works for the vast majority of my user and my traffic.
2. You can pass this FUD around about people leaving networks so that skype and bittorrent work. Last time i checked, many mobile network operators and handsets only begrudgingly supported skype and bittorent if at all. In fact, many networks spend considerable time and money to stop them. I also know that Skype has some mobile partners. I am not here to say if this is right or wrong, but i do not expect network providers to alter their ipv6 strategy of business decisions to accommodate Skype and Bittorrent. These applications have shown amazing resiliency over the years to bust through firewalls and NATs, and i am really amazed at how much opposition Skype is providing to the IPv6 transition. Note that while I do work for Skype at the present time, I am not representing Skype or its business plans when I post here from my
As long as your customers are aware that they are getting full IPv6 and a particularly crippled form of IPv4, then that's fine. But NAT64 isn't a solution for providing actual IPv4 connectivity to your customers.... just a poor simulation of it. personal email account. Please do not take my statements here as "opposition from Skype" with regard to the IPv6 transition. And yes, the mobile environment is likely a special case at this time... but one would hope that in the long term we didn't have mobile providers that were "spending considerable time and money" to stop applications that work on the non-mobile Internet.
I imagine Skype would have a better hand if Skype was IPv6 enabled a long time ago and pushing dual-stack and waiting on the carriers, but Skype is IPv4-only just like all the rest of the slow moving world. Agreed. Skype should (and again note that this is my personal opinion) have much better IPv6 support for use when both endpoints can speak IPv6. A situation that is presently rare. If dual-stack had worked, we would not be here talking about NAT64. But, dual-stack did not work. We are out of IPv4 and the network still has to grow, hence IPv6-only + NAT64. Or any number of other transition choices. You've just chosen one that has a particular weakness. And again, dual-stack is much more expensive in mobile networks than single stack so it won't happen with the Ipv4 side being endless duplication of RFC 1918 and bogon space.
Business needs often outweigh what would be technically superior.
3. I am just here to create awareness of this technology that the IETF as the protocol standardizer and the 3GPP as the mobile architecture standardizer have accepted and are moving forward. I want all applications to work with IPv6 and NAT64.
For that to happen there needs to be, at a minimum, a way for applications to discover that they are in a NAT64 environment and work with it even if they do not use DNS to exchange addresses. And as I said before, *that* discussion probably belongs back on the BEHAVE list where, for whatever reason, it is hibernating.
When you are ready to talk about moving forward, i am all ears. Until then, you can keep posturing while the clock ticks on committed deployments.
See above. Lets get the discovery problem back on top. Matthew Kaufman
In message <AANLkTinXp-C96rdb2+06v1kqwFdiehy6_2=ohOOm86Tx@mail.gmail.com>, Came ron Byrne writes:
On Wed, Jan 5, 2011 at 8:31 PM, Mark Andrews <marka@isc.org> wrote:
In message <AANLkTimkgPYKY_AkA5px4-ca-3=oufhGbnenRkPmpTE1@mail.gmail.co=
m>, Came
ron Byrne writes:
On Wed, Jan 5, 2011 at 6:42 PM, Dobbins, Roland <rdobbins@arbor.net> wro= te:
On Jan 6, 2011, at 9:38 AM, ML wrote:
At least not without some painful rebuilds of criticals systems which=
ha= ve these IPs deeply embedded in their configs.
They shouldn't be using IP addresses in configs, they should be using =
DNS= names. Time to bite the bullet and get this fixed prior to their= eventu= al forced migration to IPv6.
Somebody should tell the nytimes.com about this being a bad practice, many of their images are linked to ip addresses directly and will certainly fail in the future (this year, mobile) networks that will use NAT64/DNS64. I am sure users will find other places to view their news when nytimes.com fails to work in these ipv6-only networks.
Which is one of the reasons why DS-lite is a better solution for providing legacy access to the IPv4 Internet than NAT64/DNS64. DS-lite only breaks what NAT44 breaks. DS-lite doesn't break new things.
Thanks for the tip. But, there are legitimate business reason in various different types of networks for various strategies,
Indeed. I just which DS-lite was thought of about the same time as NATPT was. That way network operators would have the code in things like cell phones today rather than the next gen resulting in them being forced to use NAT64 and with that all the additional problems it causes. The network operator is going to be running a big/distributed NAT box of one description or another to share the available IPv4 addresses. It just a matter of which packets its processing. The end choice may come down to which DHCP options the client requests or doesn't. i.e. return DNS64 nameservers if the client doesn't request the DS-lite configuration parameters.
thanks for plugging the one your organization makes.
We also ship a DNS64 implementation.
I am tired of the IPv6 transition flavor of the day war. The reality for content folks is that there will be IPv4 host, IPv6 hosts, and dual stack hosts. Content needs to be dual-stack to reach everyone the best way (native), but if they lack dual-stack and they use IPv4 literals, they are going to lose eyeballs. End of story.
Agreed they will loose eyeballs. HTTP and IPv4 literals is one of the easier problems to be mitigated. Its the rest of the places where IPv4 addresses are passed that causes problems.
Content folks-- do yourself a favor and follow Roland's advice (also in RFC 1958) and don't use address literals, use names.
And, you will notice that the list at http://groups.google.com/group/ipv4literals shows only a few web site, because there are only a few that have this design flaws. If you know others, strengthen your case and add them to the list so that all parties can benefit. Otherwise, it is just a few poorly designed internet services that will be in a rush to fix services when users complain.... or there web pages hits start trending down while their competitors trend up.
Cameron -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Jan 5, 2011, at 10:31 PM, Mark Andrews wrote:
Which is one of the reasons why DS-lite is a better solution for providing legacy access to the IPv4 Internet than NAT64/DNS64. DS-lite only breaks what NAT44 breaks. DS-lite doesn't break new things.
Or just run a dual-stack network, with centralized NAT44, and avoid the headache of tunneling. If you're going to run two protocol families on the end host, and deal with the issues that causes, why require tunneling to make it work? Is it so hard to forward IPv4 packets natively? Cheers, -Benson
The devil's in the details (obviously), and someone that reads into the scenario better than me might have a more direct suggestion, but... I'd start by moving the NAT at least one hop into the AS so that routing symmetry can be enforced there. This allows for multi-homing (asymmetric routing at the edge) without (before) dealing with the NAT issue (if there is one at that point). On Jan 5, 2011 9:39 PM, "ML" <ml@kenweb.org> wrote: I've got a customer that is looking to multihome with upstreams in two POPs. Currently they multihome in one POP and utilize a single edge router for some one to one NAT and some PAT for their users. Before they turn up the BGP peer in the new POP I've advised them to abolish NAT once and for all in order to avoid issues with non-stateful NAT between network edges and possible asymmetric routing of their Internet traffic. The PAT can be removed easily enough. The tricky part is the one-one NAT. They have quite a few systems which have 1918 IPs which they claim "cannot be changed". At least not without some painful rebuilds of criticals systems which have these IPs deeply embedded in their configs. Has anyone here had to fix this kind of problem before? Is there a solution that would allow NAT to offloaded to a smaller device hanging off each edge router that can communicate state between each other in case traffic is asymmetrically routed?
You didn't mention, but are you introducing a second border router? Is the new upstream circuit from a new provider, or is it a second, redundant circuit to the same provider in a different POP? Does your customer have their own portable address space, or are they using provider address space? I'll make some presumptions: yes, it is a different provider, and no, they don't have their own address space. Based on those guesses/presumptions, I'd push to acquire portable address space. Advertise it to both providers, carve a chunk of that address space off and route it to a firewall(s) to perform border NAT. Migrate old, provider dependent external NAT space to new, portable address space. -M On Wed, Jan 5, 2011 at 6:38 PM, ML <ml@kenweb.org> wrote:
I've got a customer that is looking to multihome with upstreams in two POPs. Currently they multihome in one POP and utilize a single edge router for some one to one NAT and some PAT for their users.
Before they turn up the BGP peer in the new POP I've advised them to abolish NAT once and for all in order to avoid issues with non-stateful NAT between network edges and possible asymmetric routing of their Internet traffic.
The PAT can be removed easily enough. The tricky part is the one-one NAT. They have quite a few systems which have 1918 IPs which they claim "cannot be changed". At least not without some painful rebuilds of criticals systems which have these IPs deeply embedded in their configs.
Has anyone here had to fix this kind of problem before? Is there a solution that would allow NAT to offloaded to a smaller device hanging off each edge router that can communicate state between each other in case traffic is asymmetrically routed?
participants (18)
-
Benson Schliesser -
Cameron Byrne -
Dan Wing -
Dobbins, Roland -
Frank Bulk -
Jack Bates -
Jared Mauch -
Jima -
Joel Jaeggli -
Leen Besselink -
Mark Andrews -
Matt Hite -
Matthew Kaufman -
Michael Smith -
Mikael Abrahamsson -
ML -
Owen DeLong -
Steven Bellovin