[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

FW: [dhcwg] comments on draft-vijay-dhc-dhcpv6-mcast-reconf-00

Jinmei requested I send this to the IPv6 mailing list.

-----Original Message-----
From: Bernie Volz [mailto:volz@metrocast.net] 
Sent: Tuesday, March 02, 2004 6:06 PM
To: 'JINMEI Tatuya / 神-セ'B哉'; 'vijayak@india.hp.com'
Cc: 'dhcwg@ietf.org'
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: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Bernie
Sent: Tuesday, March 02, 2004 4:30 PM
To: 'JINMEI Tatuya / 神-セ'B哉'; vijayak@india.hp.com
Cc: dhcwg@ietf.org
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:


- Bernie

-----Original Message-----
From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of JINMEI
Tatuya / 神明達哉
Sent: Monday, March 01, 2004 11:40 AM
To: vijayak@india.hp.com
Cc: dhcwg@ietf.org
Subject: [dhcwg] comments on draft-vijay-dhc-dhcpv6-mcast-reconf-00

Probably too late for the wg meeting, but I have several comments on

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

- 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
=> 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

=> 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.

dhcwg mailing list

dhcwg mailing list

IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6