Re: [v6ops] DHCPv6 PD route injection (was: Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host))

"Brzozowski, John" <John_Brzozowski@comcast.com> Tue, 14 November 2017 03:17 UTC

Return-Path: <John_Brzozowski@comcast.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE2C126CC7; Mon, 13 Nov 2017 19:17:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBuzl8W-bs39; Mon, 13 Nov 2017 19:17:49 -0800 (PST)
Received: from vaadcmhout02.cable.comcast.com (vaadcmhout02.cable.comcast.com [96.114.28.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F5B112714F; Mon, 13 Nov 2017 19:17:49 -0800 (PST)
X-AuditID: 60721c4c-cc26d7000000a9fa-6a-5a0a605c88fc
Received: from VAADCEX09.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by vaadcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 64.96.43514.C506A0A5; Mon, 13 Nov 2017 22:17:48 -0500 (EST)
Received: from VAADCEX15.cable.comcast.com (147.191.102.82) by VAADCEX09.cable.comcast.com (147.191.102.76) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 13 Nov 2017 22:17:47 -0500
Received: from VAADCEX15.cable.comcast.com ([fe80::3aea:a7ff:fe12:39c0]) by VAADCEX15.cable.comcast.com ([fe80::3aea:a7ff:fe12:39c0%19]) with mapi id 15.00.1347.000; Mon, 13 Nov 2017 22:17:47 -0500
From: "Brzozowski, John" <John_Brzozowski@comcast.com>
To: Ole Troan <otroan@employees.org>, Mark Smith <markzzzsmith@gmail.com>
CC: Fernando Gont <fgont@si6networks.com>, "v6ops@ietf.org WG" <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>
Subject: Re: [v6ops] DHCPv6 PD route injection (was: Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host))
Thread-Topic: [v6ops] DHCPv6 PD route injection (was: Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host))
Thread-Index: AQHTXOOlZwr2K8IU9U+8sAzJ4tkB6aMTNIKA
Date: Tue, 14 Nov 2017 03:17:47 +0000
Message-ID: <12D6415A-562A-4844-B56F-6A2EFA0B2267@cable.comcast.com>
References: <be9724f5-2ff5-d90c-2749-ecae2c628b78@si6networks.com> <CAKD1Yr0_a2Qm8U4oK+BQU57DeDUD9i-o_+G+YhnH4pVXRxmxxQ@mail.gmail.com> <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com> <ea772bfd-4004-7f94-8469-b50e3aff0f29@si6networks.com> <F2330138-6842-4C38-B5A0-FB40BFACD038@employees.org> <e40697ca-8017-c9d2-c25d-89087046c9cf@gmail.com> <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com> <CAKD1Yr26NK2osApYZBm8Yd=0X7xcetrxojp6=JHOEAu9BB0q8A@mail.gmail.com> <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com> <E67105A3-396B-403C-B741-E9E01CFB5CE7@employees.org> <862687c9-c107-53a8-288a-29049097b0e1@acm.org> <AM5PR0701MB2836C00EA1AAC73E7E63F583E02B0@AM5PR0701MB2836.eurprd07.prod.outlook.com> <CAO42Z2xacRco7ne7biQ93so0k-x4xSnM2jzoB13-sdVRLshQDQ@mail.gmail.com> <CAKD1Yr0Zz6Jxg_ZuEbBkMhBdEaZKOrtx-eUns7KWi9v-5PDBzg@mail.gmail.com> <CAO42Z2xqwRH94dw=XJf5mt3STdDcTYmB_i1NbXP46shdJQeaPA@mail.gmail.com> <FC485644-826F-469A-92B5-45A8F9048F35@employees.org>
In-Reply-To: <FC485644-826F-469A-92B5-45A8F9048F35@employees.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.21.0.170409
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [96.114.156.8]
Content-Type: text/plain; charset="utf-8"
Content-ID: <6AEB78F83EDD114DBAD3163E0A055A59@comcast.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJIsWRmVeSWpSXmKPExsWSUOxpoRuTwBVlsO+qkMXKFXeZLJ6sesNm 8XbxD0aLnUeOsltMblvBZnH62F5mBzaPg8c+MnrsnHWX3WPJkp9MHndvXWLy+HCohz2ANYrL JiU1J7MstUjfLoEr49znDywFF7QrHhw9w9TAeECri5GTQ0LAROLK1BlMXYxcHEIC25kk3q6f ywjhHGCU2Lv/A1TmJKPE6xvTmEBa2ATMJLYcvM0OYosIeEocfT+VBaSIWeAgo8Tj74/AEsIC lRKPJqxnhiiqkvh25DYjhG0kMX/6JyCbg4NFQFXiyV8TkDCvgIvE6a2roTbP5pCYt6wHbA6n gKPEhVl/wGxGATGJ76fWgB3BLCAucevJfCaIHwQkluw5zwxhi0q8fPyPFcQWFdCTuPZhJQtE XEfi7PUnjBC2gcTWpfug4goS2/dvYwG5h1lAU2L9Ln0I00pi9WxPiE2KElO6H7JDnCkocXLm E6hOcYnDR3awTmCUnoXkoFkIg2YhDJqFZNAsJIMWMLKuYuSxNNMzNDTRM7LQMzfbxAhKAEUy PjsYP03zOMQowMGoxMM7JZ4rSog1say4MvcQowQHs5IIb0gwUIg3JbGyKrUoP76oNCe1+BCj NAeLkjjv/JOsUUIC6YklqdmpqQWpRTBZJg5OqQbG0DyB2VM3drm/N/v103B50ZNYv3MOs07t jr7LGvpbUN4r7kK9r9ytyCnapUarDh2zFM2qtZW1yfx+bfG5E9fPtvUv8fDUFV4ZVdp1otKJ 02mPRpbRrfyQsyLxPwxvJFz/If7EkeHC5ex4uyiWZWdLFrP3azJ/N3yxUSnz5p0Xc41XSTw/ wqSuxFKckWioxVxUnAgAOYmKcfwCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/GnnF0sQYxazRQrgzWlt3VtHzbXw>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Nov 2017 03:17:51 -0000

Ole I think this is perhaps 5-7 years too late possibly longer.  To be clear this has in fact been solved, PDRI was something we needed to address to launch IPv6 for DOCSIS based HSD many years ago.  Ralph (since you mention him) was there, he knows.

This is widely supported today across cable networks specifically for DOCSIS and even other fiber based (PON) access network implementations where we (Comcast) were involved in the development of IPv6 support.  Note we use the same implementation for our video services, which are IPv6 only.

Why in heavens name would you now go back and document something that has been done for so long? (rhetorical)

Please note a documentation exercise will not change any existing deployments, this ship has sailed.  This is not a wise use of IETF time and energy.  If this is the type of work the IETF believes requires attention perhaps it is time to start shutting down some of the IPv6 (6man/v6ops) WGs.

John
+1-484-962-0060

-----Original Message-----
From: v6ops <v6ops-bounces@ietf.org>; on behalf of Ole Trøan <otroan@employees.org>;
Date: Monday, November 13, 2017 at 18:57
To: Mark Smith <markzzzsmith@gmail.com>;
Cc: Fernando Gont <fgont@si6networks.com>;, v6ops <v6ops@ietf.org>;, "6man@ietf.org"; <6man@ietf.org>;, Gunter Van de Velde <gunter.van_de_velde@nokia.com>;
Subject: [v6ops] DHCPv6 PD route injection (was: Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host))

    
    
    > On 14 Nov 2017, at 03:43, Mark Smith <markzzzsmith@gmail.com>; wrote:
    > 
    > 
    > DHCPv6 has been designed to avoid having state in intermediary devices
    > by incorporating a relay agent into the architecture, specified in
    > RFC3315.
    > 
    > Clients use DUIDs to identify themselves, and the DHCPv6 server
    > associates client attributes with the client's DUID. That is what
    > allows DHCPv6-PD to survive a router/DHCPv6 relay reboot.
    > 
    > This draft hasn't been published as an RFC, however it is also
    > considering this issue.
    > 
    > "DHCPv6 Relay Agent Assignment Notification (RAAN) Option"
    > https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-agentopt-delegate-03
    > 
    > A number of vendors seem to have implemented the functional equivalent
    > by looking directly at the ID_PD option when the DHCPv6 reply is sent
    > to the client - search for "DHCPv6 Relay Agent Notification for Prefix
    > Delegation"
    > 
    > The alternative is to have a RADIUS server provide the delegated
    > prefix information to a DHCPv6 server running on the router. "RADIUS
    > Delegated-IPv6-Prefix Attribute", RFC4818.
    > 
    > Possibly the RADIUS method could be used in this draft's scenario if a
    > layer 2 attribute such as the MAC address or per-client VLAN tags, or
    > 802.1X authentication information, is used to identify the client.
    > 
    > If this draft can't document that method because it doesn't exist,
    > then, assuming Comcast is the only deployment of this, it seems
    > Comcast aren't trying to have a prefix assignment survive a router
    > reboot. That's a "flash renumbering" approach, which I don't think is
    > right for IPv6.
    > 
    > 
    >> This has not stopped the deployment of tens or hundreds of millions of
    >> networks that use DHCPv6 PD.
    >> 
    > 
    > What was the alternative that didn't have this limitation?
    > 
    > There is a big difference between something working and something working well.
    
    Yes, it's quite unfortunate that we haven't solved the problem of robust route injection in PD yet.
    
    Ralph and I when writing 3633, concluded while there were many options, few of them were attractive, and instead resorted to specify that PD must operate without relays.
    
    Markus enumerated the options here:
    https://www.ietf.org/archive/id/draft-stenberg-pd-route-maintenance-00.txt
    
    Let me know if you are interested in working on the problem.
    
    Best regards,
    Ole