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

Andrew Yourtchenko <> Wed, 30 October 2013 23:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C00A521E80A6 for <>; Wed, 30 Oct 2013 16:41:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TuQI2fiKFAGf for <>; Wed, 30 Oct 2013 16:41:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 732F121F9E52 for <>; Wed, 30 Oct 2013 16:41:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=1696; q=dns/txt; s=iport; t=1383176504; x=1384386104; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=3Sv+YCOM6gn2A/jiNDGLFj3PZYb+07lix1eYRvKGonk=; b=WWRcotgtIu4x5ybTXunt8N6ggqyude+W5LGV1cxeGWPN7Ud3S3RlGkv8 bGi5rgNQKKNu5xJu6FM4xQHDrfE7ByabUctBKZsRm8a+s9KtJrSJAFPJG 5Kous1bpbGlVXBjAiREVCBodbvBZlqxi2Wbg7iq801t0h+JsgkD/v27n+ w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgYFAGWYcVKtJXG//2dsb2JhbABZgweBDL9igSoWdIImAQEEOAI/EAs7C1cGDogMuwKPTweELAOqE4FogVqCDg
X-IronPort-AV: E=Sophos;i="4.93,605,1378857600"; d="scan'208";a="275723471"
Received: from ([]) by with ESMTP; 30 Oct 2013 23:41:44 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r9UNfhen017978 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Oct 2013 23:41:43 GMT
Received: from localhost ( by ( with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 30 Oct 2013 18:41:43 -0500
Date: Wed, 30 Oct 2013 19:41:17 -0400
From: Andrew Yourtchenko <>
X-X-Sender: ayourtch@ayourtch-mac
To: Mark ZZZ Smith <>
In-Reply-To: <>
Message-ID: <alpine.OSX.2.00.1310301940270.57865@ayourtch-mac>
References: <> <> <alpine.OSX.2.00.1310281905440.11422@ayourtch-mac> <> <> <alpine.OSX.2.00.1310291443480.31066@ayourtch-mac> <> <alpine.OSX.2.00.1310292030450.31066@ayourtch-mac> <> <alpine.OSX.2.00.1310292040510.31066@ayourtch-mac> <>
User-Agent: Alpine 2.00 (OSX 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format=flowed
X-Originating-IP: []
Cc: "" <>, Ted Lemon <>, "Ole Troan \(otroan\)" <>, Dave Thaler <>, "" <>
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: Wed, 30 Oct 2013 23:41:58 -0000

On Wed, 30 Oct 2013, Mark ZZZ Smith wrote:

> (Disclaimer: Haven't had a chance to read the text yet)
> I would generalise the description of RAs. 
> They're not "Router Advertisments", they're Advertisements (typically) 
>from Routers, and they propagate per-subnet IPv6 parameters to hosts - 
>per-link MTU, per-link ND timers, per-link address configuration method, 
>per-link on-link prefix status, default router lifetime (if not announced 
>as zero). The can be used to propagate per-client per-link IPv6 
>parameters if necessary using unicasts.
> I think DHCPv6 is really solving the application layer configuration 
>problem, which is independent of and not specific to the underlying links 
>and network layer parameters. I think IPv6 per-link parameter setting and 
>application layer parameter setting are conceptually quite different 
>problems (I think the sets of layer parameters they provide values for is 
>one of the give aways.)

I will try to rephrase this into another section:

-- cut --
Link-centric vs. client-centric

RA traditionally provide the information pertaining to the link and its 
parameters, whereas DHCPv6 typically provides the information specific to 
the client configuration.

However, this distinction is mostly a semantic one "by convention" - 
because technically nothing prevents to put a per-client configuration 
into an RA that would be sent unicast (at this point however the periodic 
multicast RA mechanism will break), as well as use the scopes in Stateless 
DHCPv6 with appropriate blobs of data to communicate the per-link 

-- cut --

Is this an adequate representation ?