Re: [Int-area] FW: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP

jnc@mercury.lcs.mit.edu (Noel Chiappa) Tue, 06 November 2007 20:52 UTC

Return-path: <int-area-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpVPQ-0002Qa-EC; Tue, 06 Nov 2007 15:52:28 -0500
Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1IpVPO-0002QJ-R1 for int-area-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 15:52:26 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpVPO-0002QB-Gj for int-area@ietf.org; Tue, 06 Nov 2007 15:52:26 -0500
Received: from mercury.lcs.mit.edu ([18.26.0.122]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpVPO-00030G-40 for int-area@ietf.org; Tue, 06 Nov 2007 15:52:26 -0500
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id B014E873D8; Tue, 6 Nov 2007 15:52:23 -0500 (EST)
To: int-area@ietf.org
Subject: Re: [Int-area] FW: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP
Message-Id: <20071106205223.B014E873D8@mercury.lcs.mit.edu>
Date: Tue, 06 Nov 2007 15:52:23 -0500
From: jnc@mercury.lcs.mit.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: jnc@mercury.lcs.mit.edu
X-BeenThere: int-area@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/int-area>
List-Post: <mailto:int-area@lists.ietf.org>
List-Help: <mailto:int-area-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@lists.ietf.org?subject=subscribe>
Errors-To: int-area-bounces@lists.ietf.org

    > From: Jari Arkko <jari.arkko@piuha.net>

    > comments appreciated.

Looks reasonable.


BTW, on the subject of protocol numbers, for another project (interoperable
upgrade to add EID's to TCP4), I once proposed adding an "end-end options"
protocol to the IPv4 base protocol set; i.e. a protocol that did nothing but
carry data from another protocol inside it (the number for that protocol
would be carried in the E2EO protocol header), along with a bunch of end-end
qoptions. Since they weren't in the IPv4 header, routers wouldn't look at
them, and it wouldn't slow down processing of those packets in the middle of
the network.

The reason I mention this is that while I was at it, I upped the size of the
"protocol carried inside this packet" field to 16 bits; I figured 2^16
protocols should probably last us a good long while. The bottom 2^8 would be
the same as the existing allocations.

With nearly 2^16 available, we could afford to be pretty cavalier about
handing out the ones that were larger than 2^8; we could pretty much have an
"if there's a document that describes it, you can have a number" policy for
that part of the number space. Which would be really nice - it would encourage
experimentation with new concepts.

	Noel


_______________________________________________
Int-area mailing list
Int-area@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area