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
smime.p7s
Description: Elektronicky podpis S/MIME
