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

From: Changming Liu <[email-masked]>
Date: Tue, 2 Mar 2004 14:25:15 -0800

The major concern I have with this draft is the relay assumption and RA
applicability. In the case there is no relay, this still sould work. Please
see my previous emails for such a scenario.

Can RA be used between routers? Can DHCPv6 used between two routers, say one
PE and one CPE?

Changming Liu

-----Original Message-----
From: JINMEI Tatuya / ????
To: [email-masked]
Cc: [email-masked]
Sent: 3/1/2004 8:40 AM
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-masked]

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg