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

"Eric Vyncke (evyncke)" <evyncke@cisco.com> Sat, 29 September 2012 09:26 UTC

Return-Path: <evyncke@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D44721F858F for <ipv6@ietfa.amsl.com>; Sat, 29 Sep 2012 02:26:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.448
X-Spam-Level:
X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x86-1VquXlfn for <ipv6@ietfa.amsl.com>; Sat, 29 Sep 2012 02:26:27 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD2D21F857A for <ipv6@ietf.org>; Sat, 29 Sep 2012 02:26:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5062; q=dns/txt; s=iport; t=1348910787; x=1350120387; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yzdXsapUXWxzf3ahy/qUrPJMPWj6H/uhsgbA0JMN08Y=; b=TVmfzIdWafdpBdG5TjowDuFqEJqi1gdtK13tKWq9CAf4caw/+p4WgDf3 dTUn4MggHn1QSaTwn/kPSgkNkAm/Obz/yNrVQWlhDkp1D8IrqiqReH6+T yMtJOAcgrq8+w9Eo3nUFQEVqRyaWHLZQCIFSi0qY37qhXF0k5YZ28iMss M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAFu9ZlCtJV2c/2dsb2JhbABFhgu3KnyBCIIgAQEBBAEBAQ8BEBE6CwwEAgEIEQEDAQEBAgIGHQMCAgIlCxQBAgYIAgQOBQgah2MLmTeNG5JrgSGJfoU5MmADln6NLYFpgmeCFw
X-IronPort-AV: E=Sophos;i="4.80,507,1344211200"; d="scan'208";a="126621913"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 29 Sep 2012 09:26:27 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8T9QRFf008820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 29 Sep 2012 09:26:27 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.26]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Sat, 29 Sep 2012 04:26:26 -0500
From: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
To: Jon Steen <steenjj@gmail.com>
Subject: RE: IPv6 address assignment for strictly point-to-point links and Device Loopbacks
Thread-Topic: IPv6 address assignment for strictly point-to-point links and Device Loopbacks
Thread-Index: AQHNm5t5Zp7Pa1Uu3EOQ2IghPq2KW5ecoJGAgABm1ICABAoP4A==
Date: Sat, 29 Sep 2012 09:26:25 +0000
Message-ID: <97EB7536A2B2C549846804BBF3FD47E111838FA3@xmb-aln-x02.cisco.com>
References: <1348632032.36928.YahooMailClassic@web126005.mail.ne1.yahoo.com> <3C3333E3-9F4A-4522-94BD-F92B72C8B9A6@employees.org> <D80DAC61-5AA7-45EA-8262-0E0F386BCE42@gmail.com>
In-Reply-To: <D80DAC61-5AA7-45EA-8262-0E0F386BCE42@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.105.146]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19220.001
x-tm-as-result: No--57.498100-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "ipv6@ietf.org" <ipv6@ietf.org>, "Michael Behringer \(mbehring\)" <mbehring@cisco.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Sep 2012 09:26:28 -0000

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
> --------------------------------------------------------------------