Okay, there seems to be some level of agreement on the fundamental
point(s), so I'm now coming back to the original comments.
I believe I've proposed resolutions to most of the comments in my
previous message (in a separate thread). I'll answer the other points
in this message.
>>>>> On Wed, 6 Oct 2004 09:05:53 -0400,
>>>>> Margaret Wasserman <[EMAIL PROTECTED]> said:
> 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?
I basically think we should publish 2461bis and 2462bis at the same
timing with consistent changes. So, it would make sense to hold one
of them until the other is done at some stage. I'm not really sure
which point is the best, though. Perhaps just before the IETF last
call (and the IESG evaluation)?
> 2. TERMINOLOGY
>>> Is this terminology section intended to be in logical order? Is
>>> there a reason to prefer this order over an alphabetical listing?
Hmm, I don't know...I just followed the same ordering convention as
RFC2462 (in fact, I don't think I even added/removed terminologies, so
I believe the ordering is exactly the same). I don't have a strong
opinion on this, but there at least seems to be some ordering
dependency. For example, in the following sequence,
router - a node that forwards IP packets not explicitly addressed to
itself.
host - any node that is not a router.
it should be natural to put "host" after "router" (rather than in an
alphabetical order).
So, unless you have a strong demand to reorder the terminologies, I'd
slightly prefer to keep the current ordering.
> 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.
Okay, then I'll add a reference to the addressing architecture RFC
(RFC3513) here. (I don't think the scope arch doc is an appropriate
reference in this context.)
> 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?
My understanding is that the change means nothing; if the "autonomous
address-configuration (A) flag" is not set, the corresponding prefix
simply isn't used for the address autoconfiguration protocol (creating
a new address or updating an existing one). I think this point is
pretty clear in Section 5.5.3, and I personally don't see the need for
describing the details in the "overview" section. What do you think?
> 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?
I agree this is a bit confusing. Since it's not a RFC2119 keyword
(i.e., not MUST), I believe this is just a wording issue. I'm fine
with chaing "must" to "should", but I'd say "all addresses must
basically be tested". Do you have any preference or other
suggestions?
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
p.s. again, I believe I've addressed the rest of the comments (in that
I've proposed resolutions), either directly or as a side effect, but
I've left those points below just in case I missed something.
> 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.
> 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.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [EMAIL PROTECTED]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
