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

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 21 September 2012 23:06 UTC

Return-Path: <brian.e.carpenter@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 C26E021E8096 for <ipv6@ietfa.amsl.com>; Fri, 21 Sep 2012 16:06:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.572
X-Spam-Level:
X-Spam-Status: No, score=-103.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 vcmFnGF+8w4r for <ipv6@ietfa.amsl.com>; Fri, 21 Sep 2012 16:06:01 -0700 (PDT)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 218F621E8092 for <ipv6@ietf.org>; Fri, 21 Sep 2012 16:06:01 -0700 (PDT)
Received: by iec9 with SMTP id 9so7618766iec.31 for <ipv6@ietf.org>; Fri, 21 Sep 2012 16:06:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8GU9H74E1j/LgYhJnWMN+kjoPOAvh0c+tO5sMyNBkU0=; b=OIIpXY5axRvv/5RAymNbx/afoNvpHeLSzoxswsaSzL8P+W5EUY2HrXQGBR6UecOuvS /4CVoTC99503kqTmYOlecuh7MKfzDM5Zxvtnb7EnsI7jajbyMN7X/Jj+nCi9TQhHBLHt cEVAOaGX/0RD/estRiiRRg9qlOl4i5rfmVfIM2dBHnmZEr8Mm/WGRk1nyWbxGuuSzkvN EzOtvJXmb2CA7854YhZKzdIIn81J5xCLTRAQLX8xc7YjJ44zEk5yRCZ6ZzIFdOlUPbBc +ZLKNASetBnVwpiISK4jBM4/FLrWQkvOoao3rjh6qmTEA6TZIBLlykc5hayAqlPFia3o tr/A==
Received: by 10.50.190.197 with SMTP id gs5mr315254igc.32.1348268760313; Fri, 21 Sep 2012 16:06:00 -0700 (PDT)
Received: from [10.255.25.102] (50-76-68-140-static.hfc.comcastbusiness.net. [50.76.68.140]) by mx.google.com with ESMTPS id uq6sm176611igb.14.2012.09.21.16.05.59 (version=SSLv3 cipher=OTHER); Fri, 21 Sep 2012 16:05:59 -0700 (PDT)
Message-ID: <505CF2DC.3050401@gmail.com>
Date: Sat, 22 Sep 2012 00:06:04 +0100
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Usman Latif <osmankh@yahoo.com>
Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks
References: <1348211033.52674.YahooMailClassic@web126005.mail.ne1.yahoo.com> <CALOgxGZ6QLhuoVoqpt+R6paLThEs1zBHBgYzVXuvOqWSdrD9ZA@mail.gmail.com> <0BB03569-6F5F-43AC-9012-C82C85A43C00@yahoo.com> <2671C6CDFBB59E47B64C10B3E0BD59235F961497@PRVPEXVS15.corp.twcable.com> <A882F196-C47E-4AF0-962B-7DE9CD15584A@yahoo.com>
In-Reply-To: <A882F196-C47E-4AF0-962B-7DE9CD15584A@yahoo.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "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: Fri, 21 Sep 2012 23:06:01 -0000

On 21/09/2012 22:35, Usman Latif wrote:
> Thanks Wes for the feedback.

...
>>>> Without this stated clearly there is likely to be some instances where readers interpret it the wrong way and end up assigning multiple p2p links with /127 subnets from a single given /64 and end up having to re-address their network in future when/if future standards use lower order 64 bits for special purposes.
>> [WEG] Given the fact that there is a standard that documents the use of a /127 for P2P links (6164), 

Wes, I think that statement is even a bit weak, since 6164 actually says:

"assuming that a number of point-to-point links will be numbered out of a single /64 prefix:"

so it is very clear: it is allowed by the standard to share a /64 among
however many pt2pt links the operator cares to. This is *not* a wrong
interpretation.

As you say, any future work will need to take account of this.

   Brian