Subject: [dhcwg] Reply to Confirm in RFC3315

From: "Leaf Yeh" <[email-masked]>
Date: Mon, 26 May 2014 10:53:49 +0800

Got 2 questions on the text in Section 18.1.8-'Receipt of Reply Messages' of
RFC3315:

<quote>

When the client receives a NotOnLink status from the server in

   response to a Confirm message, the client performs DHCP server

   solicitation, as described in
<http://tools.ietf.org/html/rfc3315#section-17> section 17, and
client-initiated

   configuration as described in
<http://tools.ietf.org/html/rfc3315#section-18> section 18.  If the client
receives any

   Reply messages that do not indicate a NotOnLink status, the client

   can use the addresses in the IA and ignore any messages that indicate

   a NotOnLink status.

</quote>

1.       If the client receive an Reply message indicating 'NoBinding' (or
even ' NoAddrsAvail'), the above sounds the client can still use the address
in the IA. Why?

2.       Why does the client could ignore 'any message' indicating
'NotOnLink' (in the 2nd half of the above paragraph)? It sounds conflict
with the 1st half of the above paragraph, not?

Best Regards,

Leaf

---

From: Marcin Siodelski <[email-masked]>
Date: Mon, 26 May 2014 12:54:01 +0200

On 26/05/14 04:53, Leaf Yeh wrote:
> Got 2 questions on the text in Section 18.1.8-‘Receipt of Reply
> Messages’ of RFC3315:
> 
>  
> 
> <quote>
> 
>    solicitation, as described in section 17
> <http://tools.ietf.org/html/rfc3315#section-17>, and client-initiated
> 
>    configuration as described in section 18
> <http://tools.ietf.org/html/rfc3315#section-18>.  If the client receives any
> 
>    can usethe addresses in the IA andignore any messages that indicate
> 
>    a NotOnLink status.
> 
> </quote>
> 
>  
> 
> 1.       If the client receive an Reply message indicating ‘NoBinding’
> (or even ‘ NoAddrsAvail’), the above sounds the client can still use the
> address in the IA. Why?

I think the context of the paragraph is important. The client sends
Confirm to any available server and client may receive multiple Replies.
Typically, one of these Replies will not contain NotOnLink status (or
contain Success) to indicate that client can use the address. Other
servers will send NotOnLink because they are not configured for the
particular subnet or so. So, the purpose of this paragraph is just to
describe this scenario.

Of course, client may receive Replies with other status codes too, and
there are relevant sections that talk about client behavior in this
case". So a couple of lines down:

"
   The client examines the status code in each IA individually.  If the
   status code is NoAddrsAvail, the client has received no usable
   addresses in the IA and may choose to try obtaining addresses for the
   IA from another server.  The client uses addresses and other
   information from any IAs that do not contain a Status Code option
   with the NoAddrsAvail code.  If the client receives no addresses in
   any of the IAs, it may either try another server (perhaps restarting
   the DHCP server discovery process) or use the Information-request
   message to obtain other configuration information only.
"

So, I don't really think there is any conflict here.

Also, you indicate that the client could use the address even though
there is a NoAddrsAvail or NoBinding. But, the returned IA will not have
an address to be used, because server places just status code NoBinding
or NoAddrsAvail in the IA and nothing else.

> 
> 2.       Why does the client could ignore ‘any message’ indicating
> ‘NotOnLink’ (in the 2^nd half of the above paragraph)? It sounds
> conflict with the 1^st half of the above paragraph, not?
> 
>  

The way I read it is that when the client receives at least one Reply
that has no NotOnLink status code, it may use the address it desires to
use. Otherwise it performs solicitation.

Perhaps, it could be more precise and say something along the lines: if
none of the Reply messages received in response to a Confirm message
indicates success, the client performs solicitation. Otherwise, it may
use the address.

Marcin

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 26 May 2014 11:41:30 +0000

I think we're talking about Reply to Confirm. If so, why would these contain NoAddrsAvail/NoBinding? They don't. Confirm does not validate a particular client's addresses/PDs or bindings. It only validates whether the addresses/PDs are on link or not.

Other than global errors like UnspecFail, a Confirm will either contain NotOnLink or Success. Nothing else.

And, yes the idea was there could be multiple servers some of which may send NotOnLink (as they may be lacking the configuration) but others that send Success. The Success on can be taken.

In general servers that aren't authoritative for a particular set of links should not respond.

- Bernie

-----Original Message-----
From: Marcin Siodelski [mailto:[email-masked]] 
Sent: Monday, May 26, 2014 6:54 AM
To: Leaf Yeh; Bernie Volz (volz); 'Tomasz Mrugalski'
Cc: [email-masked]; 'dhcpv6bis'
Subject: Re: [Dhcpv6bis] Reply to Confirm in RFC3315

On 26/05/14 04:53, Leaf Yeh wrote:
> Got 2 questions on the text in Section 18.1.8-'Receipt of Reply 
> Messages' of RFC3315:
> 
>  
> 
> <quote>
> 
> 1.       If the client receive an Reply message indicating 'NoBinding'
> (or even ' NoAddrsAvail'), the above sounds the client can still use 
> the address in the IA. Why?

I think the context of the paragraph is important. The client sends Confirm to any available server and client may receive multiple Replies.
Typically, one of these Replies will not contain NotOnLink status (or contain Success) to indicate that client can use the address. Other servers will send NotOnLink because they are not configured for the particular subnet or so. So, the purpose of this paragraph is just to describe this scenario.

Of course, client may receive Replies with other status codes too, and there are relevant sections that talk about client behavior in this case". So a couple of lines down:

"

Also, you indicate that the client could use the address even though there is a NoAddrsAvail or NoBinding. But, the returned IA will not have an address to be used, because server places just status code NoBinding or NoAddrsAvail in the IA and nothing else.

> 'NotOnLink' (in the 2^nd half of the above paragraph)? It sounds 

The way I read it is that when the client receives at least one Reply that has no NotOnLink status code, it may use the address it desires to use. Otherwise it performs solicitation.

Perhaps, it could be more precise and say something along the lines: if none of the Reply messages received in response to a Confirm message indicates success, the client performs solicitation. Otherwise, it may use the address.

Marcin

---

From: Marcin Siodelski <[email-masked]>
Date: Mon, 26 May 2014 13:55:31 +0200

Yes, NoAddrsAvail/NoBinding are not sent in response to Confirm. May 
point rather was that *even in a more general case* the server will not 
send addresses in the IA in which there is NoAddrsAvail or NoBinding. 
This comment was beyond the context of Confirm/Reply message exchange.

Marcin

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 26 May 2014 12:07:09 +0000

The only two cases where NotOnLink status is used is in the response to Request and Confirm.

In Confirm case it is global level status.

In Request case it is within the IA and means that the client's requested addresses (or PD) is not on the link. No addresses/PD should be returned to client for that IA. The Request case is a bit weird in one respect as 18.1.8 says:

   When the client receives a NotOnLink status from the server in
   response to a Request, the client can either re-issue the Request
   without specifying any addresses or restart the DHCP server discovery
   process (see section 17).

This kind of implies that it is "global".

I think this case was to handle the client moving between Solicit and Request (but with the same server still responding since the Server DUID matches).

It is a good question as to whether we should make this status global rather than IA specific. In in the end there's probably not much harm in leaving it as is because if the client restarts the process, it will just get back the other addresses/PD that might have been assigned to other IA options that did not result in NotOnLink.

- Bernie

-----Original Message-----
From: Marcin Siodelski [mailto:[email-masked]] 
Sent: Monday, May 26, 2014 7:56 AM
To: Bernie Volz (volz)
Cc: [email-masked]; 'dhcpv6bis'; Leaf Yeh; 'Tomasz Mrugalski'
Subject: Re: [Dhcpv6bis] Reply to Confirm in RFC3315

Yes, NoAddrsAvail/NoBinding are not sent in response to Confirm. May point rather was that *even in a more general case* the server will not send addresses in the IA in which there is NoAddrsAvail or NoBinding. 
This comment was beyond the context of Confirm/Reply message exchange.

Marcin

---

From: Ted Lemon <[email-masked]>
Date: Mon, 26 May 2014 08:13:49 -0400

On May 25, 2014, at 10:53 PM, Leaf Yeh <[email-masked]> wrote:
> 1.       If the client receive an Reply message indicating ‘NoBinding’ (or even ‘ NoAddrsAvail’), the above sounds the client can still use the address in the IA. Why?
> 2.       Why does the client could ignore ‘any message’ indicating ‘NotOnLink’ (in the 2nd half of the above paragraph)? It sounds conflict with the 1st half of the above paragraph, not?

NoBinding and NoAddrsAvail are indications about the status of a single DHCP server, but there may be more than one DHCP server on the wire.   So if a server replies with such a message rather than a NotOnLink message, this means that that server believes the client is correctly configured, but isn't the server that configured it.   So if another server replies NotOnLink, there's a misconfiguration—DHCP servers should never disagree about that.   Ignoring the NotOnLink in this case may be incorrect, but accepting it may also be incorrect.   And since NotOnLink is a great way to do a DoS attack, it's better to ignore an erroneous NotOnLink than honor it.

I think this is explained somewhere in the document--if so, it might be good to say so explicitly here.   If not, more explanation wouldn't hurt.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 26 May 2014 08:17:14 -0400

On May 26, 2014, at 6:54 AM, Marcin Siodelski <[email-masked]> wrote:
> Other
> particular subnet or so.

That should never happen.   If the server is not configured with information about a link, it should not respond.   Does the document say it should?   If one server responds with NotOnLink and another with NoAddrsAvail, I think that's always a configuration error.

---

From: Marcin Siodelski <[email-masked]>
Date: Mon, 26 May 2014 14:29:26 +0200

> That should never happen.   If the server is not configured with information about a link, it should not respond.   Does the document say it should?   If one server responds with NotOnLink and anot…

You're right. In 18.2.2 it is said that it should not respond when it 
doesn't have a knowledge of the prefixes on the link to which the 
client is connected. So, it really sounds that when there are two 
responses (one with NotOnLink, another one with Success) it either 
means misconfiguration or a rogue server sending Replies.

Marcin

---

From: "Leaf Yeh" <[email-masked]>
Date: Tue, 27 May 2014 10:05:15 +0800

BV > Other than global errors like UnspecFail, a Confirm will either contain
NotOnLink or Success. Nothing else.

If the client receive a reply with global error 'UnspecFail' , can the
client still 'use the addresses in the IA' indicating in the Confirm?

Best Regards,
Leaf

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]] 
Sent: Monday, May 26, 2014 7:42 PM
To: Marcin Siodelski; Leaf Yeh; 'Tomasz Mrugalski'
Cc: [email-masked]; 'dhcpv6bis'
Subject: RE: [Dhcpv6bis] Reply to Confirm in RFC3315

I think we're talking about Reply to Confirm. If so, why would these contain
NoAddrsAvail/NoBinding? They don't. Confirm does not validate a particular
client's addresses/PDs or bindings. It only validates whether the
addresses/PDs are on link or not.

Other than global errors like UnspecFail, a Confirm will either contain
NotOnLink or Success. Nothing else.

And, yes the idea was there could be multiple servers some of which may send
NotOnLink (as they may be lacking the configuration) but others that send
Success. The Success on can be taken.

In general servers that aren't authoritative for a particular set of links
should not respond.

- Bernie

-----Original Message-----
From: Marcin Siodelski [mailto:[email-masked]] 
Sent: Monday, May 26, 2014 6:54 AM
To: Leaf Yeh; Bernie Volz (volz); 'Tomasz Mrugalski'
Cc: [email-masked]; 'dhcpv6bis'
Subject: Re: [Dhcpv6bis] Reply to Confirm in RFC3315

> the address in the IA. Why?

I think the context of the paragraph is important. The client sends Confirm
to any available server and client may receive multiple Replies.
Typically, one of these Replies will not contain NotOnLink status (or
contain Success) to indicate that client can use the address. Other servers
will send NotOnLink because they are not configured for the particular
subnet or so. So, the purpose of this paragraph is just to describe this
scenario.

Of course, client may receive Replies with other status codes too, and there
are relevant sections that talk about client behavior in this case". So a
couple of lines down:

"

Also, you indicate that the client could use the address even though there
is a NoAddrsAvail or NoBinding. But, the returned IA will not have an
address to be used, because server places just status code NoBinding or
NoAddrsAvail in the IA and nothing else.

> conflict with the 1^st half of the above paragraph, not?

The way I read it is that when the client receives at least one Reply that
has no NotOnLink status code, it may use the address it desires to use.
Otherwise it performs solicitation.

Perhaps, it could be more precise and say something along the lines: if none
of the Reply messages received in response to a Confirm message indicates
success, the client performs solicitation. Otherwise, it may use the
address.

Marcin

---

From: "Leaf Yeh" <[email-masked]>
Date: Tue, 27 May 2014 10:05:15 +0800

Marcin - ... The client sends Confirm to any available server and client may
receive multiple Replies.
Typically, one of these Replies will not contain NotOnLink status (or
contain Success) to indicate that client can use the address. Other servers
will send NotOnLink because they are not configured for the particular
subnet or so. So, the purpose of this paragraph is just to describe this
scenario.

Yes, Confirm is a multicast message. Thanks for your explanation. But the
text here in the RFC3315 sounds to 'ignore any messages that indicate a
NotOnLink status.', which is under question. If no Success received, then
client performs 'DHCP server solicitation, and client-initiated
configuration'. That sounds not ignore 'any message.'

Marcin -Also, you indicate that the client could use the address even though
there is a NoAddrsAvail or NoBinding. But, the returned IA will not have an
address to be used, because server places just status code NoBinding or
NoAddrsAvail in the IA and nothing else.

I am not quite sure this Reply to Confirm will return IAs. But the text here
in RFC3315 sounds 'the addresses in the IA', which are from Confirm.

Marcin - Perhaps, it could be more precise and say something along the
lines: if none of the Reply messages received in response to a Confirm
message indicates success, the client performs solicitation. Otherwise, it
may use the address.

That sounds fine with me.

Best Regards,
Leaf

-----Original Message-----
From: Marcin Siodelski [mailto:[email-masked]] 
Sent: Monday, May 26, 2014 6:54 PM
To: Leaf Yeh; 'Bernie Volz (volz)'; 'Tomasz Mrugalski'
Cc: [email-masked]; 'dhcpv6bis'
Subject: Re: [Dhcpv6bis] Reply to Confirm in RFC3315

"

Marcin

---

From: "Leaf Yeh" <[email-masked]>
Date: Tue, 27 May 2014 13:42:02 +0800

When I read the text on 'Reply to Confirm' in RFC3315, the following statements sounds me a little misunderstanding:

<quote> @ 18.1.2 - Creation and Transmission of Confirm Messages

   The client MUST include a Client Identifier option to identify itself

   to the server.  The client includes IA options for all of the IAs

   assigned to the interface for which the Confirm message is being

   sent.  The IA options include all of the addresses the client

   currently has associated with those IAs.  The client SHOULD set the

   T1 and T2 fields in any IA_NA options, and the preferred-lifetime and

   valid-lifetime fields in the IA Address options to 0, as the server

   will ignore these fields.

</quote>

It sounds the client ask the server to confirm the address (& IA) for his interface, but why not ask the server to confirm the values of lease timers (T1/T2 for IA, preferred/valid-LT for address) he has.

<quote> @ 18.2.2 -Receipt of Confirm Messages

   The server ignores the T1 and T2 fields in the IA options and the

   preferred-lifetime and valid-lifetime fields in the IA Address

   options.

   ...

   The server MUST include a Server Identifier option containing the

   server's DUID and the Client Identifier option from the Confirm

   message in the Reply message.  The server includes a Status Code

   option indicating the status of the Confirm message.

</quote>

Certainly, the server confirmed the address (& the associated IAID) of client based on its this own database. If the server returned the global ‘Success’ in the Status Code option, it sounds all the information the client provided in Confirm has been confirmed, and assumed the client has the same lease as that recoded in the database of server.

But I think it sounds much better the server could confirm (or update) all the information about the lease (including address and the value of timers) for the client in the Reply message. It looks much clearer, and cost little in the Reply.

The global Status Code looks unspecified to each address (and its lease), which in fact needs to be confirmed.

Best Regards,

Leaf

-----Original Message-----
From: Marcin Siodelski [mailto:[email-masked]] 
Sent: Monday, May 26, 2014 7:56 PM
To: Bernie Volz (volz)
Cc: [email-masked]; 'dhcpv6bis'; Leaf Yeh; 'Tomasz Mrugalski'
Subject: Re: [Dhcpv6bis] Reply to Confirm in RFC3315

Marcin

> From: Marcin Siodelski [ <mailto:[email-masked]> mailto:[email-masked]]

> Cc:  <mailto:[email-masked]> [email-masked]; 'dhcpv6bis'

>> < <http://tools.ietf.org/html/rfc3315#section-17> http://tools.ietf.org/html/rfc3315#section-17>, and client-initiated

>> < <http://tools.ietf.org/html/rfc3315#section-18> http://tools.ietf.org/html/rfc3315#section-18>.  If the client 

>>    can usethe addresses in the IA andignore any messages that 

>> indicate

---

From: "Leaf Yeh" <[email-masked]>
Date: Tue, 27 May 2014 16:54:46 +0800

BV> In Request case it is within the IA and means that the client's requested addresses (or PD) is not on the link...The Request case is a bit weird in one respect as 18.1.8 says:

This kind of implies that it is "global". I think this case was to handle the client moving between Solicit and Request (but with the same server still responding since the Server DUID matches).

The above quoted paragraph is associated with one paragraph in section 18.2.1, 

   If the server finds that the prefix on one or more IP addresses in

   any IA in the message from the client is not appropriate for the link

   to which the client is connected, the server MUST return the IA to

   the client with a Status Code option with the value NotOnLink.

My question is why the server can't ignore 'the addresses in any IA in the message from the client', and send back a new address for the IA requested by the client per its (configuration) policy.

Best Regards,

Leaf

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]] 
Sent: Monday, May 26, 2014 8:07 PM
To: Marcin Siodelski
Cc: [email-masked]; 'dhcpv6bis'; Leaf Yeh; 'Tomasz Mrugalski'
Subject: RE: [Dhcpv6bis] Reply to Confirm in RFC3315

- Bernie

-----Original Message-----

To: Bernie Volz (volz)

Cc:  <mailto:[email-masked]> [email-masked]; 'dhcpv6bis'; Leaf Yeh; 'Tomasz Mrugalski'

Marcin

---

From: "Leaf Yeh" <[email-masked]>
Date: Tue, 27 May 2014 17:23:45 +0800

Ted - If the server is not configured with information about a link, it should not respond.

Agreed. Then I might be confused on the other sentence says in section 18.2.2- Receipt of Confirm Messages:
   When the server receives a Confirm message, the server determines
   whether the addresses in the Confirm message are appropriate for the
   link to which the client is attached. ...
   If any of the addresses do not pass this test, the server
   returns a status of NotOnLink.
Or the server does not necessarily to return the global 'NotOnLink'....

Marcin  - ...NotOnLink...) it either means misconfiguration or a rogue server sending Replies.

That sounds horrible ...:-) Anyway, may we need more clarification on the sentence under discussion...

Best Regards,
Leaf

-----Original Message-----
From: Marcin Siodelski [mailto:[email-masked]] 
Sent: Monday, May 26, 2014 8:29 PM
To: Ted Lemon
Cc: Leaf Yeh; Bernie Volz; Tomek Mrugalski; [email-masked]; dhcpv6bis
Subject: Re: [Dhcpv6bis] Reply to Confirm in RFC3315

> That should never happen.   If the server is not configured with information about a link, it should not respond.   Does the document say it should?   If one server responds with NotOnLink and anot…

You're right. In 18.2.2 it is said that it should not respond when it doesn't have a knowledge of the prefixes on the link to which the client is connected. So, it really sounds that when there are two responses (one with NotOnLink, another one with Success) it either means misconfiguration or a rogue server sending Replies.

Marcin

---

From: "Leaf Yeh" <[email-masked]>
Date: Tue, 27 May 2014 17:43:29 +0800

Ted - I think this is explained somewhere in the document--if so, it might
be good to say so explicitly here.   If not, more explanation wouldn't hurt.

FYI, the RFC has 7 places mentioned 'NotOnLink', but it seems no place to
explain that ' NotOnLink is a great way to do a DoS attack'...

Best Regards,
Leaf

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Monday, May 26, 2014 8:14 PM
To: Leaf Yeh
Cc: Bernie Volz; Tomek Mrugalski; [email-masked]; dhcpv6bis
Subject: Re: [Dhcpv6bis] Reply to Confirm in RFC3315

NoBinding and NoAddrsAvail are indications about the status of a single DHCP
server, but there may be more than one DHCP server on the wire.   So if a
server replies with such a message rather than a NotOnLink message, this
means that that server believes the client is correctly configured, but
isn't the server that configured it.   So if another server replies
NotOnLink, there's a misconfiguration-DHCP servers should never disagree
about that.   Ignoring the NotOnLink in this case may be incorrect, but
accepting it may also be incorrect.   And since NotOnLink is a great way to
do a DoS attack, it's better to ignore an erroneous NotOnLink than honor it.

I think this is explained somewhere in the document--if so, it might be good
to say so explicitly here.   If not, more explanation wouldn't hurt.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 27 May 2014 11:09:53 +0000

It is not Success not NotOnLInk, so I would say the client would ignore this message.

- Bernie

-----Original Message-----
From: Leaf Yeh [mailto:[email-masked]] 
Sent: Monday, May 26, 2014 10:05 PM
To: Bernie Volz (volz); 'Marcin Siodelski'; 'Tomasz Mrugalski'
Cc: [email-masked]; 'dhcpv6bis'
Subject: RE: [Dhcpv6bis] Reply to Confirm in RFC3315

BV > Other than global errors like UnspecFail, a Confirm will either contain NotOnLink or Success. Nothing else.

If the client receive a reply with global error 'UnspecFail' , can the client still 'use the addresses in the IA' indicating in the Confirm?

Best Regards,
Leaf

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Monday, May 26, 2014 7:42 PM
To: Marcin Siodelski; Leaf Yeh; 'Tomasz Mrugalski'
Cc: [email-masked]; 'dhcpv6bis'
Subject: RE: [Dhcpv6bis] Reply to Confirm in RFC3315

- Bernie

-----Original Message-----
From: Marcin Siodelski [mailto:[email-masked]]
Sent: Monday, May 26, 2014 6:54 AM
To: Leaf Yeh; Bernie Volz (volz); 'Tomasz Mrugalski'
Cc: [email-masked]; 'dhcpv6bis'
Subject: Re: [Dhcpv6bis] Reply to Confirm in RFC3315

"

Marcin

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 27 May 2014 11:15:49 +0000

>My question is why the server can't ignore 'the addresses in any IA in the message from the client', and send back a new address for the IA requested by the client per its (configuration) policy.

Because the client has moved and so we want it to start over – it may be that lots of other items have changed as well (perhaps even a “better” server is available).

-          Bernie

From: Leaf Yeh [mailto:[email-masked]]
Sent: Tuesday, May 27, 2014 4:55 AM
To: Bernie Volz (volz); 'Marcin Siodelski'
Cc: [email-masked]; 'dhcpv6bis'; 'Tomasz Mrugalski'
Subject: Reply to Request in RFC3315

Best Regards,

Leaf

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 27 May 2014 11:13:43 +0000

What is the point of all this?

Confirm does not confirm any leases or lease times. It just confirms that the addresses are ON LINK.

Confirm is supposed to be quick and easy for servers (no database looks or writes about a specific lease) – just to verify that addresses are on link (which is any easy test to locate the prefix containing the addresses). It is NOT a Renew.

-          Bernie

From: Leaf Yeh [mailto:[email-masked]]
Sent: Tuesday, May 27, 2014 1:42 AM
To: Bernie Volz (volz)
Cc: [email-masked]; 'dhcpv6bis'; 'Tomasz Mrugalski'; 'Marcin Siodelski'
Subject: More Discussion - RE: [Dhcpv6bis] Reply to Confirm in RFC3315

</quote>

   options.

   ...

</quote>

Best Regards,

Leaf

-----Original Message-----
From: Marcin Siodelski [mailto:[email-masked]]
Sent: Monday, May 26, 2014 7:56 PM
To: Bernie Volz (volz)
Cc: [email-masked]<mailto:[email-masked]>; 'dhcpv6bis'; Leaf Yeh; 'Tomasz Mrugalski'
Subject: Re: [Dhcpv6bis] Reply to Confirm in RFC3315

Marcin

> Cc: [email-masked]<mailto:[email-masked]>; 'dhcpv6bis'

>> <http://tools.ietf.org/html/rfc3315#section-18>.  If the client

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 May 2014 08:39:43 -0400

> It sounds the client ask the server to confirm the address (& IA) for his interface, but why not ask the server to confirm the values of lease timers (T1/T2 for IA, preferred/valid-LT for address)…

That would be a change to the protocol, and would serve no purpose, since the client already knows its lease times.   The point of this exercise is not to make gratuitous changes to the protocol.

---

From: "Leaf Yeh" <[email-masked]>
Date: Tue, 27 May 2014 22:56:52 +0800

BV> Because the client has moved…

I guess Reply to Request is not assumed the client has moved.

Best Regards,

Leaf

From: Bernie Volz (volz) [mailto:[email-masked]] 
Sent: Tuesday, May 27, 2014 7:16 PM
To: Leaf Yeh; 'Marcin Siodelski'
Cc: [email-masked]; 'dhcpv6bis'; 'Tomasz Mrugalski'
Subject: RE: Reply to Request in RFC3315

-          Bernie

 

Best Regards,

Leaf

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 27 May 2014 15:04:54 +0000

Request case allows for client to do either (re-issues Request or start over):

For Confirm, as client is using the leases it is best it start over.

- Bernie

From: Leaf Yeh <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, May 27, 2014 at 10:56 AM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>, Marcin Siodelski <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Tomek Mrugalski <[email-masked]<mailto:[email-masked]>>
Subject: RE: Reply to Request in RFC3315

Best Regards,
Leaf

Cc: [email-masked]<mailto:[email-masked]>; 'dhcpv6bis'; 'Tomasz Mrugalski'

-          Bernie

Cc: [email-masked]<mailto:[email-masked]>; 'dhcpv6bis'; 'Tomasz Mrugalski'

Best Regards,

Leaf

---

From: "Leaf Yeh" <[email-masked]>
Date: Tue, 27 May 2014 23:10:12 +0800

BV> Confirm is supposed to be quick and easy for servers (no database looks … about a specific lease) – just to verify that addresses are on link (which is any easy test to locate the prefix containing the addresses).

Even though Confirm in RFC3315 sounds only verify the addresses in IAs and assume the client knows the correct lease for each address, it still looks much clearer that the server does verify each IA, and could send back the Status Code for each IA.

I do personally like Confirm could works as Renew. J

Best Regards,

Leaf

From: Bernie Volz (volz) [mailto:[email-masked]] 
Sent: Tuesday, May 27, 2014 7:14 PM
To: Leaf Yeh
Cc: [email-masked]; 'dhcpv6bis'; 'Tomasz Mrugalski'; 'Marcin Siodelski'
Subject: RE: More Discussion - RE: [Dhcpv6bis] Reply to Confirm in RFC3315

-          Bernie

</quote>

 

   options.

   ...

</quote>

 

Best Regards,

Leaf

-----Original Message-----
From: Marcin Siodelski [mailto:[email-masked]] 
Sent: Monday, May 26, 2014 7:56 PM
To: Bernie Volz (volz)
Cc: [email-masked]; 'dhcpv6bis'; Leaf Yeh; 'Tomasz Mrugalski'
Subject: Re: [Dhcpv6bis] Reply to Confirm in RFC3315

Marcin

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 May 2014 11:11:25 -0400

> I do personally like Confirm could works as Renew. J

We are not changing the protocol.   Also, what you are proposing makes Confirm more expensive.

---

From: "Leaf Yeh" <[email-masked]>
Date: Tue, 27 May 2014 23:25:46 +0800

My point in the mail before my last mail was against: 

in section  <http://tools.ietf.org/html/rfc3315#section-18.2.1> 18.2.1-
Receipt of Request Messages.

I guess the server could choose to ignore the IP addresses in any IA from
Request, and don't return back the IA-specific 'NotOnLink'.

Why not? Pls. help to exercise my brain. J

Best Regards,

Leaf

From: Bernie Volz (volz) [mailto:[email-masked]] 
Sent: Tuesday, May 27, 2014 11:05 PM
To: Leaf Yeh; 'Marcin Siodelski'
Cc: [email-masked]; 'dhcpv6bis'; 'Tomasz Mrugalski'
Subject: Re: Reply to Request in RFC3315

Request case allows for client to do either (re-issues Request or start
over):

- Bernie

From: Leaf Yeh <[email-masked]>
Date: Tuesday, May 27, 2014 at 10:56 AM
To: Cisco Employee <[email-masked]>, Marcin Siodelski <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]"
<[email-masked]>, Tomek Mrugalski <[email-masked]>
Subject: RE: Reply to Request in RFC3315

BV> Because the client has moved.

 

Best Regards,

Leaf

>My question is why the server can't ignore 'the addresses in any IA in the
message from the client', and send back a new address for the IA requested
by the client per its (configuration) policy.

Because the client has moved and so we want it to start over - it may be
that lots of other items have changed as well (perhaps even a "better"
server is available).

-          Bernie

BV> In Request case it is within the IA and means that the client's
requested addresses (or PD) is not on the link...The Request case is a bit
weird in one respect as 18.1.8 says:

This kind of implies that it is "global". I think this case was to handle
the client moving between Solicit and Request (but with the same server
still responding since the Server DUID matches).

The above quoted paragraph is associated with one paragraph in section
18.2.1, 

My question is why the server can't ignore 'the addresses in any IA in the
message from the client', and send back a new address for the IA requested
by the client per its (configuration) policy.

Best Regards,

Leaf

---

From: Ole Troan <[email-masked]>
Date: Wed, 28 May 2014 12:56:10 +0200

> I do personally like Confirm could works as Renew. J

we did exactly that in RFC3633.
although servers without the binding is unlikely to be able to give any confirmation, in the stateful-issues draft I believe we specify a more generic form of confirm, that can also be used by other IA types than addresses.

cheers,
Ole

> Certainly, the server confirmed the address (& the associated IAID) of client based on its this own database. If the server returned the global ‘Success’in the Status Code option, it sounds all the information the client provided in Confirm has been confirmed, and assumed the client has the same lease as that recoded in the database of server.
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Leaf Yeh" <[email-masked]>
Date: Wed, 28 May 2014 23:35:03 +0800

Ted - That would be a change to the protocol, 

A very small change(no new message), just ask to return IAs (+ the
appropriate lease for its associated addresses) in the Reply to client.

Ted - and would serve no purpose, 

It can be used by SAVI-switch to create a new (and informational) binding
entry, when one client moved to a new SAVI-switch in the same broadcasting
domain.

Ted - since the client already knows its lease times.

Yes, the client knows but the SAVI-switch does not.

Best Regards,
Leaf

PS. https://datatracker.ietf.org/doc/draft-ietf-savi-dhcp/?include_text=1

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Tuesday, May 27, 2014 8:40 PM
To: Leaf Yeh
Cc: Bernie Volz; Tomek Mrugalski; [email-masked]; dhcpv6bis; Marcin
Siodelski
Subject: Re: [Dhcpv6bis] More Discussion - RE: Reply to Confirm in RFC3315

On May 27, 2014, at 1:42 AM, Leaf Yeh <[email-masked]> wrote:
> It sounds the client ask the server to confirm the address (& IA) for his
interface, but why not ask the server to confirm the values of lease timers
(T1/T2 for IA, preferred/valid-LT for address) he has.

That would be a change to the protocol, and would serve no purpose, since
the client already knows its lease times.   The point of this exercise is
not to make gratuitous changes to the protocol.

---

From: "Leaf Yeh" <[email-masked]>
Date: Thu, 29 May 2014 00:53:13 +0800

Ole - we did exactly that in RFC3633.

Per Section 12.1- Requesting router behavior in RFC3633, "The Confirm and
Decline message types are not used with Prefix Delegation. " I suppose
RFC3633 employs Rebind instead of Confirm.

Ole - in the stateful-issues draft I believe we specify a more generic form
of confirm, 

I propose a smallest change to employ back Confirm, surely we need IA_PD to
be included in Confirm to support PD. 
But the Reply to Confirm could also include IA_NA and/or IA_PD (+
IA-specified status code). 
I might need to find some time to read draft-stateful-issues again.

Ole - that can also be used by other IA types than addresses.

DHCPv6 Confirm -> Reply process needs support both IA_NA and IA_PD, and
shall respond them respectively, not only return the global and vague
'NotOnLink'. And it is better to return their lease in IA_NA and/or IA_PD.
Then we got flexibility and precision in the same time.

Best Regards,
Leaf

-----Original Message-----
From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Wednesday, May 28, 2014 6:56 PM
To: Leaf Yeh
Cc: [email-masked]; Bernie Volz (volz); dhcpv6bis
Subject: Re: [Dhcpv6bis] [dhcwg] More Discussion - RE: Reply to Confirm in
RFC3315

> BV> Confirm is supposed to be quick and easy for servers (no database
looks . about a specific lease) - just to verify that addresses are on link
(which is any easy test to locate the prefix containing the addresses).
> 
> Even though Confirm in RFC3315 sounds only verify the addresses in IAs and
assume the client knows the correct lease for each address, it still looks
much clearer that the server does verify each IA, and could send back the
Status Code for each IA.

we did exactly that in RFC3633.
although servers without the binding is unlikely to be able to give any
confirmation, in the stateful-issues draft I believe we specify a more
generic form of confirm, that can also be used by other IA types than
addresses.

cheers,
Ole

> Confirm is supposed to be quick and easy for servers (no database looks or
writes about a specific lease) - just to verify that addresses are on link
(which is any easy test to locate the prefix containing the addresses). It
is NOT a Renew.
> When I read the text on 'Reply to Confirm' in RFC3315, the following
> Certainly, the server confirmed the address (& the associated IAID) of
client based on its this own database. If the server returned the global
'Success'in the Status Code option, it sounds all the information the client
provided in Confirm has been confirmed, and assumed the client has the same
lease as that recoded in the database of server.
> 
> But I think it sounds much better the server could confirm (or update) all
the information about the lease (including address and the value of timers)
for the client in the Reply message. It looks much clearer, and cost little
in the Reply.
> Yes, NoAddrsAvail/NoBinding are not sent in response to Confirm. May point
rather was that *even in a more general case* the server will not send
addresses in the IA in which there is NoAddrsAvail or NoBinding.
>> I think we're talking about Reply to Confirm. If so, why would these
contain NoAddrsAvail/NoBinding? They don't. Confirm does not validate a
particular client's addresses/PDs or bindings. It only validates whether the
addresses/PDs are on link or not.
>> 
>> And, yes the idea was there could be multiple servers some of which may
send NotOnLink (as they may be lacking the configuration) but others that
send Success. The Success on can be taken.
>> Of course, client may receive Replies with other status codes too, and
there are relevant sections that talk about client behavior in this case".
>> The way I read it is that when the client receives at least one Reply
that has no NotOnLink status code, it may use the address it desires to use.
Otherwise it performs solicitation.
none of the Reply messages received in response to a Confirm message
indicates success, the client performs solicitation. Otherwise, it may use
the address.

_______________________________________________
Dhcpv6bis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcpv6bis