Subject: RE: (ngtrans) Re: IPv6 dns

From: "Christian Huitema" <[email-masked]>
Date: Thu, 18 Jan 2001 09:32:27 -0800

OK, let's try a middle ground here. There is a requirement to field IPv6
only machines in the net. To work well, these machines should be able to
resolve names by sending DNS requests over IPv6. This means that, in
order to resolve a name, these machines should be able to process NS
records, find the list of the name servers associated to the domain, and
find at least one server in the list that has at least one IPv6 address.
Normally, post processing rules should ensure that this is done in a
single pass, the A6 or AAAA records being carried as additional
information.

During a trial, this can be done by operating on a trial subtree for
names. Something like <example>.ipv6dns.org. During the transition,
however, we want to progressively publish A6 records for the name
servers of regular domains. Obviously, any domain manager can do this on
their own initiative: for example, Microsoft could add an NS record
pointing to a v6 capable server under "microsoft.com". However, this
impacts the general infrastructure, since the servers for microsoft.com
and their address must be provided by the ".com" server.  Randy has a
first point there: we have to understand the potential impact of serving
A6 records to vanilla .com users; we may have to set up a conservative
rule, such as only serving these records if the query for the .com user
was received over IPv6. Or maybe we need not be that conservative; but
we should try. And, maybe, just maybe, we should not try first with
".com." 

The same indeed apply for the root itself. If we say that ".com" will
only provide A6 records in the additional section if the query was
received over IPv6, then we must find a way to publish the IPv6 address
of the suitable .com server, and that must be done by the root. Indeed,
that must be done by the root for every TLD who wants to enable IPv6.
And there are good reasons to be very conservative with the handling of
the root service.

Randy also asked, what happens if an IPv6 only DNS resolver tries to get
information about an IPv4 domain. The obvious answer is to use a dual
mode server as proxy. However, this requires some configuration, which
Ngtrans should automatize. Now, that would would be a work item for this
group...

-- Christian Huitema

> -----Original Message-----
> From: Randy Bush [mailto:[email-masked]]
> Sent: Thursday, January 18, 2001 4:48 AM
> To: Bill Manning
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: (ngtrans) Re: IPv6 dns
> 
> 
> > % an example of a worry is cache poisoning of an antique v4 bind.
> > % ----
> > % and there are thousands of vulnerable v4 binds still out there.
> > 
> > 	One might argue that we have only applied the carrot.
> > 	We still have broken/vulnerable code, some pushing
> > 	15 years w/o an upgrade. Perhaps its time to apply
> > 	a stick and let folks know that things will stop working
> > 	or won't be the same unless they upgrade. 
> 
> there are people who don't think it's prudent engineering to 
> break the net
> to get people to do something.  silly things about technical 
> and social
> responsibility now that the net has grown a bit bigger than 
> boys and their
> toys.
> 
> of course there are folk with the opposite opinion.
> 
> randy
>

---

From: [email-masked]
Date: Fri, 19 Jan 2001 03:01:04 +0900

>we should try. And, maybe, just maybe, we should not try first with

	I think:
	- it should be okay to deploy AAAA records to certain degree
	- we need to be very conservative about deplying A6 records,
	  as A6 presents highly different behavior than A/AAAA records.
	  # of queries would increase, # of additoinal records would
	  go skyrocket.

	about AAAA:

	Situation may be different from ".com.", but there are registries that
	accept NS record registration with IPv6 address (NS record that
	points to AAAA record).  For example, JPNIC do this:
	http://www.nic.ad.jp/en/topics/archive/20000301-01.html
	and if you would like to see an example, try looking up NS for
	wide.ad.jp.
	% dig wide.ad.jp. ns
	% whois -h whois.nic.ad.jp wide.ad.jp/e
	% whois -h whois.nic.ad.jp ns1.v6.wide.ad.jp/e

	also, there are many MX records that point to AAAA record.  for
	example, try jp.freebsd.org. and wide.ad.jp.
	% dig jp.freebsd.org. mx
	% dig wide.ad.jp. mx

	both of them looks to be working fine.  we have conducted detailed
	test against MTAs, to see if they works okay with MX record that
	points to AAAA records.  I remember that it worked just fine.
	[email-masked] should have more detail.

	about A6:

	If we deploy A6 records, situation with additional records will get
	much, much, much worse than AAAA additional records.
	Here's an example (thanks jinmei!).

% dig @0.0.0.0 paradise.v6.kame.net. a6

; <<>> DiG 9.0.1 <<>> @0.0.0.0 paradise.v6.kame.net. a6
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54685
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 8

;; QUESTION SECTION:
;paradise.v6.kame.net.          IN      A6

;; ANSWER SECTION:
paradise.v6.kame.net.   158     IN      A6      64 ::2e0:18ff:fe98:f19d sharedsegment.a6.kame.net.
paradise.v6.kame.net.   158     IN      A6      64 ::2e0:18ff:fe98:f19d karigome-bb.v6.wide.ad.jp.

;; AUTHORITY SECTION:
kame.net.               1748    IN      NS      coconut.itojun.org.
kame.net.               1748    IN      NS      tiger.hiroo.oshokuji.org.
kame.net.               1748    IN      NS      orange.kame.net.

;; ADDITIONAL SECTION:
sharedsegment.a6.kame.net. 158  IN      A6      48 0:0:0:2000:: karigome.v6.wide.ad.jp.
karigome.v6.wide.ad.jp. 3600    IN      A6      32 0:0:4819:: wide-6bone.v6.wide.ad.jp.
wide-6bone.v6.wide.ad.jp. 3600  IN      A6      0 3ffe:501::
karigome-bb.v6.wide.ad.jp. 3600 IN      A6      48 0:0:0:4819:: wide-stla.v6.wide.ad.jp.
wide-stla.v6.wide.ad.jp. 3600   IN      A6      0 2001:200::
coconut.itojun.org.     8       IN      A       210.160.95.97
tiger.hiroo.oshokuji.org. 8     IN      A       210.145.33.242
orange.kame.net.        897     IN      A       203.178.141.194

;; Query time: 83 msec

>And there are good reasons to be very conservative with the handling of

	I'm curious about:
	- packet size requirement when we include A6/AAAA records into "."
	  queries.
	- deployment status of EDNS0 to IPv6 transport-capable resolvers

>Ngtrans should automatize. Now, that would would be a work item for this

	I don't think such a DNS server should be widely deployed.  such a
	A-to-A6/AAAA rewriting nameservers should be located in leaf sites,
	for use within the leaf site only, and every efforts should be
	made to avoid leakage of rewritten records.

	for actual implementation, see totd from Feico Dillema.
	http://www.vermicelli.pasta.cs.uit.no/ipv6/software.html

itojun

---

From: Bill Manning <[email-masked]>
Date: Thu, 18 Jan 2001 15:20:07 -0800 (PST)

% 	I think:
% 	- it should be okay to deploy AAAA records to certain degree
% 	- we need to be very conservative about deplying A6 records,
% 	  as A6 presents highly different behavior than A/AAAA records.
% 	  # of queries would increase, # of additoinal records would
% 	  go skyrocket.
% 
% 	about AAAA:
% 

	AAAA record support has been around since 4.9.6 (if memory
	serves).   There should be no reason to not deploy AAAA
	records (in the general sense) if there is a need.
	No harm at all to those "hundreds" of "antique" v4 servers
	that are out there. 
-- 
--bill

---

From: Bill Manning <[email-masked]>
Date: Thu, 18 Jan 2001 15:50:44 -0800 (PST)

% Randy also asked, what happens if an IPv6 only DNS resolver tries to get
% information about an IPv4 domain. The obvious answer is to use a dual
% mode server as proxy. However, this requires some configuration, which
% Ngtrans should automatize. Now, that would would be a work item for this
% group...
% 
% -- Christian Huitema

	Perhaps. If this is a protocol issue, then I concur.
--bill

---

From: Alain Durand <[email-masked]>
Date: Thu, 18 Jan 2001 16:09:28 -0800

There have been many exchanges lately on IPv6 DNS.
Last IETF, we agreed that this was an important issue
and the process was
	- NGtrans defines the needs
	- DNSops implements it

So I would like to gather _few_ people interested in defining
exact needs & requirements for IPv6 DNS operations.
The lifetime of such a group will be short and this group
should report to NGtrans next IETF.

So, if you are interested into participating in this group and
have enough bandwidth until IETF50, please contact me.

I will set up a mailing list and we may have to schedule some phone calls.

	- Alain.

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 18 Jan 2001 23:37:49 -0500

At/À 16:09 2001-01-18 -0800, Alain Durand you wrote/vous écriviez:
>So, if you are interested into participating in this group

I have! ;-))

>and
>I will set up a mailing list

our minds were in sync today! We already setup a mailing list and I was 
just going to announce it, and I read your mail. Anyway, it is done if you 
wanted to use it, contact me.

Regards, Marc.

>and we may have to schedule some phone calls.
>
>         - Alain.

Marc Blanchet
Viagénie inc.
tel: 418-656-9254
http://www.viagenie.qc.ca

----------------------------------------------------------
Normos (http://www.normos.org): Internet standards portal:
IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Jan 2001 09:16:28 -0600

> %         # of queries would increase, # of additoinal records would

I think it was recognized a long time ago that the initial deployment
of A6 records should be limited to two (or at most 3) levels. The question
is whether that is enough to avoid the horrors described by Dan Bernstein 
over on IPNG.

    Brian

---

From: Randy Bush <[email-masked]>
Date: Fri, 19 Jan 2001 07:42:41 -0800

> I agree with you we should be fine deploying AAA records.  I also agree
> we need to be skeptical about A6 and if they continue to exist we need to 
> for sure do the type of experiments Randy suggested.

mornin' jim,

to be pedantic, i did not suggest a particular experiment.  what i asked was
that any experiments be proposed and discussed before they are conducted on
the public internet [0].

randy

---

[0] - some experiments are conducted on disconnected nets, e.g. at dnssec
      workshops.

---

From: "Perry E. Metzger" <[email-masked]>
Date: 19 Jan 2001 10:45:54 -0500

> for sure do the type of experiments Randy suggested.

I must admit to being very skeptical of A6 -- my experience is that
renumbering is not helped by such trivia. Ultimately, the issues in
renumbering are NOT protocol issues, they are issues of how you manage
your administrative databases, and they can't be helped much by tweaks
we make to protocols. Somehow, though, I've been unable to explain
that particularly well in spite of discussion in lots of working
groups, hallway meetings, and other places with many people for the
last four years. (Maybe I need to write an informational RFC, but I
rarely have enough time these days...)

About A6, though: I feel like it is too late to oppose it. I didn't
speak up at the time it was going forward and as a result I sort of
feel as though it isn't clear I have a right to now, but I will say
this: I have deployment experience with quad-A at this time and it has
been working well for me, and I've never felt a burning need for A6's
new capabilities.

Perry

---

From: Keith Moore <[email-masked]>
Date: Fri, 19 Jan 2001 11:55:44 -0500

> 'clever' people are likely to seriously abuse DNAME and A6.  we have already
> seen unnecessary and confusing attempted use of DNAME over in the enum wg.
> is there any *significant* advantage to them allowing more than one level of
> indirection?

I can't tell that there is any significant advantage in even a single level
of indirection, as compared to a local macro expansion facility.  given that 
renumbering events are unlikely to be entirely automatic anyway, the 
necessity to re-sign the local zone when the set of prefixes changes 
doesn't seem like a big deal.  And last time I looked I couldn't find
where anyone had worked out the details of verifying a chain of signed
A6 and DNAME records anyway, at least not if you care about ensuring 
that the parties who did sign the records actually had the authority
to do so (i.e. they had the address space delegated to them.) But it
looks very non-trivial at best.

Keith

---

From: Randy Bush <[email-masked]>
Date: Fri, 19 Jan 2001 09:28:36 -0800

> given that renumbering events are unlikely to be entirely automatic anyway

as fred succintly said, how often does renumbering occur?  how often do
lookups occur?  so, for which should we optimize?

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 19 Jan 2001 07:55:37 -0800

randy

---

From: Keith Moore <[email-masked]>
Date: Fri, 19 Jan 2001 13:33:55 -0500

> lookups occur?  so, for which should we optimize?

makes sense to me.

Keith

---

From: Jim Bound <[email-masked]>
Date: Fri, 19 Jan 2001 09:49:59 -0500 (EST)

Itojun,

/jim

On Fri, 19 Jan 2001 [email-masked] wrote:

> paradise.v6..kame.net.   158     IN      A6      64 ::2e0:18ff:fe98:f19d sharedsegment.a6.kame.net.

---

From: Jim Bound <[email-masked]>
Date: Fri, 19 Jan 2001 09:53:03 -0500 (EST)

What Christian suggests and the fix is not a protocol or IETF type 
operational issue, but a deployment decision operators and users will
have to make.

/jim

---

From: Jim Bound <[email-masked]>
Date: Fri, 19 Jan 2001 11:35:14 -0500 (EST)

A6 is PS not DS.  If it will not work as is we have every right to oppose
it.  I also agree with you about renumbering personally but I doubt even
if 10 of us joined forces and tried to alter the consciousness of the
collective IETF avalanche of renumbering belief systems which are valid
but may not be true, we would probably not win that battle.  But if we
reduce the levels of hierarchy of the A6 DNAMES to max 3 it may work.  But
if anyone does 10 it will not perform for sometime.  I also think the
processing of A6 should not be done on clients but on the servers.  I
can't see my IPv6 PDA or my international gaming device having to cache
10 levels and retransmit to get my DNS records.  It just will not work.

/jim

---

From: Jim Bound <[email-masked]>
Date: Fri, 19 Jan 2001 11:40:30 -0500 (EST)

DNAME for ISP.COM
DNAME for HOME.ISP.COM
DNAME for my.unit.HOME.ISP.COM

If ISP.COM renumbers all that has to be done is change the prefix of 
the highorder bits of my Ipv6 address and only those SIG records
theoretically is the view (its much more complex), but this assumption
I think is bogus because then one assumes that a new ISP2.COM will use
all loworder bits to the right of the highorder bits prefix.  I am not
clear that is a valid assumption.

/jim

On Fri, 19 Jan 2001, Randy Bush wrote:

> ---------------------------------------------------------------------
> The IPv6 Users Mailing List
> Unsubscribe by sending "unsubscribe users" to [email-masked]
>

---

From: Jim Bound <[email-masked]>
Date: Fri, 19 Jan 2001 11:28:30 -0500 (EST)

Hi Randy,

I stand corrected.

thanks

/jim

---

From: Jim Bound <[email-masked]>
Date: Fri, 19 Jan 2001 12:37:57 -0500 (EST)

this is an excellent point!!  optimizing the lookups seems prudent.

/jim

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Jan 2001 13:21:27 -0600

Well, as I recall the earlier discussion, this rather depends on the expected
frequency and overhead of renumbering.

If the (frequency*overhead) of renumberings is comparable to the 
(frequency*overhead) of lookups, we have to optimize for both.

Renumbering frequency depends on whether we believe that sites will 
indeed be renumbered whenever they change ISP (or upstream ISP). 
That was certainly Plan A and lies behind the whole concept of 
TLA addressing. On that assumption we could certainly expect hundreds
of renumberings per day. (Which is of course a lot less than
millions of lookups per second.)

Renumbering overhead is presumably measured in units of zone
transfers.

  Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org
Non-IBM email: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Jan 2001 13:25:41 -0600

> is there any *significant* advantage to them allowing more than one level of

Probably not.. as I said, I think the interesting feature is the
ability to separate the record for a site from the record for
an individual host inside the site. But as Perry observed, you can 
get by without that if you have to.

  Brian

---

From: [email-masked]
Date: Sat, 20 Jan 2001 10:43:22 +0900

>is whether that is enough to avoid the horrors described by Dan Bernstein 

	I see... it is unfortunate RFC2874 does not cover it.
	it has A6 reference from leaf customer A6 record to ISP A6 record,
	and 5 levels of indirection.

itojun

---

From: Robert Elz <[email-masked]>
Date: Sat, 20 Jan 2001 15:27:51 +0700

Date:        Fri, 19 Jan 2001 09:28:36 -0800
    From:        Randy Bush <[email-masked]>
    Message-ID:  <[email-masked]>

  | as fred succintly said, how often does renumbering occur?  how often do
  | lookups occur?  so, for which should we optimize?

Depends what the user of the number, surely?   There are many (current
IPv4, and so one would presume, quite possibly IPv6 as well) addresses
that are changed much more frequently than anyone ever looks them up
in the DNS (name -> address translations).

In fact, aside from a (comparatively small) set of major servers,
etc, that set just might be almost the entire net.

When was the last time you (or anyone) looked up addresses for any
of the hundreds of systems in MU CSSE student labs?   I suspect never,
and I'm not in the least surprised.   Think they never get renumbered?

So, for which was it that we should optimise?  Is the answer really
as obvious as that rhetorical looking question makes it appear?

kre

---

From: [email-masked]
Date: Sat, 20 Jan 2001 21:13:22 +0900

>in the DNS (name -> address translations).

	could you give us more concrete example, so that we can share the
	image in your mind?

	(i am 100% guessing here) if you mean something like dialup home
	networks, wasn't it our goal to assign static address for these
	networks?

itojun

---

From: Robert Elz <[email-masked]>
Date: Sun, 21 Jan 2001 14:39:13 +0700

Date:        Sat, 20 Jan 2001 21:13:22 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	could you give us more concrete example, so that we can share the
  | 	image in your mind?
  | 
  | 	(i am 100% guessing here) if you mean something like dialup home
  | 	networks, wasn't it our goal to assign static address for these
  | 	networks?

No, not that specifically, though including that.

The point was that most systems on the net (that have addresses,
and are in the DNS) never get looked up, they just exist there.
A small fraction of everything that exists is the target of almost
all of the queries.

Yet, when there is a net renumbering, they all get renumbered, not
just the subset that the world cares about.   That tends to bias
the numbers somewhat away from the "millions of lookups per renumber
event" that was implied.

As for static addresses for dialup home nets - I'm not sure that I
care a lot, I'm not sure "dialup" nets will actually exist in significant
enough numbers for it to matter one way or the other very far into
the future.   Or at least I hope they don't.

And in the same thread ...

Antonio Querubin <[email-masked]> asked:
  | Now, how many times would the same single workstation access some
  | shell server, or web server, or mail server, or whatever, somewhere
  | out on the net during that year?  How about in just one day? 

Never - they're all filtered.   But they're all still in the DNS.
And they do all get renumbered from time to time.  I doubt that
we're alone in having large collections of firewalled local hosts.

And to revisit Itojun's point - yes the goal is to have even all of
those have global (static, between renumberings) IPv6 addresses.
(And we happen to have been on the net long enough that we are lucky
enough to have sufficient global IPv4 addresses that they all have
global addresses now).

kre

---

From: Antonio Querubin <[email-masked]>
Date: Sat, 20 Jan 2001 01:19:10 -1000 (HST)

> and I'm not in the least surprised.   Think they never get renumbered?

Let's take just a typical student lab workstation.  How many times would
it probably be renumbered in a year?  DHCP leases may be short but clients
tend to get the same address back week after week, month after month.  If
the addresses are statically assigned, is it more or less likely the
network it's on would be renumbered during that year?

Now, how many times would the same single workstation access some shell
server, or web server, or mail server, or whatever, somewhere out on the
net during that year?  How about in just one day?  Of those servers that
it accesses, how many of those would attempt to perform a reverse-map
check of the client address in some form, either at the moment of access,
or later when some sysadmin is going over some syslogs and doing a
periodic audit, or when some automated logging system spits out a report?

The average user may not bother looking up addresses but machines
sometimes do and sometimes often.

---

From: Robert Elz <[email-masked]>
Date: Tue, 23 Jan 2001 22:06:36 +0700

Date:        Fri, 19 Jan 2001 11:35:14 -0500 (EST)
    From:        Jim Bound <[email-masked]>
    Message-ID:  <[email-masked]>

  | A6 is PS not DS.  If it will not work as is we have every right to oppose
  | it.

All of IPv6 is DS (or less), not full std, so the same could be said.

  | But if we
  | reduce the levels of hierarchy of the A6 DNAMES to max 3 it may work.

Yes - but the problem is that it is very hard to enforce.  Just like the
NS may not name an alias, or MX may not, or aliases may not refer to
other aliases ... they are all supposedly DNS rules, but widely ignored.

  | But if anyone does 10 it will not perform for sometime.

The good thing about this is that people who do that are making it
difficult for themselves - just as people who set up stupid NS
architectures.   Sure it makes extra work for everyone else in the
attempts to resolve the names, but ultimately it is the site with
the bogus setup that suffers most.

The DNS could really do with a good recipe book, explaining to people
what works and what doesn't (not the theory, packets, ... just the how
to stuff).

  | I also think the
  | processing of A6 should not be done on clients but on the servers.

That argument was made (by you, and others) back when A6 was being
debated.   If you care to look back over the archives (IPNG, and
perhaps DNSIND) you will see why things are the way they are.
I'm sure you will recall that it wasn't just that no-one thought
of the possibility...

  | I can't see my IPv6 PDA or my international gaming device having to cache
  | 10 levels and retransmit to get my DNS records.  It just will not work.

Then have your implementation simply give up before going so far.
That's not going to bother anyone with a sensible setup.

kre

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 23 Jan 2001 10:19:31 -0600

Has anyone supplied an IPv6 address for their name server when
registering or updating a domain directly under COM, NET, ORG or EDU?
If so, what happened?

---

From: "Joseph T. Klein" <[email-masked]>
Date: Tue, 23 Jan 2001 13:41:49 -0500

> registering or updating a domain directly under COM, NET, ORG or EDU?

The result is ...

We are unable to process the Host Form below because
of an error within the form. In particular, we noted
the error indicated at the bottom of this message.

In order for Network Solutions to process this Host Form,
you should correct this error and return this form to
[email-masked].

For information about how to properly complete the Host Form,
please review the Host Form instructions available at
ftp://www.networksolutions.com/templates/host-template.txt.

However, the easiest way to complete the Host Form is to use
the online tool we've created. From our home page
at www.networksolutions.com: 1. Click on Make Changes from the blue navigation bar
2. Scroll down to the bottom of the page
3. Under the Expert Path heading, choose Network Solutions forms
4. Select Host Form
5. Follow the on-screen prompts to complete the form
6. Send your completed Host Form via e-mail to
[email-masked]  Prior to updating your host record, we strongly recommend reading
our Frequently Asked Questions about Host registration and
modification, available at
http://www.networksolutions.com/help/host.html  Network Solutions Registrar
http://www.networksolutions.com  hreg04
=========================================================================

=========================================================================

ERROR: invalid char (:) in item 1c
ERROR: invalid char (d) in item 1c
ERROR: invalid char (c) in item 1c
ERROR: invalid char (f) in item 1c
ERROR: invalid char (:) in item 1c
ERROR: invalid char (c) in item 1c
ERROR: invalid char (:) in item 1c
ERROR: invalid char (:) in item 1c
        <2002:d1cf:3c11::1>

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 23 Jan 2001 16:14:49 -0600

> > lookups occur?  so, for which should we optimize?

I can imagine some mobile devices/subnets that are renumbered more
often than their address is looked up.  But, if there's only one nice
thing about A6, it's that you get to break up the bits wherever you
want, including nowhere.

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 23 Jan 2001 16:54:07 -0600

> >of A6 records should be limited to two (or at most 3) levels. ...
> 

<blockquote>
   Until more deployment experience is gained with the A6 record, it is
   recommended that prefix delegations be limited to one or two levels.
   A reasonable phasing-in mechanism would be to start with no prefix
   delegations (all A6 records having prefix length 0) and then to move
   to the use of a single level of delegation within a single zone.  (If
   the TTL of the "prefix" A6 records is kept to an appropriate duration
   the capability for rapid renumbering is not lost.)  More aggressively
   flexible delegation could be introduced for a subset of hosts for
   experimentation.
</blockquote>

Just to drill down a bit, let me repeat:

<blockquote>
   Until more deployment experience is gained with the A6 record, it is
   recommended that prefix delegations be limited to one or two levels.
</blockquote>

---

From: Randy Bush <[email-masked]>
Date: Thu, 25 Jan 2001 11:23:54 +0100

> thing about A6, it's that you get to break up the bits wherever you

here at ripe, operators and implementors are not impressed with a6, dname,
...

randy

---

From: "Perry E. Metzger" <[email-masked]>
Date: 27 Jan 2001 12:40:43 -0500

> here at ripe, operators and implementors are not impressed with a6, dname,

I'm not impressed with A6 -- I'd like it to die.

It does not, in practice, solve the renumbering problem. It just
causes new trouble in the DNS.

The issues in the renumbering problem are database management issues,
not protocol issues. I've been saying this for about six years but I
don't think I get many people to listen to me outside of folks who've
seen things like how MIT Project Athena did machine management.

The sad thing is, it isn't just the IETF types who don't understand
the lesson -- thousands of sysadmins labor late into the night
needlessly because they don't understand how to use relational
databases to make their lives simpler. Entire companies, like Tivoli,
have been founded and operated on a misunderstanding of the systems
management problem.

Anyway, no amount of protocol tinkering will help renumbering
significantly, any more than any number of bamboo air traffic control
towers will cause the planes to land for the cargo cults. The issue
isn't protocol support. It is trivial to convey information via a
dozen protocols -- we've got plenty to handle all of this. The issue
is assuring consistency among hundreds of management databases used in
the average network of machines, and that is *not* a protocol problem.

Perry

---

From: "Joseph T. Klein" <[email-masked]>
Date: Sat, 27 Jan 2001 13:22:43 -0500

For the purposes of public deployment of root IPv6 DNS services
the discussion here seem for the most part in consensus that it
can be achieved without A6. So how about moving forward without it?
IMHO it is more important to start providing the basic
infrastructure for deployment then to try and support the more
arcane elements. Is is most assuredly true that elements having
fundamental problems in scalebility should remain experimental
or be dropped.

Address allocations have been made; stable products are out and
seem to work; it is time to make it so consumers can use IPv6.

I would be interested in seeing some statistical analysis of the
A6 issues rather than less rigorous verbal parley. Do I need to
replicate conditions in my lab to understand the full impact of
each element of IPv6? Does anyone have a publish, reproducible
scientific analysis of the A6 performance issues?

-- 
Joseph T. Klein         [email-masked]        +1 414 915 7489

  "Omnium rerum principia parva sunt." - Marcus Tullius Cicero