Subject: PPPoE requirements (was Turning on IPv6 Routers)

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 24 Jul 2017 20:00:33 +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.

---

From: Erik Kline <[email-masked]>
Date: Tue, 25 Jul 2017 11:55:38 +0900

> 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 w…

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

>> depend upon the CPE to do DHCPv6 (-PD) at all!

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

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 25 Jul 2017 12:55:20 +0000

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

No. On PPP you don't need DAD for LLA. But in the context of "offering" addresses via RA and DHCPv6 using the same prefix...
Well, of course, you can't actually "offer" a specific address via RA. But if you envision a CE Router that used the EUI-64 to derive a SLAAC address from a prefix and then offering that identical address via DHCPv6...
No. It's just too horrible. I don't want to think about it. 
 
> > 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.
> >

The population of people wanting to do PPPoE from a (non router) host to get IPv6 just to that host is going to be really, really, really small. Jumping through hoops to create an access network architecture that supports both CE routers and hosts isn't worth the trouble. If an ISP wants to supply IPv6 over PPPoE for both hosts and CE routers, my suggestion would be to supply special PPPoE software (for download onto hosts) that will look to the access network like a CE router (i.e., ask for IA_PD, etc.). Don't expect the PPPoE client native to your OS to work.
Barbara

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Jul 2017 13:49:53 -0400

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

Exactly.  It could be the case that it's just one host!

The thing is that you can't tell at PPP auth time, nor can you tell at RA
time.  You can tell at DHCPv6 time if a PD it asked for.  But, by that time
it's too late for the BMS to change it's mind and not offer an address via
SLAAC, or offer a prefix that is within the PD.

Running PPPoE from your laptop/desktop is still readily supported under
Linux, OSX and Windows.  (I think that early PPPoE assumed that there
would be multiple PPPoE sessions to get multiple PCs online in the home.)

It would be nice if we could have perhaps three (maybe 4) flavours of PPPoE/IPv6.
Vanilla, Chocolate and Strawberry (and Neopolitan).
Vanilla    == unnumbered, device does PD and picks an address.
Chocolate  == number link with SLAAC  (prefix is not excludable with 6603)
Strawberry == number link with DHCPv6 
Neopolitan == offer all of the above

I wouldn't mind if the router told the BMS of it's intentions during PPP
IP6CP time!   

While you can pick a flavour via construction and RFP, that doesn't help if
the customer provides his own router, or if the ISP is small enough to have
supplier of the month problems.  (All might be compliant, yet require
different configurations.  The customers could have more than one brand of
device as well, because maybe one device is suspected to be flaky)

In my BMS product, what exactly is done/offered is entirely determined by the
Radius options that are provided.  All I've really done is push the problem
back up a level :-)

Worse case you have to inject a /64 for the numbered link along with a /60
(or whatever) for the PD that was non-overlapping into the routing fabric,
when a single /60 would have done.  Having the PPP link unnumbered has some
small security advantage in that it removes a small surface for attack.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Jul 2017 13:56:21 -0400

> No. On PPP you don't need DAD for LLA. But in the context of "offering"
    > addresses via RA and DHCPv6 using the same prefix... 
    > Well, of course, you can't actually "offer" a specific address via
    > RA. But if you envision a CE Router that used the EUI-64 to derive a
    > SLAAC address from a prefix and then offering that identical address
    > via DHCPv6... 

The LL address "created" in PPP is well known at both ends.
(They can be derived from other addresses, or can be random)
It's created during IP6CP.   It's not hard to code at all, although I haven't
done that.  

The router can otherwise wind up with a SLAAC (self-assigned) address, and  
then also a DHCPv6 address.

The BMS chews up two neighbour cache entries. It would be nice to avoid this.  

    > The population of people wanting to do PPPoE from a (non router) host
    > to get IPv6 just to that host is going to be really, really, really
    > small. Jumping through hoops to create an access network architecture
    > that supports both CE routers and hosts isn't worth the trouble. If an
    > ISP wants to supply IPv6 over PPPoE for both hosts and CE routers, my
    > suggestion would be to supply special PPPoE software (for download onto
    > hosts) that will look to the access network like a CE router (i.e., ask
    > for IA_PD, etc.). Don't expect the PPPoE client native to your OS to
    > work. 

But, it does work.  Just like that.

While routers are ubiquitous in the first world, they are *not* ubiquitous in
the developing world.

Further, there are all sorts of interesting deployments in some places where
there are open wifi mesh networks that cross entire communities and offer
walled-garden access to local resources for free, but one can use PPPoE over
these rather slow (500kbps) links with a provider (sometimes of your choice)
for a public IP.

---

From: Mark Smith <[email-masked]>
Date: Thu, 27 Jul 2017 07:44:04 +1000

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

No. On PPP you don't need DAD for LLA.

I think you now do per RFC8064/RFC7217.

I don't really understand the motivation for avoiding DAD. It's a very
marginal saving (1 packet) in comparison to the problems and time involved
in troubleshooting duplicate addresses.

In the scenario described, it can be much worse because there is likely a
non-technical end-user and a helpdesk involved in what can be an
intermittent and obscure fault (Helpdesks can be motivated to get the
customer off the phone by saying "reboot the modem and call us back if you
have more problems", which doesn't prevent the fault re-occurring.)

I think absolute and consistent failure is much better and easier to
troubleshoot than partial and intermittent failure when the cause is simple
to determine and discover.

But in the context of "offering" addresses via RA and DHCPv6 using the same
prefix...
Well, of course, you can't actually "offer" a specific address via RA. But
if you envision a CE Router that used the EUI-64 to derive a SLAAC address
from a prefix and then offering that identical address via DHCPv6...
No. It's just too horrible. I don't want to think about it.

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

The population of people wanting to do PPPoE from a (non router) host to
get IPv6 just to that host is going to be really, really, really small.
Jumping through hoops to create an access network architecture that
supports both CE routers and hosts isn't worth the trouble. If an ISP wants
to supply IPv6 over PPPoE for both hosts and CE routers, my suggestion
would be to supply special PPPoE software (for download onto hosts) that
will look to the access network like a CE router (i.e., ask for IA_PD,
etc.). Don't expect the PPPoE client native to your OS to work.
Barbara
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------