Subject: [homenet] Homenets and MPVD

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Feb 2015 12:56:58 +1300

Hi,

I find myself wondering how draft-ietf-homenet-prefix-assignment
and draft-ietf-homenet-hncp will be reconciled with the MIF
MPVD architecture
(http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/).
Has anybody thought about that yet?

Regards
   Brian

---

From: Pierre Pfister <[email-masked]>
Date: Tue, 3 Feb 2015 08:46:53 +0100

Hello Brian,

MIF targets host configuration with PVDs. For that purpose, they are likely to do it using DHCP and RA options.
Service providers will also use such options for CPE routers configuration, associated with the delegated prefixes during the DHCP exchange.

Current HNCP strategy is to abstract what can be conveyed inside DHCP options by sharing them directly with all other routers.
For every external connection, CPE routers will advertise an External Connection TLV (Section 6.1. in HNCP).
This TLV may contain one or multiple Delegated Prefix TLVs as well as raw DHCP options (in the DHCPv4 or DHCPv6 TLV) associated with the external connection (e.g. DNS delegated zone or search domains).
Each Delegated Prefix may as well be associated with different DHCP options (e.g. Prefix class options).

All routers gather this information through HNCP and use it to configure hosts. DHCP options that are associated with a given delegated prefix are given to hosts associated with the link prefix provided by the prefix assignment algorithm. DHCP options that are not associated with a delegated prefix are aggregated and given to the host (Excepted for the DNS server option, as the router is used as DNS relay).
For now, the aggregation of such information is not specified (although in practice it can be done quite easily for most DHCP options).
But I believe it will be much clearer once MIF provides PVD specifications.

I think this approach will be sufficient. If it happen to not be, External Connection TLVs and Delegated Prefixes TLVs could contain other types of TLVs.

Regards,

  Pierre

Le 3 févr. 2015 à 00:56, Brian E Carpenter <[email-masked]> a écrit :

> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 3 Feb 2015 10:53:16 +0200

> All routers gather this information through HNCP and use it to configure hosts. DHCP options that are associated with a given delegated prefix are given to hosts associated with the link prefix pro…

DNS server option is mostly changed so we can do in-home service discovery. In MIF world, we would probably pass along DNS servers within PVDs as is, provide (e.g.) ‘.home’ PVD for in-home services only, and provide only to legacy clients the ‘relay’ DNS server address. So oddly enough, current scheme would work, most likely as-is ;) The unknown new PVD option would be passed along as is, and the clients would treat the provided legacy DNS server (+search path) as an extra implicit PVD with hopefully lower priority than the explicit PVDs.

Not changing PVDs may be crucial if the PVD authentication ever takes hold, as changing it’s content then may make it altogether invalid from the client’s point of view. 

Cheers,

-Markus

---

From: Ole Troan <[email-masked]>
Date: Tue, 3 Feb 2015 10:07:52 +0100

Markus,

> Not changing PVDs may be crucial if the PVD authentication ever takes hold, as changing it’s content then may make it altogether invalid from the client’s point of view. 

is it actually obvious that you'd pass the PVDs to the hosts in homenets?
PVDs contain policy. and allowing them to pass the administrative boundary into a home is also up to policy.
given that we already have options to control DNS server selection policy. why can't the home border amalgamate that information (according to local policy)?

sorry, I'm struggling to understand the PVD use case I suppose.

cheers,
Ole

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 3 Feb 2015 11:27:22 +0200

On 3.2.2015, at 11.07, Ole Troan <[email-masked]> wrote:
> sorry, I’m struggling to understand the PVD use case I suppose.

I vaguely remember one homenet design goal to be as transparent to clients as possible.

PVD tell you also about the kind of connectivity available there etc. While I am sure we _could_ fabricate local one, it is much easier to tell that e.g. one upstream connection is pay-per-byte 4g, and other one is VDSL2 and let hosts make educated choices instead of guesses about source prefixes to use.

Is this covered somewhere elsewhere in the DHCP option jungle?

Cheers,

-Markus

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Feb 2015 07:00:40 -0500

> given that we already have options to control DNS server selection policy. why can't the home border amalgamate that information (according to local policy)?

This is actually accounted for in the MPVD arch document.   However, that document does not contain a specific description of how to make PVDs work in a homenet--it just mentions the possibility that one might want to relay some information from the ISP intact to preserve signature information.   I think that there should be a follow-on document that explains how to do MPVD in a homenet environment and goes through the various scenarios.   What Markus described is pretty much what we had in mind.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Feb 2015 07:02:53 -0500

> PVD tell you also about the kind of connectivity available there etc. While I am sure we _could_ fabricate local one, it is much easier to tell that e.g. one upstream connection is pay-per-byte 4g,…

One of the design goals of the PVD architecture is to make it possible to get the same behavior in a 4G handset with a Wifi interface and in a laptop with no 4G interface that's connected to a network with a 4G PVD and a wireline PVD.

> Is this covered somewhere elsewhere in the DHCP option jungle?

A document is being worked on to address this, but no, it is not yet covered.

---

From: Ole Troan <[email-masked]>
Date: Tue, 3 Feb 2015 14:57:33 +0100

> One of the design goals of the PVD architecture is to make it possible to get the same behavior in a 4G handset with a Wifi interface and in a laptop with no 4G interface that's connected to a netw…

what behaviour is that?

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Feb 2015 08:08:44 -0600

> what behaviour is that?

At the moment, handsets typically prefer wifi if available.   Android 5 will actually use both interfaces in an MPVD-style separation, so that the presence of a WiFi interface is taken advantage of if it works, but doesn't break the 4G service if WiFi is nonfunctional.   This is one of the general goals of the MPVD architecture.

It would be nice if the same behavior could be achieved on a homenet.