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
- [Int-area] FW: Last Call: draft-arkko-rfc2780-pro… Jari Arkko
- Re: [Int-area] FW: Last Call: draft-arkko-rfc2780… Noel Chiappa