[ipv6-wg] IPv6 Prefix delegation BCOP version 3 is out...

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


-------------- 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/363ea8c1/attachment.p7s>