[ipv6-wg] IPv6 Prefix delegation BCOP version 3 is out...
Ondřej Caletka Ondrej.Caletka at cesnet.cz
Wed Jun 28 16:42:32 CEST 2017
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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3718 bytes Desc: Elektronicky podpis S/MIME URL: <https://lists.ripe.net/ripe/mail/archives/ipv6-wg/attachments/20170628/3ef82bfe/attachment.p7s>
[ ipv6-wg Archives ]