Re: [mif] next step for MIF PVD configuration

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

Return-Path: <mrcullen42@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 20A451A0092 for <mif@ietfa.amsl.com>; Wed, 2 Mar 2016 04:48:07 -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 y3jAH6S2OGGZ for <mif@ietfa.amsl.com>; Wed, 2 Mar 2016 04:48:05 -0800 (PST)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 A3BEC1A0041 for <mif@ietf.org>; Wed, 2 Mar 2016 04:48:05 -0800 (PST)
Received: by mail-yw0-x22a.google.com with SMTP id u200so175398538ywf.0 for <mif@ietf.org>; Wed, 02 Mar 2016 04:48:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d87skpjbLA92gZx3H7yic3kOgUhwtgJ4dTjZT5wIKPA=; b=WFmmMaCFabpNc9vmOLBtOjbY8wuNWx+C/ZpmVrj9uRSYj3ZCMVw3YE1hJ0Z4hBhIL/ u1NgFXKVhjtRuUu65uHpKexS6pLnuG2dPTe7XQvhMqgNJ7ZzRI6CmHJQaThBE9ziQ4Sg BxjK9xe7MVdpOQ7Z0cX9f+Ue67tt/6M1ieI+zCCle75cQ/n08GwwRJd639ZSSr26QiYD GZFgLKXawv3lwiJS5IjCcwV7RKX4QBHdyMROIc0B28cKae7iicvBMVhbwdNx7eKBQb+7 XQyP3KY0+r+RVOzUf6lkhzyHrdW43LoD5djuiBvM4mZXPCUBmX8P8vWXgaFyAWZ/f1C7 /J6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d87skpjbLA92gZx3H7yic3kOgUhwtgJ4dTjZT5wIKPA=; b=fI981wOC7F+5DdeMz8pBd/q7BOLEUIVrenwLBa3vj36nrFDyj3qbCOAuyBfe2rHCFP ytkxuRat9sHvDYZFxKAemROKgPEElJqiM1cvj4e0v5eGxkTTPhFCXYSarfMvk7TVUyzd pxTxLPqiCo2fi+yxIdPHfEEbKDofGKgO9e0tYdrFQjcjZdRtG5y4XqsCSe+jcc3Qr4sc D5kMXYn8T3XAYzYpDa6ChVk0+N4+CosVinn8B0+k+Drae81H0jZfvhNQdvR5V6cb0k1V q+I8K+V1fcI2R1Pz9xvJ0jN279leweDbBYCm2kvLPXRQ69dQBhcFY7Ue6wZb6STQRgNV Chvg==
X-Gm-Message-State: AD7BkJLc94NnxaEdtCxMjsvnpFxMAygnJsHi1OBEnmmFOjXZtqkZCD0tHMx9BrBoXZAYJw==
X-Received: by 10.129.72.78 with SMTP id v75mr16148713ywa.78.1456922884915; Wed, 02 Mar 2016 04:48:04 -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 d7sm28366182ywb.27.2016.03.02.04.48.03 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 02 Mar 2016 04:48:04 -0800 (PST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Margaret Cullen <mrcullen42@gmail.com>
In-Reply-To: <56D44703.7050700@fer.hr>
Date: Wed, 02 Mar 2016 07:48:02 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <256A8C0C-EEED-4AF4-8B59-DD8109AB1519@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/RbKjoogBInZoSeREps-6K_KPQ7g>
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:48:07 -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