[lacnog] Problemas en torno a SLAAC/DHCPv6-PD (nuevo IETF I-D)

JORDI PALET MARTINEZ jordi.palet en consulintel.es
Vie Feb 1 05:48:49 -02 2019


I miss this in the previous email: It is not correct the thing about dynamic prefixes in Germany.

It seems there was some misinformation about that several years ago. I've checked it with several sources. Last time I checked was precisely last week.

Regards,
Jordi
 
 

-----Mensaje original-----
De: LACNOG <lacnog-bounces en lacnic.net> en nombre de Fernando Frediani <fhfrediani en gmail.com>
Responder a: Latin America and Caribbean Region Network Operators Group <lacnog en lacnic.net>
Fecha: viernes, 1 de febrero de 2019, 4:07
Para: Latin America and Caribbean Region Network Operators Group <lacnog en lacnic.net>
Asunto: Re: [lacnog] Problemas en torno a SLAAC/DHCPv6-PD (nuevo IETF I-D)

    Hello
    
    On 31/01/2019 18:17, Fernando Gont wrote:
    >
    > That's one side of it. The other side of allocating stable prefixes is
    > that such practice renders things like temporary addresses rather
    > irrelevant: no matter how much the Interface-ID changes, you can still
    > correlate network activity via the Prefix (because it's stable).
    >
    > It would seem that in some countries (e.g., Germany) it's actually
    > *required* that CPEs default to dynamic prefixes.
    
    Humm, interesting to force to dynamic prefixes. I just hope their law 
    forces ISPs also to record each and every prefix that is given to a 
    client and make possible to identify which connection was used to commit 
    a crime for example.
    Where that is not a obligation other than solving this issue related in 
    the previous message having a stable prefix makes easier for the ISP to 
    identify someone when necessary and means less logging. But in the other 
    hand I see your point some people may not like to be identified by 
    websites and applications always behind the same prefix I guess, 
    although that happens a lot in other type of connections like Corporate 
    connections with that static prefixes allocated.
    
    >
    > It would seem this mechanism wouldn't help, since it kicks in when a
    > router ceases to advertise a prefix it used to advertise, and advertise
    > a different prefix in return. In the scenario you describe, I guess the
    > lower-priority router would refrain/stop advertising its prefix but
    > wouldn't "replace" the new prefix with a different one.
    Actually the scheme should be something like: 1) Both CPEs advertises 
    their Prefixes to the LAN but with different priorities, so devices in 
    the LAN will go out via the highest CPE gateway 2) When the WAN 
    connection of the higher priority CPE is lost RA should set Lifetime to 
    0, stop advertising the prefix and set the deprecate flag to true 3) 
    Devices in the LAN should pick up that and start using the prefix and 
    default gateway announced from the lower priority CPE.
    
    Not sure if I missed or confused something.
    
    Fernando
    _______________________________________________
    LACNOG mailing list
    LACNOG en lacnic.net
    https://mail.lacnic.net/mailman/listinfo/lacnog
    Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
    



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





Más información sobre la lista de distribución LACNOG