Subject: [dhcwg] Question for SOL_MAX_RT draft

From: Timothy Winters <[email-masked]>
Date: Fri, 17 Feb 2012 13:49:40 -0500

Hello,
		While implementing some testing around draft-droms-dhc-dhcpv6-solmaxrt-update-02 I've had a discussion with an implementation that viewed the draft differently then I did.  I'm including the statement from an implementation that we encountered when developing test cases.

	"RFC 3315, it allows a DHCPv6 client to try another server and our DHCPv6 client does it by initiating another DHCPv6 Solicitation with a new transcation ID. In terms, there may be an environment with several DHCPv6 servers.  If a client gets a NoAddrsAvail in DHCPv6 Advertisement, it can try another server immediately by initiating a new DHCPv6 Solicitation with a new Transaction ID.  I think SOL_MAX_RT counts only within the same session, in terms of the same Transaction ID. 

	In the other words, RFC leaves the flexibility for an environment with multiple DHCPv6 Servers and clients can send a new DHCPv6 Solicitation message with a new Transaction ID if there is no address available. Client doesn't need to assume there is only one DHCPv6 Server, and an DHCPv6 Advertisement with NoAddrsAvail doesn't necessarily mean that the client need to wait SOL_MAX_RT.  The Client can try another DHCPv6 server."

	I thought the spirit of the draft was to limit the the amount of DHCP Solicits.  If a DHCP client applies the SOL_MAX_RT to only one session, the Client will continuously transmit DHCP solicits looking for another DHCP Server.  Therefore the SOL_MAX_RT should applies to all session and is not limited to one.

	What other think about this?

Regards,
Tim

---

From: Andre Kostur <[email-masked]>
Date: Fri, 17 Feb 2012 11:01:00 -0800

I would argue it should be for all sessions.   The client isn't supposed to
assume that there is only one DHCP server, that's why the client is
supposed to be collecting Advertisements from (potentially) multiple DHCP
servers (RFC 3315, section 17.1.2: "...Rather, the client collects
Advertise messages until the first RT has elapsed.").  So why isn't it
examining the 4 Advertisements to find the one that doesn't claim
"NoAddrsAvail"?  Why would the client expect a different answer if it
immediately Solicited again?  You're going to hit all of the same servers
again (probably), and get nearly the same answers again.

On Fri, Feb 17, 2012 at 10:49, Timothy Winters <[email-masked]> wrote:

> Hello,
>                While implementing some testing around
> draft-droms-dhc-dhcpv6-solmaxrt-update-02 I've had a discussion with an
> implementation that viewed the draft differently then I did.  I'm including
> the statement from an implementation that we encountered when developing
> test cases.
>
>        "RFC 3315, it allows a DHCPv6 client to try another server and our
> DHCPv6 client does it by initiating another DHCPv6 Solicitation with a new
> transcation ID. In terms, there may be an environment with several DHCPv6
> servers.  If a client gets a NoAddrsAvail in DHCPv6 Advertisement, it can
> try another server immediately by initiating a new DHCPv6 Solicitation with
> a new Transaction ID.  I think SOL_MAX_RT counts only within the same
> session, in terms of the same Transaction ID.
>
>        In the other words, RFC leaves the flexibility for an environment
> with multiple DHCPv6 Servers and clients can send a new DHCPv6 Solicitation
> message with a new Transaction ID if there is no address available. Client
> doesn't need to assume there is only one DHCPv6 Server, and an DHCPv6
> Advertisement with NoAddrsAvail doesn't necessarily mean that the client
> need to wait SOL_MAX_RT.  The Client can try another DHCPv6 server."
>
>        I thought the spirit of the draft was to limit the the amount of
> DHCP Solicits.  If a DHCP client applies the SOL_MAX_RT to only one
> session, the Client will continuously transmit DHCP solicits looking for
> another DHCP Server.  Therefore the SOL_MAX_RT should applies to all
> session and is not limited to one.
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

-- 
 *Andre Kostur*
Senior Product Design Engineer
*P:* 604-678-2864
*E:* [email-masked]
*Toll-Free:* 1-800-877-1856

*F:* 604-678-2864
*VoIP:* sip:[email-masked]

 <http://www.incognito.com>

 <http://www.incognito.com/company/events>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 17 Feb 2012 17:00:03 -0600

Yes, this violates the intent of this change.

Perhaps the problem is that the draft needs to clearly indicate that (at
least) the following RFC 3315 behavior is changed, as the section
indicated in the draft is LATER (17.1.3):

17.1.2. Transmission of Solicit Messages

...

   A client MUST collect Advertise messages for the first RT seconds,

   unless it receives an Advertise message with a preference value of

   255. ... If the client receives an Advertise message that does not

   include a Preference option with a preference value of 255, the

   client continues to wait until the first RT elapses.  If the first RT

   elapses and the client has received an Advertise message, the client

   SHOULD continue with a client-initiated message exchange by sending a

   Request message.

...

   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.

The intent is NOT to terminate the retransmission process as soon as ANY
Advertise message is received, instead this needs to be modified to
indicate only if the Advertise can be used to Request (a NoAddrsAvail
Advertise is not a useful one to Request). Section 17.1.3 starts out
with saying "The client MUST ignore any Advertise ... the NoAddrsAvail".

So, I think the draft needs to be expanded as to what is in section 4.
Updates to RFC 3315?

BTW: The ordering of the original text might also have led to this
problem to begin with? If RFC 3315 simply had said earlier (in 17.1.2):

   The client MUST ignore any Advertise message that includes a Status

   Code option containing the value NoAddrsAvail, with the exception

   that the client MAY display the associated status message to the

   user.

(Of course the next text in the draft Section 4 is also needed to cause
the client to pick up the SOL_MAX_RT option.)

-          Bernie

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Andre Kostur
Sent: Friday, February 17, 2012 2:01 PM
To: Timothy Winters
Cc: [email-masked]
Subject: Re: [dhcwg] Question for SOL_MAX_RT draft

I would argue it should be for all sessions.   The client isn't supposed
to assume that there is only one DHCP server, that's why the client is
supposed to be collecting Advertisements from (potentially) multiple
DHCP servers (RFC 3315, section 17.1.2: "...Rather, the client collects
Advertise messages until the first RT has elapsed.").  So why isn't it
examining the 4 Advertisements to find the one that doesn't claim
"NoAddrsAvail"?  Why would the client expect a different answer if it
immediately Solicited again?  You're going to hit all of the same
servers again (probably), and get nearly the same answers again.

On Fri, Feb 17, 2012 at 10:49, Timothy Winters <[email-masked]>
wrote:

Hello,
               While implementing some testing around
draft-droms-dhc-dhcpv6-solmaxrt-update-02 I've had a discussion with an
implementation that viewed the draft differently then I did.  I'm
including the statement from an implementation that we encountered when
developing test cases.

       "RFC 3315, it allows a DHCPv6 client to try another server and
our DHCPv6 client does it by initiating another DHCPv6 Solicitation with
a new transcation ID. In terms, there may be an environment with several
DHCPv6 servers.  If a client gets a NoAddrsAvail in DHCPv6
Advertisement, it can try another server immediately by initiating a new
DHCPv6 Solicitation with a new Transaction ID.  I think SOL_MAX_RT
counts only within the same session, in terms of the same Transaction
ID.

       In the other words, RFC leaves the flexibility for an environment
with multiple DHCPv6 Servers and clients can send a new DHCPv6
Solicitation message with a new Transaction ID if there is no address
available. Client doesn't need to assume there is only one DHCPv6
Server, and an DHCPv6 Advertisement with NoAddrsAvail doesn't
necessarily mean that the client need to wait SOL_MAX_RT.  The Client
can try another DHCPv6 server."

Regards,
Tim

 

-- 

Andre Kostur 
Senior Product Design Engineer
P: 604-678-2864
E: [email-masked]
Toll-Free: 1-800-877-1856

F: 604-678-2864
VoIP: sip:[email-masked]

  <http://www.incognito.com/>