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

[Mark ZZZ Smith <[e-mail]>]

>________________________________
> From: Lorenzo Colitti <[e-mail]>
>To: Ted Lemon <[e-mail]> 
>Cc: Fred Baker (fred) <[e-mail]>; [e-mail]; IPv6 Ops WG <[e-mail]>; "[e-mail]" <[e-mail]> 
>Sent: Monday, 21 October 2013 7:38 PM
>Subject: Re: [v6ops] new draft: draft-smith-v6ops-ce-dhcpv6-transparency
> 
>
>
>On Sun, Oct 20, 2013 at 8:17 AM, Ted Lemon <[e-mail]> 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.
>
>

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