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

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

BTW - we really should be referencing
draft-ietf-dhc-dhcpv6-stateful-issues-00. I hope that is the draft that
you looked at.

 

> I wanted to clarify that with this text, we implicitly mean that
client can only be associated with one server at a time. 

 

We are pretty much saying that, per interface, a client is associated
with one server. There isn't anything to prohibit multiple servers, but
without some additional work (which I mentioned at the DHC WG meeting in
Paris) to support multiple administrative domains, it is not possible
for a client to know whether it is in ONE or MULTIPLE administrative
domains. And, in probably 99.9% of the cases, it is in a SINGLE
administrative domain. So, let's make sure that things work well in that
environment before worrying about the 0.1% (perhaps I should have said
99% and 1% based on the recent "Occupy" movements).

 

1.       Does it need to wait for the next renew time to get expired
before it can ask IA_PD along.? 

 

Yes. Best practice is that it should renew early and renew what it has
and also ask for the IA_PD. But, the client may also "restart" by doing
a Solicit (for IA_NA and IA_PD) - I think the renew is best though. The
only negative with starting with the Renew is that you don't really want
to wait until T2 to find another server if the original server is down.
So we might want to think some more about whether the retransmission
rules should be different.

 

2.       So are we saying that it should not send SOLICIT for IA_PD
anytime in between.? If we are still allowing SOLICIT, should it only
accept ADVERTISE from the server (which initially gave IA_NA) 

 

No - we are not disallowing this. We are saying that Renew is OK to get
new bindings. If client sends Solicit, it can accept whatever
Advertisement it likes (per the "rules" in RFC 3315/3633). 

 

We might need an additional section in the draft to specify this
behavior.

 

-          Bernie

 

From: Gaurav Halwasia (ghalwasi) 
Sent: Friday, May 25, 2012 4:10 AM
To: Bernie Volz (volz); '[e-mail]'
Subject: RE: [dhcwg] Comments on
draft-troan-dhc-dhcpv6-stateful-issues-00

 

Thanks Bernie for clarification.
 
<snip>
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).

</snip>

 

[Gaurav] I don't see any harm in including not assigned IA_'s in
subsequent renew and rebind.  I wanted to clarify that with this text,
we implicitly mean that client can only be associated with one server at
a time.  So we are saying that we can not have a deployment where 2
dhcpv6 servers (one doing IA_NA and other doing IA_PD) can be present.
Also what if client first did IA_NA and at any later point of time it
wants to do IA_PD. 

1.       Does it need to wait for the next renew time to get expired
before it can ask IA_PD along.? 

2.       So are we saying that it should not send SOLICIT for IA_PD
anytime in between.? If we are still allowing SOLICIT, should it only
accept ADVERTISE from the server (which initially gave IA_NA) 

 

Thanks,

Gaurav

From: Bernie Volz (volz) 
Sent: Friday, May 25, 2012 1:00 AM
To: Gaurav Halwasia (ghalwasi); [e-mail]
Subject: RE: [dhcwg] Comments on
draft-troan-dhc-dhcpv6-stateful-issues-00

 

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