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

Victor Kuarsingh <> Thu, 24 October 2013 20:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9757311E8196 for <>; Thu, 24 Oct 2013 13:45:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.918
X-Spam-Status: No, score=-2.918 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FcgKv50RO987 for <>; Thu, 24 Oct 2013 13:45:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D159A11E8392 for <>; Thu, 24 Oct 2013 13:45:21 -0700 (PDT)
Received: by with SMTP id tp5so5041265ieb.30 for <>; Thu, 24 Oct 2013 13:45:20 -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=cp5QSi4h29F41Fepbft6PiP+79aanX8o+cr3/SHq6Uo=; b=HYJGJpRiA03m3WcDcy+6DtPHUJ2ZsFxtlAoN0gu4FZNGIs3jDoKJG7IzbMbKrfAc9F M2S518nVBcicwt6GmCXSjKMK6b6OGUL7YF2y0iHqVpqDNXQlRGFFZzmfABgXI1g8zy7S FuqugdhlRp8JIsVq8JvZgXxsf+7POiFnNpsmgewNAtDI+D2KXHIuosCscCtJ7ae0m+i4 /XL7Jj/2Kixh+mSKSOiKF+Ry3x6P9kHjhc1paj1t6eJTOvX/W2YDe6i5xQVl//nec0ax C1AY1wIdpUb8wL6cq56fRO6JcymDRkDkhzaaEk0H1jpglLAI43qNd6fASnThKXZ6OA1a rlZw==
X-Gm-Message-State: ALoCoQlIquG3Ny5UN1LTsMx0B2Ye6jFqrnhWMUZEjWmKFHmnULBMkGwxpvdgu7fUC5i+iju/Puca
X-Received: by with SMTP id c13mr3220731igd.55.1382647520364; Thu, 24 Oct 2013 13:45:20 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id q6sm407588igi.0.2013. for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 24 Oct 2013 13:45:19 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/
Date: Thu, 24 Oct 2013 16:45:15 -0400
From: Victor Kuarsingh <>
To: Mark ZZZ Smith <>, Nick Hilliard <>, "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 20:45:30 -0000


On 2013-10-24 3:44 PM, "Mark ZZZ Smith" <> wrote:

>RAs should be limited to configuring layer 3 IPv6 parameters only,
>solving the network layer configuration problem, on a per link/subnet
>basis. Different links can have different layer 3 parameters, so the
>place to provide those parameters is on a per-link basis, using a
>link-local protocol.
>DHCPv6 should be limited to providing primarily application parameters
>(and perhaps layer 4 parameters) to hosts, solving the end-to-end
>configuration problem. This problem exists regardless of the network
>layer parameters, and the parameters for applications are not restricted
>to being subnet specific, they're more likely to be global across the
>network, so a solution needs to be subnet/link-local protocol independent.

I am not arguing against these points, but have a few questions and
comments to this approach.  Based on the approach above, it appears that
in the model you describe, DHCPv6 would not provide layer 3 addresses to
end hosts (from the position of many operators, that's the first router or
host behind their access facility).

It this in fact what you are thinking, I believe there are a number of
issues that should be considered to that approach (if this is not what you
are describing, then ignore my next few statements).

Pushing addressing to the operators edge would effectively decentralize
addressing in large operator networks.   This may introduce significant
challenges for those operators (often managing millions of endpoints).
Also, pushing more work the the edge routers should be done with caution.
Edge routers are already becoming bogged down with code, and adding more
state and/or work for that device can exasperate this issue (sometimes it
takes months to over a year to get a code drop which can actually be put
into production).

Pushing the configuration to a centralized function like DHCP has definite
advantages in larger operators environments, providing the ability to
manage very large infrastructures.  It also provides them an ability to
standardize addressing across many different access types and/or platform
versions.  If we push this function to the edge, then we will need to
chase many vendors constantly, to keep up with the needs of this function.

Keeping the edge simple, and allowing the centralized functions to take on
the task of addressing and administering many of these configuration
functions makes the infrastructure much more manageable (and in my
experience, more stable which translates into a better user experience).

Of course, I am only talking about one (significant) use case, and any
changes and/or agreement on what to do with DHCPv6 and/or RAs needs to
take in to account all the use cases.


Victor K