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

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 27 September 2012 13:12 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 1CF2721F853D for <ipv6@ietfa.amsl.com>; Thu, 27 Sep 2012 06:12:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.552
X-Spam-Level:
X-Spam-Status: No, score=-103.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 Pj8bYSjMDvRQ for <ipv6@ietfa.amsl.com>; Thu, 27 Sep 2012 06:12:05 -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 95B6A21F851C for <ipv6@ietf.org>; Thu, 27 Sep 2012 06:12:05 -0700 (PDT)
Received: by iec9 with SMTP id 9so4963319iec.31 for <ipv6@ietf.org>; Thu, 27 Sep 2012 06:12:05 -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=Clhh3dmqMWVymT4V3aH2icUWZ6MS3H20DwJakg7jAi4=; b=LXEURm+LwdVWZoSFaGNq2MBxB1gfP9vmmchMsPC4RTSJstPRB7RuLB3pq9PElwSNmC N/X6iiDDVG9imw7jQ3Ak83CjGwzGpyETXPybLaY8vr17sRGEqcQzFxOICyxgnL4EV3B+ WzjzFxTLU3HUwnU8qjK5i5Ze5+ebV4nczu27KwHifefFJyNmpPSyeB5WvzAPLb8bSvvy 7OwmI3bwLg9Okjhxbw3CsHDryye63ywqNIZvdC9HZTL5WpDrnuS3PqgMdDPRn5eveq6l BxmwcefgICR7v2iBO4NoIFiFXspgFQPTAf0a5Qx1gGh1lliY5UOGoJZLv7EyE/z/jYXy 2ykQ==
Received: by 10.50.5.180 with SMTP id t20mr3561407igt.31.1348751525198; Thu, 27 Sep 2012 06:12:05 -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 aa4sm12649346igc.15.2012.09.27.06.12.00 (version=SSLv3 cipher=OTHER); Thu, 27 Sep 2012 06:12:00 -0700 (PDT)
Message-ID: <506450AA.90305@gmail.com>
Date: Thu, 27 Sep 2012 14:12:10 +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: <3C3333E3-9F4A-4522-94BD-F92B72C8B9A6@employees.org> <1348704486.49402.YahooMailClassic@web126005.mail.ne1.yahoo.com> <m2obks3wcx.wl%randy@psg.com> <5063DFC1.407@bogus.com> <D7F25F99-40BB-4EE7-AA68-45F23897D8E8@yahoo.com>
In-Reply-To: <D7F25F99-40BB-4EE7-AA68-45F23897D8E8@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: Thu, 27 Sep 2012 13:12:06 -0000

Usman,

On 27/09/2012 12:43, Usman Latif wrote:
> Hi Joel,
> 
> RFC 6164 overriding 3627 seems logical
> However, I am looking more from perspective of 5375

RFC 5375 is an Informational document. You are at liberty to read it or not,
and to make use of it or not.

RFC 6164 is a Standards track document. It is of course a voluntary standard
like all IETF standards, but if you claim to implement it, it clearly preempts
an older Informational document such as RFC 5375.

As SM reminded us, it was probably a mistake that RFC 6164 didn't formally
update RFC 5375, but so what? There are many minor inconsistencies between
RFCs. Please don't lose any sleep over it. As long as you aren't accidentally
running SLAAC on a pt2pt link, none of this matters, as far as I can see.

   Brian

P.S. I am now adding this thread to my "ietf-silly-subj" filter.