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

神明達哉 <> Wed, 18 October 2017 20:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 491F7133528 for <>; Wed, 18 Oct 2017 13:30:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.4
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EEIIa-rkhChH for <>; Wed, 18 Oct 2017 13:30:49 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7D9C5132620 for <>; Wed, 18 Oct 2017 13:30:49 -0700 (PDT)
Received: by with SMTP id k123so7882902qke.3 for <>; Wed, 18 Oct 2017 13:30:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id y68mr4380952qky.136.1508358647564; Wed, 18 Oct 2017 13:30:47 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 18 Oct 2017 13:30:46 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
From: 神明達哉 <>
Date: Wed, 18 Oct 2017 13:30:46 -0700
X-Google-Sender-Auth: ltNmyHxarGZR3k_WwryBqJJQX0o
Message-ID: <>
To: Alexandre Petrescu <>
Cc: "" <>, "Bernie Volz (volz)" <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation - src LL vs GUA
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Oct 2017 20:30:51 -0000

At Wed, 18 Oct 2017 22:03:26 +0200,
Alexandre Petrescu <> 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