Regarding issue 277 of rfc2462bis (Semantics of M/O flags), I want to
make a consensus on one thing. (Note: in this particular thread,
please just forget the discussion about whether 2462bis should
explicitly say the stateful protocol is DHCPv6.)
Previously I proposed to revise section 5.5.2 as follows:
> If a link has no routers, a host MAY attempt to use stateful
> autoconfiguration to obtain addresses and other configuration
> information.
> ...
> An implementation MAY provide a way to enable the
> invocation of stateful autoconfiguration in this case, but the
> default SHOULD be disabled.
In current RFC2462, the text is "a host MUST attempt to use
stateful... An implementation MAY provide a way ... but the default
SHOULD be enabled". So, in my proposal, the requirement level was
totally reversed.
The reason I raised was as follows:
>>>>> On Fri, 27 Feb 2004 21:31:57 +0900,
>>>>> JINMEI Tatuya <[EMAIL PROTECTED]> said:
> To choose appropriate keywords, I'd like to be synchronized with the
> node requirements draft (draft-ietf-ipv6-node-requirements-08.txt).
> It says in Section 4.5.5 that:
> Stateful Address Autoconfiguration MAY be supported. DHCPv6 [RFC-
> 3315] is the standard stateful address configuration protocol; see
> section 5.3 for DHCPv6 support.
> Nodes which do not support Stateful Address Autoconfiguration may be
> unable to obtain any IPv6 addresses aside from link-local addresses
> when it receives a router advertisement with the 'M' flag (Managed
> address configuration) set and which contains no prefixes advertised
> for Stateless Address Autoconfiguration (see section 4.5.2).
> ...
> That is (in my understanding), implementing DHCPv6 is basically
> optional with warnings about the case of not implementing it. I know
> this was a controversial issue, but I believe the node-requirements
> draft made a reasonable decision in terms of practical and realistic
> deployment path while honoring future flexibility.
> Another reason for the change is because we can at least use
> link-local addresses within a single link without a router.
I've not seen many responses to this part, but some people, including
Ralph (Droms), agreed on this change in their responses.
However, Greg Daley pointed out in Seoul that this change might be
dangerous because there may still be a node that can forward packets
from hosts but is not sending RAs (I intentionally avoid using the
term "router" here, because in this context a "router" should be
sending RAs).
I've been thinking about this for a while, and my conclusion is that
we don't have to worry about the scenario and thus do not have to
reconsider the original proposal of mine (at least due to this
particular issue).
The reason is that the problematic scenario looks very unrealistic.
If we want to force stateful configuration, we can simply do that by
configuring a node as a "router" sending RAs with the M (and/or) O
flags being set. And, as far as I know, all existing commercial
"packet forwarders" (again, I intentionally avoid the term "router")
has the ability to send RAs, and I'm quite sure that future products
will.
The administrator might want to skip configuring RAs by relying on the
RFC2462 default, but it's very likely that this person will still have
to configure a DHCPv6 server and the "forwarders" for routing
protocols. Also, since there is no other defined way than the
stateless autoconfiguration to configure a default router for hosts
(note that DHCPv6 does not have an option for this, not as far as I
know), we'll have to configure the default route on each host
manually.
That said, I really do not see any sane reason for relying on the
default behavior.
Now I want to ask: am I still miss something, or can we agree on the
original proposal?
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
