A6/DNAME not needed for v6 renumbering [Re: who gets a /32 [Re: IPV6 renumbering painless?]]

Owen DeLong owen at delong.com
Sun Nov 28 19:15:59 UTC 2004


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 
<pekkas at 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



-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20041128/975927cd/attachment.sig>


More information about the NANOG mailing list