Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem

Victor Kuarsingh <> Thu, 24 October 2013 05:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AFE3311E813F for <>; Wed, 23 Oct 2013 22:57:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.901
X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5h40gPec42hn for <>; Wed, 23 Oct 2013 22:57:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4FA4911E8132 for <>; Wed, 23 Oct 2013 22:57:13 -0700 (PDT)
Received: by with SMTP id at1so3139791iec.15 for <>; Wed, 23 Oct 2013 22:57:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=rCx510k5dJ03Y/1a19efsCl8JtvN2TOA+Gb5LT9G08k=; b=Vb3KTRLZwuX2lQ/vtxQ6wu6/3XEPfHbZvS280LQs5/MuO7OMJw6Jg5coVMN4a4ISHf mMgoUjRpkXkMZCGe7BcL4OnXY0U1mLI9nq7VlUJ94PJG7ajr6CCizFzntq4bh01A/KXE EHhWq8AWQuJpjgkUehsArBpzZLWZb/CE3SRiTDiQh7NwsqRHlSV/u7/OQmIQf9HRmbP0 WLuFTNO4ZdX8LUr47CzwTGRijlMs+QmoYhPxEuRQhs+aA5yjy2qhO/b6N1L7QwtIGHNb I/auKtmPgWg3HasIHIEV4xQEw8oH3cH9Li6a/eM8Ag3S5qZQ3oKdfcHyAPhpma92gPuP LadQ==
X-Gm-Message-State: ALoCoQnpAhrtbi3eZwXlnfWdarUa17Qe0vYv2IYYgG7IXr3HArjgk824GWCq25k7HOlJstOeZdZP
X-Received: by with SMTP id nt7mr468249igb.13.1382594227070; Wed, 23 Oct 2013 22:57:07 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id k6sm10511014igx.8.2013. for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 23 Oct 2013 22:57:06 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/
Date: Thu, 24 Oct 2013 01:56:58 -0400
From: Victor Kuarsingh <>
To: Nick Hilliard <>, Mark ZZZ Smith <>, "Ole Troan (otroan)" <>
Message-ID: <>
Thread-Topic: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: "" <>, "" <>
Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Oct 2013 05:57:20 -0000

On 2013-10-24 12:15 AM, "Nick Hilliard" <> wrote:

>I know what RAs are.  Both protocols provide info to network hosts
>necessary for functional ipv6 connectivity.  They have different
>approaches, but they are both lan configuration protocols.
>If you feel that SLAAC+DHCPv6 or SLAAC only is the right thing for you,
>then that's great and I'm really happy for you.

There seems to be folks talking about very different environments, and in
some cases attempting to make arguments which don't address the comments
of the other side.

I understand Nick's point.  Coming freshly off a long sting at an ISP, I
see the value (if it can be done in a sound technical manner), of having
the * option * of a clean deployment for addressing and supplying IP
related configuration information to the end host/router.

This is not saying that it applies everywhere.  It's quite obvious that in
environments like sensor nets, home nets and other places, SLACC/RAs
supply significant value.  In other areas, like an operator access network
(edge element addressing), it's a different case.  Operators, such as the
one I worked or, would never (rarely?) let an element auto-configure
itself onto the network.

I think there may be valid uses cases where, if feasible, there is
perceived value is operating in DHCPv6 only mode.  Of course, in many
environments, DHCPv6 alone is not a good idea (example, my IPv6 light bulb)

In the case of client functionality, in those highly controlled access
network attachment areas, it is expected that the client (router or host)
has a certain level of functionality (and often times this can be
enforced).  So it's reasonable to expect DHCPv6 client functionality in
some use cases. 

>There is a tiny amount of protocol glue missing which would allow dhcpv6
>act as a fully functional standalone protocol, and the various attempts to

If this can be done, without harm to other environments, and achieve it's
goals for those who want it (I.e operators who see a need and can
articulate the benefits it will supply in network management and
operation), I don't see why we are unwilling to discuss it's technical

>None of these points address the core issue which is that there are a lot
>of operators who have a strong preference to use a single lan
>protocol instead of two protocols with strongly overlapping functionality
>and an ambiguous and poorly defined interaction model.

I do wonder how many operators will ask for this?  My concern is that if
there are not too many raising their hands now, it may be that they either
don't care, or if they are way behind in IPv6 deployment, they may not
know that they care yet.


Victor K