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

Mark ZZZ Smith <> Mon, 21 October 2013 19:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC9BB11E870B for <>; Mon, 21 Oct 2013 12:37:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.101
X-Spam-Level: *
X-Spam-Status: No, score=1.101 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m0IvnnV0S4ge for <>; Mon, 21 Oct 2013 12:37:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A821411E86F5 for <>; Mon, 21 Oct 2013 12:36:51 -0700 (PDT)
Received: from [] by with NNFMP; 21 Oct 2013 19:36:48 -0000
Received: from [] by with NNFMP; 21 Oct 2013 19:36:48 -0000
Received: from [] by with NNFMP; 21 Oct 2013 19:36:48 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 11468 invoked by uid 60001); 21 Oct 2013 19:36:48 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1382384207; bh=iKB0RoL2G5H4marm1HoILGXStFsSljhU+ZOkjVMBs5U=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=sG5GTJxAp2eV+vxJKQyN7j/aLWyruwvjZutsYG/6zRbpvyWdi9DRNDMTYTwV9Bj6ENsjiEwyF5B0dw8Ofn57QIlwF8COsTnimd2xV8aMgQ25kqjF49PClP5znpXs4YXD8BqqtI5pwt0hv6ZBn+0N7A6Rel4YZP0aWqzwUDnpgj0=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=D/h/cxjfg0p67aib4093KOTdf6rpKaaUGUb+CNCJdXTljVStRQN00aTqKxHH/d8ClmQgorXSV2XQPDm6pwCSoiULTHIdArDxbSIMZmU3BVZndjxmH4ac1jnoLRLSuikAR235//28tGYXat6T3c05WCSE1tfLiadvD+7qd6Zj7B4=;
X-YMail-OSG: zcxmCHAVM1ltoV9BTkXcy29Uz4Zt29tCpvCT4HgMYcT3.4R WMcpVkiIGr_Bcl2FTZTCrKiCGCEBrwb5BTdJgYGkuPMXb3eg0_QXuAuWg1Ez R1xciD2To43w.6GmeXD3Zjn_HkaYfL05ah4FZYKtQUgBrPKy_zZ6M2VgJwy4 iWCdsJFEkw3RWtnlEt_FfTaB8ZVwgALjV4DP2q2DuGCRt6Ngo7bQfePOobZ7 pmDxScEy6PD54C852m1UN5Q2pWLBBAD4EsXs6XMndcw4M7vJceIrbGdbYzfL 9fm9mtwaVy1mNUAJjnLIn5RtT7IY7cjuxszn6YyKgSFjJDZT0DHhoJLg7bcN rot3TyzmmzBuLQq3XJuJugH8dU9_M5vJtY9YPv0aa1A9Zp2vPWMkt7VOS9yZ EqDo2TBkPnO5wvpiu7Ww4m2W0vv5Gr.GLBGY827r1xlXtTh0i6VzfDTS96cp pO0wLctgU0Tv9ZUDBtenBRxVPK7G.x.5SfzTmm.TkfmEgYoSRG04pN9evbTG IbbhS5saFQNVoQAFAC54FbJITXLkd.sp4y8kGfIicGnlMYMrAOIlDs.3AY59 1rvYH9oNArSSvOdXroOxooHGlQ4lNwimLMTizzHUIHGl2dg5QxwEf0hXBUiX 6x3j_d1viL.OtmbvG8BCl1XhrM0q9hRBxcpBtg.7Qj93dWCQ1Uc15PvVrJxu t9YxkJASrC8UINlNw
Received: from [] by via HTTP; Mon, 21 Oct 2013 12:36:47 PDT
X-Rocket-MIMEInfo: 002.001, CgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbT4KPlRvOiBUZWQgTGVtb24gPHRlZC5sZW1vbkBub21pbnVtLmNvbT4gCj5DYzogRnJlZCBCYWtlciAoZnJlZCkgPGZyZWRAY2lzY28uY29tPjsgZHJhZnQtc21pdGgtdjZvcHMtY2UtZGhjcHY2LXRyYW5zcGFyZW5jeUB0b29scy5pZXRmLm9yZzsgSVB2NiBPcHMgV0cgPHY2b3BzQGlldGYub3JnPjsgImhvbWVuZXQtY2hhaXJzQHRvb2xzLmlldGYub3JnIiA8aG9tZW4BMAEBAQE-
X-Mailer: YahooMailWebService/
References: <> <> <>
Message-ID: <>
Date: Mon, 21 Oct 2013 12:36:47 -0700 (PDT)
From: Mark ZZZ Smith <>
To: Lorenzo Colitti <>, Ted Lemon <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "" <>, IPv6 Ops WG <>, "" <>
Subject: Re: [v6ops] new draft: draft-smith-v6ops-ce-dhcpv6-transparency
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Mark ZZZ Smith <>
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 21 Oct 2013 19:37:43 -0000

> From: Lorenzo Colitti <>
>To: Ted Lemon <> 
>Cc: Fred Baker (fred) <>om>;; IPv6 Ops WG <>rg>; "" <> 
>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 <> wrote:
>> A new draft has been posted, at 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.



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" -