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

Usman Latif <osmankh@yahoo.com> Thu, 27 September 2012 21:39 UTC

Return-Path: <osmankh@yahoo.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 44C8521F8594 for <ipv6@ietfa.amsl.com>; Thu, 27 Sep 2012 14:39:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level:
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
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 lteV3jnx-hvY for <ipv6@ietfa.amsl.com>; Thu, 27 Sep 2012 14:39:12 -0700 (PDT)
Received: from nm3.bullet.mail.ne1.yahoo.com (nm3.bullet.mail.ne1.yahoo.com [98.138.90.66]) by ietfa.amsl.com (Postfix) with SMTP id 3C52A21F8582 for <ipv6@ietf.org>; Thu, 27 Sep 2012 14:39:12 -0700 (PDT)
Received: from [98.138.90.50] by nm3.bullet.mail.ne1.yahoo.com with NNFMP; 27 Sep 2012 21:39:07 -0000
Received: from [98.138.226.163] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 27 Sep 2012 21:39:07 -0000
Received: from [127.0.0.1] by omp1064.mail.ne1.yahoo.com with NNFMP; 27 Sep 2012 21:39:07 -0000
X-Yahoo-Newman-Id: 242697.4072.bm@omp1064.mail.ne1.yahoo.com
Received: (qmail 51665 invoked from network); 27 Sep 2012 21:39:06 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=DKIM-Signature:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:In-Reply-To:Mime-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=6swwaFNg48UtU+Ka/LPADA2OQVkVykRjc4CIyQH5Z0BcV1uco1bnYNr3zgctji3eMEO34P9eQhJ9++taQZqyzXtuweh7Fg0c4EP5lMItp2o3geJ3K45APdpsSniPhNUNc8xwjzoQ0IZjJwBOMyYPSr14y4QaOnX3C8dMDo2j4NE= ;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1348781946; bh=pPu/wCTfO/SYE/uOoce0ivu9iZ4G/N8lXRX8Gg6Nmjw=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:In-Reply-To:Mime-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=rTlA6mNa2UppS7K5aidrg+Ej15qSK8N+yrP0huzz4SC3UB0AsFUGfpNfeV1NC34tDnUbE4aGzmlnWLcsRpH3vQAHiqUboaO5oi/sGt+YFIWKXMnofrTzvw1uaUJfNHLZD3CsHsB+ed8yfRkgP4aZGhq5llr6NejQ377fDHGA8z0=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: 1G7AXGQVM1llOOSxr2pc5yWrKpWojC0Xy.1HYjsKTZEAfzx 5Xwfy2.XwAFU3L3osbHlBYx2Rp3vpKD_ohTJo6j6eOc.aj4IKT96FV9eq4RQ vRfP1Td7qrn2BpDJ7b6htKKXsp98GmbkdtyOCOF9cxLa8A1_bxX6GyGF0kXA olI2FbiBR8xIMPzm2Hi_vAsvjA._8BngQHEwyezRunQNtSv7DzG.T08d9rzE uNwTTOntFf2pNNWiTmfjJdleHfS1yUnkXJpf2sVESo3SyIE46i7PunAwGgvM _oKx_GQ.vZTtvMnZybdpi5Jv19TCOVwPM0Azk_uOTQwCcDC9ClNOGaJXfAVh V0vwtnqAlcrro4AU2_8p1jLNtLDsb4g_aULx5gAtpMOYMks30YE15uGbJeQ2 AmDeVyXw8tIxTAlj3efFy.Rw.uLubz9guhYbGoyquHZNW.ZypjWPCR0boHBY xE7q3CEc-
X-Yahoo-SMTP: RUL5CFuswBD02LFE5KfPCwZifSs-
Received: from [10.4.103.201] (osmankh@49.176.100.84 with xymcookie) by smtp104-mob.biz.mail.gq1.yahoo.com with SMTP; 27 Sep 2012 14:39:06 -0700 PDT
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> <506450AA.90305@gmail.com> <9467057F-773B-43DB-8719-AC9AEEF2DA7D@yahoo.com>
In-Reply-To: <9467057F-773B-43DB-8719-AC9AEEF2DA7D@yahoo.com>
Mime-Version: 1.0 (1.0)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <BFCD291A-3D82-458A-AACC-6DA2563B2D67@yahoo.com>
X-Mailer: iPhone Mail (9B206)
From: Usman Latif <osmankh@yahoo.com>
Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks
Date: Fri, 28 Sep 2012 07:39:00 +1000
To: Usman Latif <osmankh@yahoo.com>
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 21:39:13 -0000

(Hopefully) my last email on this topic:

- Not only has RFC 6164 failed to properly update RFC 5375 with any reasoning provided for 5375 section(s) B.2.xx

- It has also defied and failed to update RFC 4291 which says (section 2.5.1) - "For all unicast addresses, except those that start with binary value 000, interface IDs are required to be 64 bits long"

- IMO 6164 seems to be justifying actions of those deployments where ppl have simply gone ahead and deployed /127s without properly doing their homework on v6 addressing

- This has put a constraint on greenfield deployments where we are in a position to implement /64s but are now having to deal with a compromise for existing deployments

- We are fine to follow 6164, but since RFCs come and go, if tomorrow the applications demand specific use of interface identifiers in the lower 64-bit space, and you folks send out a new RFC to override 6164, then we'll be required to re-address our network - then "I Will Come Back To Haunt You Guys - if I am alive" :)

Pls don't take me the wrong way, I have read many RFCs and think you have done a great job buy I was never confused the way I am now after successively going through 3627, 4291, 5375 and now 6164....

Regards,
Usman

Sent from my iPhone


On 28/09/2012, at 3:38 AM, Usman Latif <osmankh@yahoo.com> wrote:

> I'll conclude on the following points:
> 
> i. The only guidance that's out there today for device loopbacks (whether informational or standards track) is 5375 -because 6164 (whether voluntarily or involuntarily) chose not to provide any considerations for /128 loopbacks
> 
> ii. A reader following considerations of /128 from 5375 is led to also consider B.2.4  B.2.6 and B.2.7 for any prefixes where the subnet length is longer than /64
> 
> iii. If 6164 overrides any previous RFCs, IMO it should provide some reasoning of why it no longer felt that the sections B.2.4. B.2.6 and B.2.7 of 5375 should be considered
> 
> 
> 
> Sent from my iPhone
> 
> On 27/09/2012, at 11:12 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
>> 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.
>