| | | | | | | | |
|
|
|
You're here: Home |
Gert, On Jun 3, 2008, at 8:50 AM, Gert Doering wrote:
I'm not sure I agree. For a many application, I see code more along
the lines of
open_connection()
getaddrinfo()
while( try all addresss )
if ( connect works, break loop, return socket )
(which is the sample loop from the getaddrinfo RFC, IIR) - where the
application usually does not cache anything.
The application stores the actual destination address in application data space. This is the caching I'm talking about. In the example from the man page (at least on MacOS 10.5.3), the address values are 'cached' in 'res0'. If after the 'connect()' or 'listen()' call a renumbering event occurs, the application needs to re-execute the code presented as examples in that manpage to recover. More realistically, the applications just exit and (hopefully) get restarted.
[An alternative would have been to have the kernel maintain a table mapping names to addresses and instead of getaddrinfo(), gethostbyname(), etc., returning the address, an index into that table could have been returned. Renumbering events, either local or remotely triggered (by something like an ICMP host unreachable) would be hidden from the application. Note that this index could have been a good use for the class E space, which would have greatly reduced the need for applications to be hacked to support IPv6 and thereby reduce the time and cost of migrating to IPv6. However, we have what we have.]
My point is that IPv6 does not differ from IPv4 in significant enough ways to remove the use of NATs to limit the pain of renumbering, so saying you should NEVER EVER EVER (etc) use NAT with IPv6 in this context is approximately equivalent to saying you should NEVER EVER EVER (etc) use NAT with IPv4. As I said in a previous message, given current IPv6 architecture, you have 3 choices:
a) use PI so you never have to renumber (assuming you can get someone to route it)
b) use PA and expect to renumber everything when you change providersc) use ULA and NAT and only renumber the NAT box when you change providers
(which, perhaps not surprisingly, are exactly the same options you have with IPv4). IPv6 may make renumbering easier than IPv4, but it is still disruptive and thus, pragmatically speaking, will result in folks using tools like NAT to avoid it.
Regards, -drcP.S. Before someone points it out, I'm aware that NAT doesn't help with the need to restart connections due to application 'caching' of addresses. The point is that IPv6 as it is currently implemented doesn't make dealing with that issue any easier than with IPv4.