[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SAIDs and formats
Antony,
I think there was a miscommunication and your latest response
suggests we are in synch now. My interpretation of Ran's diagram was
as an example of where algorithm-dependent header and tralier data
would be in the IPSP format. Thus, the presence or absence of such
data, and, in some cases its size, is determined by the SAID. So I
think we are in agreement there.
As for commonality of formats, I think it's not an issue of
IPv4 constraining use in IPv6, but rather the other way around. My
comment was predicated on the observation that there is a strong push
to have an integrity option bound into the IPv6 header and to make
this option as efficient as possible, to support its use as a default.
My opinion is that this is just right, and that if this integrity
option is to encompass parts of the IP header, then this is precisely
where it should be, i.e., in the header itself. I would further
suggest that both end-to-end and end-to-intermediate system use of the
option can be provided naturally based on placement of this option in
the appropriate areas of the IPv6 header. How this may apply directly
to IPv4 since there is not a corrsponding header option capability.
However, IPSP as a protocol that sits above IP, encapsulating
a transport layer PDU, or as a protocol that encapsulates IP (when
IPSP is implemented at an intermediate system) can be equally at home
in IPv6 and IPv4, I believe. It can avoid dependencies on the (outer)
IP header by not trying to include it in the integrity calculation,
focusing instead on protecting whatever payload is encapsulated by
IPSP.
Steve