Subject: [dnsop] WGLC for "IPv6 Host Configuration of DNS Server Information Approaches"

From: David Meyer <[email-masked]>
Date: Wed, 16 Jun 2004 13:21:11 -0700

Folks

	This note starts the WG Last Call for comments on
	draft-ietf-dnsop-ipv6-dns-configuration-01.txt, 
	"IPv6 Host Configuration of DNS Server Information
	Approaches". It can be found on 
	
	ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-ipv6-dns-configuration-01.txt

	Please review the document carefully, and send your
	feedback to the list.  Please also indicate whether or
	not you believe that this document is ready to go to the
	IESG. Note that this is a somewhat unusal case as the
	IESG requested this document.

	This Last Call will end on 30 June 2004 at 1400 PDT (UTC/GMT-7).

	Thanks,

	Dave & Rob

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Soohong Daniel Park <[email-masked]>
Date: Mon, 21 Jun 2004 13:34:18 +0900

I guess this draft should be carefully reviewed but no reaction
appear until now. Please make a time to look into it and let us 
know your valuable feedbacks/comments.

Thanks in advance.

- Daniel (Soohong Daniel Park)
- Mobile Platform Lab. Samsung Electronics.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of David Meyer
> Sent: Thursday, June 17, 2004 5:21 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [dnsop] WGLC for "IPv6 Host Configuration of DNS Server 
> Information Approaches"
> 
> 
> 
> 	Folks
> 

	Thanks,

	Dave & Rob

.

---

From: Soohong Daniel Park <[email-masked]>
Date: Mon, 21 Jun 2004 20:04:28 +0900

Fairness sounds good and I am also following up
this thread on the IPv6 WG, so I will be silent in
this mailing list. I also have an experience of
limitation of multicast ND within WLAN. Anyway
please gather valuable comments and let us know
them as soon as possible.

Thanks in advance.

> From: Masataka Ohta [mailto:[email-masked]]
> Sent: Monday, June 21, 2004 8:01 PM
> To: Soohong Daniel Park
> Cc: [email-masked]
> Subject: Re: [dnsop]REMINDER: WGLC for "IPv6 Host Configuration 
> of DNS Server Information Approaches"
> 
> 
> Soohong Daniel Park wrote:
> 
> I do have some comments on WLAN and ND but am waiting for
> possible feedback from IPv6 WG for fairness.
> 
> So far, I can safely say that ND does not work well over
> WLAN, which requires several corrections.
> 
> 						Masataka Ohta
> 
> 
> 
> 
.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 21 Jun 2004 20:00:54 +0900

Masataka Ohta

.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 22 Jun 2004 14:38:41 +0900

(trying to resend from a different address which I guess the list
management system expects)

I've also added a few more comments to the previous (undelivered)
message.  So if the original message is ever delivered, please just
ignore it (and forgive me for the duplicate).

>>>>> On Wed, 16 Jun 2004 13:21:11 -0700, 
>>>>> David Meyer <[email-masked]> said:

> 	IESG requested this document.

Comments are below.

In short, I don't think it's ready to be sent to the IESG.  I agree
this can be a useful document, but it still contains non trivial
issues.

A meta comment (question):

This draft seems to adopt all the three approaches.  Does this mean we
gave up on choosing a single particular approach for this purpose, or
even gave up on specifying one "default" approach?  If so, then I
guess implementors will need to implement all the approaches (if it
needs implementation support) and/or operators will need to be
familiar with all possible approaches.  Is my understanding correct?

See also a specific comment 11 below.

Then...I'm sad.  With the chaos we've seen so far on this, however, I
understand what we need is some kind of compromise to move forward,
and I guess this is perhaps the compromise.

NON EDITORIAL COMMENTS (some of them may still be minor though)

1. Author list

Currently eight people are listed, which are much more than the norm
(up to 5) mentioned in Section 2.12 of
draft-rfc-editor-rfc2223bis-07.txt

2. formfeed characters

It would be better if the draft has the character ("Ctl-L") at page
boundaries.

3. redundant white space characters

It seems to me the draft has white space characters (" ") at each end
of lines.  It's probably better to remove them (at least it helps
shrink the total size of the file:-)

4. Introduction 

   IPv6 stateless address autoconfiguration provides a way to 
   autoconfigure either fixed or mobile nodes with one or more IPv6 
   addresses, default routes and some other parameters [3][4].

As indicated by the two references, just saying "IPv6 stateless
address autoconfiguration" is not enough.  The Neighbor Discovery
protocol also provides a way of configuration.

5. Section 3.1 

   The configuration of DNS server address can be 
   performed manually by operator or automatically DHCPv6 client 
   running on the router.

We need some clarification here to apply "dynamic *HOST* configuration
protocol" to the *router*.  Yes, we did a similar usage for prefix
delegation (RFC3633) where a requesting *router* acts as a DHCPv6
client.  In my understanding, however, that was a very special case
which can be considered as an exception.  Even if we agree on using
the same logic again, I still believe this document should clarify the
point explicitly.

6. Section 3.1.1 (Advantages of the RA option)

The draft says

   1) The RA option is a simple extension of existing ND/Autoconfig  
   mechanisms [3][4].  No new protocol mechanisms are needed and 
   extending an ND implementation to support this option should be 
   very simple. 

I don't think this is a valid statement.  I'd rather remove this item,
or at least I'd heavily reword it to be fair.

First, the meaning of "no new protocol mechanisms are needed" is
vague.  In the sense that we need an unstandardized extension to the
base ND protocol, we need a "new protocol mechanism" for the RA option
approach (on the other hand, we don't need any "new protocol
mechanism" for the DHCPv6 approach in this sense).  If you mean the
granularity of, say, the whole ND or the whole DHCPv6 by a "protocol
mechanism", then this advantage will also apply to the DHCPv6 approach
(and probably to the well known address approach as well).  So, to be
fair, we'll need to repeat this advantage for all the other
approaches, or we might simply remove this trivial advantage among the
considered three.  I'd personally prefer the latter.

Secondly, even if we decide to keep this advantage, I would reword
it without using the term "simple."  I often feel people tend to use
this word when they just prefer something over some other things by
saying the former is "simpler" than the latter.  At very least,
"simple" is a subjective term and is in general inappropriate in a
technical document.  (The same comment could apply to all the other
occurrences of "simple" in the document, but I think this one here is
particular important since this is explicitly counted as an
"advantage" of a particular approach).

Without having "simple", this statement would be just like this:

1) No new protocol mechanisms are needed.

Note that my first comment still holds.

7. Section 3.1.2 (Disadvantages of the RA option)

I think this document should include another disadvantage of the RA
option: we need to configure the RDNSS addresses at least at one
router on every link where this information needs to be configured by
this mechanism.

If there is a hidden assumption that the router can be autoconfigured
with the RDNSS addresses by DHCPv6, see comment 5 above.  Also, if we
take this approach, one of the advantages of the RA option may
plummet: address renumbering case, since DHCPv6 may not be able to
update the address quickly.

With DHCPv6, we can mitigate the configuration load with multicast
routing.  Of course, deploying multicast routing can be another
barrier of deployment, so there is a tradeoff.

With the approach of well known addresses, the configuration load will
depend on how much we should do to set up routing for the well known
addresses.  In an extreme (but not so rare) case where no route
filters are configured within the administrative domain, we basically
should not have to do anything special in routers.

8. Section 3.2 (DHCPv6 Option)

   DHCPv6 currently provides a mechanism for reconfiguring DHCPv6 
   clients.  [...]

In my understanding, DHCPv6 reconfigure can only be used for the
"stateful" mode of the protocol.  At very least, RFC3736 does not
require implementing reconfigure message, so implementations that only
conform to RFC3736 may not support reconfigure mechanism.

I believe this document should explicitly note this limitation.

9. Section 3.2.1 (DHCPv6 Advantages)

   5) Hosts in some environments are likely to need DHCPv6 for other 
   configuration information. 

This statement is quite vague for me.  Please be more specific on
"some environments".

10. Section 3.2.1 (DHCPv6 Advantages)

   7) Interoperability among independent implementations demonstrated 
   at TAHI and Connectathon. 

I'm not sure if particular event names are suitable in an RFC (I'm
just wondering; I don't have a particular opinion on this, and I, for
one, can live with or without the event names).

11. From Section 3.2.3 (DHCPv6 Observations),

I have an impression that the use of the RA option approach will be
very limited to "special applications".  However, I have a different
impression from Section 3.1, which seems to say the RA option is a
generic solution.

If my understanding is correct, then I hope the document will be
consistent on this.  Even if it can't, then it should clarify why two
different opinions (which might even contradict with each other)
appear in this single document.

12. Section 3.3 (Well-known Anycast Addresses)

I believe this draft should clarify that "anycast" is a different
notion from the one defined in the IPv6 addressing architecture (e.g.,
RFC3513).  For example, reference [9] of this draft requires using the
anycast address as a source address for TCP responses while the
address architecture prohibits this usage.

13. Section 3.3 (Well-known Anycast Addresses)

Readers would expect the same organization for this section as that
for Sections 3.1 and 3.2: general description, advantages,
disadvantages, and observation.  It might be helpful for readers if
Section 3.3 can use the same organization.

(This is just a comment, and not a requirement for advancing the
document)

14. Section 3.3 (Well-known Anycast Addresses)

   Well-known anycast addresses can be combined with cryptographic 
   security such as TSIG or DNSSEC.  However, there is no point to 
   avoid manual configuration of DNS when secret information (such as
   a shared secret key or a public key of root zone) for the 
   cryptographic security must manually be configured (and updated 
   periodically). 

I don't understand the role of this paragraph in the context of this
section or of the entire document...perhaps additional background
might help or we can simply remove this paragraph?

15. Section 4 (Interworking among IPv6 DNS Configuration Approaches)

   For ordering between RA and DHCP approaches, O (Other stateful 
   configuration) flag in RA message can be used [5].  If no RDNSS 
   option is included and O flag is set on in RA message, an IPv6 Host
   may perform DNS configuration through DHCPv6 [6]-[8]. 

Note that we are going to loosen the relationship between the O flag
and the invocation of DHCPv6 in rfc2462bis.  Right now, I'm not sure
how we can reflect the forthcoming change in this document though (or
whether we need to reflect that in the first place).

16. Section 5.2.1 (Multi-level Network Topology)

   The rest of routers below can automatically configure 
   DNS information through DHCPv6.

The same note on the use of DHCPv6 to routers applies here (see
comment 5 above).

Additionally,

   For redundancy and load sharing, well-known anycast
   addresses can be used by IPv6 hosts through RDNSS RA option.  

This statement seems to contradict with Section 3.3 where the draft
says anycast addresses are not for redundancy.

17. Normative References

There are two work-in-progress documents:

  draft-jeong-dnsop-ipv6-dns-discovery-01.txt
  draft-ohta-preconfigured-dns-01.txt

Can't we have these as normative references unless these are published
as a stable document (presumably an RFC) before the publication of
this document or at least synchronously?  Or is that actually the
plan?

EDITORIAL COMMENTS

18. (throughout the document)

Whereas this document seems to try using Recursive DNS Server (or
"RDNSS") instead of just "DNS server(s)" throughout the document,
there are still many occurrences of the phrase like "DNS server".

Just one example in Section 3.1 (page 4):

   The configuration of DNS server address can be 
   performed manually by operator or automatically DHCPv6 client 
   running on the router.

Even abstract contains the phrase.

I believe the document should perfectly be consistent on this.

19. In Section 3.1

   The RA approach is useful in environments where the addresses of 
   the recursive DNS servers is changing because the RA option 

"is changing" should be "are changing"

20. In Section 3.3 (Well-known Anycast Addresses)

   DNS clients have redundancy by having multiple resolvers that there
   should be multiple well-known anycast addresses configured on 
   clients.

I can't parse the sentence...does this mean, e.g, the following?

   DNS clients have redundancy by having multiple well-known anycast
   addresses configured as RDNSS addresses.

21. In Section 5.1.1 (RA Option Scenario)

   For easy configuration on the ISP, 
   DNS information, unsolicited RA message including a new DNS option 
   can be delegated to its subnet periodically.

I can't parse this sentence.  In particular, I don't understand the
role of the phrase "DNS information" in this sentence.

22. In Section 5.3.3

   3) Scalability and reliability of DHCPv6 in very large 3GPP 
     networks 
   (with tens or hundreds of millions of UEs) may be an issue, at 
   [...]

The second line seems to be too short (as a part of a single
sentence).

Similarly,

   4) It is sub-optimal to utilize the radio resources in 3GPP 
   networks 
   for DHCPv6 messages if there is a simpler alternative available. 

The second sentence seems to be too short.

					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: Pekka Savola <[email-masked]>
Date: Tue, 22 Jun 2004 20:40:41 +0300 (EEST)

I agree with most comments from Jinmei, but here's one which requires 
a comment..

On Tue, 22 Jun 2004, JINMEI Tatuya / [ISO-2022-JP] 神明達哉 wrote:
[...]
> update the address quickly.

I personally don't think having a router which doesn't have any DNS
servers configured is a very feasible scenario.  All the routers I can
quickly think of have a configured DNS server.

But I think what you're saying in the second paragraph is slightly
different. I.e., today's low-end router/NAT boxes have DNS servers,
but those are configured using DHCPv4.  How would DNS servers be
configured on such boxes when they support v6?  This is probably a 
good question.

Note that in some environments, this may not be a problem (e.g., 3GPP)
-- where you can assume that the first-hop router is a real, manually
configured router, not a low-end CPE.

-- 
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: Tue, 22 Jun 2004 15:19:07 -0400

Jinmei-san - responding to your meta-comment: My understanding is that this
document is the response to a request from the IESG to describe the
alternatives for DNS server configuration, without making any kind of
recommendation or choice.  The IESG will use the contents of the document in
making a decision about whether to charter any additional work on DNS server
configuration protocols in any WGs.

- Ralph

At 02:38 PM 6/22/2004 +0900, JINMEI Tatuya / 

.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 23 Jun 2004 04:19:59 +0900

JINMEI san;

My comments on your comments on WKA approach.

Perhaps, I should provide revised text on WKA part, if we can
reach a consensus.

> should not have to do anything special in routers.

"within the administrative domain" should be "within or between
the administrative domain".

It should also be noted:

   As DNS servers need configuration and the number of separate
   administrative domains is proportional to (or less than) the
   number of DNS servers, the amount of configuration on routers
   scales.

> address architecture prohibits this usage.

Yup. The fundamental difference to is that it is assumed to be
administratively prohibited to have anycast servers sharing
an anycast address in a single link. Then, most of instabilities
disappear.

> Section 3.3 can use the same organization.

OK.

> might help or we can simply remove this paragraph?

The intention is to say that there is no secure ND nor secure DHCP,
unless you manually configure a lot. :-)

With the current security consideration section, the paragraph
can be removed.

> says anycast addresses are not for redundancy.

Huh? 3.3 of the draft says:

   Large ISPs may 
   operate multiple recursive resolvers at each anycast address to 
   distribute and reduce load

> this document or at least synchronously?  Or is that actually the

ID can refer anything.

						Masataka Ohta

.

---

From: David Meyer <[email-masked]>
Date: Tue, 22 Jun 2004 13:35:29 -0700

Jinmei-san,

>> configuration protocols in any WGs.

	Ralph's understanding of the charge from the IESG is
	correct. In particular:

>> This draft seems to adopt all the three approaches.  Does this
>> mean we gave up on choosing a single particular approach for this
>> purpose, or even gave up on specifying one "default" approach?
>> If so, then I guess implementors will need to implement all the
>> approaches (if it needs implementation support) and/or operators
>> will need to be familiar with all possible approaches.  Is my
>> understanding  correct?

	No, not correct (at the very least, the conclusion that
	implementors will need to implement all approaches is
	neither specified nor mandated by this draft). The draft
	does not adopt any approach. Rather, it documents the
	different proposals. The IESG will use this information
	to determine how to move forward. The WGLC is being used
	to determine if the analysis of the attributes of the
	different approaches can be agreed upon (not which one
	should be adopted). Does this help? 

	Dave
.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Jun 2004 15:14:57 -0700

> configured on such boxes when they support v6?  This is probably a

This is an excellent point.   What's the equivalent of one of these 
boxes in IPv6 land?   Obviously we don't need a NAT (although I'm sure 
someone will offer one for sale).   But we might need an equivalent 
box, and how that box is provisioned with DNS information is a good 
question.   The WKA approach works well here.   For DNS-in-RA, I'm not 
sure what you'd do - just propagate the server address you get on the 
ISP side to the inside?   Do customer-premise routers for home users 
and dentists' offices become obsolete with IPv6?

.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 22 Jun 2004 16:22:57 -0700 (PDT)

I think customer-premise routers become full-function routers in the IPv6
model.  All of the ISP/MSOs I've spoken with and all of the
strawperson ISP architectures I've seen anticipate customers having
a CPE router at the edge of the customer network.

The WKA approach works - as long as the propagation/routing boundary is
configured to allow routing of DNS messages to/from the WKA across the
customer/provider boundary between the CPE router and the ISP/MSO edge
router.

DHCPv6 also works - especially nicely in tandem with DHCPv6 PD, which
seems to be popular as the means for provisioning the CPE router.

- Ralph

.

---

From: Bob Hinden <[email-masked]>
Date: Tue, 22 Jun 2004 16:36:10 -0700

Jinmei,

>familiar with all possible approaches.  Is my understanding correct?

As described by Ralph and Dave, this was not the intent of this 
document.  It was to provide a description of each approach and what the 
proponents for each approach thought their advantages and disadvantages were.

>and I guess this is perhaps the compromise.

I agree.  There are different points of view and it doesn't seem like there 
will be a consensus on any specific approach.

>protocol also provides a way of configuration.

I agree.

>the same logic again, I still believe this document should clarify the

I am not sure it's that useful at this point to try to define this in more 
detail.  I think DHCPv6 would be fine for this, but there are many other 
ways this could be done including pushing/pulling a configuration file, 
network management protocols, CLI, and various proprietary methods.  It 
would be good to revise the text to say there are a number of ways of doing 
this and not try to be very specific about which one is best.

>or at least I'd heavily reword it to be fair.

The intent of "no new protocol mechanisms" text was it was only necessary 
to define a new option, not change the ND protocol.  Just the same as if 
one was to define a new DHCP option, the protocol mechanisms of the DHCP do 
not need to change.  Does that help?

>1) No new protocol mechanisms are needed.

Well the extension seems simple enough to me :-)

>router on every link where this information needs to be configured by

I think this is a reasonable comment.  I happen to think this isn't a very 
significant issue as many routers may already have this information for 
their own use, but I agree it should be stated.

>update the address quickly.

Considering all of the other things that have to be updated in a router 
when one renumbers this doesn't seem like a significant problem to 
me.  Much of the other information advertised by ND would also have to be 
updated.

>barrier of deployment, so there is a tradeoff.

Right.  Automatic renumbering is a big issue, even with DHCPv6 the 
addresses of the relay agent will need to be updated.  I don't think 
renumbering is a very useful evaluation criteria.

>should not have to do anything special in routers.

This is one of the advantages of well known addresses.

.....

>appear in this single document.

I think it's better given the nature of the document to leave the 
observation sections to be what the "proponents" think makes a good overall 
solution.  Maybe we need to say something about this in the introduction.

.....

>this document or at least synchronously?  Or is that actually the

I think the normative issue only applies if this document is to become a 
BCP or Standard.  If it's just informational, these can be listed as work 
in progress.  Input from the chairs and/or ADs here would be useful.

Regards,
Bob

.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 23 Jun 2004 08:33:58 +0300 (EEST)

> in progress.  Input from the chairs and/or ADs here would be useful.

There are two "normative issues":

 1) a standards track document cannot refer normatively to an
informational/experimental document, or document with a lower maturity
than itself.  [this is not an issue here]

 2) no RFC will be published until all of its normative references (no
matter the category) have been published.  It can be approved, but
will then wait at the RFC editor queue.  Informative references are
listed as work in progress.  The justification here is that the
normative reference might change substantially before approval, and
the circumstances of the referral might be entirely different.

If reading draft-jeong-dnsop-ipv6-dns-discovery-01.txt and
draft-ohta-preconfigured-dns-01.txt is critical for understanding this
document (it might be!), they might in any case warrant being over at
normative references.  They can be moved to informative later as well
(even as far as the RFC editor) if it seems they won't move forward.

.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 23 Jun 2004 07:31:41 -0400

Pekka - your point 2 leads us to a circular dependency: the documents in
question won't be chartered for development in a WG until after
draft-ietf-dnsop-ipv6-dns-configuration is reviewed by the IESG.  But
draft-ietf-dnsop-ipv6-dns-configuration can't include
draft-jeong-dnsop-ipv6-dns-discovery-01.txt and
draft-ohta-preconfigured-dns-01.txt as normative references if
draft-ietf-dnsop-ipv6-dns-configuration is published as an RFC.

On the one hand, it's likely not necessary for
draft-ietf-dnsop-ipv6-dns-configuration to be published as an RFC to fulfill
its purpose as a source of information to the IESG.  On the other hand, I
think it's mandatory to publish draft-ietf-dnsop-ipv6-dns-configuration as
an RFC at some point to help us avoid retracing our steps over this ground
in the future.

At the risk of going way down a rat-hole, I suppose
draft-jeong-dnsop-ipv6-dns-discovery-01.txt and
draft-ohta-preconfigured-dns-01.txt could be published in their current
states as Informational, for the sole purpose of providing an archive of the
ideas in the two drafts to be referenced in
draft-ietf-dnsop-ipv6-dns-configuration.

Can you point us at the relevant RFC that defines the requirements for
normative references?  I don't remember and couldn't find the relevant RFC
with a quick search.  Thanks...

- Ralph

.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 23 Jun 2004 08:33:56 -0400

Jinmei-san - I have replied in line about selected comments (mostly about 
DHCPv6).

- Ralph

>draft-rfc-editor-rfc2223bis-07.txt

All eight people contributed text and reviewed the entire document.
Perhaps the author list should be reorganized as one editor,
with all eight people listed in a "Contributors" section.

>the same logic again, I still believe this document should clarify the

Interesting point. In my mind, there is some room for interpretation
of the interfaces on a router acting as "host" or "router" interfaces.
I think there was some discussion about the differentiation between
interface function as "advertising" or "non-advertising"?
In the PD case, the use case is a CPE router, with one interface connected
to the ISP network that acts as a "host" interface and one or more
interfaces to the customer network acting as "router" interfaces.  In this
use case, it seems reasonable to allow DHCPv6 on the CPE interface to the
ISP.

>I believe this document should explicitly note this limitation.

Suggested change:

    DHCPv6 currently provides a mechanism for reconfiguring DHCPv6
    clients that use stateful configuration assignment.

The following paragraph in the document describes the current work
on reconfiguring hosts using stateless DHCPv6.

>This statement is quite vague for me.  Please be more specific on

How about:

    5) Hosts that require other configuration information such as the
    addresses of SIP servers and NTP servers are likely to need DHCPv6
    for other configuration information.

>one, can live with or without the event names).

Sure; suggested replacement text:

    7) Interoperability among independent implementations has been
    demonstrated.

>whether we need to reflect that in the first place).

In particular, the new text in rfc2462bis does not preclude the use
of stateless DHCPv6 when the O flag is not set.  Thus, a host that
requires the address of an RDNSS might well try stateless (or even
stateful) DHCPv6 if it doesn't receive an RA with an RDNSS option.

OK.

>role of the phrase "DNS information" in this sentence.

Re-reading this sentence for intent, I think it should be qualified
to the case in which all of the CPEs use the same RDNSS.  In the
case where different customers use different RDNSSes - for example,
in the MSO/ISP - simple broadcast of an RDNSS option in an RDNSS
won't be sufficient.

Also, it might be good to be more specific in the case where the
CPE is a customer router "gateway", as the expectation would be
that the CPE accepts the RDNSS information from the RA on the
interface connected to the ISP, and copies that information into
the RAs broadcast in the customer network.

.

---

From: Tim Chown <[email-masked]>
Date: Wed, 23 Jun 2004 18:13:51 +0100

> I believe this document should explicitly note this limitation.

I think this is the rationale for Stig's lifetime draft for other
configured options using Stateless DHCPv6...  this was to cater for 
planned renumbering of DNS, NTP or other servers:

http://www.ietf.org/internet-drafts/draft-ietf-dhc-lifetime-00.txt

tim
.

---

From: Tim Chown <[email-masked]>
Date: Wed, 23 Jun 2004 18:26:37 +0100

> on reconfiguring hosts using stateless DHCPv6.

That looks good.  (as do all the comments/replies)

Tim
.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 23 Jun 2004 15:54:21 -0400

Thanks for the pointers to the referencing requirements docs.

If the IESG decision is "no further work on RDNSS configuration will be
chartered", the two drafts won't be progressed and published.  Not a huge
issue; I'd just like us to consider the potential benefits of archiving this
process...

- Ralph

At 10:39 PM 6/23/2004 +0300, Pekka Savola wrote:
>On Wed, 23 Jun 2004, Ralph Droms wrote:
> > its purpose as a source of information to the IESG.
>
>Indeed, it is not necessary to publish it for this purpose.  The IESG
>can and often does approve documents which have normative references
>as still I-Ds, or documents which have slightly similar circular
>dependencies.  Then the all the documents will just wait in the
>RFC-editor pool until all the required circular dependencies have
>entered the pool.

>Unfortunately, I don't think much of this is definitely documented.
>draft-ymbk-downref-02.txt gives the guidelines for issue (1). For
>issue (1), there's some information in
>draft-rfc-editor-rfc2223bis-07.txt.
>
>--

.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 23 Jun 2004 22:39:24 +0300 (EEST)

.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 24 Jun 2004 12:37:16 +0900

>>>>> On Tue, 22 Jun 2004 20:40:41 +0300 (EEST), 
>>>>> Pekka Savola <[email-masked]> said:

>> router on every link where this information needs to be configured
>> by this mechanism.
>> 
>> If there is a hidden assumption that the router can be
>> autoconfigured with the RDNSS addresses by DHCPv6, see comment 5
>> above.  Also, if we take this approach, one of the advantages of
>> the RA option may plummet: address renumbering case, since DHCPv6
>> may not be able to update the address quickly.

> servers configured is a very feasible scenario.  All the routers I
> can quickly think of have a configured DNS server.

I simply wanted to point out that configuration overhead at each
router can be disadvantage of the RA option approach, but it seems

> configured on such boxes when they support v6?  This is probably a

And, regardless of my original intention, I agree this is a good
question to consider.  Not sure if this particular draft should
address this point though.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 24 Jun 2004 13:07:31 +0900

>>>>> On Tue, 22 Jun 2004 13:35:29 -0700, 

>>> purpose, or even gave up on specifying one "default" approach?  If
>>> so, then I guess implementors will need to implement all the

> implementors will need to implement all approaches is neither
> specified nor mandated by this draft). The draft does not adopt any
> approach. Rather, it documents the different proposals. The IESG
> will use this information to determine how to move forward. The WGLC
> is being used to determine if the analysis of the attributes of the
> different approaches can be agreed upon (not which one should be
> adopted). Does this help?

Yes, thanks.  Then I'd like the document to be more specific on this
point, including:

- add a note in Introduction like this:

    This document is just an analysis of each possible approach, and
    does not make any recommendation on particular one or on a
    combination of particular ones.  Some approaches may even not
    adopted at all as a result of further discussion.

- revise sections 3.1.3 and 3.2.3, concentrating on the main
  approach discussed in each section, rather than comparing the main
  approach to other(s).  In fact, in the current draft section 3.1.3
  (slightly) sounds that the RA option is the preferable approach in
  most cases but the DHCPv6 approach *may* have some applicability.
  On the other hand, section 3.2.3 sounds that the DHCPv6 approach is
  the generic one but the RA option can be preferable in some "special
  applications".  (See also my original comment 11).

  I admit, however, this is perhaps just from my personal, biased
  impression.  So, I won't push it if I'm the only person who wants
  this change.

- revise section 4 to clarify the consideration of the combination is
  just an attempt to show a possible strategy *if we take all the
  three approaches*.  Perhaps we need a note like this:

     Three approaches can work together for IPv6 host configuration of
     DNS server.  This section shows a consideration on how these
     approaches can interwork each other.  Note, however, that this
     does not necessarily mean this document suggests adopting all the
     three approaches and make them interwork in the way described
     here.  In fact, some approaches may even not adopted at all as a
     result of further discussion.

					JINMEI, Tatuya
    
.

---

From: Soohong Daniel Park <[email-masked]>
Date: Thu, 24 Jun 2004 14:00:30 +0900

Hi Jinmei.

>     adopted at all as a result of further discussion.

It sounds good for me except the last sentence of your description.
I think the first sentence is almost enough.

>      result of further discussion.

same as above.

Regards.

.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 24 Jun 2004 15:33:38 +0900

>>>>> On Thu, 24 Jun 2004 14:00:30 +0900, 
>>>>> Soohong Daniel Park <[email-masked]> said:

>> - add a note in Introduction like this: This document is just an
>> analysis of each possible approach, and does not make any
>> recommendation on particular one or on a combination of particular
>> ones.  Some approaches may even not adopted at all as a result of
>> further discussion.

>> - revise section 4 to clarify the consideration of the combination
>> is just an attempt to show a possible strategy *if we take all the
>> approaches can interwork each other.  Note, however, that this does
>> not necessarily mean this document suggests adopting all the three
>> approaches and make them interwork in the way described here.  In
>> fact, some approaches may even not adopted at all as a result of
>> further discussion.

> same as above.

I personally believe the latter parts are rather important to not
misguide the readers.  At least I don't see why we cannot keep the
small two sentences.

But I won't necessarily push including these parts, if the authors
really want to remove the additional sentence.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 24 Jun 2004 17:53:08 +0900

>>>>> On Wed, 23 Jun 2004 04:19:59 +0900, 
>>>>> Masataka Ohta <[email-masked]> said:

>> notion from the one defined in the IPv6 addressing architecture
>> (e.g., RFC3513).  For example, reference [9] of this draft requires
>> using the anycast address as a source address for TCP responses
>> while the address architecture prohibits this usage.

> administratively prohibited to have anycast servers sharing an
> anycast address in a single link. Then, most of instabilities
> disappear.

My first point is that readers would be confused about the meaning of
"anycast" (since the address architecture officially defines a
slightly different notion).  I'll be happy as long as the draft
explicitly notes these two are different.

>> I don't understand the role of this paragraph in the context of
>> this section or of the entire document...perhaps additional
>> background might help or we can simply remove this paragraph?

> unless you manually configure a lot. :-)

Understood, but it's very hard, at least for me, to imply the
intention from this paragraph; it even doesn't contain "ND" or "DHCP"
at all.

> With the current security consideration section, the paragraph can
> be removed.

Okay, then I'd suggest to remove this paragraph (mainly for
readability).  I can also live with it in Section 3.3 if it provides
more context and explains the intention.

>> 16. Section 5.2.1 (Multi-level Network Topology)

(snip)

>> For redundancy and load sharing, well-known anycast addresses can
>> be used by IPv6 hosts through RDNSS RA option.
>> 

>    Large ISPs may operate multiple recursive resolvers at each
> anycast address to distribute and reduce load

Yes, but I didn't talk about the "reducing load" part, but about
redundancy.  My point here is as follows.

Section 3.3 says

   DNS clients have redundancy by having multiple resolvers that there
   should be multiple well-known anycast addresses configured on 
   clients. There is no point to have multiple servers sharing an 
   anycast address on a single link. 

(BTW: I couldn't really parse the first sentence as I said in my
first message)

I interpreted this to mean anycast addresses are not for redundancy
(i.e., it seems to me this paragraph insists redundancy should be
provided by using multiple addresses, not through the characteristics
of anycasting).

But then section 5.2.1 says

  For redundancy and load sharing, well-known anycast addresses can
  ^^^^^^^^^^^^^^
  be used by IPv6 hosts through RDNSS RA option.

which seems to me inconsistent with what Section 3.3 said about
redundancy.

>> Can't we have these as normative references unless these are
>> published as a stable document (presumably an RFC) before the
>> publication of this document or at least synchronously?  Or is that
>> actually the plan?

> ID can refer anything.

Sure, if we were not in a wg last call, I'd never make this kind of
comment.  But we are actually in a last call, and, in my
understanding, the goal (or at least one of the goals) of the document
is to publish this as an informational RFC.  For example, one
co-author clearly said so in the following message:

http://darkwing.uoregon.edu/~llynch/dnsop/msg02886.html

Section 5 of the draft also says:

   The main objective of this work is to provide a useful 
   guideline as Informational RFC. 

As you said in a separate message, if this draft won't become an RFC,
then I don't care about these things.  Even if it will, we could
postpone the decision just before the publication.  However, I'd try
to resolve these issues at this timing, since completing this work
seems urgent and it would be better to kill boring process-wise
showstoppers as early as possible.

Anyway, I personally do not mind with delaying the decision as long as
the authors understand the implication and if they still want to do so.

					JINMEI, Tatuya

---

From: Jaehoon Jeong <[email-masked]>
Date: Thu, 24 Jun 2004 07:25:37 -0700 (PDT)

First of all, thanks for your productive comments and
suggestions.

Generally, I agree on your comments.

--- JINMEI Tatuya wrote:
> 
> I personally believe the latter parts are rather
> important to not misguide the readers.
> At least I don't see why we cannot keep the
> small two sentences.

It is absolutely important to provide an exact
guideline for the audience including IESG. This is the
main objective of this document.

> really want to remove the additional sentence.

I would like to include your suggestions in this
document. I've already reflected your comments and
others' on this document.

Before WGLC ends and a new version of this document is
submitted to IETF, I'll let the revised draft,
including suggested opinions and agreements, be shown
at our mailing list.

Thanks.

Paul

__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
.
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: Fri, 25 Jun 2004 18:32:35 +0900

>>>>> On Tue, 22 Jun 2004 16:36:10 -0700, 
>>>>> Bob Hinden <[email-masked]> said:

> proponents for each approach thought their advantages and disadvantages were.

Okay, please see also my separate comment to Dave then.

> this and not try to be very specific about which one is best.

I'm personally fine with this approach.

> not need to change.  Does that help?

Yes, please then consider the fairness comment of mine.

> Well the extension seems simple enough to me :-)

As I said, you can safely think so, but it's hard to prove that (but I
won't too much insist on the appropriateness of the word "simple" if
the analysis in the next revision is fair enough).

> their own use, but I agree it should be stated.

Okay.

> me.  Much of the other information advertised by ND would also have to be 

I was talking about renumbering DNS servers addresses, not renumbering
routers or the whole (or most) part of the network.  So I believe my
comment still stands.

> renumbering is a very useful evaluation criteria.

I'm afraid we're talking about different things.  See my comment above.

> solution.  Maybe we need to say something about this in the introduction.

Okay.  I can live with this as long as the introduction (or in some
appropriate part of the document) clarifies "the nature of the document".

> in progress.  Input from the chairs and/or ADs here would be useful.

I guess we've already fully discussed this point in this thread
(though I myself did not actively participated in it).

In any event, I personally do not have a particular opinion on the
dependency issue.  I just wanted to point out a possible pitfall.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 25 Jun 2004 18:58:08 +0900

>>>>> On Wed, 23 Jun 2004 08:33:56 -0400, 
>>>>> Ralph Droms <[email-masked]> said:

> with all eight people listed in a "Contributors" section.

(As I said in the response to Bob about the reference dependency) I
personally do not have a particular opinion on this, and I just
pointed out a possible issue upon official publication.  It's up to
the authors whether this should be addresses in the first place and
how to solve it if necessary.

> use case, it seems reasonable to allow DHCPv6 on the CPE interface to the

It's probably reasonable for the PD case, but the description in this
section seems to talk about more generic cases.  I'd personally rather
make this part less specific as Bob suggested (to my first comments).

>     clients that use stateful configuration assignment.

Works for me.  Just checking: is the following a part of the suggested
change, or just a note for this thread?  (I'm assuming the latter)

>     for other configuration information.

Looks good.

>     7) Interoperability among independent implementations has been

Okay.  (As I said in my original comment, I don't care actually)

> stateful) DHCPv6 if it doesn't receive an RA with an RDNSS option.

...even if the RA does not have the O flag being set, right?  So you
might say:

   For ordering between RA and DHCP approaches, O (Other stateful
   configuration) flag in RA message can be used [5].  If no RDNSS
   option is included, an IPv6 Host may perform DNS configuration
   through DHCPv6 [6]-[8] regardless of whether the O flag is set or
   not.

> the RAs broadcast in the customer network.

Do you mean the original intention is to provide the RDNSS address in
an RA from PE router to CPE router?  If so, I could not understand the
intention from the original text.  More seriously, this approach will
lead to an open issue on how a router configures itself by receiving
RAs from another router (RFC2461 or 2462 were not clear on this.  And
we've decided to make this still open at least in rfc2462bis).  Of
course, we could discuss such an advanced topic here, but I guess it's
too early to explore such radical path in this context.

					JINMEI, Tatuya

---

From: Ralph Droms <[email-masked]>
Date: Fri, 25 Jun 2004 07:21:20 -0400

Replying to selected comments in line...

- Ralph

At 06:58 PM 6/25/2004 +0900, JINMEI Tatuya / 
>make this part less specific as Bob suggested (to my first comments).

Agreed - no particular reason to mention DHCPv6 here...

>    through DHCPv6 [6]-[8] regardless of whether the O flag is set or

That text is fine with me.

>too early to explore such radical path in this context.

The original intent of the text was not clear to me, either.  I may have
read more into the text by mentioning the use of the RA option for
configuration of CPE routers.  But, if all this paragraph describes is the
use of the RA option for hosts directly connected to the ISP network, I
don't understand why that case is specifically called out in this scenario.

.