Hi Juliusz,
thanks a lot for your comments.
Replies inline.
Cheers,
Steven
> 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.
The draft - in its current version - does not really mandate that, so at
the moment implementations must be ready to receive replies on the
HNCP-PORT instead of the source port they used. I'm not sure if its worth it
to change that.
>
> A passive node is not allowed to use global unicast (Section 3). Even
> when using security?
HNCP only specifies link-local communication, i.e. any communication from
non link-local addresses is ignored independent if security is enabled or
not.
>
>
> ### 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).
This makes sense, we will change it in the draft.
>
>
> 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).
Section 6.3.2 actually specifies when it is "desired" (in the prefix
assignment sense) and that is usually one assignment per delegated prefix
per (Common) link.
Come to think of it since its a MUST there, we should probably add a stance
like "unless explicitly overriden by local choice". And should probably say
that by default only locally generated and with internet access should be
chosen.
To allow for saner local policy choices we added the Prefix Domain TLV there,
so you can attach a bit more meaning to a prefix. See below.
>
> If a node is assigning prefixes smaller than /64 (or /24 in IPv4), how
> does it prevent fragmentation of the available space?
IIRC that is defined in the prefix assignment draft.
> ### 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 prefix domain TLV is used to convey some meta-information about prefixes.
The main intention is to be able to distinguish what the prefix actually is:
i.e. is it locally generated, does it offer internet access, is it used to
access a certain walled garden (i.e. company VPN, IPTV service etc.).
There are several use cases here:
* You may not want to assign prefixes from certain addresses to all links since
your clients may choose a walled garden address to try to access the internet.
(Clients only do very naive SAS)
* Certain (e.g. IOT) devices may want to identify other devices of the same kind
e.g. using the same "cloud" and reuse their connectivity to "upstream". This was
brought up as an idea at last IETF.
* If you have a walled garden and know exactly whats on the other side you can
fine tune your firewall to accept only packets from certain destinations.
* ...?
>
> The encoding of prefix length is strange. Why not have one octet of type,
> one octet of prefix length, and then the prefix?
Since we don't have prefixes longer than 128 why not use
the remaining values for something more meaningful.
>
> Is this TLV allowed to appear multiple times within the same delegated
> prefix? If so, what is the meaning -- and, or?
Or makes no sense to me really, so and.
>
> ### 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.
There are two levels of DHCP options here for IPv6. Per connection (top-level
options) and per-Delegated Prefix and this is aimed at per DP only. There
are several per DP options which must be strictly understood in order to operate
correctly, e.g. RFC 6603 and the (now-expired) prefix class / attributes draft
and possibly MIF options in the future.
So unknown top-level options are simply forwarded.
>
> ### 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.
The cases where local choices should actually have a lower priority over
defaults seemed rare in comparison.
>
> ### 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.
Well the main issue is, if nobody is forced to implement RAs then we might
end up with links where nobody does it, which breaks clients.
We could make it a MUST if the link is destined to be used by clients.
In any case an RA server is a few hundred LOC so not really that much of
a burden IMO. DHCPv4 is a bit more awkward though.
>
> ### Prefix delegation support
>
> Section 6.2.6 doesn't specify that the assignment must be private.
It actually does.
"Each client MUST be considered as an independent Private Link"
>
> ### 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.
I suppose since we have a default value we might want to add that this MUST
NOT be sent unless explicitly configured.
>
> ### 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.
What it was intended to say (and I think the draft says) is that there may
only be at most one locally generated ULA (i.e. without Prefix Domain TLV).
But creating such a locally generated ULA in presence of global prefixes is
optional (MAY). We will go through that paragraph again and make it clear.
Also here is another use case for that Prefix Domain TLV, we want to be able
to distinguish where ULAs come from ;)
>
>
> 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?
The draft says:
"An assigned address MUST be in the first quarter of an assigned
prefix currently applied on a Common Link which includes the
interface specified by the endpoint identifier."
>
>
> ### 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?
RFC 7084 (which is referenced somewhere) says that a router SHOULD make
acquired options available via DHCPv6 to clients. We don't explicitly
state anything for DHCPv4 in general but we probably should.
I think SHOULD readvertise on interfaces where a prefix is assigned makes
sense. However it is up to the router if it actually comes with a DNS
forwarder or if it just advertises the ISP's DNS-server to clients.
In the general the whole thing is essentially the mif problem.
>
> ### 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).
I think we had this discussion internally recently. It should be a single
name not a FQDN, should probably make that more clear.
>
> It's also not clear what a node is supposed to do with this information.
> Advertise it in DNS?
Possibly, if it runs a DNS forwarder or MDNS-proxy. Maybe we should
mention that.
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
