Hi, I'd like to provide some comments for draft-dec-dhcpv6-route-option-03. I've followed presentation of this draft in Hiroshima with great pleasure. It is really good to see that work on this draft proceeds.
> Section 1 (page 3) To avoid confusion, replace DHCP with DHCPv6. This applies to many places through out the text. Please use full name before abbreviating FTTH and IGP. The same applies to ULA. Also, note that ULA usage is depreciated. See RFC 3879. It would improve document structure if you add subsection 2.1 "Problem examples" before presenting examples. > Section 2 (page 4, example 1) > disseminates this information via the shared link also to Client2 > which an operator often wants to avoid There is nothing wrong with proposed approach, but you may want to stress out that availability (or lack of thereof) of routing information should not used as an access control method. > Furthermore it's is "it is" or "it's". > is also desired to be able to manage per user route information > from a centralized repository instead of managing such information > directly on the NAS routers. I'm not familiar with the NAS operation. Can you elaborate on how a router can manage route information? Do you mean that NAS route provide source routing capability (i.e. differentiate routes depending on source addresses?) I assume that one NAS router handles traffic from multiple users. If that is true, then you may also add a comment that maintaining per user routing information on a NAS router limits scalability and managing such information on RG level is more favorable. There is also much more generic case that you may consider to include. A very simple, separated (routerless) network with single DHCPv6 server and two or more clients. Each client receives global unicast address from the same shared pool. Even though the DHCPv6 configuration process completed successfully, clients can't ping each other. This effectively means that DHCPv6 function of assigning addresses is dysfunctional without router advertisements. client1--+ | +---server1 | client2--+ Your proposed solution elegantly solves this problem and that is the main reason why I strongly support this draft. A side note: I'm developing an open source DHCPv6 client, server and relay implementation since 2003. Aforementioned issue is the most frequently reported by many users. Unfortunately, that is a limitation of DHCPv6 protocol and not a software bug. It would be great if we could proceed with this draft and solve this problem. > 3. Solution (page 5) I would recommend renaming 3. Solution. to 3. Route DHCPv6 Option. Also replace DHCP with DHCPv6. > Furthermore, the solution can easily integrate > operationally alongside similar functionality that may already > used be for IPv4, namely DHCPv4[RFC3442] I recommend simpler wording: This solution can coexist with already defined similar solution for IPv4, namely DHCPv4 [RFC3442]. Minor nitpick - this reference is not created properly. I think it's just a text, rather than <xref> tag. > Section 3.1 (page 6) I have several comments regarding option format. You can't use single Next Hop Address for multiple prefixes. In a generic case, there may be a need to use different next hop addresses for different prefixes. Current option format does not allow that. You are proposing to solve this with using multiple options if next hops are different for each prefix. That would require combining options contents together. See my comments below. With current approach (variable prefix length), there is no easy way to validate option correctness. It would be easier to validate, if prefix field was always 128 bit long (as is the case in OPTION_IAPREFIX, defined in RFC 3633). Prefixes are usually associated with preferred and valid lifetimes (with infinite lifetimes being special case). It seems a good idea to also add those fields. You define prefix length as a value ranges from 0 to 128. I would recommend allowing 0 to 127 range. Defining /128 prefix is useless. And you also gain most significant bit for other purposes. You may consider extending the option to look like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_ROUTE | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 Next Hop Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | preferred-lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | valid-lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | prefix-length | IPv6 prefix | |-+-+-+-+-+-+-+-+ (16 octets) | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . +-+-+-+-+-+-+-+-+ You may also consider broadening scope of the problem you solve by also allowing configuration of on-link prefixes. This may be easily achieved by simply stating that if IPv6 Next Hop address field contains all zeroes, the prefix is available on-link. > Section 3.2 (page 6) > Separate options are to be used for routes not sharing the same > next-hop. There's general recommendation against such practice. Here's part of section 22 of RFC3315: Unless otherwise noted, each option may appear only in the options area of a DHCP message and may appear only once. If an option does appear multiple times, each instance is considered separate and the data areas of the options MUST NOT be concatenated or otherwise combined. It would be much better to allow multiple prefixes to be conveyed in a single option. To convey several routes in single option, it seems a good idea to repeate not only, prefix-legnth and prefix, but also next-hop field. > Section 4 (page 7) Replace DHCP with DHCPv6 in the title. > If more than one route option appears in the same DHCPv6 message, > the client MUST process the options in the same way as if the > information was received in a single route option. This violates RFC3315, section 22. See my comments above. > When processing the Route option a client MUST substitute a 0::0 IP > next hop address with the source IP address of the received DHCP > message. This is not a typical approach. Values provided in DHCP options are supposed to be used directly, without extra processing. Are there any other similar cases already defined? I'm not saying that this approach is wrong, just an unusual. Also, if you accept my previous comments about prefix begin in 0 to 127 range, you can use the most significant bit to designate if the next hop substiution should take place or not. There is no discussion regarding renew and rebind exchanges. Once client receives new prefixes in RENEW, should it discard all old prefixes? Keep them until their valid lifetime expires? > Section 5. DHCP Server Behavior. Replace DHCP with DHCPv6. > The server SHOULD support sending the option(s) as part of other > DHCP options where such a possibility exists, for example when > sending the route option(s) as part of an IA_NA or IA_PD option > set. I'm confused regarding placement of the route option. My understanding was that it was supposed to be placed in a message directly, not as a sub-option in IA_NA or IA_PD. This sentence may suggest option nesting. A different wording or a clarification would be nice. You may also rename the option to IPv6 Route option for clarification. Ok, that's it. I'm sorry for the large number of comments. But make no mistake, I'm not criticizing this draft, just want to improve it. This draft solves significant problem reported by many users. As a DHCPv6 implementation developer, I strongly support it and hope that this valuable work will be continued. Regards, Tomasz Mrugalski -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
