Subject: [dhcwg] comments on draft-ietf-dhc-dhcpv6-stateful-issues-05

From: 神明達哉 <[email-masked]>
Date: Wed, 12 Feb 2014 13:25:16 -0800

I've read the latest version of the draft.

First, I have some higher level comments and questions:

- I agree that it's a good idea to clarify/generalize the
  concept of IA so we can handle multiple types of IAs at the same
  time.  But at the same time, I wonder for what a DHCP client would
  want to request both IA_NA (or IA_TA) and IA_PD at the same time.
  Is there any specific need for that in practice?  Requesting both
  IA_NA and IA_TA at the same time seem to be a more likely need to
  me, btw, and, if only in that sense I see the value of the attempt
  of clarification and extension.

- I'm not sure if it's the best approach to consider all types of IAs
  as a set (if I understand it correctly, that's what this draft
  basically proposes, right?).  For example, assume a client wants to be
  assigned IA_NA and IA_TA but ends up with accepting an Advertise
  only containing IA_NA.  Then I suspect it's very unlikely IA_TA is
  now magically assigned in response to the subsequent Request (but
  I'm okay with this point; there doesn't seem to be any viable option
  for the client in this situation anyway, and the overhead in this
  Request and Reply would be marginal).  And the client needs to wait
  until time T1 before retrying the assignment of IA_TA.  If the
  unavailability of IA_TA is a temporary event and T1 is relatively
  large (e.g., hours or longer), that wouldn't be really good.

- (Slightly related to the previous point) The idea of considering
  T1/T2 to be "protocol timers" (per Section 4.3) is not really
  well-applicable to IA_TA since IA_TA is inherently free from
  renewal.  We could treat IA_TA as a special case for the general
  concept of "protocol timers", but if we are trying to generalize the
  concept of "stateful resources", I suspect we should rather expect
  such exceptional cases.

Considering these, I wonder it may make sense to handle different IAs
in dedicated different states, but still in the same single DHCPv6
"session".  For example, once a specific server is chosen after a
Solicit-Advertise (+ possibly Request-Reply) exchange, each IA is
maintained in its own state.  Some may involve renewal process, and
not-yet-assigned IAs can be Request-ed again after some reasonable
delay.  One tricky case with this approach is, though, when the server
stops responding to Renew and an IA needs Rebind.  We then need to
consider what to do with other IAs.

I'm not necessarily insisting on this is clearly better than the
currently described approach in the draft, but my main point is that
pros and cons are not so obvious (to me) and we'll probably need some
more discussion at this level.

Some specific comments (mostly minor) on the draft text follow:

- Section 4.1: shouldn't this SHOULD be a "MUST"?

   when not all IA option types are being offered.  A client SHOULD
   ignore an Advertise message when no bindings at all are being
   offered.

  Since in the proposed replace text it states:

     The client MUST ignore any Advertise message that contains no
     bindings (if only IA_NA and/or IA_TA options were requested,

- In Section 4.4

   With:

     At time T1 for an IA, the client initiates a Renew/Reply message
     exchange to extend the lifetimes on any addresses in the IA.  The
     client includes an IA option with all addresses currently assigned
     to the IA in its Renew message. The client also includes an IA
     option for each binding it desires but has been unable to obtain.

  Should phrases like "any addresses" be generalized so they'll be
  applicable to other types of stateful resources?  From the
  replacement of "available addresses" with "available options" in the
  proposed text in Section 4.1, I thought such generalization was one
  goal of the replacement text.  Same sense of comments apply to some
  other places of the draft (e.g., in the "With" text of Section 4.5).

- Also in Section 4.4: s/records/returns/?

     If the server cannot find a client entry for the IA the server
     creates the bindings for that client according to the server's
     policy and configuration information and records the IAs and
     other information requested by the client.

  and s/which is does/which it does/?

   these IAs.  However, it MUST limit the frequency at which is does
   this to no more often than the renewal frequency.

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 12 Feb 2014 21:56:20 +0000

JINMEI:

Many thanks for the careful review!!!

Some comments below inline (BV>).

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
Sent: Wednesday, February 12, 2014 4:25 PM
To: [email-masked]
Cc: [email-masked]
Subject: comments on draft-ietf-dhc-dhcpv6-stateful-issues-05

BV> Home gateways (such in Cable, DOCSIS) typically do request an IA_NA and IA_PD - the IA_NA is for use by the gateway itself whereas the IA_PD is for the prefix within the home (typically stateless is used within the home).

BV> The IA_NA/IA_TA case was actually "probably" already handled in RFC 3315 though I suspect we could improve this. This is more about interacting with IA_PD. The case where IA_TAs aren't provided just means that the client won't have any DHCP assigned temporary addresses and may either generate its own (if allowed) or will be restricted from using temporary addresses. An IA_TA is more likely requested on demand or periodically when the previous one becomes non-preferred. This is probably a case where a separate DHCPv6 transaction is warranted and appropriate.

BV> I agree though that we should expand the document to discuss this a bit more - again, the focus of the work was really IA_NA + IA_PD.

BV> We might even propose to DEPRECATE IA_TA as there's probably little value in it for DHCPv6 assigned addresses. This grew out of the original privacy concerns for EUI-64 mac address based addresses in IPv6 and DHCPv6 assigned addresses shouldn’t normally have these privacy concerns (you might get the same address each time you connect at work, but that won't be related to the one that you get at home or when in your favorite coffee shop).

BV> Surprising RFC 3315 DOES allow IA_TA to be renewed (see RFC 3315, section 22.5). But in any case, I agree with you that we need to discuss this more thoroughly. Or, at indicate that the stateful issues draft is mostly about IA_NA + IA_PD and leave IA_TA "out" (perhaps taken up for 3315bis work). But I suspect best to address it in this document.

BV> I'll have to think about this some more, but I think IA_TA are a bit separate and should be more independent than the IA_NA/IA_PD (for things like the Cable home gateways).

BV> I think we should revisit this now that SOLMAX RFC (7083) is out as this changes this text anyway. When this was written, SOLMAX was still a draft and thus wasn't considered. But the updated text now should include the RFC 7083 change -- see section 6 of RFC 7083.

- In Section 4.4

   With:

BV> Yes, good catch - we need to replace "addresses" with something more generic. Perhaps we can use the term "resources"? Or leases?

BV> I think this "records" refers to the fact that server must record this information? Note that as the server didn't find anything, it needs to store this if it can provide the client the addresses that it claims to be using (because of the Renew).

BV> Yes, this should be fixed.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Thu, 13 Feb 2014 10:11:27 -0800

At Wed, 12 Feb 2014 21:56:20 +0000,

> BV> Home gateways (such in Cable, DOCSIS) typically do request an IA_NA and IA_PD - the IA_NA is for use by the gateway itself whereas the IA_PD is for the prefix within the home (typically statele…

Ah, okay.  Depending on the level of generalization of this document
(see below), it may help if the example usage is mentioned.

>   only containing IA_NA.  [...]
>

Okay, but this particular topic I simply chose IA_NA and IA_TA is just
an example pair of IA_xx and IA_yy.  The same question still applies.

Now, however, as you clarified the main focus: if we're basically only
concerned about the pair of IA_NA and IA_PD, I guess one possibility
is to focus on that specific pair, rather than try to generalize the
concept.  In general it should be better if we can introduce a general
concept of IA_xx's, explain everything in the generalized context and
the case of IA_NA and IA_PD can be just one application of it.  But,
as the example of IA_TA case shows, the generalization will require
considerations on more tricky cases.

I'm not pushing a specific way, but IMO I'd either
- try full generalization that's basically applicable to any current
  and future IA_xx's, or
- just focus on the specific case of IA_NA + IA_PD, exploiting the
  fact of specialization (if that's helpful)

In that sense the current shape of the draft seems to be still
incomplete.

> BV> We might even propose to DEPRECATE IA_TA as there's probably little value in it for DHCPv6 assigned addresses. This grew out of the original privacy concerns for EUI-64 mac address based addresses in IPv6 and DHCPv6 assigned addresses shouldn't normally have these privacy concerns (you might get the same address each time you connect at work, but that won't be related to the one that you get at home or when in your favorite coffee shop).

Possibly, but I think that would be beyond the scope of this
discussion; even if we can assume we deprecate IA_TA, "the full
generalization" approach would still require considerations on such
deviant type of IAs to provide sensible abstraction level.

> BV> Surprising RFC 3315 DOES allow IA_TA to be renewed (see RFC 3315, section 22.5). But in any case, I agree with you that we need to discuss this more thoroughly. Or, at indicate that the statefu…

Ah, okay (about the renewability), but actually that was not the main
point here.  I should have said IA_TA does not have T1/T2 (so it'll be
tricky to define T1/T2 as protocol timers).  And, yes, just focusing
on IA_NA + IA_PD is one option (see above).

> BV> I think we should revisit this now that SOLMAX RFC (7083) is out as this changes this text anyway. When this was written, SOLMAX was still a draft and thus wasn't considered. But the updated te…

Hmm, I'm not sure if we are on the same page.  I just tried to point
out that the draft uses different keywords (SHOULD and MUST) to
explain essentially the same thing and they should be consistent (so
this is more about an editorial matter).

> BV> Yes, good catch - we need to replace "addresses" with something more generic. Perhaps we can use the term "resources"? Or leases?

I'd prefer resources over leases between these, as a "lease" sounds
like a different level of term (it's the available duration for the
assigned address/resource/whatever, while we are thinking about the
assigned "thing" here).  But there may be other better term.  I don't
have a particular preference.

> BV> I think this "records" refers to the fact that server must record this information? Note that as the server didn't find anything, it needs to store this if it can provide the client the address…

Hmm, I thought in this case the IAs in "records the IAs" mean other
IAs than that triggers the Renew.  Also, if this is really "records"
and means the IA that triggers the Renew, why is this plural (the IAs)
while the first occurrence of "IA" is singular?  And, even on a closer
look, I have some more questions...in "If the server cannot find a
client entry for the IA", which IA (there can be multiple of it
because of the extension) is it?  If the Renew contains IA1 and IA2
(e.g., the former triggers Renew due to T1 expiration and IA2 is not
assigned yet), is it possible that "the server cannot find a client
entry for IA1" but "the server *can* find a client entry for IA2"?  If
yes, what should happen in this case?

Note, again, that we don't have to be bothered with these in the
possible alternative approach I mentioned (once the server is chosen,
different IAs are handled separately).

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 13 Feb 2014 20:55:38 +0000

Hi:

First, I think it will be difficult to provide a completely generalized approach to processing of the IAs since IA_TAs are fundamentally very different as they are not generally intended to be renewed and hence have no T1/T2. Also, we have no idea what future IA_* options may be defined and what characteristics they may have. IA_TAs may be needed when other IA_* options are not ready to be renewed.

It is interesting that as RFC 3315 defined both IA_NA and IA_TA, it implies from what you have indicated to have failed in handling these appropriately? I don't know if that has been confirmed by implementation experience or not; it may be that IA_TAs are not widely "used"? 

We have also been discussing terminology (addresses vs resources vs leases). As this document is attempting to update text in RFC 3315, it has stuck to using RFC 3315 terminology. Thus, I think replacing "addresses" with something else is best left to the RFC 3315bis work where we merge RFC 3315/3633. That is one reason why all of the text that updates RFC 3315 has avoided introducing "delegated prefixes", "IA_PD", and anything not in RFC 3315 - we are carefully updating the text without explicitly introducing PD material. I forgot about that issue when I responded earlier. (We do have an open issue to define the terminology to be used in 3315bis.)

---

[Section 4.1]
>this is more about an editorial matter).

OK, sorry I misunderstood. I am not sure when and why that difference crept in (we will use MUST in both places). RFC 7083 does expand on the "MUST ignore" so I should at least add a note in the descriptive text about the 7083 requirements.

>  fact of specialization (if that's helpful)

I think I will favor this approach as this was about IA_NA/IA_PD interaction and not about IA_NA/IA_TA. Again, the RFC 3315 text changes are a bit tricky since it is limited to using RFC 3315 terminology/context.

If you feel there are issues with IA_NA/IA_TA, perhaps you can clarify those and we can treat them as an Errata to RFC 3315 or perhaps work on another document? I am not opposed to including in Stateful Issues if you can provide some clear list of issues and proposed fixes?

Regarding the Section 4.4 issues with the replacement text, I will need to think about that some more and perhaps work in more of the text from the Request processing (18.2.1). The intent here is to allow new IAs in Renew and have the server processing them much like it does for a Request - so borrowing from 18.2.1 will help. I wonder whether saying something like (for replacement of Section 18.2.3):

"If the server cannot find a client entry for an IA, the server SHOULD process the IA as it would for a Request (see section 18.2.1), except that:
1. The server SHOULD use any client specified addresses that it can assign to the client.
2. Any client specified addresses that are not appropriate for the link to which the client is attached or cannot be assigned to the client MUST be returned to the client with lifetimes of 0."

Would that be acceptable? It is indeed the intent.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
Sent: Thursday, February 13, 2014 1:11 PM
To: Bernie Volz (volz)
Cc: [email-masked]; [email-masked]
Subject: Re: [dhcwg] comments on draft-ietf-dhc-dhcpv6-stateful-issues-05

> BV> Home gateways (such in Cable, DOCSIS) typically do request an IA_NA and IA_PD - the IA_NA is for use by the gateway itself whereas the IA_PD is for the prefix within the home (typically statele…

Ah, okay.  Depending on the level of generalization of this document (see below), it may help if the example usage is mentioned.

> BV> I agree though that we should expand the document to discuss this a bit more - again, the focus of the work was really IA_NA + IA_PD.

Okay, but this particular topic I simply chose IA_NA and IA_TA is just an example pair of IA_xx and IA_yy.  The same question still applies.

Now, however, as you clarified the main focus: if we're basically only concerned about the pair of IA_NA and IA_PD, I guess one possibility is to focus on that specific pair, rather than try to generalize the concept.  In general it should be better if we can introduce a general concept of IA_xx's, explain everything in the generalized context and the case of IA_NA and IA_PD can be just one application of it.  But, as the example of IA_TA case shows, the generalization will require considerations on more tricky cases.

In that sense the current shape of the draft seems to be still incomplete.

> BV> We might even propose to DEPRECATE IA_TA as there's probably little value in it for DHCPv6 assigned addresses. This grew out of the original privacy concerns for EUI-64 mac address based addres…

Possibly, but I think that would be beyond the scope of this discussion; even if we can assume we deprecate IA_TA, "the full generalization" approach would still require considerations on such deviant type of IAs to provide sensible abstraction level.

> BV> Surprising RFC 3315 DOES allow IA_TA to be renewed (see RFC 3315, section 22.5). But in any case, I agree with you that we need to discuss this more thoroughly. Or, at indicate that the statefu…

Ah, okay (about the renewability), but actually that was not the main point here.  I should have said IA_TA does not have T1/T2 (so it'll be tricky to define T1/T2 as protocol timers).  And, yes, just focusing on IA_NA + IA_PD is one option (see above).

> BV> I think we should revisit this now that SOLMAX RFC (7083) is out as this changes this text anyway. When this was written, SOLMAX was still a draft and thus wasn't considered. But the updated te…

Hmm, I'm not sure if we are on the same page.  I just tried to point out that the draft uses different keywords (SHOULD and MUST) to explain essentially the same thing and they should be consistent (so this is more about an editorial matter).

> BV> Yes, good catch - we need to replace "addresses" with something more generic. Perhaps we can use the term "resources"? Or leases?

I'd prefer resources over leases between these, as a "lease" sounds like a different level of term (it's the available duration for the assigned address/resource/whatever, while we are thinking about the assigned "thing" here).  But there may be other better term.  I don't have a particular preference.

> BV> I think this "records" refers to the fact that server must record this information? Note that as the server didn't find anything, it needs to store this if it can provide the client the address…

Hmm, I thought in this case the IAs in "records the IAs" mean other IAs than that triggers the Renew.  Also, if this is really "records"
and means the IA that triggers the Renew, why is this plural (the IAs) while the first occurrence of "IA" is singular?  And, even on a closer look, I have some more questions...in "If the server cannot find a client entry for the IA", which IA (there can be multiple of it because of the extension) is it?  If the Renew contains IA1 and IA2 (e.g., the former triggers Renew due to T1 expiration and IA2 is not assigned yet), is it possible that "the server cannot find a client entry for IA1" but "the server *can* find a client entry for IA2"?  If yes, what should happen in this case?

Note, again, that we don't have to be bothered with these in the possible alternative approach I mentioned (once the server is chosen, different IAs are handled separately).

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Fri, 14 Feb 2014 10:02:24 -0800

(I'm now traveling and don't have much time for intensive discussion,
so I'm providing some quick feedback).

At Thu, 13 Feb 2014 20:55:38 +0000,

> First, I think it will be difficult to provide a completely generalized approach to processing of the IAs since IA_TAs are fundamentally very different as they are not generally intended to be rene…

I tend to agree, and now that I understand the original intent of the
draft is to clarify the paired use of IA_NA and IA_PD, I have no
problem with focusing on this specific issue.

> Would that be acceptable? It is indeed the intent.

Maybe.  But I think I need to understand this in the bigger context
of the expected operation on pairing IA_NA and IA_PD.  Whether we
generally expect "both are available or neither is" or whether it's
completely okay if one is available but the other isn't, etc.

--
jinmei

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 14 Feb 2014 19:30:42 +0000

>of the expected operation on pairing IA_NA and IA_PD.  Whether
>we generally expect "both are available or neither is" or whether
>it's completely okay if one is available but the other isn't, etc.

The usual expectation is that both would be available. I think there may be edge cases (misconfigurations) where this isn't the case and hence why handling it 'correctly' is desired.

Perhaps some cable operators can shed more light on this?

I think the core issues where:
1. What happens if something prevents the IA_NA and IA_PD from being provided the 'client' initially. This may result in one not being available. (Note that IA_PD not being available is probably a more significant issue than IA_NA; since home gateway and CMTS can communicate using link-local. Without an address, some SP management capabilities might be restricted?)
2. What happens if the T1/T2 times on the IA_NA and IA_PD are different - when renew happens, should both be renewed or just the one with the expired time as this could result in two independent renewal transactions at some point.

I think we all want to have the clients use one transaction to update both whenever possible.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
Sent: Friday, February 14, 2014 1:02 PM
To: Bernie Volz (volz)
Cc: [email-masked]; [email-masked]
Subject: Re: [dhcwg] comments on draft-ietf-dhc-dhcpv6-stateful-issues-05

(I'm now traveling and don't have much time for intensive discussion, so I'm providing some quick feedback).

> First, I think it will be difficult to provide a completely generalized approach to processing of the IAs since IA_TAs are fundamentally very different as they are not generally intended to be rene…

I tend to agree, and now that I understand the original intent of the draft is to clarify the paired use of IA_NA and IA_PD, I have no problem with focusing on this specific issue.

> Would that be acceptable? It is indeed the intent.

Maybe.  But I think I need to understand this in the bigger context of the expected operation on pairing IA_NA and IA_PD.  Whether we generally expect "both are available or neither is" or whether it's completely okay if one is available but the other isn't, etc.

--
jinmei