Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt

神明達哉 <> Wed, 15 February 2017 19:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 067FD129A2F for <>; Wed, 15 Feb 2017 11:42:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 Bi7ks5KdcFVP for <>; Wed, 15 Feb 2017 11:42:31 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 356F8129A2A for <>; Wed, 15 Feb 2017 11:42:31 -0800 (PST)
Received: by with SMTP id u25so161896993qki.2 for <>; Wed, 15 Feb 2017 11:42:31 -0800 (PST)
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=TkB7KpUpC9jzYHpfDLXA5iDVrnYfe32V5v7ZBJdYtZA=; b=s9dQFFUioizL4NZ0vpJRexCaOC3i8qAFtSDR6LQTLjY9yRZ2NGwNakdAwNT8bB/WlB ZMgZa8v943+uDmnmCr6ooKDuAU8jjEQFR3S45ezH726N5E+s/UtxCeWU5Fv9lx9Bdiud k9cnscpjAEiIga42OKhi8OnRmW/x5S+ts+1rHhYnWtdzOW4EowZPswWtUGGdCMG4wfUV Lj34SdbE2fW39EULF302wN/teoCABmOyjtoIaOJF2i0EP0MuP0gQrT+7Dkd1mT01G+dR +1HTdvkLTNzeprg6gMFmA15Pdz/R/0SoEKePnPIchm7v4MSo5Crc4bD7193r+afQ7ToJ D9yQ==
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=TkB7KpUpC9jzYHpfDLXA5iDVrnYfe32V5v7ZBJdYtZA=; b=GLU+IclrJhh00VZFBhUjvxzkLl2DUk42NJFSBEkEkZ+/jJmVxayZzC1AzrcQXeoyo5 tpBJHnt719nkzOzJDyOSNlafPfnPTsirnJX5ZqbIQ6IGoa2KtAgJO1bPjJv7sCqgY+FO v3xD84lnTj+0dmd/dN6WJUT2w28TgRl0MQSbLd8lJy654gQ9mGBtlFVaLl6ChUUzIlU8 7OxmCzLu6HFzCq4p20EBwPpSk3vKTqKNSJ/ed9fSJ/bCBMx19WR/r7yzuf61yf8XZLpu 9BjqtXKi7ABCpg23HaOpXmOA1n8LAaZcdhKlisS3VM/olc/vYJO1cYKceL7Z5qjXhM3z W1Uw==
X-Gm-Message-State: AMke39marasLf87glQUaIy2m1oALi6i1HS5H/26rKrxTdOZ5udUr1TB4qSyO9sLOYRSPcIA0eSJ0fPMJqAjUbQ==
X-Received: by with SMTP id w123mr33939201qkc.20.1487187750255; Wed, 15 Feb 2017 11:42:30 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 15 Feb 2017 11:42:29 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Wed, 15 Feb 2017 11:42:29 -0800
X-Google-Sender-Auth: OvAYaXS0gxwsED8b43_5LZ3Y6xM
Message-ID: <>
To: "Templin, Fred L" <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: dhcwg <>
Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Feb 2017 19:42:33 -0000

At Wed, 15 Feb 2017 18:51:26 +0000,
"Templin, Fred L" <> wrote:

> > > > It's probably better to describe the issue in
> > > > sedhcpv6 with a reference to the RAAN draft as a possible future
> > > > solution to it if and when it's adopted and standardized.
> > >
> > > If sedhcpv6 will not support an authentication-only mode, then it
> > > can' t go forward until RAAN is adopted as a wg item. Otherwise,
> > > an encryption-only sedhcpv6 w/o RAAN would break DHCPv6 PD.
> >
> > I personally don't think it a blocking issue for sedhcpv6, but, of
> > course, the wg should decide it.
> Some uses of DHCPv6 PD require a secure exchange between the client and
> server supported by an LDRA [RFC6221] that is in the same physical stack as
> the server. The LDRA needs to peek into the server's Reply in order to discover
> the delegated prefixes for the purpose of configuring routes. This all needs to

Where in RFC6221 is that need described?  From a quick re-read of the
RFC I can't find it.  But in any case,

> work with a standards-compliant DHCPv6 server that implements both
> sedhcpv6 and RAAN. Meaning that sedhcpv6 and RAAN would need to be
> advanced together as standards.

I don't follow the logic of the final sentence.  I see this means
sedhcpv6 at least initially wouldn't work for a particular scenario
without RAAN.  But I don't think it automatically means sedhcpv6 can't
be standardized with that limitation.  It would depend on how this
incompatibility is critical for the overall purpose of sedhcpv6, and
it doesn't seem to be that substantial - we can eventually standardize
RAAN, and then update sedhcpv6 to fill the incompatibility.  I
understand you have a different opinion, but to me it's a matter of
opinion, not an only possible interpretation of this situation.  I'm
not insisting my opinion should win, of course, and that's why I said
the wg should decide it.

> Maybe better yet would be to bring the RAAN option into the sedhcpv6
> spec itself?

For the same reason I don't think so, but, again, it should be up to
the wg.

JINMEI, Tatuya