Subject: Re: [v6ops] new draft: draft-smith-v6ops-ce-dhcpv6-transparency

From: Ted Lemon <[email-masked]>
Date: Sat, 19 Oct 2013 19:17:06 -0400

On Jul 30, 2013, at 8:45 AM, [email-masked] wrote:
> A new draft has been posted, at http://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency. Please take a look at it and comment.

Very belated reply—sorry.

This document is sort of close, but there are a few issues.   First of all, there should be no relay; rather, the CE router should, when it receives a request, issue _its own_ information request to the PE relay.   It would provide no information about the client to the PE relay, but instead would use its own information.   This model would be followed both for stateless and stateful.

This is necessary for two reasons.   First, some DHCP parameters need to come from the CE router, not the provider.   Second, as is noted in this document's security considerations section, revealing information about clients on the local network is a privacy issue, and should be avoided.

Of course, this solution creates some problems in cases where for example vendor-specific options need to be communicated upstream, but realistically the provider isn't going to have custom configuration information like that in their DHCP server or, if they do, for devices like a provider-specific VoIP device, it should be handled with a specific extension that ensures that _only_ such information as is necessary is communicated upstream.

Aside from these comments, the general flow of the proposed solution seems right.   It probably make sense to decouple information requests and use caching and information refresh timers to maintain local information for local clients, but that's the only substantial change I'd suggest.   This would provide some degree of control over revealing information about the comings and goings of users of devices on the home network.   It does add complexity to the implementation, though, particularly in the case where device-specific configuration information needs to be maintained, such as in the case where the device asks to send a vendor class identifier upstream.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 21 Oct 2013 17:38:08 +0900

On Sun, Oct 20, 2013 at 8:17 AM, Ted Lemon <[email-masked]> wrote:

> > A new draft has been posted, at
> http://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency.
> Please take a look at it and comment.
>
> Aside from these comments, the general flow of the proposed solution seems
> right.

Actually, I'm not sure this is the right approach. For example, it would
seem to be incompatible with the homenet approach of acquiring
configuration via DHCPv6 at the edge of the homenet network and then
passing that information around inside the homenet.

Given that this document is targeted at exactly the same problem that
homenet is attempting to solve, I'd rather see this work be moved to
homenet, where a lot more thinking has been done on this problem already,
than taking it on in an operational group without necessarily considering
the implications on the designs that homenet is working on.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 21 Oct 2013 09:29:57 -0400

On Oct 21, 2013, at 4:38 AM, Lorenzo Colitti <[email-masked]> wrote:
> Actually, I'm not sure this is the right approach. For example, it would seem to be incompatible with the homenet approach of acquiring configuration via DHCPv6 at the edge of the homenet network and then passing that information around inside the homenet.

It's not clear to me that there is a problem here.   In a multi-homed scenario, a host on the homenet is either going to do DHCP with multiple CE routers, in which case this works, or with a single CE router, in which case this works.

If the homenet does cascaded DHCP, then each DHCP server would cascade unknown options toward the edge, but that's a bad model—only CE routers should be doing DHCP anyway in a homenet, IMHO.   But that is certainly a discussion to be had on the homenet mailing list.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 21 Oct 2013 13:46:45 +0000

There was also the following (now expired) draft related to this topic - http://tools.ietf.org/html/draft-ietf-dhc-container-opt-07.

In that draft's model, the SP could push down a "bucket" of options which the "DHCPv6 hybrid server" could pull options from to provide the client. Ralph Droms originally started this document and it even went to the IESG. But it has not progressed much further and I think Reinaldo (and Ralph) lost interest as there didn't seem to be any strong push for it.

Regarding this draft, I think SPs would like not to see traffic from the devices behind the CPE router.

It does seem appropriate to me to consolidate the efforts and have them occur (mostly) in one place.

-          Bernie

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Monday, October 21, 2013 4:38 AM
To: Ted Lemon
Cc: [email-masked]; IPv6 Ops WG; [email-masked]
Subject: Re: [v6ops] new draft: draft-smith-v6ops-ce-dhcpv6-transparency

> A new draft has been posted, at http://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency. Please take a look at it and comment.
Aside from these comments, the general flow of the proposed solution seems right.

Given that this document is targeted at exactly the same problem that homenet is attempting to solve, I'd rather see this work be moved to homenet, where a lot more thinking has been done on this problem already, than taking it on in an operational group without necessarily considering the implications on the designs that homenet is working on.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 21 Oct 2013 12:36:47 -0700 (PDT)

>________________________________
> From: Lorenzo Colitti <[email-masked]>
>To: Ted Lemon <[email-masked]> 
>Cc: Fred Baker (fred) <[email-masked]>; [email-masked]; IPv6 Ops WG <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Monday, 21 October 2013 7:38 PM

>Given that this document is targeted at exactly the same problem that homenet is attempting to solve, I'd rather see this work be moved to homenet, where a lot more thinking has been done on this pr…

Homenet does seem the place for it in some respects, I thought v6ops was the primary place mainly because the update to RFC6204 is a v6ops draft. However, thinking about it further, I don't think it is a homenet unique issue though - 3G devices that are providing tethered Internet access via their LAN interfaces also have the same constraint as they also follow the DHCPv6 Client/Server model rather than a DHCPv6 relay or DHCPv6 hybrid server model that I propose. It also more generally applies to any environment where the customer brings their own router - SOHO, most enterprises etc.

I think where it is the biggest issue is in the residential market, if it is one where customers can bring their own CPE (such as here in .au), and are responsible for updates to it. Asking them to upgrade their CPE firmware to support new options is pretty much a waste of time - they either won't understand what you're asking them to do, won't be competent to do it, or won't be confident of doing it because the consequences of losing their Internet services if it isn't successful are too high. DHCPv6 option transparency would avoid a continuous cycle of CPE upgrades to support new DHCPv6 options that the hosts might like to use and the upstream service provider might like to provide.

As for the thinking behind it, I've been thinking about this problem since about 2010/2011. I worked on Internode's production IPv6 broadband deployment during that period. While waiting for some vendor features/bug fixes to BNG software, I also worked with a number of residential IPv6 CPE vendors, advising them on their IPv6 implementations. I realised the problem with "DHCPv6 option" transparency after there were different levels of CPE support for different DHCPv6 options. This was while RFC6204 was being developed, however as I mentioned in the draft, future useful DHCPv6 options will not be supported in the DHCPv6 client/server model. *

I understand the need for providing local services, and when writing this, wondered about the DHCPv6 hybrid server either adding options to the Client replies it constructs from the relayed Information-Request, or overwriting or adding to values in the options that it received in the relayed Information-Request. There are "interesting" issues though - should the CPE's option values always override those supplied by the service provider?  Or should they be added to those that the service provider supplies. For some options the CPE policy might be to defer to the SP supplied option values, where as for other options it might need to be a setting. I think these issues are DHCPv6 option specific, and the theme of the draft is to try to minimise / avoid any DHCPv6 option specific handling to attain DHCPv6 option transparency.

Regards,

Mark.

p.s., thanks all for your review and comments.

* I did a presentation at Ausnog 2011 on my experiences with IPv6 CPE  - "Residential IPv6 CPE - What not to do and other observations" - http://www.users.on.net/~markachy/resi_ipv6_cpe.pdf