[75944] in North American Network Operators' Group
Re: A6/DNAME not needed for v6 renumbering [Re: who gets a /32 [Re:
daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon Nov 29 04:41:27 2004
Date: Mon, 29 Nov 2004 01:40:46 -0800
From: Owen DeLong <owen@delong.com>
To: Pekka Savola <pekkas@netcore.fi>
Cc: Paul Vixie <paul@vix.com>, nanog@merit.edu
In-Reply-To: <Pine.LNX.4.61.0411290847010.26365@netcore.fi>
Errors-To: owner-nanog-outgoing@merit.edu
--==========2A2771294E3A9DED34A7==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
I suspect that it is now time to agree to disagree.
I have said before and will say again:
1. IPv4 is fundamentally flawed in that we are using a single
resource as both an end-point identifier and a routing
identifier. The phone companies figured out that these
must be separate years ago.
2. IPv6 took some steps to solve this by making this division
somewhat artificially through the use of A6/DNAME, but,
later backed off from this practice.
3. IPv6 then completely failed to address issue 1 in any other
way, and, so, we have, as near as I can tell, essentially
come full circle to TUBA which we initially rejected largely
because of issues like number 1 above.
To further paraphrase Randy: 'Swamp: do not drink.'
Owen
--On Monday, November 29, 2004 8:53 AM +0200 Pekka Savola=20
<pekkas@netcore.fi> wrote:
> On Sun, 28 Nov 2004, Owen DeLong wrote:
>> Except that A6/DNAME also supported your upstream being able to initiate
>> prefix renumbering without having to involve the end customer...
> [...]
>
> Sure. But draft-ietf-v6ops-renumbering-procedure-03.txt says it IMHO
> well:
>
> 6. Acknowledgments
> [...]
> Some took it on themselves to convince the authors that the concept
> of network renumbering as a normal or frequent procedure is daft.
> Their comments, if they result in improved address management
> practices in networks, may be the best contribution this note has to
> offer.
>
> The main thrust of A6/DNAME is adding hooks for handling so-called 'rapid
> renumbering' and 'not-user-initiated-renumbering' scenarios. That seems
> unfeasible and unreasonable.
>
> Renumbering cannot be prevented. And we should take all the reasonable
> actions to make sure it's manageable, because otherwise we'll end up with
> PI/ULAs and NATs. But AFAICS, obtaining a level of 'manageability'
> should be sufficient. We don't necessarily want or need to solve the
> most tricky renumbering problems here (e.g., rapid renumbering, automatic
> renumbering or large sites without any actions from the administrators,
> etc.).
>
> To paraphrase Randy from a couple of years ago: 'Ocean: do not drain.'
>
> --
> Pekka Savola "You each name yourselves king, yet the
> Netcore Oy kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--=20
If it wasn't crypto-signed, it probably didn't come from me.
--==========2A2771294E3A9DED34A7==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Darwin)
iD8DBQFBqu6en5zKWQ/iqj0RAr7pAJ49E59Huv+vVGraZxKYkITFmnpXJACfUouD
KpXc9Lyfd1cTgO6hboqeGXc=
=DyjI
-----END PGP SIGNATURE-----
--==========2A2771294E3A9DED34A7==========--
