Subject: RE: (ngtrans) Re: IPv6 dns

From: [email-masked]
Date: Thu, 18 Jan 2001 10:15:13 -0600

Its not that I have the opposite opinion but any product will reach
endoflife or need to be
upgraded to support new and better functions and backwards compatibility
will have to 
be broken.  It should not be done adhoc or without good reason but in this
case I think
its fair to break it.  Upgrade or don't work I agree with Bill in this case.
I also think those who have not upgraded are remiss in their social
responsiblity to advance with
the network.

/jim

-----Original Message-----
From: ext Randy Bush [mailto:[email-masked]]
Sent: Thursday, January 18, 2001 7: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: "Christian Huitema" <[email-masked]>
Date: Fri, 19 Jan 2001 17:35:43 -0800

Jim,

I agree that people should not go overboard. Most of the benefits of A6
are obtained by having one level of indirection at the "site" level --
this is the point at which A6 allows you to easily switch providers, or
to swicth which providers you want to advertize. There may be some
additional benefit with renumbering at the "access ISP" layer, but it is
real hard to envisage more than 3 layers of hierarchy.

As for client vs. server resolution, there are arguments both ways.
Experience will tell.

-- Christian Huitema

> From: Jim Bound [mailto:[email-masked]]
> Sent: Friday, January 19, 2001 8:35 AM
> To: Perry E. Metzger
> Cc: [email-masked]; Christian Huitema; Randy Bush; Bill Manning;
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: (ngtrans) Re: IPv6 dns
> 
> 
> 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
> 
> On 19 Jan 2001, Perry E. Metzger wrote:
> 
> > 
> > Jim Bound <[email-masked]> writes:
> > > 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.
> > 
> > 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: [email-masked]
Date: Sun, 21 Jan 2001 20:45:36 -0600

IPv6 core specs and implementations are not experimental they are being
deployed and
sold.  AAAA RRs are core now.  Not A6.

/jim

-----Original Message-----
From: ext Perry E. Metzger [mailto:[email-masked]]
Sent: Saturday, January 20, 2001 5:07 AM
To: Randy Bush
Cc: Keith Moore; Havard Eidnes; [email-masked]; [email-masked];

Randy Bush <[email-masked]> writes:
> > 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.
> 
> 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

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

---

From: [email-masked]
Date: Wed, 24 Jan 2001 06:51:13 -0600

-----Original Message-----
  | Just the points D. Bernstein raised by definition
  | implies BIND 9 resolvers will not scale hacking A6 hierarchies.

>Nonsense.  He also claims that NS and MX records should contain addresses,
>rather than names, for the same reasons (exactly).

No it will not scale at all its not nonsense. Also I agree with Dan on the
NS
and MX records too. In fact so far Dan has provided technical arguments and
I
have seen no one counter them.

And that is supposed to be evidence that NS and MX records don't work???
I think we have rather more evidence the other way.

>Certainly it is possible to badly configure NS and MX such that they
>won't work, and it will be possible to configure A6 so that it won't
>work.   That doesn't mean that it will never work however.

Dan and I are arguing different points.  I am telling you and others that
the
"C" code to make this work is not going to scale and will have to be changed
and
evolved.  But if we put the indirection at the server we can build it in
BIND, DENT,
MS-DNS, et al and leave the clients alone.  The A6 specs now force the
client DNS
code to deal with major caching and roundtrip requests to get the complete
A6 record
in the worst case.  If we put that burden on the servers engineers can
develop the 
"C" code to make it work and deliver it in releases so we can extend it
tomorrow.
Dan's position on the cost of queries is 100% correct.  That data means we
should
put the A6 processing on the server.  Or at least have that option in the 
DNS development community to make this work and IMO scale.

So I am not debating this from a system administrators view but an engineers
view
who ships products.  Its an implementation red flag I am raising per this
new conversation.

  | We know it won't work now.

>No we don't.    You think it won't.   That's as far as it goes.

If the BIND code is used for more than 2 or maybe 3 levels it WILL NOT WORK.
Now work
to me means:  Production code in Production Networks for real Business
operations. 
So I don't agree with your claim we don't know.  We do know.  Have you
looked at the BIND 
9 code for this?  I have.

  | ALso 3 or a few more levels can be enforced in the BIND
  | code if we put it there.

>You can easily enforce it in the resolver end (just as it is, or
>would be, possible to enforce NS's not being aimed at CNAMEs, etc).
>It is almost impossible to enforce at the server end, which is
where it would need to be to actually be effective.   Otherwise you
>just get names that don't resolve (and whether that is because your
>resolver detected what it considers to be an error, or because it
>was still out there working when you or the application decided to
>give up in frustration doesn't really matter).

Of course it can be enforced at the server within the NS delegations.  But I
may
have misunderstood your point above?

  | I do see your point but I think a compromise is to reduce the hiearchy
to
  | some value folks can agree to and when that works and we learn more
  | about A6 we can later address increased hieararchy.

>I have no problems suggesting to people that resolvers might not be willing
>to chase the chain longer than N steps, and that if they make it longer
than
>that they're going to likely cause name failures.   That could even go in
the
>docs (resolvers SHOULD NOT follow A6 chains more than N long) if that will
>help.   But I don't think anything more than that is rational.

That may work I just am not 100% convinced.  I would like to see someone
refute
what Dan is saying I have not seen that.

/jim