Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm

From: Huan Huan <[email-masked]>
Date: Wed, 15 Feb 2012 09:12:40 +0800

Hi Tim,

I think CE Router may transmit Confirm msg containing the assigned IA_NA
and Renew msg containing the assigned IA_PD separately.

BR,
Huan

2012/2/15 <[email-masked]>

> If you have received this digest without all the individual message
> attachments you will need to update your digest options in your list
> subscription.  To do so, go to
>
> https://www.ietf.org/mailman/listinfo/dhcwg
>
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this option
> globally for all the list digests you receive at this point.
>
>
>
> Send dhcwg mailing list submissions to
>        [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://www.ietf.org/mailman/listinfo/dhcwg
> or, via email, send a message with subject or body 'help' to
>        [email-masked]
>
> You can reach the person managing the list at
>        [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dhcwg digest..."
>
>
> Today's Topics:
>
>   1. I-D Action: draft-ietf-dhc-forcerenew-nonce-04.txt
>      ([email-masked])
>   2. DHCP Renew vs Confirm (Timothy Winters)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 14 Feb 2012 02:40:41 -0800
> From: [email-masked]
> To: [email-masked]
> Cc: [email-masked]
> Subject: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-04.txt
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="utf-8"
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Dynamic Host Configuration
> Working Group of the IETF.
>
>        Title           : Forcerenew Nonce Authentication
>        Author(s)       : David Miles
>                          Wojciech Dec
>                          James Bristow
>                          Roberta Maglione
>        Filename        : draft-ietf-dhc-forcerenew-nonce-04.txt
>        Pages           : 12
>        Date            : 2012-02-14
>
>   Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows for the
>   reconfiguration of a single host by forcing the DHCP client into a
>   Renew state on a trigger from the DHCP server.  In Forcerenew Nonce
>   Authentication the server sends a nonce to the client on the initial
>   DHCP ACK that is used for subsequent validation of a FORCERENEW
>   message.  This document updates RFC 3203.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-04.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-04.txt
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 14 Feb 2012 08:43:50 -0500
> From: Timothy Winters <[email-masked]>
> To: [email-masked]
> Subject: [dhcwg] DHCP Renew vs Confirm
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=us-ascii
>
> Hello,
>        While testing some CE Router implementations we have noticed a
> interesting behavior that is within the specifications but not clearly
> documented.  I wanted to get the working group thoughts on this.
>
>        Currently when a CE Router acting as a DHCP client, assigned both
> IA_NA and IA_PD, is unplugged from the network.  When reattached to the
> link the DHCP client transmits a DHCP Renew containing both the IA_NA and
> the IA_PD.
>
>        3315 Section 18.1.2 says that when link goes down a DHCP client
> implementation should transmit a DHCP Confirm message containing the
> assigned IA_NA.
>
>        3633 Section 12.1 doesn't allow the use of the Confirm message.  It
> states that DHCP Renew message, containing the assigned IA_PD, should be
> used when the link goes down.
>
>        According to the specifications a DHCP client should retransmit
> DHCP Confirm and DHCP Renew when link goes up.   The behavior we are seeing
> is the DHCP client transmits a DHCP renew containing both the IA_NA and
> IA_PD.
>
>        This behavior isn't causing interoperability issues as all the
> servers we have tried still respond properly to the DHCP Renew messages.
>
>        Is it ok when a DHCP client loses link for it to transmit one DHCP
> Renew message?
>
> Regards,
> Tim
> UNH-IOL
>
>
>
> ------------------------------
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>
> End of dhcwg Digest, Vol 94, Issue 13
> *************************************
>

-- 
Huan Huan

---

From: Timothy Winters <[email-masked]>
Date: Tue, 14 Feb 2012 20:19:41 -0500

Hi Huan,
      Is it ok to transmit just a Renew message containing both the IA_NA and IA_PD when the link goes down?

Regards,
Tim

On Feb 14, 2012, at 8:12 PM, Huan Huan <[email-masked]> wrote:

> Hi Tim,
> 
> I think CE Router may transmit Confirm msg containing the assigned IA_NA and Renew msg containing the assigned IA_PD separately.
> 
> BR,
> Huan 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.
> 
>        While testing some CE Router implementations we have noticed a interesting behavior that is within the specifications but not clearly documented.  I wanted to get the working group thoughts on this.
> 
>        Currently when a CE Router acting as a DHCP client, assigned both IA_NA and IA_PD, is unplugged from the network.  When reattached to the link the DHCP client transmits a DHCP Renew containing both the IA_NA and the IA_PD.
> 
>        3315 Section 18.1.2 says that when link goes down a DHCP client implementation should transmit a DHCP Confirm message containing the assigned IA_NA.
> 
>        3633 Section 12.1 doesn't allow the use of the Confirm message.  It states that DHCP Renew message, containing the assigned IA_PD, should be used when the link goes down.
> 
>        According to the specifications a DHCP client should retransmit DHCP Confirm and DHCP Renew when link goes up.   The behavior we are seeing is the DHCP client transmits a DHCP renew containing both the IA_NA and IA_PD.
> 
>        This behavior isn't causing interoperability issues as all the servers we have tried still respond properly to the DHCP Renew messages.
> 
>        Is it ok when a DHCP client loses link for it to transmit one DHCP Renew message?
> 
> Regards,
> Tim
> UNH-IOL
> 
> 
>

---

From: Huan Huan <[email-masked]>
Date: Thu, 16 Feb 2012 09:55:45 +0800

I don't think so.

2012/2/15 Timothy Winters <[email-masked]>

>>        3633 Section 12.1 doesn't allow the use of the Confirm message.
>>  It states that DHCP Renew message, containing the assigned IA_PD, should
>> be used when the link goes down.
>>

-- 
Huan Huan

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 15 Feb 2012 21:29:46 -0600

I don't really see what's wrong with EITHER a REBIND or CONFIRM (or even
both, one for IA_PD and one for address). Not really sure why RFC 3633
didn't permit a Confirm.

However, if one does a strict read of the standards, the two (Confirm
for address, Renew for PD) is what a  client SHOULD do.

But, there's no reason a prefix can't be confirmed just as easily as an
address.

Perhaps Ole had a reason for this in RFC 3633, but alas it is not
documented (at least that I could see).

And, a Rebind (for an address) at any time isn't really "wrong".

For a compliance test, you are probably forced to follow the standards
as that is the only thing that you can assure (a server may be strict in
following RFC 3633 and consider a Confirm with prefixes "wrong"). (Cisco
Network Registrar will deal with all of the possibilities.)

-          Bernie

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Huan Huan
Sent: Wednesday, February 15, 2012 8:56 PM
To: Timothy Winters
Cc: [email-masked]
Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm

I don't think so.

Hi Huan,

      Is it ok to transmit just a Renew message containing both the
IA_NA and IA_PD when the link goes down?

Regards,

Tim

	Hi Tim,

	I think CE Router may transmit Confirm msg containing the
assigned IA_NA and Renew msg containing the assigned IA_PD separately.

	BR,

	Huan 

	If you have received this digest without all the individual
message
	attachments you will need to update your digest options in your
list
	subscription.  To do so, go to

	Click the 'Unsubscribe or edit options' button, log in, and set
"Get
	MIME or Plain Text Digests?" to MIME.  You can set this option
	globally for all the list digests you receive at this point.

	

	When replying, please edit your Subject line so it is more
specific
	than "Re: Contents of dhcwg digest..."

	Today's Topics:

	
	
	Message: 1
	Date: Tue, 14 Feb 2012 02:40:41 -0800
	From: [email-masked]
	To: [email-masked]
	Cc: [email-masked]
	Subject: [dhcwg] I-D Action:
draft-ietf-dhc-forcerenew-nonce-04.txt
	Message-ID:
<[email-masked]>
	Content-Type: text/plain; charset="utf-8"

	A New Internet-Draft is available from the on-line
Internet-Drafts directories. This draft is a work item of the Dynamic
Host Configuration Working Group of the IETF.

	  Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows
for the
	  reconfiguration of a single host by forcing the DHCP client
into a
	  Renew state on a trigger from the DHCP server.  In Forcerenew
Nonce
	  Authentication the server sends a nonce to the client on the
initial
	  DHCP ACK that is used for subsequent validation of a
FORCERENEW
	  message.  This document updates RFC 3203.

http://www.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-04.t
xt

	
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-forcerenew-nonce-04.tx
t

	
	Message: 2
	
	Hello,
	       While testing some CE Router implementations we have
noticed a interesting behavior that is within the specifications but not
clearly documented.  I wanted to get the working group thoughts on this.
	
	       Currently when a CE Router acting as a DHCP client,
assigned both IA_NA and IA_PD, is unplugged from the network.  When
reattached to the link the DHCP client transmits a DHCP Renew containing
both the IA_NA and the IA_PD.
	
	       3315 Section 18.1.2 says that when link goes down a DHCP
client implementation should transmit a DHCP Confirm message containing
the assigned IA_NA.
	
	       3633 Section 12.1 doesn't allow the use of the Confirm
message.  It states that DHCP Renew message, containing the assigned
IA_PD, should be used when the link goes down.
	
	       According to the specifications a DHCP client should
retransmit DHCP Confirm and DHCP Renew when link goes up.   The behavior
we are seeing is the DHCP client transmits a DHCP renew containing both
the IA_NA and IA_PD.
	
	       This behavior isn't causing interoperability issues as
all the servers we have tried still respond properly to the DHCP Renew
messages.
	
	       Is it ok when a DHCP client loses link for it to transmit
one DHCP Renew message?
	
	Regards,
	Tim
	UNH-IOL

	

	

	-- 
	Huan Huan

-- 
Huan Huan

---

From: Timothy Winters <[email-masked]>
Date: Wed, 15 Feb 2012 23:53:19 -0500

Hi Bernie,
	I asked Ole about this at V6 World Congress last week, and he mentioned that it wasn't in RFC 3633 because Confirm is for detecting on-link confirmation.   It's possible I misunderstood him, if so he can feel free to jump in.

	As you point out RFC 3315 doesn't prevent an implementation from transmitting a Renew message when this happens.   So they are within the specification for transmitting the Renew message.  The missing piece is that we have DHCP clients, in this case CE Routers, that don't transmit Confirm messages. RFC 3315 states a Confirm message should happen when a device may have moved to another link, so unplugging the physical link should cause a DHCP Confirm message when plugged back in.  

	Is a DHCP Client not following RFC 3315 if they don't transmit a DHCP Confirm message? 

Regards,
Tim

On Feb 15, 2012, at 10:29 PM, Bernie Volz (volz) wrote:

> I don’t really see what’s wrong with EITHER a REBIND or CONFIRM (or even both, one for IA_PD and one for address). Not really sure why RFC 3633 didn’t permit a Confirm.
>  
> However, if one does a strict read of the standards, the two (Confirm for address, Renew for PD) is what a  client SHOULD do.
>  
> But, there’s no reason a prefix can’t be confirmed just as easily as an address.
>  
> Perhaps Ole had a reason for this in RFC 3633, but alas it is not documented (at least that I could see).
>  
> And, a Rebind (for an address) at any time isn’t really “wrong”.
>  
> For a compliance test, you are probably forced to follow the standards as that is the only thing that you can assure (a server may be strict in following RFC 3633 and consider a Confirm with prefixes “wrong”). (Cisco Network Registrar will deal with all of the possibilities.)
> -          Bernie
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Huan Huan

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 15 Feb 2012 23:13:37 -0600

>          I asked Ole about this at V6 World Congress last week, and he
mentioned that it wasn't in RFC 3633 because Confirm is for detecting
on-link confirmation.   It's possible I misunderstood him, if so he can
feel free to jump in.

   Any responding servers will indicate whether those

   addresses are appropriate for the link to which the client is

   attached with the status in the Reply message it returns to the

   client.

...

   NotOnLink       4 The prefix for the address is not appropriate for

                     the link to which the client is attached.

I disagree as the RFC 3315 text never says "on-link" in the strict sense
of what "on-link" means for IPv6. It says "appropriate for the link".
The status code is "NotOnLink" but that is something that is definitive
in the case when a delegate prefix is not 'appropriate' for the link. I
believe Ralph was purposely careful in the language used in RFC 3315
that we didn't imply that an address was "on-link" in the sense of the L
bit for ND.

I don't remember the timing of the documents and work on RFC 3633 might
have started before RFC 3315 was finalized and perhaps an earlier 3315
draft had some different terminology which was more directly tied to
"on-link". (Given that the RFC publication dates are only 6 months
apart, I suspect they were worked on in parallel. While the IETF process
was faster back then, it was never that fast.)

>          Is a DHCP Client not following RFC 3315 if they don't
transmit a DHCP Confirm message? 

   In any situation when a client may have moved to a new link, the

   client MUST initiate a Confirm/Reply message exchange.  

Thus, a strict read of RFC 3315 says it is required (MUST - not SHOULD).

Perhaps the above are items for -bis documents if they are ever done.
Or, a new draft might want to propose a reconsidering of these issues?

-          Bernie

From: Timothy Winters [mailto:[email-masked]] 
Sent: Wednesday, February 15, 2012 11:53 PM
To: Bernie Volz (volz)
Cc: Huan Huan; [email-masked]
Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm

Hi Bernie,

            I asked Ole about this at V6 World Congress last week, and
he mentioned that it wasn't in RFC 3633 because Confirm is for detecting
on-link confirmation.   It's possible I misunderstood him, if so he can
feel free to jump in.

            As you point out RFC 3315 doesn't prevent an implementation
from transmitting a Renew message when this happens.   So they are
within the specification for transmitting the Renew message.  The
missing piece is that we have DHCP clients, in this case CE Routers,
that don't transmit Confirm messages. RFC 3315 states a Confirm message
should happen when a device may have moved to another link, so
unplugging the physical link should cause a DHCP Confirm message when
plugged back in.  

            Is a DHCP Client not following RFC 3315 if they don't
transmit a DHCP Confirm message? 

Regards,

Tim

-          Bernie

I don't think so.

Hi Huan,

Regards,

Tim

	Hi Tim,

	BR,

	Huan 

	

	

	

	Today's Topics:

	
	
	Message: 1

	

	

	
	
	Message: 2
	
	Hello,

	

	
	
	Regards,
	Tim
	UNH-IOL

	

	

	-- 
	Huan Huan

-- 
Huan Huan

---

From: Huan Huan <[email-masked]>
Date: Thu, 16 Feb 2012 13:41:36 +0800

I agree with Bernie's option "a server may be strict in following RFC 3633
and consider a Confirm with prefixes “wrong”", maybe this either Renew or
Confirm causing an interoperability issue.

2012/2/16 Bernie Volz (volz) <[email-masked]>

> I don’t really see what’s wrong with EITHER a REBIND or CONFIRM (or even
> didn’t permit a Confirm.****
>
> ** **
>
> However, if one does a strict read of the standards, the two (Confirm for
> ayinqiddress, Renew for PD) is what a  client SHOULD do.****
>
> ** **
>
> But, there’s no reason a prefix can’t be confirmed just as easily as an
> address.****
>
> ** **
>
> documented (at least that I could see).****
>
> ** **
>
> And, a Rebind (for an address) at any time isn’t really “wrong”.****
>
> ** **
>
> For a compliance test, you are probably forced to follow the standards as
> that is the only thing that you can assure (a server may be strict in
> following RFC 3633 and consider a Confirm with prefixes “wrong”). (Cisco
> Network Registrar will deal with all of the possibilities.)****
>
> ****
>
> **-          **Bernie****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Huan Huan
> *Sent:* Wednesday, February 15, 2012 8:56 PM
> *To:* Timothy Winters
> *Cc:* [email-masked]
> *Subject:* Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm****
>
> ** **
>
> I don't think so.****
>
> ** **
>
> 2012/2/15 Timothy Winters <[email-masked]>****
>
> Hi Huan,****
>
>       Is it ok to transmit just a Renew message containing both the IA_NA
> and IA_PD when the link goes down?****
>
> ** **
>
> Regards,****
>
> Tim****
>
>
>
> On Feb 14, 2012, at 8:12 PM, Huan Huan <[email-masked]> wrote:****
>
> Hi Tim,****
>
> ** **
>
> and Renew msg containing the assigned IA_PD separately.****
>
> ** **
>
> BR,****
>
> Huan ****
>
> 2012/2/15 <[email-masked]>****
>
> *****************************************
>
>
>
> ****
>
> ** **
>
> --
> Huan Huan****
>
>
>
> ****
>
> ** **
>
> --
> Huan Huan****
>

-- 
Huan Huan

---

From: Ole Trøan <[email-masked]>
Date: Thu, 16 Feb 2012 08:45:50 +0100

Bernie, Tim,

> …
> I disagree as the RFC 3315 text never says “on-link” in the strict sense of what “on-link” means for IPv6. It says “appropriate for the link”. The status code is “NotOnLink” but that is something that is definitive in the case when a delegate prefix is not ‘appropriate’ for the link. I believe Ralph was purposely careful in the language used in RFC 3315 that we didn’t imply that an address was “on-link” in the sense of the L bit for ND.
>  
> I don’t remember the timing of the documents and work on RFC 3633 might have started before RFC 3315 was finalized and perhaps an earlier 3315 draft had some different terminology which was more directly tied to “on-link”. (Given that the RFC publication dates are only 6 months apart, I suspect they were worked on in parallel. While the IETF process was faster back then, it was never that fast.)

let me see if I can recall the rationale.

      CONFIRM (4)        A client sends a Confirm message to any
                         available server to determine whether the
                         addresses it was assigned are still appropriate
                         to the link to which the client is connected.

1) minor point on CONFIRM wording. CONFIRM specifically refers to addresses and appropriateness to a link. delegated prefixes are never appropriate to the link between client and server.

2) a confirm message can be replied to by _any_ DHCP server, regardless of that server having the binding or not. as there is no way for a server without a binding to know if a prefix is "appropriate" or not, we wanted to ensure that only the server with the binding would reply. thus we had to use RENEW.

cheers,
Ole

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 16 Feb 2012 07:27:29 -0500

Ole:

3315 only handles address so not surprise about its wording.

Confirm supports three possabilities - ok, not ok, can't say. And PD is usually done by delegating from a shorter prefix so the appropriate test can be applied then. Yes, there may be situations where that is not done and then a server might not be able to provide an answer.

Agree that Confirm is weaker as it provides no answer as to whether the information is valid for "that" client - just that the client is most likely still connected to where it was previously.

- Bernie

Sent from my iPad

---

From: Ole Trøan <[email-masked]>
Date: Thu, 16 Feb 2012 13:40:49 +0100

Bernie,

> 3315 only handles address so not surprise about its wording.

the unfortunate artifact of 3315 is that the message types are also very specific to handing out addresses.
being a "prefix man" I feel discriminated against. ;-)

> Agree that Confirm is weaker as it provides no answer as to whether the information is valid for "that" client - just that the client is most likely still connected to where it was previously.

with only an IA_PD I don't see any way that a server without the binding can give even a guess. just because the delegated prefix comes out of a /32 for that ISP, that the DHCP server knows about, says nothing if it has moved or not.
DHCP PD depends on route injection of the first-hop router, and most implementations depends on DHCP for that to work.

we're really back to how should DHC handle multiple stateful options. fix the message types and text to be more general. or threat multiple stateful options as separate protocol instances.

cheers,
Ole

---

From: [email-masked]
Date: Thu, 16 Feb 2012 15:30:47 -0500

I'm glad Timothy raised this point. We've hit this exact same issue in our 
lab, along with other issues (I'll send them in a separate thread). 

Ole wrote: 
> we're really back to how should DHC handle multiple stateful options. 
> fix the message types and text to be more general. 
> or threat multiple stateful options as separate protocol instances.

Ole, what do you suggest we do exactly? Change both 3633 to make it 
clearer? How exactly?

The way I see this, in order for an implementation to be compliant on the 
short term, 
it would have to do first a Confirm with the IA_NA, then if it has a valid 
IA_PD, 
initiate a Renew with at least the IA_PD and possibly the IA_NA too. 

Would this make sense? 

JF Tremblay

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 16 Feb 2012 15:17:35 -0600

This issue is tied to the question of what a client that wants IA_NA and
IA_PD should do for the Solicit and all other messages (and what it
should do if it only gets one, not both, requests in that single message
exchange).

RFC 3633 (and RFC 3315) were never written with this clearly defined or
in mind?

It was my fault that Hemant put in the requirement to have the eRouter
do ONE request for both. I regret having suggested this, and will go
back to saying that separate requests are far better.

Someone raised the issue of Option integration in that case. But I would
argue that there is NO option integration issue. The address (IA_NA) and
its options are for ONE usage (communication via the address out the
interface on which the IA_NA was obtained) whereas the prefix (IA_PD)
and its options are for the devices that will be getting prefixes (or
addresses) from the IAPREFIX and thus have NOTHING to do with the IA_NA
request. And, putting all into one exchange really prevents that
meaningful communication (the container option is there to help with
this but it technically could be deemed unnecessary if the requests were
separate).

Someone raised the issue that this adds complexity in the
implementation? Really? Seems that this is already complex and more so
since there are many more twisty little paths to explore and test. Two
much more simple and mostly independent state machines seems far easier
to me (though I am not a client implementer - other than test ones).
Nothing requires these to be separate processes or separate threads -
just two state machines however you want to implement them.

Ralph and Ole have asked me to consider writing a problem statement I-D
for this issue and I haven't yet decided if I will - as it seems clear
to me that while the extra exchange costs some additional bits on the
wire and perhaps some added latency, I still think that separate is the
better way to go.

Then the issue of whether Confirm is allowed for PD (or Renew instead of
Confirm for IA) goes away [follow the RFCs] and we can also clean up our
implementations over time to be compliant. The documents are clear on
these issue in the single type context.

Future IA_* types will need to be clear about whether they are or are
not allowed with other IA_* types in a single message.

The way I see this, in order for an implementation to be compliant on
the short term, 
it would have to do first a Confirm with the IA_NA, then if it has a
valid IA_PD, 
initiate a Renew with at least the IA_PD and possibly the IA_NA too.

Probably if we don't recommend splitting things up (or to make smaller
fixes to current implementations), that would be the way to go (not sure
why there would need to be a delay on the Renew). Confirm might come
back with Success and Renew might fail (since another server handled the
Confirm and Renewing server was no up). This would give the device an
indication that it is probably still on the same link.

-          Bernie

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Thursday, February 16, 2012 3:31 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm

I'm glad Timothy raised this point. We've hit this exact same issue in
our lab, along with other issues (I'll send them in a separate thread). 

The way I see this, in order for an implementation to be compliant on
the short term, 
it would have to do first a Confirm with the IA_NA, then if it has a
valid IA_PD, 
initiate a Renew with at least the IA_PD and possibly the IA_NA too. 

Would this make sense? 

JF Tremblay

---

From: Ole Trøan <[email-masked]>
Date: Fri, 17 Feb 2012 12:02:35 +0100

Bernie,

1. Single session
  - assumes a link is connected to a single "provisioning domain". all servers should have the same
    policy, and if not it is a configuration error.
  - implies that 3315/3633 is rewritten so that DHCP message types are made independent
    of stateful option type (e.g. CONFIRM only applying to addresses)

2. One session per stateful option
  - how does a client merge the redundant / conflicting stateless options?
    e.g if only PD + stateless options, is that going to be used also for the "host" functions?
    given that the PD also is used to configure addresses on the device.
  - where both IA_NA and IA_PD is requested but only PD given,
    will result in clients soliciting forever
    what if client also wants IA_TA?
  - allows different "provisioning domains" per stateful option?
  - results in multiple bindings per client, and presumably multiple RECONFIGURE messages
    per session

doesn't (2) encourage not only separate instances of the state machine, but different state machines altogether?
with different T1/T2 timers and different meaning of message types, we're there already? argh, I don't think we intended to create a different flavour of DHCP with RFC3633.

cheers,
Ole

On Feb 16, 2012, at 22:17 , Bernie Volz (volz) wrote:

> This issue is tied to the question of what a client that wants IA_NA and IA_PD should do for the Solicit and all other messages (and what it should do if it only gets one, not both, requests in that single message exchange).
>  
> RFC 3633 (and RFC 3315) were never written with this clearly defined or in mind?
>  
> It was my fault that Hemant put in the requirement to have the eRouter do ONE request for both. I regret having suggested this, and will go back to saying that separate requests are far better.
>  
> Someone raised the issue of Option integration in that case. But I would argue that there is NO option integration issue. The address (IA_NA) and its options are for ONE usage (communication via the address out the interface on which the IA_NA was obtained) whereas the prefix (IA_PD) and its options are for the devices that will be getting prefixes (or addresses) from the IAPREFIX and thus have NOTHING to do with the IA_NA request. And, putting all into one exchange really prevents that meaningful communication (the container option is there to help with this but it technically could be deemed unnecessary if the requests were separate).
>  
> Someone raised the issue that this adds complexity in the implementation? Really? Seems that this is already complex and more so since there are many more twisty little paths to explore and test. Two much more simple and mostly independent state machines seems far easier to me (though I am not a client implementer – other than test ones). Nothing requires these to be separate processes or separate threads – just two state machines however you want to implement them.
>  
> Ralph and Ole have asked me to consider writing a problem statement I-D for this issue and I haven’t yet decided if I will – as it seems clear to me that while the extra exchange costs some additional bits on the wire and perhaps some added latency, I still think that separate is the better way to go.
>  
> Then the issue of whether Confirm is allowed for PD (or Renew instead of Confirm for IA) goes away [follow the RFCs] and we can also clean up our implementations over time to be compliant. The documents are clear on these issue in the single type context.
>  
> Future IA_* types will need to be clear about whether they are or are not allowed with other IA_* types in a single message.
>  
>  
> The way I see this, in order for an implementation to be compliant on the short term, 
> it would have to do first a Confirm with the IA_NA, then if it has a valid IA_PD, 
> Probably if we don’t recommend splitting things up (or to make smaller fixes to current implementations), that would be the way to go (not sure why there would need to be a delay on the Renew). Confirm might come back with Success and Renew might fail (since another server handled the Confirm and Renewing server was no up). This would give the device an indication that it is probably still on the same link.
>  
> -          Bernie
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> I'm glad Timothy raised this point. We've hit this exact same issue in our lab, along with other issues (I'll send them in a separate thread). 
> 
> Ole wrote: 
> Ole, what do you suggest we do exactly? Change both 3633 to make it clearer? How exactly? 
> 
> The way I see this, in order for an implementation to be compliant on the short term, 
> it would have to do first a Confirm with the IA_NA, then if it has a valid IA_PD,