Some quick clarifications: >>>>> On Mon, 16 Aug 2004 18:43:04 +0100, >>>>> "Elwyn Davies" <[EMAIL PROTECTED]> said:
>> > The confusion around stateful, 3315 and 3736 has been >> discussed at length >> > elsewhere. >> >> Sorry, I don't understand the point. Could you be more specific on >> what you want? I guess you meant the following message: http://www1.ietf.org/mail-archive/web/ipv6/current/msg03314.html but I'm still not 100% sure about the point. I hate to make a wild guess and continue the discussion based on the assumption, but if you mean it is confusing to tie the M/O flags with the notion of "stateful" protocols while RFC3736 calls itself "stateless", I tried to clarify this point in rfc2462bis: 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. Note that this is a compromise with the real world standardization status. Perhaps you are not 100% comfortable with the compromise (I'm not, actually), we needed to face that RFC3736 was already standardized and people do not want to change the phrase "stateful" in rfc2461bis/rfc2462bis. I could not think of better compromise... >> > s.5.5.3: Should the logic on updating address lifetimes in >> item (e) be >> > applied to addresses configured by stateful and/or other >> means? Equivalent >> > DOS attacks could come from (bogus)server initiated DHCP updates as >> > described in the Security considerations of RFC3315 . >> >> We've intentionally eliminated the case of addresses configured by >> DHCPv6 for several reasons: >> >> - we basically concentrate on stateless address configuration, and the >> detailed description of the stateful case is left to other >> documents. >> - the description of Section 5.5.3 cannot easily apply to DHCPv6, >> since Section 5.5.3 depends on the notion of the "prefix length" of >> an address while DHCPv6 does not convey the information. >> >> One more point. I'm not sure what you meant by "as described in the >> Security considerations of RFC3315", but DHCPv6 has its own security >> mechanism, and, in my understanding, the "official" position to DHCPv6 >> spoofing attacks is "use DHCPv6 authentication". > You are quite right - the DHCPv6 Reconfigure messages are required to be > authenticated which reduces the risk here. Incidentally, I was not > suggesting that all of 5.5.3 was applicable to DHCP-acquired addresses, only > that it might be sensible to apply the Valid Lifetime constraints to other > addresses than those constructed by stateless autoconfig. So I interpret this to mean this is a non issue in rfc2462bis. 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 --------------------------------------------------------------------
