Re: [mpls] Available IP version numbers.

"Joel M. Halpern" <jmh@joelhalpern.com> Mon, 19 April 2021 19:04 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881013A3F60 for <mpls@ietfa.amsl.com>; Mon, 19 Apr 2021 12:04:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level:
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxjTITvC6qXP for <mpls@ietfa.amsl.com>; Mon, 19 Apr 2021 12:04:05 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC0FF3A3F56 for <mpls@ietf.org>; Mon, 19 Apr 2021 12:04:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4FPGSj1cQsz6G9vt; Mon, 19 Apr 2021 12:04:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1618859045; bh=2BKo9f3P24ib6+vn5c9v8c5Lj1AUpTQL2dKct4ixGEw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=l6AEoEwgxq++4BV7V5o1vSBLM8nSl+/ZZ5ddWsOAMTZ9vMO+IE5AMPcairbKQn9Ha LFt6ppOsqD4plFHtGpZV8/6y2Su5j7VNWJBb0EPQ+aNRm4uJlHFpkv9flDsBRaYF2x 9AsrfbmfwNEdLrCfjMAbi5MH4WHaDQPa1wrHlDmo=
X-Quarantine-ID: <yijIMTEpBXvs>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4FPGSh2LH2z6G9vm; Mon, 19 Apr 2021 12:04:04 -0700 (PDT)
To: ietf@sergey.dev, 'Loa Andersson' <loa.pi.nu@gmail.com>, 'mpls' <mpls@ietf.org>
References: <A5C8DFA9-3601-4838-9461-727CC40507B1@gmail.com> <003701d7354d$4810e660$d832b320$@sergey.dev>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <36cdf547-47b0-09f2-c168-588477f7af1c@joelhalpern.com>
Date: Mon, 19 Apr 2021 15:04:02 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1
MIME-Version: 1.0
In-Reply-To: <003701d7354d$4810e660$d832b320$@sergey.dev>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/8I4d_ziRTAftnzsw-7U5gthZMhg>
Subject: Re: [mpls] Available IP version numbers.
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Apr 2021 19:04:11 -0000

If we are defining a protocol carried with its own ethertype (e.g. 
MPLS), there is no neeed for an IP version differentiation.

It can in fact be argued that IPv6 could have used a different header 
format, and assumed that the media woudl indicate the new protocol.
However, because we knew that it needed to interwork with, be mixed 
with, and be diagnosed with existing IPv4 packets it was far more robust 
to build the packet format in such a way that it was reliably 
distinguishable from IPv4.  Which means a different starting nibble.

We could have skipped it.  (Historically, we got there the other way. 
We started by thinking we would use the same ethertype for both.  And 
then also realized that had problems.  So we have a belt and suspenders; 
dual identification.  Which is often a good design paradigm.)

Yours,
Joel

PS: In the MPLS context the is further complicated by devices which look 
at the data after the end of the stack and try to guess what it is. 
Typically to support ECMP / LAG.

On 4/19/2021 2:53 PM, ietf@sergey.dev wrote:
> Hi Loa,
> In an adjacent thread ("mpls open dt & the first nibble discussion") I raised a question about why do we even expect to take something from IP numbering. Would appreciate your feedback on this one.
> 
> 
> -----Original Message-----
> From: mpls <mpls-bounces@ietf.org> On Behalf Of Loa Andersson
> Sent: Saturday, April 17, 2021 1:13 AM
> To: mpls <mpls@ietf.org>
> Subject: [mpls] Available IP version numbers.
> 
> DT,
> 
> We had a discussion on how many IP version numbers are available.
> 
> It should be remembered that in IANA “Reserved” really means “Reserved, do not assign”.
> 
> 0,1,5,7,8,9 and 15 are reserved.
> 2,3,10,11,12,13 and 14 are unassigned
> 4 and 6 are assigned
> 
> To make the reserved requires a standard track RFC.
> 
> So we 7 IP version numbers available, that is a sufficient low number to make me nervous, if I owned the registry.
> 
> I would nit count on having more IP version numbers assigned to “us”, especially since we already have an agreement (PWE3), accepting to get two numbers and committing to not use more.
> 
> /Loa
> 
> Sent from my iPhone
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>