Subject: (ngtrans) Last call on draft-ietf-ngtrans-dns-ops-req-02.txt

From: Alain Durand <[email-masked]>
Date: Tue, 16 Oct 2001 16:41:47 -0700

draft-ietf-ngtrans-dns-ops-req-02.txt has been issued about a month ago and 
no comments
were received by the authors.

The chairs of the NGtrans wg would like to enter a 2 week last call period 
on this draft
to be published as Informational RFC. This last call will end October 30th 
2001, 5 PM PDT.

Please send editorial comments to the authors and substantive comments to 
the NGtrans
mailling list.

	- Alain.

---

From: [email-masked]
Date: Wed, 17 Oct 2001 11:29:03 +0900

>to be published as Informational RFC. This last call will end October 30th 

	I'm not really sure if the "bridging system" mentinoed in section 5
	is absolutely necessary (section 5 is named "requirements" so the
	document seem to suggest that the bridging system is required).

	I believe the problem (described in the draft) can be workarounded
	operationally, by defining a set of rules like:
	- root and TLD nameservers should become IPv4/v6 dual stack as soon as
	  possible.
	- when a nameserver is serving a zone X, and zone X contains A records,
	  (or references to A records like CNAME/MX/...) the nameserver has to
	  be IPv4-capable.
	- when a nameserver is serving a zone X, and zone X contains AAAA
	  records (or references to them), the nameserver has to be IPv6-
	  capable.
	the point I'm making is, I guess, if there's no AAAA record in a zone
	X, there's no need for IPv6-only people to be able to resolve that zone.

	also, I'm not sure if there's that much of scalability requirement
	to the "bridinging system".  an IPv6-only network operator can place
	dualstack-capable nameserver at the edge of the network, and can
	let their (IPv6-only) customers use it.  this way, IPv6-only customers
	can resolve names from IPv4-only nameservers.

	I'm talking about operational workarounds, as the currently-proposed
	"bridging system" (draft-durand-dns-proxy-00.txt) is rather scary if
	abused.

	I don't remember seeing any discussion on bridging part in the past
	IETFs, not sure if it was due to a consensus or a lack of interest...

itojun

---

From: Pekka Savola <[email-masked]>
Date: Wed, 17 Oct 2001 07:56:11 +0300 (EEST)

> 	document seem to suggest that the bridging system is required).

I very much agree.  I think I mentioned a lot of issues in:

Date: Fri, 5 Oct 2001 23:52:07 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: (ngtrans) Re: I-D ACTION:draft-durand-dns-proxy-00.txt

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Alain Durand <[email-masked]>
Date: Wed, 17 Oct 2001 09:35:39 -0700

>         X, there's no need for IPv6-only people to be able to resolve 

I would strongly encourage you to read again section 2 of the document, and
especially section 2.2 that highlight what can go wrong in that case.

>         can resolve names from IPv4-only nameservers.

Of course one can build a bridging system like that. But it will mean that 
there
will be no DNS resolver (the client side of the DNS daemon) in the IPv6 
only network,
except general forwarders.
I think that this approach is limited and I have trouble picturing a large 
scale
IPv6 only network operating this way.

>         "bridging system" (draft-durand-dns-proxy-00.txt) is rather scary if

I agree. It is scary. Note that there might be other approaches.
But the fall out of DNS pictured in 2.2 and 2.3 seems to me even
more scary.

---

From: [email-masked]
Date: Fri, 19 Oct 2001 12:50:09 +0900

>especially section 2.2 that highlight what can go wrong in that case.

	I believe I fully understand the problem.  it is still possible to
	workaround the issue in 2.2 operationally by configuring nameservers
	in IPv6-only network like my previous email.  I don't think "bridging
	system" is absolutely necessary.

>Of course one can build a bridging system like that.

	I wouldn't call it a "bridging system"...

>But it will mean that there

	the basic rule is simple.
	- if you would like to query everything available in the world,
	  your resolver has to be dual-stacked, or you have to forward your
	  queries to dual-stack resolver.
	- if you would like to show your zone to everyone in the world,
	  your zone has to be served by dual-stack nameserver, your upstream
	  zones (like "com" for foo.com) has to be served by dual-stack
	  nameserver.
	I know that the real problem comes in when IPv4 address becomes no
	longer available.  I hope IPv6 becomes well deployed before then,
	and the lack of IPv4 reachability becomes non-issue (everyone is
	dual-stacked before IPv4 address runs out completely).  this is one
	of the reason why we need to start deploying IPv6 sooner.

	proposals like draft-durand-dns-proxy-00.txt do require changes to
	the existing codebase (i.e. IPv6-only resolvers need to send queries
	to A NS records differently).  I'm not sure if it is deployable.

itojun

---

From: Pekka Savola <[email-masked]>
Date: Fri, 19 Oct 2001 20:00:26 +0300 (EEST)

> were received by the authors.

I agree with itojun here.

You're (as a hostmaster) perfectly capable of shooting yourself in the
foot.  But that's no news.

IMO, this situation should not be rectified by automating the query
process which would only encourage lousy design and abuse, but via
documenting proper operational procedures (e.g. Information/BCP RFC's) and
showing the problems with certain, wrong approaches.

(Example 2.3) If you're running an IPv6 only network, so that you don't
even have authoritative IPv4 nameserver, you definitely should not care
about IPv4-only backup MX's (as you probably couldn't find any protocol to
fetch the mail anyway!).

(Example 2.2) As for the other direction, queries like this could very 
well be sent from behind a NAT'ed IPv4 world too.

So, if an IPv4-only node wants to query IPv6-only zone, I gather almost 
all cases this is either:
 - bad design in server design or referral chaining, or
 - the IPv6-zone has no services offer for the IPv4 world, so nothing is
lost.

And vice versa for IPv6/IPv4.  Some additional points about this:
 - if source is IPv6-only, and wants to care about IPv4 too, there will
need to be dual-stacked protocol translators anyway, and thus IPv4
addresses are needed anyway and queries from dual stack shouldn't be too
big a burden.
 - if source is IPv6-only, and there is no translation, the only problems
here are root/TLD capabilities if you want to avoid dual stacks in the
source network.  I believe this scenario (no translation) will happen so
far in the future (>5yrs) that TLD's are dual stack and if destination
zone DNS-servers have no IPv6 capability, they probably don't have
anything to offer to the IPv6 world anyway.

---

From: Randy Bush <[email-masked]>
Date: Fri, 19 Oct 2001 10:04:01 -0700

> about IPv4-only backup MX's (as you probably couldn't find any protocol to

please reconcile this with rfc 2826 and the need to have a single consistent
namespace.

randy

---

From: Alain Durand <[email-masked]>
Date: Fri, 19 Oct 2001 11:36:17 -0700

>         system" is absolutely necessary.

If we do what you suggest, it will mean, from the example in 2.2,
that no IPv6 only host could browse pages from www.foobar.org until
- There is an IPv6 capable root name server
- There is an IPv6 capable name server for .org.
- There is an IPv6 capable name server for foobar.org.
....
and so on if we were looking for www.x.y.z.foobar.org

Basically, you are telling us we can not use IPv6 to do DNS resolution
until every single zone that may contain any sub-zone that contains
AAAA records are also served by an IPv6 capable name server.
I do not thik this is acceptable.

>           zones (like "com" for foo.com) has to be served by dual-stack

Doing that basically split the global DNS  view in two.
This seems to me in total contradiction to RFC2826:
"IAB Technical Comment on the Unique DNS Root"

    - Alain.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 19 Oct 2001 22:12:46 +0300 (EEST)

> and so on if we were looking for www.x.y.z.foobar.org

This is over-playing the issue.

It's rather _practical_ to require that a DNS server which has root hints
(as root is IPv4-only now) is dual-stacked.

Not every the 'first-hop' DNS server (IPv6-only if so inclined) needs to
be that.

Of course, DNS server configuration could have a knob 
"forward_ipv4_requests_to_these_servers recursively" or 
"forward_ipv6_requests_to_these_servers recursively".

That is, like BIND 'forwarders' directive but with address family
distiction.

> I do not thik this is acceptable.

After root and TLD's are dual-stack, all is left is the organizations 
themselves.  If the master organization does not have IPv6 enabled, it's 
quite probable they don't have anything to give to the IPv6 world.  Or 
their subzones either.

Ie. at that point, dual-stacked DNS server at the edge of IPv6-only cloud 
are no longer _that_ strict a requirement.

> "IAB Technical Comment on the Unique DNS Root"

It's the user's/site's choice which protocol they want to use.

If they want, they may not even want to see those IPv4 zones which have 
nothing to say to them.

But practically, this should only happen when IPv6 has become so prevalent
that we're going to need 4to6 method ;-), and the user can work around
this restriction if his ISP doesn't want to provide IPv4 service.

This is not defining an alternate DNS root system, IMO.

---

From: Alain Durand <[email-masked]>
Date: Fri, 19 Oct 2001 13:05:36 -0700

> about IPv4-only backup MX's (as you probably couldn't find any protocol to

Please read 2.3 again. In this example, foobar is an IPv6 only site that
has contracted the service of an _external_ dual stack mail relay
so IPv4 only nodes can still send Email.
The external IPv4 only node will use IPv4 to contact the  contracted IPv4 MX.

>  - the IPv6-zone has no services offer for the IPv4 world, so nothing is

Wrong. See previous comment.

> addresses are needed anyway and queries from dual stack shouldn't be too

Wrong again. The protocal to use to contact a DNS server for a particular
zone does not tell you anything about what services are available
and what protocol can be use to reach them. Again see the MX example.

> anything to offer to the IPv6 world anyway.

You seems to think that there are only names that looks like
host.domain.tld.
This is not always the case. You may have
www.a.b.c.d.e.f.g.h.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.domain.com.
and you do not want to wait until all the zones from a to z are served by an
IPv6 capable name server
before you can reach this web server using an Ipv6 only host.

    - Alain.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 19 Oct 2001 23:34:12 +0300 (EEST)

> The external IPv4 only node will use IPv4 to contact the  contracted IPv4 MX.

Oh, true.

But wrong approach.  No point in having dual-stacked MX's if you don't 
have dual-stacked nameserver.  The latter is way more important.

> and what protocol can be use to reach them. Again see the MX example.

Technically you're right.  But I have a more pragmatic approach.

If a site would have IPv6-only nameservers, in my eyes it implies strong 
intention that IPv4 is not used.  If IPv4 services would be used, the NS 
would also have an IPv4 address to maximize the connectivity.

> before you can reach this web server using an Ipv6 only host.

Technically, you're right.  But again, I have a more pragmatic approach.

If domain.com has only IPv4-only nameservers, that gives IMO a very strong
implication that there are no IPv6-only subdomains.  IPv4/IPv6 dualstacks
sure, but IPv6-only no.  A site couldn't possibly be serious about IPv6
(that is, lots of IPv6-only subdomains) if it's own zone is not
IPv6-reachable.

---

From: Alain Durand <[email-masked]>
Date: Fri, 19 Oct 2001 13:53:37 -0700

> (that is, lots of IPv6-only subdomains) if it's own zone is not

You are making assumptions here.

    - Alain.

---

From: Keith Moore <[email-masked]>
Date: Fri, 19 Oct 2001 17:02:06 -0400

>  - the IPv6-zone has no services offer for the IPv4 world, so nothing is

that's simply false.  address records are no different than any other RRs,
and it's perfectly reasonable for a node of any type to issue a query of any
type.  for example, an IPv4 only node might want to obtain the IPv6
address of some other host in order to send that address to a process which
can make use of it.  perfectly reasonable thing to do.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 19 Oct 2001 17:06:47 -0400

> No point in having dual-stacked MX's if you don't

that's simply false.  as long as there is a path by which the SMTP client's
resolver can find out the IPv6 address records for the MX, a dual-stacked
SMTP client can use those addresses.

---

From: Pekka Savola <[email-masked]>
Date: Sat, 20 Oct 2001 00:10:44 +0300 (EEST)

> SMTP client can use those addresses.  

That was taken out of the context.  The assumption there was that the 
clients are IPv4-only.

---

From: Pekka Savola <[email-masked]>
Date: Sat, 20 Oct 2001 00:18:37 +0300 (EEST)

> can make use of it.  perfectly reasonable thing to do.

Nearly all :-)

A yet more reason for a lot of dual-stack in both ends :-)

---

From: Keith Moore <[email-masked]>
Date: Fri, 19 Oct 2001 17:27:02 -0400

> That was taken out of the context.  The assumption there was that the

it really doesn't matter.  The set of DNS records available to a querant needs
to be the same regardless of whether the query is made by v4 or v6, or whether
the client has v4 or v6 support or both.  It's not reasonable to assume that
the party issuing the query is the one that will be using the records returned.

Keith

---

From: [email-masked]
Date: Sat, 20 Oct 2001 16:21:20 +0900

>"IAB Technical Comment on the Unique DNS Root"

	i believe you are badly confused, or mixing things up.
	when did I suggest having alternate root?

itojun

---

From: [email-masked]
Date: Sat, 20 Oct 2001 16:44:20 +0900

>I do not thik this is acceptable.

	good reason to be dual-stacked.  being IPv6 only is not that easy today.

itojun

---

From: Alain Durand <[email-masked]>
Date: Sat, 20 Oct 2001 11:54:57 -0700

>         when did I suggest having alternate root?

You're suggesting it is OK to have different views of the DNS tree,
depending on which protocol you are using to query the data.
For me this is a logical equivalent of an alternative DNS root.

 From RFC2826:

"In the case of a public communications system this condition
of a common symbol set with a common semantic interpretation
must be further strengthened to that of a unique symbol set with
a unique semantic interpretation. This condition of uniqueness
allows any party to initiate a communication that can be received
and understood by any other party. Such a condition rules out
the ability to define a symbol within some bounded context.
                                                    ^^^^^^^^^^^^^^^^
In such a case, once the communication moves out of the context
of interpretation in which it was defined, the meaning
of the symbol becomes lost.

Within public digital communications networks such as the Internet
this requirement for a uniquely defined symbol set with a uniquely
defined meaning exists at many levels, commencing with the binary
encoding scheme, extending to packet headers and payload formats
and the protocol that an application uses to interact. In each case
a variation of the symbol set or a difference of interpretation of the
symbols being used within the interaction causes a protocol failure,
and the communication fails. The property of uniqueness allows
a symbol to be used unambiguously in any context, allowing the symbol
to be passed on, referred to, and reused, while still preserving
the meaning of the original use. "

---

From: [email-masked]
Date: Sun, 21 Oct 2001 12:52:17 +0900

>For me this is a logical equivalent of an alternative DNS root.

	no, I did not suggest so.  you are saying that a new magical tool is
	necessary.  I am saying that we can operationally workaround your
	problem, and I mentioned a couple of ways/rules to make it work.

itojun