Re: [dhcwg] Clarification in http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues-06

[Khurram Mohammed <[e-mail]>]

Thanks Bernie for your feedback. Appreciated very much. Sure, there is no harm in including them, rather I wanted to figure out if there was any other reason in mind (as otherwise NoAddrAvail Status Code msg function seemed redundant) to include it in the PROPOSED SOLUTION in this draft.

Best Regards,
-Khurram

From: Bernie Volz (volz) [mailto:[e-mail]]
Sent: Sunday, 24 August 2014 1:40 AM
To: Khurram Mohammed
Cc: [e-mail]; Marcin Siodelski; [e-mail]
Subject: Re: Clarification in http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues-06

What harm is there in including them? It is also possible that the configuration on the Server changed between the Advertise and Request (though a small chance).

What we are trying to do here is to have the client continue to request (renew) with ALL IA_* options, even those it did not receive in an Advertise.

Of course the client should include the Advertised IA_* options - that is already in the text in RFC 3315. We are documenting the changed actions in the draft. And this is not 'replacement' text for RFC 3315bis. It is documenting the PROPOSED SOLUTION.

- Bernie

From: Khurram Mohammed <[e-mail]<mailto:[e-mail]>>
Date: Thursday, August 21, 2014 at 8:40 AM
To: Cisco Employee <[e-mail]<mailto:[e-mail]>>
Cc: Ole Troan <[e-mail]<mailto:[e-mail]>>, Marcin Siodelski <[e-mail]<mailto:[e-mail]>>
Subject: Re: Clarification in http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues-06

Thanks Bernie.

Shouldn't the text in draft read as 'the client should include the offered IA option types in its Request'?

I just don't see the logic behind including the NOT offered options again towards the server noting if the server already informed the client in ADVERTISE what it can offer eg if server only configured for IA_PD - then if client requesting both IA_NA + IA_PD in Solicit, then server will respond with NoAddrAvail for IA_NA & IA Prefix for IA_PD. Client sending IA_NA & IA_PD in Request will mean server to respond again with NoAddrAvail (which was sent at first place by server in advertise to inform client that server is not offering IA_NA addresses?

-Khurram

Sent from my iPhone

On 21 Aug 2014, at 9:25 pm, "Bernie Volz (volz)" <[e-mail]<mailto:[e-mail]>> wrote:
The client should send the Request with IA_NA and IA_PD. Text says:


   Proposed solution: a client SHOULD accept Advertise messages, even

   when not all IA option types are being offered.  And, in this case,

   the client SHOULD include the not offered IA option types in its

   Request.

- Bernie (from iPad)

On Aug 21, 2014, at 12:59 AM, "Khurram Mohammed" <[e-mail]<mailto:[e-mail]>> wrote:
Hello folks,

I was reading through this draft and had a quick clarification w.r.t section 4.2 (as provided below). Am I right to interpret the draft for the below scenario correctly:


è DHCPv6 Client sends SOLICIT (with IA_NA and IA_PD options) to DHCPv6 Server

è DHCPv6 Server sends ADVERTISE (with NoAddrAvail for IA_NA & IA Prefix for IA_PD) to the DHCPv6 Client

è SHOULD the DHCPv6 Client include ONLY IA_PD in its REQUEST (with IA Prefix for IA_PD) to the DHCPv6 Server?

OR

è SHOULD the DHCPv6 Client restart by sending SOLICIT with only IA_PD option to DHCPv6 server to complete SARR sequence?

Or is the case that both client behaviour are within the RFC 3315 & draft-ietf-dhc-dhcpv6-stateful-issues-06 compliance?
4.2<http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues-06#section-4.2>.  Advertise Message

   [RFC3315] specifies that a client must ignore an Advertise message if

   a server will not assign any addresses to a client.  A client

   requesting both IA_NA and IA_PD, with a server that only offers one

   of them, is not supported in the current protocol specification.



   Proposed solution: a client SHOULD accept Advertise messages, even

   when not all IA option types are being offered.  And, in this case,

   the client SHOULD include the not offered IA option types in its

   Request.  A client SHOULD only ignore an Advertise message when no IA

   option includes any offered addresses or delegated prefixes (or any

   future allocable resource).  Note that ignored messages MUST still be

   processed for SOL_MAX_RT and INF_MAX_RT options as specified in

   [RFC7083<http://tools.ietf.org/html/rfc7083>]

Thanks heaps in advance,

Best Regards,
-Khurram