Some vendors are permitting the use of the link local interface address to be used in next hop routing there for negating the need to us additional unicast addresses on P2P links. When using routing protocols of OSPFv3 and BGP, I have used /128 loopback global unicast and configured advertisements for aggregated prefixes between a /32 and /64 with policy based routing. This has minimized the potential for overlap and has also allowed the routing tables to be much smaller. Has anyone else tried this approach?
V/R Jon Steen On Sep 26, 2012, at 4:36 AM, Ole Trøan <otr...@employees.org> wrote: >> 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 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
