APNIC Home APNIC Home
Info & FAQ |  Resource services |  Training |  Meetings |  Membership |  Documents |  Whois & Search |  Internet community

You're here:  Home  Mailing Lists global-v6 


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GLOBAL-V6] IPV4 to IPv6 migration



Hi,

On Tue, Jun 03, 2008 at 09:49:26AM -0700, David Conrad wrote:
> 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.

Thanks for just demonstrating *my* point :-) - the whole point is that
in IPv6 renumbering, it's to be expected that multiple addresses can be 
valid *at the same time*.

So the presumed race condition "in the few microseconds between the return 
of getaddrinfo() and connect(), the res0 address has been invalidated" is
completely bogus.  A new address becomes available, the old address
continues working for a week, or so, and long after it has been
removed from forward DNS (etc), it gets removed from the machines.


Long-lived applications doing an explicit bind() to addresses will need 
to be notified - that's true.  

But everything that just needs to connect for a finite time, as in "few 
hours or less" will just find the new address for the target host upon 
the next connection attempt, and will be done with it.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  110584

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

Attachment: pgpMqY45ixKTP.pgp
Description: PGP signature