Subject: [dhcwg] Comments on draft-joshi-dhc-dhcpv6-aggr-route-opt-00

From: Tomasz Mrugalski <[email-masked]>
Date: Tue, 29 Mar 2011 00:56:57 +0200

I see that there is a new draft that's going to be discussed on Thursday
meeting. I have couple of comments and minor corrections to report.

"The aggregate route is a single route representing multiple prefixes
delegated by a DHCP server using Prefix Delegation, and maybe advertised"
=> "may be advertised"

"A DHCP message may contain multiple Aggregate Route options."
=> Why? That's probably ok, but authors should discuss "many prefixes in
single AGGR_ROUTE option vs each prefix in its own AGGR_ROUTE" approach.

Please clarify that both relays and clients may act as requestor.

"The Requestor MUST generate and include a transaction-id in the
information-request message.".
=> Unnecessary repetition from RFC3315.

"The Requestor with multiple interface MAY"
"interface" => "intefaces"

"list of known DHCP server"
=> "list of known DHCP servers"

"The requestor SHOULD unicast the information-
   request to one or more known DHCPv6 servers.".
Information-request is sent to multicast. The reason is simple. Client
does not know server's address. Here's how it works with regular
clients. Although I think this is not explicitly defined in RFC3315, the
general understanding is that unicast transmission to servers may be
done only when using REQUEST (follow up only, not the first one), RENEW,
RELEASE or DECLINE messages. My expectation is server will respond with
status code UseMulticast.

You should think this through. If this is left as it is now, this will
force changing server behavior. We would like to avoid this, if possible.

"In case no such list is configured the requestor MAY send multicast
request to All_DHCP_Servers address." By using All_DHCP_Servers instead
of regular All_DHCP_Relay_Agents_And_Servers ("normal" inf-requests are
sent to that address) you implicitly forbid using relays. This limits
scalability as you require that OPTION_AGGRR route be sent by reqestors
that are on the same link as servers.

"Upon receipt of a valid Reply message for each prefix in the
OPTION_AGGR_ROUTE the Requestor MAY based on its local configuration
add an aggregate route entry into its routing table."
=> SHOULD, not MAY. Why is requestor asking for aggregated route if it
does not intend to use it?

"The Server SHALL copy into the REPLY message...". Maybe it would be
better to use MUST, instead of SHALL. While defined in 2119, it is not
commonly used. However, it you like the way it is now, it is perfecly
RFC2119 compliant, so nobody can object.

"7. Security considerations"
- You may add reference to Section 15 of RFC3633 here.

Hope you find those comments useful.

Tomek

---

From: "JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)" <[email-masked]>
Date: Wed, 30 Mar 2011 12:02:11 +0530

Tomek,

Thanks for your review and comments, I will address incorporate and address them in the next version of draft as well as in this Thursday's discussion.

--
Shree

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tomasz Mrugalski
Sent: Tuesday, March 29, 2011 4:27 AM
To: [email-masked]
Subject: [dhcwg] Comments on draft-joshi-dhc-dhcpv6-aggr-route-opt-00

Tomek

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