PPPoE requirements (was Turning on IPv6 Routers)

"STARK, BARBARA H" <bs7652@att.com> Mon, 24 July 2017 20:01 UTC

Return-Path: <bs7652@att.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 066FF131F02; Mon, 24 Jul 2017 13:01:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level:
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 TByNeWabNJKY; Mon, 24 Jul 2017 13:01:04 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 E035C131EFE; Mon, 24 Jul 2017 13:01:04 -0700 (PDT)
Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v6OJtLmr046536; Mon, 24 Jul 2017 16:01:03 -0400
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 2bwma3pv1q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Jul 2017 16:01:03 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v6OK0whj024670; Mon, 24 Jul 2017 16:01:00 -0400
Received: from alpi134.aldc.att.com (alpi134.aldc.att.com [130.8.217.4]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v6OK0m35024292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 24 Jul 2017 16:00:54 -0400
Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (GAALPA1MSGHUBAA.itservices.sbc.com [130.8.218.150]) by alpi134.aldc.att.com (RSA Interceptor); Mon, 24 Jul 2017 20:00:35 GMT
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.219]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0319.002; Mon, 24 Jul 2017 16:00:34 -0400
From: "STARK, BARBARA H" <bs7652@att.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
CC: Fred Baker <fredbaker.ietf@gmail.com>, IPv6 Ops WG <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>
Subject: PPPoE requirements (was Turning on IPv6 Routers)
Thread-Topic: PPPoE requirements (was Turning on IPv6 Routers)
Thread-Index: AdMEt31v4/lFzKojS3arT0hUd4QLuQ==
Date: Mon, 24 Jul 2017 20:00:33 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DBDC2E7@GAALPA1MSGUSRBF.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.70.213.190]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-24_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707240304
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/i8IjS3bf3BBUxS2cLOqHigd6yt4>
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: Mon, 24 Jul 2017 20:01:07 -0000

>     > As an implementer of a PPPoE aggregator/access-router, I found that I
>     > had to invert 7084 to determine what I had to implement.
> 
>     > It might be worth a document, if only so that ISPs would have something
>     > against which to issue RFPs. Maybe.
> 
>     bhs> <bhs> BBF TR-187 documents the telco IPv6 over pppoe access
> network
>     bhs> architecture with some specific requirements for access network
>     bhs> elements.
>     bhs> https://www.broadband-forum.org/technical/download/TR-187_Issue-2.pdf
> 
> Yes, I worked from TR-187 as well. It's close to what I want, but it doesn't say
> what the access network elements *MUST* do, but rather tells you what the
> CPE boxes MUST try.

??
Section 9 of TR-187 is all about the BNG (BBF term for access network IP edge router that does aggregation) requirements.
But the doc as a whole presents a number of ways to do IPv6 over PPPoE -- not just one. This means the ISP has to pick one and configure it appropriately. The BNG requirements include support for all of the described ways. The conditional wording in some of the requirements is a bit strange, though.

> For instance: *SHOULD* a PPPoE access router provide an address for the
> CPE router link via RA or via DHCPv6?  

The BNG has to support RA (SLAAC), IA_NA, and IA_PD. The ISP is responsible for configuring the BNG appropriately/correctly per the ISP's chosen architecture. The ISP can choose to provide the address by RA (SLAAC), IA_NA, or go with the unnumbered model (CE router picks address from IA_PD prefix).

> If it does both, should it offer the same
> address?   

I would recommend against configuring the BNG to use the same prefix for SLAAC and IA_NA or IA_PD, or for IA_NA and IA_PD. Then DAD would really be needed. And I don't understand why anyone would want to. I would recommend the ISP pick a single method to use. The TR-124 RG is expected (by default) to support all numbering models. If offered SLAAC, it must take an address from that prefix (at least one). If offered IA_NA, it must accept that. It must do IA_PD. If neither SLAAC nor IA_NA are offered, then it must assign itself an address from the IA_PD. 

> It would be rather better if one *knew* the CPE would do PD
> and then assign itself an address out of one of the /64s.  That would
> eliminate a bunch of routes.  

TR-124 RG requirements (referenced by TR-187) do require support for IA_PD and the unnumbered model. RFC 7084 does not require support for the unnumbered model; there it's optional. An ISP procuring CE routers can use TR-124 for an RFP. But such an ISP cannot depend on "retail" CE routers supporting the unnumbered model. This is because CableLabs eRouters do not support the unnumbered model, and eRouters needed to be compliant with RFC 7084. I'm not sure of the status of the unnumbered model in non-eRouter "retail" CE routers.

> Part of the problem is that one can't necessarily
> depend upon the CPE to do DHCPv6 (-PD) at all!

Support for IA_PD is mandatory in RFC 7084, CableLabs eRouters, and TR-124. The default flow in TR-124 (Appendix A.1 which leads to A.2) is for IA_PD always to be requested (don't wait for RA). TR-124 was specifically designed for use in RFPs. RFC 7084 requires IA_PD be requested if M or O = 1. The fact that some CE routers don't support any of these specs doesn't mean we need more specs. It means we need more compliant CE routers.

> It would just be nice to reduce the number of options.  Maybe a BCP is in
> order.

Unless we know some of the options aren't being used by any ISP, it would be hard to get agreement to get rid of any. My sense is there is widespread support of both IA_NA and unnumbered. I don't know if anyone is using SLAAC over PPPoE, but I suspect there are. But since the IPv6 over PPPoE flow is identical to native IPv6 after IPv6CP is done, and for native IPv6 we do know of deployments with SLAAC, I would be tempted to keep that same flow rather than get rid of an option for IPv6 over PPPoE.
My recommended practices would be more like:
   - if doing PPPoE, make sure your CE routers / RGs are compliant with TR-124 WAN.PPP and WAN.PPP.IPv6 modules
   - make your CE router vendors get the IPv6 Ready CE router certification
   - don't configure the same prefix on SLAAC and IA_* or IA_NA and IA_PD

I would like to see if we could reduce the number of v4 over v6 tunneling options that v6ops will be "recommending". I think the current laundry list is a bad idea. But that's another topic.