Re: State of play with Shim6 documents

[Shinta Sugimoto <shinta@sfc.wide.ad.jp>]

Hi,

Please find my comments inline.

On Mon, 12 Mar 2007 14:26:07 -0700
Erik Nordmark <erik.nordmark@sun.com> wrote:

> Henderson, Thomas R wrote:
> 
> > 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?  
> 
> Thomas,
> 
> Are you saying that the *only* thing that prevents a complete shim6 
> user-space implementation using standard APIs is the fact that shim6 
> uses a single protocol number? I find that very hard to believe since I 
> don't know of any standard APIs that allow me to insert the transmit 
> side data plane of shim6 in the transmit path. The API RFCs clearly 
> don't have such a mechanism, nor does the socket standard from the open 
> group. Thus a user space shim6 implementation would require some 
> non-standard extensions and/or modifications to the stack. Given that, I 
> suspect one can figure out how to handle the above issue as well.
> 
> The reason for using a single protocol number for shim6 is to increase 
> the probability of uniform handling by existing firewalls. With a single 
> protocol number existing firewalls would probably either let all such 
> packets through, or block all of them. If we chose to instead use 
> multiple protocol numbers there is the danger that some packets (such as 
> the context establishment packets) make it through the firewall while 
> others (such as the payload packets) are blocked. That possibility adds 
> a new failure mode which is hard to deal with, especially if the probe 
> messages get the same firewall treatment as the context establishment 
> packets.

The above argument sounds reasonable to me. So I support having a single
protocol number for SHIM6.

In our implementation, in an inbound packet processing of an IP packet
whose next protocol field is IPPROTO_SHIM6, the kernel (Linux) verifies
the bit right after the SHIM6 common header and takes necessary action
as follows:

1) if the bit indicates the packet is data, do locator switching
2) else, do nothing and deliver the packet to RAW socket (if any)


Regards,
Shinta