Subject: [homenet] Concerns about HNCP

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 01 Jul 2015 20:53:42 +0200

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?

---

From: Steven Barth <[email-masked]>
Date: Thu, 02 Jul 2015 11:49:45 +0200

Hi Juliusz,

thanks a lot for your comments.
Replies inline.

Cheers,

Steven

> Packet format and transmission
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
HNCP only specifies link-local communication, i.e. any communication from
non link-local addresses is ignored independent if security is enabled or
not.

> (using HNCP-VERSION-0), HNCPv2 (using HNCP-VERSION-2) or both (using
This makes sense, we will change it in the draft.

> Prefix management
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.

> does it prevent fragmentation of the available space?

IIRC that is defined in the prefix assignment draft.

> 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.

* ...?

> 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.

> prefix?  If so, what is the meaning -- and, or?

Or makes no sense to me really, so and.

> Is this the expected behaviour?  If so, please add the rationale to the
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.

> the reserved and special priorities).  Please explain.
The cases where local choices should actually have a lower priority over
defaults seemed rare in comparison.

> "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.

> 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"

> 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.

> 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

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."

> 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.

> 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.
Possibly, if it runs a DNS forwarder or MDNS-proxy. Maybe we should
mention that.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 02 Jul 2015 16:50:01 +0200

> HNCP-PORT instead of the source port they used.  I'm not sure if its
> worth it to change that.

Yes, it is.  I feel very strongly about it.

One thing that people often overlook is that a protocol's success is
reliant on ease of implementation and ease of debugging.  In the MANET
space, for example, OLSR has taken over the world while AODV is
languishing because the former can reasonably be implemented and debugged.

DNCP profiles are challenging to debug (trust me, I know), since in steady
state they only exchanges hashes -- a packet trace gives you very little
information.  In order to debug a HNCP implementation, you need a way to
get it to dump its state, which is easy enough if you can send it a series
of requests and get at the replies.

What I'm asking is simply the ability to dump the state of a buggy,
closed-source HNCP speaker by doing e.g.:

  hncp-dumper fe80::dead:beef%eth0

without having to bind a reserved port and therefore interfering with
other HNCP speakers on the local node.  This cannot be done unless the
spec mandates replying to requests on the port they were sent from.

> non link-local addresses is ignored independent if security is enabled or

I don't feel very strongly about this particular issue.  What I am asking
here is the ability to do:

  hncp-dumper buggy-router.home

without having to fool with interfaces and link-local addresses.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 02 Jul 2015 17:05:56 +0200

> IIRC that is defined in the prefix assignment draft.

Right.  Smart draft.

>> ### Prefix Domain is not clear
[...]
> The prefix domain TLV is used to convey some meta-information about prefixes.
[...]
> There are several use cases here:

So it's essentially a vendor extension encoded as either an IP or a domain
name?

> So unknown top-level options are simply forwarded.

I'm still confused.  If I'm not doing PD, am I not allowed to grab
prefixes in a delegated prefix with unknown options?  What should an
implementation that doesn't speak DHCP do -- not even parse the
DELEGATED-PREFIX sub-TLVs (which is what I do currently), or drop any
delegated prefixes with any DHCP options at all?

(I'm actually parsing DHCP, but only the name server bits.)

> NOT be sent unless explicitly configured.

I'd still like a priority field.  It doesn't seem like it would add much
implementation complexity.

> interface specified by the endpoint identifier."

So in order to put a /128 on the loopback I need to do the full prefix
assignment dance.  Please don't change that, I'll let you know how I feel
about it when I'm finished implementing PA.

-- Juliusz

---

From: Steven Barth <[email-masked]>
Date: Thu, 02 Jul 2015 17:33:13 +0200

> So it's essentially a vendor extension encoded as either an IP or a domain
It is partly opaque if you are referring to that, but even for domain
names you could find potentially clever uses like telling your resolver
to use the associated DNS-servers for a special domain (only). I guess I
should write the non-opaque usecases (e.g. firewalling, DNS) out.

> (I'm actually parsing DHCP, but only the name server bits.)
Okay for more clarity (and note to self to make it more clear):
DHCPV6/4-DATA can be contained in EXTERNAL-CONNECTION
and / or DELEGATED-PREFIX.

If it is in EXTERNAL-CONNECTION it contains the usual top-level
options, e.g. DNS-Server, NTP server, what not. The HNCP
implementation does not need to know every option here.

If it is in DELEGATED-PREFIX then it contains special DP-specific
options which MUST BE understood, e.g. RFC 6603. In DHCPv6
land these are not top-level options but contained within the
OPTION_IAPREFIX DHCPv6 option.

They are meaningful for prefix assignment and therefore
cannot be ignored so you have to ignore that DP if you don't
understand them.

> implementation complexity.
It seems unnecessary though if we actually define it that the source
MUST be an administrator. If you think about silly vendor adverts in
there, then these vendors might also just use the highest prio and
then you would be back at the start.

Cheers,

Steven