Re: IPV4 to IPv6 migration
Gert Doering <[email protected]> Tue, 3 Jun 2008 16:41:07 +0200
| Newsgroups | gmane.org.apnic.global-v6 |
|---|---|
| Message-ID | <[email protected]> |
--===============0737540433==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="KAMuu62gJAdJdl2g"
Content-Disposition: inline
--KAMuu62gJAdJdl2g
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hi,
On Tue, Jun 03, 2008 at 07:27:45AM -0700, David Conrad wrote:
> Since applications cache IP addresses (be they IPv4 or IPv6), can you =20
> point to _application_ code that copes with multiple addresses in =20
> parallel and more specifically, transitioning between one address and =20
> another?
Most applications that I'm aware of cache *destination* addresses, not
*source* addresses. The "a machine can cope with multiple addresses"
statement is talking about source addresses (which, today, usually works
with IPv4 as well, but many stacks seem to have a "preferred" v4 address
plus "aliases", while with IPv6, usually they are "just addresses")
Caching destination addresses for "short" periods of time isn't going
to harm the "add new prefix, wait few days, put new prefix into DNS,
wait few days, deprecate old prefix, ..." process.
Caching destination addresses for unlimited time is *bad*.
> E.g., how do you tell an application to 'deprecate' one address over =20
> another?
Applications usually don't explicitely specify *source* addresses. The=20
OS picks the right source address, and the OS knows about depreciation.
If the application insists on specifying the source address for connections,
it needs a way to figure out if something has changed - which, for example,=
=20
bind seems to do quite well (as an example of UDP based server applications=
=20
that need to make sure that the source address of the return packet matches=
=20
whatever address the client sent his packet to).
If something is hardwired in a config file, this falls under the=20
"good planing makes renumbering less painful" category.
I'm not really sure what point you're trying to make, though...?
(Note that I never said "IPv6 makes renumbering automatic", I just think
that the impact can be lots less disruptive with IPv6 renumbering than
with IPv4 renumbering - and I've done both a number of times, and seen
the difference)
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
--KAMuu62gJAdJdl2g
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)
iQCVAwUBSEVYA6kuBuNlUUl1AQKBfwP+KEpko/joiTpVuUlfaMgKm8I1UmQt3HDE
ylGaY8ObqYjW7JTa/w8AXas0VmFefwxfBrFsmDii2woH9t4aDXkrDRQgPFEOzMKb
Ur4NeFo5taDuHIdQpBsDQ+PSthQDQhRntyPgxMcgJWDGjYOiFJDspbsCPyNf7uJt
PnSsIAjNJGs=
=tVEM
-----END PGP SIGNATURE-----
--KAMuu62gJAdJdl2g--
--===============0737540433==
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
--===============0737540433==--