Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation - src LL vs GUA

神明達哉 <jinmei@wide.ad.jp> Wed, 18 October 2017 20:30 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 491F7133528 for <dhcwg@ietfa.amsl.com>; Wed, 18 Oct 2017 13:30:51 -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 EEIIa-rkhChH for <dhcwg@ietfa.amsl.com>; Wed, 18 Oct 2017 13:30:49 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 7D9C5132620 for <dhcwg@ietf.org>; Wed, 18 Oct 2017 13:30:49 -0700 (PDT)
Received: by mail-qk0-x234.google.com with SMTP id k123so7882902qke.3 for <dhcwg@ietf.org>; Wed, 18 Oct 2017 13:30:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=aisuwFenq51Nio7kNO5/rv9nK/oWHSQwP6GfnrGjmL4=; b=VxjMYZOBudYmDLX8MkK8hafFN0x4RorrUJ9SFWC7ufRqTBjlEy0S7LgYVS7cRqpn5i U4lPa+AIFhCkF/cDS11eiNC1afFKoQmVCIc/26qZ3IBEEawD9QJp57T+7ADTaobYK3hV GtsOSWAYRvhj/4NDhCbllsFeG2G163atePGXurI8/4MRNlp/hPbUKv8dOUu8nNgCGKet 07VyFlLIrnCHE8vZmfkJ47/BACBA6raXNakuZ8SUAMLneIMAQwMOEFDHRwH3tiRIpEyQ y1VysvuoR2Kh0kIlGK40Ax8Rs11hpOH5pe3yFPihE4mxyDQ2sWNlYoosZnsXo39dwMY4 R4rw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=aisuwFenq51Nio7kNO5/rv9nK/oWHSQwP6GfnrGjmL4=; b=UAamJwAjkK9T6QVjEzpTI1gWPltY0hpzwp8/qYypOf09DEwvH5+r2e0xAVHXWXjO4N onBhcCzKCSy18A5py56ucdKEVjCsywCR7gBslH5mlZTCh2MS+c5uc5eWBbraj0vqpmQG hNkeTvUy7yZ3G4bJmIW98I5yuhkCEKiSuRjoRbxhepbx2yXBOsn/mWdHX9R0OZQL2P1u wSoqBLlivz2rcS1L5sTN0sFN8grv71uoUqP6rLzWhwukAh30xBgrv82YfPNZD2PXJrHk FxU5j55oHulu75uvmBu6/AxXEagbki/AYN/yJUVBG/hbqnGDYxqCOJ65lAeiFXncoWNR 7Cwg==
X-Gm-Message-State: AMCzsaWGSgJtLFj0j1tICR5GKxdFsLtXgTriOK5rEW8e8en6Tb+hCAJZ g1AxmjpbJRLk0TrLmcZ2W3ONKDVoV+jkVvmZ9gc=
X-Google-Smtp-Source: ABhQp+T4WBUB41STgh+4ReTpc0PlwTFxpGJDzxR9IDkUR/xcuP1JPwDX35c8EsI8j91jiWrOOE8Ibc4Aw8rF2z/hkUE=
X-Received: by 10.55.50.71 with SMTP id y68mr4380952qky.136.1508358647564; Wed, 18 Oct 2017 13:30:47 -0700 (PDT)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.237.61.137 with HTTP; Wed, 18 Oct 2017 13:30:46 -0700 (PDT)
In-Reply-To: <d0d848dc-8b56-fbf7-0c05-7584ca0a4387@gmail.com>
References: <149869621720.6575.278128190348174876@ietfa.amsl.com> <08e4e953-3a68-d6cb-6066-f60514ef0ac5@gmail.com> <3285281858d043649d507b6bda7b8646@XCH-ALN-003.cisco.com> <1f94b780-59c1-42ce-936d-0c8a71143444@gmail.com> <37917a26062f4e4c9715d324604e4d01@XCH-ALN-003.cisco.com> <d944ac55-d67d-d7d4-8eeb-f60438fdda2d@gmail.com> <35558A79-C176-4D71-9E91-4BDB19DDD006@cisco.com> <67ba54d2-d53f-82bf-93c9-1b92631ef4e8@gmail.com> <86409a9acb7846ddbdff42c58328e7d6@XCH-ALN-003.cisco.com> <eccd5dd2-3542-fdbc-89a2-7d13d563163d@gmail.com> <CAJE_bqdruffgx6D16JXevMvh9K2-j37m=g3rR=rmAPH+u-on0Q@mail.gmail.com> <d0d848dc-8b56-fbf7-0c05-7584ca0a4387@gmail.com>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Date: Wed, 18 Oct 2017 13:30:46 -0700
X-Google-Sender-Auth: ltNmyHxarGZR3k_WwryBqJJQX0o
Message-ID: <CAJE_bqc2AtaVkgurxEA9dyKuPoc2+_fXUGLEnTKVzyi18GR9xg@mail.gmail.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, "Bernie Volz (volz)" <volz@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/Fe2YZL_YgfSo3pmSB4865BFNck4>
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation - src LL vs GUA
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 18 Oct 2017 20:30:51 -0000

At Wed, 18 Oct 2017 22:03:26 +0200,
Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:

> >> But I need guidance to the following question: if the Client sends
> >> a Solicit with a LL in src, MUST the Server reply to it?  (yes/no
> >> is the needed guidance).
> >
> > I don't see the need for such guidance, at least as part of
> > rfc3315bis.  What's your problem if we didn't have such guidance in
> > normative text like a "MUST"?
>
> The problem is the following: exchange between Client and Server does
> not work.  CLient believes it needs to send LL in src, whereas Server
> believes the Client should use GUA in src.  There are other fields on
> which the problem may reside (port number, IA_ID, and others); each
> needs separate treatment.

To me, it's just that the server implementation is broken.  Unless the
protocol specification explicitly imposes a limitation on the type of
source addresses it shouldn't assume a limitation and refuse to accept
packets that don't meet its proprietary assumption.

Now, the question is whether a protocol specification needs to
explicitly say that a server MUST NOT have such an assumption.  I
simply don't think so - we can't just add nearly obvious statement
just because there is some broken implementation.  I wouldn't be
surprised if there is a broken DNS server implementation that doesn't
respond to a query from an IPv6 link-local address, but I just don't
think we should write an RFC that has "a DNS server MUST NOT drop a
query from a link-local IPv6 address" just because of such a broken
implementation.  This case is no different from that to me.

You seem to think it's worth noting in the protocol spec, but as far
as I can see you have not successfully convinced the wg about the need
for it.

--
JINMEI, Tatuya