Re: A common problem with SLAAC in "renumbering" scenarios

[Michael Richardson <[e-mail]>]

Jan Zorz - Go6 <[e-mail]> wrote:
    > On 31/01/2019 13:11, Fernando Gont wrote:
    >>> Doesn't RFC7084 already say this? L-13.
    >> 
    >> Yes, and we missed this (thanks!). -- that said, we added this bullet
    >> for completeness sake. The case we care about in this doc is the
    >> reboot scenario.

    > However, RFC7084 is Informational and not Standard. I think this should

Additionally, when it comes to what the CPE can expect from the ISP, 7084 is
essentially a set of heuristics, and there is no document about what the
*ISP* can expect from the CPE.

We need to turn both in standards, with a clear palette of behaviours.

For instance, I'd like to see standardized support for:
Scenario A:
   a) do *not* number the PPP(oE) link in IPv6. (use LL only)
   b) ISP delegates /60 or bigger and the CPE uses an address out of it.

Scenario B:
   a) do *not* number the PPP(oE) link in IPv6. (use LL only)
   b) ISP delegates exactly a /64, and the CPE uses an address out of it,
      and uses the rest for tethering, single link.

Scenario C:
   a) number the PPPoE link with RA and/or DHCPv6.
   b) Use rfc6603 to clearly exclude the link prefix

Scenario D:
   a) number the link with a /64
   b) provide another /60+ if the CPE asks for it later on.

For ISPs, there is a major win to having the all of the customer prefixes in
a single prefix (routing entry), but it's hard to know which scenario is
going to occur.

There is not enough in RFC7084 for an ISP to provide requirements to PPPoE
termination vendors (DSLAM) or to CPE vendors.    In the work I did at
Finepoint, I basically had to invert 7084 to make my requirements, but I
couldn't be sure what CPEs would support which scenarios.

The Broadband Forum TR-187 is useful, but still has too much wiggle room.

I would be willing to co-author a document.