Re: [dhcwg] unresolved comments in dhcpv6-25

["Raymond Jayaraj" <[e-mail]>]

Hi guys,

> Changed definition of binding to:
>
>   binding   A binding (or, client binding) is a group of server data
>             records containing the information the server has about
>             the addresses in an IA or configuration information
>             assigned to the client.  A binding containing
>             information about an IA is indexed by the tuple <DUID,
>             IA-type, IAID> (where IA-type is the type of address in
>             the IA; for example, temporary).  A binding containing
>             configuration information for a client is indexed by
>             <DUID>.

Sorry to barge in like this; but we're also hot on the heels of
implementing (and verifying) DHC6, and would like to confirm if:

By the change in the definition as above, a node can use stateless
(RA) address(es) yet maintain (RENEW/REBIND applies) stateful,
address-unrelated, context/configuration (e.g. roaming, security,
qos, billing, mobility etc.) information with the network via DHC6?

We've been trying to figure out other ways to accomplish this, but
always end up with sub-optimal methods.

It would be neat if DHC6 can be extended to this end; then there
won't be need to define additional edge access / "network session"
protocols - just more DHC6 options (IMHO).


Raymond Jayaraj
Institute For Communications Research
Agency For Science, Technology & Research
Singapore.


----- Original Message -----
From: "Ralph Droms" <[e-mail]>
To: <JINMEI Tatuya / $B?@L@C#:H (B <[e-mail]>)>
Cc: <[e-mail]>
Sent: Wednesday, June 05, 2002 12:02 PM
Subject: Re: [dhcwg] unresolved comments in dhcpv6-25


> Thanks for your careful review and helpful comments.  We've
> reviewed your comments and included our responses in line
> below.  www.dhcp.org/draft-26.txt reflects the changes
> described in this response.
>
> - Ralph
>
> =====
>    Message 1:
>    ----------
>    Other questions to this section:
>      - what should the receiving server do if the Information-request
>        contains a client Identifier option?  I think the server MUST
>        copy the option to the reply, but the draft does not mention this
>        case.
>      - what should the receiving server do if the Information-request
>        contains an IA option?  Section 18.1.5 says that:
>          The client MUST NOT include any IA options.
>        But none of this section and Section 15.12 mention this case.
>
> We've fixed these specific problems.
>
>    BTW: there seem to me several cases for this type of incompleteness.
>    For example, Section 22.6 says "The IA Address option must be
>    encapsulated in the Options field of an Identity Association option."
>    But I'm not sure what a node should do when it receives an IA address
>    option not encapsulated in an IA option.  I've not gone through the
>    entire draft, so I may miss something, and if so, I'd apologize in
>    advance.  If my guess is correct, however, then I'd suggest to check
>    the consistency of the requirements over the entire draft.
>
> The "UnSpecFail" status code is available to indicate a problem with
> the DHCP option where the action for that problem is not specifically
> described in the doc.
>
>    Message 2:
>    ----------
>    1. Section 4.1. defines
>
>          binding                   A binding (or, client binding) is a
>                                    group of server data records containing
>                                    the information the server has about
>                                    the addresses in an IA and any other
>                                    configuration information assigned to
>                                    the client.  A binding is indexed by
>                                    the tuple <DUID, IA-type, IAID> (where
>                                    IA-type is the type of address in the
>                                    IA; for example, temporary)
>
>    Is it always appropriate to contain "IA-TYPE" and "IAID" in the index
>    of a binding?  What if a configuration information (that needs a
>    binding) is not associated with an IA?  An IPv6 prefix delegated by
>    DHCPv6 can be an example of such binding.
>
> Changed definition of binding to:
>
>   binding   A binding (or, client binding) is a group of server data
>             records containing the information the server has about
>             the addresses in an IA or configuration information
>             assigned to the client.  A binding containing
>             information about an IA is indexed by the tuple <DUID,
>             IA-type, IAID> (where IA-type is the type of address in
>             the IA; for example, temporary).  A binding containing
>             configuration information for a client is indexed by
>             <DUID>.
>
>    2. Section 15.13. says
>
>       Clients MUST discard any received Relay-forward messages.
>
>    What if a relay agent receives a relay-forward message?
>
> We have added new text that addresses "chaining" of relay agents; that
> is, the ability of one relay agent to send a relay-forward message to
> another relay agent.
>
>    4. Section 17.1. says
>
>       A client uses the Solicit message to discover DHCP servers
configured
>       to serve addresses on the link to which the client is attached.
>
>    The wording is too specific.  Since the client may just need other
>    information than addresses, the text should be like "DHCP servers
>    configured to server addresses or other configuration
>    parameters...".
>
> Right; fixed...
>
>    5. Section 17.1.1. says
>
>       The client MAY include
>       options with data values as hints to the server about parameter
>       values the client would like to have returned.
>
>    I'm not sure how the data values are specified.  An option request
>    option can only specify required option "types"...
>
>    The same comments applies to Sections 18.1.1 and 18.1.5.
>
> The client includes the requested option (rather than indicating the
> option in the Option Request option), containing the desired option
> value.
>
>    6. Section 17.1.3 says
>
>       The client MUST ignore any Advertise message that includes a Status
>       Code option containing the value AddrUnavail, with the exception
that
>       the client MAY display the associated status message to the user.
>
>    and Section 17.2.2 has a corresponding text:
>
>       If the server will not assign any addresses to IAs in a subsequent
>       Request from the client, the server MUST send an Advertise message
to
>       the client that includes only a status code option with the status
>       code set to AddrUnavail and a status message for the user.
>
>    With the specification, it seems to me that a client cannot configure
>    itself without getting addresses (except via information-request and
>    reply exchanges).  For example, suppose that a client wants to be
>    delegated an IPv6 prefix from a provider, and sends a solicit without
>    any IA option.  The server is configured to delegate prefixes only
>    (i.e. not addresses), so it sends an Advertise message with an
>    AddrUnavail code.  Since the client MUST ignore the advertise message,
>    it cannot proceed any more.
>
>    So, the specification should be clearer on the procedure when a client
>    does not need addresses.
>
> Text in 17.2.2 clarified to specify that server returns AddrUnavail
> only if the client included IA options in the Solicit message.
>
>    7. What if a reply message for a solicit with a rapid commit option
>       does *not* contain a rapid commit option?  Section 17.2.3 says that
>       the server includes a Rapid Commit option in the Reply message, but
>       Section 17.1.4 says nothing about the case if the rapid commit
>       option is not included.
>
> Added a sentence requiring a client to discard any Reply messages that
> do not include a Rapid Commit option.
>
>    8. It is not very clear when a server includes a Server Unicast
>       option.  Section 18.1.1 (and some succeeding sections) says
>
>          Use of multicast or anycast on a link and relay agents
>          enables the inclusion of relay agent options in all messages
>          sent by the client.  The server should enable the use of
>          unicast only when relay agent options will not be used.
>
>      But, this only talks about some restrictions of including the
>      option.  Even with the text of section 22.13, I'm still not sure
>      when a server should or can send a Server Unicast option.  It
>      would be better to describe the allowed (or necessary) cases
>      explicitly.
>
> Added the sentence: "Use of unicast may avoid delays due to forwarding
> of messages by relay agents as well as avoid overhead and duplicate
> responses by servers due to delivery of client messages to multiple
> servers." to each of the DISCUSSION paragraphs explaining the use of
> the Unicast option.
>
>    9. (I've once pointed it out, but I'll do it again) Section 17.2.2
>       says
>
>       If the Solicit message was received directly by the
>       server,...The Advertise message MUST be unicast through the
>       interface on which the Solicit message was received.
>
>      Technically, the requirement is too strong, since links are larger
>      than interfaces according to the IPv6 scoped address architecture.
>      So, more accurately, it should say "The Advertise message MUST be
>      unicast through the link on which the Solicit message was received."
>      (Also see the last paragraph of Section 16.)
>
> We used the more specific requirement to avoid the problem of a client
> sending a DHCP message on an incorrect interface because the client
> had incorrect configuration information about two interfaces being on
> the same link.
>
>    10. Section 18.2.1 says
>
>       When the server receives a Request message via unicast from a
>       client to which the server has not sent a unicast option, the server
>       discards the Request message and responds with a Reply message
>       containing a status code option with value UseMulticast and no other
>       options.
>
>    I'm not sure how the client should act when it receives the reply
>    message.  Should it resend the request to multicast?  Should it
>    restart the entire procedure from the solicit?  At least Section
>    18.1.6 should mention this case.
>
>    The same comment applies to Sections 18.2.3, 18.2.6, and 18.2.7.
>
> Fixed with the following text:
>
>     When the client receives a Reply message with a Status Code
>     UseMulticast option, the client records the receipt of the
>     message and sends subsequent messages through that interface using
>     multicast. The client resends the original message using multicast.
>
>    11. Section 18.2.6 says "The server ignores invalid addresses."  What
>        does "invalid" exactly mean?  In particular, I'm not sure if the
>        source address of the receipt message is "invalid" or not (note
>        that section 18.1.7 prohibits the client to use addresses being
>        released as the source address).  The text should clearly define
>        the term "invalid".
>
>    The same comment applies to Section 18.2.7.
>
> The phrase "invalid addresses" has been clarified.
>
>    12. Section 19.1.1 says "The server sets the transaction-id field to
>        0".  But I could not found description about the case where the
>        client receives a reconfigure message with a non-0 transaction-id.
>        Should it discard the message, or should it ignore the non-0
>        value, or others?
>
> Added sentence specifying that the client ignores the transaction-id
> field in received Reconfigure messages.
>
>    13. Why doesn't the timeout and retransmission rule in Section 19.1.2
>        follow the general rules described in Section 14?  Is there
>        something special for reconfigure messages?
>
> The randomization is not required as Reconfigure messages won't be
> synchronized by some external event.
>
>    Message 3:
>    ----------
>    (1) If the client sent a solicit message with a rapid commit option
>        but the server responds to the solicitation with an advertise
>        message, what should the client do?  Should it ignore the
>        advertise, should it accept the advertise and send a request, or
>        others?  Section 17.1.4 says
>
>         ...If the client does not
>         receive a Reply message, the client restarts the server
solicitation
>         process by sending a Solicit message that does not include a Rapid
>         Commit option.
>
>       So, the client should probably ignore the advertise (and keep
>       waiting for a reply.)  But I'm not 100% sure about this.
>
> Section 17.1.4 is clarified to allow a client to use an Advertise
> message in this case if it receives no Reply with a Rapid Commit
> option.
>
>    (2) Section 17.1.2 says:
>
>       If the client is waiting for an Advertise message, the mechanism in
>       section 14 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 IRT has elapsed.  Rather, the client
>       collects Advertise messages until IRT has elapsed.
>
>    Should this rule apply if the client is retransmitting solicit
>    messages?  For example, suppose that there is no advertise in response
>    to the first solicit, and so the client retransmit the solicit.  If
>    the client then receives a first advertise, should it still wait until
>    IRT elapses?
>
> A couple of paragraphs farther down in 17.1.2 is this text:
>
>     If the client does not receive any Advertise messages before
>     the first RT has elapsed, it begins the retransmission mechanism
>     described in section 14.  The client terminates the retransmission
>     process as soon as it receives any Advertise message, and the client
>     acts on the received Advertise message without waiting for any
>     additional Advertise messages.
>
> This text is intended to address the question you raise.
>
>    (3) The paragraph above then says:
>       Also, the first
>       RT MUST be selected to be strictly greater than IRT by choosing RAND
>       to be strictly greater than 0.
>
>    However, according to Section 13, the first RT should be
>
>          RT = 2*IRT + RAND*IRT
>
>    where RAND is a random number chosen with a uniform distribution
>    between -0.1 and +0.1.  Thus,
>
>          RT >= 2*IRT - 0.1*IRT = 1.9 * IRT >= IRT
>          (the rightmost '=' is satisfied only when IRT is 0)
>
>    So the RT should always be greater than IRT regardless of the value of
>    RAND, and "by choosing RAND to be strictly greater than 0" seems to be
>    redundant.  Is my understanding correct?
>
> The initial choice of RT included a typo; it should (and now does)
> read:
>
>     RT = IRT + RAND*IRT
>
>    Message 4:
>    ----------
>    Section 18.2.1 of dhcpv6-24 says:
>
>        When the server receives a Request message via unicast from a
>        client to which the server has not sent a unicast option, the
server
>        discards the Request message and responds with a Reply message
>        containing a status code option with value UseMulticast and no
other
>        options.
>
>     On the other hand, section 15.10 says
>
>         -  the message does not include a Server Identifier option
>     (snip)
>         -  the message does not include a Client Identifier option and the
>            original message from the client contained a Client Identifier
>            option
>
>     Those two requirements seem to be inconsistent, or at least be
>     confusing.  Should the reply message contain the Server Identifier
>     option (and the Client Identifier option if the original message
>     contained it) in the Reply even if the server is responding with a
>     status code option with UseMulticast?  Or should the client loosen the
>     validation in 15.10 if the reply contains a status code option?  Or
>     others?
>
> Clarified to allow additional options; paragraph now reads:
>
>     When the server receives a Request message via unicast from a
>     client to which the server has not sent a unicast option, the server
>     discards the Request message and responds with a Reply message
>     containing a Status Code option with value UseMulticast, a Server
>     Identifier option containing the server's DUID, the Client Identifier
>     option from the client message and no other options.
>
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/dhcwg
>




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