>>> P.S.: This fix doesn't prevent the use of /127s (it's orthogonal), >> >> Unless you configure two /128's pointing to the remote side, which will >> then thus not be 'on-link for neighbor discovery, the little thing >> called the subnet anycast address will make sure that a /127 ptp simply >> does not work, unless you have a platform which disables the subnet >> anycast address of course. > [...] > > For the most part, i was trying to make it clear that I wasn't asking > about the fix in RFC 4443 from the point-of-view of "the ping-pong issue > is already fixed in RFC 4443... we don't need /127 prefixes!". (i.e., > I'm not against /127 prefixes... actually, I support the idea).
/127 gives you other things too. - those who use /31s for IPv4 today can continue the same practice (the resist change argument) - operators implicitly know the address of the other end - doesn't "waste" space (yeah, yeah... I know) one could equally just make a convention to use link-locals with fe80::1 and fe80::2 and /128s on each side if one needed global addresses for sources to traceroute etc. > But I'm still interested in knowing what's the downside of the fix in > RFC 4443 that I cited in my original post. Does it really kill performance? in the forwarding path one would have to check that incoming interface equals outgoing interface (done in existing redirect check anyway) and one would have to verify that the destination address is covered by a connected route on the outgoing interface. this shouldn't require additional lookups, but would require changes in silicon. cheers, Ole -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
