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

Jon Steen <steenjj@gmail.com> Wed, 26 September 2012 14:44 UTC

Return-Path: <steenjj@gmail.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 A429721F884D for <ipv6@ietfa.amsl.com>; Wed, 26 Sep 2012 07:44:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
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 H4W6WlG8f-rh for <ipv6@ietfa.amsl.com>; Wed, 26 Sep 2012 07:44:23 -0700 (PDT)
Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id D9D5F21F885D for <ipv6@ietf.org>; Wed, 26 Sep 2012 07:44:22 -0700 (PDT)
Received: by qaec10 with SMTP id c10so5378681qae.10 for <ipv6@ietf.org>; Wed, 26 Sep 2012 07:44:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=87BjBlAWF0nSDlWJXayn7DpQTl9UDN7cej0epKlyMYo=; b=BblilTr72eDqCib7f/YsFacYAOuDVmRTOysTviOyziy0OntZZ4iyD6e4l6cMBToQAq 4FqtAuuyUpEP9QOuIlAAzm9Mca1leBMKZQS5LRKGthUMtuYmKnsbzmvqAB1uCz8WBcQO grAMf1Brst/fwSJ6o6SgkZt5Yyma9hk2SDFHPYw90zhi1toyh1f/uF0QTyCjagJLNyPo 5tQ9vhKUBXpoev/KsJzJ8p31nhuzvIaFhfBHtGgMWRIITNOnMNu9GIRoP6z2E0do5/eK +Ldu1/HPL/8kF+PGA2R4wrtIDMNhv53izjxVjQwZNEv6Ch3HlQXl1gj2+FnYS2GsQjOh 68CQ==
Received: by 10.229.136.79 with SMTP id q15mr466253qct.123.1348670662354; Wed, 26 Sep 2012 07:44:22 -0700 (PDT)
Received: from [10.132.43.232] (mobile-198-228-193-165.mycingular.net. [198.228.193.165]) by mx.google.com with ESMTPS id ck11sm4961481qab.17.2012.09.26.07.44.18 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 26 Sep 2012 07:44:21 -0700 (PDT)
References: <1348632032.36928.YahooMailClassic@web126005.mail.ne1.yahoo.com> <3C3333E3-9F4A-4522-94BD-F92B72C8B9A6@employees.org>
In-Reply-To: <3C3333E3-9F4A-4522-94BD-F92B72C8B9A6@employees.org>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=utf-8
Message-Id: <D80DAC61-5AA7-45EA-8262-0E0F386BCE42@gmail.com>
X-Mailer: iPhone Mail (9B206)
From: Jon Steen <steenjj@gmail.com>
Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks
Date: Wed, 26 Sep 2012 10:44:13 -0400
To: =?utf-8?Q?Ole_Tr=C3=B8an?= <otroan@employees.org>
Cc: Usman Latif <osmankh@yahoo.com>, "ipv6@ietf.org" <ipv6@ietf.org>
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: Wed, 26 Sep 2012 14:44:23 -0000

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