Concerns about HNCP =================== HNCP is a protocol that uses DNCP to flood enough information to perform prefix assignment and router configuration. Unlike DNCP, which is a subtle and elegant jewel, HNCP is just what you'd expect -- dump a bunch of recursive TLVs and let the peers deal with it. (The subtlety is actually elsewhere -- it's in the prefix assignment algorithm and system-dependent sequencing of the router configuration procedures.) Accordingly, I have fewer concerns about HNCP -- it's a simple protocol, and the large TLV space will allow future us to paste over any mistakes that present us are making.
An HNCP data block is structured as follows. The DNCP node state contains a number of global HNCP options, such as the HNCP capabilities and information about assigned prefixes. For each "external connection" there is an EXTERNAL-CONNECTION TLV, which contains a number of DELEGATED-PREFIX. Stateless DHCP data can appear within both the EXTERNAL-CONNECTION and DELEGATED-PREFIX TLVs, with slightly different meaning. Note that I haven't implemented much of HNCP yet, so my comments here are likely to be even more wrong than my comments about DNCP. Please be patient and repeat your answers until it clicks. Packet format and transmission ------------------------------ ### Port and IP Is a passive node allowed to use a non-standard port? If so, which TLVs are to be honoured from a non-standard port? I suggest: only requests, with NODE-ENDPOINT ignored. A passive node is not allowed to use global unicast (Section 3). Even when using security? ### Versioning HNCP includes a mandatory HNCP-VERSION TLV, that contains both an eight-bit version number (currently set to 0) and a set of capabilities. If a node does not recognise the version, it continues synchronising the data over DNCP, but ignores its contents. Unfortunately, as it is defined here, HNCP-VERSION is not likely to allow evolving the protocol, since it is impossible for a node to participate in both versions. I suggest simply renaming HNCP-VERSION to HNCP-VERSION-0, and expanding the Reserved field to the full 16 bits. Should the need arise to replace the protocol, we can always define a new HNCP-VERSION-2 TLV, so that a node can specify that it speaks HNCPv0 (using HNCP-VERSION-0), HNCPv2 (using HNCP-VERSION-2) or both (using both). Prefix management ----------------- ### Prefix assignment policy is not specified There are a number of details that are not specified in the prefix assignment section. Should a router assign one prefix per link per external connection, one prefix per link per delegated prefix, just one per link, or is that a matter of local policy? If just one per link, since neither the delegated prefix nor the external connection TLVs carry a priority field, how can the network administrator cause one particular delegated prefix to be preferred (other than using the preferred time, with all the issues that this entails). If a node is assigning prefixes smaller than /64 (or /24 in IPv4), how does it prevent fragmentation of the available space? ### Prefix Domain is not clear It is not clear to me what information the PREFIX-DOMAIN TLV is supposed to carry. I imagine that values 1-128 carry source-specific routing information (in which case this should be said explicitly, and the exact procedure for applying sources to routes should be described), but I have no idea what value 129 is supposed to mean. The encoding of prefix length is strange. Why not have one octet of type, one octet of prefix length, and then the prefix? Is this TLV allowed to appear multiple times within the same delegated prefix? If so, what is the meaning -- and, or? ### Unknown DHCP options in DELEGATED-PREFIX cause prefix assignment to fail If a DELEGATED-PREFIX TLV contains a DHCP4-DATA TLV which advertises an LPR server, and the local implementation doesn't know about the old Berkeley protocols, it will be ignored for prefix assignment Section 6.2.3). On the other hand, the same option in the enclosing EXTERNAL-CONNECTION will be silently ignored (I think, it doesn't say). Is this the expected behaviour? If so, please add the rationale to the draft. ### Default priority is too low Section 6.2.2 specifies the default priority for prefix assignment is 2. That leaves just 2 lower priorities, but 8 higher priorities (not counting the reserved and special priorities). Please explain. ### Impossible to assign prefixes without implementing RA/DHCP Section 6.2.3 specifies that in order to do prefix assignment a node must implement RA or DHCP. This requirement should obviously exclude private prefixes. While I understand the rationale for this, I think this is too strong. I suggest that this should be changed to only allowing assignment with a priority of 0 (or perhaps 0 or 1). Or perhaps use the usual "administrator intervention" verbiage. ### Prefix delegation support Section 6.2.6 doesn't specify that the assignment must be private. ### Domain name has no priority There is no priority field in the DOMAIN-NAME TLV. I expect vendors to preconfigure routers with domain names such as "home.cisco-rocks.net", it would be nice to have a reliable means to override that. ### Rationale for ULA retraction not clear Section 6.4 specifies (roughly speaking) that ULAs are not assigned if there are global prefixes available. Does this reflect the consensus of the WG? While I happen to agree with this policy, I think that MUST NOT is too strong here; I believe that this should be the default, but can be overridden by the administrator. Other data ---------- ### NODE-ADDRESS is underspecified When a node assigns itself an address that it advertises over NODE-ADDRESS, must that be an address within a prefix assigned to an attached link, or will any assigned prefix in the homenet do? ### DHCP-DATA is underspecified The meaning of the DHCP-DATA TLVs is not clear to me. Should they be readvertised on links that have assigned prefixes from the encosing EXTERNAL-CONNECTION, or should they be readvertised on all links? Or is the router expected to use this data to configure a DNS forwarder? ### NODE-NAME is underspecified The description of the NODE-NAME TLV doesn't say if it is an FQDN, or whether it is a name under the Domain Name, or whether the interpretation depends on whether it contains any periods. (It says "DNS label", but I'm too lazy to dust my copy of RFC 1035). It's also not clear what a node is supposed to do with this information. Advertise it in DNS? _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
