Tte wglc review #40
Tte wglc review #40
Conversation
|
|
||
| ~~~~ aasvg | ||
| multi-hop mesh | ||
| .---. | ||
| | R +---. +----+ +---+ +--+ | ||
| .---. IPv6 |
There was a problem hiding this comment.
The term 'IPv6 subnet' inserted here is not explained in the text. And it may raise some questions. The entire mesh is a multi-link IPv6 subnet but this isn't shown by text, for simplicity. Do we want to say that the link between JP and Pledge is also a (different) IPv6 subnet? One where only link-local addresses are valid. Does it help to point this out?
| and selects the most appropriate Join Proxy. From the discovery, the Pledge learns the | ||
| Join Proxies link-local scope IP address and UDP (join) port. This discovery can also be | ||
| based upon {{RFC8995}} section 4.1. If the discovery method does not support discovery | ||
| of the join-port, then the Pledge assumes the default CoAP over DTLS UDP port (5683). |
There was a problem hiding this comment.
| of the join-port, then the Pledge assumes the default CoAP over DTLS UDP port (5683). | |
| of the join-port, then the Pledge assumes the default CoAP over DTLS UDP port (5684). |
| from a Plege: Whereas in the stateful proxy case, all packets with the same | ||
| (IP_jr:p_Jr, IP_R:p_r) belong to a single Pledges UDP connection and hence | ||
| DTLS/CoAP connection, only the packets with the same (IP_jr:p_Jr, IP_R:p_r, H) | ||
| belong to a single Plegdes UDP connection / DTLS/CoAP connection. The |
There was a problem hiding this comment.
| belong to a single Plegdes UDP connection / DTLS/CoAP connection. The | |
| belong to a single Pledge's UDP connection. The |
Since the text only talks about "UDP connection" above, it shouldn't be necessary to add the "/ DTLS/CoAP connection" part here. If we do need then it may be better like:
"single Pledge's UDP connection (e.g. a DTLS connection, or CoAPS connection)"
| {: #fig-stateless title='constrained stateless joining message flow.' align="left"} | ||
| Unlike the stateful operation, ICMP error messages from the Registrar can not be | ||
| mapped to the Pledge, because the ICMP error messages do not carry enough | ||
| bytes of the original packets payload to include the JPY Header. |
There was a problem hiding this comment.
Interesting point on ICMP / ICMPv6 errors. The last sentence (reason) isn't fully clear to me. Do you mean that the Registrar's ICMP error message doesn't contain the IPv6 header of the original Pledge's packet ? So the JP cannot send back an ICMP error message because it doesn't know how the original IPv6 header of the Pledge's packet looked like.
Same issue could occur for a stateful JP however: it typically doesn't store full IPv6 headers but only some limited data like (address, port, timeout-variable) per Pledge?
The Registrar may be a 'normal' unconstrained IPv6 host so it could send out a complete ICMPv6 error message that includes the JPY header and all the other (DTLS) data.
Noteworthy is that 6lowpan mesh network nodes may only send the IPv6 header in the ICMPv6 error message, but not the full packet - to avoid high load on the mesh. (The full data is in practice not used by the sender. The IPv6 header is enough to identify the sent message.) See for source code example of OpenThread mesh: https://github.com/openthread/openthread/blob/main/src/core/net/icmp6.cpp#L119
If the Registrar is located on the Border Router and thus a mesh node, it may also use this "limited" style of ICMPv6 errors with only IPv6 header info. In that case the stateless JP can't find back its JPY header in the ICMPv6 error message from Registrar.
|
I was going to go through the two big commits, split them up into separate
commits, and then sort them into controversial and non-controversial.
OTH, if there are one or two issues and we can fix them inplace, then that
would avoid a lot of effort.
|
Proposed changes according to WGLC2, review <https://mailarchive.ietf.org/arch/msg/anima/KbWQKsfFVbTWMijjm1WxCUG6908
See that message for explanations of suggested changes