Hi Michael,
Thanks for the comments. Please see comments and responses inline.
Yours,
Daniel
On 2025-01-25 14:27, Michael Richardson wrote:
I have read draft-ietf-ipsecme-ikev2-diet-esp-extension and
draft-ietf-ipsecme-diet-esp. It's been a long time since I last read them.
I found them reasonably well written, and seem to be detailed enough to
implement.. but... I'd like to see have a few more examples in the diet-esp
document, and I wonder about srcv6: 2001:db8:, with destination ff02::.
It there any reason to wonder if this is a magic choice for compression?
The selection of the specific values was not based on any particular
reasons. With LSB compression, the larger the network prefix in the TS,
the greater the potential for compression. It is relatively
straightforward to generate the examples, as we have the necessary code
available. Please feel free to let us know if you would like to see a
specific example, and we would be happy to provide it. We will provide
additional examples.
Are there interactions between the outer IP header compression mechanisms
listed and RFC7400, or RFC4944? Neither of which is cited.
There are no interactions in the sense that we do not rely on them. We
only compress the IP header when operating in tunnel mode, and the
compressed IP header is the inner IP header. The outer IP header is not
compressed. RFC 4944 and 7400 can be used to compress the outer header,
depending on L2.
I think that Valery's comments are probably on, and HCP_UNSUPPORTED surprised
me.
The current version of the draft has replaced HCP_UNSUPPORTED with
NO_PROPOSAL_CHOSEN, as we did not want this to be a blocking issue. We
still believe that being able to provide a way for a random device to
offer a hint could be useful. Conversely, we can also consider having
such information available out-of-band prior to establishing the
communication. We are open to the preference of the WG on this matter.
I see the implementation note; has this run on real devices with real radios
yet?
This version of the draft has only been tested according to the SCHC
(Static Context Header Compression) protocol, which means that the SCHC
expression of the compression corresponds to our understanding. An early
implementation of the draft has been developed on Contiki, as shown in
the following link: https://bitbucket.org/sylvain_www/diet-esp-contiki.
It has been tested on real devices, but the context was IoT. Beyond the
Proof of Concept (PoC), for diet-esp to be integrated into commercial
telecom products, it needs to become a standard. This is why we are
leading that effort ;-)
The 5-author guideline is exceeded by a bit, what is the plan here?
We will see with Tero what is the actual maximum number. Though every
steps of that documents were important, it is likely the authors
involved in the SCHC version will be prioritized. Other will be added
in the co-author section.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
]m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
_______________________________________________
IPsec mailing list --ipsec@ietf.org
To unsubscribe send an email toipsec-le...@ietf.org
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
