Re: [mpls] Available IP version numbers.

ietf@sergey.dev Mon, 19 April 2021 19:22 UTC

Return-Path: <ietf@sergey.dev>
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 A9B303A4011 for <mpls@ietfa.amsl.com>; Mon, 19 Apr 2021 12:22:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.217
X-Spam-Level:
X-Spam-Status: No, score=-0.217 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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=sergey.dev
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 edrtbzvhnBcY for <mpls@ietfa.amsl.com>; Mon, 19 Apr 2021 12:22:13 -0700 (PDT)
Received: from forward100p.mail.yandex.net (forward100p.mail.yandex.net [77.88.28.100]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B91C63A4013 for <mpls@ietf.org>; Mon, 19 Apr 2021 12:22:12 -0700 (PDT)
Received: from iva1-740a73756611.qloud-c.yandex.net (iva1-740a73756611.qloud-c.yandex.net [IPv6:2a02:6b8:c0c:92a6:0:640:740a:7375]) by forward100p.mail.yandex.net (Yandex) with ESMTP id 6AD655981120; Mon, 19 Apr 2021 22:22:05 +0300 (MSK)
Received: from iva6-2d18925256a6.qloud-c.yandex.net (iva6-2d18925256a6.qloud-c.yandex.net [2a02:6b8:c0c:7594:0:640:2d18:9252]) by iva1-740a73756611.qloud-c.yandex.net (mxback/Yandex) with ESMTP id bnipE6IlcF-M5IqrUAq; Mon, 19 Apr 2021 22:22:05 +0300
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sergey.dev; s=mail; t=1618860125; bh=+HBMVl70u/yU5UP4dnFz9/PIXFHC0xlCDVlSr+Xd3JA=; h=Subject:Date:References:To:From:Message-ID:In-Reply-To; b=kBAlZTS4B+r7FkkuNlG97Y8NUg4em32CUNfoEEL+mD74pNRzWHJGqAncvBVRYVE8a L5gazjts5GtDlPlgORMb5U7yZ63X51u9UaAKpeTNvVnEWlHN0j7FtdL3z1ZNE6OBLt GYq5c6NXaBPsGjQ9OaWZr0M/lQQSSk+Rzzv/Qbqo=
Authentication-Results: iva1-740a73756611.qloud-c.yandex.net; dkim=pass header.i=@sergey.dev
Received: by iva6-2d18925256a6.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id 4Lu4bYs19K-M3KKsUB4; Mon, 19 Apr 2021 22:22:04 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present)
From: ietf@sergey.dev
To: "'Joel M. Halpern'" <jmh@joelhalpern.com>, 'Loa Andersson' <loa.pi.nu@gmail.com>, 'mpls' <mpls@ietf.org>
References: <A5C8DFA9-3601-4838-9461-727CC40507B1@gmail.com> <003701d7354d$4810e660$d832b320$@sergey.dev> <36cdf547-47b0-09f2-c168-588477f7af1c@joelhalpern.com>
In-Reply-To: <36cdf547-47b0-09f2-c168-588477f7af1c@joelhalpern.com>
Date: Mon, 19 Apr 2021 12:22:00 -0700
Message-ID: <001b01d73551$47ba6520$d72f2f60$@sergey.dev>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQKUPgr7n0r+Iugvfy2N2vrBHUrKswHMZUEUAdyE0gKpJNpRIA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/AjWvbp8zyD1DlDlOzmath149eqU>
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:22:18 -0000

Joel,
I agree with that.

But my point it - it seems there's an implicit assumption that IP header follows an MPLS label stack, which may or may not be the case. First nibble is not a protocol identifier in a classical sense (except for LSR-guessing). 
We can't rely on a nibble as a unique identifier by itself; so is there even a point in using anything besides 0x0 (to avoid LSR-guessing)? There might be, but it is not obvious in a current form of just taking a new number.
And if we were to use a new number - it is not an IP version number (as long as we are not claiming that an IP header follows. Yes, 0x0 and 0x1 were reserved by IANA for rfc4928 usecase, but this is not, strictly speaking, a standard-defined paradigm).

--
Sergey

-----Original Message-----
From: Joel M. Halpern <jmh@joelhalpern.com> 
Sent: Monday, April 19, 2021 12:04 PM
To: ietf@sergey.dev; 'Loa Andersson' <loa.pi.nu@gmail.com>; 'mpls' <mpls@ietf.org>
Subject: Re: [mpls] Available IP version numbers.

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
>