Subject: draft-dec-dhcpv6-route-option-03 comments

From: Tomasz Mrugalski <[email-masked]>
Date: Tue, 16 Mar 2010 01:45:45 +0100

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