RE: State of play with Shim6 documents

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

> -----Original Message-----
> From: Erik Nordmark [mailto:erik.nordmark@sun.com] 
> Sent: Monday, March 12, 2007 2:26 PM
> To: Henderson, Thomas R
> Cc: Geoff Huston; shim6-wg; kurtis@kurtis.pp.se
> Subject: Re: State of play with Shim6 documents
> 
> 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.

No, I was talking about the control plane only, that it would be
convenient to define a protocol number so that raw sockets could be used
to generate and consume those messages.

For the data plane, I understand your point that it may be moot if the
control plane were to be supported without modifications, if the data
plane could not be.  However, I was thinking that judicious use of Linux
netfilter could be used to insert the data plane shim.  In particular,
the IP6 local in and local out hooks seem well positioned in the stack
to support a shim6 shimming module.

My basic concern is that it would be nice to support shim6 without
patching the Linux kernel, for deployment/experimental purposes.  It may
be possible to make this work as defined now without a patched kernel.
I think it may require some more complicated matching rules to divert
shim6 control packets to user space while diverting shim6 data packets
to a deshimming module, and making sure there is some way to inject the
control plane packets from user space.  I suspect it will be harder to
do the way it is defined, including for non-Linux systems, but perhaps
not impossible.

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

Since I understand the motivation you have here, I think it would be
best to avoid speculating and experiment with the above to see if it can
work.  I'll try to get some results in the next week or two and report
back.

Tom