[75924] 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)
Sun Nov 28 14:19:32 2004
Date: Sun, 28 Nov 2004 11:15:59 -0800
From: Owen DeLong <owen@delong.com>
To: Pekka Savola <pekkas@netcore.fi>, Paul Vixie <paul@vix.com>
Cc: nanog@merit.edu
In-Reply-To: <Pine.LNX.4.61.0411282048360.12805@netcore.fi>
Errors-To: owner-nanog-outgoing@merit.edu
--==========71DFFD2FEC1ABA3EF354==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Except that A6/DNAME also supported your upstream being able to initiate
prefix renumbering without having to involve the end customer...
As I understand it:
foo.blah.org. IN A6 MYISP1 ::4321:53ef
MYSIP1 IN DNAME 10 prefix1.isp1.net. ::dead:beef::
Then, in ISP1's isp1.net zone file
prefix1 IN DNAME 100 feed:beef::
This way, if ISP1 needed to renumber for some reason (turning in old /32 in
trade for /30, for example), they could go through the following steps:
prefix1 IN DNAME 200 feed:beef::
prefix1 IN DNAME 100 2314:5124::
Wait a few days for everyone to catch on to the new DNAME, then,
prefix1 IN DNAME 100 2314:5124::
Voila, painless ISP renumber without substantial end-user headache.
Sure, there are other issues (like bone-headed ACLs that accept/deny host
based on 128 bit address), but, this at least solved part of that problem.
Owen
--On Sunday, November 28, 2004 8:51 PM +0200 Pekka Savola=20
<pekkas@netcore.fi> wrote:
>
> On Sun, 28 Nov 2004, Paul Vixie wrote:
>> the property of a6/dname that wasn't widely understood was its intrinsic
>> multihoming support. the idea was that you could go from N upstreams to
>> N+1 (or N-1) merely by adding/deleting DNAME RRs. so if you wanted to
>> switch from ISP1 to ISP2 you'd start by adding a connection to ISP2, =
then
>> add a DNAME for ISP2, then delete the DNAME for ISP1, then disconnect
>> ISP1.
>>
>> the DNAME was expected to be inside your own zone. presto, no lock-in.
>> my theory at the time, bitter and twisted i admit, was that we had too
>> many ISP employees in positions of power inside IETF, and that A6/DNAME
>> was seen as shifting too much power to the endsystems. i've since
>> learned that it was just another case of FID (fear, ignorance, and
>> doubt).
> [...]
>
> Isn't about the same achievable with about two or three lines of
> scripting (or a new zone parsing option for bind ;) with a lot less
> protocol complexity?
>
> As you note, A6/DNAME wasn't a panacea. A lot additional stuff is needed
> to achieve the goal. It seems to me that actually the A6/DNAME part is a
> relatively simple one to achieve using current mechanisms.
>
> --
> 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.
--==========71DFFD2FEC1ABA3EF354==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Darwin)
iD8DBQFBqiPvn5zKWQ/iqj0RAk/EAJ99F8B44IT0nvZluC/a8PK/8mO6XACfWbN0
Mc4h1LaVZcnoW9MKWafiiis=
=YhLg
-----END PGP SIGNATURE-----
--==========71DFFD2FEC1ABA3EF354==========--
