Ted posted draft-lemon-stub-networks-ps awhile ago, and I have attempted to collaborate with him on it. There was a goof in the XML, so when he posted -01 of the document, it was named draft-lemon-stub-networks, and overwrote his previously uploaded solution document.
I think that this is a key architectural document on connecting IoT networks, although there is some resistance to putting such a specific use case into the title. The Problem Statement is at: https://www.ietf.org/archive/id/draft-lemon-stub-networks-01.html The solution document is at: https://datatracker.ietf.org/doc/draft-lemon-stub-networks/00/?include_text=1 Ted shared a (google) document with me to edit, but I'm not sure if he wants that as the canonical place to contribute. Here are some of my comments/questions about this document: 1) Perhaps "Stub Router" should be in the terminology. The terms: AIL, NAIL, NAL and OSNR are introduced but aren't really used. They aren't really that pneumonic. If anything, I'd like a cool TLA for "Stub Router" 2) There is advise about monitoring the RAs from the infrastructure router (which is probably the home CPE router), and soliciting them regularly. In effect, the Stub Router can't depend that the CPE router will remain alive for it's lifetime. That is, the RA lifetimes tell the client how long it may use the resource, but not how to determine if the router is alive. Of course, power can disappear at any time. Ted: it seems that maybe neigh-cache entries already have all the timers and rechecks needed, and maybe the Stub Router can just watch for the NCE going Stale? 3) _Adjacent infrastructure link (AIL)_ that's the home LAN, right? Maybe it would clearer if it was just called that? 4) I'd like to add a state machine diagram to 3.1.1/3.1.2. 5) _IP addressability not present on adjacent infrastructure link_ (AIL) When the Stub router finds no IPv6 on the "LAN" link, then it advertises one. I think that this prefix should be advertised as being _off-link_. To clarify for others: the stub router will have a ULA, and it might advertise ULA:0002::/64 on the AIL ("LAN"), and will number it's stub network with ULA:0001::/64. It will do this with a PIO that does not include a default route. On the AIL, where there is also an IPv6 prefix (but not DHCPv6-PD), then it just seems like not putting a second ULA on top of the LAN for the purpose of communicating within the LAN seems better. While the off-link prefix can be used for e2e communications on the LAN, I think that the on-link prefix will be preferred. Perhaps this messes with DNS-SD discovery. -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
