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

[Huan Huan <[e-mail]>]

Hi all,

I really want to know the end of this issue? Should we need to modify
RFC3633 or we need a new draft?

Regards,

Huan

2012/2/16 Bernie Volz (volz) <[e-mail]>

> >          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:[e-mail]]
> *Sent:* Wednesday, February 15, 2012 11:53 PM
> *To:* Bernie Volz (volz)
> *Cc:* Huan Huan; [e-mail]
>
> *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****
>
> ** **
>
> 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:* [e-mail] [mailto:[e-mail]] *On Behalf
> Of *Huan Huan
> *Sent:* Wednesday, February 15, 2012 8:56 PM
> *To:* Timothy Winters
> *Cc:* [e-mail]
> *Subject:* Re: [dhcwg] dhcwg Digest, DHCP Renew vs Confirm****
>
>  ****
>
> I don't think so.****
>
>  ****
>
> 2012/2/15 Timothy Winters <[e-mail]>****
>
> 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 <[e-mail]> 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 ****
>
> 2012/2/15 <[e-mail]>****
>
> 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
>        [e-mail]
>
> 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
>        [e-mail]
>
> You can reach the person managing the list at
>        [e-mail]
>
> 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
>      ([e-mail])
>   2. DHCP Renew vs Confirm (Timothy Winters)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 14 Feb 2012 02:40:41 -0800
> From: [e-mail]
> To: [e-mail]
> Cc: [e-mail]
> Subject: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-04.txt
> Message-ID: <[e-mail]>
> 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 <[e-mail]>
> To: [e-mail]
> Subject: [dhcwg] DHCP Renew vs Confirm
> Message-ID: <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>
> End of dhcwg Digest, Vol 94, Issue 13
> *****************************************
>
>
>
> ****
>
>  ****
>
> --
> Huan Huan****
>
>
>
> ****
>
>  ****
>
> --
> Huan Huan****
>
> ** **
>



-- 
Huan Huan