Re: IPv6 options

Thanks Robert,

This makes sense.

Cheers

Magnus

Hancock, Robert skrev:
> 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.
> 


-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email protected]
----------------------------------------------------------------------