On 28/06/2017 16:42, Ondřej Caletka wrote:
Hi,
thanks for the effort put into this document. I have two bugreports:
Hey, Thnx for having a look! :)
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.
Nope. Using /127 or /126 prevents the attack. Allocating /64 for each /127 or /126 just makes it harder to sweep over several links and burn the ND anyway if all those subnets are connected to the same router. On the other hand, it's sane to allocate /64 for each link also out of easier administration purposes.
It could be solved by splitting those two pieces of information into two separate sentences:
Agree. That improves readability. Thnx!
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".
Agree. Look like we are heading for draft v.4 ;) Let's collect more feedback and then fix the text... Cheers and tnnx, Jan
Cheers,
-- Ondřej Caletka CESNET