All,
Thanks for the feedback on this subject so far.
I think we are now approaching a consensus, so here is a summary of
resolution.
- keep the M/O flags
- clearly specify the protocols for the flags: RFC3315 for M and
RFC3736 for O
- clarify (change) the meaning of the M/O flags; they are just hints
of availability of the corresponding services, not triggers for
invoking the protocols under a certain level of requirement
- remove or reword "requirements" regarding these flags according to
the above change
- remove ManagedFlag and OtherConfigFlag, which were
implementation-internal variables in RFC2462 tightly depending on
the "requirement" nature of the M/O flags
- clarify the possible confusion coming from the fact that RFC3736
calls itself "stateless" while rfc2462bis uses "stateful"
- leave the actual usage of the M/O flags will be used to a separate
document. rfc2462bis mentions the other document
The followings are the specific changes I'd propose. These are just a
draft of draft, but would be very close to the final text (unless I
get serious comments). I'm referring to rfc2462bis-00 as the "old"
text, but it should not be so different from RFC2462 on this matter.
1. revise abstract as follows:
[...] The autoconfiguration
process includes creating a link-local address and verifying its
uniqueness on a link, determining what information should be
autoconfigured (addresses, other information, or both), and in the
case of addresses, whether they should be obtained through the
stateless mechanism, the stateful mechanism, or both. [...]
[...] The
details of autoconfiguration using the stateful protocol are
specified elsewhere.
To:
[...] 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. [...]
[...] The
details of autoconfiguration using the stateful protocol is
specified in RFC3315 and RFC3736.
2. same change as the previous one to the first paragraph of Section
1.
3. Revise the third paragraph of Section 1 to:
In the stateful autoconfiguration model, hosts obtain interface
addresses and/or configuration information and parameters from a
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.
4. add the following paragraph between the third and fourths
paragraphs of Section 1:
To obtain other configuration information without configuring
addresses in the stateful autoconfiguration model, a subset of
DHCPv6 will be used [RFC3736]. While the model is called
"stateful" 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.
5. revise the last sentence of the (current) fourth paragraph of
Section 1:
[...] The site administrator specifies which type of
autoconfiguration to use through the setting of appropriate fields in
Router Advertisement messages [5].
To:
[...] The site administrator specifies which type of
autoconfiguration is available through the setting of appropriate
fields in Router Advertisement messages [5].
6. revise the last bullet of the list in Section 3:
o System administrators need the ability to specify whether
stateless autoconfiguration, stateful autoconfiguration, or both
should be used. Router Advertisements include flags specifying
which mechanisms a host should use.
To:
o System administrators need the ability to specify whether
stateless autoconfiguration, stateful autoconfiguration, or both
is available. Router Advertisements include flags specifying
which mechanisms a host can use.
7. revise the fifth paragraph of Section 4 (page 9) as follows:
The next phase of autoconfiguration involves obtaining a Router
Advertisement or determining that no routers are present. If routers
are present, they will send Router Advertisements that specify what
sort of autoconfiguration a host should do. If no routers are
present, stateful autoconfiguration should be invoked.
To:
The next phase of autoconfiguration involves obtaining a Router
Advertisement or determining that no routers are present. If routers
are present, they will send Router Advertisements that specify what
sort of autoconfiguration a host can do. When no routers are
present, stateful autoconfiguration may be available.
8. revise the sixth paragraph of Section 4 as follows:
[...] Router Advertisements contain
two flags indicating what type of stateful autoconfiguration (if any)
should be performed. A "managed address configuration" flag indicates
whether hosts should use stateful autoconfiguration to obtain
addresses. An "other stateful configuration" flag indicates whether
hosts should use stateful autoconfiguration to obtain additional
information (excluding addresses).
To:
[...] Router Advertisements contain
two flags indicating what type of stateful autoconfiguration (if any)
is available. 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).
9. add the following to the end of the previous part:
The details of how a host may use the M flags, 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 flags, 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.
10. remove the definitions of ManagedFlag and OtherConfigFlag from
Section 5.2 (page 12). We'll also need to adjust the wording
around the definition.
11. revise Section 5.5.2 as follows:
Even if a link has no routers, stateful autoconfiguration to obtain
addresses and other configuration information may still be
available, and hosts may want to use the mechanism. From the
perspective of autoconfiguration, a link has no routers if no
Router Advertisements are received after having sent a small number
of Router Solicitations as described in RFC 2461 [5].
12. remove the first and second paragraphs of Section 5.5.3
("requirements" parts of the M/O flags).
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
