Re: [v6ops] PPPoE requirements (was Turning on IPv6 Routers)

[Erik Kline <[e-mail]>]

On 25 July 2017 at 05:00, STARK, BARBARA H <[e-mail]> wrote:
>>     > 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.

You don't need DAD to deal for link-local addresses?

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

Is this because it might actually just be a host that's connecting?

> 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.
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops