Re: [homenet] Homenets and MPVD

Markus Stenberg <markus.stenberg@iki.fi> Tue, 03 February 2015 09:27 UTC

Return-Path: <markus.stenberg@iki.fi>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C2D1A0062 for <homenet@ietfa.amsl.com>; Tue, 3 Feb 2015 01:27:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUkYqZsWxTkg for <homenet@ietfa.amsl.com>; Tue, 3 Feb 2015 01:27:29 -0800 (PST)
Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.203]) by ietfa.amsl.com (Postfix) with ESMTP id 072B01A0055 for <homenet@ietf.org>; Tue, 3 Feb 2015 01:27:29 -0800 (PST)
Received: from poro.lan (80.220.64.126) by jenni2.inet.fi (8.5.142.08) (authenticated as stenma-47) id 54C8F2EA00A95B24; Tue, 3 Feb 2015 11:27:23 +0200
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Markus Stenberg <markus.stenberg@iki.fi>
In-Reply-To: <4193A650-550D-4CA5-B23D-06AECA4F645A@cisco.com>
Date: Tue, 03 Feb 2015 11:27:22 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <749396A0-A21C-47DF-94E1-DB3FDB7C1485@iki.fi>
References: <54D00ECA.1070802@gmail.com> <84ECBDCC-DAE1-4227-B7C6-27978063CB3D@darou.fr> <F7309B04-BBA5-40F0-B87F-118E3F4C2B43@iki.fi> <4193A650-550D-4CA5-B23D-06AECA4F645A@cisco.com>
To: Ole Troan <ot@cisco.com>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/homenet/PfNsIfE1sYFc077O95-GbTCvBWA>
Cc: HOMENET <homenet@ietf.org>, Markus Stenberg <markus.stenberg@iki.fi>, Pierre Pfister <pierre.pfister@darou.fr>
Subject: Re: [homenet] Homenets and MPVD
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Feb 2015 09:27:30 -0000

On 3.2.2015, at 11.07, Ole Troan <ot@cisco.com> wrote:
>>> 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).
>> 
>> 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. 
> 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.

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