RE: IPv6 address assignment for strictly point-to-point links and Device Loopbacks

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-bounces@ietf.org [mailto:ipv6-bounces@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 <otroan@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
> --------------------------------------------------------------------