Hi Juliusz, > As mentioned previously, we did set up a wired HNCP network here in > Paris last month, and it works beautifully (at least on wired links). > I strongly support this work. thanks a lot for your (repeated) feedback and support.
> > # Ad-hoc interfaces > > You don't define ad-hoc interfaces. From Section 4, it would seem > that these are for non-transitive links with no prefix assignment (a > la AHCP), but in that case some changes may be needed to DNCP, which I > don't think will work on non-transitive links in its current shape. > In any case, the purpose of this feature needs to be made explained to > the naive reader. In it's current form the adhoc-interface category in-fact results in an assignment of a /64 per EACH adhoc-interface since the common-link is defined to only consist of the single ad-hoc interface (including potentially connected client-devices). An implementation can of course provide configuration mechanisms to turn off address assignment on a per-interface basis - independent of the interface being adhoc or not. > > > # Border discovery > > What happens if there is a non-Homenet DHCP server on a link, but for > some reason an address cannot be obtained from it (e.g. the server > NAKs all DISCOVER/REQUEST messages)? My reading is that the interface > will be considered internal, and therefore not firewalled. Is that > the expected outcome? Your reading is correct. However since homenet routers also reject (or ignore) DHCP requests coming from other homenet routers, the situation would be ambiguous if the outcome was different. Also please note that the automatic border discovery is a best-effort heuristic to provide a good (zeroconf) user experience as also explicitly noted in the security considerations section. A router must in anyway provide means to set an interface to a fixed category of internal or external. > > # Policy needs review > > There is a certain amount of policy in Section 6.4 and in Section 7 > that needs careful review by a competent third party. In particular, > I'm not entirely comfortable with the IPv4 requirements in Section 6.4 > (the IPv6 requirements look fine to my amateurish eyes). The IPv4-policy is a bit complex, yes. The reasoning behind this is that DHCP (and most client OS in general) do not really deal well with multiple IPv4-addresses thats why we make sure that there is at most one IPv4-prefix. There are other factors here, e.g. router's with global IPv4 connectivity having preference other router's that can only provide local IPv4 connectivity, etc. > > Section 7.1: I'm not familiar with DHCPv6, but is a preferred lifetime > of 1s a good idea? Noted, I will change this in the next revision, the intention here is to keep fast renumbering working even with stateful DHCPv6. The given procedure is probably debatable and inferior to others, i.e. one might only hand out a lease for a ULA-based address and let global addresses be numbered using RAs only. > > Sections 7.2 and 7.4: why announce a route for each subnet? We've got > redirects for that. I think you misread that. The text says to announce one route per "delegated prefix" not per "assigned prefix". This is e.g. to allow differentiation of local and global connectivity. It is inherited from RFC 7084 which more or less mandates that (for IPv6). Cheers, Steven _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
