Hi Jeff, On 06/24/2016 06:23 PM, Jeff Ahrenholz wrote:
Hi Miika, First of all, nice work with all of your changes! This is a big draft but seems much clearer without the RFC 5770 delta.Here’s some further comments on your questions...* What should do with compatibility with RFC 6078 (HICCUPS)I think you can omit this, since RFC 6078 is for RFC 5201 (HIPv1). (Wait until if/when 6078 is updated for HIPv2.)
ok.
* Connectivity tests should be skipped unless ESP_TRANSFORM is negotiated?Seems like a good idea. No ESP_TRANSFORM -> no need to establish two-way comms between peers. For example, when performing a registration procedure with a relay server.
The direct path could be, of course, used for exchange HIP messages directly (including hiccups v2). Does this make sense?
If not, what should happen when both ESP_TRANSFORM and ICE-HIP-UDP are both negotiated? Or should we just be proactive and state that upon receiving R1, the Initiator MUST NOT include ICE-HIP-UDP if it is not going to employ any ESP_TRANSFORM.
* Steps 5-6 could be skipped in the handoff sequence? See fig. 6.If steps 5-6 are skipped, then we would have no SEQ in step 3?
Yes.
And the subsequent connectivity checks would suffice for these steps?
Connectivity tests implement the return routability checks. Currently, the NAT mobility triggering mechanism mimics the tree-way procedure in here:
https://tools.ietf.org/html/draft-ietf-hip-rfc5206-bis-12#section-3.2.1I thought that would nice for implementers but strictly speaking steps 5-6 could skipped since the connectivity checks actually implement the return routability checks.
I can change this if you agree?
Below are a few editorial nits... -Jeff page 2 s/checks keepalives, and data relaying./check keepalives and data relaying./g page 7 s/IPsec [RFC3948] Finally/IPsec [RFC3948]. Finally/ page 15 s/NATs drop messages messages/NATs drop messages/ page 18 s/the the recipient/the recipient/ page 22 s/interact handover/interact with handover/ page 27 s/MUST not/MUST NOT/
Thanks, I have fixed the nits and they will be included in the next version.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
