Re: IPV4 to IPv6 migration

--===============1004926536==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="UJ/TbCxVZUsr84bd"
Content-Disposition: inline


--UJ/TbCxVZUsr84bd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
>=20
> The application stores the actual destination address in application =20
> data space.  This is the caching I'm talking about. In the example =20
> from the man page (at least on MacOS 10.5.3), the address values are =20
> 'cached' in 'res0'.  If after the 'connect()' or 'listen()' call a =20
> renumbering event occurs, the application needs to re-execute the code =
=20
> presented as examples in that manpage to recover.  More realistically, =
=20
> 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=20
valid *at the same time*.

So the presumed race condition "in the few microseconds between the return=
=20
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=20
to be notified - that's true. =20

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

Gert Doering
        -- NetMaster
--=20
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

--UJ/TbCxVZUsr84bd
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)

iQCVAwUBSEWtlqkuBuNlUUl1AQLwEAP6A7DUvLHfqKmOU8iZv2ICO7NIMHlGwriv
m8lWwmsUMYv26WCibyp4M/wIDBlZUOagLez+y/mmt2Yp/8kLbGaMAM50kdYunglp
aFLKxlrH2Huqt1Btlcep5sFXzFtYFWKuO4RJnwWes8g+vxt+YVioNjmU8OGpRVdx
ceAgtZFcaGE=
=/dLj
-----END PGP SIGNATURE-----

--UJ/TbCxVZUsr84bd--

--===============1004926536==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
global-v6 mailing list
[email protected]
http://mailman.apnic.net/mailman/listinfo/global-v6

--===============1004926536==--