Things I understand: IPv6 is the long term solution to IPv4 exhaustion. For IPv6 to work correctly, most of the IPv4 content has to be on IPv6. That's not there yet. IPv6 deployment to end users is not trivial (end user support, CPE support, etc...). Translation techniques are generally evil. IPv6->IPv4 still requires 1 IPv4 IP per end user or else you're doing NAT. IPv4->IPv6 (1-1) doesn't solve our main problem of giving users access to the IPv4 Internet.
I expect like most companies we're faced with having to extend the life of IPv4 since our users will continue to want access to the IPv4 content. Doing that by giving them an IPv6 address is not very feasible yet for many reasons. NAT444 seems like the only solution available while we slowly transition over to IPv6 over the next 20 years. Based on the this RFC, NAT444 breaks a lot of applications!
Things I understand: IPv6 is the long term solution to IPv4 exhaustion. For IPv6 to work correctly, most of the IPv4 content has to be on IPv6. That's not there yet. IPv6 deployment to end users is not trivial (end user support, CPE support, etc...). Translation techniques are generally evil. IPv6->IPv4 still requires 1 IPv4 IP per end user or else you're doing NAT. IPv4->IPv6 (1-1) doesn't solve our main problem of giving users access to the IPv4 Internet.
Correct, all content is not there yet... but World IPv6 Day showed
that Google, Facebook, Yahoo, Microsoft and 400+ others are just about
ready to go.
IPv6->IPv4 does not require 1 to 1, .... any protocol translation is a
form of NATish things, and stateful NAT64 has many desirable
properties IF you already do NAT44. Specifically, it is nice that
IPv6 flows bypass the NAT .... and as more content becomes IPv6, NAT
becomes less and less used. In this way, unlike NAT44 or NAT444,
NAT64 has an exit strategy that ends with proper E2E networking with
IPv6... the technology and economic incentives push the right way
(more IPv6...)
There are multiple opensource and big vendor (C, J, B, LB guys...)
implementation of NAT64 / DNS64 ... I have trialed it and plan to
deploy it, YMMV... It works great for web and email, not so great for
gaming and Skype.
I expect like most companies we're faced with having to extend the life of IPv4 since our users will continue to want access to the IPv4 content. Doing that by giving them an IPv6 address is not very feasible yet for many reasons. NAT444 seems like the only solution available while we slowly transition over to IPv6 over the next 20 years. Based on the this RFC, NAT444 breaks a lot of applications!
This is just putting IPv4 on life support without moving needle
towards a long term solution. NAT64 = good investment to get IPv6 off
the blocks. NAT444 = life support / money pit with forklift exit
required.
Has anyone deployed NAT444? Can folks share their experiences? Does it really break this many apps? What other options do we have?
Yes, expect it to be deployed in places where the access gear can only
do IPv4 and there is no money or technology available to bring in
IPv6.
Things I understand: IPv6 is the long term solution to IPv4 exhaustion. For IPv6 to work correctly, most of the IPv4 content has to be on IPv6. That's not there yet. IPv6 deployment to end users is not trivial (end user support, CPE support, etc...). Translation techniques are generally evil. IPv6->IPv4 still requires 1 IPv4 IP per end user or else you're doing NAT. IPv4->IPv6 (1-1) doesn't solve our main problem of giving users access to the IPv4 Internet.
Correct, all content is not there yet... but World IPv6 Day showed
that Google, Facebook, Yahoo, Microsoft and 400+ others are just about
ready to go.
IPv6->IPv4 does not require 1 to 1, .... any protocol translation is a
form of NATish things, and stateful NAT64 has many desirable
properties IF you already do NAT44. Specifically, it is nice that
IPv6 flows bypass the NAT .... and as more content becomes IPv6, NAT
becomes less and less used. In this way, unlike NAT44 or NAT444,
NAT64 has an exit strategy that ends with proper E2E networking with
IPv6... the technology and economic incentives push the right way
(more IPv6...)
There are multiple opensource and big vendor (C, J, B, LB guys...)
implementation of NAT64 / DNS64 ... I have trialed it and plan to
deploy it, YMMV... It works great for web and email, not so great for
gaming and Skype.
moves CPE NAT to the ISP tunneled over 192.0.0.0/29.
Has anyone deployed NAT444? Can folks share their experiences? Does it really break this many apps? What other options do we have?
Yes, expect it to be deployed in places where the access gear can only
do IPv4 and there is no money or technology available to bring in
IPv6.
You will need to deploy it along with 6rd or DS-lite.
In a typical DS-Lite deployment you won't be using NAT444. One of the
key advantages of DS-Lite (and A+P, I believe) is that there's only one
level of NAT between the end user and the public internet.
In a typical DS-Lite deployment you won't be using NAT444. One of the
key advantages of DS-Lite (and A+P, I believe) is that there's only one
level of NAT between the end user and the public internet.
yep. and in ds-lite that nat is in the core, so you talk to comcast's
lawyers when you need a new alg. with a+p, the nat is under customer
control, and they just go to best buy to get the cpe that supports the
alg that they want.
I'm going to have to deploy NAT444 with dual-stack real soon now. So I am expecting to see some issues.
A+P would be nicer perhaps, but none of the CPE I have will support it. I'll try and give people who do NAT in their CPE a public address for as long as I can, but it'll soon run out and then NAT444 will have to be used and some things will just not work very well.
I'm going to have to deploy NAT444 with dual-stack real soon now.
you may want to review the presentations from last week's apnic meeting
in busan. real mesurements. sufficiently scary that people who were
heavily pushing nat444 for the last two years suddenly started to say
"it was not me who pushed nat444, it was him!" as if none of us had a
memory.
This is what I am looking at right now. Randy makes some good comments in those sessions. I have not found anything yet, but I am only on session 3, pertaining specifically to issues around NAT444.
I would be looking for issues such as implementing ALGs on both NAT devices, ALG scaling on LSN boxes and issues surrounding application compatibility. I'm also looking at NAT logging for law enforcement issues.
Is there anything planned for the next NANOG around these issues?
However these are with a very high address-sharing ratio (several
thousands users per address). Using a sparser density (<= 64 users per
address) is likely to show much less dramatic user impacts.
Those effects are not specific to NAT444, but apply to any
provider-based NAT limiting the amount of parallel sessions available to
any one customer. Randy was (as I understood him) referring to the
evilness of double-NAT in contrast to single-state NAT (as used with
e.g. DS-Lite).
I think you have the numbers off, he started with 1000 users sharing the same IP, since you can only do 62k sessions or so and with a "normal" timeout on those sessions you ran into issues quickly.
The summary is that with anything less then 20 tcp sessions per user simultaneous google maps or earth was problematic. From 15 and downwards almost unsable.
He deducted from testing that about 10 users per IP was a more realistic limit without taking out the entire CGN "experience".
On a personal note, this isn't even taking into question things like broken virus scanners or other software updates that will happily try to do 5 sessions per second, or a msn client lost trying to do 10 per second. The most the windows IP stack will allow on client versions.
The real big issue that will be the downfall of NAT444 is the issue with ACLS and automatic blocklists and the loss of granular access control on that which the ISP has no control of. Which roughly estimates to the internet.
I was thinking of an average of around 100 sessions per user for working out how things scale to start with. It would also be handy to be able to apply sensible limits to new sessions, say limit the number of sessions to a single destination IP address and apply an overall session limit of perhaps 200 sessions per source IP address.
ACLs and blocklists are going to be a problem, perhaps, as LSN becomes more and more common, such things will gradually die out.
Considering that offices, schools etc regularly have far more than 10 users per IP, I think this limit is a little low. I've happily had around 300 per public IP address on a large WiFi network, granted these are all different kinds of users, it is just something that operational experience will have to demonstrate.
I would love to avoid NAT444, I do not see a viable way around it at the moment. Unless the Department of Work and Pensions release their /8 that is
However these are with a very high address-sharing ratio (several
thousands users per address). Using a sparser density (<= 64 users per
address) is likely to show much less dramatic user impacts.
I think you have the numbers off, he started with 1000 users sharing
the same IP, since you can only do 62k sessions or so
These numbers were not off. From page 19: "...we should assign at least
1000 [..] ports per customer to assure good performance of IPv4
applications"
"At least 1000 ports per customers" is roughly the same than "less than
64 users per address" as I stated above.
Btw, 90% of subscribers have less than 100 active connections at any time,
and with a "normal" timeout on those sessions you ran into issues
quickly.
Agreed for UDP, but most of these sessions are TCP, which arguably time
out
rather rapidly after a FIN and an extra hold time. Normal duration of a
TCP
session is usually under a few seconds.
This study saw an average connection time of 8 seconds for DSL, but it's
from 2004.
Perhaps it can be made ever so slightly less ugly if endpoints get an
"address" that consists of a 32 bit IP address + (n) upper bits of port
number.
This might be 4 significant bits to share an IP 16 ways, or 8 significant
bits to share it 256 ways, or whatever.
In a perfect world, all of the endpoints sharing a single IP would be off a
single concentration point of whatever sort (same tower, etc)...
The end users can still do their own NAT then, their NAT device just has to
restrict the external port range to the one assigned (or have packets with
bad source ports dropped when sent).
Ok, not really pretty, but maybe a little less ugly than twice NAT, and at
least users could have "fixed" addresses (including the upper bits of port
number).
Of course, the 0000 value for upper port bits can be reserved for "business"
grade users so they get the nice ports like 80, etc.
Remember that a TCP session is defined not just by the port, but by the combination of source address:source port:destination address:destination port. So that's 62k sessions *per destination* per ip address. In theory, this particular performance problem should only arise when the NAT gear insists on a unique port per session (which is common, but unnecessary) or when a particular destination is inordinately popular; the latter problem could be addressed by increasing the number of addresses that facebook.com and google.com resolve to.
I'm not advocating CGN; my point is not that this problem *should* be solved, merely that it *can* be.
Good point, but aside from these scaling issues which I expect can be resolved to a point, the more serious issue, I think, is applications that just do not work with double NAT. Now, I have not conducted any serious research into this, but it seems that draft-donley-nat444-impacts does appear to have highlight issues that may have been down to implementation.
Other simple tricks such as ensuring that your own internal services such as DNS are available without traversing NAT also help.
Certainly some more work can be done in this area, but I fear that the only way a real idea as to how much NAT444 really doe break things will be operational experience.
In theory, this
particular performance problem should only arise when the NAT gear insists on a
unique port per session (which is common, but unnecessary)
What you're describing is known as "endpoint-independent mapping" behaviour. It
is good for not breaking applications, not so good for scalability. RFC 4787
section 4.1 makes it a MUST.
