Subject: Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 06 Apr 2004 23:49:36 +0900

>>>>> On Tue, 06 Apr 2004 23:05:31 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> Editorial comments:

(Sorry, I missed one more comment in Appendix)

4. Appendix A. (Site-local Addressing Considerations for DNS)

(last paragraph)
   ... Note that the
   experience private addresses in IPv4 has shown that the root servers
   get loaded for requests for private address lookups in any.

s/experience private addresses/experience of private addresses/ ?

(if "experience private addresses" was really the phrase intended,
then "has shown" should be "have shown")

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 06 Apr 2004 23:05:31 +0900

>>>>> On Thu, 25 Mar 2004 17:18:33 +0200 (EET), 
>>>>> Pekka Savola <[email-masked]> said:

> For up-to-date copies, see:
> http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-05pre.txt
> http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-05pre-diff.html

I'm going to make comments on the 05pre revision to avoid making
duplicate comments.  (I still must admit I may not have been careful
about the last call thread and can make duplicates.  Please just
ignore duplicate ones if any).

Overall, I think this documetn is accurate and very useful.  Some
relatively minor comments below:

Substantial (or not-so-editorial) comments:

1. Section 1.1 (1.1 Representing IPv6 Addresses in DNS Records)

   In particular one should note that the use of A6 records, DNAME
   records in the reverse tree, or Bitlabels in the reverse tree is not
   recommended [2].

I think this is an overstatement about DNAME.  The text looks meaning
DNAME is not recommended *in any way* in the IPv6 reverse tree.  For
example, people would read this to mean it is discouraged to use DNAME
to manage both ip6.arpa and ip6.int zones as described in
http://www.isc.org/pubs/tn/isc-tn-2002-1.html

But, in my understanding, the sense of the discussion in RFC3363 ([2])
is that DNAME in the reverse tree is deprecated for the reverse side
of the A6 usage.  That is, the usage for constructing multi-level,
hierarchal reverse trees, particularly with bitstring labels.

Perhaps I misunderstood the sense, in which case I hope someone will
correct me.  Even if I'm correct, this is probably a result of the
ambiguous wording in RFC3363.  But I believe this document could still
be a bit clearer on the meaning of "not recommended".

2. Section 2.2 (Privacy (RFC3041) Address)

   Privacy addresses (RFC3041 [9]) use a random number as the interface
   ...

"Privacy address" is not really correct as a technical term.  RFC3041
calls this "temporary address".  I guess the dns-issues draft wanted
to make the intention of the address (i.e. privacy purposes), but I
still think it should use the correct term with additional
explanation.  For example, how about saying "Temporary addresses (for
privacy purposes defined in RFC3041 [9])"?

3. Section 4.4 (The Use of TTL for IPv4 and IPv6 RRs)

   example.com.        300    IN    MX     foo.example.com.
   foo.example.com.    300    IN    A      192.0.2.1
   foo.example.com.    100    IN    AAAA   2001:db8::1
...
   ... So,
   in this particular case, there is a window of 200 seconds when
   incomplete information is returned from the cache.

I don't see what's wrong with this.  In this case, the lost
information would be "additional" one (returned in the additional
section) after all.  If the client (probably an SMTP server in this
case) needs the missing AAAA, it can ask for the missing RR(s)
separately (otherwise, I'd call this a bug in the client).

So,

   Therefore, when the same name refers to both A and AAAA records,
   these records should have the same TTL.

I don't see a valid reason for this either.  Moreover, I can even
think of a case we want to use different TTLs for A and AAAA RRsets.
For example, if I'm going to renumber an IPv6 address of a host while
keeping IPv4 addresses on that host, I might want to use a shorter TTL
for the AAAA RRset but a longer, stable TTL for the A RRset.

4. Section 4.5 (Behaviour of Glue in Mixed IPv4/IPv6 Environments)

(second paragraph)
   Consider the case where the query is so long or the number of the
   additional ("glue") records is so high that the response must either
   be truncated (leading to a retry with TCP) or some of the additional
   data removed from the reply.

The "the query is so long" part is not really clear.  I guess the
authors tried to talk about the case where the query *name* is so
long, which should be copied to the response and may make the response
long too.  However, the original text could also read to mean "the
query *packet* is so long", and, in this case, the intention is
unclear (since there are other possibilities that may make the query
packet long, e.g., EDNS0 pseudo RR(s) and are not necessarily related
to the length of the response).

5. Section 6 (Considerations about Forward DNS Updating)

(second paragraph)
   Typically forward DNS updates are more manageable than doing them in
   the reverse DNS, because the updater can, typically, be assumed to
   "own" a certain DNS name -- and we can create a form of security
   association with the DNS name and the node allowed to update it to
   point to a new address.

(this is a mostly editorial comment) I think "security association" is
a misleading term here because it sounds like something related to
IPsec (but it seems to me that the original intention was more
generic).  I guess the authors perhaps tried to express the intention
by adding "a form of" before "security association", but the text
could explicitly be clearer.

6. Section 7.5 (DDNS with Dynamic Prefix Delegation)

(first paragraph)

   That is, whether the DNS server is managed by
   the same entity as the prefix delegator, at the site where the
   prefixes are delegated, or elsewhere (which is typically equivalent
   to the latter).

(again, mostly editorial) the parenthesized part is not really clear.
First, what's the antecedent of this part?  I guess it is "the point
where the DNS server is managed", but it could also read to specify
"elsewhere".

Secondly, what does "the latter" at the end of the sentence specify?
I guess it's "the site where the prefixes are delegated", but again,
it could also specify "elsewhere".

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

Editorial comments:

1. Section 1.1 (Representing IPv6 Addresses in DNS Records)

(first paragraph)
   PTR records in the nibble format under the ip6.arpa. -tree.

Is the "dash" (-) character before "tree" intentional?  Probably so,
but I was not sure whether this is a typo or an intentional notation.
In any case, I think we can even remove the dash (not a strong
opinion, though).

2. Section 6.2 (Dynamic DNS)

(third paragraph)
   for the hostname; the second must be configured explicitly unless one
   chooses to trust the IP address -based authentication (not a good
   idea);

s/address -based/address-based/ ?

(fourth paragraph)
   address; that way, the node can start lowering the DNS TTL if it
   seems like the address has not be renewed/refreshed in a while. Some
   discussion on how an administrator could manage the DNS TTL is
   included in [33];

s/has not be/has not been/ ?

3. Section 7.3 (DDNS with Stateless Address Autoconfiguration)

(last paragraph)
   One way to automate this is looking up the DNS server
   authoritative (e.g., through SOA record) for the IP address being
   updated, but the security material (unless the IP address -based
   authorization is trusted) must also be established by some other
   means.

s/address -based/address-based/ ?

					JINMEI, Tatuya

---

From: Pekka Savola <[email-masked]>
Date: Wed, 7 Apr 2004 11:38:34 +0300 (EEST)

Thanks a lot for good comments.  (I also took your additional 
message into account.)

I think this causes us to re-think the TTL/impartial additional-data
parts and how it's supposed to operate a bit -- so I'd welcome the 
others to look at this as well..

I've also updated the temporary copies at:
 
http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-05pre.txt
http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-05pre-diff.html
 (There is no diff between these two pre-versions though.)

Inline..

> http://www.isc.org/pubs/tn/isc-tn-2002-1.html
[...]

I'll take this discussion to a separate thread, as this may add some 
debate.

> privacy purposes defined in RFC3041 [9])"?

Good point.  Revised as follows:

        <t>Temporary addresses defined in <xref
target="RFC3041">RFC3041</xref> (sometimes called "privacy addresses")
use a random number as the interface identifier.  Publishing DNS
records relating to such addresses would defeat the purpose of the
mechanism and is not recommended.  If absolutely necessary, a mapping
could be made to some non-identifiable name, as described in <xref
target="RFC3041"/>.</t>

> separately (otherwise, I'd call this a bug in the client).

You raise a good point.  I seem to have been slightly confused here, 
thinking that the clients would do somekind of "ANY" or "give me 
everything you have about 'name'" queries.

You can do "ANY" query, but that does not give you the right answer
unless the caching resolvers on the path have also queried for both v4
and v6 records.  So, practically, you have to perform explicit queries 
for both A and AAAA records.  However, there is a case where you do 
not need explicit queries but where you could be led astray: querying 
for MX record, as the caches may give you nothing (this leads you to 
query both records explicitly), full results, or impartial results.  
Here I'm worried of impartial results.

Or am I missing something and is there some kind of real application 
of "ANY" queries?  Does anyone use them e.g. on DNS server or stub 
resolver implementations? 

Let me try to understand your bug example.  Would you consider it a 
bug that a DNS cache would have cached both A and AAAA records with 
different TTLs, and when the first-to-expire expires, the DNS cache 
does not re-query the one that expired?  Should it re-query that?
I mean, if the cache would return records in an additional section 
(e.g., when queried for MX record), but would not return all of them 
(because some of them had expired), would you consider this a bug?

(See below for text update.)

> for the AAAA RRset but a longer, stable TTL for the A RRset.

I think it should be reasonable to suggest that the TTL should be the 
same (because that simplifies the operations for those servers 
which have to handle the both) unless there are valid reasons (like 
the ones you cite) for handling them differently.

As for the current wording I've adopted (this probably requires more 
tuning still):

4.4  The Use of TTL for IPv4 and IPv6 RRs

   The behaviour of DNS caching when different TTL values are used for
   different records of the same name requires explicit discussion. For
   example, let's consider a part of a zone:

   When a caching resolver asks for the MX record of example.com, it
   gets back "foo.example.com".  It may also get back either one or both
   of the A and AAAA records in the additional section. So, there are
   three cases about returning records for the MX in the additional
   section:

   1.  We get back no A or AAAA records: this is the simplest case,
       because the we have to query which information is required
       explicitly, guaranteeing that we get all the information we're
       interested in.

   2.  We get back all the records: this is an optimization as there is
       no need to perform more queries, causing lower latency. However,
       it is impossible to guarantee that in fact we would always get
       back all the records; however, one could try to work in the
       direction to try to ensure it as far as possible.

   3.  We get impartial results: this is indistinguishable from the
       previous case, and problematic as described in the next section.

   So, we assume we get back both A and AAAA records of foo.example.com,
   or the resolver explicitly asks, in two separate queries, both A and
   AAAA records. After 100 seconds, the AAAA record is removed from the
   cache because its TTL expired.  The cache must re-query the AAAA
   record when its TTL expires to avoid the situation where there would
   be a window of 200 seconds when incomplete information is returned
   from the cache. XXX: if this is not done, is it a bug?

   To simplify the situation, it is recommended to use the same TTL for
   all the records referring to the same name. However, there are some
   scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where
   a different strategy is preferable.

   More issues with caching and A/AAAA records is presented in the next
   section.

> to the length of the response).

Yes, the intent was "query name", as the additional length of the  
packet for other reasons was also discussed a bit.  Possibly this 
would call for more text?

       <t>Consider the cases where the query name is so long, the
number of he additional records (originated from "glue") is so high,
or for other easons that the response must either be runcated (leading
to a retry with TCP) or some of the additional data emoved from the
reply. [...]
 
I added "query name" there and "or for other reasons" -catchall, but 
if you have better ideas what to add here, I'm all ears :)

> could explicitly be clearer.

Yes, this is the intent.  I've changed "security association" to 
"security relationship" to make it clearer that the terms don't 
overlap :)
 
> it could also specify "elsewhere".

The wording "at the site where the prefixes are delegated" seems to be 
unclear.  I've reworded it to "at the site where the prefixes are 
delegated to" to make it clearer.  I've also tried to clarify the 
parentheses by spelling it out:

7.5  DDNS with Dynamic Prefix Delegation

   In cases where a prefix, instead of an address, is being used and
   updated, one should consider what is the location of the server where
   DDNS updates are made. That is, where the DNS server is located:

   1.  At the same organization as the prefix delegator.

   2.  At the site where the prefixes are delegated to.

   3.  Elsewhere, as specified by the delegated site; this is
       security-wise typically equivalent to the previous case.

   On one hand, securing the DDNS relationship for prefix delegation is
   simpler if DNS server and the prefix delegator are in the same
   administrative domain, and may be more difficult otherwise.

   On the other hand, if the DNS server resides where the prefixes are
   delegated to, it is easier to manage reverse DNS updates as they can
   be done within a single administrative entity.  Similarly, then
   configuring the reverse DNS is typically simpler as well (e.g., if
   one wanted to insert a wildcard record).

It was intentional notation, but removed as it doesn't seem 
necessary.
 
> s/address -based/address-based/ ?

I like how it is at the moment because it's 'IP address'-based rather 
than just address-based.  But I've changed this as you say (two 
places) as I think this is rather equivalent in any case.
(Same for section 7.3.)

> s/has not be/has not been/ ?

Yep.
 
-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 07 Apr 2004 08:09:41 -0400

(Following up on http://darkwing.uoregon.edu/~llynch/dnsop/msg02710.html:
Pekka, thanks for your response.  I agree with your responses to any issues
from the previous message that I haven't mentioned here.)

Comments on draft-ietf-dnsop-ipv6-dns-issues-05pre.txt:

I'm still having trouble understanding:

    2.3  6to4 Addresses

       6to4 [10] specifies an automatic tunneling mechanism which maps
       a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48.
       Providing reverse DNS delegation path for such addresses is a
       challenge.  Note that similar difficulties don't surface with
       the other automatic tunneling mechanisms. In particular,
       providing reverse DNS information for Teredo [11] hosts does not
       seem feasible; the IPv6 address is based on the IPv4 address and
       UDP port of the current NAT mapping which is likely to be
       relatively short-lived.

The last sentence seems to contradict the preceding sentence.

I don't think section 5.2 accurately reflects the current state of
specifications and discussion about recursive DNS resolver configuration:

    5.2  Recursive DNS Resolver Discovery

       Recursive IPv6 DNS resolver discovery is a subject of active
       debate as of this writing (March 2003): the main proposed
       mechanisms include the use of well-known addresses [24], the use
       of Router Advertisements to convey the information [25], and
       using DHCPv6 (or the stateless subset of it [26]) for DNS
       resolver configuration [27].  No consensus has been reached yet.

       Note that IPv6 DNS resolver discovery is not required for
       dual-stack nodes in dual-stack networks as IPv6 DNS records can
       be queried over IPv4 as well as IPv6.

I think the current situation regarding recursive DNS resolver configuration
would be more accurately reflected by the following paragraph:

    5.2 Obtaining a list of DNS Recursive Resolvers

       A host can be configured with a list of DNS recursive resolvers
       through the DHCPv6 "DNS Recursive Name Server" option [RFC3646].
       This option can be passed to a host through a subset of DHCPv6
       [RFC3736].  Two alternative mechanisms are under consideration:
       the use of well-known addresses [21] and the use of Router
       Advertisements to convey the information [22].

I know this paragraph has been discussed before.  It would be good to get
other WG input to make sure the text reflects WG consensus on the subject.

In section 6, would it be possible to add a reference to work on the
problem of adding a name into a DNS zone for readers (such as myself!)
who are unfamiliar with the problem area?  Is there any guidance that
this document can give regarding adding a new name to a zone?

Comments on section 7.4:

   7.4  DDNS with DHCP

      With DHCP, the reverse DNS name is typically already inserted to
      the DNS that reflects to the name (e.g., "dhcp-67.example.com").
      All of these mappings are pre-configured, and require no
      updating.

Are you referring to DHCPv4 or DHCPv6 here?  It would be good to get
input based on deployment experience to confirm that this
strategy is "typically" used for DHCPv4.  Of course, we have little
deployment experience with DHCPv6 to know whether pre-configuration
will be used for IPv6 PTR records.

      If a more explicit control is required, similar considerations as
      with SLAAC apply, except for the fact that typically one must
      update a reverse DNS record instead of inserting one (if a denser
      address assignment policy than with SLAAC is adopted) and
      updating a record seems like a slightly more difficult thing to
      secure. However, it is yet uncertain how DHCPv6 is going to be
      used for address assignment.

Would the parenthetical phrase be more clearly stated as "(if an
address assignment policy that reassigns disused addresses is
adopted)"

      Note that when using DHCP, either the host or the DHCP server
      could perform the DNS updates; see the implications in Section
      6.2.

Is there a parallel between host updates of DHCPv6-assigned addresses
and the discussion in section 7.3, as well?  It might be worth
mentioning that the DHCPv6 server can perform the PTR record cleanup
if the DHCPv6 address assignment is used.

Finally, in response to your comments on section 7.4:

> > Section 7.4, second paragraph: What is a "denser address assignment
> > policy"?  As we have little or no experience with address assignment
> > through DHCPv6, I think it is premature to anticipate how DHCPv6 will
> > be used.  I can imagine, for example, that DHCPv6 might be used to
> > assign addresses that look just like SLAAC addresses - the advantage
> > to the use of DHCPv6 being centralized registration and accounting for
> > addresses and devices.
>
>Well -- looking at those that seem to want to use DHCPv6, their main
>point appears to continue doing what they're doing with v4.  The
>logical conclusion of that is that using relatively dense allocations
>(though not necessarily every address sequentially, until running out,
>as with v4) is something they're familiar with and want to go on
>doing.

My experience has been that network admins that want to use DHCPv6
for address assignment are primarily interested in registering
addresses and accounting for devices on the network, rather than
wanting to do sequential address assignment from a pool of available
addresses.  Those admins would be happy with a DHCPv6 server that
hands out an address constructed in the same way as a SLAAC address.

- Ralph

.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 07 Apr 2004 21:20:13 +0900

In this response, I'm also referring to the latest version of
http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-05pre.txt
(the one whose MD5 hash value is 0f0dcc920186d1a01f923dd60aac168d).

Easy ones first:

>>>>> On Wed, 7 Apr 2004 11:38:34 +0300 (EEST), 

>> 2. Section 2.2 (Privacy (RFC3041) Address)

(snip)

> could be made to some non-identifiable name, as described in <xref

Forks for me.  I'd also remove "RFC3041" from the section title:

2.2  Temporary Addresses

but this is not a strong opinion.

>> 4. Section 4.5 (Behaviour of Glue in Mixed IPv4/IPv6 Environments)

(snip)

 
> if you have better ideas what to add here, I'm all ears :)

For me, adding "name" to "the query" is enough (in fact, I'm not sure
what "other reasons" are referring to).  But again, it's not a strong
opinion and is up to you.

> "security relationship" to make it clearer that the terms don't 

Okay.
 
>> 6. Section 7.5 (DDNS with Dynamic Prefix Delegation)

(snip)

>    one wanted to insert a wildcard record).

The revised text basically looks okay except for one point: I'm not
sure about the rationale of the latter part of case 3: "this is
security-wise typically equivalent to the previous case."

> places) as I think this is rather equivalent in any case.

Ah, I see.  My comment actually came from consistency with other parts
("address-based" without "IP"), which I thought was natural notation.
If "address -based" was intentional, then I'm fine, though I
personally prefer "address-based".  And, since the latest text matches
my preference, I'm just happy with it.

					JINMEI, Tatuya

---

From: Pekka Savola <[email-masked]>
Date: Fri, 9 Apr 2004 08:32:12 +0300 (EEST)

> but this is not a strong opinion.

I'd rather keep it in, to make it clearer to not confuse them with 
non-RFC3041 addresses which just happen to be temporary, but as 
RFC3041 is to be revised in any case, I think this may be better off 
from the title, so I've removed it.
 
> opinion and is up to you.

Kept as is; "other reasons" may be due to e.g., the number of DNS
record for the name that would have to be returned (in the
*authorative* section) to be too large or inclusion of DNSSEC records
for which either query name or additional records may not be
appropriate. (However, as I don't know the details, I'm just being
vague ;-).
 
> security-wise typically equivalent to the previous case."

OK, let me try to clarify.  If you delegate the DNS delegation for a
prefix to someone else, that someone else must configure the DNS
server to accept such a delegation.  Because they don't just take
delegations from strangers, we must assume that there is some form of
relationship between the two.  Such relationship should be easily
extendable to be a security relationship as well.

However, the difference which is not explicit is that as the DDNS
packets cross the public Internet, there is probably higher need to
secure the DDNS updates coming to the server (as rather, when the
server is at the same site, you could just use IP address-based
"authentication" if you call it that).

I changed this to:

                <t>Elsewhere; this implies a relationship betwen the
site and where DNS server is located, and such a relationship should
be rather straightforward to secure as well.</t>

How does this sound?

.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 9 Apr 2004 09:26:03 +0300 (EEST)

Hi,

Ralph suggested changing section 5.2 on DNS resolver discovery to 
better reflect to what's out there (but not reflect that there is no 
consensus on the approach).  I think the proposed wording is a bit 
biased toward using DHCP but not much.

I'd slightly modify his proposal to:

       No consensus has been reached as of this writing (April 2004).

What does the WG think about this --  That is,

  Do you have a problem with the above wording?

    If yes, I won't adopt it, but use the original unless there are 
    other suggestions.

    If not, I'll use the rewording above, or something close to that.

.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 9 Apr 2004 09:33:27 +0300 (EEST)

Thanks for responding.  Trying to clarify further...

(Michael -- we discussed this last December: do you have pointers to 
the work on adding entirely new records (rather than updating) to the 
zones, as noted in section 6?  Maybe some others know more of this 
than me...)

I've updated the working copies in the same URL:

Note to DNSOP WG: there has been some discussion on IPv6 WG what to
say about DNS (forward/reverse) of the new "site-local replacement"  
described in draft-ietf-ipv6-unique-local-addr-03.txt.  I've avoided
adding text on this as it's a bit of moving target (in AD
evaluation:WG followup at the moment), but if people have opinions 
about that, feel free to shoot them.  (Note that Appendix A already 
lists considerations with site-local addresses, but the situation is 
slightly different with unique local addresses.)

> The last sentence seems to contradict the preceding sentence.

OK, let me try to reword this to:

        <t><xref target="RFC3056">6to4</xref> specifies an automatic
tunneling mechanism which maps a public IPv4 address V4ADDR to an IPv6
prefix 2002:V4ADDR::/48.  Providing reverse DNS delegation path for
such addresses is a challenge.</t>

        <t>Note that it does not seem feasible to provide reverse DNS
with the other automatic tunneling mechanism, <xref
target="I-D.huitema-v6ops-teredo">Teredo</xref>; this is because
the IPv6 address is based on the IPv4 address and UDP port of the
current NAT mapping which is likely to be relatively short-lived.</t>

(note that I'm intentionally not mentioning iSATAP here as it derives 
the address from an advertised v6 prefix, so there is nothing new 
there.)

Better?

[[ note to those who may be watching: I also added a paragraph of 
discussion on draft-huston-6to4-reverse-dns-00.txt here ]]
 
> other WG input to make sure the text reflects WG consensus on the subject.

Yes, and to little resolution.  I'll raise this separately to see what 
people think.
 
> this document can give regarding adding a new name to a zone?

Good question.  I'm actually unfamiliar with this.  I received similar 
input from Michael Patton, which I've Cc:'ed.  Maybe he could provide 
some pointers.

> will be used for IPv6 PTR records.

I'm familiar with some deployments of DHCPv4, and in almost all of 
them, you use pre-defined names.  I assume it will likely be similar 
with DHCPv6.

Clarified:

        <t>With DHCPv4, the reverse DNS name is typically already
inserted to the DNS that reflects to the name (e.g.,
"dhcp-67.example.com").  One can assume similar practice may become
commonplace with DHCPv6 as well;  all such mappings would be
pre-configured, and would require no updating.</t>

Or other suggestions?
 
> address assignment policy that reassigns disused addresses is

Yes, changed to that.

> Is there a parallel between host updates of DHCPv6-assigned
> addresses and the discussion in section 7.3, as well?  It might be
> worth mentioning that the DHCPv6 server can perform the PTR record
> cleanup if the DHCPv6 address assignment is used.

Yes, but there is difference if the disused addresses are being 
reused.  That is, with SLAAC you can pretty much be sure that nobody 
will be reusing your EUI64.

I've added a note as the last paragraph:

        <t>If disused addresses were to be reassigned, host-based DDNS
reverse updates would need policy considerations for DNS record
modification, as noted above.  On the other hand, if disused address
were not to be assigned, host-based DNS reverse updates would have
similar considerations as SLAAC in <xref target="rev_slaac"/>.
Server-based updates have similar properties except that the
janitorial process could be integrated with DHCP address
assignment.</t>

> hands out an address constructed in the same way as a SLAAC address.

Handing out such addresses, IMHO, makes no sense, as you would have to 
renumber the host if its MAC address changes, even though you wouldn't 
need to introduce this dependency.

Of course, one could just assign addresses using some other policy so 
that the addresses would not need to be reassigned.

I took this as generic discussion and did not make changes.  The text 
has been reworded in any case to deal with more than just a simple 
"dense" assignment policy.

.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 09 Apr 2004 20:00:36 +0900

>>>>> On Fri, 9 Apr 2004 08:32:12 +0300 (EEST), 

Okay.

Okay.

> extendable to be a security relationship as well.

Hmm...I'm now feeling that I've been confused from the beginning.  So
before going further, please let me make the scenario.

Let's assume a site is delegated an IPv6 prefix P:x::/48.  Also assume
the prefix delegator has the authority of the DNS reverse tree for
P::/32.  Then,

In the above case 1, the prefix delegator does not delegate P:x::/48
in terms of DNS reverse tree.  Someone in the delegated site might
want to update RRs in the P:x::/48 part of the P::/32 zone at the
delegator.

In the above case 2, the prefix delegator does delegate P:x::/48 to
the (prefix) delegated site in terms of DNS reverse tree, too.
Someone in the delegated site might want to update RRs in the P:x::/48
zone managed in the same site.

In the above case 3, the prefix delegator does delegate P:x::/48 in
terms of DNS revers tree to some different organization which is not
the delegator or the delegated site.  Someone in the delegated site
might want to update RRs in the P:x::/48 zone managed in the different
organization.

Is my understanding correct?

					JINMEI, Tatuya

---

From: Pekka Savola <[email-masked]>
Date: Fri, 9 Apr 2004 14:55:38 +0300 (EEST)

> Is my understanding correct?

This is exactly the cases I've described.  (The third case is IMHO 
relevant in the case where you don't wish to maintain your own DNS 
server in the site; this could be the case e.g., if you happened to 
have a personal co-location box acting as DNS server for your forward 
domains located somewhere else as well, and you'd like to put the 
reverses there.

Should one try to further clarify this?  If so, I'm open to 
suggestions :-)

(One thing that may be confusing that we're using the term "delegate" 
for both the prefix and the reverse tree..)

.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 09 Apr 2004 21:50:50 +0900

>>>>> On Fri, 9 Apr 2004 14:55:38 +0300 (EEST), 

> domains located somewhere else as well, and you'd like to put the 

Okay, thanks.  Now the intended scenario is very clear to me.  Then
going back to the draft text:

In these paragraphs, several cases are described:

A. the case where DNS server and the prefix delegator are in the same
   administrative domain.
B. the case where DNS server and the prefix delegator are NOT in the
   same administrative domain. (the "otherwise" case in the first
   paragraph)
C. the DNS server resides where the prefixes are delegated to.

Apparently case A means case 1, and case C seems to specify case 2.
Are these correct?  Whether the answer is yes or no, what about case
B?  Does this mean cases 2 and 3?  Does it also include other
scenarios?  Or is it a completely different scenario which is neither
2 nor 3?  

If case B is (or includes) cases 2 and 3, then the above paragraphs
seem to try to say: "in case 2, it may be more difficult to secure
DDNS, but it is easier to manage reverse DNS updates and it is simpler
to configure the reverse DNS."  Is this (part of) what you wanted to
say?

					JINMEI, Tatuya

---

From: Pekka Savola <[email-masked]>
Date: Fri, 9 Apr 2004 17:13:25 +0300 (EEST)

> to configure the reverse DNS."  Is this (part of) what you wanted to

More or less.  Thanks for keeping me honest :)

I've reworded it below for clarity:

        <t>In the first case, managing the reverse DNS (delegation) is
simpler as the DNS server and the prefix delegator are in the same
administrative domain (as there is no need to delegate anything at
all).  In the other cases, it can be slighly more difficult,
particularly as the site will have to configure the DNS server to be
authorative for the delegated reverse zone, implying automatic
configuration of the DNS server -- as the prefix may be dynamic.</t>
        <t>Managing the DDNS reverse updates is typically simple in
the second case, as the updated server is located at the local site,
and arguably IP address-based authentication could be sufficient (or
if not, setting up security relationships would be simpler).  As there
is an explicit (security) relationship between the parties in the
third case, setting up the security relationships to allow reverse
DDNS updates should be rather straightforward as well.  In the first
case, however, setting up and managing such relationships might be a
lot more difficult.</t>

Is this better? Suggestions?

.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Sat, 10 Apr 2004 00:12:24 +0900

>>>>> On Fri, 9 Apr 2004 17:13:25 +0300 (EEST), 

> Is this better? Suggestions?

Much better, yes.

And I'd clarify in the classification at the beginning of this section
that the corresponding DNS reverse zone is also delegated in the last
two cases.

So, the entire section would be as follows:

   2.  At the site where the prefixes are delegated to.  In this case,
       the authority of the DNS reverse zone corresponding to the
       delegated prefix is also delegated to the site.

   3.  Elsewhere; this implies a relationship between the
       site and where DNS server is located, and such a relationship
       should be rather straightforward to secure as well.  Like in
       the previous case, the authority of the DNS reverse zone is
       also delegated.

   In the first case, managing...

					JINMEI, Tatuya

---

From: Pekka Savola <[email-masked]>
Date: Fri, 9 Apr 2004 18:57:21 +0300 (EEST)

>    In the first case, managing...

Sounds good, added. Thanks.

I've also added note in the next paragraph noting that the prefix 
delegator, with case 1, may not actually provide any DDNS service but 
just insert a wildcard record, and refer to section 7.2:

   In the first case, managing the reverse DNS (delegation) is simpler  
   as the DNS server and the prefix delegator are in the same
   administrative domain (as there is no need to delegate anything at
   all); alternatively, the prefix delegator might forgo DDNS reverse
   capability altogether, and use e.g., wildcard records (as described
   in Section 7.2).  In the other cases, it can be slighly more  
   difficult, particularly as the site will have to configure the DNS
   server to be authorative for the delegated reverse zone, implying
   automatic configuration of the DNS server -- as the prefix may be
   dynamic.

.

---

From: Rob Austein <[email-masked]>
Date: Fri, 09 Apr 2004 15:27:27 -0400

At Wed, 7 Apr 2004 11:38:34 +0300 (EEST), Pekka Savola wrote:
> 
> On Tue, 6 Apr 2004, JINMEI Tatuya wrote:
> > 

<hat wg-co-chair=off author-of-rfc3364=on>

  As a point of information: RFC 3364 can be read as supporting either
  of these viewpoints, depending on which parts of it one reads.  My
  bad.  The intent was closer to Jinmei's interpretation than Pekka's.

  DNAME itself has been fairly contentious, but the RFC 3364
  discussion (and other debate at that time) was pretty tightly
  focused on DNAME in the reverse tree as the counterpart to A6 in the
  forward tree.  Other uses of DNAME (including in the reverse tree)
  were considered out of scope in an attempt to maintain focus on the
  specific questions about A6 and A6-like use of DNAME.

</hat>

> resolver implementations? 

<hat wg-co-chair=off just-another-bozo-on-this-bus=on>

  This turns out to be a FAQ.  Right, QTYPE=* isn't useful in normal
  operations because of the way it interacts with caching.  It's a
  good debugging tool, but that's about it.

  Every few years somebody suggests that we can save the world one
  round trip time by using QTYPE=*, then we have this discussion again
  until the person who proposed this figures out that the saving is an
  illusion once one understands the caching behavior.

  At slightly less regular intervals, somebody who has learned the
  first lesson suggests that we need a new QTYPE which acts sort of
  like QTYPE=* but with different caching behavior.  So far such
  proposals have not gained traction, probably because of the size of
  the installed base and the lack of a demonstrated burning need for
  a protocol change to address a relatively minor performance hack.

  I'm not trying to belittle the opposing viewpoints, and I know that
  at least one of them is on this mailing list, but I suspect the
  above summary suffices for the purposes of Pekka's question.

  As far as partial results go: the rules for the additional section
  are straightforward, but their implications are a bit tricky.
  Splitting an RRset (anywhere, ever) would be a protocol violation.
  But it's not a protocol violation to return only N (complete)
  RRsets, for 0 <= N < M, where M is the maximum number of distinct
  RRsets that could, in theory, have been included via additional
  section processing.  The only case in which a resolver just depends
  on additional section processing is the glue case, where it has no
  other choice.

  Nit: There's no such thing as QTYPE=ANY.  It's QTYPE=*.

</hat>
.

---

From: Ralph Droms <[email-masked]>
Date: Mon, 12 Apr 2004 11:25:39 -0400

All - I realize that my suggested text is not clear about what "under
consideration" means with regard to the use of well-known addresses and the
use of Router Advertisements, which means Pekka's suggested sentence about
"no consensus" may not be clear, either.

My understanding is that the dnsop WG is considering whether to take the
development of specifications for the use of well-known addresses and/or the
use of Router Advertisements on as WG work items.  If I have that right,
then the following paragraph might be more clear:

        A host can be configured with a list of DNS recursive resolvers
        through the DHCPv6 "DNS Recursive Name Server" option [RFC3646].
        This option can be passed to a host through a subset of DHCPv6
        [RFC3736].  Two alternative mechanisms are under consideration
        for development by the dnsop WG: the use of well-known
        addresses [21] and the use of Router Advertisements to convey
        the information [22].

My concern is that the original wording might leave the impression that an
implementor should wait for the dnsop WG to come to consensus on a
recommendation, and therefore do nothing now.

Practially speaking, this discussion may be moot if there is insufficient
interest in the WG to come to agreement on the wording of this paragraph...

- Ralph

.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 12 Apr 2004 18:55:44 +0200

>   Do you have a problem with the above wording?

Someone who isn't aware of the issue (and if we assume everyone is, why 
include any text?) might take this to mean that using DHCP is the way 
to go and/or without problems, which IMO isn't the case. I think 
working it something like "In situations where DHCPv6 is available, a 
host can discover a list of DNS resolvers through [...] Ways to 
discover or configure DNS resolvers in situations where DHCPv6 isn't 
available or appropriate are under consideration [...]".

If we feel it's necessary to provide guidance to implementers it would 
be good to say something about well-known addresses, as this solution 
has the interesting property that it can largely implemented before 
it's standardized. Pretty much all that's needed is a global list of 
DNS servers that is called upon when no "local" (specific to the active 
configuration, those of you who use a Mac know what I mean) information 
is available. Obviously the list should be empty at this time.

.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 16 Apr 2004 13:14:10 +0300 (EEST)

Hi,

This has been my concern about modifying the text too much.

There hasn't been too much discussion on the text proposal, so I 
suspect many in the WG do not care much one way or the other.

I think your suggestion is a good one, and I've now written this 
section as:

=========
5.2  Obtaining a List of DNS Recursive Resolvers
                                                                                                                                            
   Obtaining the list of DNS recursive resolvers is a subject of active
   debate; no consensus has been reached as of this writing (April
   2004).
                                                                                                                                            
   In scenarios where DHCPv6 is available, a host can discover a list
   of DNS resolvers through DHCPv6 "DNS Recursive Name Server" option
   [29]. This option can be passed to a host through a subset of DHCPv6
   [28].
                                                                                                                                            
   In scenarios where DHCPv6 is unavailable or inappropriate,
   mechanisms under consideration for development of dnsop WG include
   the use of well-known addresses [26], the use of Router
   Advertisements to convey the information [27].
                                                                                                                                            
   Note that IPv6 DNS resolver discovery is not required for dual-stack
   nodes in dual-stack networks as IPv6 DNS records can be queried over
   IPv4 as well as IPv6.
========

This is what I'm going to use unless I hear objections or suggestions 
for rewording ASAP.

Note: let's not start a discussion of what those "unavailable or 
inappropriate" scenarios could be.

.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 16 Apr 2004 08:17:49 -0400

The suggested text is good, except I don't think the first sentence conveys
enough information for someone who has not been involved with the discussion
about obtaining a list of DNS resolvers.  Specifically, no consensus has
been reached about what specific issue or issues (in para 1)?

My understanding is that the current active debate is about whether the IETF
should take on any work to develop alternatives to DHCP.  I suggest the
following text as more completely and accurately describing the current
situation:

5.2  Obtaining a List of DNS Recursive Resolvers
                                                                                                   In 
scenarios where DHCPv6 is available, a host can discover a list
    of DNS resolvers through DHCPv6 "DNS Recursive Name Server" option
    [29]. This option can be passed to a host through a subset of DHCPv6
    [28].

    The IETF is considering the development of alternative mechanisms
    for obtaining the list of DNS recursive resolvers when DHCPv6 is
    not available.  No decision about taking on this development work
    has been reached as of this writing (April 2004).
                                                                                                   In 
scenarios where DHCPv6 is unavailable or inappropriate,
    mechanisms under consideration for development of dnsop WG include
    the use of well-known addresses [26], the use of Router
    Advertisements to convey the information [27].
                                                                                                   Note 
that IPv6 DNS resolver discovery is not required for dual-stack
    nodes in dual-stack networks as IPv6 DNS records can be queried over
    IPv4 as well as IPv6.

Of course, as you wrote, it doesn't appear that many WG members have
a strong opinion about the wording of this section.

Also - I finally got around to reviewing why the DHCP option is
called "DNS Recursive Name Server".  Turns out RFC 1035 refers to
"recursive server" (top of page 7) and "recursive service" (several
places), so we used the name "DNS Recursive Name Server" for the option.
It might be appropriate to retitle this section to be "Obtaining a
List of DNS Recursive Servers".

- Ralph

.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 16 Apr 2004 14:48:47 +0200

>    nodes in dual-stack networks as IPv6 DNS records can be queried over

While this text is technically correct, some people may take it to mean 
that it's not necessary to implement DNS discovery, configuration and 
resolving over IPv6. How about:

Note that in the absense of DNS resolvers reachable over IPv6, either 
due to failed discovery and/or lack of configuration, DNS resolvers 
reachable over IPv4 may be used, if available.

BTW: how does a dual-stack host know whether to use v4 or v6 resolvers?

.

---

From: Pekka Savola <[email-masked]>
Date: Sat, 17 Apr 2004 10:15:37 +0300 (EEST)

> reachable over IPv4 may be used, if available.

This is exactly the intent.  As long as you're dual-stack, there is no
hurry to worry which mechanism you start use to discover v6 resolvers.

This is another obviously bogus so-called "show-stopper" (compare to
the request of waiting for root DNS servers to be dual-stack; another
unnecessity).

These are religions/policitical reasons only, and I'd like to keep
that part of the debate out of here.

Therefore I'm reluctant to change the tone of the text.

> BTW: how does a dual-stack host know whether to use v4 or v6 resolvers?

Depending on the ordering of resolv.conf.  The more specific question 
is how does the dual-stack host know which to use when it runs DHCPv4 
and DHCPv6(-lite or full), and both give you DNS info, is to being 
considered by DHC WG under "dual-stack DHCP issues".

.

---

From: Pekka Savola <[email-masked]>
Date: Sat, 17 Apr 2004 10:29:22 +0300 (EEST)

I've taken roughly this text, with a change to:

>     not available.

s/not available/unavailable or inappropriate/.

> List of DNS Recursive Servers".

I changed this as well, even though I think "resolvers" is a better 
word for this, and already being used in other documents.  If others 
have arguments about this, please speak up ASAP.

.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 17 Apr 2004 11:04:06 +0200

> hurry to worry which mechanism you start use to discover v6 resolvers.

There is no hurry on the part of operators, they get to do what they 
like. However, implementors must supply operators with the tools they 
need.

> that part of the debate out of here.

None of this is bogus. Running dual-stack has almost no advantages over 
running IPv4-only, it is imperative that we make it possible to run 
IPv6-only, as this is the ultimate goal. Implementations that require 
IPv4 for critical functions, even if it's only for a small set of such 
functions, are useless in the long run. And just because we update a 
spec doesn't mean people get to have implementations that conform to 
the new version any time soon, so we have to get it right from the 
start if at all possible.

> Therefore I'm reluctant to change the tone of the text.

If you prefer to duke it out at IESG last call that's fine with me.

> Depending on the ordering of resolv.conf.

Well, if a hand-crafted resolv.conf is authorative here, why are we 
wasting our time on all these discovery and autoconfiguration issues??

.

---

From: Peter Koch <[email-masked]>
Date: Sat, 17 Apr 2004 11:11:40 +0200

> have arguments about this, please speak up ASAP.

"recursive service" exists, but that's what offered by "recursive resolvers".
While "recursive name server" is unambiguous in this context, I consider this
term technically incorrect. We're clearly after resolvers, not servers here.
One might although argue, that *recursive* resolver is overspecified because
at least I can't imagine a non-recursive resolver.

Coming from the educational perspective and remembering lots of operational
hassle due to misidentification of servers vs. resolvers I'm clearly in
favor of the term resolver here.

-Peter
.

---

From: Jim Reid <[email-masked]>
Date: Sat, 17 Apr 2004 10:37:37 +0100

>>>>> "Peter" == Peter Koch <[email-masked]> writes:

    Peter> "recursive service" exists, but that's what offered by
    Peter> "recursive resolvers".  While "recursive name server" is
    Peter> unambiguous in this context, I consider this term
    Peter> technically incorrect. We're clearly after resolvers, not
    Peter> servers here.  One might although argue, that *recursive*
    Peter> resolver is overspecified because at least I can't imagine
    Peter> a non-recursive resolver.

    Peter> Coming from the educational perspective and remembering
    Peter> lots of operational hassle due to misidentification of
    Peter> servers vs. resolvers I'm clearly in favor of the term
    Peter> resolver here.

Hmmm. Just saying "resolver" could be confusing. This is generally
used (and understood to denote) a stub resolver: something that is
usually non-recursive. How about using "full service resolver" to
indicate something, usually a name server, that gets queried by stub
resolvers and makes iterative lookups to resolve those queries? This
is the term used by the DNSSEC people for the thing that resolves
queries and validates signatures, caches answers, keeps track of RTTs
and so on.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Pekka Savola <[email-masked]>
Date: Sat, 17 Apr 2004 12:35:31 +0300 (EEST)

On Sat, 17 Apr 2004, Iljitsch van Beijnum wrote:
> running IPv4-only, 

I don't think this is correct.  It gives you v6 for services which
would only be available (or working correctly) using v6.  One could
imagine a large number of p2p or similar applications falling under
that category.  Remember, our goal is not to deploy IPv6 so that we 
could surf the web using v6...

You've probably seent his already, but have a peek at:

http://www.cs.utk.edu/~moore/opinions/ipv6/dubious-assumptions.html

(this is down at the moment, but you can get it from google cache.)

> it is imperative that we make it possible to run 
> functions, are useless in the long run. 

Depends on how long run that will be.  If you expect a node to be 
deployed for 10 years, probably yes.  If it gets replaced or upgraded 
in 3 years, there's little chance of IPv4 going away during that time.

> And just because we update a 

Which is why we should not give people panic attacks about this, but 
look at it rationally and carefully.  Get it right.
 
> If you prefer to duke it out at IESG last call that's fine with me.

There will be no IETF last call as this is going for Informational, so
if you really think the text is unjustified (given above), please
state it now (and if possible, suggest alternative that would be more 
in line with the earlier context..)

> wasting our time on all these discovery and autoconfiguration issues??

Obviously, the problem is that resolv.conf is not hand-crafted but 
machine-edited :)

.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 17 Apr 2004 13:29:03 +0200

> would only be available (or working correctly) using v6.

Since there are no services that are inherently only possible over 
IPv6, the existence of services that are only available over IPv6 means 
that someone is running (effectively) IPv6-only. If they were fully 
dual-stack then the service would also be available over IPv4. So 
usefulness of IPv6 == usefulness of IPv6-only.

> One could

Our goal also isn't running IPv6 + IPv4 w/NAT for all eternity. 
Building an IPv6-only network is a much more attractive proposition 
than building an IPv4+IPv6 network, as this way there is no need to 
worry about lots of pesky IPv4 details (the users may have different 
opinions, but I'm talking about building the network right now). In a 
large network, having to run IPv4 everywhere just for the DNS is NOT 
cool, as this means having DHCP servers, worrying about subnet sizes 
and everything else. In an environment where the set of applications is 
limited (I for one only need SSH and HTTP 98% of the time) running 
v6-only internally and use proxying to talk to the v4 world is rapidly 
becoming an interesting option.

> http://www.cs.utk.edu/~moore/opinions/ipv6/dubious-assumptions.html

I'd be happy to swap IPv6 deployment scenarios some time, and mine are 
slightly different than Keith's. But it's not all that relevant. In 
order to be really useful, IPv6 needs to be able to function regardless 
of the IPv4 status du jour. Example: a couple of RIPE meetings ago they 
had lots of troubles with the DHCP server. Now I was happily logged in 
to my server over SSH and tunneling email back and forth, but I was 
completely unable to access any web pages, even the ones on my own box, 
because I couldn't access the DNS: I had no IPv4 address, and MacOS 
didn't support DNS transport over IPv6 at that time. Now if I can run 
into this kind of trouble without actively looking for it, how are the 
chances that something similar will happen at times to the ontold 
millions whom IPv6 will be bestowed upon in the future?

> in 3 years, there's little chance of IPv4 going away during that time.

It's not a question of going away. And how many people are still 
running Windows 98? Or even 95 for that matter? Old stuff just doesn't 
go away.

> look at it rationally and carefully.  Get it right.

No panic attacks, but solid specifications so that people who implement 
them don't have to come back in a few years to update their stuff for 
issues that we are aware of *now*.

> reachable over IPv4 may be used, if available.

Is there anything wrong with this? I think this captures what we want 
implementors to do fairly well. We want them to implement whatever DNS 
discovery we come up with, but if they don't they should at least make 
it possible to configure IPv6 addresses for DNS resolvers manually. 
However, if (they didn't implement the discovery mechanism or no IPv6 
resolvers were found) and no IPv6 resolvers were configured, IPv4 
resolvers can be used.

.

---

From: Pekka Savola <[email-masked]>
Date: Sat, 17 Apr 2004 17:04:41 +0300 (EEST)

I think this discussion is mostly way out of scope here, so I'll try 
to resist continuing on-list except for the last part about the 
actual discovery..

> usefulness of IPv6 == usefulness of IPv6-only.

Wrong.  Think of applications which are much simpler with IPv6, or
cannot be done easily with IPv4.  Such as apps that would need NAT
traversal but plugging them to the current client-server model which
is used to work around the NAT traversal requirement is not feasible.

Pretty much everything can be plugged to v4 with a lot of effort.  But 
at some point someone might actually figure out that doing that makes 
no sense.

> Our goal also isn't running IPv6 + IPv4 w/NAT for all eternity. 

Of course not.

> In a 
> and everything else. 

If we needed to design v6-only systems, I don't think DNS discovery is 
coming even close to top of the list of problems we'd need to solve.

> In an environment where the set of applications is 

And for the rest, 2%?  That's the gritty part here.  (As well as 
deploying the infrastructure for the proxies etc.)
 
> millions whom IPv6 will be bestowed upon in the future?

Sure, this will happen.  But it will be no worse to the mainstream use
as IPv4 won't work in any case, so there's little difference.  Those
who wish to truly avoid v4 are the early deployers in any case, may
have had the DNS resolvers configured manually, using DHCPv6-lite,
some other mechanism, etc.

I'm not arguing that we should delay or avoid specifying DNS 
discovery; I'm just saying that it isn't our top priority, and folks 
who think it is are probably thinking of IPv6 deployment in different 
kind of terms.
 
> running Windows 98? Or even 95 for that matter? Old stuff just doesn't 

Such old stuff (of today, say Windows 2003) is very unlikely even 
supposed to function properly in IPv6-only operation.  There's always 
some old stuff around, but people who aren't switching away from 
that old stuff aren't expecting the old stuff to function except in 
the set-ups which have been stable for a long time.

> resolvers were found) and no IPv6 resolvers were configured, IPv4 

This document is not meant as a lever that can be used to show the 
vendors, "see, we need IPv6 DNS discovery!"; we need 
truth-in-advertising and the earlier statement is fully correct here:

Teasing apart two major points:

 1) DNS resolver discovery is not *required* (in specific scenarios),
but it does not hurt either.

 2) you can only omit DNS resolver discovery if you're in a dual stack 
network and you're a dual stack node (if you have v6-only scenario in 
mind, you need it in any case).

In other words, this says "In specific, common scenarios, IPv6 DNS 
resolver discovery is not required", while your suggestion says "If 
DNS resolver discovery doesn't work or doesn't exist, you can fall 
back to v4 as well if that works for you".

The former is IMHO much more accurate, but I think the "required" part 
could be expanded to include a recommendation as well, like:

   Note that even though IPv6 DNS resolver discovery is a recommended 
   procedure, it is not required for dual-stack nodes in dual-stack
   networks as IPv6 DNS records can be queried over IPv4 as well as
   IPv6.

Would that alleviate your concern?

.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 18 Apr 2004 11:27:14 +0200

> at some point someone might actually figure out that doing that makes

One of the things that makes no sense is to keep using v4 for stuff 
such as DNS lookups and thereby forcing people to keep v4 in their 
network.

> coming even close to top of the list of problems we'd need to solve.

What would this list be then? Feel free to reply privately for this.

> deploying the infrastructure for the proxies etc.)

DNS discovery is most relevant to mobile systems. (It's also very 
useful for non-mobile systems but manual configuration is much more 
doable for those.) So if I only need v4 2% of the time I can easily 
solve this by making sure I connect to a v4-only or dual stack network 
part of the time, while running v6-only some of the time.

>> In order to be really useful, IPv6 needs to be able to function 
>> regardless

> as IPv4 won't work in any case, so there's little difference.

I honestly don't understand how you can say something like this. 
Obviously not having v4 is nearly always a big problem, but if we can 
make sure people still get to use IPv6 in those cases, this would be 
extremely helpful in many cases, even today, for instance in the case 
where the user can access her email over IPv6.

And it provides an incentive to people to deploy dual stack.

> who think it is are probably thinking of IPv6 deployment in different

I'm not privvy to your personal priority list. The only thing I know is 
that we are discussing IPv6 DNS resolver discovery *now* so we need to 
do a goot job at it.

> supposed to function properly in IPv6-only operation.

That's exactly my point. If a simple, but useful DNS discovery method 
had been specified several years ago, Windows 2003 might have included 
it and be able to run v6-only.

Let me ask you a question: suppose that someone wants to make a full 
IPv6 implementation, one that can be expected to work for the next 10 
years or so. At which point in time were (or will be) the IPv6 
specifications mature enough to base such an implementation on?

>    nodes in dual-stack networks as IPv6 DNS records can be queried over

I'm sorry, but I disagree. This text assumes there are nodes which are 
inherently dual-stack. That is an assumption we can't make. Even the 
implementor can't make this decision: whether a node runs v4-only, 
v6-only or dual stack is, and should be, up to the person running the 
box. If implementors don't want to build a stack that doesn't provide 
full functionality in a v6-only setup, that's of course their choice, 
but we should certainly not encourage them to do so. So if you want to 
keep your text, I think we should add:

   However, IPv6 DNS resolver discovery or manual configuration is 
necessary
   for a node to operate in the absense of reachable IPv4 DNS resolvers,
   either because of an outage or because the node is configured for IPv6
   operation only.

> but it does not hurt either.

Which is a moot point, because:

1. This isn't a standards document
2. The specific scenario the node operates under depends on the operator

> The former is IMHO much more accurate,

They're both accurate, the question is what kind of advice implementors 
are going to read into it. You seem to be saying "it's ok to require 
IPv4 to be present" while I want to get across "be careful not to 
unintentionally assume the presence of IPv4". (I would like to go much 
futher than that, though...)

> but I think the "required" part

> Would that alleviate your concern?

No. See above. Any "not required" reads as "don't bother to include 
this part".

.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 19 Apr 2004 17:57:41 +0900

>>>>> On Fri, 9 Apr 2004 18:57:21 +0300 (EEST), 

> just insert a wildcard record, and refer to section 7.2:

(Just in case you're waiting for my response - and if so, sorry for
the delay) the added text works for me.

BTW,

>    server to be authorative for the delegated reverse zone, implying
                  ^^^^^^^^^^^this should be "authoritative"

though you may have already fixed the typo.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 19 Apr 2004 18:57:36 +0900

(I've changed the subject since I'm going to this particular issue
only).

> resolver implementations? 

As a matter of fact, I don't know any DNS server implementations or
stub resolvers that rely on "ANY" (or QTYPE=*) queries.  I'm even not
sure if this is crucial for this discussion...

> does not re-query the one that expired?

No, I don't think it's a bug unless the caching server is the "real
client" of the records.  This is the case when it tries to send a
query to other authoritative servers.

> Should it re-query that?

No, it doesn't have to re-query.

> (because some of them had expired), would you consider this a bug?

No, I'd call a bug in this case if the "real client" asking a caching
DNS server does not re-query for the missing A or AAAA record.

To be more specific, consider an SMTP server and a DNS caching server.
Also assume there is an outside zone "example.com" to which the SMTP
server would want to send e-mail messages and we have different TTLs
for the A and AAAA RRs of the host name pointed by MX in the
example.com zone:

When the SMTP server first tries to send an e-mail message to
example.com, it asks the caching server for an MX record of
"example.com".  The caching server receives all the three RRs, caches
the RRs, and returns them to the SMTP server (MX in the answer
section, and A/AAAA in the additional section).

100 seconds later, the AAAA records expires at the caching server.
As I already said, the caching server does not have to re-query for
the expired recored (and I don't call it a bug of the caching server
if it does not re-query).

Then suppose the SMTP server tries to send another message to
example.com (before the A and MX RRs expire).  It asks the caching
server for an MX record of example.com, and the caching server would
return the MX (in the answer section) and A (in the additional
section) RRs in the cache (but not the AAAA RR).

If the SMTP server has IPv6 connectivity and wants to establish an
SMTP connection over IPv6 to example.com, then it should make another
query for the AAAA RR of "foo.example.com" and send it to the caching
server.  Otherwise, I'd call the SMTP server buggy.

Am I clear enough?

> As for the current wording I've adopted (this probably requires more 

I don't see anything obviously wrong in the planned text below (except
the paragraph beginning with "So, we assume", since this is not what I
meant to say).  However, I still don't understand why we should
mention this in the first place.  Actually, as explained in item 2,
"it is impossible to guarantee that in fact we would always get back
all the records".  Even if we use the same TTL for the A and AAAA RRs
in this example, the caching server can still have a "partial" result,
e.g., due to packet size issues.  On the other hand, we may even want
to use different TTL intentionally, as I explained in my first
message.

Finally, I don't see why the third case below is problematic (BTW: I'm
now confused with the wording of "impartial" there.  What does this
actually mean?)

So, at the moment, I don't see the need for this subsection at all.

					JINMEI, Tatuya

.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 19 Apr 2004 22:09:23 +0300 (EEST)

> sure if this is crucial for this discussion...

OK.

> server.  Otherwise, I'd call the SMTP server buggy.

Yes, this is clear now.

However, I think I have to disagree with the last paragraph a bit.  I 
don't think it's feasible to require you to do special queries in case 
you have IPv6 connectivity, just in case there would be IPv6 records 
which had been omitted from the caches.  The SMTP servers should not 
have to have any such code at all; they should just take whatever they 
are given when they send a MX query and be happy with it.  Forcing any 
IPv6-capable SMTP server to perform a mostly useless AAAA query seems 
like a waste of time and bits.

But as this is the current specification situation, there's not much 
one can do about it.  If you want to be positively sure that you 
always get all the records, you have to query them explicitly 
yourself, with the record type you're interested in getting.

The things that would help here, though, are at least:
 1) if the DNS servers/caches/etc. either sent all the records or no 
additional records unless they can send everything,

 2.a) if the DNS servers/caches/etc. would have identical TTLs for all 
the protocol versions, or
 2.b) if the caches would expire all the records under a hostname
(above, foo.example.com) when the first of A/AAAA records expired.  
This would actually seem to make sense..

To get out of this situation without explicit queries, we'd seemingly 
have to do 1) and either 2.a) and 2.b).  My own personal preference is 
1), recommending 2.a) but not requiring it, and requiring/recommending 
2.b) as caching implementation technique.

> meant to say).

True, I've reworded that.

> However, I still don't understand why we should

I think it might be useful to try to describe these TTL issues 
explicitly, as I their impact hasn't been clearly spelled out wrt. 
records of different types..
 
> now confused with the wording of "impartial" there.  What does this

See above for my belief that we should not have to burden all the SMTP 
servers in the world to make unnecessary queries just to confirm there 
was no IPv6 address for the MX record; the steps described in here go 
a long way in that direction.

I've reworded impartial here.  As RRsets can't be broken up, it was 
used to refer to "both A and AAAA records exists, but a cache returned 
only one kind of them".  I couldn't find a better word (suggestions?) 
but I've reworded it out of these now.

I also changed the order of sections 4.4 and 4.5, as TTL appears to be 
a more specific issue than "impartial" additional data.

The text now is:
======
4.5  The Use of TTL for IPv4 and IPv6 RRs

   In the previous section, we discussed a danger with queries,
   potentially leading to omitting records information from the
   additional section.  This section describes another problem leading  
   to omitting records in cached data, highlighted in the IPv4/IPv6
   environment.

   1.  We get back no A or AAAA records: this is the simplest case,
       because then we have to query which information is required
       explicitly, guaranteeing that we get all the information we're
       interested in.

   2.  We get back all the records: this is an optimization as there is
       no need to perform more queries, causing lower latency. However,
       it is impossible to guarantee that in fact we would always get
       back all the records (the only way to ensure that is to send a
       AAAA query for the name after getting the cached reply); however,
       one could try to work in the direction to try to ensure it as far
       as possible.

   3.  We only get back A or AAAA records even if both existed: this is
       indistinguishable from the previous case, and problematic as
       described in the next section.

   So, we assume we get back both A and AAAA records of foo.example.com,
   or the resolver explicitly asks, in two separate queries, both A and
   AAAA records. After 100 seconds, the AAAA record is removed from the
   cache because its TTL expired.  It would be useful for the cache to
   re-query the AAAA record or discard the A record when the shorter TTL
   (in this case, for the AAAA record) expires; this would avoid the
   situation where there would be a window of 200 seconds when
   incomplete information is returned from the cache. However, this is
   not mandated or mentioned by the specification(s).

.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 19 Apr 2004 22:16:10 +0300 (EEST)

Folks,

I've (again) updated the document, and it is at:

Unless I hear voluminous objections in about 8 hours (i.e., next
morning my time), I'm going to post the draft.

If there are significant issues, I'll delay the posting a day or two.
(Especially I'm interested if Jinmei's TTL issue has been adequately 
addressed.)

Thanks!

.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 20 Apr 2004 15:28:28 +0900

>>>>> On Mon, 19 Apr 2004 22:09:23 +0300 (EEST), 

> yourself, with the record type you're interested in getting.

Okay, so I guess my position is not so different than yours...but one
thing I'd like to emphasize is that the application (the SMTP server
in this case) should not assume anything in the additional section,
and should basically have the ability to fetch missing additional
data.  In that sense, I disagree on your saying that "the SMTP servers
should not have to have any such code at all".

But at the same time, it's okay for me to mention that it may help if
we use the same TTL for A and AAAA RRsets in this type of case.  It's
just a tip that may optimize the thing, though; I think
"recommendation" is a strong word for this.

Okay.

> but I've reworded it out of these now.

Hmm, the sense was not really clear at least to me with the literal
meaning of "impartial".  But I'm not an expert on English wording and
I don't have a better suggestion, so I'd leave this to you (I mean
it's okay if you want to keep it).  (Note that the latest version of
05pre still has this term in Section 4.4, which has been Sect. 4.5 so
far).

The following is my comment on the latest 05pre revision of the draft
(MD5 fingerprint is d59264c3f988a8fc132bc88c6c3de557).  Notice that I
only read Sections 4.4 and 4.5.

4.4  Behaviour of Additional Data in IPv4/IPv6 Environments

   Consider thes case where the query name is so long, the number of the

s/thes/the/

   additional records (originated from "glue") is so high, or for other
   reasons that the response must either be truncated (leading to a
   retry with TCP) or some of the additional data removed from the
   reply.

It's hard to parse the part "or some of the...from the reply".  Do you
mean:

  ...or for other reasons that the response must be truncated (leading
  to a retry with TCP) or some of the additional data must be removed
  from the reply.
?

In the last paragraph,
   ...  The operational fix
   for this is having the DNS server implementations return a warning
   when the administrators create the zones which would result in too
   much additional data being returned.

I think this statement is too strong, since it sounds like this is the
only operational fix.  I'd suggest to reword this e.g., "An
operational fix for this", etc.

s/next/previous/ ?

As a more essential comment, it's still not clear to me what the
problem described in the previous section is...are you particularly
referring to the 3rd paragraph of Section 4.4, that is, (e.g.)
returning A records to an IPv6-only node?

This paragraph seems to have several problems:

1. it's not clear to me why this paragraph begins with "So,".  Do you
   mean something like this?
   "In order to discuss the case where we have both A and AAAA
   records, let's assume we get back both records of foo.example.com,
   or the resolver explicitly asks, in two separate queries, both A
   and AAAA records."

2. in this paragraph, you used the term "resolver".  But I'm not sure
   what it exactly specifies, partly because you also used the term
   "caching resolver" in this section...does the "resolver" mean the
   "caching resolver" or the (so-called) "stub resolver"?  Similarly,
   if you mean the "caching resolver" in "It would be useful for the
   cache to..." (I believe you do), then I'd suggest to reword it as
   "It would be useful for the caching resolver to...".

3. it might be controversial whether "it would be useful for the cache
   to re-query the AAAA record".  This behavior is similar to BIND8's
   "fetch-glue" feature (though the caching server with fetch-glue
   being on does not return the missing additional data to the stub
   resolver during re-fetching it).  But ISC has deprecated the
   feature in BIND9: (from BIND9 ARM) "This is now considered a bad
   idea and BIND 9 never does it."  I don't know the full detail of
   this discussion, but there should be a clear reason for this.

[going to the last paragraph of Section 4.5]

As I already said, "recommended" is too a strong word, IMO.  I'd also
like to add a note that applications should not make or depend on a
particular assumption on the content of the additional section.  So,
I'd revise this part like this:

   To simplify the situation, it might help to use the same TTL for
   all the resource record sets referring to the same name, unless
   there is a particular reason for not doing so.  However, there are
   some scenarios (e.g., when renumbering IPv6 but keeping IPv4
   intact) where a different strategy is preferable.

   Thus, applications that use the response should not rely on a
   particular TTL configuration.  For example, even if an application
   gets a response that only has the A record in the example described
   above, it should not assume there is no AAAA record for
   "foo.example.com".  Instead, the application should try to fetch
   the missing records by itself if it needs the record.

(Note that I use "resource record set(s)" instead of just "record(s)"
where I think more appropriate).

					JINMEI, Tatuya

---

From: David Meyer <[email-masked]>
Date: Thu, 22 Apr 2004 08:05:58 -0700

Folks,

	Please have a look and post any comments you may have to
	the list. We're looking to finish this one up, and your
	input is essential.

	Thanks,

	Dave 
.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 23 Apr 2004 10:12:44 +0900

>>>>> On Thu, 22 Apr 2004 08:05:58 -0700, 
>>>>> David Meyer <[email-masked]> said:

> 	the list. We're looking to finish this one up, and your

At first glance, the 05 revision does not address my last message
about "different TTLs for A and AAAA" (attached below).

					JINMEI, Tatuya

Subject: Re: different TTLs for A and AAAA (Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt)
From: JINMEI Tatuya / 神明達哉 <[email-masked]>
To: Pekka Savola <[email-masked]>
Cc: [email-masked]
Date: Tue, 20 Apr 2004 15:28:28 +0900

Okay.

s/thes/the/

In the last paragraph,
   ...  The operational fix

s/next/previous/ ?

					JINMEI, Tatuya

---

From: Pekka Savola <[email-masked]>
Date: Fri, 23 Apr 2004 13:13:54 +0300 (EEST)

Hi,

Thanks for the insistence.  I think this should address your 
concerns..

Working copies at:
http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-06pre-diff.html
http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-06pre.txt

(I've only changed what you're commenting, and what Iljitsch was 
saying about DNS resolver discovery on v6-only networks.)

> "recommendation" is a strong word for this.

I'm not sure if I fully agree with this but as I don't have a strong 
opinion, I've just taken what you say.

> 05pre still has this term in Section 4.4, which has been Sect. 4.5 so

I reworded that to "missing some RRsets".

>   to a retry with TCP) or some of the additional data must be removed

Yes, changed.
 
> operational fix for this", etc.

Agree, changed.
 
>        described in the next section.

OK
 
> returning A records to an IPv6-only node?

Yes, that's the problem.  I can't think of ways to make it clearer.

(I'd also like to get to the situation where every v6 enabled node 
that would prefer to use v6 if possible wouldn't have to do an 
explicit query for AAAA records every time it's sending mail...)

>    or the resolver explicitly asks, in two separate queries, both A

Not quite.  The target might have both A and AAAA records, but the 
resolving host might only get back one set of these.  We discussed the 
other case in previous section, so rewording this to:

        <t>As the third case was considered in the previous section,
we assume we get back both A and AAAA records of foo.example.com, or
the stub resolver explicitly asks, in two separate queries both A and
AAAA records.</t>
 [...]
 
>    "It would be useful for the caching resolver to...".

In the above paragraph, "resolver" meant the stub resolver. Reworded.

I don't think we can get much more by honing the terminology as 
stub resolvers can also include caching, but changed to like:

        <t>After 100 seconds, the AAAA record is removed from the
cache(s) because its TTL expired.  It would be useful for the caching
resolvers to discard the A record when the shorter TTL (in this case,
for the AAAA record) expires; [...]

>    this discussion, but there should be a clear reason for this.

OK, I'm fine with dropping re-querying unless there are other 
opinions; I'll just keep the discarding part. (See above.)

> where I think more appropriate).

I don't think "recommends" is too strong, but I took you suggestion.

(I also changed some "record(s)" to "RRset(s)" elsewhere in the 
document where that is appropriate.)

.

---

From: Rob Austein <[email-masked]>
Date: Fri, 23 Apr 2004 12:43:02 -0400

<hat wg-co-chair=off just-another-bozo=on>

> have arguments about this, please speak up ASAP.

Sorry not to have caught this question sooner.

Short answer: Ralph was right, the correct term is "recursive name
server".  That's the closest thing we have to standard term for a name
server supporting recursive service (ie, an entity which accepts DNS
messages with QR=0, RD=1 and replies with messages with QR=1, RA=1).

"Resolver" just means an entity which sends messages with QR=0 and
receives messages with QR=1.  "Resolver" without further qualification
does not specify the query mode in which the resolver operates
(recursive or iterative).

Name server just means an entity which receives messages with QR=0 and
replies with messages with QR=1.

An entity which both sends and receives both queries and responses is
both a name server and a resolver (hence much of the confusion), but,
at the conceptual level, it's a name server glued back to back with a
resolver, with communciation between the two to handle recursive mode
queries.  "Recursive server", or, more properly, "recursive name
server", means a name server which offers recursive service, ie, a
name server which a recursive-mode resolver might expect to do
something useful if sent a query with RD=1.

Please also see the discussion in draft-ietf-dnsext-dnssec-intro,
which not only goes into a bit more detail but also tries to expand
this terminology to cope with the joys of DNSSEC.

</hat>
.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 26 Apr 2004 20:27:10 +0900

>>>>> On Fri, 23 Apr 2004 13:13:54 +0300 (EEST), 

> Thanks for the insistence.  I think this should address your 

Thanks for your patience.  The 06pre revision basically looks fine,
and I can live with it.

However, IMO it could use further clarification on missing records in
the additional section.

As someone has already pointed out in this list (if I remember
correctly), the level of the problem of missing additional records
differs between "glue" records and other additional data.

The "glue" case: consider a zone delegation with the following
configuration:

child.example.com.  IN NS ns.child.example.com.
ns.child.example.com. IN A 192.0.2.1
ns.child.example.com. IN A 192.0.2.2
...
ns.child.example.com. IN A 192.0.2.X
ns.child.example.com. IN AAAA 2001:db8::1
ns.child.example.com. IN AAAA 2001:db8::2
...
ns.child.example.com. IN AAAA 2001:db8::Y

(where X and Y are some large numbers)

when a caching resolver tries to resolve a name under
child.example.com, it will get the NS record from the parent zone
(example.com.) and the glue A and AAAA RRset.  If either or both
RRsets must be removed from the additional section and the caching
resolver cannot get an appropriate RRset for transport available for
the resolver, this is a critical problem; there is no other workaround
for this problem.  (The problem can happen even without AAAA (or A),
and in that sense, this is not specific to IPv6.  But adding AAAA can
increase the risk of missing additional data, so this is a kind of
IPv6-related problem.)

On the other hand, in the case of other additional data, just like
described in the example of Section 4.5, the problem is not critical;
the final user (application) of the missing record can issue another
query to fetch it.  Even though it makes additional delay or
consumption of network resource, at least we have a workaround.

So, the desirable logic in Sections 4.4 and 4.5 is, IMO, as follows:

- Section 4.4
  + there are two types of problems caused by missing additional
    data.
  + one of the problems is critical.  the other can cause suboptimal
    results, but there are workarounds
  + for both problems, a protocol fix (EDNS0) and an operational fix
    can be considered.
  + for the non critical problem, the application should be careful to
    not make the problem critical (perhaps we should move the last
    paragraph of Section 4.5 here)
  (other considerations, such as the one described in the second
  paragraph of the current document)

- Section 4.5
  different TTLs for A and AAAA can cause a similar problem as the
  non-critical one described in Section 4.4.  Using the same TTL might
  be useful to minimize the problematic cases.  Still, applications
  should be careful enough.

Again, I can live with the current text in 06pre.  I'd leave it to you
whether to adopt the revised logic.

					JINMEI, Tatuya

---

From: Pekka Savola <[email-masked]>
Date: Tue, 27 Apr 2004 17:26:23 +0300 (EEST)

>   should be careful enough.

Agreed.

I've updated the text a bit, trying to make this clearer:

Please see if these reflect to what you had in mind; I'm hoping of
submitting this within a day.

.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 28 Apr 2004 00:18:50 +0900

>>>>> On Tue, 27 Apr 2004 17:26:23 +0300 (EEST), 

> submitting this within a day.

From a quick check, I suspect you typed the keyboard too fast, because
I could not understand the following part

   In other words, there are two kinds of additional data: the kind that
   must be included (all RRsets) no matter what (an example of this is
   below), and the kind which could be omitted in full or in part, but
   could cause nonoptimal results (an example of this is in the next
   section):

I'm even not sure if this is a complete set of paragraphs you intended
to add...

Another minor nit:

   Additionally, to avoid the case where an application would not get an
   address at all due to non-critical additional data being omitted, the
   applications should be able to query the specific records of the
   desired protocol, not just rely getting all the required RRsets in
   the additional section.

I guess "rely getting" should actually be "rely on getting".

					JINMEI, Tatuya

.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 27 Apr 2004 22:19:32 +0300 (EEST)

> I'm even not sure if this is a complete set of paragraphs you intended

Hmm.  I can find no problems with this.  What may be confusing is at 
the end I said next _section_, not next paragraph, and the example I 
quoted from you relates to the first case.

I tried to reword it for clarity:

=======
  In other words, there are two kinds of additional data:

   1.  "critical" additional data; this must be included (all the
       possible RRsets) in all scenarios, and

   2.  "courtesy" additional data; this could be sent in full, with only
       a few RRsets, or with no RRsets, and can be fetched separately as
       well.

   An example of the latter are A/AAAA records in conjunction of MX
   records as shown in the next section; an example of the former is
   shown below:

   In the case of too much additional data, [...]
=======

Is this better?

Yep.

.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 28 Apr 2004 15:32:27 +0900

>>>>> On Tue, 27 Apr 2004 22:19:32 +0300 (EEST), 

> Is this better?

Yes, but I still have a couple of concerns:

1. it's not very clear how the first and second paragraphs relate each
   other with the phrase 'In other words'.  I guess you intended to
   emphasize that the following sentence in the first paragraph

     However, note that if too much additional information that is not
     strictly necessary would be added, one should remove unnecessary
     information instead of setting TC bit for this "courtesy" information
     [19].

  is the second one (item 2) in the classification of the second
  paragraph.  However, the first paragraph does not seem to talk about
  the "critical" kind of additional data, so it is a little bit
  strange to see "In other words" at the beginning of the second
  paragraph.

  Additionally, the first paragraph contains supplemental description
  which is not directly related to the classification in the second
  paragraph: the fact that RRsets cannot be broken up.  This also
  causes the confusion.

2. it is confusing to use "2001:db8::Y" without explaining what Y
   means.  In this context, I guess you could simply use an arbitrary
   hex value, e.g., "2001:db8::2".

------------ end of concerns ------------

So, I'd totally revise the beginning of this section (including the
first and second paragraphs) as follows:

   Consider the case where the query name is so long, the number of the
   additional records (originated from "glue") is so high, or for other
   reasons that the entire response would not fit in a single UDP packet.
   In some cases, the responder truncates the response with the TC bit
   being set (leading to a retry with TCP), in order for the querier
   to get the entire response later.

   However, note that if too much additional information that is not
   strictly necessary would be added, one should remove unnecessary
   information instead of setting TC bit for this "courtesy" information
   [19].

   Also notice that there are two kinds of additional data:

   Meanwhile, resource record sets (RRsets) are never "broken up",
   so if a name has 4 A records and 5 AAAA records, you can either
   return all 9, all 4 A records, all 5 AAAA records or nothing.
   Notice that for the "critical" additional data all the latter three
   cases can be critical. 

   An example of the "courtesy" additional data is A/AAAA records in
   conjunction of MX records as shown in the next section; an example
   of the "critical" additional data is shown below:

   (where the lack of either A or AAAA RRsets can be critical)

-------------

One additional comment: reconsidering the entire context, I guess the
first sentence of the following paragraph should be clarified:

   In the case of too much additional data, it might be tempting to not
   return the AAAA records if the transport for DNS query was IPv4, or
   not return the A records, if the transport was IPv6.

to, e.g.,

   In the case of too much "courtesy" additional data, ...

					JINMEI, Tatuya

---

From: Pekka Savola <[email-masked]>
Date: Wed, 28 Apr 2004 10:53:33 +0300 (EEST)

> first and second paragraphs) as follows:

I agree with you.

I've taken almost all of what you suggest, with a few touches; the 
most important of them were:

 - remove the mostly redundant "In other words" paragraph, integrate 
it with the earlier numbered list.
 - add an explicit note that it would be better to omit all of 
courtesy additional data (now that we have a semantic difference) 
rather than returning only some RRsets.
 - I didn't understand what you wrote about the all "all the 
latter three cases", so I reworded that.
 - some minor changes.

(See below for text.)

>    In the case of too much "courtesy" additional data, ...

Did we (as WG) already agree that it's better to set TC bit than
return only some RRsets of critical additional data?  I'd love that
kind of resulution, but for now, I put "(whether courtesy or
critical)" there.  If folks have strong feelings of this, let's start
a new thread explicitly only about this.

In any case, I've updated the documents at the same locations, and 
included the current section 4.4. below.

=====

   Consider the case where the query name is so long, the number of the
   additional records (originated from "glue") is so high, or for other
   reasons that the entire response would not fit in a single UDP
   packet. In some cases, the responder truncates the response with the
   TC bit being set (leading to a retry with TCP), in order for the
   querier to get the entire response later.

   2.  "courtesy" additional data; this could be sent in full, with only
       a few RRsets, or with no RRsets, and can be fetched separately as
       well, but which could lead to non-optimal results.

   Meanwhile, resource record sets (RRsets) are never "broken up", so if
   a name has 4 A records and 5 AAAA records, you can either return all
   9, all 4 A records, all 5 AAAA records or nothing.  Notice that for
   the "critical" additional data getting all the RRsets can be
   critical.

   An example of the "courtesy" additional data is A/AAAA records in
   conjunction of MX records as shown in the next section; an example of
   the "critical" additional data is shown below (where the lack of
   either A or AAAA RRsets can be critical):

   In the case of too much additional data (whether courtesy or
   critical), it might be tempting to not return the AAAA records if the
   transport for DNS query was IPv4, or not return the A records, if the
   transport was IPv6.  However, this breaks the model of independence
   of DNS transport and resource records, as noted in Section 1.2.

   This temptation would have significant problems in multiple areas.
   Remember that often the end-node, which will be using the records, is
   not the same one as the node requesting them from the authoritative
   DNS server (or even a caching resolver).  So, whichever version the
   requestor ("the middleman") uses makes no difference to the ultimate
   user of the records.  This might result in e.g., inappropriately
   returning A records to an IPv6-only node, going through a
   translation, or opening up another IP-level session (e.g., a PDP
   context [20]).

   The problem of too much additional data seems to be an operational
   one: the zone administrator entering too many records which will be
   returned either truncated or missing some RRsets to the users.  A
   protocol fix for this is using EDNS0 [40] to signal the capacity for
   larger UDP packet sizes, pushing up the relevant threshold. Further,
   DNS server implementations should rather omit courtesy additional
   data completely rather than including only some RRsets. An
   operational fix for this is having the DNS server implementations
   return a warning when the administrators create the zones which would
   result in too much additional data being returned.

   Additionally, to avoid the case where an application would not get an
   address at all due to non-critical additional data being omitted, the
   applications should be able to query the specific records of the
   desired protocol, not just rely on getting all the required RRsets in
   the additional section.
====

.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 28 Apr 2004 20:28:57 +0900

>>>>> On Wed, 28 Apr 2004 10:53:33 +0300 (EEST), 

> it with the earlier numbered list.

Ah, that should have been removed from the proposed text of mine.  I
was not careful enough.  Removing this is of course fine.

> rather than returning only some RRsets.

Okay.  I'm not sure if it is a good practice to remove the entire
RRsets, but I don't oppose to suggesting that.

> latter three cases", so I reworded that.

Okay.  Perhaps the confusion came from that I intended to use the word
"critical" for "critically bad" whereas you seem to have intended to
use the same word for "critically important".  I'm fine with rewording
that part, but then in the following sentence

   (where the lack of

it might be better to say "where getting both the A and AAAA RRsets is
critical".

> a new thread explicitly only about this.

What I wanted to say is that in the critical case (particularly in the
case of the glue for a delegation), it might make sense to organize
the additional section based on the transport.  In fact, if the
respondiner is going to return a delegation to a caching (or
recursive?) resolver using IPv4 transport, it is probably better to
prefer A RRset (as glue) to AAAA.

I basically support your opinion, though.  As the draft says, it
should be better to not combine the content with transport, based on
the basic model of DNS.  Also, we can even construct a case where the
querier that receives the delegation in the above example can be just
a "middle-node" and the real "user" exists behind the node.  (e.g.,
there is a simple DNS forwarder to help IPv4<->IPv6 translation, which
does not act as a recursive resolver - though this might be a tricky
example).

We could probably describe the subtle points, but this might be a
minor detail, so, as a result, I can live with the current wording of
yours.

					JINMEI, Tatuya

---

From: Pekka Savola <[email-masked]>
Date: Wed, 28 Apr 2004 16:10:36 +0300 (EEST)

Hi,

I posted -06 document, which appears to be good for now.

> RRsets, but I don't oppose to suggesting that.

OK.  (There are certainly arguments both ways, but my main point was
that the integrity of _all_ the information should be most important,
except if there is no other choice.)
 
> it might be better to say "where getting both the A and AAAA RRsets is

Changed.
 
> minor detail, so, as a result, I can live with the current wording of

There are tradeoffs each way whether to expand these right now or not.  
It seems to me that in order to do that, we'd have to gain WG 
consensus on the approach to go forward, and that's always difficult 
and time-consuming.. so I've avoided doing that for now.

I'll consider posting a separate thread on the subject to gauge
opinions when we get into the "waiting for IESG evaluation" stage.

.