From nobody Tue Mar 1 04:32:14 2016 Return-Path: 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 6D74C1B2B37 for ; Tue, 1 Mar 2016 04:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 vwelAwM06kSJ for ; Tue, 1 Mar 2016 04:32:11 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (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 0F0C01B2B3B for ; Tue, 1 Mar 2016 04:32:10 -0800 (PST) Received: by mail-yk0-x233.google.com with SMTP id z13so76005174ykd.0 for ; Tue, 01 Mar 2016 04:32:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=xa+Kp96pP7Y6xOVGwCljI5iU4OV+lIi4qNZ+MxSORuc=; b=M49s59MwUePvpW6lyepjKJtrMRBRJyqfaB+Qw6vJiumTGOzhD+1UOhUbPBM18LLPUX cMqUhscT6dJ5T5nmecO1fUqRZ3wM7VGxmQB1MaGbpGHrOH/vXV5B7B/m8Wr9RUEi1ZZh mcZ7/SAdub2+vS9tbel/VM+wFkXmafUt3U1BXtS57cfa+lXIWGozAbIAKQ090ENLeIvX gsNzEPjnF2kqFjOX5fFZodSE7GulMnOLaMa0QCDsGu6mfaMlnyc90A52r8zg0IcqckcL ZVB16q/24tXYd49tkJyrLMzOEV9zy95/wyUdSWyt+9xnq3EVsSyNYJvQZgNEfdPQMgG4 Z6eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=xa+Kp96pP7Y6xOVGwCljI5iU4OV+lIi4qNZ+MxSORuc=; b=jJuIcAPPPZ0JdsT1KeJxJE3Jqw15rEjGgOsA/6hrkO58fg+v45KGBo5Zvko/LPE4YW WtMaStwflo7uR9qwAQi7To9yDhON9visU0s4+0jTvIxLVQOrcl6UgXFQS3LaRcHmBfr9 Qcrl/cBuMwoigunnqhXv4sYX3tz2W2+pOS/SI4ZgfFY6yg+ZT0gGkC0ivMN8FRxDvjZt /IB7SUbUM8O9gDPjAo+/aJ8y51+gxBCB83pIrCzkmyXYjEULWJq8b4T4mFt6oDPx4EIA RLZ/JRia5OxLbWgOGXooj2ghi/LuIjoNZBorI7rG/HR0nZOVegcr8m1sQBunbRHiCoYT lm+g== X-Gm-Message-State: AD7BkJICPF/Wh7xkUlQyXGm7LGEskgu6RwDIalHb3PhW3voBkAXCimhq4HMQIK/QjDcrVA== X-Received: by 10.37.64.207 with SMTP id n198mr12128130yba.12.1456835529387; Tue, 01 Mar 2016 04:32:09 -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 u134sm24341536ywf.48.2016.03.01.04.32.08 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Mar 2016 04:32:08 -0800 (PST) From: Margaret Cullen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 1 Mar 2016 07:32:07 -0500 To: "mif@ietf.org List" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: Subject: [mif] New Charter Items? X-BeenThere: mif@ietf.org 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: Tue, 01 Mar 2016 12:32:12 -0000 At the last MIF meeting, and later on the mailing list, we reached = consensus that we would use a two-step approach for the configuration of = explicit PVDs. RAs would be used to provide the information to do a = second-step look up, including the PVD name. Then a second step would = be used to look up further information about the PVD. The only proposal we currently have on the table for a second-step = look-up is a DNS look-up, and no one seems to be advocating for another = method. So, to define a two-step approach using DNS, there are three = things that we need to specify: - An NTP server option for RAs, so that DNSSEC can be used for the = lookup. - A PVD Name option for RAs, so that we can tell hosts what PVD to look = up. - An explanation of what PVD information will be held in the DNS and = how. Those things would need to be added to our charter, so that we can = accept corresponding work items. Does anyone have any objection to adding explicit PVD configuration to = the MIF charter and adding these three work items to our milestone list? = If not, the chairs and the AD will propose a charter/milestone update = along these lines. Thanks, Margaret From nobody Wed Mar 2 04:24:56 2016 Return-Path: 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 03B0B1B2B72 for ; Wed, 2 Mar 2016 04:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 MOJSou4bY1lB for ; Wed, 2 Mar 2016 04:24:48 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (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 3C8511A1BC9 for ; Wed, 2 Mar 2016 04:24:48 -0800 (PST) Received: by mail-yk0-x233.google.com with SMTP id v186so1503917yke.2 for ; Wed, 02 Mar 2016 04:24:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=KnEOtnoTdx7eZ/hzDt7drJXeHMys4JlG3l/HjRbSOWw=; b=kil9Lvlw6uBaq3Z+I+PdA2QwEbS8b6J9ASEUGF7f1Zm5o2vdC8/AXjTUGOPltoDY/4 zKNVxCNroK3F/4b98BTKdq4NI3XsDv3vf+CedpWYCuK+T8+xXqrNnxGDmYcnYlMR7wLc iNAfSxb9Kd7x6rN+qCNRXEWse5zq2KsdXdZNLXSLMP/jSwq91aB1PB/KU4GOjRcZ0mBa CXa35jfqzRTQEtIkqV17ybeKJHwG64+DVLn32YfuDsyeR1tCNTJFY/FoeL5MWW06hDf9 AzGxkeu2RAsPPkL4oGxoaGJaKDOINF1V9ks5yNuSP6Fq06lApjIglewP9/GWz4SC9mJQ Kh7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=KnEOtnoTdx7eZ/hzDt7drJXeHMys4JlG3l/HjRbSOWw=; b=PzCvwrNsom/3/xfdXAXCxfT/EIw4VaWf3+6b7OKfiuoSUafxAztv9R4bIW/CE4b7Lb r47iJhMXnvUkWcAM2L32pAgXgbJCidPmW3ynNy0jvXoUw9RBq+L3GrNO3AH95/duZXz4 DkayUyDF7/CH5h0eQ/Jj0B9TAW+eNruQN44e4jhQ0+poCcR4V2SRpJPubyGMLFP/HTJg ZES5uELIldj8aCcTNCYvYIuq/qdKTZxo/OAgwd5xw5iHBgIqf6Yry6aSwegxpZnGDquv iXDiUK8XkuBkKmIOxWl51VYQmdwoezesFluN4LF54oyamZJVq7Lxv1Gj7XfieOXfXwli gfqA== X-Gm-Message-State: AD7BkJKkztNFm+VpdFPZ86z1ZITE7K0UlkfHJrN5N3eFFCrou66tVQH4lgV9cR3TAGWIkw== X-Received: by 10.37.91.9 with SMTP id p9mr14589596ybb.81.1456921487579; Wed, 02 Mar 2016 04:24:47 -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 k186sm28318520ywf.14.2016.03.02.04.24.46 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 02 Mar 2016 04:24:47 -0800 (PST) Sender: Margaret Cullen From: Margaret Cullen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <39E5345B-04C4-4149-A1A6-F0F5F4988C16@gmail.com> Date: Wed, 2 Mar 2016 07:24:45 -0500 To: "mif@ietf.org List" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: Subject: [mif] New Charter Items X-BeenThere: mif@ietf.org 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, 02 Mar 2016 12:24:54 -0000 At the last IETF meeting, and later on the mailing list, we reached = consensus that we would use a two-step approach for the configuration of = explicit PVDs. RAs would be used to provide the information to do a = second-step look up, including the PVD name. Then a second step would = be used to look up further information about the PVD. The only proposal we currently have on the table for a second-step = look-up is a DNS look-up, and no one seems to proposing any other second = step, so I believe there are three things that we need to define in = order for this to work: - An NTP server option for RAs, so that DNSSEC can be used for the = lookup. - A PVD Name option for RAs, so that we can tell hosts what PVD to look = up. - What PVD information can be stored in the DNS and how it will be = retrieved. Those things would need to be added to our charter, so that we can = accept corresponding work items. Does anyone have any objection to adding these three things to the MIF = charter? If not, the chairs and the AD will put together a propos From nobody Wed Mar 2 04:48:08 2016 Return-Path: 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 ; 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 ; 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 ; Wed, 2 Mar 2016 04:48:05 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id u200so175398538ywf.0 for ; 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 In-Reply-To: <56D44703.7050700@fer.hr> Date: Wed, 2 Mar 2016 07:48:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <256A8C0C-EEED-4AF4-8B59-DD8109AB1519@gmail.com> References: <56D44703.7050700@fer.hr> To: =?windows-1252?Q?Stjepan_Gro=9A?= X-Mailer: Apple Mail (2.1510) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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=9A wrote: > Hi all! >=20 > On 29.02.2016 11:21, Hui Deng wrote: >> Hello all >>=20 >> We had the concensus already about droping DHCP MPVD ID document,=20 >> 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)=20 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. >=20 > Since I didn't saw any discussions on this list about those proposals = I have few questions/comments: >=20 > 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=85 What would you use propose that we use instead? Margaret From nobody Wed Mar 2 04:50:12 2016 Return-Path: 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 ; 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 ; 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 ; Wed, 2 Mar 2016 04:50:08 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id u200so175437852ywf.0 for ; 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 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Margaret Cullen In-Reply-To: <56D44703.7050700@fer.hr> Date: Wed, 2 Mar 2016 07:50:06 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56D44703.7050700@fer.hr> To: =?windows-1252?Q?Stjepan_Gro=9A?= X-Mailer: Apple Mail (2.1510) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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=9A wrote: > Hi all! >=20 > On 29.02.2016 11:21, Hui Deng wrote: >> Hello all >>=20 >> We had the concensus already about droping DHCP MPVD ID document,=20 >> 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)=20 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. >=20 > Since I didn't saw any discussions on this list about those proposals = I have few questions/comments: >=20 > 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=85 What would you use propose that we use instead? Margaret From nobody Wed Mar 2 04:55:12 2016 Return-Path: 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 D03BB1A00A1 for ; Wed, 2 Mar 2016 04:55:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 XPQPHoTaHEWv for ; Wed, 2 Mar 2016 04:55:10 -0800 (PST) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 494B11A03D5 for ; Wed, 2 Mar 2016 04:54:50 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id u200so175528707ywf.0 for ; Wed, 02 Mar 2016 04:54:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=UtvIhvoeCsfI+Rp4mwQHedGaH+VrgGv2SSkAN+hl5c8=; b=zDo+nckzDyTVpz4mxQ1jfqbWjkgnbVw7ujom9D+ceX9CFetPpyYn7je8V9ztk87DRe KZqR1PaAjmNFmdcIcLh0qjAD8Tk5vESIyYup4GqQMPYQiVI8rcdLFLI6KcgopH0dBd/Z i+1fIP10UcdMEXV0cHWK/VWzNWUTkUKyeNA7xZ0FepqN4y4TErmJRtJsknOKZ+wFiVcK tZ2Tt68f6KciKm3TIIcSHZ4yu5Ae21B1XMN9MIYH7QQPjdXd09rsAEFRaZE/0yLKdEyD OMKNhLSc5Q9dM8Y9ZWDw8K+sQHMVxJQvRw/vRrq5RCsujO8rqS/kYtAG7gXRH9j7UU8t GW0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=UtvIhvoeCsfI+Rp4mwQHedGaH+VrgGv2SSkAN+hl5c8=; b=gncraDHcdAv7iRdi4VDrr3eNsjj4B8Sdhh1CVdfxKP11v+HZ5bGWEXWohYCiD+YuOq Zd3a9QRgj9HbZUllz+TFKDk+Gdtt2ktgmpKThH3fELlvI4IXOEDZbRKJAaMl0P/Gk63T 8aJ3a9tuFjL4gh0ggnuquz9bFy+VKBhArSKRzYlIuM4dGPhplbqOxbUdgiA/YnpaH3K3 VgGSfBDjCX2zIATHbwYuVfBd1+rFmhsXaYvy29WyAu8iUaElBdRkTG1qaNkjoRq6Hnqj ilNY5HQ71WvxoQH6uw8hPtFdI3+w8nvUZvNnv/hwXWVWRsjkdMpCpyVme7F3qjGMsZoK P5VQ== X-Gm-Message-State: AD7BkJLyF8YcaYmD8mXsyKR+GTuewbtI1dhyPvkrG9Iv+M7AF6EzE+kLw8SWv7nWAORVTw== X-Received: by 10.13.203.1 with SMTP id n1mr2653533ywd.151.1456923289644; Wed, 02 Mar 2016 04:54:49 -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 w7sm16772660ywa.4.2016.03.02.04.54.48 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 02 Mar 2016 04:54:49 -0800 (PST) From: Margaret Cullen Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <63587CBE-793F-4329-B371-CB0B0BBDE25F@gmail.com> Date: Wed, 2 Mar 2016 07:54:48 -0500 To: "mif@ietf.org List" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: Subject: [mif] Apologies for Duplicates X-BeenThere: mif@ietf.org 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, 02 Mar 2016 12:55:11 -0000 I am sorry for the duplicate messages to the list. I thought my email = was not going through properly, but apparently it has was=85 Margaret From nobody Wed Mar 2 15:42:17 2016 Return-Path: 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 B5E181B3529 for ; Wed, 2 Mar 2016 15:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 Pr8b8Ao1JzM0 for ; Wed, 2 Mar 2016 15:42:13 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (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 D16231B3528 for ; Wed, 2 Mar 2016 15:42:13 -0800 (PST) Received: by mail-pa0-x229.google.com with SMTP id fy10so2891708pac.1 for ; Wed, 02 Mar 2016 15:42:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=TmqBPRdwN/PUkEGaT3cxwJ2YsGoxMdBVBsiW4Qnelh0=; b=icwrp7wmM2L8bakG9cer/p/9qpHOSdcY5UFLR1JIIRfzQgNuebttOrQyYQHuNnJi3z mB/8OSqwpya9es+G2LbCyjfmrzg69GUve48Y8lAPDaYhmO/wvL++VemccA2lPRNNP6bZ 3soRS43Q3Q9jFVN/dbzztx7Vw1j9NhM/znlRwPYjZ6uh1R4Zg6EshYT4uWT68LBIpwDV G7UIS7RpV23+Y8uBWzCER6G6CJAM8x+meCORIMEL1MFG1XfQfkndT8u1/UQrLpp1ORu3 fqaCFi9yCF+IfLSUMlKAcAZEHvQbCEnULvlQ4AUiq0iydevx4Qkkadqd8lO7qM/hGrAQ yiUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=TmqBPRdwN/PUkEGaT3cxwJ2YsGoxMdBVBsiW4Qnelh0=; b=VsyUKrLncqwa3w+1CxTiw3o8pp4PZuLQW4sRbvFVf9g7dbLCKx/pYUsHn6kcYQ5/8P gFCm48QVXGvwF7JnHk43xJLzfWZvYeuVFDUYcttqxdzohWfq/+4Fu6edhfGDm4aPd9O4 6xca1rNRJnlvMFmyw1N7wWmx44wwsbGYwo0wMOkkqq5bUC6tUtKU2dTZQaofoPUOj17z Ka0KTe2r3MCUO045OvYpS+oxZgrBixBDiqD9q40DnkMv9DYCnDHn39WvLiG4VhdlDLp/ 6GxB9aDS/NXSgo5jlyx2+GjWaPJQ43YlsjrliPiuH27iaX9jfCItiF/XCqs6lCX25DIb CEaw== X-Gm-Message-State: AD7BkJKmushL3eis9SgbE5wo6jz+OqBAtqrEyq8Y7jt3TXDN1r9GS++WvX4YOrN74KUTXw== X-Received: by 10.66.187.36 with SMTP id fp4mr42591870pac.47.1456962133454; Wed, 02 Mar 2016 15:42:13 -0800 (PST) Received: from [10.16.75.156] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id p9sm55468779pfa.11.2016.03.02.15.42.12 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Mar 2016 15:42:12 -0800 (PST) To: Margaret Cullen , "mif@ietf.org List" References: <39E5345B-04C4-4149-A1A6-F0F5F4988C16@gmail.com> From: Jouni Korhonen Message-ID: <56D77A54.60408@gmail.com> Date: Wed, 2 Mar 2016 15:42:12 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <39E5345B-04C4-4149-A1A6-F0F5F4988C16@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mif] New Charter Items X-BeenThere: mif@ietf.org 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, 02 Mar 2016 23:42:15 -0000 Got questions & observations here.. 3/2/2016, 4:24 AM, Margaret Cullen kirjoitti: > > At the last IETF meeting, and later on the mailing list, we reached consensus that we would use a two-step approach for the configuration of explicit PVDs. RAs would be used to provide the information to do a second-step look up, including the PVD name. Then a second step would be used to look up further information about the PVD. > > The only proposal we currently have on the table for a second-step look-up is a DNS look-up, and no one seems to proposing any other second step, so I believe there are three things that we need to define in order for this to work: > > - An NTP server option for RAs, so that DNSSEC can be used for the lookup. > - A PVD Name option for RAs, so that we can tell hosts what PVD to look up. I thought we already got a WG I-D that is able to carry required name information if needed - maybe not in the "format" at the moment folks want it to be but it is up to WG to steer the content, right? > - What PVD information can be stored in the DNS and how it will be retrieved. While DNS is a good thing and actually a good idea in the context we are discussing here, few things to think in addition to those already found in the meeting minutes: does not quite work if DNS is not there and going to DNS all time even for the simplies form of PVD configuration seems a bit unefficient. These are not really concern of homenet type setups but maybe for other deployments where links come and go. My 0.02ZWD, Jouni > > Those things would need to be added to our charter, so that we can accept corresponding work items. > > Does anyone have any objection to adding these three things to the MIF charter? If not, the chairs and the AD will put together a propos > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From nobody Wed Mar 2 15:51:58 2016 Return-Path: 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 734D51B355F for ; Wed, 2 Mar 2016 15:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 2zdGM3eeNUCU for ; Wed, 2 Mar 2016 15:51:55 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEDFD1B355E for ; Wed, 2 Mar 2016 15:51:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2468; q=dns/txt; s=iport; t=1456962715; x=1458172315; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5BHCn6uS9S7c+E8n/1/qdhcyqSong1qNn/4jVi0Slq4=; b=evRB2klXPNx4u1qoBXqCrVMjGlqAjbLphdoealnmsP1HslzPKlmj39Of LbiS3n2OFJGSD07opw5pW/u4Lkv8xbh7IX0L9xA81SE4RDb7krU8ejU0E v+/HUf0lYESSsugIJRPy4qrf7PVitVPxpBLBvd+VkNN3oFMysLJZ6D4jj w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D8AQBlfNdW/5ldJa1egzpSbagDkiMBD?= =?us-ascii?q?YFnFwqFbgKBPzgUAQEBAQEBAWQnhEEBAQEDAQEBATc0CwULAgEIGB4QIQYLJQI?= =?us-ascii?q?EDgWIDAMKCA63TA2ENQEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhhKBbIJOgjqBY?= =?us-ascii?q?xaDLYEPBY0siWYBiEiDJoF0jnaHCIdDAR4BAUKDZGqIYAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,531,1449532800"; d="scan'208";a="243428026" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Mar 2016 23:51:55 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u22NpsdG021280 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Mar 2016 23:51:55 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 2 Mar 2016 17:51:54 -0600 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.009; Wed, 2 Mar 2016 17:51:53 -0600 From: "Sri Gundavelli (sgundave)" To: Jouni Korhonen Thread-Topic: [mif] New Charter Items Thread-Index: AQHRdH6KMsB4v/QegEWXN3aRhswPTZ9HNeEA//+eIFc= Date: Wed, 2 Mar 2016 23:51:53 +0000 Message-ID: <3B16CA0F-EA15-4CBD-93FA-DCFD65FE7204@cisco.com> References: <39E5345B-04C4-4149-A1A6-F0F5F4988C16@gmail.com>, <56D77A54.60408@gmail.com> In-Reply-To: <56D77A54.60408@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "mif@ietf.org List" , Margaret Cullen Subject: Re: [mif] New Charter Items X-BeenThere: mif@ietf.org 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, 02 Mar 2016 23:51:57 -0000 +1 I missed the last meeting and looks like I missed this discussion and the c= onclusions around this new approach. Sent from my iPad > On Mar 3, 2016, at 5:12 AM, Jouni Korhonen wrote= : >=20 > Got questions & observations here.. >=20 > 3/2/2016, 4:24 AM, Margaret Cullen kirjoitti: >>=20 >> At the last IETF meeting, and later on the mailing list, we reached cons= ensus that we would use a two-step approach for the configuration of explic= it PVDs. RAs would be used to provide the information to do a second-step = look up, including the PVD name. Then a second step would be used to look = up further information about the PVD. >>=20 >> The only proposal we currently have on the table for a second-step look-= up is a DNS look-up, and no one seems to proposing any other second step, s= o I believe there are three things that we need to define in order for this= to work: >>=20 >> - An NTP server option for RAs, so that DNSSEC can be used for the looku= p. >> - A PVD Name option for RAs, so that we can tell hosts what PVD to look = up. >=20 > I thought we already got a WG I-D that is able to carry required name inf= ormation if needed - maybe not in the "format" at the moment folks want it = to be but it is up to WG to steer the content, right? >=20 >> - What PVD information can be stored in the DNS and how it will be retri= eved. >=20 > While DNS is a good thing and actually a good idea in the context we are = discussing here, few things to think in addition to those already found in = the meeting minutes: does not quite work if DNS is not there and going to D= NS all time even for the simplies form of PVD configuration seems a bit une= fficient. These are not really concern of homenet type setups but maybe for= other deployments where links come and go. >=20 > My 0.02ZWD, > Jouni >=20 >=20 >=20 >>=20 >> Those things would need to be added to our charter, so that we can accep= t corresponding work items. >>=20 >> Does anyone have any objection to adding these three things to the MIF c= harter? If not, the chairs and the AD will put together a propos >>=20 >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >>=20 >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From nobody Thu Mar 3 03:47:24 2016 Return-Path: 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 2C02C1A90B7 for ; Thu, 3 Mar 2016 03:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] 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 GgxKZSd3X5dR for ; Thu, 3 Mar 2016 03:47:20 -0800 (PST) Received: from mail.zemris.fer.hr (gandalf.zemris.fer.hr [161.53.65.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7991A8F48 for ; Thu, 3 Mar 2016 03:47:19 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.zemris.fer.hr (Postfix) with ESMTP id AC4583B7C072; Thu, 3 Mar 2016 12:47:18 +0100 (CET) X-Virus-Scanned: amavisd-new at zemris.fer.hr Received: from mail.zemris.fer.hr ([127.0.0.1]) by localhost (mail.zemris.fer.hr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hozuvsHP1-zF; Thu, 3 Mar 2016 12:47:09 +0100 (CET) Received: from w540.sistemnet.local (Enel.zemris.fer.hr [161.53.65.34]) by mail.zemris.fer.hr (Postfix) with ESMTPSA id 1AC7F3B7C06C; Thu, 3 Mar 2016 12:47:09 +0100 (CET) References: <56D44703.7050700@fer.hr> <256A8C0C-EEED-4AF4-8B59-DD8109AB1519@gmail.com> To: Margaret Cullen From: =?UTF-8?Q?Stjepan_Gro=c5=a1?= Organization: UNIZG - FER Message-ID: <56D82434.5020803@fer.hr> Date: Thu, 3 Mar 2016 12:47:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <256A8C0C-EEED-4AF4-8B59-DD8109AB1519@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0aLb4298CXN1785bWgFKEgnAWx8MfX6x3" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 11:47:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0aLb4298CXN1785bWgFKEgnAWx8MfX6x3 Content-Type: multipart/alternative; boundary="------------090004000706000405090505" This is a multi-part message in MIME format. --------------090004000706000405090505 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Margaret, Thank you for the clarification/answer. I read the documents you were referring to and here are my comments. On 02.03.2016 13:48, Margaret Cullen wrote: > Hi Stepjan, > > On Feb 29, 2016, at 8:26 AM, Stjepan Gro=9A 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,=20 >>> 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 app= roach, although it did not use that terminology -- in the minutes from Yo= kohama, it has been previous referred to as an "offline mechanism". It w= as 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 sh= ould use RAs to identify an explicit PVD, and that we should use an offli= ne 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)=20 > > There is currently one proposal for an offline mechanism, the MPVD DNS = proposal (draft-stenberg-mif-mpvd-dns). It was also presented in Yokoham= a. There seemed to be general agreement in the room that a DNS approach = would be workable, but there were concerns raised about the specific prop= osal in this document (use of TXT records, etc.). In the given draft two use cases are mixed into one. The first one is for the discovery of services available. It is a valid use case for a DNS (side question, can DNS-SD already do what this draft describes, could SDP be (re)used?). The other one is the configuration data that the client should use to configure itself, this is IMHO not a valid use case for DNS service. The additional reason why not is that, for example, RA allows asynchronous notification about changes in the network parameters, while DNS doesn't. This mixes TTL into the equation. TTL values in RA are relatively large, larger that in DNS. I suspect that there could be some tricky issues too. As a side note, when we talk about QoS characteristics of discovered services, the draft offers one possible approach. But it is an interesting question would this be enough. IMHO, for some it would, for others it won't. For example, draft anticipates user visible PvD name but this doesn't mean a lot. Maybe some service provider wants to provide more elaborate description or something else. Also, there is a problem of a composition of different access methods. If both say they are fast, it might easily be that they aren't identical but due to the shortcomings of the description "language" they can not be differentiated. And if you include security into the mix, things start to complicate quickly. Anyway, one possible solution would be to provide URL that might be used to fetch description of a service/PvD which can be in different forms (depending on one's particular needs) and thus more likely to satisfy (almost) everyone. Also, this URL based access might be a better in case you want to do a per-user configuration because in the higher layers you have user's identity on your disposal which might not be available to DNS server and/or resolver code. And while we are at access control, DNS servers usually serve all data from their databases to any client that asks them. If you introduce local network specific information into DNS, how would you restrict access to this data? Of course, it can be solved, almost everything can, but needles to say, it complicates things. Finally, obviously this solution assumes a single DNS server from one ISP will provide all the data about PvDs. If you have two or more ISPs and expect them to be collaborative is nice thing to hope for, but in case they don't user is stuck. And even if they collaborate, that neither scales nor is responsive. > > At this point we are trying to see if we can recharter the group to wor= k 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-s= tep 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 PV= D ID, but the IPR on using DHCP for this makes that somewhat challenging.= IMHO, having only PVD ID in DHCP is _much_ closer to what IPR claim is about than to have all the configuration data. But, isn't this something that DHC WG should discuss and decide? Actually, DHC WG should also solve a problem of two or more _concurrent_ DHCP servers on a local network. And by solving that use case, it might also get around IPR claim (if its an issue at all). > >> 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. Maybe I'm missing something, but IMHO not much is necessary in terms of options when we talk about PvDs: one option, PvD CO (which can be PvD ID in the same time) and that's it. Of course, distinction has to be kept between node configuration (for which RA is used) and service discovery (for which RA isn't appropriate and which might explode number of necessary options). Note that there is also possibility to use RS to explicitly ask for PvDs (specific one or all available), i.e. they aren't sent in "regular" RAs. I don't know if this was explored, but in NDP draft it isn't mentioned. As for the missing information to make DNSSEC to work, I suppose that's something that's not the problem this WG should solve. > 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. There is already a second step for RA, it is DHCP and it is already implemented and works for years now. Not to mention that into already complex mix of configuration mechanisms (from operational perspective) additional one is introduced which has a host of its own problems (security issues, and slow adoption of DNSSEC). And while I'm talking about OP perspective, there are host of other configuration protocols already (RADIUS, DIAMETER, PPP, VPN specific ones). Is it really necessary to introduce yet another one into the mix? > >> 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=85 What would you use propose that we use instead? SRV as I said, is for service discovery, not node configuration. So its not good analogy. The same goes for DNS-SD, which is also for service discovery as the name implies. DHCP was designed to do a local network configuration and I think that DHC WG should be asked to solve the IPR problem. There are already some options that might invalidate, or at least work around IPR claim, like DHCPv4-over-DHCPv6 which encapsulates all configuration parameters within a single option, different domain names (NIS, KRB), etc. In the end, let mi conclude that I somehow suspect that my opinion will change anything, but I'm nevertheless strongly opposed to the direction WG is taking. SG P.S. I tried to ask on NetworkManager list for their opinion about all this, but unfortunately received no answer. That would be very valuable input. > > Margaret > > --------------090004000706000405090505 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Margaret,

Thank you for the clarification/answer. I read the documents you were referring to and here are my comments.

On 02.03.2016 13:48, Margaret Cullen wrote:
Hi Stepjan,

On Feb 29, 2016, at 8:26 AM, Stjepan Gro=9A <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,=20
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 regardin=
g this two-step approach, although it did not use that terminology -- in =
the minutes from Yokohama, it has been previous referred to as an "offlin=
e mechanism".  It was discussed in the minutes from Yokohama which were p=
osted 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)=20

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

In the given draft two use cases are mixed into one. The first one is for the discovery of services available. It is a valid use case for a DNS (side question, can DNS-SD already do what this draft describes, could SDP be (re)used?). The other one is the configuration data that the client should use to configure itself, this is IMHO not a valid use case for DNS service. The additional reason why not is that, for example, RA allows asynchronous notification about changes in the network parameters, while DNS doesn't. This mixes TTL into the equation. TTL values in RA are relatively large, larger that in DNS. I suspect that there could be some tricky issues too.

As a side note, when we talk about QoS characteristics of discovered services, the draft offers one possible approach. But it is an interesting question would this be enough. IMHO, for some it would, for others it won't. For example, draft anticipates user visible PvD name but this doesn't mean a lot. Maybe some service provider wants to provide more elaborate description or something else. Also, there is a problem of a composition of different access methods. If both say they are fast, it might easily be that they aren't identical but due to the shortcomings of the description "language" they can not be differentiated. And if you include security into the mix, things start to complicate quickly. Anyway, one possible solution would be to provide URL that might be used to fetch description of a service/PvD which can be in different forms (depending on one's particular needs) and thus more likely to satisfy (almost) everyone. Also, this URL based access might be a better in case you want to do a per-user configuration because in the higher layers you have user's identity on your disposal which might not be available to DNS server and/or resolver code.

And while we are at access control, DNS servers usually serve all data from their databases to any client that asks them. If you introduce local network specific information into DNS, how would you restrict access to this data? Of course, it can be solved, almost everything can, but needles to say, it complicates things.

Finally, obviously this solution assumes a single DNS server from one ISP will provide all the data about PvDs. If you have two or more ISPs and expect them to be collaborative is nice thing to hope for, but in case they don't user is stuck. And even if they collaborate, that neither scales nor is responsive.


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 t=
he offline mechanism for further PVD configuration.  That is the "two-ste=
p approach" that is being referred to here.


Since I didn't saw any discussions on this list ab=
out 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 ge=
t 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 so=
mewhat challenging.

IMHO, having only PVD ID in DHCP is _much_ closer to what IPR claim is about than to have all the configuration data.

But, isn't this something that DHC WG should discuss and decide?

Actually, DHC WG should also solve a problem of two or more _concurrent_ DHCP servers on a local network. And by solving that use case, it might also get around IPR claim (if its an issue at all).


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

There has been a great deal of concern expressed abo=
ut 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.

Maybe I'm missing something, but IMHO not much is necessary in terms of options when we talk about PvDs: one option, PvD CO (which can be PvD ID in the same time) and that's it. Of course, distinction has to be kept between node configuration (for which RA is used) and service discovery (for which RA isn't appropriate and which might explode number of necessary options).

Note that there is also possibility to use RS to explicitly ask for PvDs (specific one or all available), i.e. they aren't sent in "regular" RAs. I don't know if this was explored, but in NDP draft it isn't mentioned.

As for the missing information to make DNSSEC to work, I suppose that's something that's not the problem this WG should solve.

There was consensus in the room that it would be bet=
ter to get the PVD ID from an RA and use a second step to look up the ful=
l PVD configuration information.  the only current proposal for that seco=
nd step is to do it via DNS.

There is already a second step for RA, it is DHCP and it is already implemented and works for years now.

Not to mention that into already complex mix of configuration mechanisms (from operational perspective) additional one is introduced which has a host of its own problems (security issues, and slow adoption of DNSSEC).

And while I'm talking about OP perspective, there are host of other configuration protocols already (RADIUS, DIAMETER, PPP, VPN specific ones). Is it really necessary to introduce yet another one into the mix?


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

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

SRV as I said, is for service discovery, not node configuration. So its not good analogy. The same goes for DNS-SD, which is also for service discovery as the name implies.

DHCP was designed to do a local network configuration and I think that DHC WG should be asked to solve the IPR problem. There are already some options that might invalidate, or at least work around IPR claim, like DHCPv4-over-DHCPv6 which encapsulates all configuration parameters within a single option, different domain names (NIS, KRB), etc.


In the end, let mi conclude that I somehow suspect that my opinion will change anything, but I'm nevertheless strongly opposed to the direction WG is taking.

SG

P.S. I tried to ask on NetworkManager list for their opinion about all this, but unfortunately received no answer.=A0 That would be very= valuable input.


Margaret


--------------090004000706000405090505-- --0aLb4298CXN1785bWgFKEgnAWx8MfX6x3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJW2CQ0AAoJEOggxEF22YTDjJAP/3OBUq93GEC2HjzhM9bRxc3v eRQU1TFM61VzVsXaTFAoAqwFAgUg7GQU7TJ+iDkEvAgf3H72Sh5KzLWOY7YrjVTs XMV64uSdNWfzAmmi4AsKLNVQ5IGs05aUhH8TypJLCtcLAuSyLhj99a5XasunsDCW k2QSkIK1UcQqTAERDkZ/oE5aIhDBNYJonuJAK7BCycVu81YwVxbze69cVBnbGiHR u+pNhtN/OV+eRjA0AzP8k9N4ayvRyOsR92uJwhUe+or+JVO2ZwALczmPNNGY2wb0 QeFtW9xgHAsrLfyAXtlMWTSUDAShP/wON19olZRKxrJXa/IcgzRBsEBFn0/jqNJj Q4Ukr9rO+duG08i83sIswoNiLVMWdiy5zobMU9MleLnJdI/WPRZvfmdsC+2j5gpz y8Tf9iE1FvCkY84jfatgTmAoyZmuycsQVyAvyPY8vW5z+kQt+qd4nX7FtAYnFOTt fCJjRWSSF8BZhwfTtbyuk50uKg60gPJ9c+gKe5HflxAxDkzhEUtlS4/vhxJVtZay 5j8p/d3I+hLcKdRTvUmwXBjsS0yH8SfoNQP+kSwigFCbi7XPYyyenZmc3OvRAcYK Ch0Hhu0iCOmYyKVhHNZH+OWnWpesGpTj0tfc1tZxcpg68uX/pDfbgS2jjJOkss6v kfD0OmvnqeZ2ZohSjQSU =6xmT -----END PGP SIGNATURE----- --0aLb4298CXN1785bWgFKEgnAWx8MfX6x3-- From nobody Fri Mar 4 04:48:19 2016 Return-Path: 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 1CE0B1B37D0 for ; Fri, 4 Mar 2016 04:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.252 X-Spam-Level: X-Spam-Status: No, score=-1.252 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 hpO-r-gZXnti for ; Fri, 4 Mar 2016 04:48:17 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F05C1B37EF for ; Fri, 4 Mar 2016 04:48:17 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D1B50A2; Fri, 4 Mar 2016 13:48:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1457095694; bh=fYFW71xD5L2dTjUXlkxKdQm2fxj5/gG5boJUzE9aZBY=; h=Date:From:To:Subject:In-Reply-To:References:From; b=FEzgtbZvqTGaF0+Y/x60SWRtF1i8/GU4N1QoA1DRtA+zF6lny9hzAmF6WmKNF9PEo zBZb6Fz/i6MJJ9+l3rFOEl7+0rdr22J5EMYgkHkPs1bJ8Il7qEkuw+jIRvSrPT//xN oUvb6+f0Dh68IuofF15T1LPfd83vIAVdoiv7NMMU= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CE1D9A1 for ; Fri, 4 Mar 2016 13:48:14 +0100 (CET) Date: Fri, 4 Mar 2016 13:48:14 +0100 (CET) From: Mikael Abrahamsson To: mif@ietf.org In-Reply-To: <56D82434.5020803@fer.hr> Message-ID: References: <56D44703.7050700@fer.hr> <256A8C0C-EEED-4AF4-8B59-DD8109AB1519@gmail.com> <56D82434.5020803@fer.hr> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-1602763439-1457095694=:31096" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 12:48:19 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-1602763439-1457095694=:31096 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 3 Mar 2016, Stjepan Groš wrote: > Finally, obviously this solution assumes a single DNS server from one > ISP will provide all the data about PvDs. If you have two or more ISPs > and expect them to be collaborative is nice thing to hope for, but in > case they don't user is stuck. And even if they collaborate, that > neither scales nor is responsive. I re-read draft-stenberg-mif-mpvd-dns-00 . It's not obvious to me if the PvD information is globally available for anyone to ask (or not), or if there is a requirement for some kind of split horizon DNS view where you need to ask from an address within the PvD to actually get an answer back regarding the PvD. I have doubts about the DNS method, and I would prefer to have some kind of other mechanism to distribute the PvD information. What about having one more level of indirection (yeah, yeah, I know, RFC 1915 6a), and instead find the configuration resource via some kind of SRV record either available via DNSSD or via PTR .arpa lookup, or via DHCP option? Then the information could be fetched using HTTPS or some other mechanism. draft-ietf-netconf-zerotouch-04 uses these kinds of mechanisms to provide data, where you instead sign the configuration data that can be downloaded through insecure means, but you won't use it until you've verified its authenticity (for instance by doing lookups using DNSSEC to get certificate ID or similar). I also would like to separate the mechanism(s) how the information is transmitted and what information we want to transmit. These discussions are very different, and the mechanism how to transmit the information is probably not going to be changed that much, whereas we might want to add information we want to transmit more frequently. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1602763439-1457095694=:31096-- From nobody Tue Mar 8 04:55:45 2016 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24BD12D6B2 for ; Tue, 8 Mar 2016 04:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axjbIs4Yx0UT for ; Tue, 8 Mar 2016 04:55:42 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D371112D69C for ; Tue, 8 Mar 2016 04:55:41 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u28CtdOv026425 for ; Tue, 8 Mar 2016 13:55:39 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C9E3320CC54 for ; Tue, 8 Mar 2016 13:56:06 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B628220CC31 for ; Tue, 8 Mar 2016 13:56:06 +0100 (CET) Received: from [132.166.84.81] ([132.166.84.81]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u28CtdpJ004043 for ; Tue, 8 Mar 2016 13:55:39 +0100 To: mif@ietf.org References: <39E5345B-04C4-4149-A1A6-F0F5F4988C16@gmail.com> From: Alexandre Petrescu Message-ID: <56DECBC9.7060800@gmail.com> Date: Tue, 8 Mar 2016 13:55:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <39E5345B-04C4-4149-A1A6-F0F5F4988C16@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [mif] New Charter Items - NTP in RA for DNSSEC X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 12:55:44 -0000 Le 02/03/2016 13:24, Margaret Cullen a écrit : > > At the last IETF meeting, and later on the mailing list, we reached consensus that we would use a two-step approach for the configuration of explicit PVDs. RAs would be used to provide the information to do a second-step look up, including the PVD name. Then a second step would be used to look up further information about the PVD. > > The only proposal we currently have on the table for a second-step look-up is a DNS look-up, and no one seems to proposing any other second step, so I believe there are three things that we need to define in order for this to work: > > - An NTP server option for RAs, so that DNSSEC can be used for the lookup. Sounds like a good idea. I guess DNSSEC operation needs the querier to have the right time otherwise it's insecure? Hence the need for NTP? I could find 2 earlier drafts on this, maybe there are others. draft-chen-ntps-ra-opt-00 draft-bcd-6man-ntp-server-ra-opt-00 If extending RA then it's good to use the RA "flags option" RFC5075. Alex > - A PVD Name option for RAs, so that we can tell hosts what PVD to look up. > - What PVD information can be stored in the DNS and how it will be retrieved. > > Those things would need to be added to our charter, so that we can accept corresponding work items. > > Does anyone have any objection to adding these three things to the MIF charter? If not, the chairs and the AD will put together a propos > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From nobody Sat Mar 12 15:49:31 2016 Return-Path: X-Original-To: mif@ietf.org Delivered-To: mif@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6CA12DDC6; Fri, 11 Mar 2016 15:05:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160311230528.15028.20686.idtracker@ietfa.amsl.com> Date: Fri, 11 Mar 2016 15:05:28 -0800 Archived-At: X-Mailman-Approved-At: Sat, 12 Mar 2016 15:49:30 -0800 Cc: mif@ietf.org Subject: [mif] mif - Requested session has been scheduled for IETF 95 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 23:05:29 -0000 Dear DENG Hui, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. mif Session 1 (2:00:00) Thursday, Afternoon Session III 1730-1930 Room Name: Buen Ayre B size: 125 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Multiple Interfaces Area Name: Internet Area Session Requester: DENG Hui Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: 6man dhc dmm dnsop dnssd homenet intarea mptcp netext opsarea opsawg pcp softwire v6ops Second Priority: lwig sunset4 Special Requests: --------------------------------------------------------- From nobody Sat Mar 12 16:06:20 2016 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA8712D8E1 for ; Sat, 12 Mar 2016 16:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ROGDaf-Px7ZQ for ; Sat, 12 Mar 2016 16:06:17 -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 C1F5912D8B1 for ; Sat, 12 Mar 2016 16:06:17 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id d65so130322699ywb.0 for ; Sat, 12 Mar 2016 16:06:17 -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:message-id:references :to; bh=WYY46lN+rCgXPv2zGdmbw3cK18siUo1ddSmLoG4Czrw=; b=WVw1Au+u66H74XGrI+rUHxd3sBlaF+NDpA+0QQy58YLz8ZhGUgMGiHCSrN2GZMMIfB UAeGgfV0HzQhVUuq9UX3nsBnK0W0KPDj5QUkL4avqjrsGNuOqq4sNOJTaEBtfWwkWZcp 0hf+9fcMfApJqNSCUWHIMPNOdx/cCIIp5+39kcqoiWtyU4JF5df1IH/IbjS86IqNwhG5 4jLTA0sKvxbxRtF36GZ+XuIrjiTCXR1ynq3BMe9FZgmXXiUzoOmrvgw6GSz/6DEdCFYY TuWQ5l5MOh7MGnlhnLwtGPG9rBAcfXwvHt5YDRf/ZtmvaRqlK3xryK9jxf8wlPZhsc5U 0smw== 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 :message-id:references:to; bh=WYY46lN+rCgXPv2zGdmbw3cK18siUo1ddSmLoG4Czrw=; b=C3B9NuS/O7MqjUsP1ymofJheFvFtWf0IDAvFygP7KC9N22AQh2M9kij0gA1o6ZqBSw 70n3IBZ38CYCLulCkWp67yI1dI+9i8kgPKgCTco989MSX7yzAPOCKk1mmYo3Mgnjv2Bz /4JBdK+FrRtHofc4zRJKQFhCz9Eq4PUdZq9fu7yr9KoAL42t47dYK+9sWA+AS+JBCn4Q W25rNwC8GGksw71TYVNv6Rr74ZJPiOAuAAj9TJkAqNHI0nkN4rLOh5ocAEKxg4ijznEa XchTWZ+p1k/3qFA5oK2t79RHkGH6gYg5zb+XXlYaFT/LSJAsoM2g7neeMk2WqFCUXyFk 4veQ== X-Gm-Message-State: AD7BkJLrOZcznFlAXbuGESn0LbPCpNrgLdv+3DKQG2YXCvzb2QJXs70muY7n0uKVH4GeRA== X-Received: by 10.129.83.196 with SMTP id h187mr8504017ywb.319.1457827577093; Sat, 12 Mar 2016 16:06:17 -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 p189sm9451109ywc.44.2016.03.12.16.06.15 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 Mar 2016 16:06:16 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_7DF7E4D7-795D-4A2D-B42B-0FACEC221318"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Margaret Cullen In-Reply-To: <56DECBC9.7060800@gmail.com> Date: Sat, 12 Mar 2016 19:06:15 -0500 Message-Id: <9B436C85-C05B-430A-915E-C332604DAA7E@gmail.com> References: <39E5345B-04C4-4149-A1A6-F0F5F4988C16@gmail.com> <56DECBC9.7060800@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.1510) Archived-At: Cc: mif@ietf.org Subject: Re: [mif] New Charter Items - NTP in RA for DNSSEC X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 00:06:19 -0000 --Apple-Mail=_7DF7E4D7-795D-4A2D-B42B-0FACEC221318 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Mar 8, 2016, at 7:55 AM, Alexandre Petrescu = wrote: >> - An NTP server option for RAs, so that DNSSEC can be used for the = lookup. >=20 > Sounds like a good idea. >=20 > I guess DNSSEC operation needs the querier to have the right time = otherwise it's insecure? Hence the need for NTP? As I understand it, DNSSEC needs the right time, otherwise it doesn't = work. >=20 > I could find 2 earlier drafts on this, maybe there are others. > draft-chen-ntps-ra-opt-00 > draft-bcd-6man-ntp-server-ra-opt-00 >=20 > If extending RA then it's good to use the RA "flags option" RFC5075. I don't think we'd probably do an NTP RA option in the MIF WG. I = suspect it would make more sense to do it in 6man -- we'd have to = discuss it with them and see if they agree. Margaret --Apple-Mail=_7DF7E4D7-795D-4A2D-B42B-0FACEC221318 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJW5K74AAoJEJrxOXzI3ic/H2MH/RGKh0seGjNOR1CQQnkHfVCn 4k7NxH5KeFwk4tqY1VhrtMlADGKRyr/u2RdizKbolf9UfDjhiQYG5SJqNKsql24b fPCt9AzhEbJLcQw/imaHhk6/GMxQUnqRSYCM8dnqlujeQWmKRuKTzOMV3KOYr3de GRzxpi6meTz4g641NJozRxfLa0EY49qQ56G9utMXfmvw0atr/6WqgG51olOaIlw2 tHXygOpF+Dq04sI4eeLv0z0UAm8KkxVj1GNtodQmgFXg/08VUfHwGV3BNd4S4Aab m2in7ZAmu9+1kdpflW/xf+Whj50J0htrj1Yks/yHSPOBhcGE0trMarlTSL0rh58= =pdvA -----END PGP SIGNATURE----- --Apple-Mail=_7DF7E4D7-795D-4A2D-B42B-0FACEC221318-- From nobody Sat Mar 12 16:10:06 2016 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC97412D677 for ; Sat, 12 Mar 2016 16:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ouvuRWidu8sM for ; Sat, 12 Mar 2016 16:10:03 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 9C11412D59C for ; Sat, 12 Mar 2016 16:10:02 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id d65so130371050ywb.0 for ; Sat, 12 Mar 2016 16:10:02 -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:message-id:references :to; bh=G3BaD8BecF51+8Sa4ywjkQc7QU2S1Lh9UuMGXpsULm0=; b=edgiWTnNQQikCVDDjyP5br3eqrIwus3bBciWa0CFC7kOPjMV6Ct/CLgEZGp+/x3Mtt QQ8l/jf2nyiQt2vLmekXbFnFNktTbgO0wEAW9CVOnRsDRtFCV0OMlh1X0eXeElIRVCtJ rkbM3BCOa8KHyYbaSezOwvO4HqtgOWZK5FldKCZkwSAr7IqJ2ckXIkdixC9OfFTy2FKO BLFEOdAD/BQ3D6ZKWWnsU/eFagJYMnFKKbN2CqiT9QEckoOdv3POLmvBbdmo8MCyElmd xVSqg+gs7zXF41gNtDXQkseLNkhacuupupy+NV0r493iTCxHoLcT7qoWzwUGLnF3eeqe CHkg== 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 :message-id:references:to; bh=G3BaD8BecF51+8Sa4ywjkQc7QU2S1Lh9UuMGXpsULm0=; b=QK6YVnxn9IVm2/STI9AWdEowYepzyJoMTslejuXBPg74A8fB+e5BjEXJ/7wl7uJA0P 0qMaWdlkHP+VVd0pktnNLG0YwoYpg3Pj4/KJEv4q72U8YUldhU0AZTQwd4XG5BF6vqZE 8QyRwz9itmPwB8uvxeNdEssDvtvp+DvfkKteR5v4oNgxKYCYMePUWHpwpEqNZxKsMIDh P/7uQNlTYPzZsxADX7m57S/7ktdiIbTI8jPl/tavuDpRvXXlnBLN4HLIt1Zw3fDJ8ysD /Q/LIk47mV5ia2oVCNoCLgJOhhocNfxPf26PslDSPXrqSZYxfQiIdKDzFTNXOfkQpv7B eDUg== X-Gm-Message-State: AD7BkJIjakrckCWodvGTuSwXIMlJ580lG5IoANHF4VEhyoPuAJMjpzF67OGUfbl1/6qWvw== X-Received: by 10.37.2.211 with SMTP id 202mr9192159ybc.15.1457827801695; Sat, 12 Mar 2016 16:10:01 -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 e4sm9882657ywb.0.2016.03.12.16.10.00 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 Mar 2016 16:10:01 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_6DF0E16E-8E20-49E5-9BFF-B4F62348E5C7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Margaret Cullen In-Reply-To: Date: Sat, 12 Mar 2016 19:10:00 -0500 Message-Id: References: <56D44703.7050700@fer.hr> <256A8C0C-EEED-4AF4-8B59-DD8109AB1519@gmail.com> <56D82434.5020803@fer.hr> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1510) Archived-At: Cc: mif@ietf.org Subject: Re: [mif] next step for MIF PVD configuration X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 00:10:04 -0000 --Apple-Mail=_6DF0E16E-8E20-49E5-9BFF-B4F62348E5C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Mikael, I agree with some of the issues you have raised about the current draft = for DNS lookups of PVD information. I think that if we go with a = DNS-based approach, we will need to do some work on the DNS mechanism to = fix these sorts of issues. Do you have time to write a draft for the mechanism you have suggested, = so that we can discuss it in the group? Margaret On Mar 4, 2016, at 7:48 AM, Mikael Abrahamsson wrote: > On Thu, 3 Mar 2016, Stjepan Gro=9A wrote: >=20 >> Finally, obviously this solution assumes a single DNS server from one = ISP will provide all the data about PvDs. If you have two or more ISPs = and expect them to be collaborative is nice thing to hope for, but in = case they don't user is stuck. And even if they collaborate, that = neither scales nor is responsive. >=20 > I re-read draft-stenberg-mif-mpvd-dns-00 . It's not obvious to me if = the PvD information is globally available for anyone to ask (or not), or = if there is a requirement for some kind of split horizon DNS view where = you need to ask from an address within the PvD to actually get an answer = back regarding the PvD. >=20 > I have doubts about the DNS method, and I would prefer to have some = kind of other mechanism to distribute the PvD information. >=20 > What about having one more level of indirection (yeah, yeah, I know, = RFC 1915 6a), and instead find the configuration resource via some kind = of SRV record either available via DNSSD or via PTR .arpa lookup, or via = DHCP option? Then the information could be fetched using HTTPS or some = other mechanism. >=20 > draft-ietf-netconf-zerotouch-04 uses these kinds of mechanisms to = provide data, where you instead sign the configuration data that can be = downloaded through insecure means, but you won't use it until you've = verified its authenticity (for instance by doing lookups using DNSSEC to = get certificate ID or similar). >=20 > I also would like to separate the mechanism(s) how the information is = transmitted and what information we want to transmit. These discussions = are very different, and the mechanism how to transmit the information is = probably not going to be changed that much, whereas we might want to add = information we want to transmit more frequently. >=20 > -- > Mikael Abrahamsson email: = swmike@swm.pp.se_______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif --Apple-Mail=_6DF0E16E-8E20-49E5-9BFF-B4F62348E5C7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJW5K/YAAoJEJrxOXzI3ic/lJkIAIAqK14tlrQXoew7pp5xoZNk kzuO9roOEPhvPkHd+jTmTSDK0ZvOxmbdSCUmNdcBhBu4FBAtZgaHL+TmoS4Q37+r 5LdYliQqlDHIDeQzwRcn71dCdCiIUYrSVrUASxJL25TS9JGx6rOVBa6WFj3G/3ly t7dztG42TMDuSGU+P8T1XDYJ7nCs+4Bv0xHDX9XVvJwcYc5DZZazYNQ1K/YRsAl2 a7b1wTD8ePijuxSvb7n7+jPUycx+Y4mrYMfbjEO0DxuOjr7aiT5CG/1z/21bWPzW 1SzSYZHwQSIQXkp2Wl56LQ6iYiAw75RhwgSncr2CoNbXexFDTuAeRc76h7BgRHk= =3y+M -----END PGP SIGNATURE----- --Apple-Mail=_6DF0E16E-8E20-49E5-9BFF-B4F62348E5C7-- From nobody Sat Mar 12 16:23:48 2016 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5589712D5D7 for ; Sat, 12 Mar 2016 16:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 5DQt6jAm28Ez for ; Sat, 12 Mar 2016 16:23:44 -0800 (PST) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 E934612D59C for ; Sat, 12 Mar 2016 16:14:21 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id g127so130345727ywf.2 for ; Sat, 12 Mar 2016 16:14:21 -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=i3aGoioKgwrbCRV65T3baoU8IJcKzs8WIIPMUfi8rp8=; b=wxAY9/qy5NyzGFV/BQx5DWvvYp6xIAoA5nUUzY6L4Waa533uH7XdtbWVCx/WDovTK8 SsotaUmrjp89VrquK5MIu4e6iIMhm7LA52AZU1xdbbWNODSP7bLV7yG4cNlpW4hdMauW JXtxIAw1bsorVzIN7yURy1rtqPhg1UESRZ+epDZ7Hyqt/YNhAPv950FfUjbYQlo0aIc1 rNRCpS+qi9oZe7Zw8hYl8nZkYsO50foyDINcdiRSQygbo0pPzsZW6ZtwlwwglO3KLvHg bKnjfAcZIx1EhzsleZIAO3NjnPc4tk9co5d9E/o5KtlX5esxF6oAK0lRU0SR+4fA0q2Z szqA== 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=i3aGoioKgwrbCRV65T3baoU8IJcKzs8WIIPMUfi8rp8=; b=PJetlQHmZkbDO5U65f76nBThdF8von0UwKQdNmZrxym8oL4zDkW7jcK7NnAeGIoZPZ aGyKdvKudqk7Mz7SCsFYu9RcUF8IrgaP49hXQvlammh2J8K9C/steGtKovouRQZ3IwUh rMKpGdM6Ot/wRpv8hVG6NaTFLpAUoHj5cdoulmbyFTSfz+xn/RSyXfQnLOeOygmGBoaq d0vri4cufn9C/Gr+A0za+zlYu/4ZRqDzLH5XXrIO4sO90J4FDVDh1g12cBusH1G1Cxsj coSwRUBjs3wZvhhydeQTzM5SEgF5XGy+RN7n0fRzlNq6AhCR3hmc8yAyLzWP+EBFYnPB popg== X-Gm-Message-State: AD7BkJK9jp/mPuDA9NJxLd+WcQciO/4n1Q7lyf0kM9ollvDo6u2PHir8Hhg1g4pMyFLSHw== X-Received: by 10.37.27.8 with SMTP id b8mr7842948ybb.17.1457828061210; Sat, 12 Mar 2016 16:14:21 -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 p63sm9876152ywf.8.2016.03.12.16.14.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 12 Mar 2016 16:14:19 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Margaret Wasserman In-Reply-To: <56D77A54.60408@gmail.com> Date: Sat, 12 Mar 2016 19:14:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <565C10F2-D3E1-49C5-8D2C-A92441A33A99@gmail.com> References: <39E5345B-04C4-4149-A1A6-F0F5F4988C16@gmail.com> <56D77A54.60408@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1510) Archived-At: Cc: "mif@ietf.org List" Subject: Re: [mif] New Charter Items X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 00:23:45 -0000 On Mar 2, 2016, at 6:42 PM, Jouni Korhonen = wrote: >>=20 >> - An NTP server option for RAs, so that DNSSEC can be used for the = lookup. >> - A PVD Name option for RAs, so that we can tell hosts what PVD to = look up. >=20 > I thought we already got a WG I-D that is able to carry required name = information if needed - maybe not in the "format" at the moment folks = want it to be but it is up to WG to steer the content, right? Right. >=20 >> - What PVD information can be stored in the DNS and how it will be = retrieved. >=20 > While DNS is a good thing and actually a good idea in the context we = are discussing here, few things to think in addition to those already = found in the meeting minutes: does not quite work if DNS is not there = and going to DNS all time even for the simplies form of PVD = configuration seems a bit unefficient. These are not really concern of = homenet type setups but maybe for other deployments where links come and = go. This mechanism would not be used for implicit PVDs (which I think have = at least 80% of the benefit of explicit ones), only for explicit PVDs, = and perhaps only for explicit PVDs that have a flag set saying that = hosts should seek more information (?). Presumably, if a host could not = reach the DNS to find additional information about an explicit PVD, it = would treat the PVD like an implicit one. =20 I think it is a question for any two-step method, what to do if the = first step configures and explicit PVD, but the second step can't be = completed and/or returns an error? Margaret From nobody Sun Mar 13 01:26:36 2016 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F7C12D535 for ; Sun, 13 Mar 2016 01:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=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 uwe0vN7rQQpF for ; Sun, 13 Mar 2016 01:26:30 -0800 (PST) Received: from johanna2.inet.fi (mta-out1.inet.fi [62.71.2.195]) by ietfa.amsl.com (Postfix) with ESMTP id 27A1312D541 for ; Sun, 13 Mar 2016 01:26:30 -0800 (PST) RazorGate-KAS: Status: not_detected RazorGate-KAS: Rate: 0 RazorGate-KAS: Envelope from: RazorGate-KAS: Version: 5.5.3 RazorGate-KAS: LuaCore: 80 2014-11-10_18-01-23 260f8afb9361da3c7edfd3a8e3a4ca908191ad29 RazorGate-KAS: Lua profiles 69136 [Nov 12 2014] RazorGate-KAS: Method: none Received: from poro.lan (80.220.86.47) by johanna2.inet.fi (9.0.002.03-2-gbe5d057) (authenticated as stenma-47) id 56E18B5B0035B64D; Sun, 13 Mar 2016 11:26:28 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Markus Stenberg In-Reply-To: <9B436C85-C05B-430A-915E-C332604DAA7E@gmail.com> Date: Sun, 13 Mar 2016 11:26:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <39E5345B-04C4-4149-A1A6-F0F5F4988C16@gmail.com> <56DECBC9.7060800@gmail.com> <9B436C85-C05B-430A-915E-C332604DAA7E@gmail.com> To: Margaret Cullen X-Mailer: Apple Mail (2.3112) Archived-At: Cc: mif@ietf.org Subject: Re: [mif] New Charter Items - NTP in RA for DNSSEC X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 09:26:33 -0000 On 13.3.2016, at 2.06, Margaret Cullen wrote: > On Mar 8, 2016, at 7:55 AM, Alexandre Petrescu = wrote: >>> - An NTP server option for RAs, so that DNSSEC can be used for the = lookup. >>=20 >> Sounds like a good idea. >>=20 >> I guess DNSSEC operation needs the querier to have the right time = otherwise it's insecure? Hence the need for NTP? >=20 > As I understand it, DNSSEC needs the right time, otherwise it doesn=92t = work. Yes. Although given sane RTCs it can most of the time work even without = _accurate_ time. >> I could find 2 earlier drafts on this, maybe there are others. >> draft-chen-ntps-ra-opt-00 >> draft-bcd-6man-ntp-server-ra-opt-00 >>=20 >> If extending RA then it's good to use the RA "flags option" RFC5075. >=20 > I don't think we'd probably do an NTP RA option in the MIF WG. I = suspect it would make more sense to do it in 6man =97 we'd have to = discuss it with them and see if they agree. NTP RA option would not really fix the solution securely anyway, as = secure RA does not really happen. And secure NTP is also something that = does not really happen. So there is chicken and egg problem there that = is relatively far out of MIF scope I think. IETF being IETF, we cannot specify insecure things these days officially = but all base things are insecure and/or undeployed. Cheers, -Markus= From nobody Sun Mar 13 04:54:54 2016 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D9812D5AA for ; Sun, 13 Mar 2016 04:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 1p4Xm4-iKiYn for ; Sun, 13 Mar 2016 04:54:50 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 46E2112D5C0 for ; Sun, 13 Mar 2016 04:54:50 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id g127so138324830ywf.2 for ; Sun, 13 Mar 2016 04:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:mime-version:subject:in-reply-to:date:cc:message-id:references :to; bh=fLJaDYK1NnnQPFxF8ZMKMFq+vUzjxB4FAj2y9Zv87Xc=; b=LdzJhjNehtYMK4iVTOFtgwn+zCVB8MbwrFkBqofvSiAJe+qsi7ka5RKXmUJt27HwqH 0sKCp+7ZDyWM0xC9WoavWhFNr3u+j7zIrNPgO0hG6IDJgCCBiKan9hDc28D0EC5JXyiv XFZ/JzoxxVixm5+RQBgybb3+bHP0UA7BdUMuW+nThFU8etPNTDiZ+1IIvND0BLCmXWUb gCzS2GdeFHYwdLolIxcjYmogS9P3Uu6KStHZrV1D4hJvSx04XE1Xjn/kvQ8SN2GSyXox iTpIfoNojmeqPK2A7Mqpt5TQ85BCD6O7QuGhqxXLF1A4j/vl08c82V6h5euXeUt1S9j0 XtMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:subject:in-reply-to:date:cc :message-id:references:to; bh=fLJaDYK1NnnQPFxF8ZMKMFq+vUzjxB4FAj2y9Zv87Xc=; b=QPv1TAON60An6Vld6jtgVYnaXx3WHr6otnIQdEyJlPQGFZGrtaSfczLc0QgOsA7eAT q5ETXWurc3bIh96Qpoz8fKa9n9z/iaJ/xgZxDNFIGOtNmh1KEQuvqhmnIPVjKKfV9n48 wR0sANS6ZIdqpl/NKQmUgayCyzAJJ/dmTFG2tXwm4E+Ylx9qbeqd+UNQsBDUOg6p+20p mupwlZJfOu69bmbFZi761pgg7cmUMXgfPWlTVu6PW4wjMzvi7tQFugxGzu/N4+tFqaZ0 RiaD/0UxtuFy0PNMkTVW9JN+fPatkZmZAjZiIn6GpwWHhbe1tNQWUTyGFpfKSRmiKoua Ab2g== X-Gm-Message-State: AD7BkJIhN4y6ivzVboTt252PJbhvE/OLN6A0gde2vvEZz+TdL4JTE8lfNFXjSS3Y3Y0DVA== X-Received: by 10.13.229.3 with SMTP id o3mr10510684ywe.329.1457870089528; Sun, 13 Mar 2016 04:54:49 -0700 (PDT) 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 q141sm11111273ywg.2.2016.03.13.04.54.47 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 13 Mar 2016 04:54:47 -0700 (PDT) From: Margaret Wasserman X-Google-Original-From: Margaret Wasserman Content-Type: multipart/signed; boundary="Apple-Mail=_4B5BCF87-F63E-49AB-B746-521D9F2D1FB6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) In-Reply-To: Date: Sun, 13 Mar 2016 07:54:45 -0400 Message-Id: <42207FA4-3C9B-4F1E-BAC8-CAF4261AB764@gmail.com> References: <39E5345B-04C4-4149-A1A6-F0F5F4988C16@gmail.com> <56DECBC9.7060800@gmail.com> <9B436C85-C05B-430A-915E-C332604DAA7E@gmail.com> To: Markus Stenberg X-Mailer: Apple Mail (2.1510) Archived-At: Cc: mif@ietf.org Subject: Re: [mif] New Charter Items - NTP in RA for DNSSEC X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 11:54:52 -0000 --Apple-Mail=_4B5BCF87-F63E-49AB-B746-521D9F2D1FB6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Mar 13, 2016, at 5:26 AM, Markus Stenberg = wrote: > NTP RA option would not really fix the solution securely anyway, as = secure RA does not really happen. And secure NTP is also something that = does not really happen. So there is chicken and egg problem there that = is relatively far out of MIF scope I think. Since we get our information on how to reach the DNS from RAs, getting = our NTP information there isn't any less secure than getting our time = information somewhere else, and then using to to reach the DNS we = received in an RA, is it? Having NTP information passed in an RA doesn't make RAs more secure, but = it does change the threat model of a DNS lookup. For regular DNS, the = attacker only needs to spoof a DNS server (ours or one higher up in the = tree), whereas to attack us in the case where we are getting an NTP = server in an RA and using DNSSEC, the attacker also needs to be able to = inject traffic on our local network that looks like it came form our = router. So, configuring an NTP Server via RAs and using DNSSEC is more = secure than just using DNS, even if we can't/don't secure the mechanism = via which our DNS and NTP Server are configured. > IETF being IETF, we cannot specify insecure things these days = officially but all base things are insecure and/or undeployed. The spectre of the intractable security AD who blocks your work until = you secure the entire Internet is just a holdover from a less reasonable = time, IMO. With the current ADs, you can generally specify something = that is (1) more secure than the alternative, and/or (2) not less secure = than what you are replacing. It sometimes requires that you work with = the ADs to help them understand that. I am really quite sure that the security ADs would not block a new RA = option because we didn't figure out how to get the world to deploy SEND. Margaret --Apple-Mail=_4B5BCF87-F63E-49AB-B746-521D9F2D1FB6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJW5VUGAAoJEJrxOXzI3ic/9WYIAJtbwekoNQfkjhpE39j5khOf BeWwTPPwvalyc5mvno8befx/IRhbhmzBdmv4WbuHuZMbCpyXR02vJT9buEYSAfuD HElcwxptv9t3blOdrm1V6aeqEOsfiVhWugccEJ7FRpRctgskdM07R17qMnsnKDwU pD0ezvg3SOyRXG0ik5itG25rQkdghZh9w6zXbPGP7j9C2WEAipGhM5WiNLm8wWge 3p2JVv2ncnAH/Ue3YcmzLYjVZbp/aT/C+T36xz+GCC4LDPOtgoW7fXzxhZmCFQUb CbM55j/5xrPwigdIhp4kdAy+Ka32RUqLDDdrAf196RlafET+Y1N/XU+3zTcscU8= =SAQc -----END PGP SIGNATURE----- --Apple-Mail=_4B5BCF87-F63E-49AB-B746-521D9F2D1FB6-- From nobody Tue Mar 15 03:30:51 2016 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB5B12D972; Tue, 15 Mar 2016 03:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 x8XJGuA4Zurx; Tue, 15 Mar 2016 03:26:44 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAF2A12D936; Tue, 15 Mar 2016 03:26:40 -0700 (PDT) Received: from [46.227.151.81] (port=51090 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1afmBS-00018i-84 (Exim 4.72) (return-path ); Tue, 15 Mar 2016 10:26:38 +0000 To: mif@ietf.org, draft-stenberg-mif-mpvd-dns@ietf.org From: Ray Bellis Message-ID: <56E7E35D.6040108@bellis.me.uk> Date: Tue, 15 Mar 2016 10:26:37 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Tue, 15 Mar 2016 03:30:51 -0700 Subject: [mif] Domain name issue in draft-stenberg-mif-mpvd-dns X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 10:26:46 -0000 Looking at section 3 of this draft, I have a problem with the specification where it says that for e.g. a /64 the DNS lookup should be for _pvd.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.x....ip6.arpa, and likewise the /80 example (with 12 leading zeros). Taking the /80 example, it would be impossible given this specification to distinguish between a /80 where the bits between 64 and 80 were all zeros and the corresponding /64 - they would both end up at the same point in the ip6.arpa hierarchy. In my opinion (and I do have some prior art in this space, see RFC 7216) the "_pvd" label must be at the point in the ip6.arpa that presents the same level as the prefix being queried for. Any leading zeros below that point (i.e. to the left in the domain name) MUST be omitted. Hence in the /80 case, it would be _pvd.<20 labels>.ip6.arpa and in the /64 case it would be _pvd.<16 labels>.ip6.arpa Ray From nobody Tue Mar 15 04:09:21 2016 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A7112D52E; Tue, 15 Mar 2016 04:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=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 HG2RsqV8nqC4; Tue, 15 Mar 2016 04:09:16 -0700 (PDT) Received: from johanna1.inet.fi (mta-out1.inet.fi [62.71.2.199]) by ietfa.amsl.com (Postfix) with ESMTP id 08F9512D98F; Tue, 15 Mar 2016 04:08:59 -0700 (PDT) RazorGate-KAS: Status: not_detected RazorGate-KAS: Rate: 0 RazorGate-KAS: Envelope from: RazorGate-KAS: Version: 5.5.3 RazorGate-KAS: LuaCore: 80 2014-11-10_18-01-23 260f8afb9361da3c7edfd3a8e3a4ca908191ad29 RazorGate-KAS: Lua profiles 69136 [Nov 12 2014] RazorGate-KAS: Method: none Received: from [192.168.200.82] (192.194.110.125) by johanna1.inet.fi (9.0.002.03-2-gbe5d057) (authenticated as stenma-47) id 56E17AEE006F0D8F; Tue, 15 Mar 2016 13:08:56 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Markus Stenberg In-Reply-To: <56E7E35D.6040108@bellis.me.uk> Date: Tue, 15 Mar 2016 13:08:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2514F81A-CDC6-4F90-A76D-816A8F4EEDC4@iki.fi> References: <56E7E35D.6040108@bellis.me.uk> To: Ray Bellis X-Mailer: Apple Mail (2.3112) Archived-At: Cc: draft-stenberg-mif-mpvd-dns@ietf.org, mif@ietf.org Subject: Re: [mif] Domain name issue in draft-stenberg-mif-mpvd-dns X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 11:09:20 -0000 > On 15.3.2016, at 12.26, Ray Bellis wrote: > Looking at section 3 of this draft, I have a problem with the > specification where it says that for e.g. a /64 the DNS lookup should = be > for _pvd.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.x....ip6.arpa, and likewise = the > /80 example (with 12 leading zeros). >=20 > Taking the /80 example, it would be impossible given this = specification > to distinguish between a /80 where the bits between 64 and 80 were all > zeros and the corresponding /64 - they would both end up at the same > point in the ip6.arpa hierarchy. >=20 > In my opinion (and I do have some prior art in this space, see RFC = 7216) > the "_pvd" label must be at the point in the ip6.arpa that presents = the > same level as the prefix being queried for. Any leading zeros below > that point (i.e. to the left in the domain name) MUST be omitted. >=20 > Hence in the /80 case, it would be _pvd.<20 labels>.ip6.arpa and in = the > /64 case it would be _pvd.<16 labels>.ip6.arpa Actually we considered it a feature and not a bug, i.e. subdelegation = would still result in same PVD available. I am not sure your scheme = would work with subdelegation though. Given broad example, ISP has /40 for home users, but ultimately the = prefix in use may be e.g. /64 (or even something more narrow). Having = the _pvd.* in 'all' prefix lengths would be obviously available, or = performing (up to 128) lookups with subsequently shorter/longer prefix = lengths. I am not sure how client would know to start lookups from /40, or from = /56 assigned to a home, if the link has /64. Cheers, -Markus= From nobody Tue Mar 15 04:22:12 2016 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28DAD12D8C5; Tue, 15 Mar 2016 04:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 iGb4K0DX-KzT; Tue, 15 Mar 2016 04:22:09 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF11812D546; Tue, 15 Mar 2016 04:22:09 -0700 (PDT) Received: from [46.227.151.81] (port=52138 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1afn39-0002lj-98 (Exim 4.72) (return-path ); Tue, 15 Mar 2016 11:22:07 +0000 To: Markus Stenberg References: <56E7E35D.6040108@bellis.me.uk> <2514F81A-CDC6-4F90-A76D-816A8F4EEDC4@iki.fi> From: Ray Bellis Message-ID: <56E7F060.1040004@bellis.me.uk> Date: Tue, 15 Mar 2016 11:22:08 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <2514F81A-CDC6-4F90-A76D-816A8F4EEDC4@iki.fi> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-stenberg-mif-mpvd-dns@ietf.org, mif@ietf.org Subject: Re: [mif] Domain name issue in draft-stenberg-mif-mpvd-dns X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 11:22:11 -0000 On 15/03/2016 11:08, Markus Stenberg wrote: > Actually we considered it a feature and not a bug, i.e. subdelegation > would still result in same PVD available. I am not sure your scheme > would work with subdelegation though. OK, I see that, but I still think you have a problem since: 2001:0:0:0::/64 and 2001:0:0:0:0::/80 and even: 2001::/16 will end up at the same domain name. > Given broad example, ISP has /40 for home users, but ultimately the > prefix in use may be e.g. /64 (or even something more narrow). Having > the _pvd.* in 'all' prefix lengths would be obviously available, or > performing (up to 128) lookups with subsequently shorter/longer > prefix lengths. > > I am not sure how client would know to start lookups from /40, or > from /56 assigned to a home, if the link has /64. In RFC 7216 we took a "minimal" tree climbing approach, putting the records at "common" LIR / RIR prefix boundaries of /64, /56, /48, or /32. Anything more would have angered the DNS Gods... Is there no other way for the client to learn the size of the upstream PD from which its /64 has been carved out? Ray From nobody Tue Mar 15 04:35:51 2016 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3307412D991; Tue, 15 Mar 2016 04:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=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 WBAFS4SITqJK; Tue, 15 Mar 2016 04:35:48 -0700 (PDT) Received: from johanna3.inet.fi (mta-out1.inet.fi [62.71.2.195]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB7112D978; Tue, 15 Mar 2016 04:35:47 -0700 (PDT) RazorGate-KAS: Status: not_detected RazorGate-KAS: Rate: 0 RazorGate-KAS: Envelope from: RazorGate-KAS: Version: 5.5.3 RazorGate-KAS: LuaCore: 80 2014-11-10_18-01-23 260f8afb9361da3c7edfd3a8e3a4ca908191ad29 RazorGate-KAS: Lua profiles 69136 [Nov 12 2014] RazorGate-KAS: Method: none Received: from [192.168.200.82] (192.194.110.125) by johanna3.inet.fi (9.0.002.03-2-gbe5d057) (authenticated as stenma-47) id 56E79371000E44B1; Tue, 15 Mar 2016 13:35:46 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Markus Stenberg In-Reply-To: <56E7F060.1040004@bellis.me.uk> Date: Tue, 15 Mar 2016 13:35:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0EC649AC-8FDB-4B7E-B746-8173825ECF44@iki.fi> References: <56E7E35D.6040108@bellis.me.uk> <2514F81A-CDC6-4F90-A76D-816A8F4EEDC4@iki.fi> <56E7F060.1040004@bellis.me.uk> To: Ray Bellis X-Mailer: Apple Mail (2.3112) Archived-At: Cc: draft-stenberg-mif-mpvd-dns@ietf.org, mif@ietf.org Subject: Re: [mif] Domain name issue in draft-stenberg-mif-mpvd-dns X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 11:35:50 -0000 > On 15.3.2016, at 13.22, Ray Bellis wrote: > On 15/03/2016 11:08, Markus Stenberg wrote: >> Actually we considered it a feature and not a bug, i.e. subdelegation >> would still result in same PVD available. I am not sure your scheme >> would work with subdelegation though. > OK, I see that, but I still think you have a problem since: >=20 > 2001:0:0:0::/64 >=20 > and >=20 > 2001:0:0:0:0::/80 >=20 > and even: >=20 > 2001::/16 >=20 > will end up at the same domain name. Not necessarily. Your home _could_ provide (split horizon) different = records than someone else's home. Or ISP could subdelegate that part to = your home (then again, I am not sure I would bet on it). >> Given broad example, ISP has /40 for home users, but ultimately the >> prefix in use may be e.g. /64 (or even something more narrow). Having >> the _pvd.* in 'all' prefix lengths would be obviously available, or >> performing (up to 128) lookups with subsequently shorter/longer >> prefix lengths. >>=20 >> I am not sure how client would know to start lookups from /40, or >> from /56 assigned to a home, if the link has /64. > In RFC 7216 we took a "minimal" tree climbing approach, putting the > records at "common" LIR / RIR prefix boundaries of /64, /56, /48, or > /32. Anything more would have angered the DNS Gods... >=20 > Is there no other way for the client to learn the size of the upstream > PD from which its /64 has been carved out? Not without some new option in RA/DHCP I think. Cheers, -Markus= From nobody Tue Mar 15 11:44:21 2016 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFD012DD10; Tue, 15 Mar 2016 11:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ixweO4_rC2rI; Tue, 15 Mar 2016 11:44:16 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 175F312D6C2; Tue, 15 Mar 2016 11:44:05 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id g127so32543202ywf.2; Tue, 15 Mar 2016 11:44:05 -0700 (PDT) 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:message-id:references :to; bh=JoZH9ysaCpxFGFtlEVMf8dlNVAHHdutpOFNLSiwHurQ=; b=ZuSkZXRpry4bWRRKdcolWbTylNhZGCYesBmQbeDj8K6E8PtiP68rpUpJfWut2lsUl/ JlSErx2GB+TX0n2UGumd9vSBDPT4QMG83+RFsrNESuab0OxP9YM/QcXEQU9glR+IczmQ K+l2LocVMTwUzl4xavFnKKkFlTsbvGyFX/b56yPs80V+k3ZVaVfHhbzYG+GL+vBx4onw r97aJXAFdguHi5EWkv7HyxZEMfnRZfNLM7LWcmQF3EIPKbRgGdFWc/gV4OimoJH64TMY B55NH+Zdz9bjDQQBk8jCiLJad9WQwHs/O+1EeRj2y7vjOKksNGF1OagUX2PuDCEZnrVx 2vug== 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 :message-id:references:to; bh=JoZH9ysaCpxFGFtlEVMf8dlNVAHHdutpOFNLSiwHurQ=; b=Cq2iRzeVRdr+MnaO+mwkly+ereZT9CcVAWGL9CyyFc/9oNFVldY0lccCyZ1uA5ih2F SqIUqVIFPTuER3Zt8gv5y6O0AkRoZSbKQdU9tJ4YBT7npe4e9kNMLE6sciu6Oaqkw4ge 9naAAhU7lha2UqwmFgXw+SBprX7WgrX3GkPvqBS2laOfL8bJ2UqFJcNRbi6tfvTEPPEy i8NtTK9WSNx34yrb3AxCUVhOLILsFP/6DlkNcEr+84+GRMo7wnyh4vO3/RzxdftTWNKY gDCJcppW5W1N63Tf75xQylixd+l3vJpEMCAQxxRRrieHnaDROXSWWL52HuzLpZzp+c1B 3ziQ== X-Gm-Message-State: AD7BkJJO0qDQDxTOJ3mdg/ig413y/Vv4S8HHUmCk8WMtxomCL/A3ywW/7UCv1GueLF4B8g== X-Received: by 10.37.41.66 with SMTP id p63mr15701019ybp.183.1458067444350; Tue, 15 Mar 2016 11:44:04 -0700 (PDT) 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 b3sm17936080ywc.24.2016.03.15.11.44.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Mar 2016 11:44:03 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_396182A9-246F-4D73-8019-BDAE0FA74EAB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Margaret Cullen In-Reply-To: <56E7E35D.6040108@bellis.me.uk> Date: Tue, 15 Mar 2016 14:44:02 -0400 Message-Id: References: <56E7E35D.6040108@bellis.me.uk> To: Ray Bellis X-Mailer: Apple Mail (2.1510) Archived-At: Cc: draft-stenberg-mif-mpvd-dns@ietf.org, mif@ietf.org Subject: Re: [mif] Domain name issue in draft-stenberg-mif-mpvd-dns X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 18:44:18 -0000 --Apple-Mail=_396182A9-246F-4D73-8019-BDAE0FA74EAB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Personally, I think the lookup should be via PVD name, not based on the = IP address of the link, as there are many cases in which the IP = addresses known to the end nodes are not known to the DNS. Margaret On Mar 15, 2016, at 6:26 AM, Ray Bellis wrote: > Looking at section 3 of this draft, I have a problem with the > specification where it says that for e.g. a /64 the DNS lookup should = be > for _pvd.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.x....ip6.arpa, and likewise = the > /80 example (with 12 leading zeros). >=20 > Taking the /80 example, it would be impossible given this = specification > to distinguish between a /80 where the bits between 64 and 80 were all > zeros and the corresponding /64 - they would both end up at the same > point in the ip6.arpa hierarchy. >=20 > In my opinion (and I do have some prior art in this space, see RFC = 7216) > the "_pvd" label must be at the point in the ip6.arpa that presents = the > same level as the prefix being queried for. Any leading zeros below > that point (i.e. to the left in the domain name) MUST be omitted. >=20 > Hence in the /80 case, it would be _pvd.<20 labels>.ip6.arpa and in = the > /64 case it would be _pvd.<16 labels>.ip6.arpa >=20 > Ray >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif --Apple-Mail=_396182A9-246F-4D73-8019-BDAE0FA74EAB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJW6FfzAAoJEJrxOXzI3ic/xycIAJm2CPiqd5GgmzO+vzk6cd+6 TitOWW+Gw0nenpBmoPOPkRiQAANKmhmWVE/SpQDDYhS5shQo/+PKZILeemJNxdf9 yGTn3kPyzxjj4lYpYqzn3sBEE2cyYq5FGxaBayNaHMVDP9ptUrfNA4TfVfamQH4d F7EvpXdSPW+wRLvTpHE8+SZyz5hf2fB4ZfRw9zPxlpVF7Kruw30+zHLrESI3bVMJ 1cs8OMaQvp93Fntp6uvuVhJM4NtfdUL2NiWXizKl70HDbammumlL+ab03c4dcCC6 cv9nrnjNF3N1mOgBHmiDXf4Ntr58d8LfuRMgE1vEp78w2KOIjQx/zJS1JNMY2Dg= =HEeX -----END PGP SIGNATURE----- --Apple-Mail=_396182A9-246F-4D73-8019-BDAE0FA74EAB-- From nobody Thu Mar 17 03:56:35 2016 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE8D12D98F for ; Thu, 17 Mar 2016 03:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 pYz-rKpVdkek for ; Thu, 17 Mar 2016 03:56:27 -0700 (PDT) Received: from mail.zemris.fer.hr (gandalf.zemris.fer.hr [161.53.65.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8E45A12D968 for ; Thu, 17 Mar 2016 03:56:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.zemris.fer.hr (Postfix) with ESMTP id BE8643B7C063; Thu, 17 Mar 2016 11:56:18 +0100 (CET) X-Virus-Scanned: amavisd-new at zemris.fer.hr Received: from mail.zemris.fer.hr ([127.0.0.1]) by localhost (mail.zemris.fer.hr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ge-P-n0NfRdz; Thu, 17 Mar 2016 11:56:17 +0100 (CET) Received: from w540.sistemnet.local (unknown [91.208.233.27]) by mail.zemris.fer.hr (Postfix) with ESMTPSA id 477173B7C061; Thu, 17 Mar 2016 11:56:17 +0100 (CET) To: "mif@ietf.org" From: =?UTF-8?Q?Stjepan_Gro=c5=a1?= Organization: UNIZG - FER Message-ID: <56EA8D49.7040902@fer.hr> Date: Thu, 17 Mar 2016 11:56:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XJst67jPpwRuIuqTWFG7masgWLh580PQS" Archived-At: Subject: [mif] Proposal for circumventing Huawei IPR X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 10:56:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XJst67jPpwRuIuqTWFG7masgWLh580PQS Content-Type: multipart/alternative; boundary="------------020900040600090705040301" This is a multi-part message in MIME format. --------------020900040600090705040301 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi everyone, here is the proposal on how to circumvent Huawei's IPR claim so that we are able to use DHCP for what it was designed for, node configuration. As an added bonus, we also solve the problem of multiple concurrent DHCP servers on a single local network. First, let me state few assumptions: 1. The alleged problem with Huawei's IPR claim is that it includes an ID in DHCP server's response and for that reason this group abandoned the approach. 2. In the talks about the exact format of ID there were suggestions to use only UUID. Based on my experience while implementing PvD support in NetworkManager (https://github.com/sgros/MIF_NetworkManager) this is good approach because it simplifies things a lot. 3. DNS can be used for service discovery, but other mechanisms (and descriptions) should be allowed as well. Additionally, service description should include reachability definitions. 4. ID is used only for identification purposes of some specific PvD, and possibly as a parameter in a service discovery (even though DNS approach doesn't do that, but e.g. HTTP approach might). So, what I propose is NOT to send ID in responses but only a container option with a set of options that belong to a single PvD instance. ID is then calculated based on the PvD parameters, e.g. MD5(NETWORK_PREFIX, NETWORK_PREFIX_LEN, DNS_SERVERS, DNS_DOMAINS) Concrete set of options/parameters is to be determined but it is intention to uniquely identify PvD, not PvD instance. In this way client will be able to distinguish PvDs, and if necessary client and server will agree on unique PvD ID for each PvD. Few additional notes/comments: 1. This can be calculated for implicit, as well as explicit PvDs. Note that in the mentioned implementation I was using this approach to try to differentiate implicit PvDs sent in RA messages. 2. Part of PvD CO option might be an option that specifies how to do service discovery. This would allow flexibility. This option should also be included in ID computation. 3. For an added flexibility (if its really needed as it complicates things!) PvD CO option might specify which options to include or not include in the calculation of ID. 4. After node learns about some PvD it can request specific PvD by including its calculated PvD ID in request. The response will be without ID, obviously! Huawei IPR claim doesn't cover this case. 5. This would solve the situation of multiple DHPC non-PvD aware servers on a local network. By calculating ID of each reposnse client can determine if those responses are alternative (failover) or concurrent and react appropriately. The same mechanism might be used for RA messages= =2E 6. The approach will work for local network configuration (PvD specific for a certain local network) as well as for PvD's specific for providers' global networks (i.e. sending "video only" PvD to all its customers that are on different IPv6 subnetworks). SG P.S. Just as a note, I use of two distinct terms "PvD" and "PvD instance". "PvD instance" includes specific host information like concrete IP address, while "PvD" is a set of "PvD instances" valid on a certain network. To even better describe the difference, it should be noted that RAs send PvDs, while DHCPv4/DHCPv6 resposnes send PvD instance= s. --------------020900040600090705040301 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi everyone,

here is the proposal on how to circumvent Huawei's IPR claim so that we are able to use DHCP for what it was designed for, node configuration. As an added bonus, we also solve the problem of multiple concurrent DHCP servers on a single local network.

First, let me state few assumptions:

1. The alleged problem with Huawei's IPR claim is that it includes an ID in DHCP server's response and for that reason this group abandoned the approach.

2. In the talks about the exact format of ID there were suggestions to use only UUID. Based on my experience while implementing PvD support in NetworkManager (https://github.com/sgros/MIF_NetworkManager) th= is is good approach because it simplifies things a lot.

3. DNS can be used for service discovery, but other mechanisms (and descriptions) should be allowed as well. Additionally, service description should include reachability definitions.

4. ID is used only for identification purposes of some specific PvD, and possibly as a parameter in a service discovery (even though DNS approach doesn't do that, but e.g. HTTP approach might).=

So, what I propose is NOT to send ID in responses but only a container option with a set of options that belong to a single PvD instance. ID is then calculated based on the PvD parameters, e.g.
MD5(NETWORK_PREFIX, NETWORK_PREFIX_LEN, DNS_SERVERS, DNS_DOMAINS)
Concrete set of options/parameters is to be determined but it is intention to uniquely identify PvD, not PvD instance. In this way client will be able to distinguish PvDs, and if necessary client and server will agree on unique PvD ID for each PvD.

Few additional notes/comments:

1. This can be calculated for implicit, as well as explicit PvDs. Note that in the mentioned implementation I was using this approach to try to differentiate implicit PvDs sent in RA messages.=

2. Part of PvD CO option might be an option that specifies how to do service discovery. This would allow flexibility. This option should also be included in ID computation.

3. For an added flexibility (if its really needed as it complicates things!) PvD CO option might specify which options to include or not include in the calculation of ID.

4. After node learns about some PvD it can request specific PvD by including its calculated PvD ID in request. The response will be without ID, obviously! Huawei IPR claim doesn't cover this case.
5. This would solve the situation of multiple DHPC non-PvD aware servers on a local network. By calculating ID of each reposnse client can determine if those responses are alternative (failover) or concurrent and react appropriately. The same mechanism might be used for RA messages.

6. The approach will work for local network configuration (PvD specific for a certain local network) as well as for PvD's specific for providers' global networks (i.e. sending "video only" PvD to all its customers that are on different IPv6 subnetworks).
SG

P.S. Just as a note, I use of two distinct terms "PvD" and "PvD instance". "PvD instance" includes specific host information like concrete IP address, while "PvD" is a set of "PvD instances" valid on a certain network. To even better describe the difference, it should be noted that RAs send PvDs, while DHCPv4/DHCPv6 resposnes send PvD instances.
 --------------020900040600090705040301-- --XJst67jPpwRuIuqTWFG7masgWLh580PQS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJW6o1JAAoJEOggxEF22YTDJisQAKVOLXvq6gMBY6lBsGOJQLPv 2fiCVPlKvw/PPHHa2qrVSr9FVuzvDZfVILmix4G+1qngX+1LLrgupO5UCTsOzq/s XCBUyi+G+0uMYvwbo41vUbZcT3LY3PEuELcDgyaCTbhsvJM5QNi+ofOAwYrDl2IU qQb3lvhuWA30NqChDpTIptl1kXvm4Rcq353epjEbHWw/M/QaARMj3xQksLJue5eA 06VRpJBdO4TKnLEl5ViCOZloazcmfdoaEdKBrkXsYlHE4vSc/0YmJKnhiM+qfauA PQ+AKevPoNePzdCZmHMw1zxQAySSxMJVI5D1clsKoLPClQP6cbgbwuo6mA+yuc1A UDQF3zvlWBCYemjSYRLeUx7ZJcbvmng2dMDIo+OjAkEvNcT/lotSSc4GOQqRp9vP P1UcpgFhEFSIee6SM+yD+2yWJGLFySxEHCXciOoG3HA2+1L2pUUrDOL6hr6R2nsS qMpdnpXPmd4wbnL3f4FlJHHKQa9GvI5EE/fwTB/GHdlUO2kT4eG6FdUJOQnQgazP GyUQSmJqlMaY3r1CMx9degRMPDPp7h2HuJrULZZkc0LvbQrElWqcEzR7xKXiUWCa liCOtL3awxecw2n+M8uGpr99Ah8M85ipULCxzth0kPHKb5T3iF47Xv50nQsaHhRX O1iAxvb9makx3XkDZhvZ =RHW3 -----END PGP SIGNATURE----- --XJst67jPpwRuIuqTWFG7masgWLh580PQS-- From nobody Thu Mar 17 17:55:13 2016 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5BF12D782 for ; Thu, 17 Mar 2016 17:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 9BDM58TcsPRj for ; Thu, 17 Mar 2016 17:55:08 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB1E512D612 for ; Thu, 17 Mar 2016 17:55:08 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 17 Mar 2016 17:55:06 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1130.005; Thu, 17 Mar 2016 17:55:06 -0700 From: Terry Manderson To: =?iso-8859-2?Q?Stjepan_Gro=B9?= , "mif@ietf.org" Thread-Topic: [mif] Proposal for circumventing Huawei IPR Thread-Index: AQHRgDu6rtHWPX71UU+vpQpOynGL/Z9ffiCA Date: Fri, 18 Mar 2016 00:55:05 +0000 Message-ID: References: <56EA8D49.7040902@fer.hr> In-Reply-To: <56EA8D49.7040902@fer.hr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3541143303_44088962" MIME-Version: 1.0 Archived-At: Subject: Re: [mif] Proposal for circumventing Huawei IPR X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 00:55:12 -0000 --B_3541143303_44088962 Content-type: text/plain; charset="ISO-8859-2" Content-transfer-encoding: quoted-printable Stjepan and All, As the responsible AD I would like this thread to stop here. A Working Group can either choose to accept (by rough consensus) technology that is encumbered by IPR or not accept that technology. Once rough consensus is reached on an IPR disclosure, all WG participants are expected to abide by that in dealing with the encumbered technology in the WG. The WG reached rough consensus in November 2015 to drop draft-ietf-mif-mpvd-dhcp-support (https://www.ietf.org/id/draft-ietf-mif-mpvd-dhcp-support-02.txt) with the IPR claim at https://datatracker.ietf.org/ipr/2648/ Any participant may suggest new alternative technologies for the WG to consider via the known methods. Cheers Terry On 17/03/2016, 8:56 PM, "mif on behalf of Stjepan Gro=B9" wrote: >Hi everyone, > >here is the proposal on how to circumvent Huawei's IPR claim so that we >are able to use DHCP for what it was designed for, node configuration. As >an added bonus, we also solve the problem of multiple concurrent DHCP >servers on a single local network. > >First, let me state few assumptions: > >1. The alleged problem with Huawei's IPR claim is that it includes an ID >in DHCP server's response and for that reason this group abandoned the >approach. > >2. In the talks about the exact format of ID there were suggestions to >use only UUID. Based on my experience while implementing PvD support in >NetworkManager (https://github.com/sgros/MIF_NetworkManager) > this is good approach because it simplifies things a lot. > >3. DNS can be used for service discovery, but other mechanisms (and >descriptions) should be allowed as well. Additionally, service >description should include reachability definitions. > >4. ID is used only for identification purposes of some specific PvD, and >possibly as a parameter in a service discovery (even though DNS approach >doesn't do that, but e.g. HTTP approach might). > >So, what I propose is NOT to send ID in responses but only a container >option with a set of options that belong to a single PvD instance. ID is >then calculated based on the PvD parameters, e.g. > >MD5(NETWORK_PREFIX, NETWORK_PREFIX_LEN, DNS_SERVERS, DNS_DOMAINS) > >Concrete set of options/parameters is to be determined but it is >intention to uniquely identify PvD, not PvD instance. In this way client >will be able to distinguish PvDs, and if necessary client and server will >agree on unique PvD ID for each PvD. > >Few additional notes/comments: > >1. This can be calculated for implicit, as well as explicit PvDs. Note >that in the mentioned implementation I was using this approach to try to >differentiate implicit PvDs sent in RA messages. > >2. Part of PvD CO option might be an option that specifies how to do >service discovery. This would allow flexibility. This option should also >be included in ID computation. > >3. For an added flexibility (if its really needed as it complicates >things!) PvD CO option might specify which options to include or not >include in the calculation of ID. > >4. After node learns about some PvD it can request specific PvD by >including its calculated PvD ID in request. The response will be without >ID, obviously! Huawei IPR claim doesn't cover this case. > >5. This would solve the situation of multiple DHPC non-PvD aware servers >on a local network. By calculating ID of each reposnse client can >determine if those responses are alternative (failover) or concurrent and >react appropriately. The same mechanism might > be used for RA messages. > >6. The approach will work for local network configuration (PvD specific >for a certain local network) as well as for PvD's specific for providers' >global networks (i.e. sending "video only" PvD to all its customers that >are on different IPv6 subnetworks). > >SG > >P.S. Just as a note, I use of two distinct terms "PvD" and "PvD >instance". "PvD instance" includes specific host information like >concrete IP address, while "PvD" is a set of "PvD instances" valid on a >certain network. To even better describe the difference, > it should be noted that RAs send PvDs, while DHCPv4/DHCPv6 resposnes >send PvD instances. --B_3541143303_44088962 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIYwwYJKoZIhvcNAQcCoIIYtDCCGLACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC FowwggV0MIIEXKADAgECAhAJ0fxYYYV36W1njUywVtW8MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNTAzMjYw MDAwMDBaFw0xODAzMjYxMjAwMDBaMIGQMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEYMBYGA1UEAxMPVGVycnkgTWFu ZGVyc29uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwTImt0Ol/9dOAbnm4lby 4RG1iQEnHVB5UJTYqwX8kqEhA5NPFHbMX22ChnP7M/zIlY+OP2TfKcwfdF5DJN4ybt4gFGzE 9ksigMe365F0uA2Q4+CskwqWo2fGIqrhgb0C68bg6EnZxj73KlJ0mvbQqzLBY8fVwr8srWpB BexjbYSeXp/+0W41ZOJPcdii59TDXRBGuziWjp+rd7yh8KCzKcj/Px1TzAE5U/TftZOfigYi h6KTTDZBGnN+4DDaaCnZ93rveayavI3hd4agqiIWe/gB78+0vHyk5DFoe6HkwuL0qJVaBW57 KIt8AYq+p0P+igNhiQoHkPx3VvS7ZViGdQIDAQABo4IB8jCCAe4wHwYDVR0jBBgwFoAU5wIj gABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFIXwv/ZX+K34v+mCL8g1Coo9c6lMMAwGA1Ud EwEB/wQCMAAwJAYDVR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8B Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYK YIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2Nh Y2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG 9w0BAQsFAAOCAQEAH1Dvq3r4yh4+zU4t+5Rg3EzwMpSPxApBivVcW/KPq9uwdlu3yGBPJlG9 j4BXOT7fEUEGpCfyfRhBzTReyc2zask73fDRTzNFl5U3gqzOre5+Xtzv0qHyZGZ2EGcPTFv9 oaAVTug//Z6ZSr4dtDphV/7uSA4Hj1riFh5yxHErwUfrbCneIspVqwSVJqjkKWGID6W0YB0D cYJZGlyAH0FP/4+TMDxXOti2ypQrsZpNSfvc4TGC1p13Lyp4XEY+UysVtcypAgersTBN6gCb 7ueBt5KPTj9pH4w4C0lNO6rRIc6AGtJIuXHYyiy9CXUTOT5xLToXLZCyPXd+HFuWwdD9lzCC Bk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAw MFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr +Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQ elAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK 3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uC ig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/ BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9j cmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0 dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgB hv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCC AWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABD AGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBl AHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBD AFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBn AHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABp AHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQBy AGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8 lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrg YhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg 4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmw XZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1Y EhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3 MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x JDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBa Fw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMx GTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQg SUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfz t2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq 9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OM M9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJ fDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwO sLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGG MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1Ud IwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w 43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbG easS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59Pyvz tyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2 BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdh AbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIHAzCCBeugAwIBAgIQD89pSVGb AJQ9+ZeKCcX9BTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGln aUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2Vy dCBBc3N1cmVkIElEIENBLTEwHhcNMTIwMzI3MDAwMDAwWhcNMTUwMzI3MTIwMDAwWjCBrDEL MAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFzAVBgNVBAcTDk1hcmluYSBkZWwg UmV5MTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jwb3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMg YW5kIE51bWJlcnMxFzAVBgNVBAsTDkROUyBPcGVyYXRpb25zMRgwFgYDVQQDEw9UZXJyeSBN YW5kZXJzb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCkYWeFt1OjJ30tsKGB BQiMjfoNTDSC6JG1CpPj05eZpit0LVkMU0jrtrHczcRzMuqdkaE/QTBjmprbRatlrMEq7uv+ yU9U35crRmjx3yuZDD/6SOO4ZnMFBJvWdevSOWq+8wU4hAEANOnBirYCfF4oixVCBy1bkat1 hsY5xUx5QB12OpnYA0/57QJ6BL7z1ZuF6lJ4yYmU0qI88q9atkahb8l7Nm5TgEbpg6ryyN98 ixnFLmhC/gPoYKHczP3y+JHaMveuJl75hHq6ZuHeH2PyX20VFsXNBKJrvZ8BhTZOoozuNapP jiG6HLdqngPuTz3JVyTTR2FX809nclnxoMWjAgMBAAGjggNoMIIDZDAfBgNVHSMEGDAWgBQV ABIrE5iymQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUs8L0dmF6T/V40vXJJzF+YNyzNo0wJAYD VR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6Ly9j cmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMDigNqA0hjJodHRw Oi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDCCAcUGA1Ud IASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEWLmh0dHA6Ly93d3cu ZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggrBgEFBQcCAjCCAVYe ggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABpAGYAaQBjAGEA dABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBuAGMAZQAgAG8A ZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABhAG4AZAAgAHQA aABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBtAGUAbgB0ACAA dwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABhAG4AZAAgAGEA cgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIAeQAgAHIA ZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN AQEFBQADggEBAGKcMSvyr3YW8kKqyqdspTEKTc6lR6H6OITyC056f6PlMmFZ+nWlkopWlflz QcxOUZv3+5rNogNcwczrxr+eaSx9J+pYCEU3rgBs3yiLDwsD72EJJDAD1x84fQOOJtfYb4oE 4Djzco83Dk4h6sMAiUg0xGcdewhJK80D6tb3xtS75PgFoxLcQrBprLghx2mY8EPErBiO1uXA NWOEU3EH+kvXiKUrDsFyGHQ4FqvVIYv2plu68ltOmBh+wR2oraoJpt9jGbond1MyVFOvi48e 7hgPRXupNbjxB4Wl0wKKGz0qT3ToBpp8VAkULtjiO/iPLx4knuwwvy5sRAwuZAfpVE4xggH/ MIIB+wIBATB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNV BAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJ RCBDQQIQCdH8WGGFd+ltZ41MsFbVvDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFB/8 +oYeEdVBUJio6a1d6Q1XKbWiMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE2MDMxODAwNTUwM1owDQYJKoZIhvcNAQEBBQAEggEAWkyRQVlDTb1VClEScXn0 kd8DjiH63Pe2INgNgjX+5LPBd2v2pLKYH7xgKMvKRxIV9a6sRg7fkLin9lvJ9KUAM0tbNBeS Wk2lGbd+azMoLZY2YUFl0uGVFfo0lnw4thwRI4Z8KmsNlkLacFFhAWyhSdUTF6KN+apaVhjX x9gbJhN23+J+vDOJqpyfHWC8jwQXcbF9tbEdm7B3CsRuE4+kTScNlQJaldF9eA6nV8pZ+/BC lEot/4FAh7Vzr9BckydGeuPpqkH+9itWQCQxwX47yqfuGgG4igFSvMlbsva6HHOBDgIBM7Vc HhUfS3DCPi+mKqCGA3jpwSlLYxraS/jPxw== --B_3541143303_44088962-- From nobody Fri Mar 18 06:58:35 2016 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B216412DA15 for ; Fri, 18 Mar 2016 06:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 oWyybYd5yFms for ; Fri, 18 Mar 2016 06:58:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA33812D903 for ; Fri, 18 Mar 2016 06:56:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CGH81119; Fri, 18 Mar 2016 13:56:56 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 18 Mar 2016 13:56:55 +0000 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0235.001; Fri, 18 Mar 2016 06:56:50 -0700 From: John Kaippallimalil To: "mif@ietf.org" Thread-Topic: request for review: draft-mccann-dmm-prefixcost Thread-Index: AdGBHgP79adFraf2Rgavq4/hHleNLg== Date: Fri, 18 Mar 2016 13:56:49 +0000 Message-ID: <6561EABF52675C45BCDACA1B4D7AA1171DB6D7C3@dfweml501-mbb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.159] Content-Type: multipart/alternative; boundary="_000_6561EABF52675C45BCDACA1B4D7AA1171DB6D7C3dfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.56EC0928.00E0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b147fa78d7a0786ffe9c336dc3dc1b99 Archived-At: Subject: [mif] request for review: draft-mccann-dmm-prefixcost X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 13:58:33 -0000 --_000_6561EABF52675C45BCDACA1B4D7AA1171DB6D7C3dfweml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, This is a request for a review of the draft in dmm, "Communicating Prefix C= ost to Mobile Nodes"https://datatracker.ietf.org/doc/draft-mccann-dmm-prefi= xcost/ This draft was presented twice in dmm, and Brian Haberman suggested that we= get reviews from 6man and mif. The draft proposes an prefix-cost sub optio= n in RA to indicate the cost of maintaining the IP connection segment betwe= en host and access router. This can allow a host to select /attach to acces= s connections with lower cost. Abstract: In a network implementing Distributed Mobility Management, it has been agreed that Mobile Nodes (MNs) should exhibit agility in their use of IP addresses. For example, an MN might use an old address for ongoing socket connections but use a new, locally assigned address for new socket connections. Determining when to assign a new address, and when to release old addresses, is currently an open problem. Making an optimal decision about address assignment and release must involve a tradeoff in the amount of signaling used to allocate the new addresses, the amount of utility that applications are deriving from the use of a previously assigned address, and the cost of maintaining an address that was assigned at a previous point of attachment. As the MN moves farther and farther from the initial point where an address was assigned, more and more resources are used to redirect packets destined for that IP address to its current location. The MN currently does not know the amount of resources used as this depends on mobility path and internal routing topology of the network(s) which are known only to the network operator. This document provides a mechanism to communicate to the MN the cost of maintaining a given prefix at the MN's current point of attachment so that the MN can make better decisions about when to release old addresses and assign new ones. BR, John --_000_6561EABF52675C45BCDACA1B4D7AA1171DB6D7C3dfweml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

This is a request for a review of the draft in dmm, = “Communicating Prefix Cost to Mobile Nodes”https://datatracker.i= etf.org/doc/draft-mccann-dmm-prefixcost/

 

This draft was presented twice in dmm, and Brian Hab= erman suggested that we get reviews from 6man and mif. The draft proposes a= n prefix-cost sub option in RA to indicate the cost of maintaining the IP c= onnection segment between host and access router. This can allow a host to select /attach to access connectio= ns with lower cost.

 

Abstract:
   In a=
 network implementing Distributed Mobility Management, it has

   been agreed that Mobile Nodes (MNs) should exhibit agilit= y in their

   use of IP addresses.  For example, an MN might use a= n old address for

   ongoing socket connections but use a new, locally assigne= d address

   for new socket connections.  Determining when to ass= ign a new

   address, and when to release old addresses, is currently = an open

   problem.  Making an optimal decision about address a= ssignment and

   release must involve a tradeoff in the amount of signalin= g used to

   allocate the new addresses, the amount of utility that ap= plications

   are deriving from the use of a previously assigned addres= s, and the

   cost of maintaining an address that was assigned at a pre= vious point

   of attachment.  As the MN moves farther and farther = from the initial

   point where an address was assigned, more and more resour= ces are used

   to redirect packets destined for that IP address to its c= urrent

   location.  The MN currently does not know the amount= of resources

   used as this depends on mobility path and internal routin= g topology

   of the network(s) which are known only to the network ope= rator.  This

   document provides a mechanism to communicate to the MN th= e cost of

   maintaining a given prefix at the MN's current point of a= ttachment so

   that the MN can make better decisions about when to relea= se old

   addresses and assign new ones.

 

BR,

John

 

--_000_6561EABF52675C45BCDACA1B4D7AA1171DB6D7C3dfweml501mbb_-- From nobody Mon Mar 21 08:48:45 2016 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0320912D72D for ; Mon, 21 Mar 2016 08:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ElbQHMDKtNR9 for ; Mon, 21 Mar 2016 08:48:42 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 A408912D556 for ; Mon, 21 Mar 2016 08:48:42 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id g3so219761949ywa.3 for ; Mon, 21 Mar 2016 08:48:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:date:message-id:cc:to:mime-version; bh=fgWywjVP0MWUPGZvCjQaCDWeGqzoCiGC8pwjTGJ7Muw=; b=L8gBrsP+WpVVMfBQc2dPWq9bNCtdwPfO+65y0tsxiuhOPq7EYq13BYpej9EGLgVuo3 FbEuGo9h86rYn6CarUh7Fv+JuhCNhnDoX/HMfBOcswnFAVA6AseRKk0mgOqL8saYvW5/ D8l7Lt0HPv6k0Um0yf33NVLaKWE0JjTiaoR3+NfHp2OurqDweeCPfIJtHxyrOKQ/nBv7 IomwXzZez1fFWUHZbNaP4hWXa/Zopi8Vb9hqDO1Eb2GVC9K9KCH1KKBbEf2qPy7/gqmA qH4+n9S3J3SmG+IM2ewTs6+6uH1n9YF5qz2qB/L+Q/S27ojKs3Tveopq81M7je1YBkSO xgww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:date:message-id:cc:to:mime-version; bh=fgWywjVP0MWUPGZvCjQaCDWeGqzoCiGC8pwjTGJ7Muw=; b=ePxwddLQwltZapSvy503/q3G+axRhI5ZuiPbo1IN0WF6EdP6rrZMtkoYn/hIMJ1Egm DUUrkGp4OCXTHRFInSVElhvp9w0cJtOijVfbOWssxNHWFuwvpbepwOv48qSv2iwo17ME Y4wfIkofyEQbxZrkh2sKbdgI+2RiJncMThrae65VApsVlID7dCUtlsKylZmjBf9eP8Tf QDp/UZj1vx9P4WkXtn7N4u9gOQ6zQt/BQWSc5EZtL3jF+ZY09FDuk9GnuuM8tRHBPG3G UtsiXafh4AyaiKzjavaaCIzkZFj0rD9XPaeva9935uA8L6I3bOIRD4qI3D4p5+uRWtVl AvMg== X-Gm-Message-State: AD7BkJJnfpatg5tp4H6iorssPEL/rctNWGOVFxLyu4kj8giigfGMfSYeFr0/AcBMVUZqWA== X-Received: by 10.37.68.69 with SMTP id r66mr13627460yba.14.1458575321987; Mon, 21 Mar 2016 08:48:41 -0700 (PDT) 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 x6sm16133729ywd.48.2016.03.21.08.48.40 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Mar 2016 08:48:41 -0700 (PDT) From: Margaret Cullen Content-Type: multipart/signed; boundary="Apple-Mail=_2B52FAD0-B1BC-49F6-AF62-E0303C3EA66D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Mon, 21 Mar 2016 11:48:42 -0400 Message-Id: To: "mif@ietf.org List" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: Cc: Hui Deng Subject: [mif] Agenda Time? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 15:48:44 -0000 --Apple-Mail=_2B52FAD0-B1BC-49F6-AF62-E0303C3EA66D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii If you would like to request agenda time during the MIF session at IETF = 95, please send email to me and Deng Hui (cc:ed above) as soon as = possible. Please be aware that agenda time is only available to discuss drafts = that have been submitted before the meeting (the cut-off is today) or = topics that have been discussed on the mailing list. Also, the WG = Chairs will review all presentations with the presenters in advance of = the MIF slot. I hope to see many of you in Buenos Aires! Margaret --Apple-Mail=_2B52FAD0-B1BC-49F6-AF62-E0303C3EA66D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJW8BfaAAoJEJrxOXzI3ic/BrAIAKRFB29BIn8qoWtbllxFz2Um B547pBsDA7vbSGcRA9QM6ETfEGZ73U50oLNxofd08soyfNfP5hXzizGlHMMemqvZ 7vC2ld0LOKTZ6DwyMVOC4yLoFnGUZZ8cW/7h360YMOXeixy+cKRlyo76S/jGHF+3 tjDLZN4eqaVhVCCaADnoDrQnq39CTVfQYrJTp5vXTFe+42Mu+bJrDoPjXBiVB6Fa 0H6HhU8vO203u323XUMRDOrCE7lvtcwK7w1xAdIba1hiNPR7HoHsWUH4rXdrW4R0 1WXBOfc6r/rhwFCiX498e/YNe+wg+SY7hb1Je1w84G3s1wfzZE0R9Fmk+kjBGFs= =MEu3 -----END PGP SIGNATURE----- --Apple-Mail=_2B52FAD0-B1BC-49F6-AF62-E0303C3EA66D-- From nobody Mon Mar 21 09:29:27 2016 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2AE12D5BF for ; Mon, 21 Mar 2016 09:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 5ikSwstESmsj for ; Mon, 21 Mar 2016 09:29:18 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BE1C12D91C for ; Mon, 21 Mar 2016 09:29:07 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 25C59740057; Mon, 21 Mar 2016 16:29:07 +0000 (UTC) Received: from mbx-03.WIN.NOMINUM.COM ([169.254.4.19]) by CAS-03.WIN.NOMINUM.COM ([64.89.235.66]) with mapi id 14.03.0224.002; Mon, 21 Mar 2016 09:29:07 -0700 From: Ted Lemon To: Margaret Cullen , "mif@ietf.org" Thread-Topic: [mif] Agenda Time? Thread-Index: AQHRg4kojdfU5oTRlE2INEZk7cLIbJ9kFWU3 Date: Mon, 21 Mar 2016 16:29:06 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630797A41969@mbx-03.WIN.NOMINUM.COM> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.66.83.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Hui Deng Subject: Re: [mif] Agenda Time? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 16:29:25 -0000 It might be worth having a brief (~10 minute) presentation on the homenet n= aming architecture document, which has a section on the handling of provisi= oning domains in the homenet. I'll be submitting the document later on to= day; I think that what I'm putting in it regarding provisioning domains wil= l work well, but it would be good to get feedback. There's also an interesting interaction between DNSSD and MPvD that I hadn'= t noticed before: if you want services to be able to publish themselves in = the local zone, which MPvD is that? Where do they send the updates? My = current answer is that although there are different resolvers per PvD on th= e homenet, all of the resolvers will accept updates, since all updates are = by definition intended for the homenet PvD, and all of the resolvers are op= erated by the homenet, and hence capable of handling updates for the homene= t PvD. We don't want services that do updates to have to be smart about P= vDs.