as announced here is the latest version of HNCP.
Thanks a lot.
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.
I rather like HNCP, which feels much less rigid than DNCP. In particular,
I'm glad to see that mDNS-proxying remains optional.
Questions and minor nits below, probably more to follow.
# 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.
# 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?
# 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).
Section 7.1: I'm not familiar with DHCPv6, but is a preferred lifetime of
1s a good idea?
Sections 7.2 and 7.4: why announce a route for each subnet? We've got
redirects for that.
# Reassembly
An HNCP node MUST be able to reassemble datagrams of 4000 octets. IPv6
allows a node to silently drop datagrams above 1500 octets. Are there any
widely-deployed stacks that limit reassembly to 1500 octets? If so,
I expect this to be the source of difficult to diagnose bugs.
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
