IESG review: tunnel type / IANA considerations

[Tim Gleeson <tgleeson@cisco.com>]

> 3. >    Tunnel Type (8 bit unsigned integer): tunneling protocol supported
> by
> >      the feed; receivers MUST use this form of tunnel encapsulation when
> >      tunneling to the feed.
> >      47 = GRE [rfc2784] (recommended)
> >      Other values may be used, but their interpretation is not specified
> >      here.
> 
> An IANA considerations section is needed to give guidance for future
> assignment of values to this (and other?) fields.

I think we have some choices here:

a) Define our own allocation framework. This could be as simple as
"This document defines value 47. Following the policies in
RFC2434, a publically available specification is required for use of
other values." Or something much more elaborate, if greater review is
desired.

b) Let this field be defined by the IP protocol values in
RFC1700/protocol-numbers. This relieves us of the assignement
problem. We may need a little clarifying text saying what happens when
a receiver is told to use a protocol it can't support. The current
protocol-numbers defines most of the encapsulations we'd want, except
perhaps directly encapsulating LL packets in IP datagrams. But
protocol-numbers does have several numbers which could be bent/abused
to private use including "63 - any local network". Getting new values
is documented in RFC2780.

I like (b).

Tim