Subject: [dhcwg] Review of draft-ietf-mif-dhcpv6-route-option

From: Sheng Jiang <[email-masked]>
Date: Fri, 12 Aug 2011 09:40:55 +0000

Hi, all,

As agreed in the IETF 81 meeting, I have reviewed draft-ietf-mif-dhcpv6-route-option and have below comments.

Since I am reviewing this draft on behalf of DHC wg. I only focus on whether this design fits DHCPv6 protocol and its regulations. I don't really review technology requirements or mechanism design of this draft.

Overall, it is right to use DHCPv6 protocol to carry this kind of configuration information, which need to be propagated from network to end-host.

The major issue I have for this draft is: why design an IA container if "client will never use more than one IA_RT" (stated in this draft) and it has only one sub-option - Next Hop option. For me, it seems more explicit and simple to directly define Next Hop Option and allow multiple Next Hop Option if needed.

Several minor comments: there is no term explanation for IA_RT. It is helpful to indicate IA_RT option is variable length in Figure 1 and its text. I-D.troan-multihoming-without-nat66 has been replaced by draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat.

Best regards,

Sheng

---

From: Ted Lemon <[email-masked]>
Date: Fri, 12 Aug 2011 16:32:34 +0000

On Aug 12, 2011, at 5:40 AM, Sheng Jiang wrote:
The major issue I have for this draft is: why design an IA container if "client will never use more than one IA_RT" (stated in this draft) and it has only one sub-option - Next Hop option. For me, it seems more explicit and simple to directly define Next Hop Option and allow multiple Next Hop Option if needed.

If it really is the case that there is only going to be one suboption, I think you are correct.