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

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

Exactly, this is the reason why 99% of the CEs don't save this data in the flash, because it is prone to creating troubles and bringing the CE to a "brick" state.

I've seen that several times, having for example statistics written in the internal router flash, easily will break the router, or at least needed a factory reset or something similar. Alternatively using a "good quality" USB stick to save this kind of data, avoids the problem (most of the time, because from time to time I've got also good USBs being damaged after some months of usage).

I think for example, RIPE Atlas get the same problem from time to time, so the USBs get wrong. Sometimes reformatting is sufficient, but not always.

Mandating that in low cost CEs will mean CEs are no longer "low cost", unless new "safe" opensource ways to keep the flash are available and can be included in new firmware releases.

Regards,
Jordi
 
 

-----Mensaje original-----
De: ipv6 <[e-mail]> en nombre de Mikael Abrahamsson <[e-mail]>
Organización: People's Front Against WWW
Fecha: jueves, 31 de enero de 2019, 12:48
Para: Fernando Gont <[e-mail]>
CC: IPv6 Operations <[e-mail]>, "[e-mail]" <[e-mail]>
Asunto: Re: A common problem with SLAAC in "renumbering" scenarios

    On Thu, 31 Jan 2019, Fernando Gont wrote:
    
    > Any comments will be welcome.
    
    "   o  A CPE MUST record, on stable storage, the list of prefixes being
           advertised on each LAN segment."
    
    This is not always doable as some devices have very small flash with no 
    write-leveling, so doing this generally might ruin the flash cells on some 
    devices. This above requirement will drive cost, especially in the low end 
    market of HGWs.
    
           *  Any prefixes that were previously advertised via SLAAC, but
              that are not currently intended for address configuration, MUST
              be advertised with a PIO option with the "A" bit set to 1 and
              the "Valid Lifetime" and a "Preferred Lifetime" set to 0.
    
    Doesn't RFC7084 already say this? L-13.
    
    Another comment, typically the lifetime of the LAN PIO is capped at the 
    DHCPv6-PD WAN lease time. I couldn't find this requirement in RFC7084, but 
    I only searched for "lifetime". Anyhow, Openwrt does this and might be 
    good to mention.
    
    When the new prefix is received it'll most likely have a higher preferred 
    and valid lifetime, so hosts should use the new prefix just by means of 
    them preferring the higher preferred lifetime of that PIO. So the problem 
    is a bit less than you write in the draft.
    
    So while I am generally sympathetic to this draft and what it tries to 
    achieve (especially the part where it ties the router announcing something 
    to what it's later announcing, and lack of something means it's implicitly 
    zero preferred time for that), we need to figure out a few more things 
    first. RFC7084 was informational which made it fairly easy to get through, 
    now you're proposing a standards track document so we need to make sure 
    everything works. Changing all hosts is a big thing.
    
    -- 
    Mikael Abrahamsson    email: [e-mail]
    
    --------------------------------------------------------------------
    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.