On 27/07/2017 17:49, Ondřej Caletka wrote: > 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.
Hi, Thnx for this add-on. I fixed the text and here it goes the v.5 (hopefully the last one, if the stars are positioned properly ;) ) https://www.sinog.si/docs/draft-IPv6pd-BCOP-v5.pdf > > Other than that, I found no more issues. > > PS: I also noticed that https://www.sinog.si has an invalid TLSA > record ;) Thnx for pointing this out. It was not the TLSA taht was broken, it was my dnssec signer that played some tricks, but on that domain only. Go-figure ;) It should be fixed now. Cheers and thnx, Jan
smime.p7s
Description: S/MIME Cryptographic Signature
