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

Nick Hilliard <nick@inex.ie> Tue, 29 October 2013 22:03 UTC

Return-Path: <nick@inex.ie>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B37121F9D18 for <v6ops@ietfa.amsl.com>; Tue, 29 Oct 2013 15:03:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koMpbdHTL-aG for <v6ops@ietfa.amsl.com>; Tue, 29 Oct 2013 15:03:42 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id F001E21F9D28 for <v6ops@ietf.org>; Tue, 29 Oct 2013 15:03:41 -0700 (PDT)
X-Envelope-To: v6ops@ietf.org
Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r9TM3ZQZ025350 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 29 Oct 2013 22:03:35 GMT (envelope-from nick@inex.ie)
X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org
Message-ID: <527030B7.40206@inex.ie>
Date: Tue, 29 Oct 2013 22:03:35 +0000
From: Nick Hilliard <nick@inex.ie>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Andrew Yourtchenko <ayourtch@cisco.com>
References: <CE8E8EC3.59F3A%victor@jvknet.com> <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <alpine.OSX.2.00.1310281905440.11422@ayourtch-mac> <CAKD1Yr0qLd7syFizEUMa6DM2a2LY6Rv5GSFyoQAs4Pir6gcNkA@mail.gmail.com> <1383036443.56704.YahooMailNeo@web142501.mail.bf1.yahoo.com> <alpine.OSX.2.00.1310291443480.31066@ayourtch-mac> <1383074208.73179.YahooMailNeo@web142505.mail.bf1.yahoo.com> <alpine.OSX.2.00.1310292030450.31066@ayourtch-mac> <CAKD1Yr1myWu7BUmcP3sJqPXFtRyGhy=Qqd2yMsYBFQjPce3GUA@mail.gmail.com> <alpine.OSX.2.00.1310292040510.31066@ayourtch-mac> <527019EC.3090508@innovationslab.net> <alpine.OSX.2.00.1310292134210.31066@ayourtch-mac>
In-Reply-To: <alpine.OSX.2.00.1310292134210.31066@ayourtch-mac>
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: v6ops@ietf.org
Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 29 Oct 2013 22:03:43 -0000

On 29/10/2013 20:52, Andrew Yourtchenko wrote:
> Thanks. Not sure whether it should actually be another section or not -
> "Control plane and data plane" - RAs are sent by an entity that is in the
> path, whereas the DHCPv6 may be sent by an off-path entity...

this brings up another important issue, namely source address validation.

I'm not sure if it's relevant to bring this up in your draft, but the
requirement to handle snooping two new protocols for effective lan source
address validation seems to be more than most vendors can handle at the
moment, which means that as operators we are very exposed to rogue RAs and
rogue DHCPv6 packets flying around networks.

[Once upon a time, all we needed was vendor support for dhcp snooping and
ARP inspection.  Now we need an entire IETF working group to handle the
complication that the IETF has brought upon itself by overthinking ipv6 lan
requirements.  Is this progress?]

Nick