Hi,
a preliminary version here:
http://mkomu.kapsi.fi/temp/draft-hip-native-nat-traversal-19.txt
Not yet on IETF site since I missed the cut-off deadline.
On 02/19/2017 05:18 PM, Tom Henderson wrote:
Hello, I have read the latest (-17) draft and sent some purely editorial
comments to Miika. I had a few non-editorial questions and comments.
1) In appendix D, it states:
o A minimal implementation would conform only to Section 4.7.1 or
Section 4.7.2, thus merely tunneling HIP control and data traffic
over UDP. The drawback here is that it works only in the limited
cases where the Responder has a public address.
However, in section 5.4, it states:
Implementations conforming to this specification MUST implement both
UDP-ENCAPSULATION and ICE-HIP-UDP modes.
The contradictory text should be resolved. In my opinion,
implementations that want to support only the UDP-ENCAPSULATION mode
(and its restricted set of use cases) should be allowed. However, I
don't know what might need to be done to avoid a situation where a
product claims RFC compliance but only implements one of the two modes.
It could perhaps be avoided by a statement that states "Implementations
that choose to only support the UDP-ENCAPSULATION mode should clarify
this point when any claims of <RFC-to-be> compliance are made."
now it says:
"Implementations conforming to this specification MUST implement UDP-
ENCAPSULATION and SHOULD implement ICE-HIP-UDP modes."
I can also add some other wording if it is really necessary (and common
in RFC specifications). Btw, while ICE lite is not really the same as
ICE-HIP-UDP, ICE lite vs full ICE is not really enforced in the
specification.
2) Appendix C states:
o The considerations on Diffserv Codepoint markings in ICE are not
applicable to HIP since Diffserv is not used in HIP.
Why wouldn't the same issues arise in HIP as in ICE on this matter?
Should this draft instead copy or reference the RFC 5245 recommendation:
If the agent is using Diffserv Codepoint markings [RFC2475] in its
media packets, it SHOULD apply those same markings to its
connectivity checks.
Also, I don't think that the HIP control plane should be excluded from
using diffserv.
done.
3) In section 4.10 (NAT keepalives), it states:
Both a registered client and relay server SHOULD
send a HIP NOTIFY packets to each other every 15 seconds (the so-
called Tr value in ICE) unless they have exchange some other traffic
over the used UDP ports.
However, I couldn't find an explanation anywhere (also in RFC 5770)
about how to code this NOTIFY. Would it make sense to define also a
"NAT_KEEPALIVE" NOTIFY message type for this purpose?
Once these issues are resolved, I think that the draft would be ready to
publish.
done.
P.S. The new version of the draft also includes some nits from Alex Elsayed.
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
