Hello, Some people were talking about Large Scale NATs (LSN) or Carrier Grade NATs (CGN) yesterday. Comments included that DS-Lite and NAT64 are basically LSNs and they suffer from all the same problems. I don't think that NAT64 is as bad as other LSNs and here's why: NAT64 scales much better than NAT44 and NAT444(*) The trick is with its companion DNS64. If you need more NAT64 capacity, you can just add more NAT64 boxes with unique /96 prefixes around your network and have your DNS64 load-balance traffic to those boxes. You can also map one A record into two AAAA records of different NAT64 boxes, in case that works better with some application protocols. The smallest granularity of load-balancing easily available with NAT444 is per customer or per customer group. DNS64 allows per flow granularity for load-balancing without even breaking a sweat. I've been testing NAT64 at home using a public NAT64 trial and generally I've been very happy with it: http://www.trex.fi/2011/dns64.html A neat feature I've liked is that I don't have to pass all my traffic via the NAT64 box, and so it doesn't have to be between me and the Internet. NAT44 usually acts as a fuse between me and my Internet. The biggest downsides I've encountered are: I. Some streaming websites use IP addresses in their video stream URLs, so DNS64 doesn't get asked and that traffic won't flow via NAT64. Thankfully these are a minority. II. Networked games usually use some sort of a tracker to help clients find games to connect to, and those only use plain IP addresses too. And some games only query for A records, and thus can't benefit from DNS64 either. So I guess the optimal way to stretch the lifetime of IPv4 while still moving toward IPv6 all the time would be to dual-stack customers and deploy both NAT64/DNS64 and some other LSN which can handle the two downsides above. All the traffic that you can shift to NAT64 means that your other LSN (which doesn't scale as well) can handle that much more traffic before becoming a bottleneck. And naturally, you'll want to shift all that youtube/facebook/whatever traffic to native IPv6 to help both NAT boxes cope. My 2 cents delivered, -- Aleksi Suhonen () ascii ribbon campaign /\ support plain text e-mail (*) NAT44 means the normal NAT from private IPv4 addresses to public IPv4 addresses. NAT444 means that there are two layers of NAT boxes: usually one at customer premises and the other at the ISP, doing LSN.
In message <4DF053AA.50400@axu.tm>, Aleksi Suhonen writes:
Hello,
Some people were talking about Large Scale NATs (LSN) or Carrier Grade NATs (CGN) yesterday. Comments included that DS-Lite and NAT64 are basically LSNs and they suffer from all the same problems. I don't think that NAT64 is as bad as other LSNs and here's why:
NAT64 scales much better than NAT44 and NAT444(*)
The trick is with its companion DNS64. If you need more NAT64 capacity, you can just add more NAT64 boxes with unique /96 prefixes around your network and have your DNS64 load-balance traffic to those boxes. You can also map one A record into two AAAA records of different NAT64 boxes, in case that works better with some application protocols.
You can add more capacity with DS-Lite as well though it does take a while for the DHCP option to be refreshed without push support.
The smallest granularity of load-balancing easily available with NAT444 is per customer or per customer group. DNS64 allows per flow granularity for load-balancing without even breaking a sweat.
I've been testing NAT64 at home using a public NAT64 trial and generally I've been very happy with it:
http://www.trex.fi/2011/dns64.html
A neat feature I've liked is that I don't have to pass all my traffic via the NAT64 box, and so it doesn't have to be between me and the Internet. NAT44 usually acts as a fuse between me and my Internet.
You don't have to pass all the traffic through the AFTR box or the LSN when dual stacked either. The AFTR box can be on the other side of the world or out sourced if you want it to be. The same can be done with NAT64.
The biggest downsides I've encountered are:
I. Some streaming websites use IP addresses in their video stream URLs, so DNS64 doesn't get asked and that traffic won't flow via NAT64. Thankfully these are a minority.
Not a problem with DS-Lite or NAT444.
II. Networked games usually use some sort of a tracker to help clients find games to connect to, and those only use plain IP addresses too. And some games only query for A records, and thus can't benefit from DNS64 either.
Not a problem with DS-Lite or NAT444
So I guess the optimal way to stretch the lifetime of IPv4 while still moving toward IPv6 all the time would be to dual-stack customers and deploy both NAT64/DNS64 and some other LSN which can handle the two downsides above. All the traffic that you can shift to NAT64 means that your other LSN (which doesn't scale as well) can handle that much more traffic before becoming a bottleneck. And naturally, you'll want to shift all that youtube/facebook/whatever traffic to native IPv6 to help both NAT boxes cope.
My 2 cents delivered,
-- Aleksi Suhonen
() ascii ribbon campaign /\ support plain text e-mail
(*) NAT44 means the normal NAT from private IPv4 addresses to public IPv4 addresses. NAT444 means that there are two layers of NAT boxes: usually one at customer premises and the other at the ISP, doing LSN.
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Jun 9, 2011 1:32 AM, "Mark Andrews" <marka@isc.org> wrote:
In message <4DF053AA.50400@axu.tm>, Aleksi Suhonen writes:
Hello,
Some people were talking about Large Scale NATs (LSN) or Carrier Grade NATs (CGN) yesterday. Comments included that DS-Lite and NAT64 are basically LSNs and they suffer from all the same problems. I don't think that NAT64 is as bad as other LSNs and here's why:
NAT64 scales much better than NAT44 and NAT444(*)
The trick is with its companion DNS64. If you need more NAT64 capacity, you can just add more NAT64 boxes with unique /96 prefixes around your network and have your DNS64 load-balance traffic to those boxes. You can also map one A record into two AAAA records of different NAT64 boxes, in case that works better with some application protocols.
You can add more capacity with DS-Lite as well though it does take a while for the DHCP option to be refreshed without push support.
The smallest granularity of load-balancing easily available with NAT444 is per customer or per customer group. DNS64 allows per flow granularity for load-balancing without even breaking a sweat.
I've been testing NAT64 at home using a public NAT64 trial and generally I've been very happy with it:
http://www.trex.fi/2011/dns64.html
A neat feature I've liked is that I don't have to pass all my traffic via the NAT64 box, and so it doesn't have to be between me and the Internet. NAT44 usually acts as a fuse between me and my Internet.
You don't have to pass all the traffic through the AFTR box or the LSN when dual stacked either. The AFTR box can be on the other side of the world or out sourced if you want it to be. The same can be done with NAT64.
The biggest downsides I've encountered are:
I. Some streaming websites use IP addresses in their video stream URLs, so DNS64 doesn't get asked and that traffic won't flow via NAT64. Thankfully these are a minority.
Not a problem with DS-Lite or NAT444.
II. Networked games usually use some sort of a tracker to help clients find games to connect to, and those only use plain IP addresses too. And some games only query for A records, and thus can't benefit from DNS64 either.
Not a problem with DS-Lite or NAT444
So I guess the optimal way to stretch the lifetime of IPv4 while still moving toward IPv6 all the time would be to dual-stack customers and deploy both NAT64/DNS64 and some other LSN which can handle the two downsides above. All the traffic that you can shift to NAT64 means that your other LSN (which doesn't scale as well) can handle that much more traffic before becoming a bottleneck. And naturally, you'll want to shift all that youtube/facebook/whatever traffic to native IPv6 to help both NAT boxes cope.
My 2 cents delivered,
-- Aleksi Suhonen
() ascii ribbon campaign /\ support plain text e-mail
(*) NAT44 means the normal NAT from private IPv4 addresses to public IPv4 addresses. NAT444 means that there are two layers of NAT boxes: usually one at customer premises and the other at the ISP, doing LSN.
All good and accurate info. I would just restate that nat64 unlike nat444 does not need to be "on path", this is what drives its improved scaling over nat444. Also, unlike ds-lite, nat64 works without any special client, such as the b4 function in the ds-lite architecture. Any fully functional ipv6 system such as win7 can work out of the box (ipv4 only apps being the exception) Finally, ds-lite and nat444 are just crutches for ipv4. Nat64 pushes ipv6 by making ipv6 end to end and forcing applications to be AF agnostic .... as where the others enable ipv4 without any backpressure. Each solution fits well for some set of constraints and objectives Cb
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Thu, Jun 9, 2011 at 10:39 AM, Cameron Byrne <cb.list6@gmail.com> wrote:
On Jun 9, 2011 1:32 AM, "Mark Andrews" <marka@isc.org> wrote:
In message <4DF053AA.50400@axu.tm>, Aleksi Suhonen writes:
Hello,
Some people were talking about Large Scale NATs (LSN) or Carrier Grade NATs (CGN) yesterday. Comments included that DS-Lite and NAT64 are basically LSNs and they suffer from all the same problems. I don't think that NAT64 is as bad as other LSNs and here's why:
NAT64 scales much better than NAT44 and NAT444(*)
The trick is with its companion DNS64. If you need more NAT64 capacity, you can just add more NAT64 boxes with unique /96 prefixes around your network and have your DNS64 load-balance traffic to those boxes. You can also map one A record into two AAAA records of different NAT64 boxes, in case that works better with some application protocols.
You can add more capacity with DS-Lite as well though it does take a while for the DHCP option to be refreshed without push support.
The smallest granularity of load-balancing easily available with NAT444 is per customer or per customer group. DNS64 allows per flow granularity for load-balancing without even breaking a sweat.
I've been testing NAT64 at home using a public NAT64 trial and generally I've been very happy with it:
http://www.trex.fi/2011/dns64.html
A neat feature I've liked is that I don't have to pass all my traffic via the NAT64 box, and so it doesn't have to be between me and the Internet. NAT44 usually acts as a fuse between me and my Internet.
You don't have to pass all the traffic through the AFTR box or the LSN when dual stacked either. The AFTR box can be on the other side of the world or out sourced if you want it to be. The same can be done with NAT64.
The biggest downsides I've encountered are:
I. Some streaming websites use IP addresses in their video stream URLs, so DNS64 doesn't get asked and that traffic won't flow via NAT64. Thankfully these are a minority.
Not a problem with DS-Lite or NAT444.
II. Networked games usually use some sort of a tracker to help clients find games to connect to, and those only use plain IP addresses too. And some games only query for A records, and thus can't benefit from DNS64 either.
Not a problem with DS-Lite or NAT444
So I guess the optimal way to stretch the lifetime of IPv4 while still moving toward IPv6 all the time would be to dual-stack customers and deploy both NAT64/DNS64 and some other LSN which can handle the two downsides above. All the traffic that you can shift to NAT64 means that your other LSN (which doesn't scale as well) can handle that much more traffic before becoming a bottleneck. And naturally, you'll want to shift all that youtube/facebook/whatever traffic to native IPv6 to help both NAT boxes cope.
My 2 cents delivered,
-- Aleksi Suhonen
() ascii ribbon campaign /\ support plain text e-mail
(*) NAT44 means the normal NAT from private IPv4 addresses to public IPv4 addresses. NAT444 means that there are two layers of NAT boxes: usually one at customer premises and the other at the ISP, doing LSN.
All good and accurate info. I would just restate that nat64 unlike nat444 does not need to be "on path", this is what drives its improved scaling over nat444.
Also, unlike ds-lite, nat64 works without any special client, such as the b4 function in the ds-lite architecture. Any fully functional ipv6 system such as win7 can work out of the box (ipv4 only apps being the exception)
Finally, ds-lite and nat444 are just crutches for ipv4. Nat64 pushes ipv6 by making ipv6 end to end and forcing applications to be AF agnostic .... as where the others enable ipv4 without any backpressure.
Each solution fits well for some set of constraints and objectives
Cb
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
A handy/succinct phrase I often use for that (in total agreement, of course) is: "NAT444 is NOT an IPv6 Transition Technology". Using an "anycast"-flavored model, where all DNS64 servers synthesize using the same prefix[es] and all NAT64 gateways are otherwise out of the critical path (injecting said prefix[es]), is indeed a highly scalable methodology. I've been deploying as such for the last ~6mo with great success. What was surprising was how Enterprise-applicable this has been in "v6-only access client" trials. The lack of need for gaming, streaming radio/media (i.e., "hard-coded IPv4 literals"), and desktop VoIP/P2P apps have turned out exceedingly well. -Jeff
Hi, On Thu, Jun 9, 2011 at 10:39 AM, Cameron Byrne <cb.list6@gmail.com> wrote:
In message <4DF053AA.50400@axu.tm>, Aleksi Suhonen writes:
Some people were talking about Large Scale NATs (LSN) or Carrier Grade NATs (CGN) yesterday. Comments included that DS-Lite and NAT64 are basically LSNs and they suffer from all the same problems. I don't think that NAT64 is as bad as other LSNs and here's why:
My statement is that a *pure* ipv6-only network, in the sense you have 0 NAT:ed reachability to the IPv4 Internet, will only attract people like me. :)
All good and accurate info. I would just restate that nat64 unlike nat444 does not need to be "on path", this is what drives its improved scaling over nat444.
Also, unlike ds-lite, nat64 works without any special client, such as the b4 function in the ds-lite architecture. Any fully functional ipv6 system such as win7 can work out of the box (ipv4 only apps being the exception)
Finally, ds-lite and nat444 are just crutches for ipv4. Nat64 pushes ipv6 by making ipv6 end to end and forcing applications to be AF agnostic .... as where the others enable ipv4 without any backpressure.
You are absolutely correct here. The proper solution is indeed to backtrack from the end-goal, which is to have only one stack in the network. Thanks, Martin
On Thu, Jun 09, 2011 at 07:39:17AM -0700, Cameron Byrne wrote:
Each solution fits well for some set of constraints and objectives
Indeed. Unfortunately there's no good way to support v6-only clients in an environment, where dual stacked endpoints do exist as well, see RFC6147 (DNS64) ch. 6.3.2. We still need to find some solution to that problem. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Indeed. Unfortunately there's no good way to support v6-only clients in an environment, where dual stacked endpoints do exist as well, see RFC6147 (DNS64) ch. 6.3.2.
We still need to find some solution to that problem.
We've been using two workarounds: 1. Separate DNS resolvers (both BIND 9.8; one DNS64 and the other DNS6). Have the client provisioning system assign the appropriate DNS server IPs (dual-stack to anycast set 1, v6-only to anycast set 2). 2. Use range-specific views to determine whether or not to apply DNS64 (this setup isn't standard BIND, though). One is a kludge, and the other is vendor-specific, but they work. -Jeff
On Thu, Jun 09, 2011 at 06:39:18PM -0400, Jeff Hartley wrote:
We've been using two workarounds: 1. Separate DNS resolvers (both BIND 9.8; one DNS64 and the other DNS6). Have the client provisioning system assign the appropriate DNS server IPs (dual-stack to anycast set 1, v6-only to anycast set 2). 2. Use range-specific views to determine whether or not to apply DNS64 (this setup isn't standard BIND, though).
One is a kludge, and the other is vendor-specific, but they work.
Not for SLAAC environments and others where there is no mandatory endpoint registration. E.g. residential LANs. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
In message <BANLkTimKBa5hY3sAMTzB6W51mGhGXqMoFw@mail.gmail.com>, Cameron Byrne writes:
--000e0ce0b4eaf1531104a5486aed Content-Type: text/plain; charset=ISO-8859-1
On Jun 9, 2011 1:32 AM, "Mark Andrews" <marka@isc.org> wrote:
In message <4DF053AA.50400@axu.tm>, Aleksi Suhonen writes:
Hello,
Some people were talking about Large Scale NATs (LSN) or Carrier Grade NATs (CGN) yesterday. Comments included that DS-Lite and NAT64 are basically LSNs and they suffer from all the same problems. I don't think that NAT64 is as bad as other LSNs and here's why:
NAT64 scales much better than NAT44 and NAT444(*)
The trick is with its companion DNS64. If you need more NAT64 capacity, you can just add more NAT64 boxes with unique /96 prefixes around your network and have your DNS64 load-balance traffic to those boxes. You can also map one A record into two AAAA records of different NAT64 boxes, in case that works better with some application protocols.
You can add more capacity with DS-Lite as well though it does take a while for the DHCP option to be refreshed without push support.
The smallest granularity of load-balancing easily available with NAT444 is per customer or per customer group. DNS64 allows per flow granularity for load-balancing without even breaking a sweat.
I've been testing NAT64 at home using a public NAT64 trial and generally I've been very happy with it:
http://www.trex.fi/2011/dns64.html
A neat feature I've liked is that I don't have to pass all my traffic via the NAT64 box, and so it doesn't have to be between me and the Internet. NAT44 usually acts as a fuse between me and my Internet.
You don't have to pass all the traffic through the AFTR box or the LSN when dual stacked either. The AFTR box can be on the other side of the world or out sourced if you want it to be. The same can be done with NAT64.
The biggest downsides I've encountered are:
I. Some streaming websites use IP addresses in their video stream URLs, so DNS64 doesn't get asked and that traffic won't flow via NAT64. Thankfully these are a minority.
Not a problem with DS-Lite or NAT444.
II. Networked games usually use some sort of a tracker to help clients find games to connect to, and those only use plain IP addresses too. And some games only query for A records, and thus can't benefit from DNS64 either.
Not a problem with DS-Lite or NAT444
So I guess the optimal way to stretch the lifetime of IPv4 while still moving toward IPv6 all the time would be to dual-stack customers and deploy both NAT64/DNS64 and some other LSN which can handle the two downsides above. All the traffic that you can shift to NAT64 means that your other LSN (which doesn't scale as well) can handle that much more traffic before becoming a bottleneck. And naturally, you'll want to shift all that youtube/facebook/whatever traffic to native IPv6 to help both NAT boxes cope.
My 2 cents delivered,
-- Aleksi Suhonen
() ascii ribbon campaign /\ support plain text e-mail
(*) NAT44 means the normal NAT from private IPv4 addresses to public IPv4 addresses. NAT444 means that there are two layers of NAT boxes: usually one at customer premises and the other at the ISP, doing LSN.
All good and accurate info. I would just restate that nat64 unlike nat444 does not need to be "on path", this is what drives its improved scaling over nat444.
NAT44 only needs to be on the IPv4 path. It does NOT need to be on the IPv6 path. Similarly NAT64 and AFTR need to be on the IPv4 path not the IPv6 path.
Also, unlike ds-lite, nat64 works without any special client, such as the b4 function in the ds-lite architecture. Any fully functional ipv6 system such as win7 can work out of the box (ipv4 only apps being the exception)
No. It needs a specialised nameserver with DNS64 support, which prevents machines running there own nameserver until they get such a nameserver and get the prefix information to configure the DNS64 component. As for the B4, I can manually configure that on 10 year old boxes. It's basically a IPv4 in IPv6 tunnel.
Finally, ds-lite and nat444 are just crutches for ipv4. Nat64 pushes ipv6 by making ipv6 end to end and forcing applications to be AF agnostic .... as where the others enable ipv4 without any backpressure.
DS-lite and NAT444 don't break existing applications. If you have a green field deployment the limitations of NAT64/DNS64 can often be overlooked. When you are deploying into a exist IPv4 network you don't have the luxury of breaking more existing applications that is absolutely necessary.
Each solution fits well for some set of constraints and objectives
Cb
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Fri, Jun 10, 2011 at 09:29:47AM +1000, Mark Andrews wrote:
DS-lite and NAT444 don't break existing applications.
They do, to different degrees. There is plenty of evidence for that.
Each solution fits well for some set of constraints and objectives
Pick your poison. :-) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
participants (6)
-
Aleksi Suhonen -
Cameron Byrne -
Daniel Roesen -
Jeff Hartley -
Mark Andrews -
Martin Millnert