Subject: [dhcwg] Reminder - WGLC: draft-ietf-dhc-triggered-reconfigure-03

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 25 Feb 2013 03:58:14 +0000

Just a reminder that this WGLC is coming to a close (Feb 28) and I believe there's only been one response so far.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Thursday, February 14, 2013 11:16 AM
To: [email-masked] WG
Subject: [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-03

Med has updated the draft to account for comments made during the working group last call.   This is a new WGLC: if you had comments on the previous draft, please review the changes.   If you are in favor of advancing the draft, please say so.   If you oppose advancing the draft, please say so.

We will determine consensus on February 28.

Thanks!

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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Feb 2013 04:10:12 +0000

> Just a reminder that this WGLC is coming to a close (Feb 28) and I believe there's only been one response so far.

Chair/AD hat off, I think the draft is a good idea and we should publish it.

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Mon, 25 Feb 2013 04:18:27 +0000

I support the advancement of this draft. It should move forward.

-Gaurav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Monday, February 25, 2013 9:28 AM
To: [email-masked] WG
Subject: [dhcwg] Reminder - WGLC: draft-ietf-dhc-triggered-reconfigure-03

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Thursday, February 14, 2013 11:16 AM
To: [email-masked] WG
Subject: [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-03

Thanks!

---

From: Andre Kostur <[email-masked]>
Date: Mon, 25 Feb 2013 09:32:39 -0800

I support this draft.

-- 
Andre Kostur

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 25 Feb 2013 23:01:34 +0100

On 25.02.2013 04:58, Bernie Volz (volz) wrote:
> Just a reminder that this WGLC is coming to a close (Feb 28) and I
> believe there's only been one response so far.
I support this work and would like it to move forward.

I have some comments on it though.

Figure 1 could be updated. The example used in exchange between NAS and
Radius server is DS-Lite-Tunnel-Name. I assume that is Radius name of
the option for DS-Lite. That is ok. That name is then used in
Relay-Forward using that same name. It should be OPTION_AFTR_NAME
(DHCPv6 name, not Radius name). It should also be mentioned in Relay-Reply
"includes Advertise that includes OPTION_AFTR_NAME" or similar.
Otherwise it is difficult to understand how relay gets that option.

Figure 1 mentions NAS, without explaining what it means. I presume that
it is Network Access Server, but it is not a common term in DHCP world,
so it would be good to explain it.

Section 2: "Reconfigure message is then sent to the DHCPv6 relay, which
in turn will forward the message to the appropriate DHCPv6 client." This
reconfigure message will be sent encapsulated in Relay-Reply, so it will
look like every other message received from a server and to be processed
by the relay, right? There's no text that clarifies that.

Last paragraph is section 2 talks about retransmissions, but do not
explain how to conduct them if there is no server response. It should
point out that the details are explained in section 4.3.

Section 4.2.1: "Clients MUST silently discard any received
RECONFIGURE-REQUEST messages.". I would add that logging such an event
is allowed, though.

"The server MUST be configurable to accept or reject RECONFIGURE-
REQUEST messages." This should probably be moved to "Server behavior"
section. Also, you should specify what is the server default if not
explicitly configured. It should be reject in my opinion.

"The relay agent MUST be configurable to accept or reject RECONFIGURE-
REQUEST messages received from other relay agents.". Reconfigure-Request
is not addressed at relay and it merely helps deliver it to server, so
instead of "accept or reject" I would use "forward or drop" here.

There should be a separate "Relay behavior" section and second to last
paragraph in 4.2.1 should be moved to it. There are very good reasons
for having separate behavior sections for server, relays and client
There should be one for client as well, even if it contains only one
sentence about dropping those messages. It makes life of implementors
much easier and increases chances of wider adoption of that proposal.

The last paragraph in 4.2.1 belongs more in the Server behavior section.

Section 4.3 "The relay may receive (Relay-Reply) Reconfigure before..."
is awkward. It should be "The relay may receive Reconfigure encapsulated
in Relay-Reply before..."

"The relay agent MUST include a Client Identifier Option..." => "The
relay agent MUST include one or more Client Identifier Options..."

Section 4.4 "Upon receipt of a valid Reconfigure-Request message from a
DHCPv6 relay agent (see Section 4.2), the server determines the
client(s) for which a Reconfigure message is to be sent.".

Section 4.4, bullet 2 and 3 contradict each other. When relay requested
reconfigure for 2 clients and one succeeds and the other fails, what
should be the return status: success or failure code? What if the
failure reasons are different for each client? It seems that the status
code returning is not very useful for more than one client.

Section 4.4, bullet 2 says that server must keep list of client-ids that
it couldn't configure, but does not explain what to do with that list.
Did you mean "include in reconfigure-ack"? If that is so, please
rephrase that sentence. If you meant something else, please clarify as well.

Section 7. You should change the text to say that servers MUST discard
configure-request unless explicitly configured to accept them (or
perhaps this should go into server behavior section). It's better to be
safe than sorry.

Although DUIDs are typically 14 bytes long, the maximum allowed length
is 128, so we can hit fragementation limit with only 10 clients. There
should be a short clarification that relay should send separate
reconfigure-requests if there are more clients (or some other suggestion
what to do if the MTU limit is hit).

Reconfigure mechanism is optional. What should the server do if client
does not support Reconfigure?  There's currently no way for server to
signal that to back to relay. UnspecFail doesn't look right. Perhaps
NotConfigured would be the right code for it?

Excuse my poor understanding of how NAS works, but does it keep DUIDs of
all clients connected through it? So from the pure DHCP perspective,
this is a stateful relay, right? If that is so, it should be pointed
somewhere that the way relay keeps the information about clients is
outside of scope for this document.

Other than those comments, this draft is in a good shape and I support
this work moving forward.

Tomek

---

From: <[email-masked]>
Date: Tue, 26 Feb 2013 10:34:21 +0100

Hi Tomek,

Many thanks for the detailed review. 

Please see inline.
Cheers,
Med 

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De 
>la part de Tomek Mrugalski
>Envoyé : lundi 25 février 2013 23:02
>À : [email-masked]
>Objet : Re: [dhcwg] Reminder - WGLC: 
>draft-ietf-dhc-triggered-reconfigure-03
>

Med: Thanks for catching this. The figure is now updated. 

>so it would be good to explain it.

Med: I added this sentence: 
"Figure 1 shows a broadband network scenario in which the Network Access Server (NAS) embeds a DHCPv6 relay agent."

Do you think the document needs to say more?

>by the relay, right? There's no text that clarifies that.

Med: I added this sentence just after the one you quoted: 

"Note, the server encapsulates the Reconfigure message in a Relay-reply message."

Better?

>point out that the details are explained in section 4.3.

Med: The text is now updated to call out Section 4.3. 

>RECONFIGURE-REQUEST messages.". I would add that logging such an event

Med: Is there any value to log such events in the client side?

>section. 

Med: Ok for me. Done.

Also, you should specify what is the server default if not
>explicitly configured. It should be reject in my opinion.

Med: I added this sentence: 
"If no indication is explicitly configured to the server, the default behaviour is to reject RECONFIGURE-REQUEST messages."

>instead of "accept or reject" I would use "forward or drop" here.

Med: I do think both wording would work. "accept" is more generic as forwarding the message will be the result of other steps than just accept handling the message. I will maintain the initial wording. 

>paragraph in 4.2.1 should be moved to it.

Med: I added a new section called "Intermediate Relay Agents Behaviour" and moved that text to the new section.

 There are very good reasons
>The last paragraph in 4.2.1 belongs more in the Server 

Med: Agree.

>in Relay-Reply before..."

Med: Fixed. Thanks.

>relay agent MUST include one or more Client Identifier Options..."

Med: Fixed. 

>should be the return status: success or failure code?

Med: bullet 2 is about partial failure (i.e., there is at least a success for one client); bullet 3 is when there is failure for all clients. In the partial failure case, the list of failed cio are returned also in the Reconfigure-Ack.

 What if the
>rephrase that sentence. If you meant something else, please 

Med: The text is about Reconfigure-Ack. I fixed the text.

>perhaps this should go into server behavior section). It's better to be

Med: discarding RECONFIGURE-REQUEST messages + configuration options are already covered in the server behaviour. I prefer

>what to do if the MTU limit is hit).

Med: Isn't this covered in the text of Section 4.3: 

 If including Client
   Identifier Options of all impacted clients exceeds the maximum
   message size (see Section 5), the relay MUST generate several
   RECONFIGURE-REQUEST messages required to carry all Client Identifier
   Options.  Rate-limit considerations are discussed in Section 5.

>NotConfigured would be the right code for it?

Med: If we need to specific, a new error code need to be defined for this case. If you think there is a value in specifying that behaviour, I suggest we define a new error code for it.  

>outside of scope for this document.

Med: Section 2 says: 

   This setup assumes the relay has a record of the client, so that it
   has enough information to send the Reconfigure-Request message to the
   server.  Means to recover state in failure events must be supported,
   but are not discussed in this document.

I propose to change it to 

   This setup assumes the relay has a record of the client, so that it
   has enough information to send the Reconfigure-Request message to the
   server. How the state is recorded in the relay is out of scope. Furthermore, means to recover state in failure events must be supported,
   but are not discussed in this document.

>this work moving forward.

Med: Thanks.

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 26 Feb 2013 11:56:48 +0100

> Do you think the document needs to say more?
No. That addition is sufficient.

> "Note, the server encapsulates the Reconfigure message in a Relay-reply message."
Yes.

> Med: The text is now updated to call out Section 4.3. 
Thanks.

> Med: Is there any value to log such events in the client side?
Sometimes yes. Some clients (e.g. dibbler) will print out a warning
message, when receiving unknown message (basically anything besides
advertise or reply). Reception of such a message by a client may mean
that your network is seriously broken or there is an attack in progress.
This is really a grey area that nobody cares about. Many clients and
servers log various things when configured with sufficient log levels.
If we want to be strict, this is a violation of RFC3315, but I have
serious doubts anyone care about that. So I'm ok if you don't want to do
anything here.

>> REQUEST messages." This should probably be moved to "Server behavior"
Thanks.

> "If no indication is explicitly configured to the server, the default behaviour is to reject RECONFIGURE-REQUEST messages."
Ok, great.

> Med: I do think both wording would work. "accept" is more generic as forwarding the message will be the result of other steps than just accept handling the message. I will maintain the initial word…
Ok.

> Med: I added a new section called "Intermediate Relay Agents Behaviour" and moved that text to the new section.
Thanks.

>> The last paragraph in 4.2.1 belongs more in the Server 
Ok, thanks.

>> in Relay-Reply before..."
Thanks.

>> relay agent MUST include one or more Client Identifier Options..."
Thanks a lot. This was confusing without this clarification.

> Med: bullet 2 is about partial failure (i.e., there is at least a success 
> for one client); bullet 3 is when there is failure for all clients. In
the
> partial failure case, the list of failed cio are returned also in the
> Reconfigure-Ack.
> 
>  What if the
Thanks.

> Med: discarding RECONFIGURE-REQUEST messages + configuration options are already covered in the server behaviour. I prefer
Good point. THere's no need to repeat them here. One place is enough.

>    Options.  Rate-limit considerations are discussed in Section 5.
Oh, I missed that. Sorry. Yes, the existing text is clear then.

> Med: If we need to specific, a new error code need to be defined for this
> case. If you think there is a value in specifying that behaviour,
> I suggest we define a new error code for it.
I don't know. Does the relay can use the information why the reconfigure
failed? I suppose there could be some value in making different
permanent failures (e.g. the client do not support reconfigure) with
some temporary failure that may disappear when repeated reconfigure
request is made. But I do not have any strong opinion on that. Can
someone else comment on this as well?

>    but are not discussed in this document.
Ok.

Ok, great. That deals with all my comments. Let's see if anyone else has
additional comments on the status code. I'm ok with leaving it as it is,
reusing some of the codes from leasequery or defining a new one.

After that I think the draft is good to move forward.

Cheers,
Tomek

---

From: <[email-masked]>
Date: Tue, 26 Feb 2013 13:42:54 +0100

Re-,

For the error code, I will wait for other opinions. 
If no preference is expressed, the current text will be maintained as it is. 

Thanks again for the review. 
Cheers,
Med

>De : Tomek Mrugalski [mailto:[email-masked]] 
>Envoyé : mardi 26 février 2013 11:57
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : [email-masked]
>> "Figure 1 shows a broadband network scenario in which the 
>Network Access Server (NAS) embeds a DHCPv6 relay agent."
>> "If no indication is explicitly configured to the server, 
>the default behaviour is to reject RECONFIGURE-REQUEST messages."
>Ok, great.
>
>> Med: I do think both wording would work. "accept" is more 
>generic as forwarding the message will be the result of other 
>steps than just accept handling the message. I will maintain 
>the initial wording. 
>Ok.
>
>> Med: I added a new section called "Intermediate Relay Agents 
>Behaviour" and moved that text to the new section.
>Thanks.
>
>> Med: discarding RECONFIGURE-REQUEST messages + configuration 
>options are already covered in the server behaviour. I prefer
>>    server. How the state is recorded in the relay is out of 
>scope. Furthermore, means to recover state in failure events 
>must be supported,

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 1 Mar 2013 05:20:48 +0000

(WG hat off)

The issue regarding section 4.4 and error-codes should be addressed and clarified.

Personally, I don't see a need for the server to return specific status (error) information for each client, as the likely reasons it would not be able to send a Reconfigure is because the client didn't negotiate for reconfigure support or the client doesn't exist in the server. There are other reasons (lack of resources) ...

We have to ask what benefit (other than potentially logging) would the Relay gain by having more specific information? I don't really believe there is.

Perhaps the three possible returns are:
- Full Success (first bullet in existing section).
- Partial Success (second bullet) - includes list of clients NOT processed (for whatever reason) which might be ALL clients.
- Full failure (third bullet) where clients were not even attempted - this handles the case where:
A) the packet is malformed (for example has no client-identifier option) - UnspecFail
B) the server has been configured not to allow this request - NotAllowed
C) the server has no record of the link - NotConfigured

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
Sent: Tuesday, February 26, 2013 5:57 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dhcwg] Reminder - WGLC: draft-ietf-dhc-triggered-reconfigure-03

On 26.02.2013 10:34, [email-masked] wrote:
>> Figure 1 mentions NAS, without explaining what it means. I presume 
>> that it is Network Access Server, but it is not a common term in DHCP 
>> world, so it would be good to explain it.
> 

>> Section 2: "Reconfigure message is then sent to the DHCPv6 relay, 
>> which in turn will forward the message to the appropriate DHCPv6 
>> client." This reconfigure message will be sent encapsulated in 
>> Relay-Reply, so it will look like every other message received from a 
>> server and to be processed by the relay, right? There's no text that 
>> clarifies that.
> 
Yes.

Thanks.

>> RECONFIGURE-REQUEST messages.". I would add that logging such an 
>> event is allowed, though.
Sometimes yes. Some clients (e.g. dibbler) will print out a warning message, when receiving unknown message (basically anything besides advertise or reply). Reception of such a message by a client may mean that your network is seriously broken or there is an attack in progress.
This is really a grey area that nobody cares about. Many clients and servers log various things when configured with sufficient log levels.
If we want to be strict, this is a violation of RFC3315, but I have serious doubts anyone care about that. So I'm ok if you don't want to do anything here.

Thanks.

Ok, great.

>> "The relay agent MUST be configurable to accept or reject 
>> RECONFIGURE- REQUEST messages received from other relay agents.".
>> Reconfigure-Request
>> is not addressed at relay and it merely helps deliver it to server, 
>> so instead of "accept or reject" I would use "forward or drop" here.
> 
Ok.

>> There should be a separate "Relay behavior" section and second to 
>> last paragraph in 4.2.1 should be moved to it.
> 
Thanks.

Ok, thanks.

>> is awkward. It should be "The relay may receive Reconfigure 
>> encapsulated in Relay-Reply before..."
> 
> Med: Fixed. Thanks.
Thanks.

>> Section 4.4, bullet 2 and 3 contradict each other. When relay 
>> requested reconfigure for 2 clients and one succeeds and the other 
>> fails, what should be the return status: success or failure code?
> 
> Med: bullet 2 is about partial failure (i.e., there is at least a 
> success for one client); bullet 3 is when there is failure for all 
> clients. In
the
>> failure reasons are different for each client? It seems that the 
>> status code returning is not very useful for more than one client.
>>
>> Section 4.4, bullet 2 says that server must keep list of client-ids 
>> that it couldn't configure, but does not explain what to do with that 
>> list.
Thanks.

>> Section 7. You should change the text to say that servers MUST 
>> discard configure-request unless explicitly configured to accept them 
>> (or perhaps this should go into server behavior section). It's better 
>> to be safe than sorry.
> 
> Med: discarding RECONFIGURE-REQUEST messages + configuration options 
> are already covered in the server behaviour. I prefer

>> Although DUIDs are typically 14 bytes long, the maximum allowed 
>> length is 128, so we can hit fragementation limit with only 10 
>> clients. There should be a short clarification that relay should send 
>> separate reconfigure-requests if there are more clients (or some 
>> other suggestion what to do if the MTU limit is hit).
> 

>> Reconfigure mechanism is optional. What should the server do if 
>> client does not support Reconfigure?  There's currently no way for 
>> server to signal that to back to relay. UnspecFail doesn't look 
>> right. Perhaps NotConfigured would be the right code for it?
> 
> Med: If we need to specific, a new error code need to be defined for 
> this case. If you think there is a value in specifying that behaviour, 
I don't know. Does the relay can use the information why the reconfigure failed? I suppose there could be some value in making different permanent failures (e.g. the client do not support reconfigure) with some temporary failure that may disappear when repeated reconfigure request is made. But I do not have any strong opinion on that. Can someone else comment on this as well?

>> Excuse my poor understanding of how NAS works, but does it keep DUIDs 
>> of all clients connected through it? So from the pure DHCP 
>> perspective, this is a stateful relay, right? If that is so, it 
>> should be pointed somewhere that the way relay keeps the information 
>> about clients is outside of scope for this document.
> 
> Med: Section 2 says: 
> 
Ok.

Ok, great. That deals with all my comments. Let's see if anyone else has additional comments on the status code. I'm ok with leaving it as it is, reusing some of the codes from leasequery or defining a new one.

Cheers,
Tomek