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

[Jan Zorz - Go6 <[e-mail]>]

On 02/02/2019 19:42, JORDI PALET MARTINEZ wrote:
> When I started the work in RFC7084-bis (now draft-ietf-v6ops-transition-ipv4aas, waiting for the final IESG "go"), I was always thinking that it must become a standard, but the discussions in the WG didn't went that way.
> 
> I will be happy also to co-author if more work is needed in this direction.

Excellent!!!

Cheers, Jan

> 
> Regards,
> Jordi
>   
>   
> 
> -----Mensaje original-----
> De: ipv6 <[e-mail]> en nombre de Michael Richardson <[e-mail]>
> Fecha: sábado, 2 de febrero de 2019, 18:19
> Para: Jan Zorz - Go6 <[e-mail]>
> CC: <[e-mail]>
> Asunto: Re: A common problem with SLAAC in "renumbering" scenarios
> 
>      
>      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.
>      
>      --------------------------------------------------------------------
>      IETF IPv6 working group mailing list
>      [e-mail]
>      Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>      --------------------------------------------------------------------
>      
> 
> 
> 
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
> 
> 
> 
>