This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[ipv6-wg] IPv6 Prefix delegation BCOP version 3 is out...
- Previous message (by thread): [ipv6-wg] IPv6 Prefix delegation BCOP version 3 is out...
- Next message (by thread): [ipv6-wg] IPv6 Prefix delegation BCOP version 3 is out...
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
JORDI PALET MARTINEZ
jordi.palet at consulintel.es
Wed Jun 28 17:20:12 CEST 2017
Hi Ondrej, I agree with our first proposed change. However, I think you didn’t got the other one. The IPv4 model is NAT, so the addresses inside the customer network aren’t affected by non-persistent CPE WAN addressing, because internally is not “seen”. Regards, Jordi -----Mensaje original----- De: ipv6-wg <ipv6-wg-bounces at ripe.net> en nombre de Ondřej Caletka <Ondrej.Caletka at cesnet.cz> Responder a: <Ondrej.Caletka at cesnet.cz> Fecha: miércoles, 28 de junio de 2017, 16:42 Para: <ipv6-wg at ripe.net> Asunto: Re: [ipv6-wg] IPv6 Prefix delegation BCOP version 3 is out... Hi, thanks for the effort put into this document. I have two bugreports: In section 4.1.1: > If we decide to use /127 for each point to point link, then it is also advisable to > allocate a /64 for each link and use just one /127 out of it to prevent the Neighbor Discovery > exhaustion attack (RFC6583). My understanding of this sentence is that allocating /64 somehow prevents Neighbor Discovery exhaustion attack. It could be solved by splitting those two pieces of information into two separate sentences: > Using /127 for each point to point link can, on the other hand, prevent the Neighbor Discovery exhaustion attack (RFC6583). > To avoid possible renumbering in the future, it is always advisable to allocate a /64 for each link and use just one /127 out of it. In section 5.1: > Bear in mind that end customers with an IPv4 subnet behind their CPE never got > “non-persistent” assigned IPv4 prefixes as this would require reconfiguration of all hosts on > their network every few hours or days. By contrast, every IPv6 customer gets an IPv6 subnet > so it is unnecessary to apply this “IPv4 model” to IPv6. I don't really understand the last sentence. Which "IPv4 model" is unnecessary to apply to IPv6? The model of static leases? I would propose something like: > > By contrast, every IPv6 customer gets an IPv6 subnet, so keeping customer's IPv6 subnet persistent follows perfectly the "IPv4 model". Cheers, -- Ondřej Caletka CESNET ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
- Previous message (by thread): [ipv6-wg] IPv6 Prefix delegation BCOP version 3 is out...
- Next message (by thread): [ipv6-wg] IPv6 Prefix delegation BCOP version 3 is out...
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]