IETF Logo Mail Archive

Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD

Thomas Narten <narten@us.ibm.com> Mon, 23 May 2011 21:11 UTC

Return-Path: <narten@us.ibm.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99960E0851 for <ipv6@ietfa.amsl.com>; Mon, 23 May 2011 14:11:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDZn8hpqWyvM for <ipv6@ietfa.amsl.com>; Mon, 23 May 2011 14:11:34 -0700 (PDT)
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by ietfa.amsl.com (Postfix) with ESMTP id 233DEE0841 for <ipv6@ietf.org>; Mon, 23 May 2011 14:11:34 -0700 (PDT)
Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by e2.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4NKpYD8007789 for <ipv6@ietf.org>; Mon, 23 May 2011 16:51:34 -0400
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p4NLBX4e092838 for <ipv6@ietf.org>; Mon, 23 May 2011 17:11:33 -0400
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4NLBVrU010756 for <ipv6@ietf.org>; Mon, 23 May 2011 18:11:32 -0300
Received: from cichlid.raleigh.ibm.com (sig-9-65-221-88.mts.ibm.com [9.65.221.88]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4NLBUHc010513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 May 2011 18:11:30 -0300
Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p4NLBScJ013180; Mon, 23 May 2011 17:11:29 -0400
Message-Id: <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com>
To: Christopher Morrow <christopher.morrow@gmail.com>
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD
In-reply-to: <BANLkTinByCkcvd6=wLE6=9h1xLX16AhPVQ@mail.gmail.com>
References: <C9F53B85.11BE93%john_brzozowski@cable.comcast.com> <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com> <BANLkTinByCkcvd6=wLE6=9h1xLX16AhPVQ@mail.gmail.com>
Comments: In-reply-to Christopher Morrow <christopher.morrow@gmail.com> message dated "Mon, 23 May 2011 16:58:00 -0400."
Date: Mon, 23 May 2011 17:11:28 -0400
From: Thomas Narten <narten@us.ibm.com>
Cc: "ipv6@ietf.org" <ipv6@ietf.org>, Ralph Droms <rdroms.ietf@gmail.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 May 2011 21:11:35 -0000

Christopher Morrow <christopher.morrow@gmail.com> writes:

> one gotcha with 'dhcp only' is perhaps folks mean: "slaac to signal v6
> is on-net, but require full config from a dhcpv6 server".
> How does a host know that v6 is available otherwise? (this may be why
> someone said "you don't really want to do that..')

Well, if I could go back in time, I would never have defined the M&O
bits at all.

Just say that at startup time, invoke SLAAC & DHCPv6 both. Then use
whatever is available. That would have been simple and
predictable. (And avoided 10GB of mailing list discussion!)

(Hmm, maybe I should just write such a spec now, given the M&O bit
definitions are in the twilight zone anyway... Discussion of what to
do with them was effectively removed from the last revisions of the
SLAAC documents, so now there is no clear guidance on how to process
them. The IETF at its finest...)

Thomas

v2.23.0 | Report a Bug | By Email