IETF Logo Mail Archive

Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance

Nick Hilliard <nick@inex.ie> Thu, 09 January 2014 19:11 UTC

Return-Path: <nick@inex.ie>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD701AE005 for <v6ops@ietfa.amsl.com>; Thu, 9 Jan 2014 11:11:26 -0800 (PST)
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] 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 MaQdxUViD1dG for <v6ops@ietfa.amsl.com>; Thu, 9 Jan 2014 11:11:24 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id C65901ADFB2 for <v6ops@ietf.org>; Thu, 9 Jan 2014 11:11:23 -0800 (PST)
X-Envelope-To: v6ops@ietf.org
Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id s09JB5bx088019 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 9 Jan 2014 19:11:10 GMT (envelope-from nick@inex.ie)
X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org
Message-ID: <52CEF448.4020900@inex.ie>
Date: Thu, 09 Jan 2014 19:11:04 +0000
From: Nick Hilliard <nick@inex.ie>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Mikael Abrahamsson <swmike@swm.pp.se>
References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <CAKD1Yr1i56skSnw+MzuYWsf97MwCfavgu2ADm5PyQBQSq4u+KA@mail.gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7@nkgeml506-mbx.china.huawei.com> <CAKD1Yr0RgsL5sF-p_yNKEtCuXC-cTxO3MAZU9fzPFGoACXuRkA@mail.gmail.com> <alpine.DEB.2.02.1401090702210.20074@uplift.swm.pp.se> <CAKD1Yr2kxL_TcTXshAu-US4ZHuKhpYza95PK6m=5PJ2juYDT_A@mail.gmail.com> <alpine.DEB.2.02.1401090758240.20074@uplift.swm.pp.se> <CAKD1Yr0TnG5Ncc-0CaLY_+x-NGJpeGKpH92ssNDBcBz4Xw-z+g@mail.gmail.com> <52CEC7E4.8060103@inex.ie> <alpine.DEB.2.02.1401091942350.20074@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.2.02.1401091942350.20074@uplift.swm.pp.se>
X-Enigmail-Version: 1.6
X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804
X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3
X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee
X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24.
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org, "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2014 19:11:26 -0000

On 09/01/2014 18:44, Mikael Abrahamsson wrote:
> what else would it do?
> 
> I get zero hits on the word "netmask" in RFC3315. DHCPv6 will hand out
> addresses, which in IPv6 implicitly is a /128?

It's context / configuration dependent.  If the interface already has an
address+netmask configured which contains the address received from DHCP,
then local connectivity will work just fine.

This necessarily will lead to either mealy-mouthed expressions like "may
work, or may not", or else further qualification of when and how it may or
may not work, maybe, depending on what the implementer did.

I'd suggest it might be better not to have the phrase at all.

Nick

v2.23.0 | Report a Bug | By Email