Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue

神明達哉 <jinmei@wide.ad.jp> Mon, 02 May 2016 17:45 UTC

Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 410C612D134 for <dhcwg@ietfa.amsl.com>; Mon, 2 May 2016 10:45:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level:
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 oXNp6OxExN8O for <dhcwg@ietfa.amsl.com>; Mon, 2 May 2016 10:45:34 -0700 (PDT)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 75DD012D130 for <dhcwg@ietf.org>; Mon, 2 May 2016 10:45:34 -0700 (PDT)
Received: by mail-io0-x22d.google.com with SMTP id u185so204472175iod.3 for <dhcwg@ietf.org>; Mon, 02 May 2016 10:45:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-transfer-encoding; bh=U+GhQrnaLc55GBxYkV4M3+yd1DNXt4rmDNyF/zVVcqs=; b=uqs/+cYpkZXEZ/aobb5Okb6Qiw1KgIRk45BpaXEDJlQm9og4jrEoTOZ8k5w1orbeCM O/2O4srAfSQss32SmUwcKoFc7T/sHCqgj+H8IkcaQ4EWQBHEdJugwr22O8wBn2gs+hD3 hJ3a7Dnu9drcjEjLM+zGEsSSl14/ZekVaVeSv2n3xKwB4MeIUsjxkUYQoKI1vr4UYEEv cUw6LI9Bo7JHROkPZoAu9GvjJTcrgGy2o2y7x0zHeHMionmYPEDfwibzRsurlYoGLfcp 9JKaOmhOl+KUcpnojMuabTfcVDJBs4zejjnHd46kNwuwZtaNOHSuVg9RJM2hc5MjVls8 twXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=U+GhQrnaLc55GBxYkV4M3+yd1DNXt4rmDNyF/zVVcqs=; b=UevHRhgJ/wDyKfhJRF5xQ3Q1zVhp1uJhb0z9gFRP9lxsGWmTjJOWNojMvwrLDE2Koj och6NK/dFMhfMdcgjdKN8KT/SjDUNnuLQrupGYxT5nxy8wSi+W1oWzlfB+8noxPvPddW xdhwpbmzYhNlGqj8UA2u0p2z+pOS+zlr+YRNWnmgOvI9zN8lxiw4DNl2o6OqdcC07dcj cdmNS/I4ENt1obB6yC8A6x6ASBQM7z2hnxb+PeIIQpVWQHaYKQ3Rrx/eAeItXXFyaUUV XrAfwOod7OZ6m1HYS2uKbgPPQjLjFgoLlVkPtWSfu1uxO+9ZM8qAXWBpdI/9fKoLrEl1 aGNg==
X-Gm-Message-State: AOPr4FW+Ubc+J05w0Ltt02lZPN11xFAtNUicOQnM0z+mpSxnqDSmQblUOUzesCPpqyr4zJ9A+MQzKvRposIAQA==
MIME-Version: 1.0
X-Received: by 10.107.58.213 with SMTP id h204mr44682097ioa.172.1462211133781; Mon, 02 May 2016 10:45:33 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.19.218 with HTTP; Mon, 2 May 2016 10:45:33 -0700 (PDT)
In-Reply-To: <CAFx+hEMmAbEPq6F_Uh4x5jX7pLXyO7pjaq8_DB+dhQhQUpXBJw@mail.gmail.com>
References: <0a8817dba2ea46c88ca67334a11c956d@XCH-ALN-003.cisco.com> <CAJE_bqedsyBNLscViu+C9JSRm0sDtnGBjk+4SCPtZ5cKnDanYA@mail.gmail.com> <CAFx+hEMmAbEPq6F_Uh4x5jX7pLXyO7pjaq8_DB+dhQhQUpXBJw@mail.gmail.com>
Date: Mon, 02 May 2016 10:45:33 -0700
X-Google-Sender-Auth: -I4V20-N6aLauTQCl6vbk_Yw72w
Message-ID: <CAJE_bqeX6TbKgGHSi_k5+R6ML+b7uhm5h_N9e3R5q45jKuAjbA@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
To: tianxiang li <peter416733@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/Qv6RcYCsJl1zE6U9CCxxwxDuyvU>
Cc: dhcwg <dhcwg@ietf.org>, "Bernie Volz (volz)" <volz@cisco.com>
Subject: Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 May 2016 17:45:36 -0000

At Sat, 30 Apr 2016 09:51:02 +0800,
tianxiang li <peter416733@gmail.com> wrote:

> Thank you reviewing the document and providing your comments. Unlike other
> hints such as T1 T2 lifetimes, which could be easily ignored by the server,
> completely ignoring the prefix-length hint would cause some functional
> issues for the client, how the prefix-length hint should be handled is a
> bit more complicated, and it should be given more considerations. We
> believe there is actual requirement for some ISPs to clarify how it should
> work, and understand the expectations of the client and server. E.g. If a
> server has an existing binding for a prefix length different from what the
> client is currently requesting, what should it do? This is the case when
> the client changed its home router configuration and it needs a shorter
> prefix. Also, if a client didn’t get the prefix it wanted, should it
> continue to ask for the preferred prefix (during Renew/Rebind)? Or should
> the server remember what the client originally requested, and assign it a
> new prefix if it should become available? These are some issues we are
> trying to clarify in the document, so that servers which DO want to
> understand the client’s actual prefix requirement, would know how the
> prefix-length hint should be handled, to make it work well. I'm not sure
> whether there is the same problem for addresses, it might be something
> worth discussing.

The above statement basically seems to be a statement of what's
written in the draft.  So the "problem statement" still seem to be
artificial to me.  Is there actually a service provider that is
willing to behave differently depending on the hint prefix length
specified by the requesting router, for example?  If there's such an
operational case, I see the need for the clarification.  But I've not
heard of such a practical motivation yet (it's quite possible that I
simply don't know it especially most of other wg members don't seem to
have this question.  so I'm happy to be corrected).

--
JINMEI, Tatuya