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

"Fred Baker (fred)" <> Mon, 19 August 2013 17:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA71511E8131 for <>; Mon, 19 Aug 2013 10:38:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -109.637
X-Spam-Status: No, score=-109.637 tagged_above=-999 required=5 tests=[AWL=-0.902, BAYES_00=-2.599, FRT_LOLITA1=1.865, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ejmg6Rt+N3n0 for <>; Mon, 19 Aug 2013 10:38:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A2B8611E813D for <>; Mon, 19 Aug 2013 10:38:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3852; q=dns/txt; s=iport; t=1376933905; x=1378143505; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=PzUQX/KYE/26c7+FrTXcta1WK/LCQTRUn/tkaF4GUew=; b=fVwQffPXiIFUNnq3M4jgG4W6zITSlZA66CUCPsVmY9Thfz76feMG9S87 ZqLIwfw+TLHuDDgn+b2prblIYgbLqQlfSDWFAES9IkK9JhSbu3q6XKTxL TkEqMT4t8OGaGCIyk0zjcaderHPYmy95jR+EOMfzEEtX+F1qMJezKCBdz Y=;
X-Files: signature.asc : 195
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkFAJ5WElKtJXG9/2dsb2JhbABagwc1Ub8ygSMWdIIkAQEBAwF5BQsCAQgiJDIlAgQBDQUIAQUOh24GDLYgkCsxB4MbdwOQFoEul3WDHIIq
X-IronPort-AV: E=Sophos; i="4.89,914,1367971200"; d="asc'?scan'208"; a="249088601"
Received: from ([]) by with ESMTP; 19 Aug 2013 17:38:25 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r7JHcPDL027819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 19 Aug 2013 17:38:25 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Mon, 19 Aug 2013 12:38:24 -0500
From: "Fred Baker (fred)" <>
To: "Antonio M. Moreiras" <>, Alejandro Acosta <>
Thread-Topic: [v6ops] draft-moreiras-v6ops-rfc3849bis-00
Thread-Index: AQHOnQLnfxLPnI7P/02x30eIFMb3Rg==
Date: Mon, 19 Aug 2013 17:38:24 +0000
Message-ID: <>
References: <> <> <> <20130819123450.GY65295@Space.Net>
In-Reply-To: <20130819123450.GY65295@Space.Net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_3EFB6E92-EFBD-4316-AA73-9A77E7295F90"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Cc: "" <>, " 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:38:30 -0000

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