See also: http://tools.ietf.org/html/draft-ietf-opsec-lla-only-01 which has been discussed today at the Large Interim Meeting
-éric > -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Jon > Steen > Sent: mercredi 26 septembre 2012 16:44 > To: Ole Trøan > Cc: Usman Latif; ipv6@ietf.org > Subject: Re: IPv6 address assignment for strictly point-to-point links and > Device Loopbacks > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
