Re: IPv10.

Mark Smith <> Sat, 12 November 2016 03:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5621B1294C0; Fri, 11 Nov 2016 19:00:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.519
X-Spam-Status: No, score=-1.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2vW6TtEtx-pX; Fri, 11 Nov 2016 19:00:11 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 53207126D74; Fri, 11 Nov 2016 19:00:10 -0800 (PST)
Received: by with SMTP id 51so27250113uai.1; Fri, 11 Nov 2016 19:00:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gAK7xsiAyMAO1smRrPVEkK5twep+vo42Ai2Op74KYN0=; b=ZwS0ti0z7ze6+OODrCh9yijsPIbIrz7wyYiWuGPeog/D3PTcj1KsvY1XH3ZK30u6gF FOj1UDfJpW/wMWHAyGyKaM3NXvsnQ91UdHxbrHFYvpw7Xu6+MWPFeDCJWaC+wFjLCO+m iXuUEUPYqLiJJDuCv9bDvA4PUrrm5Ud87M2lb6F18KQly8EB5E4g63419nchCzuo2u97 SjRuGvdPl3+Xh6QwFh4ltDVUXTxZeBjhCMRJCA0EjOPnp7sBoegoUgLTPjndA/eVTtmX ArtmxnMuDojNEffFjjt60E8/lXkWZMGXytCowKbfAAeXd4JZgPAG6mFEYngSAPHXxqp4 LjrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gAK7xsiAyMAO1smRrPVEkK5twep+vo42Ai2Op74KYN0=; b=MVtj9l19V1aqZmYZqkExdupIF8UGv+2bylM3kvFFID+WcB1zLxBj4/mvHRXFToKOKo kRmUW6mC6cHZl0oaf6WMTHJQL+p1hALKlI+rpuDg4LWRZa9vK/aQ4qdAxwUX9lC7k8on bqEu5+ghJ8SVciIwDaKmK1uwLIH5wYN4jqpaqD3ZmRElylvoT3rDGMWByP6g5owjUfyT wkEH2uXqkO7sgRdyoh4Wb+PeZiyrtCwWJAKFMO+YC97Sjglc42R1IPg0D4gvM9Vb4mD6 wvx/D3W93/W4kK8StfCv/y7SlJb9NUnKBlBSik2d/CMksSd9Q6nwKykMjGMtUm+nN4Zp 3vbg==
X-Gm-Message-State: ABUngvdvtREzPxdcgjSTAUjyaYGqm/y44gYxqC1Vk2hPDwiPMTxpwgmZnrASjv6mkjpy0Cq2U3PE807HIqrIzg==
X-Received: by with SMTP id a7mr3471884uaa.95.1478919549383; Fri, 11 Nov 2016 18:59:09 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 11 Nov 2016 18:58:39 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
From: Mark Smith <>
Date: Sat, 12 Nov 2016 13:58:39 +1100
Message-ID: <>
Subject: Re: IPv10.
To: Brian E Carpenter <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: "" <>, "" <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 12 Nov 2016 03:00:12 -0000

On 12 November 2016 at 12:43, Brian E Carpenter
<> wrote:
> On 12/11/2016 14:15, Randy Bush wrote:
>>> Right now it seems that you have got a solution proposal
>>> for a problem, that is IMHO not very clearly described.
>> how about ipv4 and ipv6 are incompatible on the wire and this
>> has created a multi-decade ipv6 charlie foxtrot?
> Yes, I suggest mentioning that to Vint, Bob and a few others in 1977,
> so that they can design IPv4 with extensible addresses. People in
> 2016 will be grateful.

It looks like the first version of TCP from 1974 had them.


"4 bits: Length of destination network address in 4 bit units (current
   value is 1)

   4 bits: Destination network address

      1010-1111 are addresses of ARPANET, UCL, CYCLADES, NPL, CADC, and
      EPSS respectively.


   4 bits: length of source network address in 4 bit units (current
   value is 1)

   4 bits: source network address (as for destination address)"

or up to 60 bit addresses.

>From what I've read, there were proposals to do variable length
addresses in IPv6 as CLNS did, however there was a concern that it
would be harder to cope with them in hardware, and the observation
that even though CLNS supported them, everybody just used the same

More recently, I've heard of few organisations here in .au that have
run out of RFC1918s because they've been using /24s everywhere -
previously I only knew of Comcast running out for their cable modem
management network. I've also seen /24s universally being
"unnecessarily" used in virtual networks used to build virtual server

It seems most people will choose simple and consistent when they can
even though it is less efficient. There's operational value in that -
if all subnets are /24s or /64s, then one with an incorrect length
sticks out like a sore thumb. Less variables means less opportunity
for error and errors being far more obvious.