That’s RFC 3046 sorry for the typo 😊 Small phone fat fingers...
Pascal Le 17 nov. 2017 à 22:27, Michael Richardson <[email protected]<mailto:[email protected]>> a écrit : Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>> wrote: Looks like a great idea Michael. In an ideal world the Root would become a filtering Join Relay (think DHCP relay here). Yes.... although once the traffic has reached the root, the network has already paid for it, so filtering it is less interesting, I think. Can 6p allocate bandwidth in the reverse direction? i.e. could the DAGroot, seeing a lot of legitimate join traffic from some branch allocate more bandwidth towards itself (the DAGroot)? I think that this is planned, but beyond minimal, right? Like in RFC 3048, this also means extra information for the relayed RFC3048: Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer I think this might be a typo, but I tried 3408 and 3084, and neither made sense either. packets, so the JR can point on its local state of the pledge on the way back (if the root is JR it needs the addresses of the JP or a locally significant pointer to it). The DAGroot can encapsulate the traffic entirely (VXLAN, GRE, IPsec), or could terminate the CoAP/UDP traffic into a NAT64 if it wants. Anything is possible, but it's all out of scope. Having said this, I believe that proxies SHOULD support a JRC address which is not the DAGroot. In addition to the off-LLN situation, there is also the case where there are multiple possible DAGroots, but only one of them intends to be the JRC, yet the other DAGroot is for whatever reason the active one. Are there security implications that do not foresee, like which of the JP and JR has an SA with the JRC vs end to end protection of the join response? You write "JR" and "JRC" in the same sentence, and I thought above that JR was just short for JRC. Whether it's DTLS or OSCORE or ???, the SA is always between the pledge and the JRC, and the rest are just helpful plumbing. -- Michael Richardson <[email protected]<mailto:[email protected]>>, Sandelman Software Works -= IPv6 IoT consulting =-
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
