> From: Jari Arkko <[EMAIL PROTECTED]>
> 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
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
