Subject: Re: [dhcwg] unresolved comments in dhcpv6-25

From: "Raymond Jayaraj" <[email-masked]>
Date: Wed, 5 Jun 2002 15:38:50 +0800

(This is a resend, in plain text, of an earlier HTML email)

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" <[email-masked]>
To: <JINMEI Tatuya / $B?@L@C#:H (B <[email-masked]>)>
Cc: <[email-masked]>
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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 10 Jun 2002 14:31:33 +0900

>>>>> On Wed, 5 Jun 2002 15:38:50 +0800, 
>>>>> "Raymond Jayaraj" <[email-masked]> said:

> qos, billing, mobility etc.) information with the network via DHC6?

In my understanding, yes, but the specification of dhcpv6 originally
intended to allow such coexistence.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: "Raymond Jayaraj" <[email-masked]>
Date: Wed, 12 Jun 2002 10:11:33 +0800

Hi. Thx for the response!

----- Original Message -----
From: <JINMEI Tatuya / $B?@L@C#:H (B
<[email-masked]>)>
To: "Raymond Jayaraj" <[email-masked]>
Cc: "Ralph Droms" <[email-masked]>; <[email-masked]>
Sent: Monday, June 10, 2002 1:31 PM
Subject: Re: [dhcwg] unresolved comments in dhcpv6-25