Subject: [Dhcpv6bis] Fwd: draft-ietf-savi-dhcp-30 posted

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Thu, 4 Dec 2014 13:41:20 +0000

Fred forwarded a specific question to me about temporary addresses in RFC 3315.  His question is regarding the first paragraph of section 12:

   A client may request the assignment of temporary addresses (see RFC
   3041 [12] for the definition of temporary addresses).  DHCPv6
   handling of address assignment is no different for temporary
   addresses.  DHCPv6 says nothing about details of temporary addresses
   like lifetimes, how clients use temporary addresses, rules for
   generating successive temporary addresses, etc.

which he reads as implying addresses in an IA_TA will have no associated lease time.

My recollection is that the intention for IA_TA is that the addresses in an IA_TA have lifetimes, but the client is not expected to renew the lease on the address.  That recollection is supported, in my opinion, by this paragraph from 22.5:

   An IA_TA option does not include values for T1 and T2.  A client MAY
   request that the lifetimes on temporary addresses be extended by
   including the addresses in a IA_TA option sent in a Renew or Rebind
   message to a server.  For example, a client would request an
   extension on the lifetime of a temporary address to allow an
   application to continue to use an established TCP connection.

I don't know if this issue has already been identified.  Seems worth some discussion...

- Ralph

Begin forwarded message:

> From: "Fred Baker (fred)" <[email-masked]>
> Subject: draft-ietf-savi-dhcp-30 posted
> Date: December 3, 2014 at 6:17:06 PM PST
> To: Elwyn Davies <[email-masked]>, Kathleen Moriarty <[email-masked]>, Ted Lemon <[email-masked]>, "[email-masked]" <[email-masked]>, "Ralph Droms (rdroms)" <[email-masked]>, Barry Leiba <[email-masked]>
> 
> We have posted draft-ietf-savi-dhcp-30. In that we think we have address all of Kathleen’s, Ted’s, and Barry’s comments, and most of Elwyn’s. We have a few open issues that will need to be addressed in a -31 version. Depending on the guidance we receive, -30 could go for further wider review, or -31 could do that. We’re waiting for your guidance.
> 
> 
> One open issue has to do with what looks like an inconsistency in RFC 3315, which is being updated in dhc as we speak and we are in correspondence with Ralph about. This has to do with (Elwin’s comment) the lifetime of a temporary address assigned using DHCP. As we understand 3315 section 10, all IAs carry a lifetime for each address they carry. Section 12 says that the IA_TA carrying a temporary address does not contain a lifetime. Ralph tells us, in private email, that it does. We think that has to be addressed by dhc.
> 
> Another open issue has to do with the terms “upstream” and “downstream” as used by the document. In short, the question is whether the SAVI device can legitimately expect to see all DHCP messages related to a given host; a downstream device/link would see all such, and an upstream device/link would not necessarily see them all. That said, the terminology would appear to suggest that the SAVI domain is at the edge of a network, with no other separate SAVI domains beyond it, which may not be true. We discussed using the terms “protected” and “unprotected”, and would like reviewer advice: would that be an improvement? Are there other terms that might be preferable?
> 
>> RFC 5007 recommends that LEASEQUERY/LEASEQUERY_REPLY messages should be protected by IPsec...
> 
> True. For the switch to send such a message to a DHCP server, either the switch must have an IPsec security association with the server, or the server needs to be able to accept a non-IPsec-protected message from the switch. Unless we can trigger the host to initiate the LEASEQUERY, we think this has to be handled operationally. What text would the reviewers recommend?
> 
> There used to be some discussions on IPSec issues( s11.5 in savi-dhcp-28). They are removed due to comments received. Should they be added in again(after revision) ?
> 
> To Elwyn’s remaining unaddressed comments: we think they require no action.
> 
>> The definitions in s3 and the descriptions of the need to distinguish between upstream and downstream links would appear to rule out the use of SAVI as currently specified in situations where transit traffic and destination traffic share the same link.  Presumably this rules out quite a few wi-fi networks, for example IPv6 networks with multiple subnets per link and possibly situations where there are multiple routers in series.
> 
> The question is whether DHCP messages go through the switch to the host in question. If we see the DHCP messages, we can create a binding for the host; if we don’t, we can’t. Hence, upstream links (paths to devices we may not see the DHCP messages for) cannot be protected by this model, and are precluded by configuring attributes on the relevant interfaces. We believe that the draft identifies the fact and specifies those links.
> 
>> s1: The reference to RFC 2827 (aka BCP38) might better refer to the more extensive RFC 3704 (BCP 84) - and, in any case, use the BCP reference rather than the RFC to cover any future update.
> 
> Speaking as one of the authors of RFC 3704. RFC 2827 (BCP 38) protects a network from spoofed traffic coming from outside of it (usually a customer) by asking whether the source address is reasonable, and drops the message if it is not. RFC 3704 (BCP 84) suggests routing solutions would enable a network to route traffic to an upstream ISP that will not drop it following BCP 38, and describes uRPF filtering, which is a form of routing-based filter that could be used to implement BCP 38. When the switch thinks it is reasonable to accept some given set of IP addresses from the set of hosts attached to a given port, and drops messages with other addresses, it is similar to BCP 38, not BCP 84.
> 
>> Specifying the Data-Snooping state machine as a modification of the DHCP-Snooping state machine is confusing. 
> 
> In -30 at least, the two FSMs are separate.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 4 Dec 2014 06:08:28 -0800

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Dec 2014 09:43:06 -0500

> which he reads as implying addresses in an IA_TA will have no associated lease time.

I think the fundamental problem with what you've said is the old confusion between lease times and lifetimes.   In DHCPv4, lease times both imply renewal times and also imply expiry times.   In DHCPv6, renewal times are independent of expiry times, and IA_TA is one example of why that's so: temporary addresses ordinarily shouldn't be renewed (although they may be if they are still in use).

So I think the text Fred is quoting in section 12 is indeed wrong.   savi-dhcp should be paying attention to address lifetimes, not to T1/T2 times.   So the text should just say that IA_TA addresses are handled _by savi-dhcp_ in exactly the same way as IA_NA addresses.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 4 Dec 2014 15:08:59 +0000

The quoted text is broken because DHCPv6 does say something about lifetimes for temporary addresses - lifetimes are specified by IAADDR. I think if lifetimes was changed to renewal/rebind times it would be more accurate. This matches what Ted's recommendation - savi should not care about t1/t2 - just valid lifetimes (it can ignore preferred lifetime too).

- Bernie (from iPad)

> On Dec 4, 2014, at 9:44 AM, Ted Lemon <[email-masked]> wrote:
> 
> _______________________________________________
> Dhcpv6bis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcpv6bis

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 4 Dec 2014 17:11:52 +0000

> So I think the text Fred is quoting in section 12 is indeed wrong.   savi-dhcp should be paying attention to address lifetimes, not to T1/T2 times.   So the text should just say that IA_TA addresse…

What I need to know is this, and would like someone to give me some text to point to for the record. When DHCP/DHCPv6 is used to assign an address to what SAVI calls a “binding anchor” - the device attached to a switch port, the device using a given MAC address, or maybe a combination of the two - and the SAVI switch creates a Binding State Table entry permitting the indicated host to use the address, there is also some sense of when SAVI should subsequently remove the entry from the Binding State Table an prevent the continued use of the address by the host unless it is renewed. How, specifically, should the SAVI-DHCP device determine that for a temporary address?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Dec 2014 12:19:31 -0500

On Dec 4, 2014, at 12:11 PM, Fred Baker (fred) <[email-masked]> wrote:
> How, specifically, should the SAVI-DHCP device determine that for a temporary address?

Whether the address is in an IA_TA or an IA_NA, it should use the valid lifetime of the address to decide when to remove the address from the table.   If the address valid lifetime has not been extended by the time it expires, the address should be removed from the table.   savi-dhcp should not be paying any attention to T1/T2.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 4 Dec 2014 17:45:45 +0000

> Whether the address is in an IA_TA or an IA_NA, it should use the valid lifetime of the address to decide when to remove the address from the table.   If the address valid lifetime has not been ext…

And exactly where do we find that “valid lifetime”, given (section 12) that says

   Note that an IA has no explicit "lifetime" or "lease length" of its
   own.  When the valid lifetimes of all of the addresses in an IA_TA
   have expired, the IA can be considered as having expired.

?

That’s my question. How do I know what lifetime to apply?

The only thing I have come up with sounds like a royal kluge, which is to monitor RAs, observe the lifetime on various prefixes, and note that an assigned temporary address is within some prefix. To avoid that, I’m looking for some statement by the DHCP server, in a DHCP message, that the address should be purged after some specific interval.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Dec 2014 12:50:58 -0500

> And exactly where do we find that “valid lifetime”, given (section 12) that says

IA_NA and IA_TA both include zero or more IAADDR options.   The lifetime for a particular IP address is in that option.   The T1 and T2 times in the IA_NA option should _never_ be used for savi-dhcp; the fact that they are not present in IA_TA is therefore perfectly OK.

If an existing savi-dhcp implementation relies on T1 and T2, it is broken.   As long as the client keeps renewing the addresses before T2, the brokenness may never become apparent, but it is nevertheless there.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 4 Dec 2014 19:50:57 +0000

On Dec 4, 2014, at 9:50 AM, Ted Lemon <[email-masked]> wrote:

> IA_NA and IA_TA both include zero or more IAADDR options.   The lifetime for a particular IP address is in that option. 

   22. DHCP Options. . . . . . . . . . . . . . . . . . . . . . . . .  70
       22.1.  Format of DHCP Options . . . . . . . . . . . . . . . .  71
       22.2.  Client Identifier Option . . . . . . . . . . . . . . .  71
       22.3.  Server Identifier Option . . . . . . . . . . . . . . .  72
       22.4.  Identity Association for Non-temporary Addresses Option 72
       22.5.  Identity Association for Temporary Addresses Option. .  75
       22.6.  IA Address Option. . . . . . . . . . . . . . . . . . .  76
       22.7.  Option Request Option. . . . . . . . . . . . . . . . .  78
       22.8.  Preference Option. . . . . . . . . . . . . . . . . . .  79
       22.9.  Elapsed Time Option. . . . . . . . . . . . . . . . . .  79
       22.10. Relay Message Option . . . . . . . . . . . . . . . . .  80
       22.11. Authentication Option. . . . . . . . . . . . . . . . .  81
       22.12. Server Unicast Option. . . . . . . . . . . . . . . . .  82
       22.13. Status Code Option . . . . . . . . . . . . . . . . . .  82
       22.14. Rapid Commit Option. . . . . . . . . . . . . . . . . .  83
       22.15. User Class Option. . . . . . . . . . . . . . . . . . .  84
       22.16. Vendor Class Option. . . . . . . . . . . . . . . . . .  85
       22.17. Vendor-specific Information Option . . . . . . . . . .  86
       22.18. Interface-Id Option. . . . . . . . . . . . . . . . . .  87
       22.19. Reconfigure Message Option . . . . . . . . . . . . . .  88
       22.20. Reconfigure Accept Option. . . . . . . . . . . . . . .  89

You’re referring, I presume, to the optional parts of the information element in 22.6. Which of those is the lifetime to which you refer?

The only guidance I see is, from 22.6, either the preferred-lifetime or the valid-lifetime, which Elwyn, in his comment, points out are not present in an IA_TA.

12. Management of Temporary Addresses

   like lifetimes, …

Pick one: I can depend on the lifetime information being present in the IAADDR option, or I can’t. If I can, Elwyn’s comment is wrong. If I can’t, I need lifetime information.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 4 Dec 2014 20:34:29 +0000

We would have to see if Ralph recalls the reason for this text, but I suspect it means that the RFC 3315 is not providing any guidance as to what the actual lifetimes values should be set to (i.e., is the temporary address lifetime 10 minutes or 2 days or 3 months).

It is not saying that there are no lifetimes (i.e., ignore the preferred/valid-lifetime fields).

I think we will look at fixing this text - perhaps we should say "like the lifetime values to be used" or remove the "lifetimes" from the list.

I have open a RFC3315bis ticket for this, http://trac.tools.ietf.org/group/dhcpv6bis/ticket/128.

- Bernie

-----Original Message-----
From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Fred Baker (fred)
Sent: Thursday, December 04, 2014 2:51 PM
To: Ted Lemon
Cc: Ralph Droms; dhcpv6bis
Subject: Re: [Dhcpv6bis] draft-ietf-savi-dhcp-30 posted

You're referring, I presume, to the optional parts of the information element in 22.6. Which of those is the lifetime to which you refer?

   like lifetimes, ...

Pick one: I can depend on the lifetime information being present in the IAADDR option, or I can't. If I can, Elwyn's comment is wrong. If I can't, I need lifetime information.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Dec 2014 16:17:56 -0500

> The only guidance I see is, from 22.6, either the preferred-lifetime or the valid-lifetime, which Elwyn, in his comment, points out are not present in an IA_TA.

The IAADR option is present in any IA_NA or IA_TA option that contains an address, because it is this option that conveys the address.   It's possible for an IA_NA or IA_TA to _not_ contain an address, but we don't care about such options, because there's no address with a lifetime to expire .   The valid and preferred lifetimes are not optional in the IAADDR option.   So there is no case where an address will be conveyed by the DHCP server to the DHCP client without both a valid and preferred lifetime being included.

This is what RFC 3315 says in the description of the IA_TA option:

So indeed, Elwyn's comment is simply incorrect.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 4 Dec 2014 21:42:38 +0000

> So indeed, Elwyn's comment is simply incorrect.

In that case, with respect to draft-ietf-savi-dhcp, I’ll simply drop it. The text we have should cover it.