Subject: RE: IPv6 dns

From: Randy Bush <[email-masked]>
Date: Wed, 17 Jan 2001 06:54:57 -0800

> I am trying to get someone to tell me exactly what the problem is with the
> existing DNS servers and why there is any deployment problem.  Thus far I
> can find nor get any concrete data that anything is wrong.  I have
> outstanding mail to the DNS chair.
> 
> Until someone can provide some concrete data we should begin deployment.
> 
> There are no DNS police or governments if the owners of the root servers
> will deploy IPv6.  And ngtrans has seen no issue.  
> 
> Clearly A6 records can cause a performance problem at the resolver but
> that should not be news to anyone at this point.

in san diego, we agreed that
  o ngtrans would write up what the v6 community actually needs/wants
  o dnsop would then design and write up how to meet that need
  o the operational community would then do it

but, the chairs of ngtrans have specifically told me that they can see no
actual need at the present time.  hence, i have not whined at the [dns]ops
community for help.  please educate me if i am off the track here.

randy

---

From: "David R. Conrad" <[email-masked]>
Date: Wed, 17 Jan 2001 07:24:11 -0800

Maybe unrelated but has ip6.arpa been delegated yet?

Rgds,
-drc

---

From: Randy Bush <[email-masked]>
Date: Wed, 17 Jan 2001 07:26:18 -0800

> Maybe unrelated but has ip6.arpa been delegated yet?

% dig ip6.arpa. ns

; <<>> DiG 8.3 <<>> ip6.arpa. ns 
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUERY SECTION:
;;      ip6.arpa, type = NS, class = IN

;; AUTHORITY SECTION:
ARPA.                   1D IN SOA       A.ROOT-SERVERS.NET. hostmaster.nsiregistry.NET. (
                                        2001011600      ; serial
                                        30M             ; refresh
                                        15M             ; retry
                                        1W              ; expiry
                                        1D )            ; minimum

;; Total query time: 170 msec
;; FROM: rip.psg.com to SERVER: default -- 147.28.0.3
;; WHEN: Wed Jan 17 07:25:44 2001
;; MSG SIZE  sent: 26  rcvd: 107

---

From: "David R. Conrad" <[email-masked]>
Date: Wed, 17 Jan 2001 07:33:27 -0800

Thanks, I was aware its not in the DNS yet.  Apologies, I guess I should've 
said 'adminstratively delegated' (or perhaps, sadly, who will be making the 
decision to adminstratively delegate)?

Rgds,
-drc

---

From: Randy Bush <[email-masked]>
Date: Wed, 17 Jan 2001 07:41:46 -0800

> decision to adminstratively delegate)?

matt and i are behind on our homework to write it up.  mea culpa.

randy

---

From: Jim Bound <[email-masked]>
Date: Wed, 17 Jan 2001 15:03:21 -0500 (EST)

Hi Randy,

> community for help.  please educate me if i am off the track here.

OK I see the disconnect.  Let me try.  3GPP IP trials have already started
and we have serious ISPs about IPv6 like Zama out there and others are
preparing for real IPv6 production deployment in 2001.  This is driven by
some edge and Wireless providers in Europe and Asia.  A sprinkling in the
U.S.  We need to be sure the DNS root servers can support IPv6 RR records
in the near future.  

I did not hear the ngtrans folks say they see no need for root DNS servers
ito support IPv6 DNS records, but thats not their call or authority. 
Thats the markets call. I will go to the IPv6 Forum where the expertise is
working with the market and deploymennt and ask the question.  But realize
that not all providers, users, vendors, ISVs etc.. of the IPv6 Forum
member body will be able to disclose all public details of their planed
deployment. 

I think if the list above is done that will be good and really useful.
I have also asked several of our IPv6 Technical directorate members to
work with Olafur to understand the problem and then we can relate to the
deployment issues in an intelligent manner.

I will conect these folks and myself with you offline.

thanks (we do need these write-ups A.S.A.P..).
/jim

---

From: Randy Bush <[email-masked]>
Date: Wed, 17 Jan 2001 16:55:41 -0800

> I don't know what you've been told, but some of us are very, very
> unhappy at the lack of roots that speak v6 transport at the moment.

you have my deepest sympathy in your unhappiness.

but perhaps you should communicate TECHNICAL NEEDS to ngtrans, which,
depsite rantings and ravings about massive marketplace demands, is the part
of ietf where we deal with these things.

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 17 Jan 2001 17:24:44 -0800

>> depsite rantings and ravings about massive marketplace demands, is the
>> part of ietf where we deal with these things.
> You may recall that I did just that at the ngtrans meeting.

i do not recall.  you may want to get the minutes updated.

and, if you really care about getting something done, maybe you should
present the technical argument for what it is you actually need here.

randy

---

From: Keith Moore <[email-masked]>
Date: Thu, 18 Jan 2001 00:07:36 -0500

> but perhaps you should communicate TECHNICAL NEEDS to ngtrans

please explain what is non-technical about the need to have at least
one or two servers in place for ip6.arpa?  

or does the lack of a specific number in Perry's request somehow
make it non-technical?  

seems like the dnsops folks the ones to determine the number anyway.

Keith

---

From: Randy Bush <[email-masked]>
Date: Wed, 17 Jan 2001 22:10:29 -0800

i think this discussion was played in the dnsop meeting in san diego.

> The situation is fairly simple. A lot of us would like to be able to
> deploy v6 only hardware, without depending on v4 translator boxes in
> various places.

so how will you get dns resolution for, e.g., psg.com?

> Now you may argue (reasonably) that you also need lots of other hosts
> further along in the DNS server hierarchy running v6 as well, and
> you're right -- but that doesn't lessen the argument for why some of
> us want roots running v6 transport deployed.

i believe the point was, given that it is believed to be unsafe to deploy a
rogue root server that is actually used, or at least it needs further study,
that maybe you can conduct testing that v6 dns servers work a bit lower in
the dns hierarchy just as usefully.

during that time, you have a nice window to explain what you really want to
test at the root, and folk can look at constructing a prudent and documented
experiment.

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 17 Jan 2001 22:39:15 -0800

> Why do a rogue server? Why not just have the existing root operators
> deploy v6 transport capable root servers that are official?

no disagreement there.

> If you feel that it is too risky to do that on the existing hardware ...

obviously you missed the entire discussion.  this is not about the usual
software bugs.  it's about cache poisoning of old servers in v4 space.

> I would ask you to state a reason (other than possible expense) why
> having a couple of "clone servers" run and administered by the same
> folks running the current roots but on the 6bone and accepting
> requests over v6 transport could cause an operational problem. What is
> it, exactly, that we're fearing here?

this was discussed in dnsop, and is in the dnsop minutes.  it was discussed
in ngtrans.

to repeat the presentation:

----

the v6 directorate and the i* would appreciate if today's dnsop meeting
would add the following to its agenda:

  o if there actually is a need for to experiment with a separate v6 root,

  o what is the cache hints and root zone content, and, given that

  o what are the possiblity vulnerabilities of the general internet, and if
    there are any

  o what are the limits/guidelines needed to prudently protect the net?

an example of a worry is cache poisoning of an antique v4 bind.

----

and there are thousands of vulnerable v4 binds still out there.

randy

---

From: [email-masked]
Date: Thu, 18 Jan 2001 18:56:18 +1100

> an example of a worry is cache poisoning of an antique v4 bind.

	A quick look at the code says that AAAA/A6 records won't
	be cached.  If fact you can use this technique for finger
	printing nameservers.

	Anti-cache poisoning techniques depend upon ownernames not
	type.

	The real worry with BIND 4 is that it does not support TCP
	retries.   So as long a mix of A and A6/AAAA records make
	it into the additional section and we don't increase the
	answer section things should be ok.

	Mark

--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Perry E. Metzger" <[email-masked]>
Date: 17 Jan 2001 19:52:15 -0500

Perry

---

From: "Perry E. Metzger" <[email-masked]>
Date: 17 Jan 2001 20:11:28 -0500

--
Perry E. Metzger		[email-masked]
--
Quality NetBSD CDs, Support & Service. http://www.wasabisystems.com/

---

From: "Perry E. Metzger" <[email-masked]>
Date: 17 Jan 2001 20:34:45 -0500

> i do not recall.  you may want to get the minutes updated.

The minutes gave a one line summary of my original tiresome rant. They
aren't particularly accurate, but it is an effort to get them modified.

The situation is fairly simple. A lot of us would like to be able to
deploy v6 only hardware, without depending on v4 translator boxes in
various places. If we actually claim to be transitioning to v6, this
is not an unreasonable desire, eh?

Well, part of being able to actually run v6 is having DNS up and
working for real for v6 only machines. Without the DNS, a modern
machine is pretty much lost. You can do okay with a dual stack
translator box, but if you don't have one, and there are no v6
transport responding roots, you're screwed.

Is that a reasonable summary?

---

From: "Perry E. Metzger" <[email-masked]>
Date: 18 Jan 2001 01:24:42 -0500

> so how will you get dns resolution for, e.g., psg.com?

Over v6 only transport, you couldn't -- yet. Eventually, I'd do a v6
transport query to . for .com, do a v6 query to the ns'es for .com for
psg.com, etc.

The point is, though, we're going to need the roots to have v6
addresses and accept requests over v6 transport sooner or later.

If you feel that it is too risky to do that on the existing hardware
because of concerns about less well tested software revisions, for the
moment you can use new hardware in parallel -- no one will notice, and
the load is likely to be miniscule at the moment so it is okay if the
v6 machines aren't quite so performant. Note that I'm not suggesting
"rogue" root servers in parallel -- I'm suggesting that the folks
running the existing servers operate these, and only until they feel
more comfortable with the stability of things like Bind v9 and the
revs of the OSes that do v6 and such.

> test at the root,

I don't want to test. I want to use. I've already got v6 deployed on
my own networks. Half the time when I move a file around or remote log
in I have no clue if it is going over v6 or v4.

This isn't an experimental protocol any more. A year ago it was
different -- a year ago I couldn't actually "eat my own dogfood" --
but now that's totally changed. v6 is now thoroughly usable. The time
for tests is over. It is time to deploy. The problem is that we've got
things that are still missing. v6 transport reachable root servers are
one of them.

On the DNS side, there isn't much of an experiment to be done here --
we know you can encapsulate DNS messages in v6 datagrams.

> and folk can look at constructing a prudent and documented experiment.

The only thing I can think of is (possible) visibility in caches of A6
records for the roots by resolvers that would crash if they saw them.
If that's really going to destroy the internet and we're never going
to face it, we might as well just give up on deploying v6 right now,
because we'll have to deal with those things sooner or later.

---

From: Randy Bush <[email-masked]>
Date: Thu, 18 Jan 2001 04:47:37 -0800

> % 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: Bill Manning <[email-masked]>
Date: Thu, 18 Jan 2001 04:00:54 -0800 (PST)

The RSSAC has talked about v6 roots for the past couple of
years. There are IESG and IAB members as part of this group.
Several members of the RSSAC have established a testbed 
and there has been discussion on how to open it up for more
general use. Perhaps some of the material from the last
few RSSAC discussions might be useful to ngtrans & dnsops?
Or the IESG & IAB members of RSSAC could pass on that information
to the protocol organization, the IETF.

% 
% 
% > > Why do a rogue server? Why not just have the existing root operators
% > > deploy v6 transport capable root servers that are official?
% > 
% > no disagreement there.
% > 
% > > If you feel that it is too risky to do that on the existing hardware ...
% > 
% > obviously you missed the entire discussion.  this is not about the usual
% > software bugs.  it's about cache poisoning of old servers in v4 space.
% > 
% > > I would ask you to state a reason (other than possible expense) why
% > > having a couple of "clone servers" run and administered by the same
% > > folks running the current roots but on the 6bone and accepting
% > > requests over v6 transport could cause an operational problem. What is
% > > it, exactly, that we're fearing here?
% > 
% > this was discussed in dnsop, and is in the dnsop minutes.  it was discussed
% > in ngtrans.
% > 
% > to repeat the presentation:
% > 
% > ----
% > 
% > the v6 directorate and the i* would appreciate if today's dnsop meeting
% > would add the following to its agenda:
% > 
% >   o if there actually is a need for to experiment with a separate v6 root,
% > 
% >   o what is the cache hints and root zone content, and, given that
% > 
% >   o what are the possiblity vulnerabilities of the general internet, and if
% >     there are any
% > 
% >   o what are the limits/guidelines needed to prudently protect the net?
% > 
% > an example of a worry is cache poisoning of an antique v4 bind.
% 
% 	A quick look at the code says that AAAA/A6 records won't
% 	be cached.  If fact you can use this technique for finger
% 	printing nameservers.
% 
% 	Anti-cache poisoning techniques depend upon ownernames not
% 	type.
% 
% 	The real worry with BIND 4 is that it does not support TCP
% 	retries.   So as long a mix of A and A6/AAAA records make
% 	it into the additional section and we don't increase the
% 	answer section things should be ok.
% 
% 	Mark
% 
% > 
% > ----
% > 
% > and there are thousands of vulnerable v4 binds still out there.
% > 
% > randy
% --
% Mark Andrews, Nominum Inc.
% 1 Seymour St., Dundas Valley, NSW 2117, Australia
% PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
% 

-- 
--bill

---

From: Bill Manning <[email-masked]>
Date: Thu, 18 Jan 2001 04:14:09 -0800 (PST)

% 
% randy
% 

	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. 
	I note that we will have this problem regardless and more
	esp. as we hit "unknown" RR types.  Zones won't load. 
	Perhaps we should have dnsops worry about the deployment of
	new types, be it RR or Class?

-- 
--bill

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Thu, 18 Jan 2001 09:38:06 -0500

See <ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-unknown-rrs-00.txt>.

Donald

From:  Bill Manning <[email-masked]>
Message-Id:  <[email-masked]>
To:  [email-masked] (Randy Bush)
Date:  Thu, 18 Jan 2001 04:14:09 -0800 (PST)
Cc:  [email-masked] (Perry E. Metzger), [email-masked] (Jim Bound),
            [email-masked], [email-masked] (dns op wg),
            [email-masked]
In-Reply-To:  <[email-masked]> from "Randy Bush" at Jan 17, 2001 10:39:15 PM

---

From: "Perry E. Metzger" <[email-masked]>
Date: 18 Jan 2001 09:10:37 -0500

> 	answer section things should be ok.

We could easily just have the roots only reply with AAAA/A6 records
for themselves when contacted over v6 transport. That should lessen
the issue for old clients, eh?

---

From: "Perry E. Metzger" <[email-masked]>
Date: 18 Jan 2001 09:17:01 -0500

> of course there are folk with the opposite opinion.

It isn't obvious to some of us that the net would break. Many of us
have already deployed new record types (not just AAAA or what have
you) in our DNSes and somehow there aren't widespread reports of
random resolvers detonating when they look at our zones.

In fact, I'll note that there are a *lot* of them our there.  You
would imagine with all the mail passing through some of said zones
that such detonations would occur.  By now, I think we would have
gotten extensive field reports about trouble -- even if only in the
form of worried messages from CERT about a new evil way to attack DNS
servers.

Indeed, if you guys are right and all this crashes machines left and
right, it is a serious security hole -- one that will probably be
fixed pretty damn fast once it is discovered by The Evil People. If
you can demonstrate the problem, CERT wants to know -- now, I suspect,
before The Evil People find out.

Perry

---

From: Randy Bush <[email-masked]>
Date: Thu, 18 Jan 2001 15:22:25 -0800

> 	And these folks tend to win operational/engineering arguments,
> 	otherwise we'd still be running:
> 	
> 	RIP, NCP, BGPv1, BGPv2, BGPv3, 
> 	Sometimes, you've got to cut the cord.

hint: the above protocols can still be run and not get damaged by boy
engineers who seem to like to argue.

---

From: Bill Manning <[email-masked]>
Date: Thu, 18 Jan 2001 14:58:21 -0800 (PST)

% 
% > % 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
% 

-- 
--bill

---

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

% 
% 
% [email-masked] writes:
% > 	The real worry with BIND 4 is that it does not support TCP
% > 	retries.   So as long a mix of A and A6/AAAA records make
% > 	it into the additional section and we don't increase the
% > 	answer section things should be ok.
% 
% We could easily just have the roots only reply with AAAA/A6 records
% for themselves when contacted over v6 transport. That should lessen
% the issue for old clients, eh?
% 
% --
% Perry E. Metzger		[email-masked]
% --
% Quality NetBSD CDs, Support & Service. http://www.wasabisystems.com/
% 

That might not be prudent. Unfragmented UDP packet sizes are different
and keeping a mixed A/AAAA bag might have soem trouble fitting into the
LCD packet size.

-- 
--bill

---

From: [email-masked] (Bruce A. Mah)
Date: Thu, 18 Jan 2001 17:37:04 -0800

A semi-related remark...I was mentioning this thread to Karl Auerbach 
and he says:

> If you post to that list you may want to point folks at me and let 'em
> know that I'm working within ICANN to try to figure out what we need to do
> to get the v6 aspects of the name registration system working and I'd love
> to talk with some folks who have ideas about what is needed.

Mail to <[email-masked]>.

Cheers,

Bruce.

---

From: "Perry E. Metzger" <[email-masked]>
Date: 19 Jan 2001 03:55:42 -0500

> and keeping a mixed A/AAAA bag might have soem trouble fitting into the

I'm afraid that I don't understand your point -- could you explain it
further?

.pm

---

From: Randy Bush <[email-masked]>
Date: Fri, 19 Jan 2001 13:54:34 -0800

> On the one hand we have a few people who are afraid that we might
> cause lossage in oldish software if said software is exposed to new
> and unknown record types such as AAAA or A6 in additional sections.
>
> So, how's that for shooting at both parties? ;-)

bad aim.  the worry is not AAAA and A6 RRs.  it is bogus NS RR for the root
zone.

randy

---

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

> I've asked Randy explicitly if he felt that there was an issue here,
> and the only issue he can articulate is a worry about cache
> contamination, not a worry about hosts going ga-ga when they get
> exposed to quad-A or A6.

likely only because of lack of clue about this aspect of the problem.
other then udp size problems, i am not sure what other aspects of aaaa
and a6 sould worry me.  but bill seemed worried.  and if bill is even the
tensiest concerned, then i would probably be terrified if i understood
the issue.  :-)

sorry to be so boring here.  but it is because we don't clearly and
crisply understand what needs to be tested, that we do not understand
what a test plan would be, and thus we can not judge any dangers it might
pose so we can try to protect against them.

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 19 Jan 2001 14:44:06 -0800

> In what way will actual AAAA or A6 records for root zone hosts be
> "bogus"?

again, lack of specifics of a test plan don't make answering ANY questions
easy.

but once again and again and again and again ...

o if you deploy a rogue root server
o its ip address will be cached in other servers
o and one or more of those servers may indirectly pass that additional data
  to deployed v4 binds that are quite vulnerable to cache poisoning

and yes, that is old vulnerable software and should be updated.  but it is
not our prerogative to break it any more than it is a cracker's prerogative
to break into a vulnerable site.

and once again and again and again and again ...

this is just one worry about one *rumored* experiment.  without a statement
of specifically what needs to be tested, and the corresponding test plan,
discussion of vulnerabilities in a non-existant test plan are tenuous at
best.

randy

---

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

> one or two servers in place for ip6.arpa?  

you may notice the draft today which starts that process.

> or does the lack of a specific number in Perry's request somehow

the disorganization of the "we need X" hysteria is deliciously exemplified
by perry's request not saying a single thing about ip6.arpa.

randy

---

From: "Perry E. Metzger" <[email-masked]>
To: Randy Bush <[email-masked]>
Cc: Havard Eidnes <[email-masked]>, [email-masked], [email-masked],
	[email-masked], [email-masked]
Subject: Re: IPv6 dns
Date: 19 Jan 2001 18:53:29 -0500

Randy Bush <[email-masked]> writes:
> >> bad aim.  the worry is not AAAA and A6 RRs.  it is bogus NS RR
> >> for the root zone.

As a trial balloon, lets assume the strawman I mentioned earlier:
pending a feeling of operational stability about Bind 9, selected
operators of root name servers deploy (officially) parallel machines
running v6 transport serving ".". Once Bind 9 is judged stable, the
machines can be "merged" again -- separate hardware is just a check
against problems with Bind 9 during shakedown. We also assume the v6
machines would be treated as "first class citizens" -- the only reason
for the caution is the newness of the software causing a desire for a
safety measure, not a notion that these are "experimental" machines.

We further assume that no root server machines return AAAA or A6
records for machines serving "."  unless it gets queried over v6
transport, in order to minimize the "can't fit in a datagram" issue.

> o if you deploy a rogue root server

What I am proposing are in no way rogue servers -- they're quite
legitimate, run by the same folks, storing the same data, and
eventually being (in fact) the same machines.

> o its ip address will be cached in other servers

...which is okay since they're real servers with perfectly fine data...

>   to deployed v4 binds that are quite vulnerable to cache poisoning

...but it is only cache poisoning if the data is inaccurate and in
this instance, it isn't.

> and yes, that is old vulnerable software and should be updated.

Vulnerable to *what* though. We've spoken of the danger of bad data
flowing through the system but none of the data we are talking about
is bad.

> this is just one worry about one *rumored* experiment.

You're speaking probably of the notion of the Viagenie test root
server running v6. I'd like to get beyond that for now and to the
wider issue of deploying real v6 transport aware roots, and what the
issues there might be.

---

From: Randy Bush <[email-masked]>
Date: Fri, 19 Jan 2001 16:23:26 -0800

> By the way, the overall technical need is for the centralized
> infrastructure of the net (which in practice turns out just to be our
> DNS infrastructure) to properly support v6 users. That means we need
> three things: proper support for reverse lookups, proper support for
> v6 records in the NS records deployed by the roots and various TLDs,
> and proper support for queries over v6 transport by machines like the
> root servers and the servers for various TLD zones.
> 
> Note that these needs can be addressed in steps without much
> trouble. Providing v6 transport aware root servers can be segregated
> from the problem of providing reverse lookups, which can be segregated
> from the problem of having NS records associated with machines with
> AAAA records for, say, wasabisystems.com
> 
> Right now, my initial concern is getting roots with v6 addresses that
> reply to queries made over v6.

could you please expand each of these items in just a bit more detail?

like make what needs to be tested a bit more explicit e.g. "(proper support
for reverse lookups, proper support for v6 records in the NS records
deployed by the roots and various TLDs" is open to interpretation)

and then just a wee bit of motivation, so folk can say "yup, i see why
that is important."

and then expnad a bit on the ordering, i.e. which comes second, ...

randy

---

From: Keith Moore <[email-masked]>
Date: Fri, 19 Jan 2001 21:18:10 -0500

Perry,

regarding the new root servers which respond to queries over IPv6 -
one thing you didn't quite mention, but I suspect is necessary, is 
that their IPv6 addresses be stable. that is, that once root 
servers are established at these addresses and are advertised,
that there will continue to be authoritative root servers at 
those addresses for the forseeable future.

this has implications for the roots; but perhaps also, for their
ISPs and for address assignment in general.  regardless of what
assumptions we make about IPv6 renumbering elsewhere, we don't
want to renumber the root servers very often.

Keith

---

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

> want to renumber the root servers very often.

and i thought y'all were talking about an *experiment*.

randy

---

From: Marc Blanchet <[email-masked]>
Date: Sun, 21 Jan 2001 10:41:13 -0500

nothing different from v4, no?

Marc.

At/À 21:18 2001-01-19 -0500, Keith Moore you wrote/vous écriviez:
>---------------------------------------------------------------------
>The IPv6 Users Mailing List
>Unsubscribe by sending "unsubscribe users" to [email-masked]

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: Keith Moore <[email-masked]>
Date: Sun, 21 Jan 2001 20:41:42 -0500

> nothing different from v4, no?

fundamentally, no.  in either case you want to arrange for the root
servers to have addresses that are more stable than the average IPv# 
address. 

Keith

---

From: "Perry E. Metzger" <[email-masked]>
Date: 19 Jan 2001 19:09:56 -0500

> one or two servers in place for ip6.arpa?  

Those would be nice, yes...

---

From: "Perry E. Metzger" <[email-masked]>
Date: 19 Jan 2001 17:28:06 -0500

I agree with many things you say, but:

Havard Eidnes <[email-masked]> writes:
>  o Itojun informing us that deployment of AAAA has already happened
>    at various places in the DNS tree, and that some registries
>    already handle registration of IPv6-related glue, and that no
>    problems have been observed so far.
> 
> An argument against Itojun's experiences could be that the set of
> name servers actually exposed to their IPv6 records is probably quite
> small.

I would strongly argue that it isn't. Any time electronic mail gets
sent to folks at KAME, or to me, or to lots of other people, the hosts
on the other side get exposed to AAAA records or worse. There are
probably, without exaggeration, at least hundreds of thousands of hosts
that have been exposed so far -- and nothing bad has happened to them.

---

From: Havard Eidnes <[email-masked]>
Date: Fri, 19 Jan 2001 21:47:07 +0100

Hi,

please let me stick my hand into this hornet's nest...

On the one hand we have a few people who are afraid that we might
cause lossage in oldish software if said software is exposed to new
and unknown record types such as AAAA or A6 in additional sections.
While no concrete evidence has been presented that specific problems
will in fact ensue and NOCs will start getting calls left and right
from irate users whose name servers are experiencing untold problems,
the spectre of this happening has been sufficiently successfully
painted on the wall to cause some people to be (perhaps overly)
cautious, and request documentation of what exactly is planned/
requested and "evidence" to be reasonably assured that the above
scenario will indeed not happen were the plans to be followed.  This
group is essentially putting the "burden of proof" on the IPv6
proponents.

On the other hand we have some people in the IPv6 crowd who want to
deploy IPv6-only hosts, and who wish to use IPv6 as much as possible,
including for DNS name resolution.  A (perhaps snide) remark could be
that it's not obvious (to me at least) whether interaction with the
IPv4-only parts of the Internet is part of the requirement set for
these hosts.

On the "concrete information" front, the current discussion has not
brought forth too many fruits, except for:

 o Mark Andrews saying that based on quick source code perusal, AAAA
   or A6 records will not be cached by BIND version 4, but that there
   may be some caveats related to missing TCP query retries.

An argument against Itojun's experiences could be that the set of
name servers actually exposed to their IPv6 records is probably quite
small.  However, how do we get an existance proof that this will
indeed not cause problems when deployed in a more "visible" area
without actually doing such a deployment?  (Nice chicken/egg
situation.)  I think that at some point you need to make the move.

I agree that it would be highly unwise to do an unannounced and
undocumented experiment with the root name service, so I agree that
whatever is to be done in this area should be properly planned,
documented and tested in (relatively) controlled environments (and
test experiences documented) before we go ahead with a wider
deployment.  I think this is all Randy's asking for.

Though it is relatively independent of the current discussion it
should perhaps be mentioned that many of the old name server versions
out there have known security problems (such as being vulnerable to
IPv4 cache pollution and susceptible to buffer overrun-related
security vulnerabilities), so even if they would not get into any
sort of trouble due to more widespread deployment of IPv6 RRs in the
DNS it would be a good idea to push for an upgrade of them anyway.  I
mean, it's not as if these problems have not been known and
documented for quite a while...

Best regards,

- Håvard

---

From: "Perry E. Metzger" <[email-masked]>
Date: 21 Jan 2001 13:58:57 -0500

Bill Manning <[email-masked]> writes:
> THe last time it was seriously raised was at the Joint IETF/ISOC mtg in 
> Montreal. The failure modes are pretty spectactular, at least until
> DNSsec is deployed and applications can verify the accuracy of the data
> received from a root server.

You can probably manage to forge data in a significant way right now
-- I'm not sure host routes in the DFZ would make that substantially
worse. It is also possible to use standard policy mechanisms to note
attempts to hijack one of the routes...

.pm

---

From: "Perry E. Metzger" <[email-masked]>
Date: 20 Jan 2001 05:06:46 -0500

> and i thought y'all were talking about an *experiment*.

I believe I've said about five or six times that I, at least, am not
talking about an experiment. I'm talking about *deployment*. I can't
speak for other people, but from my point of view, IPv6 is no longer
"experimental".

Perry

---

From: Havard Eidnes <[email-masked]>
Date: Sat, 20 Jan 2001 16:46:38 +0100

> > I don't suppose use of EDNS0 would serve as a suitable
> > alternative distinguishing criterion for whether to add v6
> > glue records to replies?
>
> The issue is not the vintage of the resolver -- it is a UDP
> datagram length problem. We assume a much larger v6 datagram
> can get through without the risk of fragmentation. Such a v6
> datagram is reasonably large at 1280 bytes. The v4 datagrams
> have much less space for v6 glue records, since we can only
> assume 512 bytes of payload before fragmentation. (The truth is
> it would probably be okay if we assumed most of the world had a
> much larger MTU even for v4. That's a whole different issue,
> though.)

IPv6 may provide a larger minimum MTU guarantee than IPv4.  I
guess that also means that DNS over UDP over IPv6 can in
principle use the larger datagram size (?).

I have also heard mutterings to the effect that IPv6
implementations should be required to use EDNS0, thus, it may
also be a better distinguishing factor, and has a better
probability of making dual-stack machines aware of IPv6 RRs
should the query happen to be made over IPv4 transport.

Regards,

- Håvard

---

From: "Perry E. Metzger" <[email-masked]>
Date: 19 Jan 2001 19:27:28 -0500

Havard Eidnes <[email-masked]> writes:
> > We further assume that no root server machines return AAAA or
> > A6 records for machines serving "." unless it gets queried over
> > v6 transport, in order to minimize the "can't fit in a
> > datagram" issue.
> 
> You'll have to excuse my inexperience with the intimate details
> of BINDv9, but is this code already part of BINDv9?

No, but from the looks of things, it should straightforward.

> I don't suppose use of EDNS0 would serve as a suitable alternative
> distinguishing criterion for whether to add v6 glue records to
> replies?

The issue is not the vintage of the resolver -- it is a UDP datagram
length problem. We assume a much larger v6 datagram can get through
without the risk of fragmentation. Such a v6 datagram is reasonably
large at 1280 bytes. The v4 datagrams have much less space for v6 glue
records, since we can only assume 512 bytes of payload before
fragmentation. (The truth is it would probably be okay if we assumed
most of the world had a much larger MTU even for v4. That's a whole
different issue, though.)

> ...and no new IPv4 address would be added for the new "separate"
> v6-serving hosts, I suppose.

Correct.

---

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

Randy Bush <[email-masked]> writes:
> and a6 sould worry me.

I think the UDP size problem isn't an issue if we have the roots only
reply with AAAA or A6 if queried over v6. That way, the v4 UDP
datagrams won't be impacted by the new records for ".". 

> but bill seemed worried.  and if bill is even the

Pardon, but which Bill? Manning?

---

From: "Perry E. Metzger" <[email-masked]>
Date: 19 Jan 2001 18:53:29 -0500

---

From: Bill Manning <[email-masked]>
Date: Sun, 21 Jan 2001 10:00:39 -0800 (PST)

% 
% Perry,
% 
% regarding the new root servers which respond to queries over IPv6 -
% one thing you didn't quite mention, but I suspect is necessary, is 
% that their IPv6 addresses be stable. that is, that once root 
% servers are established at these addresses and are advertised,
% that there will continue to be authoritative root servers at 
% those addresses for the forseeable future.
% 
% this has implications for the roots; but perhaps also, for their
% ISPs and for address assignment in general.  regardless of what
% assumptions we make about IPv6 renumbering elsewhere, we don't
% want to renumber the root servers very often.
% 
% Keith
% 

The stablitity of the addressing plan for a root structure was delt with
about 5 years ago. THe cache usued to have TTL values of all nines, e.g.
never expire. This effects how persistant any specific address has to be
in the root cache. The values were changed to a week, forcing cahce aging to 
occur. 
That said, I think that long term, stablitiy in the numbering space is 
vital to DNS stability. V6 is still young and to gain experience, we 
should consider that renumbering will be more frequent in that space.

-- 
--bill

---

From: Havard Eidnes <[email-masked]>
Date: Sat, 20 Jan 2001 01:20:13 +0100

Regards,

- Håvard

---

From: "Perry E. Metzger" <[email-masked]>
Date: 20 Jan 2001 05:08:39 -0500

> want to renumber the root servers very often.

It has occurred to me for some time that we should be willing to
supply host routes for the root servers in the default free
zone. We're only talking about a tiny number of servers, and it is the
only service for which this is necessary. Yes, it would end up adding
a dozen extra routes to the tables, but I think that in general it is
probably the right way to go.

Anyone else have thoughts on that notion?

Perry

---

From: "Perry E. Metzger" <[email-masked]>
Date: 21 Jan 2001 17:18:26 -0500

> nothing different from v4, no?

I think the assumption has been in the v6 world that we'll be
renumbering a lot more often. There are, however, a few hosts that we
pretty obviously don't know how to renumber often: the root name
servers.

Perry

---

From: "Perry E. Metzger" <[email-masked]>
Date: 19 Jan 2001 17:29:09 -0500

---

From: Bill Manning <[email-masked]>
Date: Sun, 21 Jan 2001 10:04:12 -0800 (PST)

% It has occurred to me for some time that we should be willing to
% supply host routes for the root servers in the default free
% zone. We're only talking about a tiny number of servers, and it is the
% only service for which this is necessary. Yes, it would end up adding
% a dozen extra routes to the tables, but I think that in general it is
% probably the right way to go.
% 
% Anyone else have thoughts on that notion?
% 
% Perry
% 

-- 
--bill

---

From: Bill Manning <[email-masked]>
Date: Sun, 21 Jan 2001 14:04:57 -0800 (PST)

% 
% 
% Bill Manning <[email-masked]> writes:
% > THe last time it was seriously raised was at the Joint IETF/ISOC mtg in 
% > Montreal. The failure modes are pretty spectactular, at least until
% > DNSsec is deployed and applications can verify the accuracy of the data
% > received from a root server.
% 
% You can probably manage to forge data in a significant way right now
% -- I'm not sure host routes in the DFZ would make that substantially
% worse. It is also possible to use standard policy mechanisms to note
% attempts to hijack one of the routes...
% 
% .pm
% 

	Two considerations:
	1) gettting general consensus by Operators to add this varience
	   to their SOP on which things get intot their routing tables
	  (VERY HARD)
	2) Forged route announcements... folks pay more attention to 
	   a forged entry for 18.0.0.0/8 than 192.168.10.10/32... although
	   this "feature" is a key component of the Otha-san/Hardie 
	   "anycast" root server (drafts).

	I'd really want to have some method to authenticate the chain
	and have an imbedded x509 CERT ... if we go to host routes.
	(mind, I think its a good idea :)

--bill

---

From: "Perry E. Metzger" <[email-masked]>
Date: 19 Jan 2001 19:57:44 -0500

> and then expnad a bit on the ordering, i.e. which comes second, ...

(I'll continue to note that very little here actually needs testing --
only, perhaps, Bind v9).

Reverse resolution:

Reverse resolution actually works right now -- the ip6.int zone is out
and functioning. All that was really required for this was the
creation of NS records for IP6.INT in the root to machines that are
properly maintained, resolving the delegation hierarchy for the PTR
records.

There don't seem to be a plethora of servers for it, however. Only two
are listed, and only one of those has a AAAA record associated with it
(z.ip6.int). This is (to say the least!) not enough
redundancy. Therefore, I'd ask that a couple more machines be
deployed. Note that this is *not* a request for testing of any sort --
there is nothing to test. It works now. It is just an operational worry
about losing reverse resolution.

v6 transport capable servers:

In order for a host running v6 only to do DNS queries, it needs to be
able to make queries over the only protocol it speaks -- IPv6. There
are two ways to do this. For the moment, we all make do with proxies
that speak both v4 and v6 and which will make our queries for us into
the v4 world.

However, if we REALLY are going to deploy v6 universally, we
eventually need to be able to make queries without needing
proxies. That means that we need (someday, not now!) for every DNS
server to speak IPv6.

Now, the most obvious lack in the universe of v6 accessible DNS
servers is the root name service. If there are no root servers with v6
addresses, you literally can't even make your first DNS query without
getting stuck (or using a proxy).

It would be very useful, then, if some subset of
?.ROOT-SERVERS.NET. spoke v6 or had "twins" operated by the same folks
that spoke v6. The latter expedient (as I've noted) may be necessary
to provide some safety against the perceived newness of Bind 9.

Eventually, we would like to take this to the next step, and have
servers for all TLDs that speak v6. The roots, however, are a logical
starting point, as they are literally the first query you make.

Once that is done, we'll eventually try to get the servers for .AU and
.GOV and all the rest to speak v6, too, but the root is the start.

v6 records in the DNS:

Currently, if I ask Network Solutions to add a DNS server to its
database so I can use it for my zone (see
http://www.networksolutions.com/cgi-bin/makechanges/itts/host ), or
indeed ask anyone else, they have a single slot that says "IP Address"
for the server. Presumably their database would not be pleased if I
told it the IP address was 3ffe:1ce1:0:fe10::1 -- and there is in any
case no way to tell them that this is a AAAA (or A6), not an A.

We therefore eventually need to get the registrars capable of
accepting these records for inclusion within .COM or .NET or .ORG or
.CO.UK or whatever.

Eventually (many years from now) we would assume nearly ALL records
would be A6 or AAAA and very few would be A records, but for the
moment, just allowing those of us who choose to register our DNS
servers' IPv6 addresses within the database to do so would be a good
start. I'd like to do a "dig -t ns kame.net" and get v6 addresses in
addition to v4 addresses for the servers.

Ordering considerations:

There is no real ordering consideration here so far as I can
tell. These three areas are pretty much independent.

Is this a good start, Randy? I'm sure I've left a bunch of stuff
out. What would you like added?

Perry

---

From: "Cricket Liu" <[email-masked]>
Date: Tue, 23 Jan 2001 06:45:58 -0700

> in the root cache. The values were changed to a week, forcing cahce aging
to

More significantly, BIND's behavior changed and BIND began sending
system queries to get a "live" set of root NS RRs rather than using the
NS RRs in the root hints file.  The records in the root hints file just help
BIND find a name server to send the system query to.

(The current TTL on the root name servers' A RRs is 41 days, 16
hours.  If that's an implication of the stability of those addresses, I'd
say they're fairly stable.)

Regarding this proposed "reply with A6/AAAA RRs only if queried
over IPv6" suggestion:  Even if we imagine this enhancement patched
in to BIND 9.1.0 and deployed on the root name servers, how are we
going to prevent non-root name servers from redistributing the
A6/AAAA RRs?  For example, if my dual-homed IPv4 and IPv6
name server gets A6 RRs in response to its system query and caches
those, but lacks the patch, it'll respond with those A6 RRs to:

1.  Any name server that sends it a system query (because it's
misconfigured to think my dual-homed name server is a root name
server, for example).

2.  Any name server that sends it a query for a domain name
in a zone that it's lame for, assuming my dual-homed name
server can't find a set of enclosing NS RRs "closer" than the
root.

In case 2, a newer name server that received the response wouldn't
cache the RRs because of credibility, but an older BIND name
server would.

I'm pointing this out not because I'm sure that advertising A6 RRs
is a problem--I think the biggest problem may be inducing TCP
retries because of truncation--but because I've found it's really
difficult to "compartmentalize" cached RRs and therefore we
shouldn't count on being able to protect all of the Internet's name
servers from AAAA and A6 with a clever hack.

cricket

---

From: "Perry E. Metzger" <[email-masked]>
Date: 23 Jan 2001 08:58:34 -0500

"Cricket Liu" <[email-masked]> writes:
> A6/AAAA RRs?

There is no harm if they do. The problem is the root servers
themselves being unable to put out full sets of A records for the
NS'es for "." without overflow. If your local name server has all of
it, there is likely no harm. We especially don't want people doing TCP
based queries against the roots.

We've already been told, by the way, that older versions of BIND won't
cache the AAAA/A6 records at all.

Perry

---

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

> without the risk of fragmentation.

I can't believe the consideration that led to the nonsensical limit
of 512 was the risk of fragmentation in transit.  I'm sure it must
have been the receiver's ability to reassemble.  (The logic leading
to 512 is still flawed, but it's much closer.)