[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: visibility of identifier in shim6 payload packet (was: Re: IPsec !?...)
In your previous mail you wrote:
I am not saying that we should give up providing the compatibility.
I am saying that we should first take a look at the problem, and
see how serious the problem is. I am not sure if the combination
of SHIM6 and BITW IPsec is totally infeasible or not, so I need
=> note that we have the architectural point of view (i.e., Jim's
concern) which is the same issue but with another kind of arguments.
Based on assumption that BITW IPsec should be completely transparent
to the ULPs (including SHIM6 as its a conceptual sublayer within IP
layer), I don't see why SHIM6 over BITW IPsec would not work.
=> what do you mean with SHIM6 over BITW IPsec? Don't forget the kind
of IPsec implementations is transparent too, i.e., the provided service
is the same, and in particular the traffic selectors are the ULIDs when
the device fiddles about the bits in the wire.
it would not be optimum operation, but that's same in the case of
normal IP host connected to multihomed site over BITW device isn't it?
(Please correct me if I am wrong)
=> I can't say: I don't understand your idea.
I agree with your statement, in general. But I would like to see if
the problem that we are talking about is a problem newly created by
the SHIM6 intermediation,
=> it is created by SHIM6 because, even we can consider it is a bad design,
IPsec needs to find its traffic selectors in the traffic packets and
the choice to put IPsec at an upper level than SHIM6 in the stack is
bot incompatible with an IPsec device running at the wire level and
raises a basic architectural issue on how IPsec knows the locators/ULID