Re: IESG review: tunnel type / IANA considerations

[Dr G Fairhurst <gorry@erg.abdn.ac.uk>]

If in doubt, I'd say don't invent new numbers and do allow other options to be
defined
later. I favour (b).

Tim Gleeson wrote:

> > 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

--
------------------------------
http://www.erg.abdn.ac.uk/users/gorry