IPv6 options (was: RE: AD comments on draft-ietf-nsis-ntlp-14)

hi magnus,

on your point (2): 

> 2. Section 5.3.2.2:
> 
> "   The upper layer protocol MUST be UDP without intervening
>    encapsulation layers.  Following the hop-by-hop option 
> header, the IP
>    header MUST NOT include any extension headers other than routing
>    options or destination options, and for the last extension header
>    MUST have a next-header field of UDP."
> 
> Here I must actually ask if this specification really can 
> require that other IP extensions not are used. This seem to 
> have potential clashes with other basic building blocks. So I 
> would like to understand why the WG thinks it is necessary to 
> make these restrictions.

This text came in response to review comments, mainly from
the security and routing people. The reasoning behind the text is
in two parts.

Firstly, consider the current set of IPv6 options which aren't
actually upper layer protocols. From IANA, they are:

        00 = Hop-by-Hop Options
        41 = ipv6
        43 = Routing
        44 = Fragment
        51 = Authentication
        60 = Destination Options
        50 = Encapsulating Security Payload
        xx = Upper Layer Header
        58 = Internet Control Message Protocol (ICMP)
        59 - no next header

So the text is ruling out ip in ip (which would make no sense 
for Q-mode), fragmentation (which should not be necessary),
esp/ah (which would prevent GIST working at all), and ICMP
(which is really an upper layer protocol anyway). 

In terms of future IPv6 options, we need to wonder what could
exist other than hop-by-hop or destination options. I'm not
sure what those would be, but quite likely those options would
have some non-trivial impact on the way that the network layer
processed packets (e.g. how they were forwarded). But the correct
operation of GIST (in Q mode) depends rather closely on its
correct interaction with the network layer. So, arbitrarily using
other options would be a source of danger.

>From another point of view, think of the process of defining a
new IPv6 option. The spec is basically saying that you can't use
that option and GIST Q-mode at the same time, without updating the
GIST spec itself - which would be the trigger for some re-analysis
to find out if the combination was safe. If (somehow) you are 
forced to use the new option, then you cannot use GIST; if you 
have freedom about whether to use the new option (which would 
surely be the normal case), don't use it with GIST Q-mode.

To me, these restrictions seem reasonable - is more rationale 
required?

robert h.