Re: [v6ops] Fw: New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt

Owen DeLong <owen@delong.com> Thu, 21 February 2013 07:10 UTC

Return-Path: <owen@delong.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E32A021F8DD7 for <v6ops@ietfa.amsl.com>; Wed, 20 Feb 2013 23:10:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.418
X-Spam-Level:
X-Spam-Status: No, score=-0.418 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_RAND_1=2]
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 uiNN8uZ2W34V for <v6ops@ietfa.amsl.com>; Wed, 20 Feb 2013 23:10:43 -0800 (PST)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id A1CA521F8E0A for <v6ops@ietf.org>; Wed, 20 Feb 2013 23:10:43 -0800 (PST)
Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r1L76BX6018096 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Feb 2013 23:06:11 -0800
X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1L76BX6018096
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1361430371; bh=cxFdPSm+3OB4QeICkMSLELwFF5A=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ZUemLRRAm2AgT2VnglV2r+rlcIE7fEuJp+oeG/TobI3qR1Urtl0Fxw1HsgWhqmY0a s0bdKsacs9zpAqSWQFwNK5wTu/jyniJP30jC+PrQ54xYec6ZgHevlUk+jV+WDtUjn6 gwTcu+aZ0ntlNvLBSBB5lI4WHF8fcFd2MiaE0rx4=
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <1361427742.78324.YahooMailNeo@web142504.mail.bf1.yahoo.com>
Date: Wed, 20 Feb 2013 23:06:08 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <5B975716-59C8-4F7C-9C6F-373A150EE4D1@delong.com>
References: <20130220191706.20280.59416.idtracker@ietfa.amsl.com> <1361388476.43517.YahooMailNeo@web142501.mail.bf1.yahoo.com> <B9CA20D6-4142-4CE9-8062-36DA54DF0AB5@delong.com> <1361392079.27417.YahooMailNeo@web142501.mail.bf1.yahoo.com> <20130221012540.B3D192FECCED@drugs.dv.isc.org> <1361416048.43450.YahooMailNeo@web142504.mail.bf1.yahoo.com> <20130221052919.57DD52FEE70B@drugs.dv.isc.org> <1361427742.78324.YahooMailNeo@web142504.mail.bf1.yahoo.com>
To: Mark Smith <markzzzsmith@yahoo.com.au>
X-Mailer: Apple Mail (2.1499)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 20 Feb 2013 23:06:11 -0800 (PST)
Cc: v6ops v6ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] Fw: New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Feb 2013 07:10:45 -0000

>>> 
>>> 1. it has been easy to remember
>> 
>> so is fc00::/48
>>  
> 
> sigh. RFC4193:
> 
> "3.2.  Global ID
> The allocation of Global IDs is pseudo-random [RANDOM].  They MUST NOT be assigned sequentially or with well-known numbers."
> 
> Given your name is on the top of RFC6303, I'd have thought you'd agree it is important to follow what is in them.
> 

RFC4193 does not apply to fc00::/48. It only applies to fd00::8. fc00::/8 currently has no RFCs specifying it other than the part of 4193 that says it is intended for globally unique registered ULA. However, the companion RFC that provided for that failed to gain consensus, so fc00::/8 is actually in limbo. As far as I'm concerned, this would be a perfectly fine use of fc00::/48 as the first registered ULA.

Further, when considering RFCs in a particular use case, I think it is important to apply the context of WHY the RFC says what it says. In this case, there is no downside to (mis)using ULA in this way on a local basis because you can choose a non-conflicting ULA prefix pretty easily. Afterall, all that is required is that it not conflict with ULA in use by any of the machines that your test subject will be sending packets to.

Blind adherence to the RFCs without context is almost as silly as blind ignorance of them.

Owen