Jinmei,
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?
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.
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.
I agree. There are different points of view and it doesn't seem like there will be a consensus on any specific approach.
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.
I agree.
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.
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.
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.
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?
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.
Well the extension seems simple enough to me :-)
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.
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.
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.
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.
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.
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.
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.
This is one of the advantages of well known addresses.
.....
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.
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.
.....
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?
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
. dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
