Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00

["Dan Wing" <[e-mail]>]

 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Simon Perreault
> Sent: Tuesday, December 01, 2009 10:01 AM
> To: [e-mail]
> Subject: Re: [BEHAVE] proprietary implementation v.s 
> standardisedprotocols//re: draft-xu-behave-nat-state-sync-00
> 
> Dan Wing wrote, on 2009-12-01 12:16:
> > It's not just the AAAA records getting cached.  It's also the 
> > applications that have done their getaddrinfo() and now have the
> > IPv6 address in their internal datastructures.  There is no lifetime
> > for that, and very very few applications pay any attention to the
> > TTL of the AAAA record.  Applications expect the IPv6 address to 
> > be fixed and to be valid as long as they need it.
> 
> How hard should NAT64 try to accommodate broken applications?

My point is that it shouldn't make things worse.  If the functioning
NAT64's prefix changes and the old prefix no longer works, that makes
things worse -- it effectively causes IPv6 addresses to change.  That
breaks not just applications that are sensitive to IP address changes, 
but also existing TCP sessions.  SCTP handles IP address changes
better, but there is scant deployment of SCTP yet (due to many 
reasons).

> These applications would fail in many other cases that don't 
> involve NAT64.

But IPv4 addresses on today's Internet don't change much, especially
while connections are up.  When they do, yes, applications break.  
That's part of the whole Location/Identifier split problem.

-d