[ipv6-wg] IPv6 Prefix delegation BCOP version 3 is out...
Jan Zorz - Go6 jan at go6.si
Wed Jun 28 17:25:39 CEST 2017
On 28/06/2017 17:20, JORDI PALET MARTINEZ wrote: > 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”. Jordi, Ondrej is right. That sentence reads as that we are applying the "IPv4 prefix delegation" model to IPv6. Now, or we do it as Ondrej suggested (I like his proposal), or we make sure that "IPv4 model" says that that is a NAT model - and maybe even add Ondrej's suggestion as an additional information. Cheers, Jan > > 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. > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3976 bytes Desc: S/MIME Cryptographic Signature URL: <https://lists.ripe.net/ripe/mail/archives/ipv6-wg/attachments/20170628/b566584a/attachment.p7s>
[ ipv6-wg Archives ]