RE: State of play with Shim6 documents

["Henderson, Thomas R" <thomas.r.henderson@boeing.com>]

> -----Original Message-----
> From: Geoff Huston [mailto:gih@apnic.net] 
> Sent: Monday, January 22, 2007 3:21 PM
> To: shim6-wg
> Cc: kurtis@kurtis.pp.se
> Subject: Re: State of play with Shim6 documents
> 
> It seems that asking these questions has stopped all further 
> discussion on this topic, which is a pity, as it would be good to 
> resolve these matters in the next week or so if possible.
> 
> The three topics that I see from the mailing list as being unresolved 
> at this stage are:
> 
>      * explicit shim6 error message (the lack thereof)
> 
>            Its not clear what the WG want to do on this. Suggestions?

I think it would be useful to define a mechanism for this, even if we do
not yet have the implementation experience to decide on all the types of
errors that should/should not be reported.  Other control protocols such
as IKE (section 2.21 of RFC 4306) have defined such messages, although
whether a host generates them is a matter of security policy.  In HIP,
we cloned the IKE Notify parameter and defined a number of error cases
that could occur during context establishment.  Does this WG want to
adopt something similar?  Or just leave it for further study?

(see the current HIP base draft, sections 4.3 and 5.2.16 (NOTIFY
parameter))

> 
> 
>      * TCP Checksum Failure
> 
>            Its not clear what the WG want to do on this. Suggestions?
> 

I would vote to align the checksum with the locators, under the
assumption that defining an alternate probing mechanism to discover
these problems is more cumbersome.  If you care strongly enough about
using the transport checksum to detect incorrect address rewriting in
certain error scenarios, that may argue for putting better error
detection in the shim proper, but I'm not sure it is a high enough
probability event.

>      * Control Message length
> 
>            Text proposed 
> (http://ops.ietf.org/lists/shim6/msg01780.html)
>             Are we in agreement with this suggestion?

My first thought was "why not just use regular IPv6 fragmentation in the
control plane, perhaps with IPV6_USE_MIN_MTU socket option?" but then I
realized that the whole protocol is defined in terms of IPv6 destination
headers below the fragmentation layer.  

from the current draft:
> The shim6 control messages use the same extension
> header formats so that a single "protocol number" needs to be allowed
> through firewalls in order for shim6 to function across the firewall.

Besides the fragmentation issue, the way it is defined now, it seems
burdensome to implementations that want to implement the shim6 control
plane as a user-space daemon (as opposed to defining a separate protocol
number for shim6 control messages).  My reading of IPv6 raw sockets
semantics suggests that they cannot be used.

from RFC 3542:
"With IPv6 raw sockets will be
   used for ICMPv6 and to read and write IPv6 datagrams containing a
   Next Header field that the kernel does not process."

This is not the case for shim6 since the kernel does process the payload
extension header in the data plane.

Under current definition, how should a user-space shim6 implementation
use IPv6 sockets API to get only the control messages?  If there isn't
an easy way, should we consider to separate the protocol numbers?  

Tom