RE: [dhcwg] Rev of DHCPv6 spec

["Bernie Volz (EUD)" <[e-mail]>]

Ralph:

Some other changes you might think about making (I'm still in the process of reviewing the draft):

1. Section 10 (DUIDs). I think it is important to state that the server should treat the entire DUID as an opaque value and use it only in comparing DUIDs with each other - the server should not take apart the DUID or restrict the DUID types to the values specified as future documents may define new types.

2. The example in 10.3 is broken. There are only 7 octets before "example.com", not the required 8.

3. In section 20.2, I thought we were going to drop the "DUID len" field from the option as it wasn't required (DUID len is option-len - 2 (for the DUID type)).

4. In section 7.5, some of the timings are a bit short. I haven't investigated this in detail yet, but when one considers the speed of dial-up links and round trip times, I'm just a bit concerned that 250 msecs is a bit short.

5. In 9.2, you might want to indicate that the link-prefix and client-return-address fields are copied from the Relay-forward.

6. Section 15.1.1 (Use of XID Field) should probably be moved to apply globally not just to "Client Behavior" unter "DHCP Server Solicitation"?

7. In Section 15.1.3, the destination port number is not specified.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[e-mail]]
Sent: Monday, October 15, 2001 1:37 PM
To: Thirumalesh Bhat
Cc: [e-mail]
Subject: RE: [dhcwg] Rev of DHCPv6 spec


Thanks for your review and feedback.  I haven't sent in the -20 rev to the 
IETF for publication, so I can still make some changes based on your 
comments.  I'll respond to your comments in line...

- Ralph

At 09:33 AM 10/15/2001 -0700, Thirumalesh Bhat wrote:
>Some comments on the latest draft below:
>
>a) Section 10.1 - DUIDs
>         Do we have an upper limit on the DUID length? I thought we had a
>prior thread regarding DUIDs where it was agreed that the upper limit on
>DUID length will help the server implementation.

Yes - I think we put an upper limit of 256 bytes on a DUID.  I'll add that
restriction to the spec.

>b) Section 15.1.2 Creation of Solicit messages:
>    Can the client send a solicit message without an IA. An example would
>be for a client to check the servers that can provide the options it
>needs.

Yes - I'll make sure that it's clear that a client can send a Solicit
without IAs.

>c) Section 15.1.3 Transmission of Solicit Messages:
>The draft says "The client sends the Solicit message to the
>All_Dhcp_Agents" multicast address". How would this work if the DHCP
>Server is on the same segment as the client? Probably the DHCP server
>should bind to "ALL_Dhcp_Agents" as well as "All_DHCP_Servers" address.

Turns out the naming of the of these multicast addresses is potentially
confusing; both servers and relay agents are members of the
All_DHCP_Agents multicast group:

       All_DHCP_Agents address:  FF02::1:2 This link-scoped multicast
                  address is used by clients to communicate with the
                  on-link agent(s) when they do not know the link-local
                  address(es) for those agents.  All agents (servers and
                  relays) are members of this multicast group.


>d) Section 15.1.4: Receipt of Advertise Messages:
>Is there a recommendation on how long a client should wait to collect
>response from all the responding servers or is this implementation
>specific?

The intention is that SOL_TIMEOUT defines the time during which the
client collects responses.  If that's not clear, we'll need to fix
the text:

    The client transmits the message according to section 13, using the
    following parameters:

       IRT   SOL_TIMEOUT

       MRT   SOL_MAX_RT

       MRC   0

       MRD   0

    The mechanism in section 13 is modified as follows for use in the
    transmission of Solicit messages.  The message exchange is not
    terminated by the receipt of an Advertise before SOL_TIMEOUT has
    elapsed.  Rather, the client collects Advertise messages until
    SOL_TIMEOUT has elapsed.  The first RT MUST be selected to be
    strictly greater than SOL_TIMEOUT by choosing RAND to be strictly
    greater than 0.

    A client MUST collect Advertise messages for SOL_TIMEOUT seconds,
    unless it receives an Advertise message with a preference value
    of 255.  The preference value is carried in the Preference option
    (section  20.5).  Any Solicit that does not include a Preference
    option is considered to have a preference value of 0.  If the client
    receives an Advertise message with a preference value of 255, then
    the client MAY act immediately on that Advertise message without
    waiting for any more additional Advertise messages.

>e) Section 15.2.2 - Creation and transmission of Advertise messages:
>third paragraph:
>What happens if the client doesn't send an IA - does the server ignore
>the packet?

I guess the answer to this question is related to the answer to your
question (b).  If a client is allowed to send a Solicit with no IAs,
the text in 15.2.2 must be clarified to allow a server to respond with
an Advertise with no IAs.  The server can't generate IAs for the client;
all it can do is fill in IAs supplied by the client.

>f) Section 16.1.5
>When a client receives AddrUnavail status should it create a new IA? I
>would think that the client should create a new IA if it receives
>NoPrefixMatch status back.

The client doesn't have to create a new IA; it just has to find a different
server that will agree to put addresses in the IA.

>Not sure the reason for the use of "ConfNoMatch" status - I think the
>other error codes can pretty much tell the client what to do. Same goes
>for the error codes "RenwNoMatch", "RebdNoMatch".

The "*NoMatch" status codes are the analog of DHCPNAK in DHCPv4;
a mechanism through which the server can tell the client that
the client needs to recontact the server for new configuration
information.

>g) Section 16.2.2 Receipt of confirm messages:
>
>"If the server cannot determine if the info in the confirm message is
>valid or invalid, the server MUST NOT send a reply to the client".
>
>This statement is a bit confusing. A server might be able to figure out
>that the client request is not valid as far as it is confirmed but it
>cant verify if it is invalid to other servers.
>
>May be the server should send its error message anyway and the client
>should wait for a certain period of time ( as it does for advertise
>messages ) to check if there is a server that can serve its needs.

The spec presumes that the servers are all configured consistently,
so the presumption is the client won't get some ACK and some NAK
responses.  The text you quote allows for the fact that a server
may get a Confirm in which the addresses are appropriate for the
link from which the message was received, but the server doesn't
have a binding for the client to confirm that the addresses in
the IA have been specifically assigned to the client.

>h) Section 17.1.1 - Creation and transmission of reconfigure-init
>messages.
>
>Has the possibility of sending reconfigure-init to a relay been removed
>so that the relay can unicast to the clients that it is aware of?

There is no mechanism through which a relay agent can forward a
reconfigure-init to multiple clients.

>i) Section 20.1 - Format of DHCP Options.
>We should be explicit in saying that the option code and option length
>are in network byte order.

OK.

>j) I feel that we should also add "Vendor class" and "User class"
>options to the draft. I can prepare the text for these two options if
>desired.

OK, I'll accept your offer to write up text for "Vendor class" and
"User class".  Thanks!



_______________________________________________
dhcwg mailing list
[e-mail]
http://www1.ietf.org/mailman/listinfo/dhcwg