Subject: [dhcwg] comments on draft-ietf-dhc-dhcpv6-agentopt-delegate-00.txt

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 27 Jun 2006 17:08:08 +0900

Dear authors,

I have some comments on draft-ietf-dhc-dhcpv6-agentopt-delegate-00.txt.
These are basically minor, but (I think) not just editorial, so I'm
copying the list.

- 1.  Introduction

>   For example, a network administrator uses the DHCP Relay Agent
>   Assignment Notification option to inform a relay agent of a prefix
>   that has been delegated through DHCP PD to a DHCP client.

The term "DHCP PD" is used earlier the point where this term is
defined (Section 2).  Similarly, it's odd to see a reference to
RFC3633 ([3]) first appears in Section 2.

This document generally seems to use "requesting router" as a DHCP
client in the context of PD.  If so, the policy should be consistent.

>   The relay
>   agent notifies the network element on which the it is implemented of

  s/the it/it/

- 3.  Option semantics

>   The DHCP server MAY include this option in a Reply message sent to a
>   client that includes assigned addresses and/or prefixes.

I understand what this sentence intends to say, but I don't think it's
very accurate, because this option is actually located *outside* of
the Reply message.  The following sentence indeed clarifies the point:

>   If the DHCP
>   server does include this option in a Reply message, it MUST include
>   it in the option area of the Relay-reply message sent to the relay
>   agent intended as the recipient of the option.

So, I'd say, for example:

"The DHCP server MAY include this option along with a Reply message
[...]"
or
"The DHCP server MAY include this option in the same packet that
contains a Reply message [...]"
(although the latter is probably tedious).

>   A relay agent that receives this option SHOULD pass the information
>   to the node in which the relay agent is instantiated.

This sentence sounds strange to me, because in some contexts "a relay
agent" itself can be interpreted as a "node" (am I clear enough?).  I
guess the sentence is basically equivalent to this one in Section 1:

   The relay
   agent notifies the network element on which the it is implemented of
   the delegation information [...]

which sounds more reasonable.  So, (at least to me) it would be better
to avoid the confusing word "node" in this type of context.  It would
also be better to clarify what "relay agent" precisely means in
Section 2.

- 5.1.  IA Address option

>   valid-lifetime The expiration lifetime of the information carried in
>      this IA Address option, expressed in units of seconds; the
>      expiration-lifetime is a relative time, giving the duration
>      relative to the current time of the information in this IA Address
>      option; if the valid-lifetime is 0, the information is no longer
>      valid.

Does 0xffffffff mean infinity as in RFC3315?  The same question
applies to the IA Prefix option (Section 5.2).

- 8.  Security considerations

I believe a forged Relay Agent Assignment Notification Option can also
be used traffic hijack, which may be more serious than a DoS (although
it's probably not so feasible, depending on the network topology).  So
it would be better for this section to give some considerations on
this attack.

>   through the use of IPSec, as described in section 21.1 of RFC 3315.

In my understanding, the common notation for IP security is "IPsec"
("s" is a lower case letter).

					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