Subject: [homenet] PREFIX-DOMAIN in HNCP

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 10 Jul 2015 13:12:26 +0200

Steven, Markus,

I still find the PREFIX-DOMAIN TLV confusing.  Could you please confirm
that the following is correct:

1. the PREFIX-DOMAIN TLV can only appear within a DELEGATED-PREFIX TLV;

2. if a DELEGATED-PREFIX TLV contains no PREFIX-DOMAIN, or if it contains
   a PREFIX-DOMAIN with Prefix Length = 0 (possibly among other such TLVs),
   then it MAY be used for assignment;  otherwise, it MUST NOT be used for
   assignment;

3. if a delegated prefix with non-zero domain is included within a prefix
   with zero domain, it still causes the (longer, smaller) prefix to be
   excluded from prefix assignment according to 6.2.1.

Thanks,

-- Juliusz

---

From: Steven Barth <[email-masked]>
Date: Fri, 10 Jul 2015 13:37:20 +0200

> 1. the PREFIX-DOMAIN TLV can only appear within a DELEGATED-PREFIX TLV;
Correct.

>    then it MAY be used for assignment;  otherwise, it MUST NOT be used for
No, -07 currently says that locally generated prefixes (e.g. ULAs) and
those with internet access are "desired" in the sense of
draft-ietf-homenet-prefix-assignment (this is not standard normative language).
Maybe we should ask Pierre what the actual normative translation to that is,
my personal take is that desired means "MUST assign" unless changed by
local policy.

Anyway others aren't currently "desired" by default, i.e. except by policy.
Thinking about that this might be too restrictive since we want to usually just
pass on all information to clients by default. So consider this changed for -08,
to all are desired by default.

I'm currently considering  a new type "explicit" or so which says that you must
only assign prefixes from this is you can actually identify this by (manufacturer
or administrator provided) local policy retaining that functionality. So you can
still have special DPs which are only selectively assigned from.

Also maybe this thing should be renamed to Prefix Policy TLV since this seems
more accurate.

It is intended as: Delegated Prefixes included within other Delegated Prefixes
are ignored, as well as their nested options. I will make this more explicit.

Cheers,

Steven

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 10 Jul 2015 14:22:55 +0200

> draft-ietf-homenet-prefix-assignment (this is not standard normative
> language).  Maybe we should ask Pierre what the actual normative
> translation to that is,

I'm happy with the current situation -- "desired" is precisely defined in
the PA draft.  I would simply suggest changing hncp to say "desired in the
sense defined in Section whatever of [I.D.-whatever]".  And put "desired"
in Italics ;-)

> consider this changed for -08, to all are desired by default.

Oh, my.

In that case, please clarify whether prefixes assigned from non-zero
policy prefixes should be treated specially, by HNCP, by the routing
protocol, or by RA/DHCP.  (E.g. do I just serve such a prefix normally
over DHCPv4?  Do I tag it somehow in the routing protocol?  Do I serve the
associated DHCP options normally, say DNS servers?)

Steven, I'd really be grateful for a usage scenario.

> Also maybe this thing should be renamed to Prefix Policy TLV since this
> seems more accurate.

That's probably better, since it doesn't imply it's a DNS thing.

> It is intended as: Delegated Prefixes included within other Delegated
> Prefixes are ignored, as well as their nested options.

Right, silly me.  Excluded prefixes are encoded as Assigned Prefixes with
Link Identifier zero and Priority 15 (Section 6.2.5).

-- Juliusz

---

From: Steven Barth <[email-masked]>
Date: Fri, 10 Jul 2015 15:12:11 +0200

> Steven, I'd really be grateful for a usage scenario.
There is the section "Special Purpose Prefixes" (now renamed to "Prefix Policy") which specifies extra behavior. In general (unless noted there) you do not treat them differently than other prefixes.

Just serve them via RA/DHCPv6 as usual if they are assigned. Also HNCP does not specify routing protocol behavior so that's out of scope. At some point when mif-wg has finalized their work on special RA or DHCPv6 options, clients will be able to identify and interpret them based on the TBD options that HNCP just passes through, until then its basic SAS.

IPv4 / DHCPv4 only allows a single prefix, so it doesn't really apply there anyway.

Example usecases for Prefix Policy (autonomous and manual):
1. You have a (company?) VPN router and only want to be able to reach the VPN from a certain link, e.g. only in your home office.
2. You are an IOT-device manufacturer and want to form a single prefix / "IOT-network" if a user has multiple of your IOT-gateways (and with that even discover there is a second one already).
3. You are an ISP and have a special purpose uplink or vlan (e.g. for IPTV) and only want to assign prefixes from these to your HNCP-Enabled STPs that can really use them, but you want the user to be able to place these boxes anywhere in the network.

Maybe it would be worth adding 1 or 2 of them to the draft as well.

Cheers,

Steven