RE: [dhcwg] Rev of DHCPv6 spec

[Ralph Droms <[e-mail]>]

OK - thanks, Bernie.  I'll make these changes, as well.

- Ralph

On Mon, 15 Oct 2001, Bernie Volz (EUD) wrote:

> 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
>


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