Re: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00

["Bernie Volz (volz)" <[e-mail]>]

Hi and thanks for reading and commenting!

 

Comments below (BV>).

 

-          Bernie

 

From: [e-mail] [mailto:[e-mail]] On Behalf
Of Gaurav Halwasia (ghalwasi)
Sent: Thursday, May 24, 2012 11:03 AM
To: [e-mail]
Subject: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00

 

I have read this informational draft and I have couple of comments so
far.

 

1.)Section 3.1

   Replace Section 17.1.3
<http://tools.ietf.org/html/draft-troan-dhc-dhcpv6-stateful-issues-00#se
ction-17.1.3> : (existing errata)
 
 
      The client MUST ignore any Advertise message that includes a
Status
      Code option containing the value NoAddrsAvail, with the exception
      that the client MAY display the associated status message to the
      user.
 
   With:
 
 
      The client MUST ignore any IAs in an Advertise message that
      includes a Status Code option containing the value NoAddrsAvail,
      with the exception that the client MAY display the associated
      status message to the user. An Advertise message without any IA
      options MUST be ignored.

 

Is this only applicable to IA_NA.? I guess in case client sends SOLICIT
with both IA_NA and IA_PD. Then in that case I guess we should mention
"NoPrefixAvail" as well.
 
BV> It is applicable to IA_NA and IA_TA as those are the cases that end
up with the Status Code option of NoAddsAvailable in the "main" part of
the message - not in each IA_NA/IA_TA. (IA_PD puts the NoPrefixAvail
Status Code option in the IA_PD itself. This is what we wish had been
specified for IA_NA/IA_TA but was not.)
 
2.) Section 3.6
   Proposed solution: the client should keep a single session with the
   server.  The client should continue with the IA_ options received,
   while continuing to request the other IA options in subsequent
   messages to the server.  That means continue to include the empty
   unanswered IAs in subsequent Renew and Rebind messages.
 
I believe, it is possible that a particular server is willing to offer
only a subset of IA_'s which has been requested. In that case, what's
the use of including the other IA_ in the subsequent renew/rebind. As in
this case server will anyway only renew only one IA_. ? Are we
suggesting that a client at any given point of time should only be
talking to one server after the advertise is accepted.
 
BV> What harm is there in continuing to include this in the subsequent
operations? If the server's policy prohibits returning addresses or
delegated prefixes for these other IA types, there is no harm. The main
assumption is that clients are in a single administrative domain and
thus talking to another server will be unlikely to help (except of
course in the case of misconfiguration, but better that the issue is
detected early and dealt with).
 
-          Bernie