Re: [mif] next step for MIF PVD configuration

Margaret Cullen <margaretw42@gmail.com> Wed, 02 March 2016 12:50 UTC

Return-Path: <margaretw42@gmail.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6BB1A008E for <mif@ietfa.amsl.com>; Wed, 2 Mar 2016 04:50:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.45
X-Spam-Level:
X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 r-VztzAJ64mW for <mif@ietfa.amsl.com>; Wed, 2 Mar 2016 04:50:08 -0800 (PST)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A6991A0060 for <mif@ietf.org>; Wed, 2 Mar 2016 04:50:08 -0800 (PST)
Received: by mail-yw0-x22b.google.com with SMTP id u200so175437852ywf.0 for <mif@ietf.org>; Wed, 02 Mar 2016 04:50:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d87skpjbLA92gZx3H7yic3kOgUhwtgJ4dTjZT5wIKPA=; b=e3DT1l6vM/WmBvQR4/+6JvvCSEbAUIWs5geHLHNUztq+9qS0KsjCHhoGOhQ3Cp0Dih 3sRElV6gpFF1oW7F5RZeNvMAmk5BEQy4Ggmq+TcCRuBh51Lra8v2FVy5WA1SllYFPpLD oL2+MqFXeUXkQGjH/YyIeFJDCVMKYjSYxYM22m5oGJO+fNRUaFAtzcxqfmM2x36p2zEc 4dFB5b8X32t1OVw6BCTgSVL2Q3j7UdzR19K7RJW6/MaD48r80F7Po2BLq4KRkGOTpdgz mh69nfx1Eu4RIrVXqAav8UT8sBj4fDMEshSa0uxX63W/E2h1T7brVK6vlPMMSMHhbv59 4SyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=d87skpjbLA92gZx3H7yic3kOgUhwtgJ4dTjZT5wIKPA=; b=Zmp1VyW/QtjS8ucdeWmIv8qGWN/g9H/SYIwZ0iTAh6ar+QlgN1IFdL1yGyO0tl/FH2 c74961DKvqGfDwVp//m+p+gxSHkSqXISF2QoBDvpteQ6QJ2LYjAfmx7irmJ82jXa8KV+ EZ/7Y9ydHABiEeAtlsnl84549WyD/xFnCviN/BkoAav7uTy1SENnQHfvxaifYmvMbzuy fbYg/W2fvWhN4ccKQDH2x/Ud7MO+SN46qQxAVBnQSlav9VAb/nAyekos+GZU654mD0cl o3aFIHChWBXbeFl1yJSJClsrAKTv3u6z+Pkn/VaEwiUZE3SXYbGLrHR9VVwXUx97vmj2 cS3Q==
X-Gm-Message-State: AD7BkJI+64gj4QYn+x0BVEtVcbNH6tAcXbjwJctuTQe8pc/cZU1a4zXbffRJhQqhnLxdvw==
X-Received: by 10.129.31.131 with SMTP id f125mr14453445ywf.267.1456923007975; Wed, 02 Mar 2016 04:50:07 -0800 (PST)
Received: from new-host.home (pool-72-74-19-153.bstnma.fios.verizon.net. [72.74.19.153]) by smtp.gmail.com with ESMTPSA id g187sm28387535ywd.51.2016.03.02.04.50.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 02 Mar 2016 04:50:07 -0800 (PST)
Sender: Margaret Cullen <mrcullen42@gmail.com>
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Margaret Cullen <margaretw42@gmail.com>
In-Reply-To: <56D44703.7050700@fer.hr>
Date: Wed, 02 Mar 2016 07:50:06 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <B48816CA-81A5-457B-A82D-28EC4F5E517A@gmail.com>
References: <COL125-W396ADD4D31445DAE7867D3B1BA0@phx.gbl> <56D44703.7050700@fer.hr>
To: Stjepan Groš <stjepan.gros@fer.hr>
X-Mailer: Apple Mail (2.1510)
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/98ZAEKoPalX2jE9TlNJCjcDfEns>
Cc: mif@ietf.org
Subject: Re: [mif] next step for MIF PVD configuration
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mif/>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Mar 2016 12:50:10 -0000

Hi Stepjan,

On Feb 29, 2016, at 8:26 AM, Stjepan Groš <stjepan.gros@fer.hr> wrote:

> Hi all!
> 
> On 29.02.2016 11:21, Hui Deng wrote:
>> Hello all
>> 
>> We had the concensus already about droping DHCP MPVD ID document, 
>> based on this, here chairs would like to understand whether MIF WG
>> has achieved the concensus on below two steps to deliver MPVD conf.
>> 1) step 1: using RA to get MPVD ID information
>> 2) step 2: using DNS to get other MPVD configuration.

There has been previous mention on the list regarding this two-step approach, although it did not use that terminology -- in the minutes from Yokohama, it has been previous referred to as an "offline mechanism".  It was discussed in the minutes from Yokohama which were posted to the list.  During the meeting, we reached consensus of those int he room that we should use RAs to identify an explicit PVD, and that we should use an offline mechanism to get further PVD information.

The MIF WG minutes from the last meeting can be round here:
https://www.ietf.org/proceedings/94/minutes/minutes-94-mif) 

There is currently one proposal for an offline mechanism, the MPVD DNS proposal (draft-stenberg-mif-mpvd-dns).  It was also presented in Yokohama.  There seemed to be general agreement in the room that a DNS approach would be workable, but there were concerns raised about the specific proposal in this document (use of TXT records, etc.).

At this point we are trying to see if we can recharter the group to work on a two step proposal for PVD configuration using RAs and using DNS as the offline mechanism for further PVD configuration.  That is the "two-step approach" that is being referred to here.

> 
> Since I didn't saw any discussions on this list about those proposals I have few questions/comments:
> 
> 1. Is this only for IPv6, or it is for IPv4 too (step 2)?

A DNS lookup could be used for IPv4 or IPv6.  Right now, though, there has only really been discussion of how a host could get it's explicit PVD ID (which would most likely be needed for the lookup) from an IPv6 RA.  It is possible that we could define a way for an IPv4 host to get it's PVD ID, but the IPR on using DHCP for this makes that somewhat challenging.

> 2. Why only MPVD ID in RA? Why not other information too for which RA is a natural place to be?

There has been a great deal of concern expressed about adding all sorts of different configuration information into RAs.  In fact, currently RAs don't even contain enough information to do a secure DNS lookup, as they are missing an NTP configuration option.

There was consensus in the room that it would be better to get the PVD ID from an RA and use a second step to look up the full PVD configuration information.  the only current proposal for that second step is to do it via DNS.

> 3. Why turn DNS into a local network configuration protocol?

Well, there is an extent to which DNS is already used for these things via SRV records, TXT records, etc.  However, I do see your point to some extent…  What would you use propose that we use instead?

Margaret