Jinmei requested I send this to the IPv6 mailing list. -----Original Message----- From: Bernie Volz [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 02, 2004 6:06 PM To: 'JINMEI Tatuya / �_-�'B��'; '[EMAIL PROTECTED]' Cc: '[EMAIL PROTECTED]' Subject: RE: [dhcwg] comments on draft-vijay-dhc-dhcpv6-mcast-reconf-00
Regarding Jinmei's msg01798: - I agree that DHCPv6 should be the stateful protocol (question c). - I don't agree that DHCPv6light should not be controlled by the 'O' flag in a RA (question d). Personally, I think it a good thing for hosts to be silent on any protocol unless explicitly configured to run it. So, avoiding periodic Information-Request messages on all IPv6 networks, especially simple networks, is IMHO a good thing. Also, from RFC 2462, we have: "In addition, when the value of the ManagedFlag is TRUE, the value of OtherConfigFlag is implicitely TRUE as well." This would seem to me to very closely tie the "M" (Managed) and "O" (Other) configuration protocols - if they are completely separate, why connect them at all? - Bernie -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bernie Volz Sent: Tuesday, March 02, 2004 4:30 PM To: 'JINMEI Tatuya / �_-�'B��'; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [dhcwg] comments on draft-vijay-dhc-dhcpv6-mcast-reconf-00 FYI - For those that don't want to spend the 5 to 10 minutes I did looking for Jinmei's email, I think he was referring to: http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01798.html - Bernie -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of JINMEI Tatuya / �_���B�� Sent: Monday, March 01, 2004 11:40 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [dhcwg] comments on draft-vijay-dhc-dhcpv6-mcast-reconf-00 Probably too late for the wg meeting, but I have several comments on draft-vijay-dhc-dhcpv6-mcast-reconf-00. General comments: As an initial impression, I support (the idea of) this document. However, I think some fundamental points need to be discussed. - the document (and the ipv6-icmp-refresh-otherconf draft) assumes that the "O" flag in RA is tightly related to DHCPv6Light. However, this is not clear in the ongoing rfc2462bis work. And, actually, I just proposed at the ipv6 ML that we should rather separate the O flag from DHCPv6Light (the reasons were explained there). - this draft tries to reuse the existing framework, but it seems to me that the attempt causes some inconsistencies. The previous bullet is one of them. The other one is pointed out below at comment item 3. - having considered above point and the current deployment status of DHCPv6 and DHCPv6Light, it might make much more sense to design the mechanism as an explicit extension, rather than to stick to the compatibility with the existing specification and implementation. Technical (non editorial) comments: 1. In Section 4, Even if the Relay doesn't reside in the default router of the link, it should be capable of sending RAs without advertising itself as a default router. => this might cause inconsistency on the content of RAs between that from "real" routers and that from the Relay, which will then cause warnings at routers (and probably at the Relay also) according to Section 6.2.7 of RFC2461. 2. In Section 7.1, - the peer-address doesn't match any of the IPv6 prefixes configured in any of the relay's interfaces and the Interface-id option is not sent. => should the "peer-address" actually be "link-address"? 3. In Section 7.1, The match is done based on longest prefix match. => this matching rule is not always trustworthy, since the relay may have multiple link prefixes with different prefix lengths, like P::/64 and P::/72. What if the server actually wants to specify the former (and it does not know the corresponding interface ID)? Editorial comments: 4. In Section 1, of the of the client, including the address by which the client can => s/of the of the/of the 5. In Section 4, ... administrative domain to have the security association with them for IPv6Sec. => I don't think "IPv6Sec" is not a very appropriate term. IPsec would simply be enough in this case. 6. In Section 5, If the nodes find the O flag in the RA changes form FALSE to TRUE, => s/form/from/ 7. In Section 6.1, peer-address: It should be filled with 0, as this message is not really destined to any client. => I think "filled with 0" can (or even should) simply be "the unspecified address". 8. In Section 6.2, The server continues this process until REC_MAX_RC unsuccessful attempts have been made, => this seems an incomplete sentence. s/,/./ ? 9. In Section 7.2, The relay MUST trigger the router to include the Redo Service Discovery Option in the RAs. => What's the "Redo Service Discovery Option"? Shouldn't this be the "Refresh Other Configuration Option"? 10. In Section 7.3, The Relay prepares an DHCP Reply message with transaction-id copied => s/an/a/ JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] _______________________________________________ dhcwg mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/dhcwg -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
