Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

[JORDI PALET MARTINEZ <[e-mail]>]

The problem is that if the router has been rebooted (example, power outage), then it doesn’t know what was the previous or new prefix (if it has changed).

 

So, even if the router follows RFC7084, it will not be able to “recognize” the change, unless the prefixes are “stored” in flash or other stable storage.

 

I’ve seen only one vendor doing that.


Regards,

Jordi

 

 

 

De: ipv6 <[e-mail]> en nombre de Tassos Chatzithomaoglou <[e-mail]>
Organización: Forthnet
Fecha: jueves, 31 de enero de 2019, 12:41
Para: Fernando Gont <[e-mail]>, "[e-mail]" <[e-mail]>, IPv6 Operations <[e-mail]>
Asunto: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

 

Isn't that handled by L-13 of RFC7084?

L-13:  If the delegated prefix changes, i.e., the current prefix is
          replaced with a new prefix without any overlapping time
          period, then the IPv6 CE router MUST immediately advertise the
          old prefix with a Preferred Lifetime of zero and a Valid
          Lifetime of either a) zero or b) the lower of the current
          Valid Lifetime and two hours (which must be decremented in
          real time) in a Router Advertisement message as described in
          Section 5.5.3, (e) of [RFC4862].
--
Tassos
 
Fernando Gont wrote on 31/1/2019 1:00 μμ:
Folks,
 
We have posted a new I-D discussing a problem that can arise in typical
deployment scenarios where the CPE obtains a prefix via DHCPv6-PD and
advertises a prefix on the LAN side.
 
Our draft is available at:
https://tools.ietf.org/html/draft-gont-6man-slaac-renum
 
 
The Abstract is:
   A very common IPv6 deployment scenario is that in which a CPE employs
   DHCPv6 Prefix Delegation to obtain an IPv6 prefix, and at least one
   prefix from within the leased prefix is advertised on a local network
   via SLAAC.  In scenarios where e.g. the CPE crashes and reboots,
   nodes on the local network continue using outdated prefixes which
   result in connectivity problems.  This document analyzes this problem
   scenario, and proposes workarounds.
 
Any comments will be welcome.
 
Thanks!
 
Cheers,

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