> Also its a good idea to encompass recommendations for p2p and loopbacks (and > for that matter any assignment where prefix length is going beyond /64 into > smaller subnets) into one standard track because the cautions and potential > overlap issues that may exist for a /127 would pretty much be similar for > /128 or any prefix that goes into the lower-64 bit territory...
> One major concern I have with using /127 and /128 on p2p and loopbacks > respectively is that we need to be careful that there are existing (ISATAP > etc) and potentially future implementations that would use/reserve bits in > the lower 64 bits -so unless we set aside bit boundaries in the lower 64 > bits, we are likely to overlap with these... which is why if we use /127 with > a whole /64 reserved for the p2p subnet, then it should be okay but if /127 > or /128s are numbered from the same /64 consecutively, then obviously its > likely that the reserved bits used by other implementations would overlap. > When this happens, any scenario where the router (which has this overlap) is > SRC/DST of packets would be confused whether to interpret those lower-64 bits > as simple global unicast prefix or try to treat the lower-64 bits in a > different way (according to the protocol implementation which is using that > bit pattern). a few general points: - the 64 bit boundary is a "policy". implementations should handle any prefix length. implementations should, and as far as I know do, consider all bits in the address as transparent. - a loopback interface using a /128 cannot by definition overlap with anything else. - for a point to point link the operator should know if there applications at either of two end points requiring the use of reserved addresses, if so the link must use a /64 otherwise /127 is fine. these are operational choices, and I don't see a need to change IPv6 addressing architecture or protocol specifications. cheers, Ole
smime.p7s
Description: S/MIME cryptographic signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
