I’m lost as well; I understood so far sar the CoAP URI host is the same as the http host: header parameter. If I m correct then this is normally a string with the dns name and port to reach the server. Without it, the proxy wouldn’t know how to reach the server in the first place. Without it, a multihomed server wouldn’t know which instance it reached. This is why I understood it became mandatory in http 1.1.
Where is s the disconnect? Pascal Le 19 mai 2018 à 08:12, Mališa Vučinić <[email protected]<mailto:[email protected]>> a écrit : Michael, I am not sure I follow. How come is it not the case that this well-known host name is resolved to an IP address? When JP receives a first DIO and learns the DODAG root’s IPv6, it stores the IP address as the resolution of 6tisch.arpa. Same thing when it learns the JRC’s IPv6 through the Join Response. When a CoAP message to be proxied is received, and URI-Host that is in the clear indicates 6tisch.arpa, the name is resolved to the previously stored IP address and a new CoAP message is generated creating a new IPv6 packet. Note that URI-Path is encrypted and therefore not available to the proxy. How is then 6tisch.arpa never associated with an IPv6 address? Mališa On Fri, 18 May 2018 at 23:17, Michael Richardson <[email protected]<mailto:mcr%[email protected]>> wrote: Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>> wrote: >> I don't understand at all. Would a PCE provide enrollment services? pt> [PT>] We are talking to a stateless CoAP proxy, giving an alias to a pt> service that it will map into the IP address of the server, here the pt> JRC. pt> I understood that this is an anycast name for the JRC, aimed to be pt> resolved by the proxy in a pseudo DNS fashion into the IP address of pt> the server. Do I have that wrong? Not the case. It's just a value for the CoAP Host "header" > If the proxy is used for only one service, arguable there is no need to > pass a string at all. If it is generic enough and used for more than > one service than we need something meaningful. I'm not sure which we > really want but 6tisch.arpa fails either way. >> 2) There is never an IP address associated with 6tisch.arpa, it's just >> something to put into the Host part of the CoAP. Since we are talking >> to a Join Proxy, and the Join Proxy points to the JRC, we get the JRC. pt> [PT>] OK then you seem to be looking at a dedicated proxy; if so, why a pt> string at all? Because CoAP header needs one, and the original name wasn't going to get past the IESG. >> If we had something that wanted a PCE, what would it talk to get that? >> Wouldn't the node already have enrolled? >> How would it get the IP address of the PCE? > [PT>] The string could be a real DNS name. The question is whether the > instance of the proxy is dedicated to join or not... -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] [email protected]<mailto:[email protected]> http://www.sandelman.ca/ | ruby on rails [ _______________________________________________ 6tisch mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
