Re: [mif] Subject: Comments on draft-ietf-mif-mpvd-dhcp-support-01

Steven Barth <> Wed, 22 July 2015 07:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A929B1ACDF0 for <>; Wed, 22 Jul 2015 00:21:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.549
X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yTCASnMOTWNL for <>; Wed, 22 Jul 2015 00:21:16 -0700 (PDT)
Received: from ( [IPv6:2001:1bc0:d::4:9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 272681B2AAE for <>; Wed, 22 Jul 2015 00:21:16 -0700 (PDT)
Received: from localhost ([]) by id 1ZHoL4-0000mo-Bv with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for ; Wed, 22 Jul 2015 09:21:14 +0200
To: Hui Deng <>, "" <>
References: <COL125-W436833B2B6FAD013C45D6DB1830@phx.gbl>
From: Steven Barth <>
Message-ID: <>
Date: Wed, 22 Jul 2015 09:21:13 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <COL125-W436833B2B6FAD013C45D6DB1830@phx.gbl>
Content-Type: multipart/alternative; boundary="------------070707070207090606030506"
Archived-At: <>
Subject: Re: [mif] Subject: Comments on draft-ietf-mif-mpvd-dhcp-support-01
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiple Interface Discussion List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Jul 2015 07:21:18 -0000

I resent it and it went through. See
It seems my subscription wasn't 100% through the first time I sent, sorry about that.

Am 22.07.2015 um 09:13 schrieb Hui Deng:
> Hello all,
> Steven sent this, by some chance, it was not shown up in our list, so I cc here
> From: Steven Barth <>
> To:
> Cc: 
> Date: Tue, 21 Jul 2015 21:55:49 +0200
> Subject: Comments on draft-ietf-mif-mpvd-dhcp-support-01
> Hi everyone,
> as promised few comments on the DHCPv6 support draft. This is based on roughly
> reading it 1-2 times and not meant to be conclusive in any way. Also I'm not a
> dhc expert, though I have implemented a DHCPv6 client, server and relay myself.
> 3 SHOULD contain exactly one still allows more than one PVD_AUTH vs.
> "MUST be the last option inside PVD" in 5
> 5 refers to RFC3791 in key-hash and digital-signature options but 3791 is
> not part of references.
> 6 specifies that ANY options may be encapsulated. This is awkward, e.g., what
> would be the meaning of e.g. a Status or a Reconfigure-Accept option within
> that container, more general what happens to options explicitly defined to be
> on some level and / or having a specific meaning there?
> Also where may your container option be present? Only on the top-level?
> Also inside IA_NA/IA_PD? Inside IAAddr / IAPrefix?
> Also in which DHCPv6 messages may your container appear?
> 7.1 merely specifies to send ORO etc. in SOLICIT, but not in REQUEST, RENEW etc.
> whereas 7.3 says OPTION_PVD must not be sent if ORO is absent in request
> 8 mentions the use of timestamps to avoid replay attacks, though DHCPv6 is usually
> used to bootstrap network connectivity and thus at this point devices (especially
> embedded ones) may not have an accurate wallclock yet. This is especially interesting
> since DHCPv6 itself may carry NTP server addresses to use.
> Some additional stuff related to routers forwarding this kind of information from
> to clients (e.g. your coffee shop example in 8). In general this should applies to CPEs,
> as specified in RFC 7084, especially if they themselves got the information using
> DHCPv6 from an ISP, but not necessarily. Again disclaimer: this list is not conclusive:
> Since you don't restrict options inside your container, it may originally contain options
> e.g. FQDN which may only be directed at the specific receiving router but not hosts behind
> it (e.g. the hotspot got the PVD TLVs via DHCPV6 itself). Furthermore the container may
> contain options which are specified to not be sent to clients unless explicitly asked for
> in an ORO. In both instances the "coffee shop router" would need to dynamically remove
> options from the container which will inevitably invalidate the signature of the container.
> Also given the "coffee shop router" is supposed to hand out addresses from different PVDs
> and "tag" them appropriately: How is it supposed to do that with just a container which
> SHOULD contain a signature?
> It certainly cannot place IAAddrs or IAPrefixes inside containers since it doesn't have
> the key (there are more and even more severe issues with trying to use containers for IA_Xs
> or IAAdress / IAPrefix but I will skip them for the sake of simplicity for now).
> Also, if a hotspot / CER / etc. asks (e.g. an ISP) for PVD information that does
> not necessarily mean that all the hosts behind said router will understand PVD information
> so that router requires that it also gets "legacy" information for "legacy" hosts being
> not PVD-aware OR it needs some guidance to construct that information from data within
> the PVD containers it got.
> Cheers,
> Steven