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