Mark, I think this thread has shown convincingly that there is a problem with the current wording of 4291bis about the 64 bit IID length. I suggest that we wordsmith it on the 6man list and come back to this broader CC list when we have a proposal. Regards Brian On 14/01/2017 19:37, Mark Smith wrote: > On 14 Jan. 2017 15:36, "David Farmer" <farmer@xxxxxxx> wrote: > > > > On Fri, Jan 13, 2017 at 9:28 PM, Brian E Carpenter < > brian.e.carpenter@xxxxxxxxx> wrote: > >> .... >> >> >> Which is exactly why we have so far only delegated 1/8 of the >> IPv6 address space for global unicast allocation, leaving a *lot* >> of space for fixing our mistakes. Moving away from /64 as the >> recommended subnet size might, or might not, prove to be necessary in >> the long term future. That's why the point about routing being >> classless is fundamental. I do think we need to be a bit more >> precise on this point in 4291bis. >> >> Brian >> > > Exactly, /64 is the RECOMMENDED subnet size, or a SHOULD from RFC2119, and > I'm fine with that, but that's not what the following says. > > For all unicast addresses, except those that start with the binary > value 000, Interface IDs are required to be 64 bits long. Background > on the 64 bit boundary in IPv6 addresses can be found in [RFC7421 > <https://tools.ietf.org/html/rfc7421>]. > > > It says REQUIRED, that is a MUST from RFC2119, and I believe it to be an > Imperative as discussed in section 6 of RFC2119. > > I'm fine with /64, /127 and /128 as the RECOMMENDED subnet sizes, I support > that and believe it to be the consensus of the IETF. Maybe even explicitly > noting /65 through /126 are NOT RECOMMENDED subnet sizes, and not support > by SLACC. But it is not correct to say the /64 is REQUIRED. > > > I don't think /127s should really be recommended either. > > They don't guarantee that the ping pong problem is solved, because it > depends on both ends being configured with the /127 prefix length by the > operator or operators at each end if the link. There is no protocol > requirement that both ends of a link have the same prefix and prefix > length, nor is there any protocol checking of that condition. > > For example, if an ISP configures a /127 on their end of the customer's > link, but the customer just configures a default route on their end over > the link, it is a legitimate configuration by the protocols, Internet > access will work (so the customer might assume the link is configured > correctly), and yet the link is vulnerable to a ping pong attach despite it > "having" a /127 prefix. > > So it is a mitigation, however it relies on the operator or operators being > disciplined about the configuration, and comes at the cost of other things > that may be useful if a 64 bit IID was available e.g. protect against > discovery of link addresses via unsolicited inbound probing if the IIDs are > random (which may include static configuration of an offline generated > random 64 bit IID). > > Regards, > Mark. > > > I also believe RFC7608 supports this conclusion. > > Thanks. >