Dne 26.7.2017 v 13:18 Jan Zorz - Go6 napsal(a):
I introduced this text into section 4.1.5 and here comes the BCOP draft v.4 ;)
https://www.sinog.si/docs/draft-IPv6pd-BCOP-v4.pdf
Can you please all have a look if this document is now ready for publication? We are receiving many requests for a stable document on this topic - and we've been "babysitting" this one quite long enough.
Hello, sorry for another babysitting issue, but I still don't like this formulation 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).
Let me try to rephrase this paragraph:
Some operators also use /126, /127, /112 or an alternative prefix assignment instead of /64 for managed links where addresses on the link are manually configured, and according to RFC6164, a /127 is suggested, to prevent, among others, the Neighbor Discovery exhaustion attack (RFC6583). Please note, that not all equipment currently supports this option, so /64 is still the safest approach and has the advantage of being future proof in the event that new standards make usage of the other 64 bits for other purposes or the link becomes point-to-multipoint, etc. Furthermore, some ISP hardware has limitations in using prefixes longer than /64, so the use of non-/64 prefixes will use more resources on these devices. 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.
Other than that, I found no more issues. PS: I also noticed that https://www.sinog.si has an invalid TLSA record ;) -- Ondřej Caletka