Hi Jinmei,
I finished my AD review of draft-ietf-ipv6-rfc2462bis-06.txt. I have several comments on this document that I believe should be resolved before this document is sent to IETF Last Call for publication as a Draft Standard.
All of my comments are included below, but my most serious concerns are:
(1) Having decided that "the stateful configuration" mechanism is DHCPv6, I don't think that there is a reason to maintain the awkward and confusing wording about "the stateful mechanism" in many places. I've pointed out the worst cases, but there are many others. I know that this is largely an editorial concern, but the awkwardness and lack of clarity are bad enough in some places (see below) that I consider this a blocking problem for publication at DS.
(2) I am not comfortable with the idea that we would punt the interpretation of the M & O bits to a "separate document" with no reference. I believe that information about how to interpret these bits is essential to implementing IPv6 address autoconfiguration. See below for the specific text that concerns me.
I'd be interested in your feedback on these issues, as well as on the other more minor issues I've noted below.
I've cc:ed the IPv6 WG on this message, and other IPv6 folks should also feel free to respond, especially if you think that I'm mistaken about something.
Margaret
---
My comments are in-line, marked with ">>"
Abstract
This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information can be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they can be obtained through the stateless mechanism, the stateful mechanism, or both.
whether they can be obtained through stateless autoconfiguration, the Dynamic Host Configuration Protocol (DHCP) or both?
This document defines the process for generating a link-local address, the process for generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure. The details of autoconfiguration using the stateful protocol are specified in RFC 3315; an alternative way of using the stateful protocol to deliver 'other information' only is specified in RFC 3736.
I'd move the whole last sentence to an introduction and take it out of the abstract. Since we can't have references in an abstract, I think it is useless, anyway.
1. INTRODUCTION
This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6 (IPv6). The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information can be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they can be obtained through the stateless mechanism, the stateful mechanism, or both.
s/the stateful mechanism/DHCP
This document defines the process for generating a link-local address, the process for generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure. The details of autoconfiguration using the stateful protocol is specified in [RFC3315] and [RFC3736].
s/the stateful protocol/DHCP
IPv6 defines both a stateful and stateless address autoconfiguration mechanism. Stateless autoconfiguration requires no manual configuration of hosts, minimal (if any) configuration of routers, and no additional servers. The stateless mechanism allows a host to generate its own addresses using a combination of locally available information and information advertised by routers. Routers advertise prefixes that identify the subnet(s) associated with a link, while hosts generate an "interface identifier" that uniquely identifies an interface on a subnet. An address is formed by combining the two. In the absence of routers, a host can only generate link-local addresses. However, link-local addresses are sufficient for allowing communication among nodes attached to the same link.
In the stateful autoconfiguration model, hosts obtain interface addresses and/or configuration information and parameters from a Dynamic Host Configuration Protocol (DHCPv6) server. Servers maintain a database that keeps track of which addresses have been assigned to which hosts. The stateful autoconfiguration protocol allows hosts to obtain addresses, other configuration information or both from a server. Stateless and stateful autoconfiguration complement each other. For example, a host can use stateless autoconfiguration to configure its own addresses, but use stateful autoconfiguration to obtain other information.
To obtain other configuration information without configuring addresses in the stateful autoconfiguration model, a subset of DHCPv6 [RFC3736] will be used. While the model is called "stateful" here in order to highlight the contrast to the stateless protocol defined in this document, the intended protocol is also defined to work in a stateless fashion. This is based on a result, through operational experiments, that all known "other" configuration information can be managed by a stateless server, that is, a server that does not maintain state of each client that the server provides with the configuration information.
This is the part that I consider to be quite awkward, particularly the vague references to operational experiments that aren't documented or referenced here. If you switch to just referring to DHCP, the preceeding three paragraphs can be substantially simplified. I also thin it is unnecessary to say so much about how DHCP works -- that is the subject of other document. There are many other places where the text would be much clearer if DHCP (or DHCPv6) were used instead of "the stateful mechanism", but I will not mark them all.
The stateless approach is used when a site is not particularly concerned with the exact addresses hosts use, so long as they are unique and properly routable. The stateful approach is used when a site requires tighter control over exact address assignments. Both stateful and stateless address autoconfiguration may be used simultaneously. The site administrator specifies which type of autoconfiguration is available through the setting of appropriate fields in Router Advertisement messages [I-D.ietf-ipv6-2461bis].
Given this normative reference, would it make sense to hold 2462bis until 2461bis is completed and send them forward together? Otherwise, this will just block in the RFC Editor, and we won't have the ability to change it again if we discover issue while finishing the 2461 update. Thoughts?
2. TERMINOLOGY
Is this terminology section intended to be in logical order? Is there a reason to prefer this order over an alphabetical listing?
Nodes (both hosts and routers) begin the autoconfiguration process by generating a link-local address for the interface. A link-local address is formed by appending the interface's identifier to the well-known link-local prefix.
I think that there should be a reference to the addressing architecture or the scoped address architecture here... Something that tells me how I actually create a link-local address.
A "managed address configuration (M)" flag indicates whether hosts can use stateful autoconfiguration [RFC3315] to obtain addresses. An "other stateful configuration (O)" flag indicates whether hosts can use stateful autoconfiguration [RFC3736] to obtain additional information (excluding addresses).
The details of how a host may use the M flag, including any use of the "on" and "off" transitions for this flag, to control the use of the stateful protocol for address assignment will be described in a separate document. Similarly, the details of how a host may use the O flag, including any use of the "on" and "off" transitions for this flag, to control the use of the stateful protocol for getting other configuration information will be described in a separate document. However a host uses the M and O flags, and local configuration to control autoconfiguration, the default setting will result in received Router Advertisements being processed for stateless address autoconfiguration.
I don't think it is okay to publish a DS that leaves important implementation details to a "separate document". Has the separate document been published? If so, it needs to be normatively referenced here.
Router Advertisements also contain zero or more Prefix Information options that contain information used by stateless address autoconfiguration to generate global addresses. It should be noted that the stateless and stateful address autoconfiguration fields in Router Advertisements are processed independently of one another, and a host may use both stateful and stateless address autoconfiguration simultaneously. One Prefix Information option field, the "autonomous address-configuration flag", indicates whether or not the option even applies to stateless autoconfiguration. If it does, additional option fields contain a subnet prefix together with lifetime values indicating how long addresses created from the prefix remain preferred and valid.
What happens if the value of the "autonomous address-configuration flag" changes over time?
For safety, all addresses must be tested for uniqueness prior to their assignment to an interface. The test should individually be performed on all addresses obtained manually, via stateless address autoconfiguration, or via stateful address autoconfiguration. To accommodate sites that believe the overhead of performing Duplicate Address Detection outweighs its benefits, the use of Duplicate Address Detection can be disabled through the administrative setting of a per-interface configuration flag.
I am not sure how the last sentence is consistent with the must in the first sentence. Change the must in the first sentence to a should?
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
