[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


    Date:        Thu, 3 May 2001 07:22:13 -0700 (PDT)
    From:        Bill Manning <[email protected]>
    Message-ID:  <[email protected]>

  | No!!! not politics!

Yes, it is politics.   As you said in an earlier reply, you can do
DNAME, bit string labels, etc, in ip6.int (or any other domain).

Similarly, you could do a.b.c.d.e.f..... PTR lookups in ip6.arpa.

There was a decision made (100% political) to switch from ip6.int
to ip6.arpa - and BIND respected that decision in their implementation.

But no-one has bothered to actually delegate ip6.arpa, which really is
a pre-requisite for any kind of use of it at all (with any kind of

  | Someone wrote a draft that became an RFC that stated: "the previous method
  | is depricated by this one", hence the statements in ARM et.al.  Of course 
  | there was the minor oversight in dealing w/ the:
  | 	) the deployed based
  | 	) lack of tools to effectivly use the new format

All that might explain why DNAME, etc, aren't used much.   Another
(additional) explanation might be that it has been made needlessly
difficult by people (which certainly wasn't the DNAME (etc) inventors, or
the ipngwg or dnsext working groups (or ngtrans either)) who insisted
that the domain should be changed (perhaps for good reason), but then
didn't arrange to make sure that the new one was actually ready to be
used by anyone wanting to try it.

I mean, this query was sparked by exactly that - someone who wants to
try it, that is, to become part of a new deployed base, and perhaps
either work around the lack of tools, or build some, but is being
stymied by the lack of the defined domain in which to actually do the work.

  | I guess the lesson here is that just 'cause someone says
  | something doen't make it so.

No.  But what really hurts is when someone says something, then does nothing
at all to make what they said possible.

Perhaps ipngwg should simply publish revised versions of those specs which
move back to using ip6.int rather than ip6.arpa, given that the latter
simply doesn't exist (just treat the reference to ip6.arpa as a bug in
the specification that has to be fixed).   And while we're waiting, updating
BIND (and anything else that is able to do new stlye IPv6 reverse lookups)
to use ip6.int instead of ip6.arpa can't be very hard...