Re: visibility of identifier in shim6 payload packet (was: Re: IPsec !?...)

[Francis Dupont <Francis.Dupont@point6.net>]

 In your previous mail you wrote:

   so, let me ask you another question with respect to BITW and MIPv6 RO 
   operation...
   
   suppose you have a node using MIPv6 in RO mode and it is using BITW 
   IPSec and it receives a packet with the HoA dest option
   
=> yes, a BITW IPsec has to know what is a HoA dest option. In fact
it already has to know for AH handling (another point where SHIM6
needs some specs but it is not an issue).

   Bottom line is that i think that a reasonable apporach would eb to try 
   to follow the same path that MIPv6 folks have done...
   
=> this is the easy solution...
   
   > => one way is to put the ULID in all packets. This solves this problem
   > and related firewall issues too (*). But it is clearly expensive.
   
   i think this may be one option for this particular BITW case
   i mean, the other option is that the BITW module can access to shim6 
   state, but from your words above, i conclude that this is not feasible
   
=> more important it is not desirable for the same reasons which make
BITW the right choice in some circumstances.
   
   > Two other points:
   >  - one possible solution is to integrated the whole SHIM6 into the BITW
   >    device (i.e., have an IPsec+SHIM6 BITW). As the issue comes from the
   >    relative positions of the IPsec and SHIM6 sublayer, this makes 
   > sense.
   
   yes this is another possibility indeed and as i understand this is 
   partialy what is done in MIPv6 with respect to HoA and Routing header 
   processing, right?
   
   i mean, as i understand this, part of the shim6 processing will be 
   performed by the BITW device. I guess we have two options so far:
   - or we integrate all the shim6 processing in the BITW device

=> this is my idea. This was never considered for MIPv6, IMHO because
the MIPv6 target was very small devices and the proxy-MIPv4 stuff
was already heavily patented.

   - or we include the ULID pair option in data packets (when BITW is in 
   use), so that the BITW device can hace access to all the information 
   that is needed and do not need to perform all the shim6 processing 
   itself
   
   My suggestion would be to:
   - adopt the first option now
   - make an extension to shim later so that this BITW optimized mode is 
   supported
   
   makes sense?
   
=> I don't understand how we can have both options at the same time.
   
Regards
   
Francis.Dupont@fdupont.fr