Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00

Owen DeLong <> Mon, 19 August 2013 17:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 179BB11E8145 for <>; Mon, 19 Aug 2013 10:56:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.368
X-Spam-Status: No, score=-1.368 tagged_above=-999 required=5 tests=[AWL=-1.232, BAYES_00=-2.599, FRT_LOLITA1=1.865, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hm6zXfLlU-sW for <>; Mon, 19 Aug 2013 10:56:18 -0700 (PDT)
Received: from ( [IPv6:2620:0:930::200:2]) by (Postfix) with ESMTP id 20E7821F9263 for <>; Mon, 19 Aug 2013 10:56:18 -0700 (PDT)
Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by (8.14.2/8.14.1) with ESMTP id r7JHqGfK006739 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 19 Aug 2013 10:52:16 -0700
X-DKIM: Sendmail DKIM Filter v2.8.3 r7JHqGfK006739
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple;; s=mail; t=1376934737; bh=GQi+bwoKS5gFJWZIkiqmgV3tVyE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=HSbb5ltAKU27Y1YauRfOaQyxcn2gvMMol28FPM1Zuw+1k4p7n7LwpgvbZV4uC3f4V wrlrTj0e0nUiqEjCaUv5bnW0LeSdcSxS9Ybe4DqFYXdN9FyMdV6lo5zJVfbYukRNUg xIWK4/qFHTssAQ5B2Zzr5aj+teeB7Ywp1ObQVdd4=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Owen DeLong <>
In-Reply-To: <>
Date: Mon, 19 Aug 2013 10:52:15 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <20130819123450.GY65295@Space.Net> <>
To: "Fred Baker (fred)" <>
X-Mailer: Apple Mail (2.1508)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 ( [IPv6:2620:0:930::200:2]); Mon, 19 Aug 2013 10:52:17 -0700 (PDT)
Cc: Alejandro Acosta <>, "" <>, " WG" <>
Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Aug 2013 17:56:19 -0000

I think all of Fred's recommendations below are spot on. I support the changes and I like the idea of 2001:db0::/28.

In such a case, should we stick with fc00:db8::/44 or should we consider fc00:db0::/28 for parity? I'm OK either way, just looking to minimize potential confusion and wondering if the tradeoff in space is worth while or not. What do others think?


On Aug 19, 2013, at 10:38 , "Fred Baker (fred)" <> wrote:

> On Aug 19, 2013, at 5:34 AM, Gert Doering <> wrote:
>> 2001:db8 came from APNIC, that's why :-) - their delegated file lists
>> apnic|AU|ipv6|2001:db0::|32|20031112|allocated
>> apnic|AU|ipv6|2001:dc0::|32|20030124|assigned
>> so an extention to /29 would technically be possible, to a /28 won't.
> Hmm. Tell me about 2001:da0:: and 2001:d80::? Per
>> apnic|AU|ipv6|2001:7fa:b::|48|20050922
>> apnic|AU|ipv6|2001:7fa:c::|48|20050922
>> apnic|AU|ipv6|2001:7fa:d::|48|20050922
>> apnic|AU|ipv6|2001:7fa:e::|48|20050922
>> apnic|ID|ipv6|2001:7fa:f::|48|20050929
>> apnic|CN|ipv6|2001:7fa:10::|48|20060531
>> apnic|AU|ipv6|2001:7fa:11::|48|20061031
>> apnic|AU|ipv6|2001:dc0::|32|20030124
>> apnic|TW|ipv6|2001:dc1::|32|20030331
>> apnic|JP|ipv6|2001:dc2::|32|20030529
>> apnic|JP|ipv6|2001:dc3::|32|20030619
> To my small mind, that suggests 2001:d80::/26 (64 prefixes), 2001:da0::/27 (32), 2001:db0::/28 (16), or 2001:db8::/29 (8). Shorter than /26 includes 2001:dc0:: and 2001:de0::, which have been allocated. The neighborhood, however, includes 2001:db8::, which we already use. I, for one, would like to see one documentation range, at least for the global unicast address space, which is to say a prefix shorter than and including 2001:db8::/32.
> notes that 2001:DB8::/29 is reserved and by definition available.
> I note that we are not discussing the recommendation per se; we are narrowing in on the length of the prefix. Unless someone disagrees, I think we have pretty much agreed that something shorter than /32 makes sense.
> Here's my suggestion. The 6man chairs tell me that RFC 3489 was their work group product, so it's replacement should be. I'd suggest respinning the draft as draft-moreiras-6man-rfc3849bis (and tell that it replaces this one). You want to do two separate things:
> a) argue for a shorter prefix in 2000::/3, and make a separate-but-analogous argument for a prefix in fc00::/8.
> In those, focus on need, not want. "We designed a lab that has 2^128 different addresses in it, we obviously need the entire IPv6 address space" doesn't follow. Say what you *need* and why you *need* it. While the request was for a /20, I have not heard a cogent argument for a /26 or shorter, I heard that there was a training lab somewhere that required a /27 (32 /32s) but have not heard that the intent of the lab could not have been done with 16 /32s, and observe that a nibble boundary would suggest a /28 (16 /32s).
> b) in the IANA considerations section, note:
> b.1) the availability of 2001:d80::/26, 2001:da0::/27, 2001:db0::/28, or 2001:db8::/29
> b.2) the suggestion of fc00:db8:?::/44, which I think we more or less agreed to in the thread
> b.3) the fact that this would also affect
> _______________________________________________
> v6ops mailing list