From cb.list6@gmail.com Sun Jan 5 07:00:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4301AEA80 for ; Sun, 5 Jan 2014 07:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.96 X-Spam-Level: ** X-Spam-Status: No, score=2.96 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.886, RAZOR2_CHECK=0.922, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m__3FxtMzVf2 for ; Sun, 5 Jan 2014 07:00:07 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD171AEA7F for ; Sun, 5 Jan 2014 07:00:07 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hm19so1971872wib.13 for ; Sun, 05 Jan 2014 06:59:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=KsSym3B5UnLwoFk7ceOVZtmRJfUB7TQra4mp1NBrf5w=; b=W3uNfd3zGYuoEkQbTPWOg9R6GmvJWQVb+ThsE2OHODFwyUNEnaCKPlYp6KrndMn1u3 v16YGGAOiT1WXWlwyBQ4VhEVo6Ou1dcvUKaXKeBu2xj0MlVukNlTXmCtRL3AfL4aY+Na IsEloH9LD2TNBA0fgqbSkY71ZNX4gGfG0ozZBDEB9t7ktdhnua9SwejJ90i5sXjlGWDi Etv/pi/oZaxFTGAdbXGklTb5dSa/AUDMwiAAAIrLJRWNgPodEjaW4+wenXxdeBgjJc1I J82Bk5tl5WN+DzZSD5fULMjo1kn45IthPBMNlI7Gh2h5N00H4nZsUIHxxZllwyIr1Kk7 5pkA== MIME-Version: 1.0 X-Received: by 10.194.178.135 with SMTP id cy7mr14044855wjc.21.1388933998615; Sun, 05 Jan 2014 06:59:58 -0800 (PST) Received: by 10.217.58.133 with HTTP; Sun, 5 Jan 2014 06:59:58 -0800 (PST) Date: Sun, 5 Jan 2014 06:59:58 -0800 Message-ID: From: "cb.list6" To: IPv6 Ops WG Content-Type: multipart/alternative; boundary=089e013d1dd49aa1f604ef3a65f1 Subject: [v6ops] Updated draft-byrne-v6ops-clatip-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jan 2014 15:00:08 -0000 --089e013d1dd49aa1f604ef3a65f1 Content-Type: text/plain; charset=ISO-8859-1 Hi folks, I have updated draft-byrne-v6ops-clatip-01. From Vancouver, i took the feedback that the main message of this draft should be that we are generalizing the reservation 192.0.0.0/29 from only DS-lite to any IPv6 transition technology that does not require putting packets on-the-wire, yet needs to provide a locally unique ipv4 address to a local host. Please have a look, and let me know if we can move this forward as a WG document and then finally IANA action. http://tools.ietf.org/html/draft-byrne-v6ops-clatip-01 Thanks, Cameron --089e013d1dd49aa1f604ef3a65f1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi folks,

I have updated draft-byrne-v6op= s-clatip-01.=A0 From Vancouver, i took the feedback that the main message o= f this draft should be that we are generalizing the reservation 192.0.0.0/29 from only DS-lite to any IPv6 transit= ion technology that does not require putting packets on-the-wire, yet needs= to provide a locally unique ipv4 address to a local host.

Please have a look, and let me know if we can move this forward a= s a WG document and then finally IANA action.

http://tools.ietf.org/html/dra= ft-byrne-v6ops-clatip-01

Thanks,

Cameron
--089e013d1dd49aa1f604ef3a65f1-- From leo.liubing@huawei.com Mon Jan 6 00:00:00 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B40D1ADFF8 for ; Mon, 6 Jan 2014 00:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWq043CbByd1 for ; Sun, 5 Jan 2014 23:59:58 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CB2D41AC4C1 for ; Sun, 5 Jan 2014 23:59:57 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCE27591; Mon, 06 Jan 2014 07:59:48 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 6 Jan 2014 07:59:21 +0000 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 6 Jan 2014 07:59:47 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.72]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Mon, 6 Jan 2014 15:59:40 +0800 From: "Liubing (Leo)" To: "v6ops@ietf.org" Thread-Topic: DHCPv6/SLAAC Interaction Operational Guidance-//RE: [v6ops] new draft: draft-liu-v6ops-dhcpv6-slaac-guidance Thread-Index: AQHPAXeVQmo1lyuCJUK4K/NdSAAP8pp3YWwg Date: Mon, 6 Jan 2014 07:59:39 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> In-Reply-To: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 08:00:00 -0000 Hi Dear All, In ietf88 meeting, we discussed draft-liu-bonica-dhcpv6-slaac-problem which= indicated the hosts' behavior might varied on DHCPv6/SLAAC interaction cau= sed by ambiguous standard definition. (The draft was adopted as ietf-v6ops-= dhcpv6-slaac-problem after the meeting.) Since the above draft is only filed as a Problem Statement document, as dis= cussed in the meeting, the WG decided to initiate another draft to provide = some operational guidance of what the administrators should do given the fa= ct that the host behavior might varied in some situations.=20 So this is the 00 version. Hope you can read it and comment. Your review and comments would be appreciated very much. And a late happy new year to you all. Best regards Bing > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of fred@cisco.com > Sent: Wednesday, December 25, 2013 9:45 PM > To: v6ops@ietf.org > Cc: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org > Subject: [v6ops] new draft: draft-liu-v6ops-dhcpv6-slaac-guidance >=20 >=20 > A new draft has been posted, at > http://tools.ietf.org/html/draft-liu-v6ops-dhcpv6-slaac-guidance. Please > take a look at it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From sarikaya2012@gmail.com Mon Jan 6 12:24:19 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF631AE1F8 for ; Mon, 6 Jan 2014 12:24:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0EuGKFxxXjC for ; Mon, 6 Jan 2014 12:24:17 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id 643D61AE1FD for ; Mon, 6 Jan 2014 12:24:17 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id x18so10308804lbi.11 for ; Mon, 06 Jan 2014 12:24:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=XbKDxF0JhH0YHmlANpBsqCeiIK844ZV29qvz9zBPEbI=; b=Vk0HaKF0Udjz2lccZP2UWIP/bS/bTmWkX8dO7AbmKae/TatalHxW5935c+3uZn2Jka Q5E0l/QdGTy7CS2arhWYnMMuPmz9G+7CNMu++zBLOAzZkjULPIJ1hPxgmOg2w05b/4NK BVT2FebNtZ3ptB8wqmmXjc+7+x9k69BmBnP9egU2N3NfrRCG8nBRuvK/kSJ3CkvuiXFu vfGocEMNzyI1RcaJRFWDNmfDcqHuaoY2695U48KaXXDvm7S3wwNlaC7lxNfbqfTiXjfd 6DGDnaCQ4TOqfkZbrNciZMduACBh8ILeiP4M4Y242OTHjXPuAUEnNpoYDRDLOlPyIxR/ LizQ== MIME-Version: 1.0 X-Received: by 10.112.155.106 with SMTP id vv10mr1848196lbb.53.1389039847990; Mon, 06 Jan 2014 12:24:07 -0800 (PST) Received: by 10.114.170.193 with HTTP; Mon, 6 Jan 2014 12:24:07 -0800 (PST) In-Reply-To: References: Date: Mon, 6 Jan 2014 14:24:07 -0600 Message-ID: From: Behcet Sarikaya To: Andrew Yourtchenko Content-Type: multipart/alternative; boundary=089e01161028b7ebcc04ef530a8e Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 20:24:19 -0000 --089e01161028b7ebcc04ef530a8e Content-Type: text/plain; charset=ISO-8859-1 Hi all, This document does not seem to have bibxml3 record, I am getting: unable to find external file "reference.I-D.yourtchenko-ra-dhcpv6-comparison" Regards, Behcet On Wed, Nov 27, 2013 at 7:06 AM, Andrew Yourtchenko wrote: > Hello all, > > Finally I managed to comb a little bit and finally submit the doc that > aims to compare RAs with DHCPv6 which emerged from the discussion on this > list a few weeks ago. > > I'll be very happy to hear any comments, suggestions, flames, etc. > > --a > > > p.s. The "realtime changes" repository is at: https://github.com/ayourtch/ > ra-dhcpv6, in case you want to send the feedback via a pull request :) > > ---------- Forwarded message ---------- > Date: Wed, 27 Nov 2013 04:52:14 -0800 > From: internet-drafts@ietf.org > To: Andrew Yourtchenko > Subject: New Version Notification for > draft-yourtchenko-ra-dhcpv6-comparison-00.txt > > > A new version of I-D, draft-yourtchenko-ra-dhcpv6-comparison-00.txt > has been successfully submitted by Andrew Yourtchenko and posted to the > IETF repository. > > Filename: draft-yourtchenko-ra-dhcpv6-comparison > Revision: 00 > Title: A comparison between the DHCPv6 and RA based host > configuration > Creation date: 2013-11-27 > Group: Individual Submission > Number of pages: 12 > URL: http://www.ietf.org/internet-drafts/draft-yourtchenko-ra- > dhcpv6-comparison-00.txt > Status: http://datatracker.ietf.org/doc/draft-yourtchenko-ra- > dhcpv6-comparison > Htmlized: http://tools.ietf.org/html/draft-yourtchenko-ra-dhcpv6- > comparison-00 > > > Abstract: > This document attempts to make a balanced comparison between the RA- > based and DHCPv6-based host configuration mechanisms. It compares > the two on different aspects, e.g: underlying media assumptions, > coordination, locality, etc. and highlights the strong and weak > sides of both protocols for each scenario. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --089e01161028b7ebcc04ef530a8e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

This document does not seem to h= ave bibxml3 record, I am getting:
unable to find external file &quo=
t;reference.I-D.yourtchenko-ra-dhcpv6-comparison"



Regards,

Behcet

On Wed, Nov 27, 2013 at 7:06 AM, Andrew Yourtchenko <ayourtch@c= isco.com> wrote:
Hello all,

Finally I managed to comb a little bit and finally submit the doc that aims= to compare RAs with DHCPv6 which emerged from the discussion on this list = a few weeks ago.

I'll be very happy to hear any comments, suggestions, flames, etc.

--a


p.s. The "realtime changes" repository is at: https://github.com/ayourtc= h/ra-dhcpv6, in case you want to send the feedback via a pull re= quest :)

---------- Forwarded message ----------
Date: Wed, 27 Nov 2013 04:52:14 -0800
From: interne= t-drafts@ietf.org
To: Andrew Yourtchenko <ayourtch@cisco.com>
Subject: New Version Notification for
=A0 =A0 draft-yourtchenko-ra-dhcpv6-comparison-00.txt


A new version of I-D, draft-yourtchenko-ra-dhcpv6-comparison-00.txt<= br> has been successfully submitted by Andrew Yourtchenko and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-yourtchenko-ra-dhcpv6-comparison
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 A comparison between the DHCPv6 and RA based hos= t configuration
Creation date: =A0 2013-11-27
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 12
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://ww= w.ietf.org/internet-drafts/draft-yourtchenko-ra-dhcpv6-compar= ison-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.iet= f.org/doc/draft-yourtchenko-ra-dhcpv6-comparison
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html= /draft-yourtchenko-ra-dhcpv6-comparison-00


Abstract:
=A0 =A0This document attempts to make a balanced comparison between the RA-=
=A0 =A0based and DHCPv6-based host configuration mechanisms. =A0It compares=
=A0 =A0the two on different aspects, e.g: underlying media assumptions,
=A0 =A0coordination, locality, etc. =A0and highlights the strong and weak =A0 =A0sides of both protocols for each scenario.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--089e01161028b7ebcc04ef530a8e-- From brian.e.carpenter@gmail.com Mon Jan 6 15:39:20 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E041AE328 for ; Mon, 6 Jan 2014 15:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnVVNtO5vQLx for ; Mon, 6 Jan 2014 15:39:18 -0800 (PST) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 084651AE323 for ; Mon, 6 Jan 2014 15:39:17 -0800 (PST) Received: by mail-pb0-f53.google.com with SMTP id ma3so19100109pbc.40 for ; Mon, 06 Jan 2014 15:39:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mPmPpSy8UYhvjbG2VrZprOVwkHaY/usxtWCdxaKIbLw=; b=oF2opjVwcaH7+phjvHCpDf1M82TFqZE9gZhIQnqp4wouv4smHZlaZ3L9sBYoLun9cg uB8M+pLGjiXyox+YX+L3yHq/dQrZXQz9bfn8GLjChlPqM542pTptY9kVBeHgIex6wneT kCm6MlwII53pkkNCesEzZGTPnR3hZpeauf6vICM/e//htYW8Yyd0shckRDeLE/UYf1o0 0GAUvsl3DH5FSEgsSqYoMoRCxk3L4iXHOkHr6equllGFgO2QnvAILnJlECSgflSC0qPc jpI9QzDAb7JPbBBVeA0xfAashhzVU0Txkq6vrFVtQcL356OAqaQ2FVpeGiSF/wEFCyuM Zycg== X-Received: by 10.68.164.196 with SMTP id ys4mr777879pbb.37.1389051549561; Mon, 06 Jan 2014 15:39:09 -0800 (PST) Received: from [192.168.178.21] (122.195.69.111.dynamic.snap.net.nz. [111.69.195.122]) by mx.google.com with ESMTPSA id k10sm61184468pbk.18.2014.01.06.15.39.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Jan 2014 15:39:08 -0800 (PST) Message-ID: <52CB3E9E.6020002@gmail.com> Date: Tue, 07 Jan 2014 12:39:10 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: sarikaya@ieee.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 23:39:20 -0000 There's a generic problem with the bibxml3 files, with numerous missing records. The xml2rfc people know but it's taking some time to fix, apparently. xml2rfc@ietf.org is the list for reporting such problems. Brian On 07/01/2014 09:24, Behcet Sarikaya wrote: > Hi all, > > This document does not seem to have bibxml3 record, I am getting: > > unable to find external file "reference.I-D.yourtchenko-ra-dhcpv6-comparison" > > > > > Regards, > > Behcet > > On Wed, Nov 27, 2013 at 7:06 AM, Andrew Yourtchenko wrote: > >> Hello all, >> >> Finally I managed to comb a little bit and finally submit the doc that >> aims to compare RAs with DHCPv6 which emerged from the discussion on this >> list a few weeks ago. >> >> I'll be very happy to hear any comments, suggestions, flames, etc. >> >> --a >> >> >> p.s. The "realtime changes" repository is at: https://github.com/ayourtch/ >> ra-dhcpv6, in case you want to send the feedback via a pull request :) >> >> ---------- Forwarded message ---------- >> Date: Wed, 27 Nov 2013 04:52:14 -0800 >> From: internet-drafts@ietf.org >> To: Andrew Yourtchenko >> Subject: New Version Notification for >> draft-yourtchenko-ra-dhcpv6-comparison-00.txt >> >> >> A new version of I-D, draft-yourtchenko-ra-dhcpv6-comparison-00.txt >> has been successfully submitted by Andrew Yourtchenko and posted to the >> IETF repository. >> >> Filename: draft-yourtchenko-ra-dhcpv6-comparison >> Revision: 00 >> Title: A comparison between the DHCPv6 and RA based host >> configuration >> Creation date: 2013-11-27 >> Group: Individual Submission >> Number of pages: 12 >> URL: http://www.ietf.org/internet-drafts/draft-yourtchenko-ra- >> dhcpv6-comparison-00.txt >> Status: http://datatracker.ietf.org/doc/draft-yourtchenko-ra- >> dhcpv6-comparison >> Htmlized: http://tools.ietf.org/html/draft-yourtchenko-ra-dhcpv6- >> comparison-00 >> >> >> Abstract: >> This document attempts to make a balanced comparison between the RA- >> based and DHCPv6-based host configuration mechanisms. It compares >> the two on different aspects, e.g: underlying media assumptions, >> coordination, locality, etc. and highlights the strong and weak >> sides of both protocols for each scenario. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From mpetach@gmail.com Mon Jan 6 19:11:09 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A326E1AE3E4 for ; Mon, 6 Jan 2014 19:11:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.643 X-Spam-Level: * X-Spam-Status: No, score=1.643 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzdeE2AQxtMW for ; Mon, 6 Jan 2014 19:11:06 -0800 (PST) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A009F1AE3E0 for ; Mon, 6 Jan 2014 19:11:06 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id rq2so19339183pbb.31 for ; Mon, 06 Jan 2014 19:10:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:cc:content-type; bh=S9k7x3GTAcIDxNxmxyYuuBr5qr6pCadA/xnzJ0nIPuc=; b=ZzYZt0XqzKKFyzFqAWqbUTIccHmv+yycAfR/lZ//oPynp++qKtLnONZxyBWN+LI/W4 sIrgmCAzITlYLN45tuojLnnrqRjGKZNVKvC/ZngmSJiECX9EpvIaY73fkezLHQTB5XU4 b7cTrr6FIJbx86Xl4zFHMQJgEyIwg16g8ROiBZs7y+kUO6YRanPabw4QtLpUFPV2h4ee aynprR6XZU/FmfDw5vwQoudQOQpBBMV3IS+haWH2p+IEh/9yp2jimIJqo05AdfiRq3ek GF5pns5K+8tCcwtC2hkH4bUI8wuelkmMmxSA2+et048AmJXEJktib1hPUeAazaj5CVcq IiiA== MIME-Version: 1.0 X-Received: by 10.66.123.5 with SMTP id lw5mr2157152pab.83.1389064258132; Mon, 06 Jan 2014 19:10:58 -0800 (PST) Sender: mpetach@gmail.com Received: by 10.70.1.130 with HTTP; Mon, 6 Jan 2014 19:10:57 -0800 (PST) In-Reply-To: <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> Date: Mon, 6 Jan 2014 19:10:57 -0800 X-Google-Sender-Auth: -6T0RcfAf7I4EM1DFrfMusZNz5E Message-ID: From: Matthew Petach Cc: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary=047d7bf0e7c8ad212d04ef58b988 Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 03:20:35 -0000 --047d7bf0e7c8ad212d04ef58b988 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Dec 8, 2013 at 11:38 AM, Owen DeLong wrote: > > On Dec 8, 2013, at 11:22 , Brian E Carpenter > wrote: > > > On 08/12/2013 19:40, Owen DeLong wrote: > >> On Dec 7, 2013, at 22:25 , Andrew Yourtchenko > wrote: > > > > ... > >>> I think you nailed it here: With RA you *discover* the routers > available on the link, with DHCP in legacy IP, you *configure* them. > >> > >> No, with DHCP, you discovered what some remote host rumored them to be. > > > > I don't think we should be having this argument. We should be > > trying to write down objectively the type of scenarios where > > DHCPv6 is applicable, the type of scenarios where RA-only is > > applicable, and the type of scenarios where both (simultaneously) > > are applicable. > > > > There's no right or wrong answer here. > > > > Brian > > In IPv6, as I read the RFCs, there's no valid way for a host to know that > it is supposed to get information from a DHCPv6 server unless it receives > an RA with the M and/or O bits set. > [been sitting on this for several days, pondering whether or not to send it out. finally decided it's not in my nature to not be impetuous, so after careful consideration decided I needed to go ahead and continue to be impetuous, and send it out. apologies for it now being a very stale rant.] As I read this thread, I try to avoid banging my head into the wall in frustration. People seem to be replying based on a notion that the current set of RFCs define the way the future must be. That is not a true notion. There are multi-billion dollar companies that have a need to operate their networks in very specific ways. If those ways are not supported by the RFCs, they will pay money to vendors to have options added to the software to allow them to operate their networks in that way. See for example the filter-aaaa-on-v4 option in BIND; while there was resistance to the idea that DNS servers be configurable to not return quad-A records to v4 queries, in the end, the needs of the business won out. There is a similar dynamic at play here. There are very large networks that require DCHPv6-only implementations to work, and they will get software to support that model, one way or another, because without it, they cannot move to a dual-stack environment. Not from a technical perspective, of course, but from an accounting and control perspective; the DHCP server must be the source of both v4 and v6 address assignments, and the only such source, in order for the staff to know for certain who has been assigned a given address on the network. You can argue back and forth until you're blue in the face; but it's rather like trying to persuade a glacier to stop advancing by pointing a hair dryer at it. There *will* be networks that will be run with address assignments from DHCP only, both for v4 and v6, and it can either happen with support from the RFC-discussing community, or it can come via paid-for-knobs in software to allow for non-RFC DHCPv4+DHCPv6-only environments. Remember, RFCs are guidelines only, not laws, and if the guidelines don't support the operational needs of businesses, they _will_ bypass them in order to keep the business functioning. Very large scale enterprises are well grounded in the model of having the host config say "obtain addresses dynamically", and having the source of those addresses be an authoritative box which tracks and accounts for all addresses given out. The notion of clients selecting their own address does not work in those environments, and trying to insist they alter their business to fit your idea of how things should work is less than useful. > > As such, the options are not DHCPv6 only, RA-only, and Both, but, RA-only > and Both. > > The scenarios where RA-Only make sense are any scenario where you do not > need greater control of the client configuration than Prefix information, > routing information, and DNS resolver addresses and search strings. > > In any scenario where you need to supply the host with more configuration > information on a dynamic basis, DHCPv6 is also required. > > Also, if you want dynamic DNS updates, deterministic assigned suffixes, > etc., these fall into the DHCPv6 realm. > > It's really as simple as that as near as I can tell. > > If you want to run without RAs, then you are into the realm of static > configuration. I, personally, do not see this as a problem. > Or, you're a company with tens of thousands of desktops, where static configuration is not a viable option, but control over address assignment from central servers is a must; in that environment, DHCPv6-assignment-only is a reality, and will exist; it is already being explored today, and to to deny that it is coming is equally as useful as cursing the coming of nightfall; it will happen, with or without your agreement or support. Matt > > Owen > > --047d7bf0e7c8ad212d04ef58b988 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Dec 8, 2013 at 11:38 AM, Owen DeLong <= owen@delong.com>= ; wrote:

On Dec 8, 2013, at 11:22 , Brian E Carpenter <brian.e.carpenter@gmail.com> = wrote:

> On 08/12/2013 19:40, Owen DeLong wrote:
>> On Dec 7, 2013, at 22:25 , Andrew Yourtchenko <ayourtch@cisco.com> wrote: >
> ...
>>> I think you nailed it here: With RA you *discover* the routers= available on the link, with DHCP in legacy IP, you *configure* them.
>>
>> No, with DHCP, you discovered what some remote host rumored them t= o be.
>
> I don't think we should be having this argument. We should be
> trying to write down objectively the type of scenarios where
> DHCPv6 is applicable, the type of scenarios where RA-only is
> applicable, and the type of scenarios where both (simultaneously)
> are applicable.
>
> There's no right or wrong answer here.
>
> =A0 Brian

In IPv6, as I read the RFCs, there's no valid way for a host to k= now that it is supposed to get information from a DHCPv6 server unless it r= eceives an RA with the M and/or O bits set.

[been sitting on this for several days, pondering whether or not= to send
=A0it out. =A0finally decided it's not in my n= ature to not be impetuous, so after
=A0careful consideratio= n decided I needed to go ahead and continue to be
=A0impetuous, and send it out. =A0apologies for it now being a v= ery stale rant.]

=A0

As I read this thread, I try to avoid banging my head into thewall in frustration.

People seem to be replying based o= n a notion that the current
set of RFCs define the way the future must b= e.

That is not a true notion.

There are multi= -billion dollar companies that have a need
to operate their networks in = very specific ways.=A0 If those
ways are not supported by the RFCs, they= will pay money
to vendors to have options added to the software to allow
them to operat= e their networks in that way.=A0 See for example
the filter-a= aaa-on-v4 option in BIND; while there was resistance
to the idea that DN= S servers be configurable to not
return quad-A records to v4 queries, in the end, the
needs of the busine= ss=A0won out.=A0=A0
There is a
similar dynamic at play = here.=A0 There are very large networks
that require DCHPv6-only implementations to work, and they
will get soft= ware to support that model, one way or another,
because without it, they= cannot move to a dual-stack
environment.=A0 Not from a technical persp= ective, of course,
but from an accounting and control perspective; the DHCP
server must be = the source of both v4 and v6 address assignments,
and the only such sour= ce, in order for the staff to know for certain
who has been assigned a g= iven address on the network.

You can argue back and forth until you're blue in the fa= ce;
but it's rather like trying to persuade a glacier to stop
adv= ancing by pointing a hair dryer at it.=A0 There *will* be
networks that = will be run with address assignments from DHCP only,
both for v4 and v6, and it can either happen with support from the
RFC-= discussing community, or it can come via paid-for-knobs in
software to = allow for non-RFC DHCPv4+DHCPv6-only environments.

Remember, RFCs are guidelines only, not laws, and
if the= guidelines don't support the operational needs
of businesses, they = _will_ bypass them in order to
keep the business functioning.

Very large scale enterprises are well grounded in
the model o= f having the host config say "obtain
addresses dynamical= ly", and having the source
of those addresses be an authoritative b= ox which
tracks and accounts for all addresses given out.
The notion o= f clients selecting their own address
does not work in those environment= s, and trying
to insist they alter their business to fit your idea
of how things should work is less than useful.

=A0

As such, the options are not DHCPv6 only, RA-only, and Both, but, RA-only a= nd Both.

The scenarios where RA-Only make sense are any scenario where you do not ne= ed greater control of the client configuration than Prefix information, rou= ting information, and DNS resolver addresses and search strings.

In any scenario where you need to supply the host with more configuration i= nformation on a dynamic basis, DHCPv6 is also required.

Also, if you want dynamic DNS updates, deterministic assigned suffixes, etc= ., these fall into the DHCPv6 realm.

It's really as simple as that as near as I can tell.

If you want to run without RAs, then you are into the realm of static confi= guration. I, personally, do not see this as a problem.

Or, you're a company with tens of thousands
of deskt= ops, where static configuration is not
a viable option, but control over address
assignment from ce= ntral servers is a must;
in that environment, DHCPv6-assignment-only is =
a reality, and will exist; it is already being explored
today, and = to to deny that it is coming is equally as
useful as cursing the coming of nightfall; it
will happen, with or witho= ut your agreement
or support.

Matt

= =A0

Owen


= =A0
--047d7bf0e7c8ad212d04ef58b988-- From Ted.Lemon@nominum.com Mon Jan 6 20:11:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135C01ADF7A for ; Mon, 6 Jan 2014 20:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GDpViJ8cIT7 for ; Mon, 6 Jan 2014 20:11:42 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 13F541ADF72 for ; Mon, 6 Jan 2014 20:11:42 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUst+dR1wzFCQ9N1wEpTTwsSZph0n7aV1@postini.com; Mon, 06 Jan 2014 20:11:33 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 721E01B82D6 for ; Mon, 6 Jan 2014 20:11:33 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 53F9C19005C; Mon, 6 Jan 2014 20:11:33 -0800 (PST) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 6 Jan 2014 20:11:27 -0800 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Mon, 6 Jan 2014 23:11:24 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <50833006-C1DA-4F71-BFE4-C9E1F6F29076@nominum.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> To: Matthew Petach X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 04:11:44 -0000 On Jan 6, 2014, at 10:10 PM, Matthew Petach = wrote: > There are multi-billion dollar companies that have a need > to operate their networks in very specific ways.=20 If you set your routers to send RAs with the M bit set and the A bit set = on any prefixes that are advertised, then devices will not autoconfigure = using SLAAC (or at least, they shouldn't). That delivers to you the = exact functionality you say you want. What change are you arguing for = in addition to this? From Ted.Lemon@nominum.com Mon Jan 6 20:12:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DCB1ADF72 for ; Mon, 6 Jan 2014 20:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5y0BZw3h0QYb for ; Mon, 6 Jan 2014 20:12:42 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7ED1ADF6E for ; Mon, 6 Jan 2014 20:12:42 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUst+spsNQpRR5LJzAdr/a1jcsbaquLD6@postini.com; Mon, 06 Jan 2014 20:12:34 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E41621B82B6 for ; Mon, 6 Jan 2014 20:12:33 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id DDEB319005C; Mon, 6 Jan 2014 20:12:33 -0800 (PST) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 6 Jan 2014 20:12:33 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <50833006-C1DA-4F71-BFE4-C9E1F6F29076@nominum.com> Date: Mon, 6 Jan 2014 23:12:32 -0500 Content-Transfer-Encoding: 7bit Message-ID: <39FCAF86-7C85-4FF2-9D41-E7391215EA4C@nominum.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> <50833006-C1DA-4F71-BFE4-C9E1F6F29076@nominum.com> To: Matthew Petach X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 04:12:45 -0000 On Jan 6, 2014, at 11:11 PM, Ted Lemon wrote: > If you set your routers to send RAs with the M bit set and the A bit set Sorry, I meant with the A bit clear, of course. From lorenzo@google.com Mon Jan 6 20:14:27 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D8F1ADF72 for ; Mon, 6 Jan 2014 20:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrHnS84M8ZSK for ; Mon, 6 Jan 2014 20:14:24 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1DC1ADF6E for ; Mon, 6 Jan 2014 20:14:24 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id tp5so18947245ieb.25 for ; Mon, 06 Jan 2014 20:14:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=p/YYmkasBtdEcjWKv8Zj0XSpKAKWIN4wcy7p5uukEbE=; b=Yg2O4Nu+1uZ+Zp2L1IWXOje4k+x9CBOgCxDuD4eqlhHQAwVYcf2RCUTWbukAETmVs1 9S3xZOzBA/6B29B93tXP2Ox++2hI2MQFdssy8rR3xegD2Vsi9aSOAauj1WjaO8OE3dFN Vzv1YKXECiEwM0BVh/oIk9xdm1WmwXmMD2LsS8rbKtbzoQhaj5ZB04bpY3JDgvOiM2Oe xGHT9mvcH401xMkJanY/JY9DLpUQ1JoTF0SlIiAAFKhJGuptYR6hjwMOnioa1prz6kyV muLAixollSykMP0rgMgD1tInweNMUPI0ISx+I95hgCaWytZnSXIEh2yMXoW83iKnGIuO /v1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=p/YYmkasBtdEcjWKv8Zj0XSpKAKWIN4wcy7p5uukEbE=; b=Bg9iHMIoUez29shhx3dVkxykEcTdu8KW9VDJWb6wDz2knBkOaj7HO5uLhPYu2Ly4Zh BLtqs81/QHkRmuzUUFzoEOsTobAYYQA4j6A0JAADOUZwzbExo3tTxFIBqJ5RMUiq4EQc 6ACx/emEEkvFvcKBMA+YdfPsZ4e823UQAQmiwq3582m+sNGSTpzoj4gD8fQ7nszL8KG3 X412JeDZkgpxlK6j/+OMGn27xJdvY8ra2EpmU5CNQOVVxAKXqlRSJqwQTZuazh6nY4kT 8SnQGj4QMlAL43Ahtb3nwGbexgc7PjmwpAvrb/C4bw94YzA1+FF+oQcc7AjbC2mN5fO6 Nytw== X-Gm-Message-State: ALoCoQlKzcphRKsVSUvSrwwcGrDMHtGgVKQ9djMT01QDp9HcYlSdWDMzZI4Vdqyj4wvWRNH947mrwx8EYKXz8LrUHTWxcGswCylKx/sdDP5t3TPOwE2q6kEugMQ27uSiibQOHTPXgbqqb3pyKpQjcMD7XDCgC5/4Ayvz44GVWGtcr4sCs+WfGbchX6Srs/HC3eqr1Aej9ncA X-Received: by 10.50.79.228 with SMTP id m4mr22999044igx.47.1389068055613; Mon, 06 Jan 2014 20:14:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Mon, 6 Jan 2014 20:13:54 -0800 (PST) In-Reply-To: References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> From: Lorenzo Colitti Date: Tue, 7 Jan 2014 13:13:54 +0900 Message-ID: To: Matthew Petach Content-Type: multipart/alternative; boundary=089e013a1f16063cda04ef599ced Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 04:14:27 -0000 --089e013a1f16063cda04ef599ced Content-Type: text/plain; charset=UTF-8 On Tue, Jan 7, 2014 at 12:10 PM, Matthew Petach wrote: > There are multi-billion dollar companies that have a need > to operate their networks in very specific ways. If those > ways are not supported by the RFCs, they will pay money > to vendors to have options added to the software to allow > them to operate their networks in that way. See for example > the filter-aaaa-on-v4 option in BIND; while there was resistance > to the idea that DNS servers be configurable to not > return quad-A records to v4 queries, in the end, the > needs of the business won out. > I think that's a terrible example. AFAIK (and I think I was in the room) the filter-aaaa-on-v4 hack was originally proposed for use in CPEs, and it met with opposition even there. Opposition for getting it into bind was pretty strong, and AIUI - as you say - it was included only because someone said, "We have a contract. Here's a check. Now honour the contract." In hindsight, it turned out to be a really bad idea. The hack was never used for its intended purpose in the CPE, but it did end up being used basically by an entire country to cling to a fundamentally broken IPv6 deployment model (the NTT walled-garden "here's a global IPv6 address and a default route, but you can't reach the IPv6 Internet, have a nice day" fiasco). I think that if filter-aaaa-on-v4 is an example of anything, it's an example of the law of unintended consequences. > There are very large networks > that require DCHPv6-only implementations to work, and they > will get software to support that model, one way or another, > because without it, they cannot move to a dual-stack > environment. Not from a technical perspective, of course, > but from an accounting and control perspective; the DHCP > server must be the source of both v4 and v6 address assignments, > and the only such source, in order for the staff to know for certain > who has been assigned a given address on the network. > DHCPv6 is not *necessary* accounting and control. It is one way to do it, but you can do it just as well with address tracking in the switches. Address tracking is also much more flexible (allowing multiple addresses, dynamic addresses) and more secure: while using DHCP for address verification requires strong first-hop security in the switches (DHCP snooping, address-to-MAC binding, forced forwarding, etc) address tracking requires none of that. In fact, there's a fallacy here: I have personally see security people think that DHCP-provided addresses are secure, when by themselves they are not secure at all. They can only be made secure if first-hop security is in place. In fact, I'd argue that DHCPv4 is not particularly well-suited for address tracking at all, and the only reason we use DHCP for address tracking in IPv4 is that in IPv4 there is basically no other mechanism to assign addresses. With that out of the way: why are you talking about address assignment. DHCPv6-only address assignment is already a standard. Send an RA with M=1 (and optionally a prefix with A=0) and - assuming your hosts implement DHCPv6 - you're done. > You can argue back and forth until you're blue in the face; > but it's rather like trying to persuade a glacier to stop > advancing by pointing a hair dryer at it. There *will* be > networks that will be run with address assignments from DHCP only, > both for v4 and v6, and it can either happen with support from the > RFC-discussing community, or it can come via paid-for-knobs in > software to allow for non-RFC DHCPv4+DHCPv6-only environments. > Of course. In the privacy of your own network, or between consenting networks and implementations, you can do whatever you like. But standardizing it is a much higher bar. In hindsight, I think it's pretty clear to that filter-aaaa-on-v4 is a terrible idea (just think of what will happen to it when DNSSEC rolls around), and I think it's clear that it will never be standardized. But that doesn't stop people from using it. Or, you're a company with tens of thousands > of desktops, where static configuration is not > a viable option, but control over address > assignment from central servers is a must; > in that environment, DHCPv6-assignment-only is > a reality, and will exist; it is already being explored > today, and to to deny that it is coming is equally as > useful as cursing the coming of nightfall; it > will happen, with or without your agreement > or support. > It's not entirely clear to me what you're talking about here, since DHCPv6-only address assignment is already possible today. But take a random $FEATURE. If you're right and your multi-billion dollar enterprises get all host operating systems to support $FEATURE, then it will be a de facto standard. But until then, it would be a mistake for the IETF to to standardize $FEATURE if there are existing and technically superior ways of implmenting $FEATURE's functionality just because a subset of users want to stick to the same practices they used in IPv4. BTW, I am aware of at least one company that meets your "multi-billion dollar, tens of thousands of desktops" definition that claims to have brought IPv6 to 99% of its engineers without using DHCPv6 for address assignment. In fact, they saw this as an opportunity to not run a DHCPv6 server at all. Cheers, Lorenzo --089e013a1f16063cda04ef599ced Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 7, 2014 at 12:10 PM, Matthew Petach <mpetach@netflight.com> wrote:
There are multi-billion dollar companies that have a need
to operat= e their networks in very specific ways.=C2=A0 If those
ways are not supp= orted by the RFCs, they will pay money
to vendors to have options added to the software to allow
them to operat= e their networks in that way.=C2=A0 See for example
the filte= r-aaaa-on-v4 option in BIND; while there was resistance
to the idea that= DNS servers be configurable to not
return quad-A records to v4 queries, in the end, the
needs of the busine= ss=C2=A0won out.=C2=A0=C2=A0

<= /div>
I think that's a terrible example. AFAIK (and I think I was i= n the room) the filter-aaaa-on-v4 hack was originally proposed for use in C= PEs, and it met with opposition even there. Opposition for getting it into = bind was pretty strong, and AIUI - as you say - it was included only becaus= e someone said, "We have a contract. Here's a check. Now honour th= e contract."

In hindsight, it turned out to be a really bad idea. Th= e hack was never used for its intended purpose in the CPE, but it did end u= p being used basically by an entire country to cling to a fundamentally bro= ken IPv6 deployment model (the NTT walled-garden "here's a global = IPv6 address and a default route, but you can't reach the IPv6 Internet= , have a nice day" fiasco). I think that if filter-aaaa-on-v4 is an ex= ample of anything, it's an example of the law of unintended consequence= s.
=C2=A0
There are very large networks
that require DCHPv6-only implementations to work, and they
will get soft= ware to support that model, one way or another,
because without it, they= cannot move to a dual-stack
environment.=C2=A0 Not from a technical pe= rspective, of course,
but from an accounting and control perspective; the DHCP
server must be = the source of both v4 and v6 address assignments,
and the only such sour= ce, in order for the staff to know for certain
who has been assigned a g= iven address on the network.

<sidenote>=C2=A0
DHCPv6 is not *necessary* accounting and control. It is one way to= do it, but you can do it just as well with address tracking in the switche= s. Address tracking is also much more flexible (allowing multiple addresses= , dynamic addresses) and more secure: while using DHCP for address verifica= tion requires strong first-hop security in the switches (DHCP snooping, add= ress-to-MAC binding, forced forwarding, etc) address tracking requires none= of that. In fact, there's a fallacy here: I have personally see securi= ty people think that DHCP-provided addresses are secure, when by themselves= they are not secure at all. They can only be made secure if first-hop secu= rity is in place.

In fact, I'd argue that DHCPv4 is not particularly = well-suited for address tracking at all, and the only reason we use DHCP fo= r address tracking in IPv4 is that in IPv4 there is basically no other mech= anism to assign addresses.
</sidenote>

With that out of the w= ay: why are you talking about address assignment. DHCPv6-only address assig= nment is already a standard. Send an RA with M=3D1 (and optionally a prefix= with A=3D0) and - assuming your hosts implement DHCPv6 - you're done.<= /div>
=C2=A0
You can argue back and forth until you'= re blue in the face;
but it's rather like trying to persu= ade a glacier to stop
advancing by pointing a hair dryer at it.=C2=A0 Th= ere *will* be
networks that will be run with address assignments from DHCP only,
both for v4 and v6, and it can either happen with support from the
RFC-= discussing community, or it can come via paid-for-knobs in
software to = allow for non-RFC DHCPv4+DHCPv6-only environments.

Of course. In the privacy of your ow= n network, or between consenting networks and implementations, you can do w= hatever you like. But standardizing it is a much higher bar. In hindsight, = I think it's pretty clear to that filter-aaaa-on-v4 is a terrible idea = (just think of what will happen to it when DNSSEC rolls around), and I thin= k it's clear that it will never be standardized. But that doesn't s= top people from using it.

Or, you're a company with tens of thousands
<= /div>
of desktops, where static configuration is not
a viable option, but control over address
assignment from ce= ntral servers is a must;
in that environment, DHCPv6-assignment-only is =
a reality, and will exist; it is already being explored
today, and = to to deny that it is coming is equally as
useful as cursing the coming of nightfall; it
will happen, with or witho= ut your agreement
or support.
<= br>
It's not entirely clear to me what you're talking abo= ut here, since DHCPv6-only address assignment is already possible today. Bu= t take a random $FEATURE. If you're right and your multi-billion dollar= enterprises get all host operating systems to support $FEATURE, then it wi= ll be a de facto standard. But until then, it would be a mistake for the IE= TF to to standardize $FEATURE if there are existing and technically superio= r ways of implmenting $FEATURE's functionality just because a subset of= users want to stick to the same practices they used in IPv4.

BTW, I am aware of at least one company that meets your= "multi-billion dollar, tens of thousands of desktops" definition= that claims to have brought IPv6 to 99% of its engineers without using DHC= Pv6 for address assignment. In fact, they saw this as an opportunity to not= run a DHCPv6 server at all.

Cheers,
Lorenzo
--089e013a1f16063cda04ef599ced-- From markzzzsmith@yahoo.com.au Tue Jan 7 01:48:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C366D1ADFA4 for ; Tue, 7 Jan 2014 01:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.748 X-Spam-Level: * X-Spam-Status: No, score=1.748 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2APM1S-8uRr for ; Tue, 7 Jan 2014 01:48:07 -0800 (PST) Received: from nm26-vm0.bullet.mail.bf1.yahoo.com (nm26-vm0.bullet.mail.bf1.yahoo.com [98.139.213.74]) by ietfa.amsl.com (Postfix) with ESMTP id DF0FD1ADF8A for ; Tue, 7 Jan 2014 01:48:06 -0800 (PST) Received: from [98.139.212.151] by nm26.bullet.mail.bf1.yahoo.com with NNFMP; 07 Jan 2014 09:47:58 -0000 Received: from [98.139.212.234] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 07 Jan 2014 09:47:58 -0000 Received: from [127.0.0.1] by omp1043.mail.bf1.yahoo.com with NNFMP; 07 Jan 2014 09:47:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 30083.90157.bm@omp1043.mail.bf1.yahoo.com Received: (qmail 38418 invoked by uid 60001); 7 Jan 2014 09:47:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1389088077; bh=ORYkHem1L543zOzsj/gELSiGj31vUi/O6ZKznQeScYQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=l2oCyHD1/VbiDKwgns7OSXRgX0AUGMCdTt5fA7k99RKF5nLOwnTQKfO5RzYRDDo5h6yOh2AsW15h1kASNJzhoD/PJ/QrwwIbxAzNs020de7qwZNPIPOSx/stbsMkT0dZOzkDvKq/STfk5iVKkQB2fRNmp6FzHf2KMmozlkAAHiQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=2yyUUQ1brsXp3oP6beT13I8FnwOVYwJl+yL3GVnNJ/I5t3Mn7kKGZ4UU+0Y7c4x3WFzd6tngZxVuC3oiZqRGZoYpS7fAV2HOFdR0G0Tz9FnvIFXAqCO5SPzJmDI3/W1KaUAfR7koSuecJ/pFP4JDqhdp9bZJXeJVt+Kb+hjomXU=; X-YMail-OSG: 33REeLUVM1nW1i4kVCjamv3_WV3By5frLs6z9P_hGPnbTTZ NkcCHr1aBcO1wQ2lHejZRhkSmynUGLdVjBEvTTCR7lkM49A1SMHquewEZr25 ROZ6khWuF3mK8iu6BhsrWr035uNOkCQCieGHYASBdJx_dYIGmS7udLRFPxZd ViiTtnmmfzanCrSApCQ8MEwm6Uq8dXoWk9j7nBQgZAeiy9RTzOVDFkMOhF_O t3ZQVh0VQ0BLtc8LOPln4TnoYg3mAuCo0Q2HPaCYLRz1l5pWMv.2rq1QT7wd XWiiV1Tg0mzO4NQ4yqTaFve_REpjqM1yRrTp1avPBNQzPTkWQraKNVxzOlVd ImtnQNdUkn0wnscRC3PJYAj26HfNFx8PsPZjVu9ppbxD1tYAV8ONEy.aIgpF 3C01SJpzr85OWq6UgliValopyow6jfUoYsG203X3ykb38Iq_xYTUVmfaewXX Qq9oUSPHB8ZQxqOsE3khznBDvbC0QiUWXQQISeonQ5B3ocvDZfplnxhkdRf_ h2MF4DyXygI0N9woNAzNnrbFUEk5vkGp62E65g8eNVbJ4W3s81t9pV5Bd0kv aOWXosvAhBm2rBWPpl3t8dSd81uFjmL2uBbOSCb_I3E9A_Yt8G0B_7NiDviN zmjTnkOyiXj5Lk7QJnWKeUje8xgA5UaWleqypQoxUhF18sKnuAGc- Received: from [150.101.221.237] by web161902.mail.bf1.yahoo.com via HTTP; Tue, 07 Jan 2014 01:47:57 PST X-Rocket-MIMEInfo: 002.001, PHNuaXA.Cgo.Cj4KPlJlbWVtYmVyLCBSRkNzIGFyZSBndWlkZWxpbmVzIG9ubHksIG5vdCBsYXdzLCBhbmQKPgo.aWYgdGhlIGd1aWRlbGluZXMgZG9uJ3Qgc3VwcG9ydCB0aGUgb3BlcmF0aW9uYWwgbmVlZHMKPm9mIGJ1c2luZXNzZXMsIHRoZXkgX3dpbGxfIGJ5cGFzcyB0aGVtIGluIG9yZGVyIHRvCj5rZWVwIHRoZSBidXNpbmVzcyBmdW5jdGlvbmluZy4KPgoKQW5kIHRoZXkncmUgcXVpdGUgZnJlZSB0byBkbyB0aGF0IGF0IHRoZWlyIGV4cGVuc2UsIHByaXZhdGVseSBpbnNpZGUgdGhlaXIgb3duIG5ldHcBMAEBAQE- X-Mailer: YahooMailWebService/0.8.172.614 References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> Message-ID: <1389088077.95524.YahooMailNeo@web161902.mail.bf1.yahoo.com> Date: Tue, 7 Jan 2014 01:47:57 -0800 (PST) From: Mark ZZZ Smith To: Matthew Petach In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 09:48:08 -0000 =0A=0A>=0A>=0A>Remember, RFCs are guidelines only, not laws, and=0A>= =0A>if the guidelines don't support the operational needs=0A>of businesses,= they _will_ bypass them in order to=0A>keep the business functioning.=0A>= =0A=0AAnd they're quite free to do that at their expense, privately inside = their own network, and without any involvement of the IETF if they don't ca= re about interoperability. They can pay all of the costs of their device ve= ndors implementing the enterprise's own methods and protocols when they are= different to the IETF's.=0A=0AThe thing the IETF have to worry about is su= mmarised quite well in the title of RFC3271, and a few paragraphs from it:= =0A=0A"The Internet is for Everyone"=0A=0A=0A" =A0Internet is for everyone = - but it won't be until in every home, in=0A=A0 =A0every business, in every= school, in every library, in every hospital=0A=A0 =A0in every town and in = every country on the Globe, the Internet can be=0A=A0 =A0accessed without l= imitation, at any time and in every language."=0A=0A" =A0Internet is for ev= eryone - but it won't be if it is too complex to be=0A=A0 =A0used easily by= everyone. =A0Let us dedicate ourselves to the task of=0A=A0 =A0simplifying= the Internet's interfaces and to educating all that are=0A=A0 =A0intereste= d in its use."=0A=0AThe IETF is about providing protocols to provide intero= perability between many different, independent and unrelated parties' imple= mentations. That means that my mother's interoperability and ease of use ne= eds are as equally important to consider as your enterprises' are, when dev= eloping a solution.=A0=0A=0AEnterprise networks are quite welcome to bring = their needs to the IETF, but I don't think they can expect that only their = needs will be considered and satisfied, just because they've got lots of mo= ney. There are more home users of the Internet and home networks attached t= o the Internet than there are enterprises networks and users, so if there i= s a common case to optimise for, it is the non-technical home user.=A0=0A= =0A>=0A>Very large scale enterprises are well grounded in=0A>the model of h= aving the host config say "obtain=0A>=0A>addresses dynamically", and having= the source=0A>of those addresses be an authoritative box which=0A>tracks a= nd accounts for all addresses given out.=0A>=0A=0ADHCPv4 and DHCPv6 "tracks= and accounts for all addresses given out", but it won't guarantee to tell = you all addresses in use, and I think that is what mostly enterprise people= actually are caring about (and I used to be one of them).=A0DHCP does not = track statically configured addresses in either IPv4 or IPv6, and in the ca= se of IPv6, won't track link-local addresses present and in use either. DHC= Pv6, SLAAC, static and link-local addresses are all candidate addresses for= applications to use (RFC6742, RFC4007), so DHCPv6 will only ever provide p= artial visibility into what addresses are in use - just as DHCPv4 does.=0A= =0AGive up the delusion that DHCP of either flavour will guarantee to tell = you all the addresses in use on your network, and deploy a proper solution = that does, such as arpwatch for IPv4, or=A0ipv6mon (http://www.si6networks.= com/tools/ipv6mon/) for IPv6. I don't know if the commercial router vendors= are providing equivalent tools, but they should be if they aren't and want= to address their enterprise customers' security needs.=0A=0A=0A>The notion= of clients selecting their own address=0A=0A>does not work in those enviro= nments, and trying=0A>to insist they alter their business to fit your idea= =0A>of how things should work is less than useful.=0A>=0A>=A0=0A=0A>=0A>=0A= >>As such, the options are not DHCPv6 only, RA-only, and Both, but, RA-only= and Both.=0A>>=0A>>The scenarios where RA-Only make sense are any scenario= where you do not need greater control of the client configuration than Pre= fix information, routing information, and DNS resolver addresses and search= strings.=0A>>=0A>>In any scenario where you need to supply the host with m= ore configuration information on a dynamic basis, DHCPv6 is also required.= =0A>>=0A>>Also, if you want dynamic DNS updates, deterministic assigned suf= fixes, etc., these fall into the DHCPv6 realm.=0A>>=0A>>It's really as simp= le as that as near as I can tell.=0A>>=0A>>If you want to run without RAs, = then you are into the realm of static configuration. I, personally, do not = see this as a problem.=0A>>=0A>=0A>=0A>Or, you're a company with tens of th= ousands=0A>of desktops, where static configuration is not=0A>=0A>a viable o= ption, but control over address =0A>assignment from central servers is a mu= st;=0A>in that environment, DHCPv6-assignment-only is =0A>a reality, and wi= ll exist; it is already being explored =0A>today, and to to deny that it is= coming is equally as=0A>useful as cursing the coming of nightfall; it=0A>w= ill happen, with or without your agreement=0A>or support.=0A>=0A>=0A>Matt= =0A>=0A>=0A>=0A>=A0=0A>=0A>>Owen=0A>>=0A>>=0A>>=0A>=0A>=0A>=A0=0A>=0A>_____= __________________________________________=0A>v6ops mailing list=0A>v6ops@i= etf.org=0A>https://www.ietf.org/mailman/listinfo/v6ops=0A>=0A>=0A> From gert@Space.Net Tue Jan 7 02:40:14 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FD11AD9AE for ; Tue, 7 Jan 2014 02:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arx8klZrtgq7 for ; Tue, 7 Jan 2014 02:40:12 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 20F321AD66E for ; Tue, 7 Jan 2014 02:40:11 -0800 (PST) Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id B1C446028E for ; Tue, 7 Jan 2014 11:40:01 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 6B27B60270 for ; Tue, 7 Jan 2014 11:40:01 +0100 (CET) Received: (qmail 62951 invoked by uid 1007); 7 Jan 2014 11:40:01 +0100 Date: Tue, 7 Jan 2014 11:40:01 +0100 From: Gert Doering To: Matthew Petach Message-ID: <20140107104001.GM81676@Space.Net> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 10:40:14 -0000 Hi, On Mon, Jan 06, 2014 at 07:10:57PM -0800, Matthew Petach wrote: > [been sitting on this for several days, pondering whether or not to send > it out. finally decided it's not in my nature to not be impetuous, so > after > careful consideration decided I needed to go ahead and continue to be > impetuous, and send it out. apologies for it now being a very stale rant.] Your stale rant is completely missing the point, unfortunately. Your multi-million-dollar enterprise can do DHCPv6-based IPv6 address assignment perfectly well today. Client and server implementations exist, and RFCs back that. The thing that can not be done today is "do that if you do not have RAs on your network, that will tell the clients 'go to the DHCPv6 server for address information, but route the packets to me'". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From v6ops@globis.net Tue Jan 7 04:12:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71491ADFC7 for ; Tue, 7 Jan 2014 04:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pO90Zcg7pxWM for ; Tue, 7 Jan 2014 04:12:31 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id E5CE61ADFC5 for ; Tue, 7 Jan 2014 04:12:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id AC740870F8E; Tue, 7 Jan 2014 13:12:21 +0100 (CET) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuHrIy-d8Ea4; Tue, 7 Jan 2014 13:12:21 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 8AADE870067; Tue, 7 Jan 2014 13:12:21 +0100 (CET) Message-ID: <52CBEF24.5060902@globis.net> Date: Tue, 07 Jan 2014 13:12:20 +0100 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Lorenzo Colitti References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 12:12:33 -0000 Lorenzo Colitti wrote: > On Tue, Jan 7, 2014 at 12:10 PM, Matthew Petach > wrote: > > There are multi-billion dollar companies that have a need > to operate their networks in very specific ways. If those > ways are not supported by the RFCs, they will pay money > to vendors to have options added to the software to allow > them to operate their networks in that way. See for example > the filter-aaaa-on-v4 option in BIND; while there was resistance > to the idea that DNS servers be configurable to not > return quad-A records to v4 queries, in the end, the > needs of the business won out. > > > I think that's a terrible example. AFAIK (and I think I was in the > room) the filter-aaaa-on-v4 hack was originally proposed for use in > CPEs, and it met with opposition even there. Opposition for getting it > into bind was pretty strong, and AIUI - as you say - it was included > only because someone said, "We have a contract. Here's a check. Now > honour the contract." > > In hindsight, it turned out to be a really bad idea. The hack was > never used for its intended purpose in the CPE, but it did end up > being used basically by an entire country to cling to a fundamentally > broken IPv6 deployment model (the NTT walled-garden "here's a global > IPv6 address and a default route, but you can't reach the IPv6 > Internet, have a nice day" fiasco). I think that if filter-aaaa-on-v4 > is an example of anything, it's an example of the law of unintended > consequences. > > There are very large networks > that require DCHPv6-only implementations to work, and they > will get software to support that model, one way or another, > because without it, they cannot move to a dual-stack > environment. Not from a technical perspective, of course, > but from an accounting and control perspective; the DHCP > server must be the source of both v4 and v6 address assignments, > and the only such source, in order for the staff to know for certain > who has been assigned a given address on the network. > > > > DHCPv6 is not *necessary* accounting and control. It is one way to do > it, but you can do it just as well with address tracking in the > switches. Address tracking is also much more flexible (allowing > multiple addresses, dynamic addresses) and more secure: while using > DHCP for address verification requires strong first-hop security in > the switches (DHCP snooping, address-to-MAC binding, forced > forwarding, etc) address tracking requires none of that. In fact, > there's a fallacy here: I have personally see security people think > that DHCP-provided addresses are secure, when by themselves they are > not secure at all. They can only be made secure if first-hop security > is in place. > > In fact, I'd argue that DHCPv4 is not particularly well-suited for > address tracking at all, and the only reason we use DHCP for address > tracking in IPv4 is that in IPv4 there is basically no other mechanism > to assign addresses. > > > With that out of the way: why are you talking about address > assignment. DHCPv6-only address assignment is already a standard. Send > an RA with M=1 (and optionally a prefix with A=0) and - assuming your > hosts implement DHCPv6 - you're done. > > You can argue back and forth until you're blue in the face; > but it's rather like trying to persuade a glacier to stop > advancing by pointing a hair dryer at it. There *will* be > networks that will be run with address assignments from DHCP only, > both for v4 and v6, and it can either happen with support from the > RFC-discussing community, or it can come via paid-for-knobs in > software to allow for non-RFC DHCPv4+DHCPv6-only environments. > > > Of course. In the privacy of your own network, or between consenting > networks and implementations, you can do whatever you like. But > standardizing it is a much higher bar. In hindsight, I think it's > pretty clear to that filter-aaaa-on-v4 is a terrible idea (just think > of what will happen to it when DNSSEC rolls around), and I think it's > clear that it will never be standardized. But that doesn't stop people > from using it. > > Or, you're a company with tens of thousands > > of desktops, where static configuration is not > a viable option, but control over address > assignment from central servers is a must; > in that environment, DHCPv6-assignment-only is > a reality, and will exist; it is already being explored > today, and to to deny that it is coming is equally as > useful as cursing the coming of nightfall; it > will happen, with or without your agreement > or support. > > > It's not entirely clear to me what you're talking about here, since > DHCPv6-only address assignment is already possible today. But take a > random $FEATURE. If you're right and your multi-billion dollar > enterprises get all host operating systems to support $FEATURE, then > it will be a de facto standard. But until then, it would be a mistake > for the IETF to to standardize $FEATURE if there are existing and > technically superior ways of implmenting $FEATURE's functionality just > because a subset of users want to stick to the same practices they > used in IPv4. > > BTW, I am aware of at least one company that meets your "multi-billion > dollar, tens of thousands of desktops" definition that claims to have > brought IPv6 to 99% of its engineers without using DHCPv6 for address > assignment. In fact, they saw this as an opportunity to not run a > DHCPv6 server at all. > > Cheers, > Lorenzo Correct me if I'm wrong, but there seems to be an underlying assumption in this discussion that the infra and infra people knowing the address that a particular host uses for communication is universally for "bad things" e.g. to break privacy so people can be tracked. e.g. to prevent unauthorised access. There are also "good things", especially in a "dumb host/ smart network" model found in many enterprises e.g. your friendly help desk and network engineering staff can trace your communication problem, and can correlate problem investigation across various logs. e.g. you can be given VIP DSCP settings to improve your voice quality and for call admission purposes. e.g. WAN acceleration can be used for certain servers/apps without overloading the acceleration engine. e.g. PBR can be used to send your traffic over a better path. Not all LANs are centrally managed. And being able to tell an outsourcer to add "this config per interface and it'll all work" is definitely preferable in some environments. RA flags are not that tough to set, but I'm certain many will mess it up and the A flag will not be set to 0. Then the ability to turn off/filter RA altogether has some attraction. Telling people "From now on, you have to organise your security ACLs, firewall rules, WAN acceleration rules, PBR, QoS ACLs per /64 LAN prefix" hasn't gone down too well so far. On the long term this may be a good thing, but lack of functional equivalence with IPv4 is certainly a hurdle to deployment. -- Regards, RayH From karsten_thomann@linfre.de Tue Jan 7 05:49:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD77A1AE046 for ; Tue, 7 Jan 2014 05:49:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEqb6z0jCInA for ; Tue, 7 Jan 2014 05:49:45 -0800 (PST) Received: from linfre.de (linfre.de [83.151.26.85]) by ietfa.amsl.com (Postfix) with ESMTP id 13B841AE044 for ; Tue, 7 Jan 2014 05:49:45 -0800 (PST) Received: from linne.localnet (85.16.209.105) by linfreserv.linfre (Axigen) with (AES256-SHA encrypted) ESMTPSA id 0BF608; Tue, 7 Jan 2014 14:49:27 +0100 From: Karsten Thomann To: v6ops@ietf.org Date: Tue, 07 Jan 2014 14:49:25 +0100 Message-ID: <1847363.xquTMZ8SQy@linne> User-Agent: KMail/4.10.4 (Windows/6.1; KDE/4.10.4; i686; ; ) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="nextPart2324088.DD23jTxtXn" Content-Transfer-Encoding: 7Bit X-AXIGEN-DK-Result: No records DomainKey-Status: no signature X-AxigenSpam-Level: 7 Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 13:49:48 -0000 This is a multi-part message in MIME format. --nextPart2324088.DD23jTxtXn Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Hi, I think the draft is useful for everyone who is starting an ipv6 deployment and doesn't know how to handle the flags in the right way. Notes: Section 3.1 In my opinion there should be an addional note that DHCPv6 is not anymore a requirement for hosts (RFC6434). I know it is covered in section 3.2, to make sure all hosts support DHCPv6 but should be also covered as a note at the SLAAC section. Section 3.3 s/Window 8/ Windows 8/ Best regards Karsten Am Montag, 6. Januar 2014, 07:59:39 schrieb Liubing: > Hi Dear All, > > In ietf88 meeting, we discussed draft-liu-bonica-dhcpv6-slaac-problem which > indicated the hosts' behavior might varied on DHCPv6/SLAAC interaction > caused by ambiguous standard definition. (The draft was adopted as > ietf-v6ops-dhcpv6-slaac-problem after the meeting.) > > Since the above draft is only filed as a Problem Statement document, as > discussed in the meeting, the WG decided to initiate another draft to > provide some operational guidance of what the administrators should do > given the fact that the host behavior might varied in some situations. > > So this is the 00 version. Hope you can read it and comment. > Your review and comments would be appreciated very much. > > And a late happy new year to you all. > > Best regards > Bing > > > -----Original Message----- > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of fred@cisco.com > > Sent: Wednesday, December 25, 2013 9:45 PM > > To: v6ops@ietf.org > > Cc: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org > > Subject: [v6ops] new draft: draft-liu-v6ops-dhcpv6-slaac-guidance > > > > > > A new draft has been posted, at > > http://tools.ietf.org/html/draft-liu-v6ops-dhcpv6-slaac-guidance. Please > > take a look at it and comment. > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --nextPart2324088.DD23jTxtXn Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="us-ascii"

Hi,

 

I think the draft is useful for everyone who is starting an ipv6 deployment and doesn't know how to handle the flags in the right way.

 

Notes:

Section 3.1

In my opinion there should be an addional note that DHCPv6 is not anymore a requirement for hosts (RFC6434).

I know it is covered in section 3.2, to make sure all hosts support DHCPv6 but should be also covered as a note at the SLAAC section.

 

Section 3.3

s/Window 8/ Windows 8/

 

Best regards

Karsten

 

Am Montag, 6. Januar 2014, 07:59:39 schrieb Liubing:

> Hi Dear All,

>

> In ietf88 meeting, we discussed draft-liu-bonica-dhcpv6-slaac-problem which

> indicated the hosts' behavior might varied on DHCPv6/SLAAC interaction

> caused by ambiguous standard definition. (The draft was adopted as

> ietf-v6ops-dhcpv6-slaac-problem after the meeting.)

>

> Since the above draft is only filed as a Problem Statement document, as

> discussed in the meeting, the WG decided to initiate another draft to

> provide some operational guidance of what the administrators should do

> given the fact that the host behavior might varied in some situations.

>

> So this is the 00 version. Hope you can read it and comment.

> Your review and comments would be appreciated very much.

>

> And a late happy new year to you all.

>

> Best regards

> Bing

>

> > -----Original Message-----

> > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of fred@cisco.com

> > Sent: Wednesday, December 25, 2013 9:45 PM

> > To: v6ops@ietf.org

> > Cc: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org

> > Subject: [v6ops] new draft: draft-liu-v6ops-dhcpv6-slaac-guidance

> >

> >

> > A new draft has been posted, at

> > http://tools.ietf.org/html/draft-liu-v6ops-dhcpv6-slaac-guidance. Please

> > take a look at it and comment.

> > _______________________________________________

> > v6ops mailing list

> > v6ops@ietf.org

> > https://www.ietf.org/mailman/listinfo/v6ops

>

> _______________________________________________

> v6ops mailing list

> v6ops@ietf.org

> https://www.ietf.org/mailman/listinfo/v6ops

--nextPart2324088.DD23jTxtXn-- From markzzzsmith@yahoo.com.au Tue Jan 7 05:50:01 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1016D1AE057 for ; Tue, 7 Jan 2014 05:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.401 X-Spam-Level: X-Spam-Status: No, score=0.401 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1irLfOzwXBB for ; Tue, 7 Jan 2014 05:49:59 -0800 (PST) Received: from nm3-vm0.bullet.mail.bf1.yahoo.com (nm3-vm0.bullet.mail.bf1.yahoo.com [98.139.212.154]) by ietfa.amsl.com (Postfix) with ESMTP id 6823C1ADF66 for ; Tue, 7 Jan 2014 05:49:59 -0800 (PST) Received: from [98.139.215.141] by nm3.bullet.mail.bf1.yahoo.com with NNFMP; 07 Jan 2014 13:49:50 -0000 Received: from [98.139.212.211] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 07 Jan 2014 13:49:50 -0000 Received: from [127.0.0.1] by omp1020.mail.bf1.yahoo.com with NNFMP; 07 Jan 2014 13:49:50 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 596450.83003.bm@omp1020.mail.bf1.yahoo.com Received: (qmail 39639 invoked by uid 60001); 7 Jan 2014 13:49:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1389102590; bh=foyR91RI8RTJlZlG7WovEtDbN1AF+CAxCWBA3NuYd0M=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=G1FZLzcSfE0egfuOp8MW4XrVFxOUu2tTXkGB9d8IrqYufej4GjGYhAbgXVwjr8gt0CtghzhkUMBWH2W2H9qaBXbq6P6+14Hhfv57uo678No1NMG96vCTh88fhPUzkiMp5q10v2+uVkzVNY+AGKBU4q7McVVdsPUR5viOqxRwayQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=hcxwTYi5e1hPqbGLo1xYuX7iRsCsF7TCpZlAjqpFPG1/FvnsFDpysRYrMjohQcVllw5gppEZ7J4i2vyKQf4bwXHJUHWTS9xBskdQWAAgdQtbIyXJU0pZZjAILcb2aAgC8QpWb2nZLiwwzdttFS/wwQE4dmGZGhs4H8mBjJ4sgwc=; X-YMail-OSG: bnmMUhQVM1mStjN63YC8d2hSvMbI_QwsE7hsWBL0hiVRcja UiRk_H6qvIeH.Is86EwA0jC2YX7.rAooA6nQ2qPaiqsD4wioMqBkt_ShFOKC MTiwOZ.tMTZdyj2PTEVH3i4h0JCo1l8tAO0TtN1eskq7NJZdnSLzPh1gw8Lw yGYWYFgGzC7RUnG4iodcqTBuHLtlD5iKXexaS86VjSUVtFLNtkhd_pEGzATK 0_v3lxHKRS.39MtChzNG5DrPrmN6J4m6PHACmul3OWpW5CKP0sqh7b4JvM3V UHj3to7cGx40CzizH0DOAogMjMz_f5AZUg4fmY_66PnZgHdzk4zRA4qXk_E9 oXHrswkAuLxtU11485QHOsyOBbcexouxMl8Ga3xW3cRlPOAQrZG4O8bOdyrH g4v3czO66nFhFIgMgKRirMQIOn4S8O.DHnySZ6_T7MPbNHuSE6VBY2YzatQq zbIXj_lLQ0UpRd5XoHecZWjsPSmtVPd2WAHt85UY.Pc4Hgm6t.JVWLURYskM Od_Xl0cqV1iBBPZ8keD8XE0Iu3QEs4jaaehDvIF0ssJzoc93UYpjhEzU8czD wdAT3HEis48JjRIA35k9FVKco Received: from [150.101.221.237] by web161902.mail.bf1.yahoo.com via HTTP; Tue, 07 Jan 2014 05:49:50 PST X-Rocket-MIMEInfo: 002.001, CgoKCjxzbmlwPgoKPj4gIEJUVywgSSBhbSBhd2FyZSBvZiBhdCBsZWFzdCBvbmUgY29tcGFueSB0aGF0IG1lZXRzIHlvdXIgIm11bHRpLWJpbGxpb24gCj4gCj4.ICBkb2xsYXIsIHRlbnMgb2YgdGhvdXNhbmRzIG9mIGRlc2t0b3BzIiBkZWZpbml0aW9uIHRoYXQgY2xhaW1zIHRvIGhhdmUgCj4.ICBicm91Z2h0IElQdjYgdG8gOTklIG9mIGl0cyBlbmdpbmVlcnMgd2l0aG91dCB1c2luZyBESENQdjYgZm9yIGFkZHJlc3MgCj4.ICBhc3NpZ25tZW50LiBJbiBmYWN0LCB0aGV5IHNhdyB0aGlzIGFzIGFuIG9wcG8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.172.614 References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> <52CBEF24.5060902@globis.net> Message-ID: <1389102590.30063.YahooMailNeo@web161902.mail.bf1.yahoo.com> Date: Tue, 7 Jan 2014 05:49:50 -0800 (PST) From: Mark ZZZ Smith To: Ray Hunter , Lorenzo Colitti In-Reply-To: <52CBEF24.5060902@globis.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 13:50:01 -0000 =0A=0A=0A=0A=0A=0A>> BTW, I am aware of at least one company that me= ets your "multi-billion =0A> =0A>> dollar, tens of thousands of desktops" = definition that claims to have =0A>> brought IPv6 to 99% of its engineers = without using DHCPv6 for address =0A>> assignment. In fact, they saw this = as an opportunity to not run a =0A>> DHCPv6 server at all.=0A>> =0A>> Che= ers,=0A>> Lorenzo=0A> Correct me if I'm wrong, but there seems to be an un= derlying assumption =0A> in this discussion that the infra and infra people= knowing the address =0A> that a particular host uses for communication is = universally for "bad =0A> things"=0A> =0A> e.g. to break privacy so people = can be tracked.=0A> e.g. to prevent unauthorised access.=0A>=A0=0A=0AI don'= t think so. I think there are are quite valid reasons to track addresses in= use. The point is that DHCPv6 cannot possibly accurately provide that info= rmation, because it only has records of the addresses it hands out, which d= oesn't include other types of addresses that hosts may or will have, such a= s static, SLAAC or link-local addresses.=0A=0AIf the enterprise admin has a= bsolute control over the hosts then it would seem to me that they don't nee= d to be concerned with unauthorised address use, because there is no possib= ility of unauthorised address use. In the least, as first steps, they shoul= d be enforcing this control by using 802.1X to prevent unauthorised access = to the network, as well as shutting down network ports that aren't in use.= =0A=0AIf they are concerned about unauthorised address use, that means they= don't have absolute control over the hosts and their attachment to the net= work, and therefore there is a possibility that untrusted and less controll= ed hosts can choose to not use the DHCPv6 assigned addresses, use link-loca= ls instead for which DHCPv6 has no records, or completely ignore the DHCPv6= assigned addresses and statically configure their own ULA prefix to use in= stead.=0A=0ASo DHCPv6 isn't an effective tool to accurately track address u= sage because untrusted hosts can choose not to use it or can avoid using th= e addresses it gives out.=0A=0A> There are also "good things", especially i= n a "dumb host/ smart =0A> network" =0A> model found in many enterprises=0A= > =0A> e.g. your friendly help desk and network engineering staff can trace= =0A> your communication problem, and can correlate problem investigation = =0A> across various logs.=0A> e.g. you can be given VIP DSCP settings to im= prove your voice quality =0A> and for call admission purposes.=0A> e.g. WAN= acceleration can be used for certain servers/apps without =0A> overloading= the acceleration engine.=0A> e.g. PBR can be used to send your traffic ove= r a better path.=0A> =0A> Not all LANs are centrally managed. And being abl= e to tell an outsourcer =0A> to add "this config per interface and it'll al= l work" is =0A> definitely =0A> preferable in some environments.=0A> RA fla= gs are not that tough to set, but I'm certain many will mess it up =0A> and= the A flag will not be set to 0. Then the ability to turn off/filter =0A> = RA altogether has some attraction.=0A> =0A> Telling people "From now on, yo= u have to organise your security ACLs, =0A> firewall rules, WAN acceleratio= n rules, PBR, QoS ACLs per /64 LAN =0A> prefix" hasn't gone down too well s= o far.=0A> On the long term this may be a good thing, but lack of functiona= l =0A> equivalence with IPv4 is certainly a hurdle to deployment.=0A>=A0=0A= =0AI really struggle to understand how the additional effort to have to con= stantly "right size" IPv4 prefixes has somehow made creating firewall rules= , ACLs, PBR etc. preferable. Every time the IPv4 prefix length is changed, = all of those things need to be updated. It's monotonous work, may involve a= fter hours changes to avoid network service disruption, and requires effort= and concentration to ensure it is done correctly and accurately. Some peop= le might find that enjoyable, but I think they're well and truly in the min= ority (people with no experience doing it might enjoy it the first few time= s, but after that ...).=0A=0AActually, most enterprises now use RFC1918 add= resses, and if you look at their addressing, they'll commonly pick /24s for= their LAN segments and use them everywhere (and call them "Class C"s). So = it seems to be human nature to try to pick a simple and single large enough= prefix size from the outset when the opportunity is there to do so.=0A=0A"= Right sizing" IPv4 prefixes has only really been necessary to deal with IPv= 4's lack of public address space, and has created much additional administr= ative work and network service disruption. It is a cost that can easily be = eliminated when the address space is large. Making the network cheaper to o= perate and increasing its availability by minimising configuration changes = can only be a good thing.=0A=0ARegards,=0AMark. From owen@delong.com Tue Jan 7 10:13:36 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D281AE0FB for ; Tue, 7 Jan 2014 10:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQS1fSicCErC for ; Tue, 7 Jan 2014 10:13:34 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8D21AE0FA for ; Tue, 7 Jan 2014 10:13:33 -0800 (PST) Received: from [IPv6:2620::930:0:225:ff:fe44:af17] ([IPv6:2620:0:930:0:225:ff:fe44:af17]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s07IAoMw026234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 7 Jan 2014 10:10:50 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s07IAoMw026234 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1389118251; bh=BEG7B7DFtvBoU+itYWWYlbYSWH0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=s+kHz6ujedvyDzNt2UcxnszC1WnFqNs1yPOkBZEj5LXLIqLSUOHuGuuO3OcdfWnoH zUomotpXlHeCCSz1P3FmuV/A0i8B54Up8g2LI++M/gXeExg1Osbwc4RaVLHuk0ojXO V25fZL+V95Ktl79Gb5igk3ruPHtVGqhwY6HyjKso= Content-Type: multipart/alternative; boundary="Apple-Mail=_B1F9590A-3028-4219-9914-A098DE2E16B3" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Owen DeLong In-Reply-To: Date: Tue, 7 Jan 2014 10:10:49 -0800 Message-Id: <0570E136-702E-4200-9C7F-528A9A6281C7@delong.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> To: Matthew Petach X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 07 Jan 2014 10:10:51 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 18:13:37 -0000 --Apple-Mail=_B1F9590A-3028-4219-9914-A098DE2E16B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 >=20 > As such, the options are not DHCPv6 only, RA-only, and Both, but, = RA-only and Both. >=20 > The scenarios where RA-Only make sense are any scenario where you do = not need greater control of the client configuration than Prefix = information, routing information, and DNS resolver addresses and search = strings. >=20 > In any scenario where you need to supply the host with more = configuration information on a dynamic basis, DHCPv6 is also required. >=20 > Also, if you want dynamic DNS updates, deterministic assigned = suffixes, etc., these fall into the DHCPv6 realm. >=20 > It's really as simple as that as near as I can tell. >=20 > If you want to run without RAs, then you are into the realm of static = configuration. I, personally, do not see this as a problem. >=20 > Or, you're a company with tens of thousands > of desktops, where static configuration is not > a viable option, but control over address=20 > assignment from central servers is a must; > in that environment, DHCPv6-assignment-only is=20 > a reality, and will exist; it is already being explored=20 > today, and to to deny that it is coming is equally as > useful as cursing the coming of nightfall; it > will happen, with or without your agreement > or support. >=20 We are talking about two different things=85 DHCPv6-assignment-only is possible today. It is what happens if you set = the M bit in the RA. DHCPv6 will then have full control of address = assignment. What is not possible today is to do that DHCPv6 assignment without = receiving an RA to instruct the host to do so. Why is that a problem for the network environments you have described? As to getting software to do it, that=92s not really the problem. The = problem is that there=92s already lots of deployed hardware and software = that is implemented as defined in the current RFCs. It=92s the elimination of RAs that is problematic. Using DHCP = exclusively for address assignment isn=92t difficult. Adding routing = information to DHCPv6 wouldn=92t be all that difficult. Eliminating RAs from the process would require a major change that would = likely pose some level of compatibility problem with existing = deployments. Owen --Apple-Mail=_B1F9590A-3028-4219-9914-A098DE2E16B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

As such, the options are not DHCPv6 only, RA-only, and Both, but, = RA-only and Both.

The scenarios where RA-Only make sense are any scenario where you do not = need greater control of the client configuration than Prefix = information, routing information, and DNS resolver addresses and search = strings.

In any scenario where you need to supply the host with more = configuration information on a dynamic basis, DHCPv6 is also = required.

Also, if you want dynamic DNS updates, deterministic assigned suffixes, = etc., these fall into the DHCPv6 realm.

It's really as simple as that as near as I can tell.

If you want to run without RAs, then you are into the realm of static = configuration. I, personally, do not see this as a = problem.

Or, you're a company with = tens of thousands
of desktops, where static configuration is not
a viable option, but control over address
assignment from = central servers is a must;
in that environment, = DHCPv6-assignment-only is
a reality, and will exist; it is already = being explored
today, and to to deny that it is coming is equally = as
useful as cursing the coming of nightfall; it
will happen, with or = without your agreement
or = support.


= We are talking about two different = things=85

DHCPv6-assignment-only is possible today. = It is what happens if you set the M bit in the RA. DHCPv6 will then have = full control of address assignment.

What is not = possible today is to do that DHCPv6 assignment without receiving an RA = to instruct the host to do so.

Why is that a = problem for the network environments you have = described?

As to getting software to do it, = that=92s not really the problem. The problem is that there=92s already = lots of deployed hardware and software that is implemented as defined in = the current RFCs.

It=92s the elimination of RAs = that is problematic. Using DHCP exclusively for address assignment isn=92t= difficult. Adding routing information to DHCPv6 wouldn=92t be all that = difficult.

Eliminating RAs from the process = would require a major change that would likely pose some level of = compatibility problem with existing = deployments.

Owen

= --Apple-Mail=_B1F9590A-3028-4219-9914-A098DE2E16B3-- From leo.liubing@huawei.com Tue Jan 7 17:40:41 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71C81AE285 for ; Tue, 7 Jan 2014 17:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81FSyRRaLhmQ for ; Tue, 7 Jan 2014 17:40:39 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 57C261AE284 for ; Tue, 7 Jan 2014 17:40:38 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZS52842; Wed, 08 Jan 2014 01:40:21 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 8 Jan 2014 01:39:57 +0000 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 8 Jan 2014 01:40:20 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.72]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Wed, 8 Jan 2014 09:40:14 +0800 From: "Liubing (Leo)" To: Karsten Thomann , "v6ops@ietf.org" Thread-Topic: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance Thread-Index: AQHPC69aFuMwL0u35UivZdi86dE6hZp6DBWQ Date: Wed, 8 Jan 2014 01:40:13 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D828258@nkgeml506-mbx.china.huawei.com> References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <1847363.xquTMZ8SQy@linne> In-Reply-To: <1847363.xquTMZ8SQy@linne> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D828258nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 01:40:41 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D828258nkgeml506mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Karsten, Thanks a lot for your review and comment. I think your suggestion is good, we'll revise accordingly in the next versi= on. Best regards, Bing From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Karsten Thomann Sent: Tuesday, January 07, 2014 9:49 PM To: v6ops@ietf.org Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: ne= w draft: draft-liu-v6ops-dhcpv6-slaac-guidance Hi, I think the draft is useful for everyone who is starting an ipv6 deployment= and doesn't know how to handle the flags in the right way. Notes: Section 3.1 In my opinion there should be an addional note that DHCPv6 is not anymore a= requirement for hosts (RFC6434). I know it is covered in section 3.2, to make sure all hosts support DHCPv6 = but should be also covered as a note at the SLAAC section. Section 3.3 s/Window 8/ Windows 8/ Best regards Karsten Am Montag, 6. Januar 2014, 07:59:39 schrieb Liubing: > Hi Dear All, > > In ietf88 meeting, we discussed draft-liu-bonica-dhcpv6-slaac-problem whi= ch > indicated the hosts' behavior might varied on DHCPv6/SLAAC interaction > caused by ambiguous standard definition. (The draft was adopted as > ietf-v6ops-dhcpv6-slaac-problem after the meeting.) > > Since the above draft is only filed as a Problem Statement document, as > discussed in the meeting, the WG decided to initiate another draft to > provide some operational guidance of what the administrators should do > given the fact that the host behavior might varied in some situations. > > So this is the 00 version. Hope you can read it and comment. > Your review and comments would be appreciated very much. > > And a late happy new year to you all. > > Best regards > Bing > > > -----Original Message----- > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of fred@cisco.com= > > Sent: Wednesday, December 25, 2013 9:45 PM > > To: v6ops@ietf.org > > Cc: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org > > Subject: [v6ops] new draft: draft-liu-v6ops-dhcpv6-slaac-guidance > > > > > > A new draft has been posted, at > > http://tools.ietf.org/html/draft-liu-v6ops-dhcpv6-slaac-guidance. Pleas= e > > take a look at it and comment. > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D828258nkgeml506mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Karsten= ,

 = ;

Thanks a l= ot for your review and comment.

I think yo= ur suggestion is good, we’ll revise accordingly in the next version.<= o:p>

 = ;

Best regar= ds,

Bing<= /o:p>

 = ;

From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Karsten Thomann
Sent: Tuesday, January 07, 2014 9:49 PM
To: v6ops@ietf.org
Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-/= /RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance

 

Hi,=

 

I think the draft is useful for everyone w= ho is starting an ipv6 deployment and doesn't know how to handle the flags in the right way.

 

Notes:

Section 3.1

In my opinion there should be an addional = note that DHCPv6 is not anymore a requirement for hosts (RFC6434).

I know it is covered in section 3.2, to ma= ke sure all hosts support DHCPv6 but should be also covered as a note at the SLAAC section.

 

 

Section 3.3

s/Window 8/ Windows 8/

 

Best regards

Karsten

 

Am Montag, 6. Januar 2014, 07:59:39 schrie= b Liubing:

> Hi Dear All,

>

> In ietf88 meeting, we discussed draft= -liu-bonica-dhcpv6-slaac-problem which

> indicated the hosts' behavior might v= aried on DHCPv6/SLAAC interaction

> caused by ambiguous standard definiti= on. (The draft was adopted as

> ietf-v6ops-dhcpv6-slaac-problem after= the meeting.)

>

> Since the above draft is only filed a= s a Problem Statement document, as

> discussed in the meeting, the WG deci= ded to initiate another draft to

> provide some operational guidance of = what the administrators should do

> given the fact that the host behavior= might varied in some situations.

>

> So this is the 00 version. Hope you c= an read it and comment.

> Your review and comments would be app= reciated very much.

>

> And a late happy new year to you all.=

>

> Best regards

> Bing

>

> > -----Original Message-----<= /o:p>

> > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of fred@cisco.com<= /p>

> > Sent: Wednesday, December 25, 20= 13 9:45 PM

> > To: v6ops@ietf.org

> > Cc: dra= ft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org

> > Subject: [v6ops] new draft: draf= t-liu-v6ops-dhcpv6-slaac-guidance

> >

> >

> > A new draft has been posted, at<= o:p>

> > http://tools.ietf.org/html/draft-liu-v6ops-dhcpv6-slaac-guidance. Ple= ase

> > take a look at it and comment.

> > ________________________________= _______________

> > v6ops mailing list

> > v6ops@ietf.org

> > https://www.ietf.or= g/mailman/listinfo/v6ops

>

> _____________________________________= __________

> v6ops mailing list<= /p>

> v6ops@ietf.org

> https://www.ietf.or= g/mailman/listinfo/v6ops

--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D828258nkgeml506mbxchi_-- From internet-drafts@ietf.org Tue Jan 7 18:49:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E101AE29D; Tue, 7 Jan 2014 18:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9B-GUW-tNm_m; Tue, 7 Jan 2014 18:49:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD401AE2A0; Tue, 7 Jan 2014 18:49:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140108024900.9459.59545.idtracker@ietfa.amsl.com> Date: Tue, 07 Jan 2014 18:49:00 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 02:49:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : NAT64 Operational Experience Authors : Gang Chen Zhen Cao Chongfeng Xie David Binet Filename : draft-ietf-v6ops-nat64-experience-08.txt Pages : 22 Date : 2014-01-07 Abstract: This document summarizes NAT64 function deployment scenarios and operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) and NAT64 server Front End (NAT64-FE) are considered in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-nat64-experience-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lorenzo@google.com Tue Jan 7 23:06:05 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5709E1AE2FB for ; Tue, 7 Jan 2014 23:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFtSE-AbCRIi for ; Tue, 7 Jan 2014 23:06:02 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id DCED71AE300 for ; Tue, 7 Jan 2014 23:06:01 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id lx4so1617190iec.9 for ; Tue, 07 Jan 2014 23:05:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZUnczlU9EQSMcB6GLtYqv451mGtf2SfGJ/16AKqxhm0=; b=Sfh+XDm0MRt5ZpHDm/Qgzmw+4ZRMd6zpuju/JmgcRrX7gRvJ8Cxfl6xlDa7k5By7Fn AC5uSdssT/IDbswxpgUmH1B72lReJTtajl2m9hWS6cZQTYU54Hk9+f6kgry1JrhGzREw lR3YCPJ63KcWMH38Bj3tivrdrFhoyXKJG5OmDMqDPH9JLrqM7pQShQn7Dni9i1pNqtdx 3l2mZlRmu8JBtSJ5JbjyGUlrDWqcPlmlBhjtFibXWSlJ8GVLje81twHUv+dz0V3ELxrQ VDx6jNbBP5++tTIP0XNoyGRBXjRXgs1nYFW15dyVMmzmyfHflC2584dNLm1RrYZAyQFs jrSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ZUnczlU9EQSMcB6GLtYqv451mGtf2SfGJ/16AKqxhm0=; b=UYAGR+oyfTJUhzP6axDmhL4ew9RLX7pQj7tGOGMs3Nz+7bWwFbMwPURA2/KID+IQyI Rc0+2hlXvIRJr+ZWfDwBzA1nj3YLVuodeslApqg7qq5RZUOL4d/EUySrm6M7CWcrX1OS SwQVfDRWGpBF9vIxsuxCgYnzREBVHWhIQOsQZM20iriOrOBH5g4RmZDqrp78f0uEI0iC eHu7ufk8epyHhmidwJp6LCvWfdkd43FWYHJqxg1r58b8M6c05P8bbsKnZ10G5s6W57PE MIeX/r59ds23xZJTSUFFC0AWqMqsQ4UyDNH4WT1gG74uXXr0pAz4zNbvN3WTSHYTfHrp /mfA== X-Gm-Message-State: ALoCoQmlGHhQudzzSujMV9D2aY+YlbWze5Ji5eUi65KJT8dV/qPzGsCxvP+qeu8oQ+iebstlXHN7IYw/IRPrlGnlSMo8vE3RX5rp2Pe69+LyH+vqsKiaFCSb9uuhKU+cCAAckYgUu413B3BuHySSc1tCW1J8uzWhtb7LWcRD0TQ8nFnO2WJWgv1LntqU/mcemI8YgboSuu10 X-Received: by 10.42.18.68 with SMTP id w4mr73212656ica.22.1389164752695; Tue, 07 Jan 2014 23:05:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Tue, 7 Jan 2014 23:05:31 -0800 (PST) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> From: Lorenzo Colitti Date: Wed, 8 Jan 2014 16:05:31 +0900 Message-ID: To: "Liubing (Leo)" Content-Type: multipart/alternative; boundary=20cf301d42d89e9fdd04ef701f3b Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 07:06:05 -0000 --20cf301d42d89e9fdd04ef701f3b Content-Type: text/plain; charset=UTF-8 Authors, I see this document has a "Guidance for DHCPv6-only Deployment" section which mentions "DHCPv6-only configuration without RAs". Three points on that: 1. We had a discussion on this topic when discussing the problem statement draft a couple of weeks ago, and I thought we had agreed that a DHCPv6-only configuration without RAs doesn't do anything useful at all, and since it doesn't do anything useful at all, it should not be documented. See for example at http://www.ietf.org/mail-archive/web/v6ops/current/msg18231.html If it's not documented in the problem statement document because it doesn't do anything useful, then it certainly should not be documented in the guidance to operators document. And in fact, the draft already states that "this is an invalid use case". Can you remove it, then? As an operational group we don't want to provide guidance on invalid use cases. :-) 2. That section should also make it clear that in a DHCPv6-only deployment: - If there is no RA, the addresses assigned by DHCPv6 cannot be used for anything at all. - If there is an RA that specifies a default router but does not specify the on-link prefix, then all traffic, even between hosts on the same link, is routed at layer 3 by the default gateway. 3. Please do not cite [DHCPv6-ROUTE]. That document was so controversial that it was removed from the WG's charter and is no longer a WG item, so it is inappropriate to cite it in an operational guidance document. Cheers, Lorenzo On Mon, Jan 6, 2014 at 4:59 PM, Liubing (Leo) wrote: > Hi Dear All, > > In ietf88 meeting, we discussed draft-liu-bonica-dhcpv6-slaac-problem > which indicated the hosts' behavior might varied on DHCPv6/SLAAC > interaction caused by ambiguous standard definition. (The draft was adopted > as ietf-v6ops-dhcpv6-slaac-problem after the meeting.) > > Since the above draft is only filed as a Problem Statement document, as > discussed in the meeting, the WG decided to initiate another draft to > provide some operational guidance of what the administrators should do > given the fact that the host behavior might varied in some situations. > > So this is the 00 version. Hope you can read it and comment. > Your review and comments would be appreciated very much. > > And a late happy new year to you all. > > Best regards > Bing > > > > -----Original Message----- > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of fred@cisco.com > > Sent: Wednesday, December 25, 2013 9:45 PM > > To: v6ops@ietf.org > > Cc: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org > > Subject: [v6ops] new draft: draft-liu-v6ops-dhcpv6-slaac-guidance > > > > > > A new draft has been posted, at > > http://tools.ietf.org/html/draft-liu-v6ops-dhcpv6-slaac-guidance. Please > > take a look at it and comment. > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --20cf301d42d89e9fdd04ef701f3b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Authors,

I see this document has a &quo= t;Guidance for DHCPv6-only Deployment" section which mentions "DH= CPv6-only configuration without RAs". Three points on that:

1. We had a discussion on this topic when discussing the pro= blem statement draft a couple of weeks ago, and I thought we had agreed tha= t a DHCPv6-only configuration without RAs doesn't do anything useful at= all, and since it doesn't do anything useful at all, it should not be = documented. See for example at http://www.ietf.org/mail-archive/web/v6ops= /current/msg18231.html

If it's not documented in the problem statement doc= ument because it doesn't do anything useful, then it certainly should n= ot be documented in the guidance to operators document. And in fact, the dr= aft already states that "this is an invalid use case".

Can you remove it, then? As an operational group we don= 't want to provide guidance on invalid use cases. :-)


2. That section should also make it clear that in a = DHCPv6-only deployment:
  • If there is no RA, the addresses assigned by DHCPv6 cannot be = used for anything at all.
  • If there is an RA that specifies a de= fault router but does not specify the on-link prefix, then all traffic, eve= n between hosts on the same link, is routed at layer 3 by the default gatew= ay.

3. Please do not cite [DHCPv6-ROUTE]. That d= ocument was so controversial that it was removed from the WG's charter = and is no longer a WG item, so it is inappropriate to cite it in an operati= onal guidance document.

Cheers,
Lorenzo


On Mon, Jan 6, 2014 at 4:59 PM,= Liubing (Leo) <leo.liubing@huawei.com> wrote:
Hi Dear All,

In ietf88 meeting, we discussed draft-liu-bonica-dhcpv6-slaac-problem which= indicated the hosts' behavior might varied on DHCPv6/SLAAC interaction= caused by ambiguous standard definition. (The draft was adopted as ietf-v6= ops-dhcpv6-slaac-problem after the meeting.)

Since the above draft is only filed as a Problem Statement document, as dis= cussed in the meeting, the WG decided to initiate another draft to provide = some operational guidance of what the administrators should do given the fa= ct that the host behavior might varied in some situations.

So this is the 00 version. Hope you can read it and comment.
Your review and comments would be appreciated very much.

And a late happy new year to you all.

Best regards
Bing


> -----Original Message-----
> From: v6ops [mailto:v6ops-bo= unces@ietf.org] On Behalf Of fred@cis= co.com
> Sent: Wednesday, December 25, 2013 9:45 PM
> To: v6ops@ietf.org
> Cc: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org
> Subject: [v6ops] new draft: draft-liu-v6ops-dhcpv6-slaac-guidance
>
>
> A new draft has been posted, at
> http://tools.ietf.org/html/draft-liu-v6ops-dhcpv6-= slaac-guidance. Please
> take a look at it and comment.
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--20cf301d42d89e9fdd04ef701f3b-- From sthaug@nethelp.no Wed Jan 8 01:40:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682CE1AE0F1 for ; Wed, 8 Jan 2014 01:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEg761LHpX2h for ; Wed, 8 Jan 2014 01:40:28 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id BDD5F1AE0CF for ; Wed, 8 Jan 2014 01:40:27 -0800 (PST) Received: (qmail 45400 invoked from network); 8 Jan 2014 09:40:16 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 8 Jan 2014 09:40:16 -0000 Date: Wed, 08 Jan 2014 10:40:16 +0100 (CET) Message-Id: <20140108.104016.74707582.sthaug@nethelp.no> To: lorenzo@google.com From: sthaug@nethelp.no In-Reply-To: References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 09:40:30 -0000 > I see this document has a "Guidance for DHCPv6-only Deployment" section > which mentions "DHCPv6-only configuration without RAs". Three points on > that: > > 1. We had a discussion on this topic when discussing the problem statement > draft a couple of weeks ago, and I thought we had agreed that a DHCPv6-only > configuration without RAs doesn't do anything useful at all, and since it > doesn't do anything useful at all, it should not be documented. See for > example at http://www.ietf.org/mail-archive/web/v6ops/current/msg18231.html > > If it's not documented in the problem statement document because it doesn't > do anything useful, then it certainly should not be documented in the > guidance to operators document. And in fact, the draft already states that > "this is an invalid use case". The authors may well agree that this a DHCPv6-only configuration without RAs doesn't do anything useful. I'd be inclined to agree *today* - but I certainly wouldn't want to rule out DHCPv6-only configuration without RAs in the future. > Can you remove it, then? As an operational group we don't want to provide > guidance on invalid use cases. :-) Removing it is not going to make the demand for DHCPv6-only configuration without RAs magically disapppear. Steinar Haug, AS 2116 From lorenzo@google.com Wed Jan 8 01:51:39 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E801AE0F1 for ; Wed, 8 Jan 2014 01:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ubnqxKaUdpt for ; Wed, 8 Jan 2014 01:51:38 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2E86A1AE110 for ; Wed, 8 Jan 2014 01:51:38 -0800 (PST) Received: by mail-ig0-f175.google.com with SMTP id j1so12682105iga.2 for ; Wed, 08 Jan 2014 01:51:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JuqsYzdKQnXAJaj1zWheEW14UXq94X9sjYTQ9Ry9zN0=; b=GFC3j+EIunzlS5TJJ7ChCBFIlwFV/1F81B3VYjbSHQDMSgIkhGHaNhhDdkdn31PAuH swfLJh7uZTaZcIaYpesd+Sp3EGEsCjGMESmFjxc6OKDs0YwZAqCRh6KnWSe19nvskcbh f1F0mwaLPJt9rbdxRXl71rEXlp1V/PB5JnCWAsmSJOIaKGOBKhUzIvCjklSwFy6kQ3fA rtQIzVrzsLzI0YUMwVEWMz0onDa4QTmTolknYMW0fiOjlRUcuUbYLn1ZJ/WqTIfXuXZu aT+6KGYoyqIQMeN5bDebXlHNG55iPZtD9aDJ3hY32RmyXJ2Vk8QgcXwB5FuHgIwh2dU/ XRJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=JuqsYzdKQnXAJaj1zWheEW14UXq94X9sjYTQ9Ry9zN0=; b=MSoEoWQHjBZpECwVwSLorkQzWas/6GhpJWfLScEl0yZE1GmSrdxoGGMPHECWDrFJJa Hlrv3/gZyifFKP4JviVArArJ53UHSKB8MsFvCsMGkpu1YeQ5EzIhNCLmJv+aKuJ7r6HW YbVAIC9pMEz8SELajXE1CkBh5ICrTCRKnNgN11TwhRpOdlua6oBuz+aPTpLIsgXmVXwC Il3x6uKdgIY5PZBVtwVYS39/txp/qHUsEiP2xp9mgrykpGXkjAYenTIMtUwMobADKE3M LEjn8egetsl3pDThvPs9xsMWo/f6RycSrPTIUrii4r8pCv5kBKsN0qxkYEJcYoi2Obkf 32+w== X-Gm-Message-State: ALoCoQmNyp2uTwIp3PqTcBTlApEtevYGPni3mv9mIR1Bj7KxOZUeQP8qkVf2nMjdoPpArKaGY2CELJ9/39W4N6+VHoUxMRQjTYMOfG2B0FE/TthE0rjAYF2N9Yn04UHXcv4xheUQVRkwa4MViP8f0uzarx4WXz242VlFx8XRlVzA/8TtNsPQvo87kSp/68lBLXta1uOlfhji X-Received: by 10.50.23.104 with SMTP id l8mr4507308igf.31.1389174688869; Wed, 08 Jan 2014 01:51:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Wed, 8 Jan 2014 01:51:07 -0800 (PST) In-Reply-To: <20140108.104016.74707582.sthaug@nethelp.no> References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <20140108.104016.74707582.sthaug@nethelp.no> From: Lorenzo Colitti Date: Wed, 8 Jan 2014 18:51:07 +0900 Message-ID: To: sthaug@nethelp.no Content-Type: multipart/alternative; boundary=089e0149cbe4dc90bd04ef726fc8 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 09:51:40 -0000 --089e0149cbe4dc90bd04ef726fc8 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 8, 2014 at 6:40 PM, wrote: > The authors may well agree that this a DHCPv6-only configuration without > RAs doesn't do anything useful. I'd be inclined to agree *today* - but I > certainly wouldn't want to rule out DHCPv6-only configuration without > RAs in the future. > It's not the role of an operational group to surmise on what future standards might exist, or to make future standards. So I agree this document shouldn't rule out DHCPv6-only configuration. But for precisely the same reason, it should also not imply that it may exist in the future. So the correct course of action is to remove it, because it is inappropriate to cite something that's not a standard (and, given *years* of lack of consensus, is unlikely to become a standard anytime soon) in an operational guidance document. > > Can you remove it, then? As an operational group we don't want to provide > > guidance on invalid use cases. :-) > > Removing it is not going to make the demand for DHCPv6-only configuration > without RAs magically disapppear. > Sure, but v6ops doesn't do protocol work. That discussion belongs in 6man. And until 6man has that discussion and changes the standards, then DHCPv6-only configuration is not a standard and it's inappropriate to cite it in an operational guidance document. --089e0149cbe4dc90bd04ef726fc8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 8, 2014 at 6:40 PM, <sthaug@nethelp.no> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
The authors may well = agree that this a DHCPv6-only configuration without
RAs doesn't do anything useful. I'd be inclined to agree *today* - = but I
certainly wouldn't want to rule out DHCPv6-only configuration without RAs in the future.

It's not the rol= e of an operational group to surmise on what future standards might exist, = or to make future standards. So I agree this document shouldn't rule ou= t DHCPv6-only configuration. But for precisely the same reason, it should a= lso not imply that it may exist in the future.

So the correct course of action is to remove it, becaus= e it is inappropriate to cite something that's not a standard (and, giv= en *years* of lack of consensus, is unlikely to become a standard anytime s= oon) in an operational guidance document.
=C2=A0
> Can you remove it, then? As an operational group we = don't want to provide
> guidance on invalid use cases. :-)

Removing it is not going to make the demand for DHCPv6-only configura= tion
without RAs magically disapppear.

Sure,= but v6ops doesn't do protocol work. That discussion belongs in 6man. A= nd until 6man has that discussion and changes the standards, then DHCPv6-on= ly configuration is not a standard and it's inappropriate to cite it in= an operational guidance document.
--089e0149cbe4dc90bd04ef726fc8-- From otroan@employees.org Wed Jan 8 03:22:48 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851F21AE2E6 for ; Wed, 8 Jan 2014 03:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4F-OxEDgFDk for ; Wed, 8 Jan 2014 03:22:46 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7711AE2A1 for ; Wed, 8 Jan 2014 03:22:46 -0800 (PST) Received: from dhcp-lys01-vla250-10-147-113-220.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id BC0A2A93A; Wed, 8 Jan 2014 02:54:06 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_95968B99-F6E1-4D01-9759-A0DB19D24232"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ole Troan In-Reply-To: Date: Wed, 8 Jan 2014 11:54:03 +0100 Message-Id: References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <20140108.104016.74707582.sthaug@nethelp.no> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1827) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 11:22:48 -0000 --Apple-Mail=_95968B99-F6E1-4D01-9759-A0DB19D24232 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > The authors may well agree that this a DHCPv6-only configuration = without > RAs doesn't do anything useful. I'd be inclined to agree *today* - but = I > certainly wouldn't want to rule out DHCPv6-only configuration without > RAs in the future. >=20 > It's not the role of an operational group to surmise on what future = standards might exist, or to make future standards. So I agree this = document shouldn't rule out DHCPv6-only configuration. But for precisely = the same reason, it should also not imply that it may exist in the = future. >=20 > So the correct course of action is to remove it, because it is = inappropriate to cite something that's not a standard (and, given = *years* of lack of consensus, is unlikely to become a standard anytime = soon) in an operational guidance document. >=20 >> Can you remove it, then? As an operational group we don't want to = provide >> guidance on invalid use cases. :-) >=20 > Removing it is not going to make the demand for DHCPv6-only = configuration > without RAs magically disapppear. >=20 > Sure, but v6ops doesn't do protocol work. That discussion belongs in = 6man. And until 6man has that discussion and changes the standards, then = DHCPv6-only configuration is not a standard and it's inappropriate to = cite it in an operational guidance document. I would expect the operational working group to come up with the problem = statement / use cases. those I have not seen yet, at least no in a language I can understand. cheers, Ole --Apple-Mail=_95968B99-F6E1-4D01-9759-A0DB19D24232 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSzS5LAAoJEFuJXizso86g9E8H/i2XtB6A2g9n2K7q012ctLxo 1bYwHKwWfEIk2oROea4toN1/QIKSpYrOQBT19JgggJcChm5h6Xn6VgJYYjNoa5E7 p8VHoJJC0+lbXZTsug3PRdnfqDuUVMznJ8WRrOIpQPsS6eMuGQicemkeLhoz52qL D1uJUenJitCJiZYcCn7SMYS3E1lflS3vM9GcRtoaSTWee7X50oTyJ5YL54RkaN7J Q0tYM2L5Q7MN4PjNoeYAOoGG8hNDHRrstHGdersiM6gpsuduDr9vmqBQl7IwguSg BnjGm9dFnIoquWj0tVC/Oled3pYkvhc4R7+b9HjFyo7LVJcNFDJaDIrqkcQG7Nw= =Arqp -----END PGP SIGNATURE----- --Apple-Mail=_95968B99-F6E1-4D01-9759-A0DB19D24232-- From alexandru.petrescu@gmail.com Wed Jan 8 04:46:35 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D2F1AE24D for ; Wed, 8 Jan 2014 04:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRBXQ5G962dx for ; Wed, 8 Jan 2014 04:46:34 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id C1ABC1AE375 for ; Wed, 8 Jan 2014 04:46:33 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s08CkNTN012029 for ; Wed, 8 Jan 2014 13:46:23 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 67EC42060E6 for ; Wed, 8 Jan 2014 13:47:23 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 601F620601B for ; Wed, 8 Jan 2014 13:47:23 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s08CkKRN028901 for ; Wed, 8 Jan 2014 13:46:23 +0100 Message-ID: <52CD489C.4030108@gmail.com> Date: Wed, 08 Jan 2014 13:46:20 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 12:46:35 -0000 Le 08/01/2014 08:05, Lorenzo Colitti a écrit : > Authors, > > I see this document has a "Guidance for DHCPv6-only Deployment" section > which mentions "DHCPv6-only configuration without RAs". Three points on > that: > > 1. We had a discussion on this topic when discussing the problem > statement draft a couple of weeks ago, and I thought we had agreed that > a DHCPv6-only configuration without RAs doesn't do anything useful at > all, and since it doesn't do anything useful at all, it should not be > documented. See for example at > http://www.ietf.org/mail-archive/web/v6ops/current/msg18231.html > > If it's not documented in the problem statement document because it > doesn't do anything useful, then it certainly should not be documented > in the guidance to operators document. And in fact, the draft already > states that "this is an invalid use case". > > Can you remove it, then? As an operational group we don't want to > provide guidance on invalid use cases. :-) > > > 2. That section should also make it clear that in a DHCPv6-only deployment: > > * If there is no RA, the addresses assigned by DHCPv6 cannot be used > for anything at all. Lorenzo - you keep saying that but does it have any practical basis? Have you tried it? Alex > * If there is an RA that specifies a default router but does not > specify the on-link prefix, then all traffic, even between hosts on > the same link, is routed at layer 3 by the default gateway. > > > 3. Please do not cite [DHCPv6-ROUTE]. That document was so controversial > that it was removed from the WG's charter and is no longer a WG item, so > it is inappropriate to cite it in an operational guidance document. > > Cheers, > Lorenzo > > > On Mon, Jan 6, 2014 at 4:59 PM, Liubing (Leo) > wrote: > > Hi Dear All, > > In ietf88 meeting, we discussed > draft-liu-bonica-dhcpv6-slaac-problem which indicated the hosts' > behavior might varied on DHCPv6/SLAAC interaction caused by > ambiguous standard definition. (The draft was adopted as > ietf-v6ops-dhcpv6-slaac-problem after the meeting.) > > Since the above draft is only filed as a Problem Statement document, > as discussed in the meeting, the WG decided to initiate another > draft to provide some operational guidance of what the > administrators should do given the fact that the host behavior might > varied in some situations. > > So this is the 00 version. Hope you can read it and comment. > Your review and comments would be appreciated very much. > > And a late happy new year to you all. > > Best regards > Bing > > > > -----Original Message----- > > From: v6ops [mailto:v6ops-bounces@ietf.org > ] On Behalf Of fred@cisco.com > > > Sent: Wednesday, December 25, 2013 9:45 PM > > To: v6ops@ietf.org > > Cc: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org > > > Subject: [v6ops] new draft: draft-liu-v6ops-dhcpv6-slaac-guidance > > > > > > A new draft has been posted, at > > http://tools.ietf.org/html/draft-liu-v6ops-dhcpv6-slaac-guidance. > Please > > take a look at it and comment. > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From sthaug@nethelp.no Wed Jan 8 05:02:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E56D1AE37F for ; Wed, 8 Jan 2014 05:02:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftYuLyDp_ooU for ; Wed, 8 Jan 2014 05:02:26 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id D18F81AE384 for ; Wed, 8 Jan 2014 05:02:25 -0800 (PST) Received: (qmail 47291 invoked from network); 8 Jan 2014 13:02:14 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 8 Jan 2014 13:02:14 -0000 Date: Wed, 08 Jan 2014 14:02:14 +0100 (CET) Message-Id: <20140108.140214.74708195.sthaug@nethelp.no> To: alexandru.petrescu@gmail.com From: sthaug@nethelp.no In-Reply-To: <52CD489C.4030108@gmail.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <52CD489C.4030108@gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 13:02:28 -0000 > > 2. That section should also make it clear that in a DHCPv6-only deployment: > > > > * If there is no RA, the addresses assigned by DHCPv6 cannot be used > > for anything at all. > > Lorenzo - you keep saying that but does it have any practical basis? > Have you tried it? I believe the idea here is that without RA: - you don't have a default gateway - you cannot determine what prefixes are on-link/off-link Steinar Haug, AS2116 From lorenzo@google.com Wed Jan 8 05:33:16 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6108B1AE3A5 for ; Wed, 8 Jan 2014 05:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KO6-o1QLYlXn for ; Wed, 8 Jan 2014 05:33:13 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id C500F1AE3A6 for ; Wed, 8 Jan 2014 05:33:13 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id as1so1957133iec.13 for ; Wed, 08 Jan 2014 05:33:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yCq0zR6UlKJdseUmAV/6jr7X00ZwqLSd9KFaGtye2G0=; b=EJOHdWun6pPq0xbPr5u7GfcXITqSomjsWVKf1MwSr0bZlJpzQKZfYhYDR/Xka4Z46p t9OUVV0iPa8yNqZSoP3YaDY3SdLJKqXaDefeD+fEYgAzQSt0x17gWlKOAF4fZQjqxjrn ObYyYLzWz6lbD6ztWHYc3ldFmb9lLNn/9NIrAJ3Xy8VsmTIO/6sSLWlsW56nCimjgWKX Dlp1OibYFvyLIFcpj6o2Hqg5/uw8sZYDDpuiydTuTawVAhx7KiPqNCgfpLxYcQ+XOmSm e9nc21NTc6GWvYYWzERB1E+yMf8kjVuaDVJm5bBVeoxwY7Pkh8nf92Fzah8d8jvMKiiI Q2Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yCq0zR6UlKJdseUmAV/6jr7X00ZwqLSd9KFaGtye2G0=; b=jo8fc9ivJ0NIILXiMRS+ZiM4+qtZTVlYQb7ZGfeT8Jk3BaCiji/7BAwTXhNyt4R8Pp Y3/SzDFB6ZmumHcZDWqzQePJOuXakEN8rpmQMyaGi+pIcfTy3ccsCfif0V6z1u9ttw+q j7JkImtVYQS0O2zzBhGs7FtJ/zSEs6d6nT8Dz/Rw/QwzpbcfffFMppGH8beJoymHt9gD oIusH2Uw1nWgmXnuXAe5GHVREN35+H42dsyJe1LkHpLkJiFrx9f6jE0V/hIF5ktBDVGq bf2Or17/5YyxVU8DwYsdDhmukylWFZVlyikJCY+jDpPlxw+VzUQSmi0Z1nrYx6c5AG1W wLww== X-Gm-Message-State: ALoCoQlOLKYhBOUuszCzJmhTvdSLHqXshTED/cTGz9vnYkH7u0iwWJlKhm1vnuBVVhzEST7yHrvcSS5qd9wlcmCXWCaqxjy6j7HBzA761D/umiZb78D0sk8KszptS63WctiywQGRIzBqFJ237VpHpsCqbBLrquiY+DBCcLFpY+zHAyThiHhALVP57k9Do4V9p6e/IWhGf+2H X-Received: by 10.50.23.104 with SMTP id l8mr5661157igf.31.1389187984453; Wed, 08 Jan 2014 05:33:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Wed, 8 Jan 2014 05:32:44 -0800 (PST) In-Reply-To: <52CD489C.4030108@gmail.com> References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <52CD489C.4030108@gmail.com> From: Lorenzo Colitti Date: Wed, 8 Jan 2014 22:32:44 +0900 Message-ID: To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=089e0149cbe4573c6b04ef75887f Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 13:33:16 -0000 --089e0149cbe4573c6b04ef75887f Content-Type: text/plain; charset=UTF-8 On Wed, Jan 8, 2014 at 9:46 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > * If there is no RA, the addresses assigned by DHCPv6 cannot be used >> for anything at all. >> > > Lorenzo - you keep saying that but does it have any practical basis? Have > you tried it? > http://tools.ietf.org/html/rfc4943#section-4 : The result of these changes is that destinations are considered unreachable when there is no routing information for that destination (through a default router or otherwise)." Since DHCPv6 does not configure routing, if all you have is addresses from DHCPv6 and no RA, then all destinations are unreachable. --089e0149cbe4573c6b04ef75887f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 8, 2014 at 9:46 PM, Alexandru Petrescu <alexandru.petre= scu@gmail.com> wrote:
=C2=A0 * If there is no RA, the addresses assigned by DHCPv6 cannot be used=
=C2=A0 =C2=A0 for anything at all.

Lorenzo - you keep saying that but does it have any practical basis? Have y= ou tried it?


=C2=A0=C2=A0 The result of these changes is that destin= ations are considered
=C2=A0 =C2=A0unreachable when there is no r= outing information for that destination
=C2=A0 =C2=A0(through a d= efault router or otherwise)."

Since DHCPv6 does not configure routing, if all you hav= e is addresses from DHCPv6 and no RA, then all destinations are unreachable= .
--089e0149cbe4573c6b04ef75887f-- From leo.liubing@huawei.com Wed Jan 8 05:39:55 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F07C1AE3B4 for ; Wed, 8 Jan 2014 05:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LU_e3xEPTDtW for ; Wed, 8 Jan 2014 05:39:51 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCF21AE33D for ; Wed, 8 Jan 2014 05:39:50 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCH25444; Wed, 08 Jan 2014 13:39:40 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 8 Jan 2014 13:39:15 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 8 Jan 2014 13:39:39 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.72]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Wed, 8 Jan 2014 21:39:35 +0800 From: "Liubing (Leo)" To: Lorenzo Colitti Thread-Topic: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance Thread-Index: AQHPDEAXxSskx4jQs0+XEKzlvRgebpp6zyGg Date: Wed, 8 Jan 2014 13:39:34 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7@nkgeml506-mbx.china.huawei.com> References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 13:39:55 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7nkgeml506mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9yZW56bywNCg0KVGhhbmtzIG11Y2ggZm9yIHlvdXIgcmV2aWV3IGFuZCBjb21tZW50cy4N ClBsZWFzZSBzZWUgcmVwbGllcyBpbmxpbmUuDQoNCkZyb206IExvcmVuem8gQ29saXR0aSBbbWFp bHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAwOCwgMjAx NCAzOjA2IFBNDQpUbzogTGl1YmluZyAoTGVvKQ0KQ2M6IHY2b3BzQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW3Y2b3BzXSBESENQdjYvU0xBQUMgSW50ZXJhY3Rpb24gT3BlcmF0aW9uYWwgR3VpZGFu Y2UtLy9SRTogbmV3IGRyYWZ0OiBkcmFmdC1saXUtdjZvcHMtZGhjcHY2LXNsYWFjLWd1aWRhbmNl DQoNCkF1dGhvcnMsDQoNCkkgc2VlIHRoaXMgZG9jdW1lbnQgaGFzIGEgIkd1aWRhbmNlIGZvciBE SENQdjYtb25seSBEZXBsb3ltZW50IiBzZWN0aW9uIHdoaWNoIG1lbnRpb25zICJESENQdjYtb25s eSBjb25maWd1cmF0aW9uIHdpdGhvdXQgUkFzIi4gVGhyZWUgcG9pbnRzIG9uIHRoYXQ6DQoNCjEu IFdlIGhhZCBhIGRpc2N1c3Npb24gb24gdGhpcyB0b3BpYyB3aGVuIGRpc2N1c3NpbmcgdGhlIHBy b2JsZW0gc3RhdGVtZW50IGRyYWZ0IGEgY291cGxlIG9mIHdlZWtzIGFnbywgYW5kIEkgdGhvdWdo dCB3ZSBoYWQgYWdyZWVkIHRoYXQgYSBESENQdjYtb25seSBjb25maWd1cmF0aW9uIHdpdGhvdXQg UkFzIGRvZXNuJ3QgZG8gYW55dGhpbmcgdXNlZnVsIGF0IGFsbCwgYW5kIHNpbmNlIGl0IGRvZXNu J3QgZG8gYW55dGhpbmcgdXNlZnVsIGF0IGFsbCwgaXQgc2hvdWxkIG5vdCBiZSBkb2N1bWVudGVk LiBTZWUgZm9yIGV4YW1wbGUgYXQgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L3Y2b3BzL2N1cnJlbnQvbXNnMTgyMzEuaHRtbA0KW0JpbmddIFllcyBJIHJlbWVtYmVyIHRoZSBk aXNjdXNzaW9uIGEgY291cGxlIG9mIHdlZWtzIGFnby4gQW5kIHRoZSBhYm92ZSBzZW50ZW5jZSDi gJx0aGlzIGlzIGFuIGludmFsaWQgdXNlIGNhc2XigJ0gaXMganVzdCB0byByZWZsZWN0IHRoZSBk aXNjdXNzaW9uIHJlc3VsdC4NCg0KSWYgaXQncyBub3QgZG9jdW1lbnRlZCBpbiB0aGUgcHJvYmxl bSBzdGF0ZW1lbnQgZG9jdW1lbnQgYmVjYXVzZSBpdCBkb2Vzbid0IGRvIGFueXRoaW5nIHVzZWZ1 bCwgdGhlbiBpdCBjZXJ0YWlubHkgc2hvdWxkIG5vdCBiZSBkb2N1bWVudGVkIGluIHRoZSBndWlk YW5jZSB0byBvcGVyYXRvcnMgZG9jdW1lbnQuIEFuZCBpbiBmYWN0LCB0aGUgZHJhZnQgYWxyZWFk eSBzdGF0ZXMgdGhhdCAidGhpcyBpcyBhbiBpbnZhbGlkIHVzZSBjYXNlIi4NCg0KQ2FuIHlvdSBy ZW1vdmUgaXQsIHRoZW4/IEFzIGFuIG9wZXJhdGlvbmFsIGdyb3VwIHdlIGRvbid0IHdhbnQgdG8g cHJvdmlkZSBndWlkYW5jZSBvbiBpbnZhbGlkIHVzZSBjYXNlcy4gOi0pDQpbQmluZ10gSSBhZ3Jl ZSB3aXRoIHlvdSB0aGF0IOKAnERIQ1B2Ni1vbmx5IHdpdGhvdXQgUkHigJ0gc2hvdWxkIG5vdCBi ZSBpZGVudGlmaWVkIGFzIGEgdmFsaWQgdXNlIGNhc2UuIEJ1dCBpbiB0aGUgZG9jdW1lbnQsIHdo YXQgd2Ugd2FudCB0byBjYXV0aW9uIHRoZSByZWFkZXIgaXMgdGhhdCBzb21lIG9wZXJhdGluZyBz eXN0ZW1zIHdvdWxkIHJlbHkgUkFzIHRvIHRyaWdnZXIgREhDUHY2LiBJIHRoaW5rIOKAnFJBcyBh cmUgbmVjZXNzYXJ5IGZvciBJUHY2IGNvbmZpZ3VyYXRpb27igJ0gIGFuZCDigJxSQXMgYXJlIG5l Y2Vzc2FyeSB0byB0cmlnZ2VyIERIQ1B2NuKAnSBhcmUgdHdvIGRpZmZlcmVudCB0aGluZ3MgaW4g Y29uY2VwdC4gV2UganVzdCB3YW50IHRvIGVtcGhhc2l6ZSB0aGUgbGF0dGVyIG9uZS4gTWF5YmUg aXQgaXMgYSBsaXR0bGUgcmVkdW5kYW50IGluIHdvcmRpbmcsIGJ1dCBhdCBsZWFzdCBpdCBpcyBu b3QgaGFybWZ1bD8gRXNwZWNpYWxseSBjb25zaWRlcmluZyB0aGF0IGluIHJlYWwgcHJhY3RpY2Us IGFkbWlucyBjb3VsZCBlbmFibGUgcm91dGluZyBjb25maWd1cmF0aW9uIGluIERIQ1B2NiBieSBw cml2YXRlL2N1c3RvbWl6ZWQgZXh0ZW5zaW9uIChJU0MgZGhjcGQgJiBkaWJibGVyIGJvdGggcHJv dmlkZSB0aGUgY2FwYWJpbGl0eSkgLiBJIHRoaW5rIG1heWJlIHRoZSByZWR1bmRhbmN5IHdvcmRp bmcgY291bGQgYmUgdXNlZnVsIGZvciB0aGUgc2l0dWF0aW9ucy4NCg0KQmVzdCBSZWdhcmRzLA0K QmluZw0KDQoyLiBUaGF0IHNlY3Rpb24gc2hvdWxkIGFsc28gbWFrZSBpdCBjbGVhciB0aGF0IGlu IGEgREhDUHY2LW9ubHkgZGVwbG95bWVudDoNCg0KICAqICAgSWYgdGhlcmUgaXMgbm8gUkEsIHRo ZSBhZGRyZXNzZXMgYXNzaWduZWQgYnkgREhDUHY2IGNhbm5vdCBiZSB1c2VkIGZvciBhbnl0aGlu ZyBhdCBhbGwuDQogICogICBJZiB0aGVyZSBpcyBhbiBSQSB0aGF0IHNwZWNpZmllcyBhIGRlZmF1 bHQgcm91dGVyIGJ1dCBkb2VzIG5vdCBzcGVjaWZ5IHRoZSBvbi1saW5rIHByZWZpeCwgdGhlbiBh bGwgdHJhZmZpYywgZXZlbiBiZXR3ZWVuIGhvc3RzIG9uIHRoZSBzYW1lIGxpbmssIGlzIHJvdXRl ZCBhdCBsYXllciAzIGJ5IHRoZSBkZWZhdWx0IGdhdGV3YXkuDQoNCjMuIFBsZWFzZSBkbyBub3Qg Y2l0ZSBbREhDUHY2LVJPVVRFXS4gVGhhdCBkb2N1bWVudCB3YXMgc28gY29udHJvdmVyc2lhbCB0 aGF0IGl0IHdhcyByZW1vdmVkIGZyb20gdGhlIFdHJ3MgY2hhcnRlciBhbmQgaXMgbm8gbG9uZ2Vy IGEgV0cgaXRlbSwgc28gaXQgaXMgaW5hcHByb3ByaWF0ZSB0byBjaXRlIGl0IGluIGFuIG9wZXJh dGlvbmFsIGd1aWRhbmNlIGRvY3VtZW50Lg0KDQpDaGVlcnMsDQpMb3JlbnpvDQoNCk9uIE1vbiwg SmFuIDYsIDIwMTQgYXQgNDo1OSBQTSwgTGl1YmluZyAoTGVvKSA8bGVvLmxpdWJpbmdAaHVhd2Vp LmNvbTxtYWlsdG86bGVvLmxpdWJpbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KSGkgRGVhciBBbGws DQoNCkluIGlldGY4OCBtZWV0aW5nLCB3ZSBkaXNjdXNzZWQgZHJhZnQtbGl1LWJvbmljYS1kaGNw djYtc2xhYWMtcHJvYmxlbSB3aGljaCBpbmRpY2F0ZWQgdGhlIGhvc3RzJyBiZWhhdmlvciBtaWdo dCB2YXJpZWQgb24gREhDUHY2L1NMQUFDIGludGVyYWN0aW9uIGNhdXNlZCBieSBhbWJpZ3VvdXMg c3RhbmRhcmQgZGVmaW5pdGlvbi4gKFRoZSBkcmFmdCB3YXMgYWRvcHRlZCBhcyBpZXRmLXY2b3Bz LWRoY3B2Ni1zbGFhYy1wcm9ibGVtIGFmdGVyIHRoZSBtZWV0aW5nLikNCg0KU2luY2UgdGhlIGFi b3ZlIGRyYWZ0IGlzIG9ubHkgZmlsZWQgYXMgYSBQcm9ibGVtIFN0YXRlbWVudCBkb2N1bWVudCwg YXMgZGlzY3Vzc2VkIGluIHRoZSBtZWV0aW5nLCB0aGUgV0cgZGVjaWRlZCB0byBpbml0aWF0ZSBh bm90aGVyIGRyYWZ0IHRvIHByb3ZpZGUgc29tZSBvcGVyYXRpb25hbCBndWlkYW5jZSBvZiB3aGF0 IHRoZSBhZG1pbmlzdHJhdG9ycyBzaG91bGQgZG8gZ2l2ZW4gdGhlIGZhY3QgdGhhdCB0aGUgaG9z dCBiZWhhdmlvciBtaWdodCB2YXJpZWQgaW4gc29tZSBzaXR1YXRpb25zLg0KDQpTbyB0aGlzIGlz IHRoZSAwMCB2ZXJzaW9uLiBIb3BlIHlvdSBjYW4gcmVhZCBpdCBhbmQgY29tbWVudC4NCllvdXIg cmV2aWV3IGFuZCBjb21tZW50cyB3b3VsZCBiZSBhcHByZWNpYXRlZCB2ZXJ5IG11Y2guDQoNCkFu ZCBhIGxhdGUgaGFwcHkgbmV3IHllYXIgdG8geW91IGFsbC4NCg0KQmVzdCByZWdhcmRzDQpCaW5n DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB2Nm9wcyBbbWFpbHRv OnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc+XSBP biBCZWhhbGYgT2YgZnJlZEBjaXNjby5jb208bWFpbHRvOmZyZWRAY2lzY28uY29tPg0KPiBTZW50 OiBXZWRuZXNkYXksIERlY2VtYmVyIDI1LCAyMDEzIDk6NDUgUE0NCj4gVG86IHY2b3BzQGlldGYu b3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCj4gQ2M6IGRyYWZ0LWxpdS12Nm9wcy1kaGNwdjYt c2xhYWMtZ3VpZGFuY2VAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWxpdS12Nm9wcy1kaGNw djYtc2xhYWMtZ3VpZGFuY2VAdG9vbHMuaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFt2Nm9wc10gbmV3 IGRyYWZ0OiBkcmFmdC1saXUtdjZvcHMtZGhjcHY2LXNsYWFjLWd1aWRhbmNlDQo+DQo+DQo+IEEg bmV3IGRyYWZ0IGhhcyBiZWVuIHBvc3RlZCwgYXQNCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtbGl1LXY2b3BzLWRoY3B2Ni1zbGFhYy1ndWlkYW5jZS4gUGxlYXNlDQo+IHRha2Ug YSBsb29rIGF0IGl0IGFuZCBjb21tZW50Lg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5v cmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Y2b3BzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQoN Cg== --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7nkgeml506mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwg ZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtaW5kZW50OjIxLjBwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyNDE3MTY0NTE7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOi0xMTU1NjA0MzU4O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoz Ni4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgTG9y ZW56byw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIG11Y2ggZm9y IHlvdXIgcmV2aWV3IGFuZCBjb21tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlBsZWFzZSBzZWUgcmVwbGllcyBpbmxpbmUuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NCjxi cj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEphbnVhcnkgMDgsIDIwMTQgMzowNiBQTTxicj4N CjxiPlRvOjwvYj4gTGl1YmluZyAoTGVvKTxicj4NCjxiPkNjOjwvYj4gdjZvcHNAaWV0Zi5vcmc8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gREhDUHY2L1NMQUFDIEludGVyYWN0aW9u IE9wZXJhdGlvbmFsIEd1aWRhbmNlLS8vUkU6IG5ldyBkcmFmdDogZHJhZnQtbGl1LXY2b3BzLWRo Y3B2Ni1zbGFhYy1ndWlkYW5jZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5BdXRob3JzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkg c2VlIHRoaXMgZG9jdW1lbnQgaGFzIGEgJnF1b3Q7R3VpZGFuY2UgZm9yIERIQ1B2Ni1vbmx5IERl cGxveW1lbnQmcXVvdDsgc2VjdGlvbiB3aGljaCBtZW50aW9ucyAmcXVvdDtESENQdjYtb25seSBj b25maWd1cmF0aW9uIHdpdGhvdXQgUkFzJnF1b3Q7LiBUaHJlZSBwb2ludHMgb24gdGhhdDo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjEuIFdlIGhhZCBh IGRpc2N1c3Npb24gb24gdGhpcyB0b3BpYyB3aGVuIGRpc2N1c3NpbmcgdGhlIHByb2JsZW0gc3Rh dGVtZW50IGRyYWZ0IGEgY291cGxlIG9mIHdlZWtzIGFnbywgYW5kIEkgdGhvdWdodCB3ZSBoYWQg YWdyZWVkIHRoYXQgYSBESENQdjYtb25seSBjb25maWd1cmF0aW9uIHdpdGhvdXQgUkFzIGRvZXNu J3QgZG8gYW55dGhpbmcgdXNlZnVsIGF0IGFsbCwgYW5kIHNpbmNlDQogaXQgZG9lc24ndCBkbyBh bnl0aGluZyB1c2VmdWwgYXQgYWxsLCBpdCBzaG91bGQgbm90IGJlIGRvY3VtZW50ZWQuIFNlZSBm b3IgZXhhbXBsZSBhdA0KPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL3Y2b3BzL2N1cnJlbnQvbXNnMTgyMzEuaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL3Y2b3BzL2N1cnJlbnQvbXNnMTgyMzEuaHRtbDwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltCaW5nXSBZZXMgSSByZW1lbWJlciB0aGUg ZGlzY3Vzc2lvbiBhIGNvdXBsZSBvZiB3ZWVrcyBhZ28uIEFuZCB0aGUgYWJvdmUgc2VudGVuY2Ug 4oCcdGhpcyBpcyBhbiBpbnZhbGlkIHVzZSBjYXNl4oCdIGlzIGp1c3QgdG8gcmVmbGVjdCB0aGUg ZGlzY3Vzc2lvbg0KIHJlc3VsdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPklmIGl0J3Mgbm90IGRvY3VtZW50ZWQgaW4gdGhlIHByb2JsZW0gc3RhdGVt ZW50IGRvY3VtZW50IGJlY2F1c2UgaXQgZG9lc24ndCBkbyBhbnl0aGluZyB1c2VmdWwsIHRoZW4g aXQgY2VydGFpbmx5IHNob3VsZCBub3QgYmUgZG9jdW1lbnRlZCBpbiB0aGUgZ3VpZGFuY2UgdG8g b3BlcmF0b3JzIGRvY3VtZW50LiBBbmQgaW4gZmFjdCwgdGhlIGRyYWZ0IGFscmVhZHkgc3RhdGVz IHRoYXQNCiAmcXVvdDt0aGlzIGlzIGFuIGludmFsaWQgdXNlIGNhc2UmcXVvdDsuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5DYW4geW91IHJlbW92ZSBp dCwgdGhlbj8gQXMgYW4gb3BlcmF0aW9uYWwgZ3JvdXAgd2UgZG9uJ3Qgd2FudCB0byBwcm92aWRl IGd1aWRhbmNlIG9uIGludmFsaWQgdXNlIGNhc2VzLiA6LSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltCaW5nXSBJIGFncmVlIHdpdGgg eW91IHRoYXQg4oCcREhDUHY2LW9ubHkgd2l0aG91dCBSQeKAnSBzaG91bGQgbm90IGJlIGlkZW50 aWZpZWQgYXMgYSB2YWxpZCB1c2UgY2FzZS4gQnV0IGluIHRoZSBkb2N1bWVudCwgd2hhdCB3ZSB3 YW50IHRvIGNhdXRpb24NCiB0aGUgcmVhZGVyIGlzIHRoYXQgc29tZSBvcGVyYXRpbmcgc3lzdGVt cyB3b3VsZCByZWx5IFJBcyB0byB0cmlnZ2VyIERIQ1B2Ni4gSSB0aGluayDigJxSQXMgYXJlIG5l Y2Vzc2FyeSBmb3IgSVB2NiBjb25maWd1cmF0aW9u4oCdICZuYnNwO2FuZCDigJxSQXMgYXJlIG5l Y2Vzc2FyeSB0byB0cmlnZ2VyIERIQ1B2NuKAnSBhcmUgdHdvIGRpZmZlcmVudCB0aGluZ3MgaW4g Y29uY2VwdC4gV2UganVzdCB3YW50IHRvIGVtcGhhc2l6ZSB0aGUgbGF0dGVyIG9uZS4gTWF5YmUg aXQNCiBpcyBhIGxpdHRsZSByZWR1bmRhbnQgaW4gd29yZGluZywgYnV0IGF0IGxlYXN0IGl0IGlz IG5vdCBoYXJtZnVsPyBFc3BlY2lhbGx5IGNvbnNpZGVyaW5nIHRoYXQgaW4gcmVhbCBwcmFjdGlj ZSwgYWRtaW5zIGNvdWxkIGVuYWJsZSByb3V0aW5nIGNvbmZpZ3VyYXRpb24gaW4gREhDUHY2IGJ5 IHByaXZhdGUvY3VzdG9taXplZCBleHRlbnNpb24gKElTQyBkaGNwZCAmYW1wOyBkaWJibGVyIGJv dGggcHJvdmlkZSB0aGUgY2FwYWJpbGl0eSkgLiBJIHRoaW5rDQogbWF5YmUgdGhlIHJlZHVuZGFu Y3kgd29yZGluZyBjb3VsZCBiZSB1c2VmdWwgZm9yIHRoZSBzaXR1YXRpb25zLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZXN0IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CaW5nPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+Mi4gVGhhdCBzZWN0aW9uIHNob3VsZCBhbHNvIG1ha2UgaXQgY2xlYXIgdGhhdCBpbiBhIERI Q1B2Ni1vbmx5IGRlcGxveW1lbnQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+SWYgdGhlcmUgaXMgbm8gUkEsIHRoZSBh ZGRyZXNzZXMgYXNzaWduZWQgYnkgREhDUHY2IGNhbm5vdCBiZSB1c2VkIGZvciBhbnl0aGluZyBh dCBhbGwuPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1s aXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj5JZiB0aGVyZSBpcyBhbiBS QSB0aGF0IHNwZWNpZmllcyBhIGRlZmF1bHQgcm91dGVyIGJ1dCBkb2VzIG5vdCBzcGVjaWZ5IHRo ZSBvbi1saW5rIHByZWZpeCwgdGhlbiBhbGwgdHJhZmZpYywgZXZlbiBiZXR3ZWVuIGhvc3RzIG9u IHRoZSBzYW1lIGxpbmssIGlzIHJvdXRlZCBhdCBsYXllciAzIGJ5IHRoZSBkZWZhdWx0IGdhdGV3 YXkuPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij4zLiBQbGVhc2UgZG8gbm90IGNpdGUgW0RIQ1B2Ni1ST1VURV0uIFRoYXQgZG9jdW1lbnQgd2Fz IHNvIGNvbnRyb3ZlcnNpYWwgdGhhdCBpdCB3YXMgcmVtb3ZlZCBmcm9tIHRoZSBXRydzIGNoYXJ0 ZXIgYW5kIGlzIG5vIGxvbmdlciBhIFdHIGl0ZW0sIHNvIGl0IGlzIGluYXBwcm9wcmlhdGUgdG8g Y2l0ZSBpdCBpbiBhbiBvcGVyYXRpb25hbCBndWlkYW5jZSBkb2N1bWVudC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNoZWVycyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+TG9yZW56bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBNb24sIEphbiA2LCAyMDE0 IGF0IDQ6NTkgUE0sIExpdWJpbmcgKExlbykgJmx0OzxhIGhyZWY9Im1haWx0bzpsZW8ubGl1Ymlu Z0BodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+bGVvLmxpdWJpbmdAaHVhd2VpLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5IaSBEZWFyIEFsbCw8YnI+DQo8YnI+DQpJbiBpZXRmODggbWVldGlu Zywgd2UgZGlzY3Vzc2VkIGRyYWZ0LWxpdS1ib25pY2EtZGhjcHY2LXNsYWFjLXByb2JsZW0gd2hp Y2ggaW5kaWNhdGVkIHRoZSBob3N0cycgYmVoYXZpb3IgbWlnaHQgdmFyaWVkIG9uIERIQ1B2Ni9T TEFBQyBpbnRlcmFjdGlvbiBjYXVzZWQgYnkgYW1iaWd1b3VzIHN0YW5kYXJkIGRlZmluaXRpb24u IChUaGUgZHJhZnQgd2FzIGFkb3B0ZWQgYXMgaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxl bSBhZnRlciB0aGUgbWVldGluZy4pPGJyPg0KPGJyPg0KU2luY2UgdGhlIGFib3ZlIGRyYWZ0IGlz IG9ubHkgZmlsZWQgYXMgYSBQcm9ibGVtIFN0YXRlbWVudCBkb2N1bWVudCwgYXMgZGlzY3Vzc2Vk IGluIHRoZSBtZWV0aW5nLCB0aGUgV0cgZGVjaWRlZCB0byBpbml0aWF0ZSBhbm90aGVyIGRyYWZ0 IHRvIHByb3ZpZGUgc29tZSBvcGVyYXRpb25hbCBndWlkYW5jZSBvZiB3aGF0IHRoZSBhZG1pbmlz dHJhdG9ycyBzaG91bGQgZG8gZ2l2ZW4gdGhlIGZhY3QgdGhhdCB0aGUgaG9zdCBiZWhhdmlvciBt aWdodA0KIHZhcmllZCBpbiBzb21lIHNpdHVhdGlvbnMuPGJyPg0KPGJyPg0KU28gdGhpcyBpcyB0 aGUgMDAgdmVyc2lvbi4gSG9wZSB5b3UgY2FuIHJlYWQgaXQgYW5kIGNvbW1lbnQuPGJyPg0KWW91 ciByZXZpZXcgYW5kIGNvbW1lbnRzIHdvdWxkIGJlIGFwcHJlY2lhdGVkIHZlcnkgbXVjaC48YnI+ DQo8YnI+DQpBbmQgYSBsYXRlIGhhcHB5IG5ldyB5ZWFyIHRvIHlvdSBhbGwuPGJyPg0KPGJyPg0K QmVzdCByZWdhcmRzPGJyPg0KQmluZzxicj4NCjxicj4NCjxicj4NCiZndDsgLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IHY2b3BzIFttYWlsdG86PGEgaHJlZj0ibWFp bHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmciPnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBP biBCZWhhbGYgT2YNCjxhIGhyZWY9Im1haWx0bzpmcmVkQGNpc2NvLmNvbSI+ZnJlZEBjaXNjby5j b208L2E+PGJyPg0KJmd0OyBTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDI1LCAyMDEzIDk6NDUg UE08YnI+DQomZ3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGll dGYub3JnPC9hPjxicj4NCiZndDsgQ2M6IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1saXUtdjZvcHMt ZGhjcHY2LXNsYWFjLWd1aWRhbmNlQHRvb2xzLmlldGYub3JnIj5kcmFmdC1saXUtdjZvcHMtZGhj cHY2LXNsYWFjLWd1aWRhbmNlQHRvb2xzLmlldGYub3JnPC9hPjxicj4NCiZndDsgU3ViamVjdDog W3Y2b3BzXSBuZXcgZHJhZnQ6IGRyYWZ0LWxpdS12Nm9wcy1kaGNwdjYtc2xhYWMtZ3VpZGFuY2U8 YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgQSBuZXcgZHJhZnQgaGFzIGJlZW4gcG9zdGVk LCBhdDxicj4NCiZndDsgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt bGl1LXY2b3BzLWRoY3B2Ni1zbGFhYy1ndWlkYW5jZSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGl1LXY2b3BzLWRoY3B2Ni1zbGFhYy1ndWlkYW5j ZTwvYT4uIFBsZWFzZTxicj4NCiZndDsgdGFrZSBhIGxvb2sgYXQgaXQgYW5kIGNvbW1lbnQuPGJy Pg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCiZndDsgdjZvcHMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86djZv cHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp2Nm9wcyBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdjZvcHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Y2b3BzPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7nkgeml506mbxchi_-- From alexandru.petrescu@gmail.com Wed Jan 8 07:02:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3A31AE417 for ; Wed, 8 Jan 2014 07:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjYWyBLvkb_o for ; Wed, 8 Jan 2014 07:02:42 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCA51AE416 for ; Wed, 8 Jan 2014 07:02:40 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s08F2TtR018724; Wed, 8 Jan 2014 16:02:29 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3D30120639C; Wed, 8 Jan 2014 16:03:29 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 27AC4206355; Wed, 8 Jan 2014 16:03:29 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s08F2Pjx032749; Wed, 8 Jan 2014 16:02:29 +0100 Message-ID: <52CD6882.2060000@gmail.com> Date: Wed, 08 Jan 2014 16:02:26 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <52CD489C.4030108@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 15:02:44 -0000 Le 08/01/2014 14:32, Lorenzo Colitti a écrit : > On Wed, Jan 8, 2014 at 9:46 PM, Alexandru Petrescu > > > wrote: > > * If there is no RA, the addresses assigned by DHCPv6 cannot be used > for anything at all. > > > Lorenzo - you keep saying that but does it have any practical basis? > Have you tried it? > > > http://tools.ietf.org/html/rfc4943#section-4 : > > The result of these changes is that destinations are considered > unreachable when there is no routing information for that > destination (through a default router or otherwise)." > > Since DHCPv6 does not configure routing, if all you have is addresses > from DHCPv6 and no RA, then all destinations are unreachable. Yes and no. Yes in that DHCPv6 would not configure routing as we speak. No, in that not only DHCPv6 configures routing these days. It may very well be that that routing be configured at link setup time by RFC-unspecified means (PPP negotiation, USB if-up, more), or by use of ICMP Redirect. Neither of these is RA. In this sense, it would be sufficient for DHCP to give an address, Client not read any RA, and still reach out. Alex From peter.vickers@gmail.com Wed Jan 8 07:04:14 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939861AE3F7 for ; Wed, 8 Jan 2014 07:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNdbwt22nLCx for ; Wed, 8 Jan 2014 07:04:13 -0800 (PST) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5881ADE84 for ; Wed, 8 Jan 2014 07:04:13 -0800 (PST) Received: by mail-la0-f48.google.com with SMTP id n7so1205745lam.21 for ; Wed, 08 Jan 2014 07:04:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=xhOA7yr7eOWjRRjWnOB4HKMfVCphp17K7jpYQaa7LEU=; b=UIRkR06+3V7hx6mlb593LD53W0uGGA+zMfC/cv89CbPCBhnEIbwZaJblXLn3A1nLAN prj5rLv4gzQB88XdHMjOqNBHok64I7V7ejRKj6TWgnoQ+7U+V1PSxb4e00MGhfWPY7lH +z49vkk0jBtSOlLFF7waSGdqAIoNvRAHmIwJCxXoKj7kjkMqj4vfyjE2rGkClmdlaGpU tr3L0Qt5Z0DYRcYBZGlzfZFJYCfLZ8eN5URBJjN1bdO5BqUfmGEvtnZBwovKJzxPAGId WN2X4aHtiCMPwxy3bnLMawGX43UqDSw6SAff80FaYsIpN2+pVFpTO55jsQgBSe/EgzgJ yqbw== X-Received: by 10.152.19.97 with SMTP id d1mr5795758lae.57.1389193443503; Wed, 08 Jan 2014 07:04:03 -0800 (PST) Received: from [192.168.100.251] ([195.214.204.17]) by mx.google.com with ESMTPSA id h11sm47120549lbg.8.2014.01.08.07.04.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Jan 2014 07:04:03 -0800 (PST) From: Pete Vickers Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> Date: Wed, 8 Jan 2014 16:04:02 +0100 To: "v6ops@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 15:04:14 -0000 Been lurking on this particular discussion for a while, however I think = this whole DHCPv6 without RAs is getting out of hand. Irrespective of if = someone has a corner case and would like to do away with their RA = dependance, doesn't mean that we should create a special case for it. = RAs exist and work, and are for a purpose. To use a bad theoretical = example, suppose I raised a request to remove ARP requirement in my = DHCPv4 deployment, and wanted instead a DHCP option to provide a/the = router's MAC address. I think we'd all agree that that would be rejected = and that I should just accept ARP and move on. Likewise here, just = accept that your IPv6 systems should use RAs and move on. All the = arguments I've seen around control and security should be addressed = elsewhere rather than trying to hardwire the RA process. /Pete= From alexandru.petrescu@gmail.com Wed Jan 8 07:05:11 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B50061AE410 for ; Wed, 8 Jan 2014 07:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Djj6C4tiq3R for ; Wed, 8 Jan 2014 07:05:10 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id F282F1AE402 for ; Wed, 8 Jan 2014 07:05:09 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s08F50Ix009425; Wed, 8 Jan 2014 16:05:00 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B0DDA20639A; Wed, 8 Jan 2014 16:05:59 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9B7DB2062EA; Wed, 8 Jan 2014 16:05:59 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s08F4xtG002275; Wed, 8 Jan 2014 16:04:59 +0100 Message-ID: <52CD691B.2090702@gmail.com> Date: Wed, 08 Jan 2014 16:04:59 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: sthaug@nethelp.no References: <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <52CD489C.4030108@gmail.com> <20140108.140214.74708195.sthaug@nethelp.no> In-Reply-To: <20140108.140214.74708195.sthaug@nethelp.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 15:05:11 -0000 Le 08/01/2014 14:02, sthaug@nethelp.no a écrit : >>> 2. That section should also make it clear that in a DHCPv6-only deployment: >>> >>> * If there is no RA, the addresses assigned by DHCPv6 cannot be used >>> for anything at all. >> >> Lorenzo - you keep saying that but does it have any practical basis? >> Have you tried it? > > I believe the idea here is that without RA: > > - you don't have a default gateway > - you cannot determine what prefixes are on-link/off-link Thanks for the clarification. The idea makes sense in a certain way in which only RA provides the default route, and only NS/NA provide the on-link determination. In some other way one could still get a default gateway without DHCP and without RA, and could determine on/off link by other existing means. Alex > > Steinar Haug, AS2116 > > From rajiva@cisco.com Wed Jan 8 07:10:57 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF6F1AE431 for ; Wed, 8 Jan 2014 07:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRVmpO920gO1 for ; Wed, 8 Jan 2014 07:10:55 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C06711AE438 for ; Wed, 8 Jan 2014 07:10:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1880; q=dns/txt; s=iport; t=1389193844; x=1390403444; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=dfEecXWLINez3mti1DS7cNFuJ2+4kd9ONyjP4CJBvs8=; b=muycvY2WncVUkCxNrMcSVM6EUs3/9rIkiMqT3GpiAC4n/ez70DmbeKum SpT+gOBEKoZjSKEwFy+GGVRVu9/8f9Fm4259JgO39OAKSwWiMI2wlfRTq wLfhGubZwP6o1yzzJLkM/68rc+CqxBR/nNlI9PAH2BwU2pyr3XdsbHMiN E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAMlpzVKtJXG9/2dsb2JhbABZgws4VrlvgRQWdIIlAQEBAwEBAQFrCwUHBgEIEQMBAiQsBgsdCAIEAQ0Fh3ADCQgNv3ANhHUTBIxygTxXBwaEMQSJC40ggWyMWoU7gW+BPoFpQQ X-IronPort-AV: E=Sophos;i="4.95,625,1384300800"; d="scan'208";a="296060332" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 08 Jan 2014 15:10:43 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s08FAhmX032754 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Jan 2014 15:10:43 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.165]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Wed, 8 Jan 2014 09:10:43 -0600 From: "Rajiv Asati (rajiva)" To: Alexandru Petrescu , "sthaug@nethelp.no" Thread-Topic: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance Thread-Index: AQHPAXeVQmo1lyuCJUK4K/NdSAAP8pp3YWwggAOAQ4CAAF85AIAABHEAgAAiTID//63DgA== Date: Wed, 8 Jan 2014 15:10:42 +0000 Message-ID: In-Reply-To: <52CD691B.2090702@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.82.218.9] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2181D18CCED5054DA37F5EB9F9F7C0CF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 15:10:57 -0000 > In some other way one could still get a default gateway without DHCP and > without RA, and could determine on/off link by other existing means. I am curious to know more about "other way" and "other existing means". ND (including RA) is there for a reason, so, what benefits are we trying to attain by replacing them with something else? IMHO, we should strive to limit our protocol choices, not increase them. This doesn't bode well for implementations. --=20 Cheers, Rajiv =20 -----Original Message----- From: Alexandru Petrescu Date: Wednesday, January 8, 2014 10:04 AM To: "sthaug@nethelp.no" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance >Le 08/01/2014 14:02, sthaug@nethelp.no a =E9crit : >>>> 2. That section should also make it clear that in a DHCPv6-only >>>>deployment: >>>> >>>> * If there is no RA, the addresses assigned by DHCPv6 cannot be >>>>used >>>> for anything at all. >>> >>> Lorenzo - you keep saying that but does it have any practical basis? >>> Have you tried it? >> >> I believe the idea here is that without RA: >> >> - you don't have a default gateway >> - you cannot determine what prefixes are on-link/off-link > >Thanks for the clarification. The idea makes sense in a certain way in >which only RA provides the default route, and only NS/NA provide the >on-link determination. > >In some other way one could still get a default gateway without DHCP and >without RA, and could determine on/off link by other existing means. > >Alex > >> >> Steinar Haug, AS2116 >> >> > > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From alexandru.petrescu@gmail.com Wed Jan 8 07:38:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701E41AE4BD for ; Wed, 8 Jan 2014 07:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7G8xlBp7RFQJ for ; Wed, 8 Jan 2014 07:38:30 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 19ECB1ADF7D for ; Wed, 8 Jan 2014 07:38:29 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s08FcJDA026630; Wed, 8 Jan 2014 16:38:19 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5984E206366; Wed, 8 Jan 2014 16:39:19 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4DAEC206319; Wed, 8 Jan 2014 16:39:19 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s08FcFqQ026944; Wed, 8 Jan 2014 16:38:19 +0100 Message-ID: <52CD70E7.6090406@gmail.com> Date: Wed, 08 Jan 2014 16:38:15 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Pete Vickers , "v6ops@ietf.org" References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> In-Reply-To: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 15:38:32 -0000 Le 08/01/2014 16:04, Pete Vickers a écrit : > > Been lurking on this particular discussion for a while, however I > think this whole DHCPv6 without RAs is getting out of hand. > Irrespective of if someone has a corner case and would like to do > away with their RA dependance, doesn't mean that we should create a > special case for it. RAs exist and work, and are for a purpose. To > use a bad theoretical example, suppose I raised a request to remove > ARP requirement in my DHCPv4 deployment, and wanted instead a DHCP > option to provide a/the router's MAC address. I think we'd all agree > that that would be rejected and that I should just accept ARP and > move on. Likewise here, just accept that your IPv6 systems should > use RAs and move on. All the arguments I've seen around control and > security should be addressed elsewhere rather than trying to hardwire > the RA process. I do not discuss along DHCPv6 vs RA. That's hard to converge. However, discussion whether DHCP-only deployments are possible, in theory or otherwise, may not be that mean. Just as we state RA-only deployments are the way to be we can also ack that DHCP-only deployments do work. One particular enterprise does RA everywhere - congratulations to them. I am seriously happy for them and would be proud to work there and tell everybody how great that is. That does not mean there are not other settings where RA everywhere is hardly feasible. It has to do with many technical and non technical criteria. Alex > > /Pete _______________________________________________ v6ops mailing > list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From alexandru.petrescu@gmail.com Wed Jan 8 07:44:41 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF59D1AD9AD for ; Wed, 8 Jan 2014 07:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVanpek0_ArJ for ; Wed, 8 Jan 2014 07:44:41 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 348361AD627 for ; Wed, 8 Jan 2014 07:44:39 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s08FiRJU002094; Wed, 8 Jan 2014 16:44:27 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C532E20641A; Wed, 8 Jan 2014 16:45:26 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id ADA1E203285; Wed, 8 Jan 2014 16:45:26 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s08FiNAA031780; Wed, 8 Jan 2014 16:44:26 +0100 Message-ID: <52CD7257.8040207@gmail.com> Date: Wed, 08 Jan 2014 16:44:23 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Rajiv Asati (rajiva)" , "sthaug@nethelp.no" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 15:44:42 -0000 Le 08/01/2014 16:10, Rajiv Asati (rajiva) a écrit : >> In some other way one could still get a default gateway without >> DHCP and without RA, and could determine on/off link by other >> existing means. > > I am curious to know more about "other way" and "other existing > means". In that special case I meant ppp. When one sets up a ppp connection often the default route may come from something else than RA/DHCP. I also meant ICMP Redirect, whose cases are also implemented. I also meant Transition methods: when one sets up a 6to4 tunnel the default route is to that tunnel, it doesnt need RA. There are many of those special cases out there. They dont need neither DHCP nor RA. > ND (including RA) is there for a reason, so, what benefits are we > trying to attain by replacing them with something else? I will not suggest here and now to replace RA with DHCP. I just mean that already RA's role is already substituted by something else in many settings. > IMHO, we should strive to limit our protocol choices, not increase > them. This doesn't bode well for implementations. In a sense yes, it's good to have just one standard. In another sense the more standards are out there the more useful SDN is. Alex From alexandru.petrescu@gmail.com Wed Jan 8 07:53:26 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83991AE4D1 for ; Wed, 8 Jan 2014 07:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcby-XJqL_DD for ; Wed, 8 Jan 2014 07:53:25 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 6D05A1AE4D8 for ; Wed, 8 Jan 2014 07:53:20 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s08FrAJB028797; Wed, 8 Jan 2014 16:53:10 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4730E206439; Wed, 8 Jan 2014 16:54:10 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 31E2B20324C; Wed, 8 Jan 2014 16:54:10 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s08Fr6O7006493; Wed, 8 Jan 2014 16:53:10 +0100 Message-ID: <52CD7462.7050304@gmail.com> Date: Wed, 08 Jan 2014 16:53:06 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Pete Vickers , "v6ops@ietf.org" References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> In-Reply-To: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] control and security of DHCP (was: DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 15:53:27 -0000 Le 08/01/2014 16:04, Pete Vickers a écrit : [...] > All the arguments I've seen around control and security should be > addressed elsewhere rather than trying to hardwire the RA process. Addressing it elsewhere? Where? The lack of control and security in RA, compared to DHCP, means that people do not need to pre-register their laptops before connecting to an internal Enterprise network. That's a security risk. In some Enterprise settings every computer connected to that network needs to go to a complex pre-registration, identification, involving filing forms, signing by hand with pencil on paper, declaring, waiting 2 weeks, and so on. There are tools automating that and involving DHCP. I think it would be easier to migrate all that from v4 to v6, rather than introducing new protocols with their new security risks. Alex > > /Pete _______________________________________________ v6ops mailing > list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From rajiva@cisco.com Wed Jan 8 08:05:31 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F076A1ADFA9 for ; Wed, 8 Jan 2014 08:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4xJYyzlgoLJ for ; Wed, 8 Jan 2014 08:05:29 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id D0CF01ADFA3 for ; Wed, 8 Jan 2014 08:05:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2458; q=dns/txt; s=iport; t=1389197121; x=1390406721; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=515aoGqhm6XNbBkTxC3DXcZvcxvjSQgVn8OMkRQw0eo=; b=lrHWgbLDSDiripdxZ62cIgoZ//eztFocZcf1RYquXRwdMEjba9PhZMH/ 5KnO3Ejh1sHlRzqB5KAiggOy8BwjBLh2AxwUVfUGZf8TkUtoGQDdaV6tY h+3BYmmXFJ5RgUvI2kQM9PUOhMSO9YFywJg591pChklvRaRfOS7ldOMuo E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAP52zVKtJV2Y/2dsb2JhbABZgwuBDrkvgRQWdIIlAQEBAwF5BQcGAQgRAwECJCwRHQgCBAENBYdwAwkIv2wNhH4XjHKBPFcHBoQxAQOJC40ggWyMWoU7gW+BPoFpQQ X-IronPort-AV: E=Sophos;i="4.95,625,1384300800"; d="scan'208";a="11405881" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP; 08 Jan 2014 16:05:03 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s08G526e017633 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Jan 2014 16:05:02 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.165]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Wed, 8 Jan 2014 10:05:02 -0600 From: "Rajiv Asati (rajiva)" To: Alexandru Petrescu , "sthaug@nethelp.no" Thread-Topic: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance Thread-Index: AQHPAXeVQmo1lyuCJUK4K/NdSAAP8pp3YWwggAOAQ4CAAF85AIAABHEAgAAiTID//63DgIAAXT+A//+x6gA= Date: Wed, 8 Jan 2014 16:05:02 +0000 Message-ID: In-Reply-To: <52CD7257.8040207@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.82.218.9] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0BBBBD956EC31047B4555BB7FD27057D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 16:05:31 -0000 Hi Alex, Pls see inline, > In that special case I meant ppp. When one sets up a ppp connection > often the default route may come from something else than RA/DHCP. I presume that you didn't mean the default route coming from PPP (IPv6CP to be specific). RFC5072 has no provision for that. FWIW, RA must not have to carry default route (by encoding as 0.0.0.0/0 in RIO) per RFC4191. RA itself can be good enough to provide the default router.=20 > I also meant ICMP Redirect, whose cases are also implemented. Is that related to default routing? > I also meant Transition methods: when one sets up a 6to4 tunnel the > default route is to that tunnel, it doesnt need RA. Agreed. --=20 Cheers, Rajiv Asati Distinguished Engineer, Cisco -----Original Message----- From: Alexandru Petrescu Date: Wednesday, January 8, 2014 10:44 AM To: Rajiv Asati , "sthaug@nethelp.no" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance >Le 08/01/2014 16:10, Rajiv Asati (rajiva) a =E9crit : >>> In some other way one could still get a default gateway without >>> DHCP and without RA, and could determine on/off link by other >>> existing means. >> >> I am curious to know more about "other way" and "other existing >> means". > >In that special case I meant ppp. When one sets up a ppp connection >often the default route may come from something else than RA/DHCP. > >I also meant ICMP Redirect, whose cases are also implemented. > >I also meant Transition methods: when one sets up a 6to4 tunnel the >default route is to that tunnel, it doesnt need RA. > >There are many of those special cases out there. They dont need neither >DHCP nor RA. > >> ND (including RA) is there for a reason, so, what benefits are we >> trying to attain by replacing them with something else? > >I will not suggest here and now to replace RA with DHCP. > >I just mean that already RA's role is already substituted by something >else in many settings. > >> IMHO, we should strive to limit our protocol choices, not increase >> them. This doesn't bode well for implementations. > >In a sense yes, it's good to have just one standard. > >In another sense the more standards are out there the more useful SDN is. > >Alex > > From joelja@bogus.com Wed Jan 8 08:17:00 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624F61ADFFD for ; Wed, 8 Jan 2014 08:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iev86SBscv02 for ; Wed, 8 Jan 2014 08:16:58 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9BC1ADFD7 for ; Wed, 8 Jan 2014 08:16:58 -0800 (PST) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s08GGkjf054522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 8 Jan 2014 16:16:47 GMT (envelope-from joelja@bogus.com) Message-ID: <52CD79EC.9060105@bogus.com> Date: Wed, 08 Jan 2014 08:16:44 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: Alexandru Petrescu , Pete Vickers , "v6ops@ietf.org" References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> In-Reply-To: <52CD7462.7050304@gmail.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="N4VH63LATaX9PXOCT1UqOR2HJ5lGsdJw6" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Wed, 08 Jan 2014 16:16:47 +0000 (UTC) Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 16:17:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --N4VH63LATaX9PXOCT1UqOR2HJ5lGsdJw6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1/8/14, 7:53 AM, Alexandru Petrescu wrote: > Le 08/01/2014 16:04, Pete Vickers a =E9crit : > [...] >> All the arguments I've seen around control and security should be >> addressed elsewhere rather than trying to hardwire the RA process. >=20 > Addressing it elsewhere? Where? >=20 > The lack of control and security in RA, compared to DHCP, means that > people do not need to pre-register their laptops before connecting to a= n > internal Enterprise network. That's a security risk. We use this thing called 802.1x > In some Enterprise settings every computer connected to that network > needs to go to a complex pre-registration, identification, involving > filing forms, signing by hand with pencil on paper, declaring, waiting = 2 > weeks, and so on. There are tools automating that and involving DHCP. Because MAC addresses and host-IDs are really well protected identifiers.= =2E. > I think it would be easier to migrate all that from v4 to v6, rather > than introducing new protocols with their new security risks. >=20 > Alex >=20 >> >> /Pete _______________________________________________ v6ops mailing >> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --N4VH63LATaX9PXOCT1UqOR2HJ5lGsdJw6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLNeewACgkQ8AA1q7Z/VrLiNACfXpNB9avvnYUjs/P8dbN9DMod wOIAoIoGZrAozTSNxwGUb7GaVwV+FzCK =RnS8 -----END PGP SIGNATURE----- --N4VH63LATaX9PXOCT1UqOR2HJ5lGsdJw6-- From alexandru.petrescu@gmail.com Wed Jan 8 08:25:50 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB0E1AE03D for ; Wed, 8 Jan 2014 08:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOXftdloIQwj for ; Wed, 8 Jan 2014 08:25:47 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDB31ADFA2 for ; Wed, 8 Jan 2014 08:25:47 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s08GPYU2017771; Wed, 8 Jan 2014 17:25:34 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8399A206439; Wed, 8 Jan 2014 17:26:34 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 75EDA206319; Wed, 8 Jan 2014 17:26:34 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s08GPTus029862; Wed, 8 Jan 2014 17:25:34 +0100 Message-ID: <52CD7BF9.8070104@gmail.com> Date: Wed, 08 Jan 2014 17:25:29 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: joel jaeggli , Pete Vickers , "v6ops@ietf.org" References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <52CD79EC.9060105@bogus.com> In-Reply-To: <52CD79EC.9060105@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 16:25:50 -0000 Le 08/01/2014 17:16, joel jaeggli a écrit : > On 1/8/14, 7:53 AM, Alexandru Petrescu wrote: >> Le 08/01/2014 16:04, Pete Vickers a écrit : [...] >>> All the arguments I've seen around control and security should >>> be addressed elsewhere rather than trying to hardwire the RA >>> process. >> >> Addressing it elsewhere? Where? >> >> The lack of control and security in RA, compared to DHCP, means >> that people do not need to pre-register their laptops before >> connecting to an internal Enterprise network. That's a security >> risk. > > We use this thing called 802.1x Which is good, and I am happy for everyone using it. >> In some Enterprise settings every computer connected to that >> network needs to go to a complex pre-registration, identification, >> involving filing forms, signing by hand with pencil on paper, >> declaring, waiting 2 weeks, and so on. There are tools automating >> that and involving DHCP. > > Because MAC addresses and host-IDs are really well protected > identifiers... Well yes. Sure, one knows how to sniff and fake one. And sure as well one knows how to identify someone who sniffs in the first place. 'Sniffing' to one can be perceived as active attack by someone else. No - not everybody trusts certificates and Certificate Authorities. Some become CAs without caring that nobody else trusts that CA. Some big deployers become CA in 2003, last a few years, then revert back to pencil and paper security. Yes - some people do have processes in place that do work well, do afford security. YEs - some of these need to be migrated, but careful with security. Alex >> I think it would be easier to migrate all that from v4 to v6, >> rather than introducing new protocols with their new security >> risks. >> >> Alex >> >>> >>> /Pete _______________________________________________ v6ops >>> mailing list v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> > > From alexandru.petrescu@gmail.com Wed Jan 8 08:30:19 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6F51AE411 for ; Wed, 8 Jan 2014 08:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEX1a2aWmzU1 for ; Wed, 8 Jan 2014 08:30:17 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3E21ADF38 for ; Wed, 8 Jan 2014 08:30:16 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s08GU5DX019166; Wed, 8 Jan 2014 17:30:05 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2EC072064BF; Wed, 8 Jan 2014 17:31:05 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 16B3D2064B0; Wed, 8 Jan 2014 17:31:05 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s08GU49q032758; Wed, 8 Jan 2014 17:30:05 +0100 Message-ID: <52CD7D0C.4010609@gmail.com> Date: Wed, 08 Jan 2014 17:30:04 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Rajiv Asati (rajiva)" , "sthaug@nethelp.no" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 16:30:19 -0000 Le 08/01/2014 17:05, Rajiv Asati (rajiva) a écrit : > Hi Alex, > > Pls see inline, > >> In that special case I meant ppp. When one sets up a ppp connection >> often the default route may come from something else than RA/DHCP. > > I presume that you didn't mean the default route coming from PPP (IPv6CP > to be specific). RFC5072 has no provision for that. Right. No, I was wrong. IPv6 PPP on somme cellular entities is default route with RA. How about the other non-cellular PPPs putting up an interface first IPv4 and second IPv6? How about cellular PPP on 2G systems (or even 1G 9600kbit) which uses IPv4 tunnelling to realize IPv6? > FWIW, RA must not have to carry default route (by encoding as 0.0.0.0/0 in > RIO) per RFC4191. RA itself can be good enough to provide the default > router. > >> I also meant ICMP Redirect, whose cases are also implemented. > > Is that related to default routing? No, not to default routing. But to reach out. ICMP Redirect gives a specific route to a specific destination. It does not give a default route because a dst address in a packet can not be ::/0. >> I also meant Transition methods: when one sets up a 6to4 tunnel the >> default route is to that tunnel, it doesnt need RA. > > Agreed. Alex > > From swmike@swm.pp.se Wed Jan 8 08:34:33 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280871AE411 for ; Wed, 8 Jan 2014 08:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.389 X-Spam-Level: X-Spam-Status: No, score=-4.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_HwJyztRp-x for ; Wed, 8 Jan 2014 08:34:31 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id E7A2C1ADF38 for ; Wed, 8 Jan 2014 08:34:30 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 18F32A1; Wed, 8 Jan 2014 17:34:21 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 11CAD9C; Wed, 8 Jan 2014 17:34:21 +0100 (CET) Date: Wed, 8 Jan 2014 17:34:21 +0100 (CET) From: Mikael Abrahamsson To: Alexandru Petrescu In-Reply-To: <52CD7D0C.4010609@gmail.com> Message-ID: References: <52CD7D0C.4010609@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 16:34:33 -0000 On Wed, 8 Jan 2014, Alexandru Petrescu wrote: > How about the other non-cellular PPPs putting up an interface first IPv4 > and second IPv6? There is no real PPP in cellular system, it's just between the mobile device and the host system for historic reasons (it's emulated). When you're actually in the air, there is no PPP. > How about cellular PPP on 2G systems (or even 1G 9600kbit) which uses IPv4 > tunnelling to realize IPv6? 2G supports IPv6 just exactly the same way as 3G and 4G. There is no 3GPP standard for IPv6oIPv4 tunneling. In PPP you only negotiate Link local addresses, the rest is done through RA and DHCPv6 afaik. -- Mikael Abrahamsson email: swmike@swm.pp.se From alexandru.petrescu@gmail.com Wed Jan 8 08:38:15 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56DD1AE503 for ; Wed, 8 Jan 2014 08:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-09cVtisU78 for ; Wed, 8 Jan 2014 08:38:14 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB361AE502 for ; Wed, 8 Jan 2014 08:38:13 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s08Gc4EF021870; Wed, 8 Jan 2014 17:38:04 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 296CB206450; Wed, 8 Jan 2014 17:39:04 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1452120641C; Wed, 8 Jan 2014 17:39:04 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s08Gc0HJ005363; Wed, 8 Jan 2014 17:38:04 +0100 Message-ID: <52CD7EE8.9070008@gmail.com> Date: Wed, 08 Jan 2014 17:38:00 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <52CD7D0C.4010609@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 16:38:15 -0000 Le 08/01/2014 17:34, Mikael Abrahamsson a écrit : > On Wed, 8 Jan 2014, Alexandru Petrescu wrote: > >> How about the other non-cellular PPPs putting up an interface first >> IPv4 and second IPv6? > > There is no real PPP in cellular system, it's just between the mobile > device and the host system for historic reasons (it's emulated). When > you're actually in the air, there is no PPP. Right, our old discussion. I agree with you. >> How about cellular PPP on 2G systems (or even 1G 9600kbit) which uses >> IPv4 tunnelling to realize IPv6? > > 2G supports IPv6 just exactly the same way as 3G and 4G. There is no > 3GPP standard for IPv6oIPv4 tunneling. Well, have you tried IPv6 on a 1G system? I did and there is no RA, yet I set the default route to the tunnel I put in place. > In PPP you only negotiate Link local addresses, the rest is done through > RA and DHCPv6 afaik. YEs, with the IPv6 version of PPP when the other end of the PPP connection is an IPv6-enabled entity. Alex > From Ted.Lemon@nominum.com Wed Jan 8 09:10:57 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE121ADFA0 for ; Wed, 8 Jan 2014 09:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGKVMGyLtu-C for ; Wed, 8 Jan 2014 09:10:55 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9899D1ADF30 for ; Wed, 8 Jan 2014 09:10:55 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUs2Glu1s3rGgMQyjg5KZ8MHYN5jMvAMV@postini.com; Wed, 08 Jan 2014 09:10:46 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 5A5E51B82A5 for ; Wed, 8 Jan 2014 09:10:46 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 3D08919005C; Wed, 8 Jan 2014 09:10:46 -0800 (PST) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 8 Jan 2014 09:10:45 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Wed, 8 Jan 2014 12:10:41 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <85079612-5FFD-4DDE-B1FB-339512C8D125@nominum.com> References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 17:10:57 -0000 On Jan 8, 2014, at 2:05 AM, Lorenzo Colitti wrote: > 3. Please do not cite [DHCPv6-ROUTE]. That document was so = controversial that it was removed from the WG's charter and is no longer = a WG item, so it is inappropriate to cite it in an operational guidance = document. I don't think this is a reasonable request. Yes, the document was = controversial. But also, it indisputably does solve the stated = problem. I am deeply uncomfortable with the "process" that resulted in = this document being killed. I asked the MIF working group to drop it = from their charter because it was preventing useful work from being done = in MIF and didn't really make sense as a MIF working group item. The fact that it was removed from the MIF charter should not be taken as = any kind of agreement that the question of whether to publish the = document *somewhere* in the IETF has been conclusively resolved. I = don't see any strong need to revive it, but that is not the same thing = as saying that we have consensus that it's a bad idea. From Ted.Lemon@nominum.com Wed Jan 8 09:11:53 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73201ADFA0 for ; Wed, 8 Jan 2014 09:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZrOpTI9tN_4 for ; Wed, 8 Jan 2014 09:11:52 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 624FB1ADF30 for ; Wed, 8 Jan 2014 09:11:52 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUs2Gzw5uZH1sLQf5UXTVPrsQfnNzvWhI@postini.com; Wed, 08 Jan 2014 09:11:43 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4610D1B82A5 for ; Wed, 8 Jan 2014 09:11:43 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 3F14F19005C; Wed, 8 Jan 2014 09:11:43 -0800 (PST) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 8 Jan 2014 09:11:42 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Wed, 8 Jan 2014 12:11:41 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <4165074B-4DA1-4C37-859B-C2CB23F02CDD@nominum.com> References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <20140108.104016.74707582.sthaug@nethelp.no> To: Ole Troan X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 17:11:53 -0000 On Jan 8, 2014, at 5:54 AM, Ole Troan wrote: > I would expect the operational working group to come up with the = problem statement / use cases. > those I have not seen yet, at least no in a language I can understand. Exactly right. From swmike@swm.pp.se Wed Jan 8 09:16:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145DE1AE51B for ; Wed, 8 Jan 2014 09:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.389 X-Spam-Level: X-Spam-Status: No, score=-4.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDN0r_PUsF8V for ; Wed, 8 Jan 2014 09:16:30 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id A58261AE510 for ; Wed, 8 Jan 2014 09:16:30 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 252569C; Wed, 8 Jan 2014 18:16:21 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1E56B9A; Wed, 8 Jan 2014 18:16:21 +0100 (CET) Date: Wed, 8 Jan 2014 18:16:21 +0100 (CET) From: Mikael Abrahamsson To: Alexandru Petrescu In-Reply-To: <52CD7EE8.9070008@gmail.com> Message-ID: References: <52CD7D0C.4010609@gmail.com> <52CD7EE8.9070008@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 17:16:32 -0000 On Wed, 8 Jan 2014, Alexandru Petrescu wrote: > Well, have you tried IPv6 on a 1G system? I did and there is no RA, yet > I set the default route to the tunnel I put in place. What do you mean by 1G? No, I haven't used 1G systems, as GSM is 2G and this was launched in 1991 or so. We don't have any active 1G systems left in my country, they were turned off long ago. I am not aware that they had data capability anyway. -- Mikael Abrahamsson email: swmike@swm.pp.se From gert@Space.Net Wed Jan 8 09:28:21 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653441AE53C for ; Wed, 8 Jan 2014 09:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-nrEzUR-5wz for ; Wed, 8 Jan 2014 09:28:19 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id CEC6C1AE02E for ; Wed, 8 Jan 2014 09:28:18 -0800 (PST) Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 595286042C for ; Wed, 8 Jan 2014 18:28:08 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 3969B60183 for ; Wed, 8 Jan 2014 18:28:08 +0100 (CET) Received: (qmail 22239 invoked by uid 1007); 8 Jan 2014 18:28:08 +0100 Date: Wed, 8 Jan 2014 18:28:08 +0100 From: Gert Doering To: Alexandru Petrescu Message-ID: <20140108172808.GA81676@Space.Net> References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <52CD7462.7050304@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" , Pete Vickers Subject: Re: [v6ops] control and security of DHCP (was: DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 17:28:21 -0000 Hi, On Wed, Jan 08, 2014 at 04:53:06PM +0100, Alexandru Petrescu wrote: > Le 08/01/2014 16:04, Pete Vickers a écrit : > [...] > > All the arguments I've seen around control and security should be > > addressed elsewhere rather than trying to hardwire the RA process. > > Addressing it elsewhere? Where? > > The lack of control and security in RA, compared to DHCP, means that > people do not need to pre-register their laptops before connecting to an > internal Enterprise network. That's a security risk. You're *so* misunderstanding the issues under discussion. First, nobody prevents doing this with DHCPv6 today. You don't need "DHCPv6 and no RA" for this. Then, relying on DHCP to assure that a rogue laptop will not get an address is fake security at best (it's trivial to sniff the network, see what addresses are in use and just manually assign something) - so this is actually an example of policies that do not serve what they are claiming to do. Registering the MAC addresses and not permitting access *to the network* for unregistered devices is much more effective, but not strongly coupled to "DHCP" or "no RA". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From gert@Space.Net Wed Jan 8 09:30:10 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763581AE545 for ; Wed, 8 Jan 2014 09:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3mTGnNs75FK for ; Wed, 8 Jan 2014 09:30:07 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDDE1AE54A for ; Wed, 8 Jan 2014 09:30:07 -0800 (PST) Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 0791060274 for ; Wed, 8 Jan 2014 18:29:58 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id C0C8B60183 for ; Wed, 8 Jan 2014 18:29:57 +0100 (CET) Received: (qmail 22398 invoked by uid 1007); 8 Jan 2014 18:29:57 +0100 Date: Wed, 8 Jan 2014 18:29:57 +0100 From: Gert Doering To: Alexandru Petrescu Message-ID: <20140108172957.GB81676@Space.Net> References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD70E7.6090406@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52CD70E7.6090406@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" , Pete Vickers Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 17:30:10 -0000 Hi, On Wed, Jan 08, 2014 at 04:38:15PM +0100, Alexandru Petrescu wrote: > However, discussion whether DHCP-only deployments are possible, in > theory or otherwise, may not be that mean. Just as we state RA-only > deployments are the way to be we can also ack that DHCP-only deployments > do work. *They* *do* *not* *work*, unless you add in "manual configuration" or "other sources of configuration information". DHCPv6-only will give hosts IPv6 addresses that they can not use for anything. If you add information about on-link prefixes or default routing to that, from other sources, it's not "DHCP-only deployment". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From karsten_thomann@linfre.de Wed Jan 8 11:07:56 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1131AE552 for ; Wed, 8 Jan 2014 11:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPKHIzgQma5T for ; Wed, 8 Jan 2014 11:07:51 -0800 (PST) Received: from linfre.de (linfre.de [83.151.26.85]) by ietfa.amsl.com (Postfix) with ESMTP id 01B561AE551 for ; Wed, 8 Jan 2014 11:07:51 -0800 (PST) Received: from linne.localnet (85.16.22.153) by linfreserv.linfre (Axigen) with (AES256-SHA encrypted) ESMTPSA id 169FA7; Wed, 8 Jan 2014 20:07:24 +0100 From: Karsten Thomann To: v6ops@ietf.org Date: Wed, 08 Jan 2014 20:07:24 +0100 Message-ID: <3262931.LOsuuBpOXh@linne> User-Agent: KMail/4.10.4 (Windows/6.1; KDE/4.10.4; i686; ; ) In-Reply-To: <85079612-5FFD-4DDE-B1FB-339512C8D125@nominum.com> References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <85079612-5FFD-4DDE-B1FB-339512C8D125@nominum.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="nextPart4398107.W2NP8KpZ47" Content-Transfer-Encoding: 7Bit X-AXIGEN-DK-Result: No records DomainKey-Status: no signature X-AxigenSpam-Level: 7 Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 19:07:56 -0000 This is a multi-part message in MIME format. --nextPart4398107.W2NP8KpZ47 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Am Mittwoch, 8. Januar 2014, 12:10:41 schrieb Ted Lemon: > On Jan 8, 2014, at 2:05 AM, Lorenzo Colitti wrote: > > 3. Please do not cite [DHCPv6-ROUTE]. That document was so controversial > > that it was removed from the WG's charter and is no longer a WG item, so > > it is inappropriate to cite it in an operational guidance document. > I don't think this is a reasonable request. Yes, the document was > controversial. But also, it indisputably does solve the stated problem. > I am deeply uncomfortable with the "process" that resulted in this document > being killed. I asked the MIF working group to drop it from their charter > because it was preventing useful work from being done in MIF and didn't > really make sense as a MIF working group item. > > The fact that it was removed from the MIF charter should not be taken as any > kind of agreement that the question of whether to publish the document > *somewhere* in the IETF has been conclusively resolved. I don't see any > strong need to revive it, but that is not the same thing as saying that we > have consensus that it's a bad idea. I support Lorenzo, it should only contain information which is really standardized today, or at least something which is expected to be standardized in the next months... It should changed to something which simply clarifies that DHCPv6 without any RAs are not working as there is no on-link and gateway information available to the hosts, without any further sentence about DHCPv6-Route. Also I would like to add the information from Lorenzo about DHCPv6 with RAs without on-link prefix information to document the expected behaviour. In my opinion it should document the behaviour which can be expected with different configurations. Best regards Karsten --nextPart4398107.W2NP8KpZ47 Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="us-ascii"

Am Mittwoch, 8. Januar 2014, 12:10:41 schrieb Ted Lemon:

> On Jan 8, 2014, at 2:05 AM, Lorenzo Colitti <lorenzo@google.com> wrote:

> > 3. Please do not cite [DHCPv6-ROUTE]. That document was so controversial

> > that it was removed from the WG's charter and is no longer a WG item, so

> > it is inappropriate to cite it in an operational guidance document.

> I don't think this is a reasonable request. Yes, the document was

> controversial. But also, it indisputably does solve the stated problem.

> I am deeply uncomfortable with the "process" that resulted in this document

> being killed. I asked the MIF working group to drop it from their charter

> because it was preventing useful work from being done in MIF and didn't

> really make sense as a MIF working group item.

>

> The fact that it was removed from the MIF charter should not be taken as any

> kind of agreement that the question of whether to publish the document

> *somewhere* in the IETF has been conclusively resolved. I don't see any

> strong need to revive it, but that is not the same thing as saying that we

> have consensus that it's a bad idea.

 

I support Lorenzo, it should only contain information which is really standardized today, or at least something which is expected to be standardized in the next months...

 

It should changed to something which simply clarifies that DHCPv6 without any RAs are not working as there is no on-link and gateway information available to the hosts, without any further sentence about DHCPv6-Route.

 

Also I would like to add the information from Lorenzo about DHCPv6 with RAs without on-link prefix information to document the expected behaviour.

 

In my opinion it should document the behaviour which can be expected with different configurations.

 

Best regards

Karsten

--nextPart4398107.W2NP8KpZ47-- From owen@delong.com Wed Jan 8 11:09:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411471AE06D for ; Wed, 8 Jan 2014 11:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.529 X-Spam-Level: X-Spam-Status: No, score=-1.529 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CARl-QzYV7i0 for ; Wed, 8 Jan 2014 11:09:06 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id D23801ADFA6 for ; Wed, 8 Jan 2014 11:09:06 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s08J3tsj008463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 8 Jan 2014 11:03:55 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s08J3tsj008463 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1389207836; bh=Kq2D1MPzi+UHJW7VQ1hi4nAE1t4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=pwiaWfeJUWG15NU1BH2LFQ9LXModzbC8Nvp0pPkAIIYma+aqKWCRLjRMFu28Qldso u/EnH4WOFITtLPZywJFOnyn8oMeJSY5LFQsSD9pWosw6OWzGJODd0rGlZCyOJyarFn F4RQKTJm1v+HaFpD5eVCLmft1MClW2esNvV/zjQE= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Owen DeLong In-Reply-To: Date: Wed, 8 Jan 2014 11:03:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5AA500A7-F321-416A-A0BE-7172946BE61E@delong.com> References: To: "Rajiv Asati (rajiva)" X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 08 Jan 2014 11:03:56 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 19:09:08 -0000 On Jan 8, 2014, at 08:05 , Rajiv Asati (rajiva) = wrote: > Hi Alex, >=20 > Pls see inline, >=20 >> In that special case I meant ppp. When one sets up a ppp connection >> often the default route may come from something else than RA/DHCP. >=20 > I presume that you didn't mean the default route coming from PPP = (IPv6CP > to be specific). RFC5072 has no provision for that. >=20 >=20 > FWIW, RA must not have to carry default route (by encoding as = 0.0.0.0/0 in Why would an RA attempt to encode an IPv4 address in an RIO? Did you mean ::ffff:0:0/96 or did you mean ::/0? > RIO) per RFC4191. RA itself can be good enough to provide the default > router.=20 >=20 >> I also meant ICMP Redirect, whose cases are also implemented. >=20 > Is that related to default routing? >=20 >> I also meant Transition methods: when one sets up a 6to4 tunnel the >> default route is to that tunnel, it doesnt need RA. >=20 > Agreed. >=20 >=20 > --=20 > Cheers, > Rajiv Asati > Distinguished Engineer, Cisco >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Alexandru Petrescu > Date: Wednesday, January 8, 2014 10:44 AM > To: Rajiv Asati , "sthaug@nethelp.no" = > Cc: "v6ops@ietf.org" > Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational = Guidance-//RE: > new draft: draft-liu-v6ops-dhcpv6-slaac-guidance >=20 >> Le 08/01/2014 16:10, Rajiv Asati (rajiva) a =E9crit : >>>> In some other way one could still get a default gateway without >>>> DHCP and without RA, and could determine on/off link by other >>>> existing means. >>>=20 >>> I am curious to know more about "other way" and "other existing >>> means". >>=20 >> In that special case I meant ppp. When one sets up a ppp connection >> often the default route may come from something else than RA/DHCP. >>=20 >> I also meant ICMP Redirect, whose cases are also implemented. >>=20 >> I also meant Transition methods: when one sets up a 6to4 tunnel the >> default route is to that tunnel, it doesnt need RA. >>=20 >> There are many of those special cases out there. They dont need = neither >> DHCP nor RA. >>=20 >>> ND (including RA) is there for a reason, so, what benefits are we >>> trying to attain by replacing them with something else? >>=20 >> I will not suggest here and now to replace RA with DHCP. >>=20 >> I just mean that already RA's role is already substituted by = something >> else in many settings. >>=20 >>> IMHO, we should strive to limit our protocol choices, not increase >>> them. This doesn't bode well for implementations. >>=20 >> In a sense yes, it's good to have just one standard. >>=20 >> In another sense the more standards are out there the more useful SDN = is. >>=20 >> Alex >>=20 >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From owen@delong.com Wed Jan 8 11:13:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83B01AE12E for ; Wed, 8 Jan 2014 11:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.529 X-Spam-Level: X-Spam-Status: No, score=-1.529 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQEAFCf0PJqC for ; Wed, 8 Jan 2014 11:13:07 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 7B78F1AE06D for ; Wed, 8 Jan 2014 11:13:07 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s08J9PqB008659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 8 Jan 2014 11:09:25 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s08J9PqB008659 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1389208166; bh=RcdfNcmw0RPdEqiDKpQwOQ6RXJg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=cFc1fpz6hkF69ZXoilmi2uQmoTuzvbB9tYImQjEwD2Pos5tZg2cayAUvZkW/E8L86 J+g18aCjGJfNIYy7R7FPFTUyTXR+asNwcFBdbzfSXG2l4vsWoluXDDxDLjuHxuPV/p q7ejDnrDzwJFv17t0pH/JcH4WN+vNeBq9GdHmUuY= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Owen DeLong In-Reply-To: <52CD7BF9.8070104@gmail.com> Date: Wed, 8 Jan 2014 11:09:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <52CD79EC.9060105@bogus.com> <52CD7BF9.8070104@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 08 Jan 2014 11:09:26 -0800 (PST) Cc: "v6ops@ietf.org" , Pete Vickers Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 19:13:08 -0000 >>=20 >> Because MAC addresses and host-IDs are really well protected >> identifiers... >=20 > Well yes. >=20 > Sure, one knows how to sniff and fake one. And sure as well one knows > how to identify someone who sniffs in the first place. 'Sniffing' to > one can be perceived as active attack by someone else. >=20 I'm curious... How do you identify someone sniffing your wifi network = from 20 miles away? I can understand how you _MIGHT_ detect the forged MAC address, but = detecting the sniffing part has me very curious. Do you really believe you can detect someone doing a passive fiber tap = in the middle of one of your long-haul circuits? Do you really believe that you can = detect someone duplicating your traffic off to a maintenance feed on one of the DACS = that the circuit flows through? You might be able to detect sniffing in some circumstances, but reliably = detecting it in all circumstances is a hard problem and I remain unconvinced that it = is solved. Most of the time, faking a MAC address doesn't even really require all = that much sniffing. Grab something out of one of the OUIs for Apple portable = devices and you can usually get in to a lot of places. If that doesn't work, it only = takes a few seconds to sniff one. > No - not everybody trusts certificates and Certificate Authorities. > Some become CAs without caring that nobody else trusts that CA. So? > Some big deployers become CA in 2003, last a few years, then revert = back > to pencil and paper security. >=20 > Yes - some people do have processes in place that do work well, do > afford security. >=20 > YEs - some of these need to be migrated, but careful with security. Any security that depends on a "trusted MAC address" or "host = identifier" is the security equivalent of a screen door. Owen >=20 > Alex >=20 >>> I think it would be easier to migrate all that from v4 to v6, >>> rather than introducing new protocols with their new security >>> risks. >>>=20 >>> Alex >>>=20 >>>>=20 >>>> /Pete _______________________________________________ v6ops >>>> mailing list v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ v6ops mailing list >>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>=20 >>=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From owen@delong.com Wed Jan 8 11:18:02 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530A51AE3F8 for ; Wed, 8 Jan 2014 11:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8S67lkeALMI for ; Wed, 8 Jan 2014 11:17:57 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3AB1AE40B for ; Wed, 8 Jan 2014 11:17:57 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s08JHAfV008833 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 8 Jan 2014 11:17:10 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s08JHAfV008833 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1389208630; bh=aLPE+sVTXfEodDkfWq4cg4yQpi4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=SmRwzvMEptQ0rczeh0DpDp2XH8VnGIGiv3hVziXBSZA9RZ8BrbpmuVIQdSRb7S7P9 +kCbDcObI1838yo8no1/MQT5F1F4YgoWBzCf1zc80n0S/J3voIkGg+G32d8ZC6aeAj 80Io2tDsx/hSoskyZtuMPbvHYMHea2GcNO5k/7nw= Content-Type: multipart/alternative; boundary="Apple-Mail=_3DE94B8B-B575-48A7-A4FC-6A12E76CC119" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Owen DeLong In-Reply-To: <3262931.LOsuuBpOXh@linne> Date: Wed, 8 Jan 2014 11:17:09 -0800 Message-Id: References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <85079612-5FFD-4DDE-B1FB-339512C8D125@nominum.com> <3262931.LOsuuBpOXh@linne> To: Karsten Thomann X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 08 Jan 2014 11:17:10 -0800 (PST) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 19:18:02 -0000 --Apple-Mail=_3DE94B8B-B575-48A7-A4FC-6A12E76CC119 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This probably goes without saying, but for the record: +1 Owen On Jan 8, 2014, at 11:07 , Karsten Thomann = wrote: > Am Mittwoch, 8. Januar 2014, 12:10:41 schrieb Ted Lemon: > > On Jan 8, 2014, at 2:05 AM, Lorenzo Colitti = wrote: > > > 3. Please do not cite [DHCPv6-ROUTE]. That document was so = controversial > > > that it was removed from the WG's charter and is no longer a WG = item, so > > > it is inappropriate to cite it in an operational guidance = document. > > I don't think this is a reasonable request. Yes, the document was > > controversial. But also, it indisputably does solve the stated = problem. =20 > > I am deeply uncomfortable with the "process" that resulted in this = document > > being killed. I asked the MIF working group to drop it from their = charter > > because it was preventing useful work from being done in MIF and = didn't > > really make sense as a MIF working group item. > >=20 > > The fact that it was removed from the MIF charter should not be = taken as any > > kind of agreement that the question of whether to publish the = document > > *somewhere* in the IETF has been conclusively resolved. I don't = see any > > strong need to revive it, but that is not the same thing as saying = that we > > have consensus that it's a bad idea. > =20 > I support Lorenzo, it should only contain information which is really = standardized today, or at least something which is expected to be = standardized in the next months... > =20 > It should changed to something which simply clarifies that DHCPv6 = without any RAs are not working as there is no on-link and gateway = information available to the hosts, without any further sentence about = DHCPv6-Route. > =20 > Also I would like to add the information from Lorenzo about DHCPv6 = with RAs without on-link prefix information to document the expected = behaviour. > =20 > In my opinion it should document the behaviour which can be expected = with different configurations.=20 > =20 > Best regards > Karsten > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_3DE94B8B-B575-48A7-A4FC-6A12E76CC119 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This = probably goes without saying, but for the record: = +1

Owen

On Jan 8, 2014, at = 11:07 , Karsten Thomann <karsten_thomann@linfre.de>= ; wrote:

Am Mittwoch, 8. Januar 2014, 12:10:41 schrieb Ted Lemon:
> On = Jan 8, 2014, at 2:05 AM, Lorenzo Colitti <lorenzo@google.com> = wrote:
> > 3. Please do not cite [DHCPv6-ROUTE]. That = document was so controversial
> > that it was removed from the = WG's charter and is no longer a WG item, so
> = > it is inappropriate to cite it in an operational guidance = document.
> I don't think this is a reasonable request. = Yes, the document was
> controversial. But also, it indisputably = does solve the stated problem.
> I am deeply uncomfortable = with the "process" that resulted in this document
> = being killed. I asked the MIF working group to drop it from their = charter
> because it was preventing useful work from being = done in MIF and didn't
> really make sense as a MIF working group = item.
>
> The fact that it was removed from = the MIF charter should not be taken as any
> kind of agreement that = the question of whether to publish the document
> = *somewhere* in the IETF has been conclusively resolved. I don't see = any
> strong need to revive it, but that is not the same thing as = saying that we
> have consensus that it's a bad idea.

 

I support Lorenzo, it should only contain information = which is really standardized today, or at least something which is = expected to be standardized in the next months...

 

It should changed to something which simply clarifies = that DHCPv6 without any RAs are not working as there is no on-link and = gateway information available to the hosts, without any further sentence = about DHCPv6-Route.

 

Also I would like to add the information = from Lorenzo about DHCPv6 with RAs without on-link prefix information to = document the expected behaviour.

 

In my opinion it should = document the behaviour which can be expected with different = configurations.

 

Best regards
Karsten
_______________________________________________
v6op= s mailing list
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops

= --Apple-Mail=_3DE94B8B-B575-48A7-A4FC-6A12E76CC119-- From brian.e.carpenter@gmail.com Wed Jan 8 11:26:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09671AE116 for ; Wed, 8 Jan 2014 11:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqaYC_P1pnxA for ; Wed, 8 Jan 2014 11:26:52 -0800 (PST) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 85A151AE126 for ; Wed, 8 Jan 2014 11:26:52 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id rq2so1988741pbb.3 for ; Wed, 08 Jan 2014 11:26:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VK1Gcx5nMarlm+gQP8E516iMGGdTwCcmAj7o9k69ZdM=; b=X7vuF7KF3HaNCEvaqM1ZpaZuzyMYup3ZBk8Bt4L+8iPzbVRDQKtBHDb6LRUpkxqXMo nCaErTw8EZ0ZAmG0ClrmUFSjhjyTC+e76Szqin1Uqvvb0w/DM4JjE6kefcdcZC+fl6za +Z39iaAoDmhkEUe4fBJfYf6Q4khJjD9aQQU4e0kfcttoAukvLD8wQk30EvM8RMNEZrs5 N/tRollqxW8fbwgYMuYt0kXnBpBdBU6Z8lyqKAFjgGMjyboOpSh7prm6jXjpz7TZUSr/ ORo31v/87q7eLezwQCWnjEcZ75YjpF/J2EC7Lj2n0TFhD1Yc8odRRouM6gAI5zjhTHOw NlhA== X-Received: by 10.68.20.1 with SMTP id j1mr25627054pbe.148.1389209203370; Wed, 08 Jan 2014 11:26:43 -0800 (PST) Received: from [192.168.178.21] (81.196.69.111.dynamic.snap.net.nz. [111.69.196.81]) by mx.google.com with ESMTPSA id iu7sm4302545pbc.45.2014.01.08.11.26.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Jan 2014 11:26:42 -0800 (PST) Message-ID: <52CDA679.6010405@gmail.com> Date: Thu, 09 Jan 2014 08:26:49 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Gert Doering References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> In-Reply-To: <20140108172808.GA81676@Space.Net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Pete Vickers , "v6ops@ietf.org" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 19:26:55 -0000 On 09/01/2014 06:28, Gert Doering wrote: ... > Registering the MAC addresses and not permitting access *to the network* > for unregistered devices is much more effective, but not strongly coupled > to "DHCP" or "no RA". True. However, this will become harder if the planned ephemeral 802.11 MAC addresses become widespread, as has been suggested over on the perpass list. Brian From rajiva@cisco.com Wed Jan 8 11:40:55 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3796E1AE3F8 for ; Wed, 8 Jan 2014 11:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idZUcb0X0MsT for ; Wed, 8 Jan 2014 11:40:52 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3421AE104 for ; Wed, 8 Jan 2014 11:40:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3617; q=dns/txt; s=iport; t=1389210043; x=1390419643; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=oCNflyeVA0kK574TXtO+rHhxEhb0UpVpRJRmFsqbBvg=; b=AtMsS0vXzvjGQtsHUdSl41der8IoYGH5Z9gJv/E8NH5ZnnWVPvib71px crL0G7kvZQ7E2vci/GB1gGYX2cHzJjzSvMylQEZ2/YS5v1lXuNH33UcMw rH/UEsFS16cXag+RBca/9MohN+gzDYp6G+MFeXUtCj/1/wUprQHtvKzdB Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAIGpzVKtJXG+/2dsb2JhbABZgws4Vrk5gRQWdIIlAQEBBAEBAWsLDAYBCBEDAQIBIywGCx0IAgQOBYdwAxENvzINhQATBIxygTxXBwaEMQSJC40ggWyMWoU7gW+BPoFpQQ X-IronPort-AV: E=Sophos;i="4.95,626,1384300800"; d="scan'208";a="11465804" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-8.cisco.com with ESMTP; 08 Jan 2014 19:40:43 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s08JegwK021787 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Jan 2014 19:40:43 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.165]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Wed, 8 Jan 2014 13:40:42 -0600 From: "Rajiv Asati (rajiva)" To: Owen DeLong Thread-Topic: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance Thread-Index: AQHPAXeVQmo1lyuCJUK4K/NdSAAP8pp3YWwggAOAQ4CAAF85AIAABHEAgAAiTID//63DgIAAXT+A//+x6gCAAIXWgP//tmyA Date: Wed, 8 Jan 2014 19:40:42 +0000 Message-ID: In-Reply-To: <5AA500A7-F321-416A-A0BE-7172946BE61E@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.82.218.9] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 19:40:55 -0000 Sorry, I did mean ::0. :=3D) --=20 Cheers, Rajiv Asati Distinguished Engineer, Cisco -----Original Message----- From: Owen DeLong Date: Wednesday, January 8, 2014 2:03 PM To: Rajiv Asati Cc: Alexandru Petrescu , "sthaug@nethelp.no" , "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance > >On Jan 8, 2014, at 08:05 , Rajiv Asati (rajiva) wrote: > >> Hi Alex, >>=20 >> Pls see inline, >>=20 >>> In that special case I meant ppp. When one sets up a ppp connection >>> often the default route may come from something else than RA/DHCP. >>=20 >> I presume that you didn't mean the default route coming from PPP (IPv6CP >> to be specific). RFC5072 has no provision for that. >>=20 >>=20 >> FWIW, RA must not have to carry default route (by encoding as 0.0.0.0/0 >>in > >Why would an RA attempt to encode an IPv4 address in an RIO? > >Did you mean ::ffff:0:0/96 or did you mean ::/0? > >> RIO) per RFC4191. RA itself can be good enough to provide the default >> router.=20 >>=20 >>> I also meant ICMP Redirect, whose cases are also implemented. >>=20 >> Is that related to default routing? >>=20 >>> I also meant Transition methods: when one sets up a 6to4 tunnel the >>> default route is to that tunnel, it doesnt need RA. >>=20 >> Agreed. >>=20 >>=20 >> --=20 >> Cheers, >> Rajiv Asati >> Distinguished Engineer, Cisco >>=20 >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Alexandru Petrescu >> Date: Wednesday, January 8, 2014 10:44 AM >> To: Rajiv Asati , "sthaug@nethelp.no" >> >> Cc: "v6ops@ietf.org" >> Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: >> new draft: draft-liu-v6ops-dhcpv6-slaac-guidance >>=20 >>> Le 08/01/2014 16:10, Rajiv Asati (rajiva) a =E9crit : >>>>> In some other way one could still get a default gateway without >>>>> DHCP and without RA, and could determine on/off link by other >>>>> existing means. >>>>=20 >>>> I am curious to know more about "other way" and "other existing >>>> means". >>>=20 >>> In that special case I meant ppp. When one sets up a ppp connection >>> often the default route may come from something else than RA/DHCP. >>>=20 >>> I also meant ICMP Redirect, whose cases are also implemented. >>>=20 >>> I also meant Transition methods: when one sets up a 6to4 tunnel the >>> default route is to that tunnel, it doesnt need RA. >>>=20 >>> There are many of those special cases out there. They dont need >>>neither >>> DHCP nor RA. >>>=20 >>>> ND (including RA) is there for a reason, so, what benefits are we >>>> trying to attain by replacing them with something else? >>>=20 >>> I will not suggest here and now to replace RA with DHCP. >>>=20 >>> I just mean that already RA's role is already substituted by something >>> else in many settings. >>>=20 >>>> IMHO, we should strive to limit our protocol choices, not increase >>>> them. This doesn't bode well for implementations. >>>=20 >>> In a sense yes, it's good to have just one standard. >>>=20 >>> In another sense the more standards are out there the more useful SDN >>>is. >>>=20 >>> Alex >>>=20 >>>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > From sthaug@nethelp.no Wed Jan 8 12:29:59 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8BA21AE1A8 for ; Wed, 8 Jan 2014 12:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tv72JdgBgRl for ; Wed, 8 Jan 2014 12:29:57 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 345BA1AE189 for ; Wed, 8 Jan 2014 12:29:56 -0800 (PST) Received: (qmail 52323 invoked from network); 8 Jan 2014 20:29:45 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 8 Jan 2014 20:29:45 -0000 Date: Wed, 08 Jan 2014 21:29:45 +0100 (CET) Message-Id: <20140108.212945.74700481.sthaug@nethelp.no> To: alexandru.petrescu@gmail.com From: sthaug@nethelp.no In-Reply-To: <52CD691B.2090702@gmail.com> References: <52CD489C.4030108@gmail.com> <20140108.140214.74708195.sthaug@nethelp.no> <52CD691B.2090702@gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 20:30:00 -0000 > > I believe the idea here is that without RA: > > > > - you don't have a default gateway > > - you cannot determine what prefixes are on-link/off-link > > Thanks for the clarification. The idea makes sense in a certain way in > which only RA provides the default route, and only NS/NA provide the > on-link determination. You probably mean "only the Prefix Information Option in RA provides the on-link determination". If I read the on-link determination part of RFC 4861, together with RFC 5942, I could easily be left with the impression that a static IPv6 route with global next hop pointing to a statically defined default gateway is not *meant* to work without RA. Fortunately, it works in the operating systes where I've tried it. (And there are routers where the ND/NS functionality is separated from the RA functionality such that ND/NS works by default as soon as an IPv6 interface is configured, while RA needs to be explicitly turned on. To me, this is a good thing.) > In some other way one could still get a default gateway without DHCP and > without RA, and could determine on/off link by other existing means. Yes, for instance static configuration. Steinar Haug, AS2116 From randy@psg.com Wed Jan 8 13:00:23 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D2B1AE5C8 for ; Wed, 8 Jan 2014 13:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbkqdMHYEubL for ; Wed, 8 Jan 2014 13:00:22 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 703971AD9B7 for ; Wed, 8 Jan 2014 13:00:22 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1W10ES-0005gi-It; Wed, 08 Jan 2014 21:00:09 +0000 Date: Thu, 09 Jan 2014 06:00:07 +0900 Message-ID: From: Randy Bush To: Gert Doering In-Reply-To: <20140107104001.GM81676@Space.Net> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> <20140107104001.GM81676@Space.Net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Thu_Jan__9_06:00:02_2014-1"; micalg=pgp-sha512; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 21:00:23 -0000 --pgp-sign-Multipart_Thu_Jan__9_06:00:02_2014-1 Content-Type: text/plain; charset=US-ASCII > Your multi-million-dollar enterprise can do DHCPv6-based IPv6 address > assignment perfectly well today. Client and server implementations > exist, and RFCs back that. > > The thing that can not be done today is "do that if you do not have RAs > on your network, that will tell the clients 'go to the DHCPv6 server > for address information, but route the packets to me'". the multi-million-euro enterprise can continue to do ipv4. and that's what they are doing. we can stick our heads and pretend that this is not a festering and embarrassing problem or we can fix it. randy --pgp-sign-Multipart_Thu_Jan__9_06:00:02_2014-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAABCgAGBQJSzbxXAAoJEMzMBey4OgLtv3AIAKhzySYvypLhHhgiVztv4Slc aQNupWJx2v7TYt76SE7ZYwXTegA/wuycdirIZSSRjvpzTdfS52ft/V7Lger6hNob 2JGtNLDgfVKNwTuzUo4PvZWt6ZGylu1bKk1f+aYgHNO6Y5lio1lkHUTY+QF4akUs Nms3d7mPxgN0s2GsDQ+1r6T5Xb4gydw+01AYb4epHf1DQdI8F1Dhmyjit1D7C83F u/tE2SrvmRikmldltUnMSe76jGASyvWQlH7IscNndyzQy5frZTCph8asL0wxQKjG fVyQAnaS6IVQFcAqYFw7SW0GvzF39iP355HVt/yt+yZ0+8ktbq9yvJ0GlqZvtpM= =b/3P -----END PGP SIGNATURE----- --pgp-sign-Multipart_Thu_Jan__9_06:00:02_2014-1-- From Ted.Lemon@nominum.com Wed Jan 8 13:05:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA4B1AE5CC for ; Wed, 8 Jan 2014 13:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQk08CpxkmFp for ; Wed, 8 Jan 2014 13:05:25 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 85E0A1AE5C8 for ; Wed, 8 Jan 2014 13:05:25 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUs29jDavmK/hAfcZ7G99u/FsEtO2EsTm@postini.com; Wed, 08 Jan 2014 13:05:16 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 1D1C01B82CC for ; Wed, 8 Jan 2014 13:05:16 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id ED0C219005C; Wed, 8 Jan 2014 13:05:15 -0800 (PST) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 8 Jan 2014 13:05:15 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Wed, 8 Jan 2014 16:05:11 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <72626BC4-CB9E-49E8-8A54-48A141F52C0C@nominum.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> <20140107104001.GM81676@Space.Net> To: Randy Bush X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 21:05:28 -0000 On Jan 8, 2014, at 4:00 PM, Randy Bush wrote: > the multi-million-euro enterprise can continue to do ipv4. and that's > what they are doing. we can stick our heads and pretend = that > this is not a festering and embarrassing problem or we can fix it. Okay, Randy. You're a smart, articulate guy. Can you tell us what is = missing that we need to add, and in what sense it's missing? I have = yet to hear a clear statement of what the problem is. From randy@psg.com Wed Jan 8 13:31:50 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F9A1A8031 for ; Wed, 8 Jan 2014 13:31:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sucDyruLVpTp for ; Wed, 8 Jan 2014 13:31:48 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id D7BF31A802D for ; Wed, 8 Jan 2014 13:31:48 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1W10iu-0005kn-5S; Wed, 08 Jan 2014 21:31:36 +0000 Date: Thu, 09 Jan 2014 06:31:34 +0900 Message-ID: From: Randy Bush To: Ted Lemon In-Reply-To: <72626BC4-CB9E-49E8-8A54-48A141F52C0C@nominum.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> <20140107104001.GM81676@Space.Net> <72626BC4-CB9E-49E8-8A54-48A141F52C0C@nominum.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Thu_Jan__9_06:31:28_2014-1"; micalg=pgp-sha512; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 21:31:50 -0000 --pgp-sign-Multipart_Thu_Jan__9_06:31:28_2014-1 Content-Type: text/plain; charset=US-ASCII >> the multi-million-euro enterprise can continue to do ipv4. and that's >> what they are doing. we can stick our heads and pretend that >> this is not a festering and embarrassing problem or we can fix it. > > Okay, Randy. You're a smart, articulate guy. Can you tell us what is > missing that we need to add, and in what sense it's missing? I have > yet to hear a clear statement of what the problem is. then you are a newcomer to an eight year old conversation. i will not bother with the technical issues which have been discussed endlessly, rinse repeat. that's why we have list archives. the bottom line is that the vast majority enterprises, campuses, ... are run by IT departments which pay the bills and do it their way. they use dhcp, good, bad, indifferent. we don't have to like what the people who pay us money want to do. arguing with the customer is generally not a good strategy. yes there are enterprises who drink the koolaid and follow the true religion. so far, they are a teensie minority. the vast majority of enterprises run ipv4, rfc1918, ... when they look at ipv6 the first question, and often the only question is "how much will it cost?" and the answer to that is bad enough without any speed bumps of changing what they are doing today. if we want them to deploy ipv6, as opposed to more rfc1918 space, then we need to remove all speed bumps. not discuss them. not tell them that RA is the true religion. frelling remove the speed bump. there is no harm and there is trivial cost in giving the customer what she wants. that the ietf has refused to do so for years is characteristic of the arrogance and ignorance which leaves ipv6's survival still at risk. randy --pgp-sign-Multipart_Thu_Jan__9_06:31:28_2014-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAABCgAGBQJSzcO0AAoJEMzMBey4OgLtL0AIAKW+XOic2b82NIJRWD4Ka8+m JOiq6iP1tuUPsL170rURPvQ8Ilms5i70l1A7BHzEvy+YmJLmVlYlLh2kbGwDHwo7 Cd2benWFBbNKWgfhHZoMrtr1iozC+cYwXQkb7ajvfwRn3i0IGhiGeE5aL4epsgbY +iEgFQvEp7WJF+MN1BObyb+tkQv4IoQ1Z3KKED0mEV9jF0YMpNvStBGu/UIFGqmI J846iGNA28vchI3pg80tchF8HI30KSbELBF+0RkTAAO+eCGpuC2EbpjR9lAi3JJS oaVo0K1pPOX9p+TvxSUwRxaeX57W7M7uy0gUmGCHHhmZpxekfsR6NegKj2Z4OvA= =zkZW -----END PGP SIGNATURE----- --pgp-sign-Multipart_Thu_Jan__9_06:31:28_2014-1-- From Ted.Lemon@nominum.com Wed Jan 8 13:47:55 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137B31AC8F5 for ; Wed, 8 Jan 2014 13:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvt-8MZ0GyvH for ; Wed, 8 Jan 2014 13:47:54 -0800 (PST) Received: from exprod7og129.obsmtp.com (exprod7og129.obsmtp.com [64.18.2.122]) by ietfa.amsl.com (Postfix) with ESMTP id DE1C91AC862 for ; Wed, 8 Jan 2014 13:47:53 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob129.postini.com ([64.18.6.12]) with SMTP ID DSNKUs3Hf29qSjDXMFD8ropu8pBi9p6jHCKB@postini.com; Wed, 08 Jan 2014 13:47:45 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id AD6A31B82B2 for ; Wed, 8 Jan 2014 13:47:43 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 9507F19005C; Wed, 8 Jan 2014 13:47:43 -0800 (PST) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 8 Jan 2014 13:47:43 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Wed, 8 Jan 2014 16:47:39 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <6A64F619-4A0E-423A-A5E7-4C3234B461AE@nominum.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> <20140107104001.GM81676@Space.Net> <72626BC4-CB9E-49E8-8A54-48A141F52C0C@nominum.com> To: Randy Bush X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 21:47:55 -0000 On Jan 8, 2014, at 4:31 PM, Randy Bush wrote: > if we want them to deploy ipv6, as opposed to more rfc1918 space, then > we need to remove all speed bumps. not discuss them. not tell them > that RA is the true religion. frelling remove the speed bump. Can you name a specific speed bump? I've been listening to this = conversation for eight years too, and have yet to hear one named. You = seem to be saying that RA is the speed bump, but that's not specific. = What is it about RA that "they" need changed? From randy@psg.com Wed Jan 8 13:57:48 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7B91ACCDA for ; Wed, 8 Jan 2014 13:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kj9cZ3EwhBsq for ; Wed, 8 Jan 2014 13:57:47 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id A12D41AC3FA for ; Wed, 8 Jan 2014 13:57:47 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1W1183-0005pS-SA; Wed, 08 Jan 2014 21:57:36 +0000 Date: Thu, 09 Jan 2014 06:57:34 +0900 Message-ID: From: Randy Bush To: Ted Lemon In-Reply-To: <6A64F619-4A0E-423A-A5E7-4C3234B461AE@nominum.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> <20140107104001.GM81676@Space.Net> <72626BC4-CB9E-49E8-8A54-48A141F52C0C@nominum.com> <6A64F619-4A0E-423A-A5E7-4C3234B461AE@nominum.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Thu_Jan__9_06:57:30_2014-1"; micalg=pgp-sha512; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 21:57:49 -0000 --pgp-sign-Multipart_Thu_Jan__9_06:57:30_2014-1 Content-Type: text/plain; charset=US-ASCII >> if we want them to deploy ipv6, as opposed to more rfc1918 space, then >> we need to remove all speed bumps. not discuss them. not tell them >> that RA is the true religion. frelling remove the speed bump. > > Can you name a specific speed bump? I've been listening to this > conversation for eight years too, and have yet to hear one named. You > seem to be saying that RA is the speed bump, but that's not specific. > What is it about RA that "they" need changed? the missing dhcp function, exit router --pgp-sign-Multipart_Thu_Jan__9_06:57:30_2014-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAABCgAGBQJSzcnOAAoJEMzMBey4OgLtJxAH/1ARGSrP680Fb4P+JqD9c1Q3 df3ELT2ff/3bH9Nqvbbd4zE9xXoDWNe5I44ZBZ/BwY0pzH3X0sldYOHhkoknZaRS 1F19zC2XWrtoKuCFEGDzIqA+3WQAAtlyqyAzE2rcJUCcDzuZmPEihph2a2K1WRKC RbTCKpdlzFH74iNMXCf/ox+lxRVhGSmNV6rdoOMPdsSyWWmulYe8O2UZGLo7q+JQ kuRNt699gYLo5MmIYkS+B3ZOtPrtMI9j2zDeAcSKXezfIQm6mch/pdMPHguNEoRa XqVy1DVuXi28yBgo30ZEZjyXzqXhA9AJ0vKn5ELVocpO+/M5nTIDhl1yJ0XmgNs= =LvFH -----END PGP SIGNATURE----- --pgp-sign-Multipart_Thu_Jan__9_06:57:30_2014-1-- From jared@puck.nether.net Wed Jan 8 14:02:36 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 401B41ACCEF for ; Wed, 8 Jan 2014 14:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhtzLq2-QzT8 for ; Wed, 8 Jan 2014 14:02:34 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id BBF8A1ACCEA for ; Wed, 8 Jan 2014 14:02:34 -0800 (PST) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.7/8.14.5) with ESMTP id s08M2NVE015699 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Jan 2014 17:02:24 -0500 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: Date: Wed, 8 Jan 2014 17:03:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7F9988DB-00B8-47FF-928A-E346164BEAFD@puck.nether.net> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> <20140107104001.GM81676@Space.Net> <72626BC4-CB9E-49E8-8A54-48A141F52C0C@nominum.com> <6A64F619-4A0E-423A-A5E7-4C3234B461AE@nominum.com> To: Randy Bush X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7 (puck.nether.net [204.42.254.5]); Wed, 08 Jan 2014 17:02:24 -0500 (EST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 22:02:36 -0000 On Jan 8, 2014, at 4:57 PM, Randy Bush wrote: >>> if we want them to deploy ipv6, as opposed to more rfc1918 space, = then >>> we need to remove all speed bumps. not discuss them. not tell them >>> that RA is the true religion. frelling remove the speed bump. >>=20 >> Can you name a specific speed bump? I've been listening to this >> conversation for eight years too, and have yet to hear one named. = You >> seem to be saying that RA is the speed bump, but that's not specific. >> What is it about RA that "they" need changed? >=20 > the missing dhcp function, exit router For the rest of the class, please read the "turning on comcast v6" = thread for the operator community feedback. http://mailman.nanog.org/pipermail/nanog/2013-December/thread.html http://mailman.nanog.org/pipermail/nanog/2014-January/thread.html - Jared= From joelja@bogus.com Wed Jan 8 14:09:20 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3D21ACCEA for ; Wed, 8 Jan 2014 14:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-o-utYCgaX1 for ; Wed, 8 Jan 2014 14:09:18 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id BDD1C1ACC8B for ; Wed, 8 Jan 2014 14:09:18 -0800 (PST) Received: from [192.168.43.134] ([172.56.39.37]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s08M8Xwd057234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 8 Jan 2014 22:09:09 GMT (envelope-from joelja@bogus.com) Message-ID: <52CDCC5A.5030408@bogus.com> Date: Wed, 08 Jan 2014 14:08:26 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: Randy Bush , Ted Lemon References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> <20140107104001.GM81676@Space.Net> <72626BC4-CB9E-49E8-8A54-48A141F52C0C@nominum.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gnENnxS2nuDDdg8PIdEELQep3kliqO6nK" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Wed, 08 Jan 2014 22:09:09 +0000 (UTC) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 22:09:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gnENnxS2nuDDdg8PIdEELQep3kliqO6nK Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1/8/14, 1:31 PM, Randy Bush wrote: >>> the multi-million-euro enterprise can continue to do ipv4. and that'= s >>> what they are doing. we can stick our heads and pretend th= at >>> this is not a festering and embarrassing problem or we can fix it. >> >> Okay, Randy. You're a smart, articulate guy. Can you tell us what is= >> missing that we need to add, and in what sense it's missing? I have >> yet to hear a clear statement of what the problem is. >=20 > then you are a newcomer to an eight year old conversation. i will not > bother with the technical issues which have been discussed endlessly, > rinse repeat. that's why we have list archives. >=20 > the bottom line is that the vast majority enterprises, campuses, ... ar= e > run by IT departments which pay the bills and do it their way. they us= e > dhcp, good, bad, indifferent. we don't have to like what the people wh= o > pay us money want to do. arguing with the customer is generally not a > good strategy. >=20 > yes there are enterprises who drink the koolaid and follow the true > religion. so far, they are a teensie minority. the vast majority of > enterprises run ipv4, rfc1918, ... when they look at ipv6 the first > question, and often the only question is "how much will it cost?" and > the answer to that is bad enough without any speed bumps of changing > what they are doing today. >=20 > if we want them to deploy ipv6, as opposed to more rfc1918 space, then > we need to remove all speed bumps. not discuss them. not tell them > that RA is the true religion. frelling remove the speed bump. >=20 > there is no harm and there is trivial cost in giving the customer what > she wants. So not-withstanding my whatever personal feelings I have related to this dicussion (which mostly involve digsust) there are real consequences for keying up you radio and sending a dhcp request that may never be answered every so often until the end of time... This applies in the ipv4 case for ipv4 adhoc networks as well. but it certainly applies to ipv4 only subnets with ipv6 speakers (not really an uncommon case), ipv6 adhoc networks, dual stack networks with no dhcpv6 (you should innore RAs at your peril) and so on. There's now way to get these things to shut up in ipv4 without managing them. it would be nice if we could do better than that. > that the ietf has refused to do so for years is characteristic of the > arrogance and ignorance which leaves ipv6's survival still at risk. >=20 > randy >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --gnENnxS2nuDDdg8PIdEELQep3kliqO6nK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLNzFsACgkQ8AA1q7Z/VrJ4UACfQ7EjsEOEqils9v9iX+qia+PB 9loAn0VC5A/SoyscdYIWq5DrBjbnZgi3 =Gw6V -----END PGP SIGNATURE----- --gnENnxS2nuDDdg8PIdEELQep3kliqO6nK-- From Fred.L.Templin@boeing.com Wed Jan 8 14:09:50 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0E31ACCFF for ; Wed, 8 Jan 2014 14:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUjOZKmLrmTm for ; Wed, 8 Jan 2014 14:09:46 -0800 (PST) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id CD80B1ACCFE for ; Wed, 8 Jan 2014 14:09:42 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s08M9XgB017748; Wed, 8 Jan 2014 14:09:33 -0800 Received: from XCH-PHX-409.sw.nos.boeing.com (xch-phx-409.sw.nos.boeing.com [10.57.37.40]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s08M9Uwq017736 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 8 Jan 2014 14:09:30 -0800 Received: from XCH-BLV-306.nw.nos.boeing.com (130.247.25.218) by XCH-PHX-409.sw.nos.boeing.com (10.57.37.40) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 8 Jan 2014 14:09:29 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.203]) by XCH-BLV-306.nw.nos.boeing.com ([169.254.6.159]) with mapi id 14.03.0158.001; Wed, 8 Jan 2014 14:09:29 -0800 From: "Templin, Fred L" To: Randy Bush , Gert Doering Thread-Topic: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) Thread-Index: AQHPDLSn6J1CsFbJ1ku+GSVUUTw/25p7YC0w Date: Wed, 8 Jan 2014 22:09:27 +0000 Message-ID: <2134F8430051B64F815C691A62D98318192E82@XCH-BLV-504.nw.nos.boeing.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> <20140107104001.GM81676@Space.Net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 22:09:50 -0000 > the multi-million-euro enterprise can continue to do ipv4. and that's > what they are doing. That's fine - let them leave their IPv4 network infrastructure in place and deploy IPv6 using AERO: http://tools.ietf.org/html/draft-templin-aerolink It's all very simple. End user networks get IPv6 prefix delegations, and enterprise network servers keep track of where all the end user networks are located. DHCPv6 for prefix delegation, and RS/RA for routing and neighbor state maintenance. The enterprise network is seen by the end systems as a giant "link" over which IPv6 packets are transmitted between "neighbors". That's it. Thanks - Fred fred.l.templin@boeing.com=20 From otroan@employees.org Wed Jan 8 14:41:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C379F1AD73E for ; Wed, 8 Jan 2014 14:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GHXQJNQJ3b3 for ; Wed, 8 Jan 2014 14:41:31 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 34AEE1ACD04 for ; Wed, 8 Jan 2014 14:41:31 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAE/TzVKQ/khL/2dsb2JhbABZgws4uhWBFBZ0giYBAQR3AhALRlcGJ4dwDaoymgsXjwUHgySBEwEDkDOJFJBlgW+BPzs X-IronPort-AV: E=Sophos;i="4.95,626,1384300800"; d="asc'?scan'208";a="3356327" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 08 Jan 2014 22:41:21 +0000 Received: from dhcp-10-61-97-102.cisco.com (dhcp-10-61-97-102.cisco.com [10.61.97.102]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s08MfKgc015029 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Jan 2014 22:41:20 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_17888F2A-972F-414D-9D31-AF8DFA02DFC8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ole Troan In-Reply-To: <7F9988DB-00B8-47FF-928A-E346164BEAFD@puck.nether.net> Date: Wed, 8 Jan 2014 23:41:19 +0100 Message-Id: <7183B360-FD11-479E-9361-5A57D42F0308@employees.org> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> <20140107104001.GM81676@Space.Net> <72626BC4-CB9E-49E8-8A54-48A141F52C0C@nominum.com> <6A64F619-4A0E-423A-A5E7-4C3234B461AE@nominum.com> <7F9988DB-00B8-47FF-928A-E346164BEAFD@puck.nether.net> To: Jared Mauch X-Mailer: Apple Mail (2.1827) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 22:41:33 -0000 --Apple-Mail=_17888F2A-972F-414D-9D31-AF8DFA02DFC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >>>> if we want them to deploy ipv6, as opposed to more rfc1918 space, = then >>>> we need to remove all speed bumps. not discuss them. not tell = them >>>> that RA is the true religion. frelling remove the speed bump. >>>=20 >>> Can you name a specific speed bump? I've been listening to this >>> conversation for eight years too, and have yet to hear one named. = You >>> seem to be saying that RA is the speed bump, but that's not = specific. >>> What is it about RA that "they" need changed? >>=20 >> the missing dhcp function, exit router >=20 > For the rest of the class, please read the "turning on comcast v6" = thread for the operator community feedback. >=20 > http://mailman.nanog.org/pipermail/nanog/2013-December/thread.html > http://mailman.nanog.org/pipermail/nanog/2014-January/thread.html 15 messages in, and I still don't get it. could you summarize the problem in a sentence please? cheers, Ole --Apple-Mail=_17888F2A-972F-414D-9D31-AF8DFA02DFC8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSzdQPAAoJEFuJXizso86gAjEIALudg3nfcRRrOEYcBLUWMX78 wyldzV3vvkg67i4LJLilsDsBSlnOm0j8ej3l6gtxf2iwrirbzpfcCnIWJzQFKnb5 a8b2QPGFvt2Yf8CwaAaLMGSc8UHqPIggFpeHpBZ8LHWMJB7iE2WdsbZn+6m7oxkA izgPGjF55gJAIjeTTZ1qg+Q+6Q9etIJNul/JCCpP0QO5KuS1KujCqZEvu/7qtEnC vLKWRny7hyAf/mfOsAR3m8dA+bJNKxgHBagz/uLOEwr3e13KgbzFMErDWEbPObVx b2imDjZrwBrpwrNlWPmunx+8F8AP3g9SzrilvtNBg6nriDK1ZaI7HWyJEiaVs3c= =QSr1 -----END PGP SIGNATURE----- --Apple-Mail=_17888F2A-972F-414D-9D31-AF8DFA02DFC8-- From lorenzo@google.com Wed Jan 8 16:34:20 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7EB1ADF10 for ; Wed, 8 Jan 2014 16:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InPnqWEz9Sqm for ; Wed, 8 Jan 2014 16:34:17 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7F37E1ADF0F for ; Wed, 8 Jan 2014 16:34:17 -0800 (PST) Received: by mail-ig0-f178.google.com with SMTP id ut6so6150705igb.5 for ; Wed, 08 Jan 2014 16:34:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=IDWpXiTcdu/Z6il3So1w+kWWxQF09M25iOr6f+jBCeA=; b=QY1LCg4HqlimlwDKRlvfvWKXPB7SKV2WT3QNmojbsLPKnOZmuoNTHkN/jYzNsFVUVc 2Aw9iKfo+xeGifDJQ4bdSfOhvQjXsPiGoUGIJSAICw3IsBDfh/tIcMfYFdJ1vvAdT1qn mnzaoU54qMHnHVmLUZFmg7RPlXbs5OrAjk5WqCIpmr1hdUsyIIBywIJwdI9Ou3335ArW yVaqYtVhDwx1sbNMUOSlY8YAi2+SrTZGLBxfJAMfhBuXawGuwdY/c92paykRqjJoTwav aSy5Mila0vdVr8r9vpvIIC5VRxgsABwYuRZ9W8bCcKN6xSxAFYVNdl7bk1ZO8sC+jBhs 9B3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=IDWpXiTcdu/Z6il3So1w+kWWxQF09M25iOr6f+jBCeA=; b=KJFot4O37HizqT0ek/hp3+w8c+Swi1Kv7NH8u/nm5BU4QC8OZ2KDSYmKXuGo9ZpOe8 05OpB1qleksQLz5IXJ74GC/5QH7o74IwAaidSZAkWfZYNeNMDmLWOdFuIV+maJpA9wcv XB6y4j5UfoPDmv7pD0en6QkMXUTlakUforsDx2TeUcEck0PMXhuI8yUec2V5GcK/o2BD 4R3d5wUscRuJslGorL8SsWcxe2+5oequ4GEtkD/vE03sNz62J7Iyjei1xM9/X3mioBde uss4OmHteCeynqxLLz/6n7iKi/5oqd1zsbZ8eJG3t18qu9MDcRJBzpPDELSYKDRmm4ik 57qQ== X-Gm-Message-State: ALoCoQl3u3MzLSdgDqgkQ0/HF4tvL96M4kwjmAeVM1Het+qLmYJUf7+M/xjMlR3NZE2uwOQum1h94wj2bQDrBDeWMsd/JcLEjNcJKNSbz1Ss7oUWchnBZI9JFSOQzqiDkLIJqyoQiy0q0rouo+ylwjyPwY2XDDJitM8AJCdGg7AjhZhhsezzGj/yFRX2+ls0clwxLu8XYjEr X-Received: by 10.50.61.101 with SMTP id o5mr516083igr.31.1389227647878; Wed, 08 Jan 2014 16:34:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Wed, 8 Jan 2014 16:33:46 -0800 (PST) In-Reply-To: <85079612-5FFD-4DDE-B1FB-339512C8D125@nominum.com> References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <85079612-5FFD-4DDE-B1FB-339512C8D125@nominum.com> From: Lorenzo Colitti Date: Thu, 9 Jan 2014 09:33:46 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=001a1136035076e62a04ef7ec480 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 00:34:20 -0000 --001a1136035076e62a04ef7ec480 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 9, 2014 at 2:10 AM, Ted Lemon wrote: > On Jan 8, 2014, at 2:05 AM, Lorenzo Colitti wrote: > > 3. Please do not cite [DHCPv6-ROUTE]. That document was so controversial > that it was removed from the WG's charter and is no longer a WG item, so it > is inappropriate to cite it in an operational guidance document. > > I don't think this is a reasonable request. Yes, the document was > controversial. But also, it indisputably does solve the stated problem. So would HTTP requests to a well-known link-local address, or sniffing VRRPv3 requests. But those aren't IETF standards either. > I am deeply uncomfortable with the "process" that resulted in this > document being killed. I asked the MIF working group to drop it from > their charter because it was preventing useful work from being done in MIF > and didn't really make sense as a MIF working group item. > And I am deeply uncomfortable with the "process" that resulted in a solution document that had failed to reach consensus for adoption in two arguably more appropriate WGs (dhc and 6man) being made a charter item for a new WG, and then that WG claiming that it had to be published "because it was a charter item". But let's not talk about here. > The fact that it was removed from the MIF charter should not be taken as > any kind of agreement that the question of whether to publish the document > *somewhere* in the IETF has been conclusively resolved. I don't see any > strong need to revive it, but that is not the same thing as saying that we > have consensus that it's a bad idea. > But the fact that it was removed from the MIF charter recently is a clear signal that it is not an IETF standard, and that it is controversial, and thus, given that the IETF processes are based on rough consensus, that it is likely not to become a standard in the near future. Hence, recommending its use in an operational guidance document is inappropriate. An operational guidance document should not cite or recommend solutions that are not standards. --001a1136035076e62a04ef7ec480 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 9, 2014 at 2:10 AM, Ted Lemon <ted.lemon@nominum.com> wrote:
On Jan 8, 2014, at 2:05 AM= , Lorenzo Colitti <lorenzo@google.= com> wrote:
> 3. Please do not cite [DHCPv6-ROUTE]. That document was so controversi= al that it was removed from the WG's charter and is no longer a WG item= , so it is inappropriate to cite it in an operational guidance document.
I don't think this is a reasonable request. =C2=A0 Yes, the docum= ent was controversial. =C2=A0 But also, it indisputably does solve the stat= ed problem.

So would HTTP requests to a wel= l-known link-local address, or sniffing VRRPv3 requests. But those aren'= ;t IETF standards either.
=C2=A0
=C2=A0 I am deeply uncomfo= rtable with the "process" that resulted in this document being ki= lled. =C2=A0 I asked the MIF working group to drop it from their charter be= cause it was preventing useful work from being done in MIF and didn't r= eally make sense as a MIF working group item.

And I am deeply uncomfortable with the &qu= ot;process" that resulted in a solution document that had failed to re= ach consensus for adoption in two arguably more appropriate WGs (dhc and 6m= an) being made a charter item for a new WG, and then that WG claiming that = it had to be published "because it was a charter item". But let&#= 39;s not talk about here.
=C2=A0
The fact that it was remove= d from the MIF charter should not be taken as any kind of agreement that th= e question of whether to publish the document *somewhere* in the IETF has b= een conclusively resolved. =C2=A0 I don't see any strong need to revive= it, but that is not the same thing as saying that we have consensus that i= t's a bad idea.

But the fact that it was removed from the = MIF charter recently is a clear signal that it is not an IETF standard, and= that it is controversial, and thus, given that the IETF processes are base= d on rough consensus, that it is likely not to become a standard in the nea= r future. Hence, recommending its use in an operational guidance document i= s inappropriate. An operational guidance document should not cite or recomm= end solutions that are not standards.
--001a1136035076e62a04ef7ec480-- From lorenzo@google.com Wed Jan 8 17:02:05 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B72C1ADF10 for ; Wed, 8 Jan 2014 17:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkjaXDBzz1sX for ; Wed, 8 Jan 2014 17:02:03 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id ADB2C1ADF0E for ; Wed, 8 Jan 2014 17:02:03 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id m12so6198838iga.1 for ; Wed, 08 Jan 2014 17:01:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SvHST/TFeBq9YW0jrO35rS5/G7N6ULqfR3IVbZrA+MU=; b=SmtR3TT1IUZA/dQo7Mj8QtjYzo7rB/Yyo41PW+EB81t6KC8jPkkbzzXdDh+5jFilME /2leVGqVvg5TSSKdpNF0yJZ2ljR+d0y7AkYJ46Ixu6xeScHh6IdhnIFgPFJ0PF5u8/U5 SFAcbNCAv9KCdlkqHnjhiUDGSc9doGoFAAUGswaeI8Qo5ddLfMKnpq7iR0iRcRKIiiom eGsl0CdLpPLdiwhSVofOfteL1eSVfVMNpo4Jb9aMTQYRIhDOLvCiBrVpB8TRs17Y6mqY guRxhTSXD4JYS0my8j5mGZfqAoasg/fBlKMlmJ82HEugxgrnUr20EzR6umELoD5D50Kk Mdyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=SvHST/TFeBq9YW0jrO35rS5/G7N6ULqfR3IVbZrA+MU=; b=Qe9U+7LeMTTs4TFp4t7i89aa/67a9CcU0VaYjQwtUiz0t1PzJVp9C/Q0lcyjTN5JDC T662uZ/qJJmhnCqwpooL/tG4tGQZ3kAVbzkb02VUfTR7n78bRBygn/nJI6HdQo5BD7/P h9dPwFhMrPVQKP1hzuKbaj/2yWMBmDAGZn7aTUqKLWa3KphxJfg9UVmBIdYSDdheaVGi LVAjyK5azyutfWgx3+4cjaH47GuzlnH+OL/9GSiMp3pZ1Dgp7WzafIj23ZhvcS4AOyLr NJSgi/wugVXnDGBsmHHoH+piNPxcKFeKlxjhrsZIrlUzu7GYpgqhKImDlQk6F7oZVpdx yKjw== X-Gm-Message-State: ALoCoQmAxXMHEZy+7L5j+Vsx9DZiDEorfqv6CDp/FtuG0zSY/8qd4UHwYcy9fTALVMGZuWThb0EgmMaZRFE/kPWMdEPqqPGbRpkyei5aOtJ0jnCLl+5FSKlaE8HnPY+BpXEkLLDaQSKYAZig1GuZTMQnslf/hMB12FIi2jaMZVIuaS0Ikk0zjattCIhxMZcyVP2U7He3ll2w X-Received: by 10.50.36.67 with SMTP id o3mr670999igj.47.1389229314155; Wed, 08 Jan 2014 17:01:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Wed, 8 Jan 2014 17:01:34 -0800 (PST) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7@nkgeml506-mbx.china.huawei.com> References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7@nkgeml506-mbx.china.huawei.com> From: Lorenzo Colitti Date: Thu, 9 Jan 2014 10:01:34 +0900 Message-ID: To: "Liubing (Leo)" Content-Type: multipart/alternative; boundary=089e01160174c8c0c504ef7f274a Cc: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org, "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 01:02:05 -0000 --089e01160174c8c0c504ef7f274a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jan 8, 2014 at 10:39 PM, Liubing (Leo) wrot= e: > Can you remove it, then? As an operational group we don't want to > provide guidance on invalid use cases. :-) > > [Bing] I agree with you that =E2=80=9CDHCPv6-only without RA=E2=80=9D sho= uld not be > identified as a valid use case. But in the document, what we want to > caution the reader is that some operating systems would rely RAs to trigg= er > DHCPv6. I think =E2=80=9CRAs are necessary for IPv6 configuration=E2=80= =9D and =E2=80=9CRAs are > necessary to trigger DHCPv6=E2=80=9D are two different things in concept.= We just > want to emphasize the latter one. Maybe it is a little redundant in > wording, but at least it is not harmful? Especially considering that in > real practice, admins could enable routing configuration in DHCPv6 by > private/customized extension (ISC dhcpd & dibbler both provide the > capability) . I think maybe the redundancy wording could be useful for th= e > situations. > Ok, so if that's what you want to say, how about replacing section 3.2 with something like this: =3D=3D=3D 3.2. Guidance for DHCPv6-only Deployment Some networks prefer central management of all IP addressing. These networks may want to assign addresses only via DHCPv6. This can be accomplished by sending an RA that indicates that DHCPv6 address assignment is available (i.e., M=3D1), installing DHCPv6 servers or DHCPv6 relays on all links, and setting A=3D0 in the Prefix Information Options of all prefixes in the RA. Note that an RA is still necessary in order for hosts to be able to use these addresses. This is for two reasons: 1. Per problem #1, if there is no RA, some hosts will not attempt to obtain address configuration via DHCPv6 at all. 2. If there is no RA, or if the RA does not include a Prefix Information Option covering the addresses assigned via DHCPv6, then those addresses cannot be used for any communication, even on-link communication. This i= s because DHCPv6 does not provide a way to configure routing, and unless routing is configured by some other means, hosts will consider all destinations to be unreachable [RFC4943]. Thus, using DHCPv6 without an = RA does not currently provide any functionality. Also note that unlike SLAAC, DHCPv6 is not a strict requirement for IPv6 hosts [RFC6434], and some nodes do not support DHCPv6. Thus, this model can only be used if all the hosts that need IPv6 connectivity support DHCPv6. Per problem #2, if the administrators want to switch the DHCPv6-only configured hosts to SLAAC-only, this is not possible on some hosts without manually changing the hosts' configuration or using additional management tools. Per problem #4, for some platforms, the A flag and O flag might not be independent, when SLAAC is off, a stand-alone stateless DHCPv6 session would not be applicable. However, this might not be a common use case. =3D=3D=3D (Note: I don't understand what you meant by the last paragraph about problem #4, so I just repeated it as is in the suggestion above. But it should be clarified) Cheers, Lorenzo --089e01160174c8c0c504ef7f274a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 8, 2014 at 10:39 PM, Liubing (Leo) <leo.liubing@huawei.com> wrote:

Can you remove it= , then? As an operational group we don't want to provide guidance on in= valid use cases. :-)

[Bing] I agree with you tha= t =E2=80=9CDHCPv6-only without RA=E2=80=9D should not be identified as a va= lid use case. But in the document, what we want to caution the reader is that some operating systems would rely RAs to trigger DHCPv6= . I think =E2=80=9CRAs are necessary for IPv6 configuration=E2=80=9D =C2=A0= and =E2=80=9CRAs are necessary to trigger DHCPv6=E2=80=9D are two different= things in concept. We just want to emphasize the latter one. Maybe it is a little redundant in wording, but at least it is not harmful? Especial= ly considering that in real practice, admins could enable routing configura= tion in DHCPv6 by private/customized extension (ISC dhcpd & dibbler bot= h provide the capability) . I think maybe the redundancy wording could be useful for the situations.


Ok, so if t= hat's what you want to say, how about replacing section 3.2 with someth= ing like this:

=3D=3D=3D

3.2. Guidance f= or DHCPv6-only Deployment

Some networks pref= er central management of all IP addressing. These networks may want to assi= gn addresses only via DHCPv6.

This can be accomplished by sending an RA that indicate= s that DHCPv6 address assignment is available (i.e., M=3D1), installing DHC= Pv6 servers or DHCPv6 relays on all links, and setting A=3D0 in the Prefix = Information Options of all prefixes in the RA.

Note that an RA is still necessary in order for hosts t= o be able to use these addresses. This is for two reasons:
    Per problem #1, if there is no RA, some hosts will not attempt to obtain = address configuration via DHCPv6 at all.
  1. If there is no RA, or if the RA does not include a Prefix Informat= ion Option covering the addresses assigned via DHCPv6, then those addresses= cannot be used for any communication, even on-link communication. This is = because DHCPv6 does not provide a way to configure routing, and unless rout= ing is configured by some other means, hosts will consider all destinations= to be unreachable [RFC4943]. Thus, using DHCPv6 without an RA does not cur= rently provide any functionality.
Also note that unlike SLAAC, DHCPv6 is not a strict require= ment for IPv6 hosts [RFC6434], and some nodes do not support DHCPv6. Thus, = this model can only be used if all the hosts that need IPv6 connectivity su= pport DHCPv6.

Per problem #2, if the administrators want to swit= ch the DHCPv6-only configured hosts to SLAAC-only, this is not possible on = some hosts without manually changing the hosts' configuration or using = additional management tools.

Per problem #4, for some platforms, the A flag and O fl= ag might not be independent, when SLAAC is off, a stand-alone stateless DHC= Pv6 session would not be applicable. However, this might not be a common us= e case.

=3D=3D=3D

(Note: I don&#= 39;t understand what you meant by the last paragraph about problem #4, so I= just repeated it as is in the suggestion above. But it should be clarified= )

Cheers,
Lorenzo
--089e01160174c8c0c504ef7f274a-- From lorenzo@google.com Wed Jan 8 17:03:11 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF391ADF0E for ; Wed, 8 Jan 2014 17:03:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Obnhg2kxCoME for ; Wed, 8 Jan 2014 17:03:10 -0800 (PST) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 28BA41AD8F4 for ; Wed, 8 Jan 2014 17:03:10 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id e14so2899882iej.40 for ; Wed, 08 Jan 2014 17:03:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=oFnzYaBGHBN22AXGNGlkUDP6JMiJ/jNr5jVdBB637Sw=; b=Z6pQIPXkiNxXkkXeitiX55BFl+mUytE2UGwt9k6C7QljPP/4Pkde73rfRbSmpuDAMU N/xdSdj/8LR0NSz/3Hv07GTA0Q5n2RMizambGgX3lYWTMvkVX8/IXt5wHF0MryMLOSE9 A4Zgf/PR81n9wrPeI5zFyClw75YjHfVXqIcLMI0yelCJzCcb4nOHkheywy6RXh7XM5Yv aQiGixnGXiq44SI/DWzIBEv1gi0dwRlPfucXBTOGvi2G3gW0ifqA1HJ7UJjgRHPuJU2w 6UTyM0udmPkLtoh05RYx1QW+3GBqY4hpiK6II205H+Zb6HuE3MAeFwiEx7Elf918isex Ok5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=oFnzYaBGHBN22AXGNGlkUDP6JMiJ/jNr5jVdBB637Sw=; b=TnigTKH/SemRR/sH+4N/JyWSRuoZSWOsi3hMgOB8W0j/cFSLli7WDFJzL53WF2Tgqv 26KJ2QUYj/iBRg+E8Xx2h5EwblvsW/rEzv8gTRCdh10qMnyGKrhLa4VJWomek8cRKKNu wGeGKNFskV34VflLR3eLFI1qQn5/qbEss4R/OkJLyZA7rGeddQeWXxPp5gWy51r6DXLE Flw2/8r5+1jfa2B8qldX9r9tnvKMZyqee0EldCmajoCjqgwkJYvUOZibtJ6YFS/4GUUV 7XepdKxNvKQ8pfj9HeYnEvl/yKtUPzdZrDwDV20OGeADlUKm+Ag0YGEYPtvxYtK+os22 kdzg== X-Gm-Message-State: ALoCoQluWVqbsUxVpGzQQ0Lv88mT27hLgx3AqTKCoCa00NFSHil7OArdL1wCXQ1yKktzZCafCfjseD19J/EF4xImwjuVmQw4iIDtFdBNO4OgM9BnYR+NvKLXfXZM+h9fIByzMcKCfNG2Li9B+j+lMSbopjnkEUp3BgUxtdeogTm1fIro0ud3A1xG6tytbE7vKR9SibxS5CjK X-Received: by 10.42.227.66 with SMTP id iz2mr86851icb.77.1389229380742; Wed, 08 Jan 2014 17:03:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Wed, 8 Jan 2014 17:02:39 -0800 (PST) In-Reply-To: <3262931.LOsuuBpOXh@linne> References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <85079612-5FFD-4DDE-B1FB-339512C8D125@nominum.com> <3262931.LOsuuBpOXh@linne> From: Lorenzo Colitti Date: Thu, 9 Jan 2014 10:02:39 +0900 Message-ID: To: Karsten Thomann Content-Type: multipart/alternative; boundary=001a1132e2c4c09b8704ef7f2b21 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 01:03:11 -0000 --001a1132e2c4c09b8704ef7f2b21 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 9, 2014 at 4:07 AM, Karsten Thomann wrote: > I support Lorenzo, it should only contain information which is really > standardized today, or at least something which is expected to be > standardized in the next months... > > > > It should changed to something which simply clarifies that DHCPv6 without > any RAs are not working as there is no on-link and gateway information > available to the hosts, without any further sentence about DHCPv6-Route. > > > > Also I would like to add the information from Lorenzo about DHCPv6 with > RAs without on-link prefix information to document the expected behaviour. > > > > In my opinion it should document the behaviour which can be expected with > different configurations. > Does the text I just suggested work for you? --001a1132e2c4c09b8704ef7f2b21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 9, 2014 at 4:07 AM, Karsten Thomann <karsten_thomann@lin= fre.de> wrote:

I support Lorenzo, it = should only contain information which is really standardized today, or at l= east something which is expected to be standardized in the next months...

=C2=A0

It should changed to something which simply clarifies t= hat DHCPv6 without any RAs are not working as there is no on-link and gatew= ay information available to the hosts, without any further sentence about D= HCPv6-Route.

=C2=A0

Also I would like to add the information from Lorenzo a= bout DHCPv6 with RAs without on-link prefix information to document the exp= ected behaviour.

=C2=A0

In my opinion it should document the behaviour which ca= n be expected with different configurations.


Does the text I just suggested work for you?
--001a1132e2c4c09b8704ef7f2b21-- From lorenzo@google.com Wed Jan 8 17:21:11 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416281ADF65 for ; Wed, 8 Jan 2014 17:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huMUOt6s65A3 for ; Wed, 8 Jan 2014 17:21:09 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 99B621ADF62 for ; Wed, 8 Jan 2014 17:21:09 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id u16so440259iet.18 for ; Wed, 08 Jan 2014 17:21:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=AR5aqv6PV+9lTesymZqbiScheEf/MXc+YDlVy4DKCSc=; b=PyMuNGE6mH4XT/Tcc3kOHg3pjyLX6o9GqBGDgsc8FgqJPt002Jix38tSbPTPDgU0C4 AseWcbCYvBPGbBllJEO0PbYDX5mGNC7zkMKJ4TDLOtuTR7bVAa7QRjA7tzZH+PK0wGTk nDWlF1MS76tXdLa46FKhF6VttZlwwrBUXEWglD55EDuiX37aKozxE3NDKFGJbv4mkM3M d+T8JjzQj5ejKUj5bidwwk77SdUWAsTUup8lNFPNOMgsAGRdh0TAMuGgdH9fyNinQ/gP mWFyPqUuCzilv19tXRUya/2UlYBC9VxQBVxgt992dsf2KCfxzIGRfQwspftTts+hFjMx /CVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=AR5aqv6PV+9lTesymZqbiScheEf/MXc+YDlVy4DKCSc=; b=izXTFBNx+5hXc4WXhp7zYoUdutn8FCNg/ei0s4Bip5rsvjh558pQDz5oSvrjGyCbFs XhfMNBScrQkTpi8wbSfjd9KhX77DE843gNaqzuZI1IPv2nU0AwyjgNoEi8hv3CKlYyUM hEhtFOKnjzxf4QZ5h/2Yk3Pqpw62kmTQxPBGNvZ37vVsYCAuiIrQdeHMZiA9oJ9ymUXL pg/5N06YaRl9wLjcGFuTtfjiA4bE1PyULbHnRn9mfgHain6ACuY48/ISmuwYcZyh52rb +GduIu7tyWLqnvLa5NTtGrQJCwRm+4m/rvh9n422StJrIJZk2VSj6WZPeerqkUblXckb +Kpg== X-Gm-Message-State: ALoCoQklMqLdmMKBY3+qAL7BRFJ+rIcrAh9NfOn2oTTcY4FRhVBjMJJteUxpvm3DEY/eqW6FpWwtTHAnxmFXiIzClfBFZc7jJxHmw+2qs3p0pDrdN7wpNtHAGDCuNWwA5ElqahoLNHfBqJXGRHvbDp+xyvT7i9DjzuWsRv4Pz+dbq57+B0QcjiDa0BvTl49V1fGyDLKEseKq X-Received: by 10.50.61.101 with SMTP id o5mr651144igr.31.1389230460080; Wed, 08 Jan 2014 17:21:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Wed, 8 Jan 2014 17:20:39 -0800 (PST) In-Reply-To: References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> <20140107104001.GM81676@Space.Net> From: Lorenzo Colitti Date: Thu, 9 Jan 2014 10:20:39 +0900 Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=001a1136035015bea304ef7f6c8c Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 01:21:11 -0000 --001a1136035015bea304ef7f6c8c Content-Type: text/plain; charset=UTF-8 On Thu, Jan 9, 2014 at 6:00 AM, Randy Bush wrote: > > The thing that can not be done today is "do that if you do not have RAs > > on your network, that will tell the clients 'go to the DHCPv6 server > > for address information, but route the packets to me'". > > the multi-million-euro enterprise can continue to do ipv4. and that's > what they are doing. we can stick our heads and pretend that > this is not a festering and embarrassing problem or we can fix it. > We're talking about the same enterprises that weren't at the forefront of IPv4 adoption either, right? A [deliberately caricatured] strawman counterargument would be that what's going on is: 1. The network managers in those enterprises are change averse. 2. "We can't deploy IPv6 until we can configure routing via DHCPv6" is an excuse for not deploying IPv6, but the real reason is that there's no business need for doing so, and providing a way to configure routing via DHCPv6, will just cause them to move on to the next excuse. 3. When there is a business need to deploy IPv6, it will be deployed, lack-of-routing-in-DHCPv6 or not (after all that's what my enterprise did, and a fair number of others too, right?) Knock that down? Cheers, Lorenzo --001a1136035015bea304ef7f6c8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 9, 2014 at 6:00 AM, Randy Bush <randy@psg.com> wrote:
> The thing that can not be done today is "do tha= t if you do not have RAs
> on your network, that will tell the clients 'go to the DHCPv6 serv= er
> for address information, but route the packets to me'".

the multi-million-euro enterprise can continue to do ipv4. =C2=A0and = that's
what they are doing. =C2=A0we can stick our heads <fill in> and prete= nd that
this is not a festering and embarrassing problem or we can fix it.

We're talking about the same enterprises th= at weren't at the forefront of IPv4 adoption either, right? A [delibera= tely caricatured] strawman counterargument would be that what's going o= n is:

1. The network managers in those enterprises are change= averse.
2. "We can't deploy IPv6 until we can configure= routing via DHCPv6" is an excuse for not deploying IPv6, but the real= reason is that there's no business need for doing so, and providing a = way to configure routing via DHCPv6, will just cause them to move on to the= next excuse.
3. When there is a business need to deploy IPv6, it will be deployed, = lack-of-routing-in-DHCPv6 or not (after all that's what my enterprise d= id, and a fair number of others too, right?)

Knock that down?

Cheers,
Lorenzo
--001a1136035015bea304ef7f6c8c-- From lorenzo@google.com Wed Jan 8 17:46:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4531ADFAB for ; Wed, 8 Jan 2014 17:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnbTO89e-Hrh for ; Wed, 8 Jan 2014 17:46:05 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA5B1ADF9A for ; Wed, 8 Jan 2014 17:46:05 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id hk11so14785794igb.0 for ; Wed, 08 Jan 2014 17:45:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=cI0otNciNXueSbLzGl3Df/n6GcYPspVKYZukHLldaYk=; b=OTICwGGShBMhlAqYGDpq90JmiTHB33l2G19ZenqZpjrItrFZdwCPplLPCrBVr5IqcN Kpk4KLZ7LFMal455vJt2/9vgtYnvzv/A/98bOMymmw5wqSevVouqYS57nBGNoDQiUzQ9 MZeBqOhEOlcfs2V18feZ4gvlWarVcrwAbBXbob5dYsTK02p4ghCzEOOQkjYycMBxmAYg BbcLM9joP60xlVFBfidtVEC+ojpVgBwu3Ogu3LcJlrknW+ZtyKPH1JzVFC+yOE0WnywS sC1t7Z/ZCRWQ6oLVnA3IlrQUNMhNdrJOZuub9CmHpzx/fYHPbo/5unSglXnl9txPV9gJ 3rmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=cI0otNciNXueSbLzGl3Df/n6GcYPspVKYZukHLldaYk=; b=k4JoTEQ8s5CeELfYrLgtqaVd/NCFKiLjQTuMaNYuCeVNT/1Td2qmQXLMp4djm3/Kfm A2TNuht85CpZcQXJKnIQdSufc1uGsn9N4THCEVY61d0WMDkwTwxaznLcQ5tWMVeuDxBy X3v6DgBy2H5gvTYHd2KwSlIFA5oFhdyv06UNyFw3d2qsBE/YvnBERWfXjD1A20sEjPE5 zoxfKjkvYf491T98TTVoxNMp2yc56wjl9hYv/tLWJDRj30r8AkmTjxsgs+b2SBaVAkjM Tz0Gbq84+2AAGFygUiEcLb0CYyPVNT+VJdSN7RHdmTbE2yogAF6v5TWMzfPv5R+rjl6U jsRg== X-Gm-Message-State: ALoCoQldhowvQuHOrx6Hj5e0bSDQJuryddYd7YR8L0hwFMIuqboskVoNrMk2VIZ7wL8nnMEvIqw8HAMhk89qtzj/8Si3zsXt0b5xPkCfYVtJ2hTWclRW/AJtPgh8s4ug0zpVCHYQFD2Lyt3FH+RHHXk0yuZwfxdHcrKNnE4uAyKkcYMhHUu4Bnxo0BwO96h2gV9m+q7tdhtM X-Received: by 10.50.79.228 with SMTP id m4mr35010830igx.47.1389231955806; Wed, 08 Jan 2014 17:45:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Wed, 8 Jan 2014 17:45:35 -0800 (PST) In-Reply-To: <7183B360-FD11-479E-9361-5A57D42F0308@employees.org> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> <20140107104001.GM81676@Space.Net> <72626BC4-CB9E-49E8-8A54-48A141F52C0C@nominum.com> <6A64F619-4A0E-423A-A5E7-4C3234B461AE@nominum.com> <7F9988DB-00B8-47FF-928A-E346164BEAFD@puck.nether.net> <7183B360-FD11-479E-9361-5A57D42F0308@employees.org> From: Lorenzo Colitti Date: Thu, 9 Jan 2014 10:45:35 +0900 Message-ID: To: Ole Troan Content-Type: multipart/alternative; boundary=089e013a1f163cacb404ef7fc552 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 01:46:06 -0000 --089e013a1f163cacb404ef7fc552 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 9, 2014 at 7:41 AM, Ole Troan wrote: > > http://mailman.nanog.org/pipermail/nanog/2013-December/thread.html > > http://mailman.nanog.org/pipermail/nanog/2014-January/thread.html > > 15 messages in, and I still don't get it. > could you summarize the problem in a sentence please? > If you want to read it, it starts at http://mailman.nanog.org/pipermail/nanog/2013-December/062933.html The one-sentence summary is "we want to do it the same way as we do in IPv4". --089e013a1f163cacb404ef7fc552 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 9, 2014 at 7:41 AM, Ole Troan <otroan@employees.org> wrote:
15 messages in, and I still don't get it.
could you summarize the problem in a sentence please?
=
If you want to read it, it starts at=C2=A0http://mailman.nanog.org/pipermail/nanog/2013-December/062933.html<= /div>

The one-sentence summary is "we want to do it the = same way as we do in IPv4".
--089e013a1f163cacb404ef7fc552-- From marka@isc.org Wed Jan 8 17:56:31 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDC301ADFC3 for ; Wed, 8 Jan 2014 17:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sh22SqGcny_T for ; Wed, 8 Jan 2014 17:56:30 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 88E821ADFB8 for ; Wed, 8 Jan 2014 17:56:30 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 1E019C941E; Thu, 9 Jan 2014 01:56:09 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1389232581; bh=1QHq4WZNo1evX7cNyrWO3HcxIh+ZHbFgZSiNus72JGo=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=l42KBo+PlDnWbnbyeyqrW46nKMwSlEKaOPkncz1rzIww/74UwdZvxlZw29SPDu1Rn +pG0hWQ6MEv3x+8kDgtGwz4rvF/5N1ckDBdm03qTDYQr45QQIg246YDZQJjjTOTGL/ t0KoaAjLRUX6VUpv4a9+lRXuD7n/vKpDVb2DhBes= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 9 Jan 2014 01:56:09 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 90BF1160459; Thu, 9 Jan 2014 02:06:34 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 61AA6160446; Thu, 9 Jan 2014 02:06:34 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 0A6BAC8E346; Thu, 9 Jan 2014 12:57:22 +1100 (EST) To: Brian E Carpenter From: Mark Andrews References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CDA679.6010405@gmail.com> In-reply-to: Your message of "Thu, 09 Jan 2014 08:26:49 +1300." <52CDA679.6010405@gmail.com> Date: Thu, 09 Jan 2014 12:57:22 +1100 Message-Id: <20140109015723.0A6BAC8E346@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "v6ops@ietf.org" , Pete Vickers Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 01:56:32 -0000 In message <52CDA679.6010405@gmail.com>, Brian E Carpenter writes: > On 09/01/2014 06:28, Gert Doering wrote: > ... > > > Registering the MAC addresses and not permitting access *to the network* > > for unregistered devices is much more effective, but not strongly coupled > > to "DHCP" or "no RA". > > True. However, this will become harder if the planned ephemeral 802.11 > MAC addresses become widespread, as has been suggested over on the > perpass list. Then the network needs to use 802.1x and the host needs to renegotiate as required or the use of ephemeral 802.11 MAC addresses needs to be disabled for that network. Ephemeral 802.11 MAC addresses are great for when you are connecting to a hot spot. They don't help at all in the tightly controlled environment that doesn't want unauthorised devices being plugged in to succeed. Mark > Brian > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mpetach@gmail.com Wed Jan 8 18:56:14 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692321AE012 for ; Wed, 8 Jan 2014 18:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICjeLbv3LU2T for ; Wed, 8 Jan 2014 18:56:12 -0800 (PST) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDE21ADF9B for ; Wed, 8 Jan 2014 18:56:12 -0800 (PST) Received: by mail-pd0-f171.google.com with SMTP id z10so2591922pdj.2 for ; Wed, 08 Jan 2014 18:56:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=8UoiywG6xbrRFSuw9SCGpfyHIZTiEvqnID6qT2faClA=; b=l6isSzSZM7/h1TTnkNldTJujzRsgwXzAbIlksU9MlveBkvf/hqsvESicaW8mUV4GsI 0XmpD2X5pLwYRZbxCrrtJ2WnitjT/opgv1pitUmw0e1gKXOBtVr+/riT4FJ9iajEbKMI S8iPX1/Rt7HhXl1Lv43KoqJRlzAF5/3DK8+NOtWMXGmQj7ko6HRTUwv84PLWEeX04ZR0 as22yCki9AOJAJe7mbFSTZ9z8jKYvwJs4OWJUU5EDFY/gATrYH1ogZNGj9+vPTTIX5NB 57PSpir0rTvt6X8frgiXpK9IKU3zmitsOe/5H0NulhgVpUfDXys2K94XRui1LHaSloJH ++bA== MIME-Version: 1.0 X-Received: by 10.66.163.164 with SMTP id yj4mr663820pab.91.1389236162871; Wed, 08 Jan 2014 18:56:02 -0800 (PST) Sender: mpetach@gmail.com Received: by 10.70.1.130 with HTTP; Wed, 8 Jan 2014 18:56:02 -0800 (PST) Date: Wed, 8 Jan 2014 18:56:02 -0800 X-Google-Sender-Auth: e-mQHL1XhGO6I57XPhMXyuOhLQU Message-ID: From: Matthew Petach To: Owen DeLong Content-Type: multipart/alternative; boundary=047d7b86ec5eff497404ef80bf07 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 02:56:14 -0000 --047d7b86ec5eff497404ef80bf07 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Jan 7, 2014 at 10:10 AM, Owen DeLong wrote: > > >> As such, the options are not DHCPv6 only, RA-only, and Both, but, RA-onl= y >> and Both. >> >> The scenarios where RA-Only make sense are any scenario where you do not >> need greater control of the client configuration than Prefix information= , >> routing information, and DNS resolver addresses and search strings. >> >> In any scenario where you need to supply the host with more configuratio= n >> information on a dynamic basis, DHCPv6 is also required. >> >> Also, if you want dynamic DNS updates, deterministic assigned suffixes, >> etc., these fall into the DHCPv6 realm. >> >> It's really as simple as that as near as I can tell. >> >> If you want to run without RAs, then you are into the realm of static >> configuration. I, personally, do not see this as a problem. >> > > Or, you're a company with tens of thousands > of desktops, where static configuration is not > a viable option, but control over address > assignment from central servers is a must; > in that environment, DHCPv6-assignment-only is > a reality, and will exist; it is already being explored > today, and to to deny that it is coming is equally as > useful as cursing the coming of nightfall; it > will happen, with or without your agreement > or support. > > > We are talking about two different things=85 > > DHCPv6-assignment-only is possible today. It is what happens if you set > the M bit in the RA. DHCPv6 will then have full control of address > assignment. > > What is not possible today is to do that DHCPv6 assignment without > receiving an RA to instruct the host to do so. > > Why is that a problem for the network environments you have described? > I'm sorry, it's been a really busy week, so I'm a bit behind in following up to the people who have asked for further clarification. Here's the slightly more detailed description of the situation: 4 groups of hosts on the subnet; groupA, groupB, groupC, groupD; four different policies on the DHCP server. subnet has 4 different upstream routers. groupA is handed IP address on routerA as default gateway groupB is handed IP address on routerB as default gateway groupC is handed IP address on routerC as default gateway groupD is handed IP address on routerD as default gateway all four groups are within the same L2 broadcast domain, and have applications that make use of that same-subnet relationship. In looking at DHCPv6 vs RAs, I don't see how to give the different groups of hosts the appropriate default router IP unless the default router is provided by the DHCP server. The routers don't have a way to target their respective RAs to just members of the appropriate group of hosts, and there doesn't seem to be an option to tell the hosts in groupA to only listen to RAs from routerA. > As to getting software to do it, that=92s not really the problem. The > problem is that there=92s already lots of deployed hardware and software = that > is implemented as defined in the current RFCs. > > It=92s the elimination of RAs that is problematic. Using DHCP exclusively > for address assignment isn=92t difficult. Adding routing information to > DHCPv6 wouldn=92t be all that difficult. > > So, I apologize for the confusion. I didn't mean that RAs need to go away; I simply meant we need a way for the hosts to ignore the default router information from the RA, and instead to obtain that from DHCPv6. Essentially, having the RA only pass the "go ask DHCPv6" option bits to the hosts, and everything else gets superseded by what the DHCPv6 server sends to the host. > Eliminating RAs from the process would require a major change that would > likely pose some level of compatibility problem with existing deployments= . > > Owen > > Sorry; it's not really eliminating the RAs from the process as much as saying "ignore what the RA is sending you, other than the option bits telling you to go ask the DHCPv6 server for your info, and use what the DHCPv6 server gives you, including your default route information." I hope that's a bit clearer; sorry to not have been clearer earlier. Thanks!! Matt --047d7b86ec5eff497404ef80bf07 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Tue, Jan 7, 2014 at 10:10 AM, Owen DeLong <= owen@delong.com>= ; wrote:

As to getting software to do it, that=92s not really t= he problem. The problem is that there=92s already lots of deployed hardware= and software that is implemented as defined in the current RFCs.

It=92s the elimination of RAs that is problematic. Usin= g DHCP exclusively for address assignment isn=92t difficult. Adding routing= information to DHCPv6 wouldn=92t be all that difficult.


So, I apologize for the confusion.= =A0 I didn't mean that RAs need
to go away; I simply meant we need a= way for the hosts to
ignore the default router information f= rom the RA, and instead
to obtain that from DHCPv6.=A0 Essentially, having the RA only
pass the "go ask DHCPv6" option bits to the hosts, and
every= thing else gets superseded by what the DHCPv6
server sends to the host.<= br>
=A0
Eliminating RAs from the process would requ= ire a major change that would likely pose some level of compatibility probl= em with existing deployments.

Owen


Sorry; it's not really eliminating the RAs from the p= rocess as much
as saying "ignore what the RA is sending you, other than the
option= bits telling you to go ask the DHCPv6 server for your info,
and use what the DHCPv6 server gives you, including y= our
default route information."

I hope that's a bit clearer; sorry to no= t have been clearer
earlier.

Thanks!!

Matt

--047d7b86ec5eff497404ef80bf07-- From owen@delong.com Wed Jan 8 19:18:09 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE74C1AE0CA for ; Wed, 8 Jan 2014 19:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giKFX6BfmJNB for ; Wed, 8 Jan 2014 19:18:05 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id B3EE81AE051 for ; Wed, 8 Jan 2014 19:18:05 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s093H94f024304 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 8 Jan 2014 19:17:09 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s093H94f024304 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1389237429; bh=XKOUYzk5vmGw67Rdu8xutIqOLmk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=lKOcK8sYpE3SI5mbKmO07k1pxTvD+V2NHe7ukGtxMoHXc/6mOJFOig5Mm8aoggv4+ OKT5x3baQM51anp+v4wAsbXFDjI9n8NmCijrDQyqhR8CgNYu3mqTzc8eVkgwrHRGNU o0VsKnBdRXPHgDnkAxRtoQCdPu5PbqDNxdZ+y7gg= Content-Type: multipart/alternative; boundary="Apple-Mail=_A51BED30-FEE5-4C7B-A080-5A474FEAC9AE" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Owen DeLong In-Reply-To: Date: Wed, 8 Jan 2014 19:17:08 -0800 Message-Id: <24CFBACC-7994-47D2-AAC5-F4CCAB4B29D8@delong.com> References: To: Matthew Petach X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 08 Jan 2014 19:17:09 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 03:18:09 -0000 --Apple-Mail=_A51BED30-FEE5-4C7B-A080-5A474FEAC9AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jan 8, 2014, at 18:56 , Matthew Petach wrote: >=20 >=20 >=20 > On Tue, Jan 7, 2014 at 10:10 AM, Owen DeLong wrote: >=20 >>=20 >> As such, the options are not DHCPv6 only, RA-only, and Both, but, = RA-only and Both. >>=20 >> The scenarios where RA-Only make sense are any scenario where you do = not need greater control of the client configuration than Prefix = information, routing information, and DNS resolver addresses and search = strings. >>=20 >> In any scenario where you need to supply the host with more = configuration information on a dynamic basis, DHCPv6 is also required. >>=20 >> Also, if you want dynamic DNS updates, deterministic assigned = suffixes, etc., these fall into the DHCPv6 realm. >>=20 >> It's really as simple as that as near as I can tell. >>=20 >> If you want to run without RAs, then you are into the realm of static = configuration. I, personally, do not see this as a problem. >>=20 >> Or, you're a company with tens of thousands >> of desktops, where static configuration is not >> a viable option, but control over address=20 >> assignment from central servers is a must; >> in that environment, DHCPv6-assignment-only is=20 >> a reality, and will exist; it is already being explored=20 >> today, and to to deny that it is coming is equally as >> useful as cursing the coming of nightfall; it >> will happen, with or without your agreement >> or support. >>=20 >=20 > We are talking about two different things=85 >=20 > DHCPv6-assignment-only is possible today. It is what happens if you = set the M bit in the RA. DHCPv6 will then have full control of address = assignment. >=20 > What is not possible today is to do that DHCPv6 assignment without = receiving an RA to instruct the host to do so. >=20 > Why is that a problem for the network environments you have described? >=20 >=20 > I'm sorry, it's been a really busy week, so I'm a bit behind in > following up to the people who have asked for further clarification. >=20 > Here's the slightly more detailed description of the situation: >=20 > 4 groups of hosts on the subnet; > groupA, groupB, groupC, groupD; > four different policies on the DHCP server. > subnet has 4 different upstream routers. > groupA is handed IP address on routerA as default gateway > groupB is handed IP address on routerB as default gateway > groupC is handed IP address on routerC as default gateway > groupD is handed IP address on routerD as default gateway >=20 > all four groups are within the same L2 broadcast domain, > and have applications that make use of that same-subnet > relationship. Ignoring for the moment that this is an incredibly convoluted corner = case which is likely fragile, at best, in IPv4... In IPv4, that makes sense. In IPv6, it does not. In IPv6, you don't have broadcasts, it's all multicast. You can define a = multicast scope (ff04 perhaps?) that incorporates those 4 distinct IPv6 = subnets. > In looking at DHCPv6 vs RAs, I don't see how to give the > different groups of hosts the appropriate default router IP > unless the default router is provided by the DHCP server. That's because you haven't looked at the fact that in IPv6, these don't = need a shared broadcast domain to continue working the way you describe. > The routers don't have a way to target their respective > RAs to just members of the appropriate group of hosts, > and there doesn't seem to be an option to tell the hosts > in groupA to only listen to RAs from routerA. You could, but it would involve elaborate configuration on the routers. = It makes more sense to divide these groups of hosts into separate IPv6 = networks. >=20 > As to getting software to do it, that=92s not really the problem. The = problem is that there=92s already lots of deployed hardware and software = that is implemented as defined in the current RFCs. >=20 > It=92s the elimination of RAs that is problematic. Using DHCP = exclusively for address assignment isn=92t difficult. Adding routing = information to DHCPv6 wouldn=92t be all that difficult. >=20 >=20 > So, I apologize for the confusion. I didn't mean that RAs need > to go away; I simply meant we need a way for the hosts to > ignore the default router information from the RA, and instead > to obtain that from DHCPv6. Essentially, having the RA only > pass the "go ask DHCPv6" option bits to the hosts, and > everything else gets superseded by what the DHCPv6 > server sends to the host. I don't see a mechanism for not treating a router announcing RAs as a = candidate default route is likely to succeed. I think it would require = modifications to host stacks that could not be backward compatible with = existing implementations. I'm all for adding RIO equivalence in DHCPv6, though I think it is = significantly less useful than advocated. >=20 > =20 > Eliminating RAs from the process would require a major change that = would likely pose some level of compatibility problem with existing = deployments. >=20 > Owen >=20 >=20 > Sorry; it's not really eliminating the RAs from the process as much > as saying "ignore what the RA is sending you, other than the > option bits telling you to go ask the DHCPv6 server for your info, > and use what the DHCPv6 server gives you, including your > default route information." I can certainly see ways to suggest that DHCPv6 route information, if = presented, should supersede any route information learned via RA. I = don't see ignoring the RA information completely. >=20 > I hope that's a bit clearer; sorry to not have been clearer > earlier. Much clearer. I have to ask... Do you have a running network where this = actually is still in use? I've seen a few environments like this, but = most of them were deprecated years ago due to various problems that they = create in IPv4. Owen --Apple-Mail=_A51BED30-FEE5-4C7B-A080-5A474FEAC9AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jan 8, 2014, at 18:56 , Matthew = Petach <mpetach@netflight.com> = wrote:




On Tue, Jan 7, 2014 at 10:10 AM, Owen DeLong = <owen@delong.com> wrote:


As such, the options are not DHCPv6 only, RA-only, and Both, but, = RA-only and Both.

The scenarios where RA-Only make sense are any scenario where you do not = need greater control of the client configuration than Prefix = information, routing information, and DNS resolver addresses and search = strings.

In any scenario where you need to supply the host with more = configuration information on a dynamic basis, DHCPv6 is also = required.

Also, if you want dynamic DNS updates, deterministic assigned suffixes, = etc., these fall into the DHCPv6 realm.

It's really as simple as that as near as I can tell.

If you want to run without RAs, then you are into the realm of static = configuration. I, personally, do not see this as a = problem.

Or, you're a company with = tens of thousands
of desktops, where static configuration is not
a viable option, but control over address
assignment from = central servers is a must;
in that environment, = DHCPv6-assignment-only is
a reality, and will exist; it is already = being explored
today, and to to deny that it is coming is equally = as
useful as cursing the coming of nightfall; it
will happen, with or = without your agreement
or = support.


=
We are talking about two different things=85

DHCPv6-assignment-only is possible today. It is what = happens if you set the M bit in the RA. DHCPv6 will then have full = control of address assignment.

What is not = possible today is to do that DHCPv6 assignment without receiving an RA = to instruct the host to do so.

Why is that a problem for the network environments = you have described?


I'm = sorry, it's been a really busy week, so I'm a bit behind in
following = up to the people who have asked for further clarification.

Here's the slightly more detailed description of the = situation:

4 groups of hosts on the = subnet;
groupA, groupB, groupC, groupD;
four different = policies on the DHCP server.
subnet has 4 different upstream routers.
groupA is handed = IP address on routerA as default gateway
groupB is handed IP address = on routerB as default gateway
groupC is handed IP address = on routerC as default gateway
groupD is handed IP address on routerD as default = gateway

all four groups are within the same L2 = broadcast domain,
and have applications that make use of that = same-subnet
relationship.
=
Ignoring for the moment that this is an incredibly = convoluted corner case which is likely fragile, at best, in = IPv4...

In IPv4, that makes sense. In IPv6, it does = not.

In IPv6, you don't have broadcasts, it's = all multicast. You can define a multicast scope (ff04 perhaps?) that = incorporates those 4 distinct IPv6 subnets.

In looking at DHCPv6 vs RAs, I don't see how = to give the
different groups of hosts the appropriate default = router IP
unless the default router is provided by the DHCP = server.

That's = because you haven't looked at the fact that in IPv6, these don't need a = shared broadcast domain to continue working the way you = describe.

The routers don't have a way to target their respective
RAs to just = members of the appropriate group of hosts,
and there = doesn't seem to be an option to tell the hosts
in groupA to only = listen to RAs from = routerA.

You = could, but it would involve elaborate configuration on the routers. It = makes more sense to divide these groups of hosts into separate IPv6 = networks.


As to getting = software to do it, that=92s not really the problem. The problem is that = there=92s already lots of deployed hardware and software that is = implemented as defined in the current RFCs.

It=92s the elimination of RAs that is problematic. = Using DHCP exclusively for address assignment isn=92t difficult. Adding = routing information to DHCPv6 wouldn=92t be all that = difficult.


So, I apologize for the = confusion.  I didn't mean that RAs need
to go away; I simply = meant we need a way for the hosts to
ignore the default = router information from the RA, and instead
to obtain that from DHCPv6.  Essentially, having the RA = only
pass the "go ask DHCPv6" option bits to the hosts, = and
everything else gets superseded by what the DHCPv6
server = sends to the = host.

I = don't see a mechanism for not treating a router announcing RAs as a = candidate default route is likely to succeed. I think it would require = modifications to host stacks that could not be backward compatible with = existing implementations.

I'm all for adding = RIO equivalence in DHCPv6, though I think it is significantly less = useful than advocated.


 
Eliminating RAs from the = process would require a major change that would likely pose some level = of compatibility problem with existing deployments.

Owen


Sorry; = it's not really eliminating the RAs from the process as much
as saying "ignore what the RA is sending you, other than the
option = bits telling you to go ask the DHCPv6 server for your = info,
and use what the DHCPv6 server = gives you, including your
default route = information."

I can certainly = see ways to suggest that DHCPv6 route information, if presented, should = supersede any route information learned via RA. I don't see ignoring the = RA information completely.


I hope that's a bit clearer; sorry to not have = been clearer
earlier.

Much = clearer. I have to ask... Do you have a running network where this = actually is still in use? I've seen a few environments like this, but = most of them were deprecated years ago due to various problems that they = create in = IPv4.

Owen

= --Apple-Mail=_A51BED30-FEE5-4C7B-A080-5A474FEAC9AE-- From marka@isc.org Wed Jan 8 19:28:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E82F1AE0D7 for ; Wed, 8 Jan 2014 19:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.439 X-Spam-Level: X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kB_9t9tjfIDS for ; Wed, 8 Jan 2014 19:28:28 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by ietfa.amsl.com (Postfix) with ESMTP id 08FD81AE053 for ; Wed, 8 Jan 2014 19:28:28 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 2E4E92383A7; Thu, 9 Jan 2014 03:28:06 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 4624C160446; Thu, 9 Jan 2014 03:38:31 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id B7899160389; Thu, 9 Jan 2014 03:38:30 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 77E84C97CF5; Thu, 9 Jan 2014 14:29:19 +1100 (EST) To: Matthew Petach From: Mark Andrews References: In-reply-to: Your message of "Wed, 08 Jan 2014 18:56:02 -0800." Date: Thu, 09 Jan 2014 14:29:18 +1100 Message-Id: <20140109032919.77E84C97CF5@rock.dv.isc.org> Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 03:28:30 -0000 In message , Matthew Petach writes: > > On Tue, Jan 7, 2014 at 10:10 AM, Owen DeLong wrote: > > > > > > >> As such, the options are not DHCPv6 only, RA-only, and Both, but, > >> RA-only and Both. > >> > >> The scenarios where RA-Only make sense are any scenario where you do > >> not need greater control of the client configuration than Prefix > >> information, routing information, and DNS resolver addresses and > >> search strings. > >> > >> In any scenario where you need to supply the host with more > >> configuration information on a dynamic basis, DHCPv6 is also required. > >> > >> Also, if you want dynamic DNS updates, deterministic assigned suffixes, > >> etc., these fall into the DHCPv6 realm. > >> > >> It's really as simple as that as near as I can tell. > >> > >> If you want to run without RAs, then you are into the realm of static > >> configuration. I, personally, do not see this as a problem. > >> > > > > Or, you're a company with tens of thousands > > of desktops, where static configuration is not > > a viable option, but control over address > > assignment from central servers is a must; > > in that environment, DHCPv6-assignment-only is > > a reality, and will exist; it is already being explored > > today, and to to deny that it is coming is equally as > > useful as cursing the coming of nightfall; it > > will happen, with or without your agreement > > or support. > > > > > > We are talking about two different things... > > > > > DHCPv6-assignment-only is possible today. It is what happens if you set > > the M bit in the RA. DHCPv6 will then have full control of address > > assignment. > > > > What is not possible today is to do that DHCPv6 assignment without > > receiving an RA to instruct the host to do so. > > > > Why is that a problem for the network environments you have described? > > > > > I'm sorry, it's been a really busy week, so I'm a bit behind in > following up to the people who have asked for further clarification. > > Here's the slightly more detailed description of the situation: > > 4 groups of hosts on the subnet; > groupA, groupB, groupC, groupD; > four different policies on the DHCP server. > subnet has 4 different upstream routers. > groupA is handed IP address on routerA as default gateway > groupB is handed IP address on routerB as default gateway > groupC is handed IP address on routerC as default gateway > groupD is handed IP address on routerD as default gateway > > all four groups are within the same L2 broadcast domain, > and have applications that make use of that same-subnet > relationship. > > In looking at DHCPv6 vs RAs, I don't see how to give the > different groups of hosts the appropriate default router IP > unless the default router is provided by the DHCP server. > The routers don't have a way to target their respective > RAs to just members of the appropriate group of hosts, > and there doesn't seem to be an option to tell the hosts > in groupA to only listen to RAs from routerA. > > > > > As to getting software to do it, that's not really the problem. The > > problem is that there's already lots of deployed hardware and software > > that is implemented as defined in the current RFCs. > > > > It's the elimination of RAs that is problematic. Using DHCP exclusively > > for address assignment isn't difficult. Adding routing information to > > DHCPv6 wouldn't be all that difficult. > > > > > So, I apologize for the confusion. I didn't mean that RAs need > to go away; I simply meant we need a way for the hosts to > ignore the default router information from the RA, and instead > to obtain that from DHCPv6. Essentially, having the RA only > pass the "go ask DHCPv6" option bits to the hosts, and > everything else gets superseded by what the DHCPv6 > server sends to the host. If you want all the nodes to not use the RA to set a default route then set Router Lifetime to zero. Router Lifetime 16-bit unsigned integer. The lifetime associated with the default router in units of seconds. The field can contain values up to 65535 and receivers should handle any value, while the sending rules in Section 6 limit the lifetime to 9000 seconds. A Lifetime of 0 indicates that the router is not a default router and SHOULD NOT appear on the default router list. The Router Lifetime applies only to the router's usefulness as a default router; it does not apply to information contained in other message fields or options. Options that need time limits for their information include their own lifetime fields. > > Eliminating RAs from the process would require a major change that would > > likely pose some level of compatibility problem with existing deployments. > > > > Owen > > > > > Sorry; it's not really eliminating the RAs from the process as much > as saying "ignore what the RA is sending you, other than the > option bits telling you to go ask the DHCPv6 server for your info, > and use what the DHCPv6 server gives you, including your > default route information." > > I hope that's a bit clearer; sorry to not have been clearer > earlier. > > Thanks!! > > Matt -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mpetach@gmail.com Wed Jan 8 19:35:00 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2781ADF9B for ; Wed, 8 Jan 2014 19:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1un5IgLfFFRj for ; Wed, 8 Jan 2014 19:34:57 -0800 (PST) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE8C1ADFDA for ; Wed, 8 Jan 2014 19:34:57 -0800 (PST) Received: by mail-pb0-f43.google.com with SMTP id rq2so2423270pbb.30 for ; Wed, 08 Jan 2014 19:34:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4LYEiJqyeMK+z+dBRXBSkqu8uGSQ0q5DpZgIvSQQalQ=; b=t8sHZBJ5ljd5UdVblBINjHTnvydT1MSF9nA/IAZFTkeCLNpuViwszLlbBWOd71mNRi 51/F4mIBWFRDcVjtqL+vFeUuk8L759jTirhWLbz0/uTw7zG52rl3VPa1DM88tkU4A36U YCjbRnz8Y+b9Vz+5HsC18NnK7piA4r+BHMmEhkWHk2Seu86SKWzYFs901ZUWM+gy+TY9 XzfqyV4TNrDUQmpMckaD1x4GSw7/hZ5p3ue43hiyeM56KgUGvHmRUojlm9dkmJMEPZcw ViIThaHkXeU5yRVRLV0w8424U0KFS6s6bjG1dFiMaMHe+JrP+XQponiqVCi1h1fUNeFp hkyg== MIME-Version: 1.0 X-Received: by 10.66.66.202 with SMTP id h10mr993553pat.70.1389238488307; Wed, 08 Jan 2014 19:34:48 -0800 (PST) Sender: mpetach@gmail.com Received: by 10.70.1.130 with HTTP; Wed, 8 Jan 2014 19:34:48 -0800 (PST) In-Reply-To: <24CFBACC-7994-47D2-AAC5-F4CCAB4B29D8@delong.com> References: <24CFBACC-7994-47D2-AAC5-F4CCAB4B29D8@delong.com> Date: Wed, 8 Jan 2014 19:34:48 -0800 X-Google-Sender-Auth: -I8LAk4QXfYa8tKK_U-R1ZUspgI Message-ID: From: Matthew Petach To: Owen DeLong Content-Type: multipart/alternative; boundary=001a1134a8669a9e9804ef814a95 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 03:35:00 -0000 --001a1134a8669a9e9804ef814a95 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Jan 8, 2014 at 7:17 PM, Owen DeLong wrote: > > On Jan 8, 2014, at 18:56 , Matthew Petach wrote: > > > > I'm sorry, it's been a really busy week, so I'm a bit behind in > following up to the people who have asked for further clarification. > > Here's the slightly more detailed description of the situation: > > 4 groups of hosts on the subnet; > groupA, groupB, groupC, groupD; > four different policies on the DHCP server. > subnet has 4 different upstream routers. > groupA is handed IP address on routerA as default gateway > groupB is handed IP address on routerB as default gateway > groupC is handed IP address on routerC as default gateway > groupD is handed IP address on routerD as default gateway > > all four groups are within the same L2 broadcast domain, > and have applications that make use of that same-subnet > relationship. > > > Ignoring for the moment that this is an incredibly convoluted corner case > which is likely fragile, at best, in IPv4... > > It's actually not that convoluted; it allows you to segment your traffic flows across different upstream devices/interfaces without having to forklift upgrade your network infrastructure completely. defaultA is actually an HSRP address that is master on routerA, backup on routerB; defaultB is master on routerB, backup on routerC; defaultC is master on routerC, backup on routerD; and defaultD is master on routerD, backup on routerA. Each router takes care of 25% of the host load for the network that way. > In IPv4, that makes sense. In IPv6, it does not. > > In IPv6, you don't have broadcasts, it's all multicast. You can define a > multicast scope (ff04 perhaps?) that incorporates those 4 distinct IPv6 > subnets. > But it requires your router be configured to route multicast traffic between subnets in order for that to work, when in the v4 space, the traffic between hosts doesn't require participation from the router for host-to-host communication to function. > > In looking at DHCPv6 vs RAs, I don't see how to give the > different groups of hosts the appropriate default router IP > unless the default router is provided by the DHCP server. > > > That's because you haven't looked at the fact that in IPv6, these don't > need a shared broadcast domain to continue working the way you describe. > It's somewhat awkward telling a group of users "so, in v4, you're on the same subnet and can communicate directly; but in v6, you're on different subnets and can't communicate directly". Yes, I suppose we could try to do do non-homologous topologies for v4 and v6 for dual-stacked hosts, but troubleshooting that kinda scares me a bit. :( > > The routers don't have a way to target their respective > RAs to just members of the appropriate group of hosts, > and there doesn't seem to be an option to tell the hosts > in groupA to only listen to RAs from routerA. > > > You could, but it would involve elaborate configuration on the routers. I= t > makes more sense to divide these groups of hosts into separate IPv6 > networks. > Would that mean having to go back and break up the v4 topology to match what's best for v6, or run a different topology for v6 and v4 on the same hosts? It kinda sounds like the message is "v6 is a different beast, and to use it, you have to redo your network, including your v4 topology, to best match what v6 wants." > > >> As to getting software to do it, that=92s not really the problem. The >> problem is that there=92s already lots of deployed hardware and software= that >> is implemented as defined in the current RFCs. >> >> It=92s the elimination of RAs that is problematic. Using DHCP exclusivel= y >> for address assignment isn=92t difficult. Adding routing information to >> DHCPv6 wouldn=92t be all that difficult. >> >> > So, I apologize for the confusion. I didn't mean that RAs need > to go away; I simply meant we need a way for the hosts to > ignore the default router information from the RA, and instead > to obtain that from DHCPv6. Essentially, having the RA only > pass the "go ask DHCPv6" option bits to the hosts, and > everything else gets superseded by what the DHCPv6 > server sends to the host. > > > I don't see a mechanism for not treating a router announcing RAs as a > candidate default route is likely to succeed. I think it would require > modifications to host stacks that could not be backward compatible with > existing implementations. > > I'm all for adding RIO equivalence in DHCPv6, though I think it is > significantly less useful than advocated. > > > > >> Eliminating RAs from the process would require a major change that would >> likely pose some level of compatibility problem with existing deployment= s. >> >> Owen >> >> > Sorry; it's not really eliminating the RAs from the process as much > as saying "ignore what the RA is sending you, other than the > option bits telling you to go ask the DHCPv6 server for your info, > and use what the DHCPv6 server gives you, including your > default route information." > > > I can certainly see ways to suggest that DHCPv6 route information, if > presented, should supersede any route information learned via RA. I don't > see ignoring the RA information completely. > Sure, supersede vs ignore is fine; main point being the DHCPv6 server knows better what that group of hosts should be using than the router does, so the host should use what the DHCPv6 server sends it, not the RA message from the router. > > > I hope that's a bit clearer; sorry to not have been clearer > earlier. > > > Much clearer. I have to ask... Do you have a running network where this > actually is still in use? I've seen a few environments like this, but mos= t > of them were deprecated years ago due to various problems that they creat= e > in IPv4. > > Owen > > Virtualization is actually increasing the number of deployments in that mode, rather than decreasing them. Matt --001a1134a8669a9e9804ef814a95 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Wed, Jan 8, 2014 at 7:17 PM, Owen DeLong <<= a href=3D"mailto:owen@delong.com" target=3D"_blank">owen@delong.com>= wrote:

On Jan 8, 2014, at 18:56 , Matthew Petach <= mpetach@netfligh= t.com> wrote:



I'm sorry, it's b= een a really busy week, so I'm a bit behind in
following up to the p= eople who have asked for further clarification.

Here's the slightly more detailed description of the sit= uation:

4 groups of hosts on the subnet;
gr= oupA, groupB, groupC, groupD;
four different policies on the DHCP server= .
subnet has 4 different upstream routers.
groupA is handed IP = address on routerA as default gateway
groupB is handed IP address on rou= terB as default gateway
groupC is handed IP address on router= C as default gateway
groupD is handed IP address on routerD as default gateway
all four groups are within the same L2 broadcast domain,
and= have applications that make use of that same-subnet
relationship.

Ignori= ng for the moment that this is an incredibly convoluted corner case which i= s likely fragile, at best, in IPv4...


It's actually not that convoluted; it allows you to= segment
your traffic flows across different upstream devices= /interfaces
without having to forklift upgrade your network infrastructu= re
completely.=A0 defaultA is actually an HSRP address that is
master on ro= uterA, backup on routerB; defaultB is master
on routerB, backup on route= rC; defaultC is master on
routerC, backup on routerD; and defaultD is ma= ster
on routerD, backup on routerA.=A0 Each router takes
care of 2= 5% of the host load for the network that way.
=A0
In IPv4, that makes sen= se. In IPv6, it does not.

In IPv6, you don't h= ave broadcasts, it's all multicast. You can define a multicast scope (f= f04 perhaps?) that incorporates those 4 distinct IPv6 subnets.

But it requires your router be confi= gured to route
multicast traffic between subnets in order for that
to= work, when in the v4 space, the traffic between
hosts doesn't requi= re participation from the router
for host-to-host communication to function.

=A0

<= div class=3D"gmail_quote">
In looking at DHCPv6 vs RAs, I don't see= how to give the
different groups of hosts the appropriate defaul= t router IP
unless the default router is provided by the DHCP server.

That's because you haven= 9;t looked at the fact that in IPv6, these don't need a shared broadcas= t domain to continue working the way you describe.

It's somewhat awkward telling a = group of users
"so, in v4, you're on the same subnet= and can
communicate directly; but in v6, you're on
different sub= nets and can't communicate
directly".=A0 Yes, I suppose we could try to do
do non-homologous = topologies for v4 and
v6 for dual-stacked hosts, but troubleshooting
= that kinda scares me a bit.=A0 :(

=A0

The routers don't have a way to target their respective
RAs to just = members of the appropriate group of hosts,
and there doesn= 9;t seem to be an option to tell the hosts
in groupA to only listen to R= As from routerA.

You could, but it= would involve elaborate configuration on the routers. It makes more sense = to divide these groups of hosts into separate IPv6 networks.

Would that mean having to go back and brea= k
up the v4 topology to match what's best for v6,
or run a differ= ent topology for v6 and v4 on the
same hosts?

It kinda sounds lik= e the message is "v6 is a
different beast, and to use it, you have to
redo your network, including= your v4 topology,
to best match what v6 wants."

= =A0


As to getting software to do i= t, that=92s not really the problem. The problem is that there=92s already l= ots of deployed hardware and software that is implemented as defined in the= current RFCs.

It=92s the elimination of RAs that is problematic. Usin= g DHCP exclusively for address assignment isn=92t difficult. Adding routing= information to DHCPv6 wouldn=92t be all that difficult.


So, I apologize for the confusion.= =A0 I didn't mean that RAs need
to go away; I simply meant we need a= way for the hosts to
ignore the default router information f= rom the RA, and instead
to obtain that from DHCPv6.=A0 Essentially, having the RA only
pass the "go ask DHCPv6" option bits to the hosts, and
every= thing else gets superseded by what the DHCPv6
server sends to the host.<= br>

I don't = see a mechanism for not treating a router announcing RAs as a candidate def= ault route is likely to succeed. I think it would require modifications to = host stacks that could not be backward compatible with existing implementat= ions.

I'm all for adding RIO equivalence in DHCPv6, thoug= h I think it is significantly less useful than advocated.


=A0
Eliminating RAs from the process would requ= ire a major change that would likely pose some level of compatibility probl= em with existing deployments.

Owen

=

Sorry; it's not really eliminating the RAs from the process as much as saying "ignore what the RA is sending you, other than the
option= bits telling you to go ask the DHCPv6 server for your info,
and use what the DHCPv6 server gives you, including y= our
default route information."
=

I can certainly see ways to suggest= that DHCPv6 route information, if presented, should supersede any route in= formation learned via RA. I don't see ignoring the RA information compl= etely.

Sure, supersede vs ignore is fine; m= ain point being
the DHCPv6 server knows better what that group of
hos= ts should be using than the router does, so the
host should use what the= DHCPv6 server sends it,
not the RA message from the router.
=A0


I hope that's a bit clearer; sorry to not have been clearer
ea= rlier.

Much clearer. I hav= e to ask... Do you have a running network where this actually is still in u= se? I've seen a few environments like this, but most of them were depre= cated years ago due to various problems that they create in IPv4.

Owen


Virtualization is actually increasing the number of deplo= yments
in that mode, rather than decreasing them.=

Matt


--001a1134a8669a9e9804ef814a95-- From mpetach@gmail.com Wed Jan 8 19:40:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08A01AE0B1 for ; Wed, 8 Jan 2014 19:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kC8M6N9EPXUa for ; Wed, 8 Jan 2014 19:40:44 -0800 (PST) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 493711AE0A2 for ; Wed, 8 Jan 2014 19:40:44 -0800 (PST) Received: by mail-pd0-f182.google.com with SMTP id v10so2605576pde.41 for ; Wed, 08 Jan 2014 19:40:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=nPwWbXQP2kdbiNZcYvlrv/WqAf1rXeIVrFqA8YymsT0=; b=MegpLLmBrASphnxKZeXBgdzzJBfF3It/ceX5HFJO6PTvaEDJTEJ9b+YBGleNuWdpja 5RbdXsKsHwY/URljIm+D2Fip9BLXPbn+NfBcIWTFVsp7+7rOXbUXze5RIthkMnKBhjo8 q/bTlJH0MtrA76MBrZ9FFm1fn1A7zRomQ7WEGHbDXO6V41TZ/QYdl6G8TYQHZAGX44Tl 2WXhPpk6xLMIRWr+vV2nVnY0pMbAOrNqU/WBlK1hd9xBkYaQtrt71nT8AqfkRNvoMGNK 7PDelLLV9KsU3HL50bgikVvlboQXNQhRZhKZ8yXFZrLVj9RbxP87ptYkOWBIP9RYDUVq v02A== MIME-Version: 1.0 X-Received: by 10.66.163.164 with SMTP id yj4mr873655pab.91.1389238835059; Wed, 08 Jan 2014 19:40:35 -0800 (PST) Sender: mpetach@gmail.com Received: by 10.70.1.130 with HTTP; Wed, 8 Jan 2014 19:40:34 -0800 (PST) In-Reply-To: <20140109032919.77E84C97CF5@rock.dv.isc.org> References: <20140109032919.77E84C97CF5@rock.dv.isc.org> Date: Wed, 8 Jan 2014 19:40:34 -0800 X-Google-Sender-Auth: _eeYi7wJO87rAsZilXhdyqQJNDk Message-ID: From: Matthew Petach To: Mark Andrews Content-Type: multipart/alternative; boundary=047d7b86ec5e45a25104ef815fa1 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 03:40:46 -0000 --047d7b86ec5e45a25104ef815fa1 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 8, 2014 at 7:29 PM, Mark Andrews wrote: > > In message 263jFp+BLpF3H6PuS8+Fd6qinMT3g@mail.gmail.com> > , Matthew Petach writes: > > > > If you want all the nodes to not use the RA to set a default route > then set Router Lifetime to zero. > > Router Lifetime > 16-bit unsigned integer. The lifetime associated > with the default router in units of seconds. The > field can contain values up to 65535 and receivers > should handle any value, while the sending rules in > Section 6 limit the lifetime to 9000 seconds. A > Lifetime of 0 indicates that the router is not a > default router and SHOULD NOT appear on the default > router list. The Router Lifetime applies only to > the router's usefulness as a default router; it > does not apply to information contained in other > message fields or options. Options that need time > limits for their information include their own > lifetime fields. > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > OMG. Yes! That's perfect! So, I need to change to set the M and O bits, set lifetime to 0, and then send the default route info via DHCPv6 and I should be golden! You're a lifesaver, thank you! Matt --047d7b86ec5e45a25104ef815fa1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jan 8, 2014 at 7:29 PM, Mark Andrews <= marka@isc.org> wrote:

In message <CAEmG1=3DrRYwJaZp3qYF47=3D263jFp+BLpF3H6PuS8+Fd6qinMT3g@mail.gmail.= com>
, Matthew Petach writes:
>

If you want all the nodes to not use the RA to set a default ro= ute
then set Router Lifetime to zero.

=A0 =A0 =A0 Router Lifetime
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A016-bit unsigned integer. =A0The = lifetime associated
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0with the default router in units= of seconds. =A0The
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0field can contain values up to 6= 5535 and receivers
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0should handle any value, while t= he sending rules in
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Section 6 limit the lifetime to = 9000 seconds. =A0A
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Lifetime of 0 indicates that the= router is not a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0default router and SHOULD NOT ap= pear on the default
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0router list. =A0The Router Lifet= ime applies only to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the router's usefulness as a= default router; it
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0does not apply to information co= ntained in other
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0message fields or options. =A0Op= tions that need time
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0limits for their information inc= lude their own
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0lifetime fields.


--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2= 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@isc.org



O= MG.=A0 Yes!=A0 That's perfect!=A0 So, I need to change to
set the M and O bits, set lifetime to 0, and then send the default route info via DHCPv6 and I should
be golden!=A0 You're a lifesaver, thank you!

Matt
--047d7b86ec5e45a25104ef815fa1-- From leo.liubing@huawei.com Wed Jan 8 19:51:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADD51AE122 for ; Wed, 8 Jan 2014 19:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfrLPFHgXslJ for ; Wed, 8 Jan 2014 19:51:25 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 30FCC1AE11E for ; Wed, 8 Jan 2014 19:51:24 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZT52730; Thu, 09 Jan 2014 03:51:14 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 9 Jan 2014 03:50:47 +0000 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 9 Jan 2014 03:51:12 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.72]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Thu, 9 Jan 2014 11:51:05 +0800 From: "Liubing (Leo)" To: Lorenzo Colitti Thread-Topic: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance Thread-Index: AQHPDEAXxSskx4jQs0+XEKzlvRgebpp6zyGggAA+8ACAAKxRcA== Date: Thu, 9 Jan 2014 03:51:04 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D829778@nkgeml506-mbx.china.huawei.com> References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D829778nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 03:51:28 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D829778nkgeml506mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9yZW56bywNCg0KRnJvbTogTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29n bGUuY29tXQ0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgMDksIDIwMTQgOTowMiBBTQ0KVG86IExp dWJpbmcgKExlbykNCkNjOiB2Nm9wc0BpZXRmLm9yZzsgZHJhZnQtbGl1LXY2b3BzLWRoY3B2Ni1z bGFhYy1ndWlkYW5jZUB0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUmU6IFt2Nm9wc10gREhDUHY2 L1NMQUFDIEludGVyYWN0aW9uIE9wZXJhdGlvbmFsIEd1aWRhbmNlLS8vUkU6IG5ldyBkcmFmdDog ZHJhZnQtbGl1LXY2b3BzLWRoY3B2Ni1zbGFhYy1ndWlkYW5jZQ0KDQpPbiBXZWQsIEphbiA4LCAy MDE0IGF0IDEwOjM5IFBNLCBMaXViaW5nIChMZW8pIDxsZW8ubGl1YmluZ0BodWF3ZWkuY29tPG1h aWx0bzpsZW8ubGl1YmluZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQpDYW4geW91IHJlbW92ZSBpdCwg dGhlbj8gQXMgYW4gb3BlcmF0aW9uYWwgZ3JvdXAgd2UgZG9uJ3Qgd2FudCB0byBwcm92aWRlIGd1 aWRhbmNlIG9uIGludmFsaWQgdXNlIGNhc2VzLiA6LSkNCltCaW5nXSBJIGFncmVlIHdpdGggeW91 IHRoYXQg4oCcREhDUHY2LW9ubHkgd2l0aG91dCBSQeKAnSBzaG91bGQgbm90IGJlIGlkZW50aWZp ZWQgYXMgYSB2YWxpZCB1c2UgY2FzZS4gQnV0IGluIHRoZSBkb2N1bWVudCwgd2hhdCB3ZSB3YW50 IHRvIGNhdXRpb24gdGhlIHJlYWRlciBpcyB0aGF0IHNvbWUgb3BlcmF0aW5nIHN5c3RlbXMgd291 bGQgcmVseSBSQXMgdG8gdHJpZ2dlciBESENQdjYuIEkgdGhpbmsg4oCcUkFzIGFyZSBuZWNlc3Nh cnkgZm9yIElQdjYgY29uZmlndXJhdGlvbuKAnSAgYW5kIOKAnFJBcyBhcmUgbmVjZXNzYXJ5IHRv IHRyaWdnZXIgREhDUHY24oCdIGFyZSB0d28gZGlmZmVyZW50IHRoaW5ncyBpbiBjb25jZXB0LiBX ZSBqdXN0IHdhbnQgdG8gZW1waGFzaXplIHRoZSBsYXR0ZXIgb25lLiBNYXliZSBpdCBpcyBhIGxp dHRsZSByZWR1bmRhbnQgaW4gd29yZGluZywgYnV0IGF0IGxlYXN0IGl0IGlzIG5vdCBoYXJtZnVs PyBFc3BlY2lhbGx5IGNvbnNpZGVyaW5nIHRoYXQgaW4gcmVhbCBwcmFjdGljZSwgYWRtaW5zIGNv dWxkIGVuYWJsZSByb3V0aW5nIGNvbmZpZ3VyYXRpb24gaW4gREhDUHY2IGJ5IHByaXZhdGUvY3Vz dG9taXplZCBleHRlbnNpb24gKElTQyBkaGNwZCAmIGRpYmJsZXIgYm90aCBwcm92aWRlIHRoZSBj YXBhYmlsaXR5KSAuIEkgdGhpbmsgbWF5YmUgdGhlIHJlZHVuZGFuY3kgd29yZGluZyBjb3VsZCBi ZSB1c2VmdWwgZm9yIHRoZSBzaXR1YXRpb25zLg0KDQpPaywgc28gaWYgdGhhdCdzIHdoYXQgeW91 IHdhbnQgdG8gc2F5LCBob3cgYWJvdXQgcmVwbGFjaW5nIHNlY3Rpb24gMy4yIHdpdGggc29tZXRo aW5nIGxpa2UgdGhpczoNCg0KPT09DQoNCjMuMi4gR3VpZGFuY2UgZm9yIERIQ1B2Ni1vbmx5IERl cGxveW1lbnQNCg0KU29tZSBuZXR3b3JrcyBwcmVmZXIgY2VudHJhbCBtYW5hZ2VtZW50IG9mIGFs bCBJUCBhZGRyZXNzaW5nLiBUaGVzZSBuZXR3b3JrcyBtYXkgd2FudCB0byBhc3NpZ24gYWRkcmVz c2VzIG9ubHkgdmlhIERIQ1B2Ni4NCg0KVGhpcyBjYW4gYmUgYWNjb21wbGlzaGVkIGJ5IHNlbmRp bmcgYW4gUkEgdGhhdCBpbmRpY2F0ZXMgdGhhdCBESENQdjYgYWRkcmVzcyBhc3NpZ25tZW50IGlz IGF2YWlsYWJsZSAoaS5lLiwgTT0xKSwgaW5zdGFsbGluZyBESENQdjYgc2VydmVycyBvciBESENQ djYgcmVsYXlzIG9uIGFsbCBsaW5rcywgYW5kIHNldHRpbmcgQT0wIGluIHRoZSBQcmVmaXggSW5m b3JtYXRpb24gT3B0aW9ucyBvZiBhbGwgcHJlZml4ZXMgaW4gdGhlIFJBLg0KDQpOb3RlIHRoYXQg YW4gUkEgaXMgc3RpbGwgbmVjZXNzYXJ5IGluIG9yZGVyIGZvciBob3N0cyB0byBiZSBhYmxlIHRv IHVzZSB0aGVzZSBhZGRyZXNzZXMuIFRoaXMgaXMgZm9yIHR3byByZWFzb25zOg0KDQogIDEuICBQ ZXIgcHJvYmxlbSAjMSwgaWYgdGhlcmUgaXMgbm8gUkEsIHNvbWUgaG9zdHMgd2lsbCBub3QgYXR0 ZW1wdCB0byBvYnRhaW4gYWRkcmVzcyBjb25maWd1cmF0aW9uIHZpYSBESENQdjYgYXQgYWxsLg0K ICAyLiAgSWYgdGhlcmUgaXMgbm8gUkEsIG9yIGlmIHRoZSBSQSBkb2VzIG5vdCBpbmNsdWRlIGEg UHJlZml4IEluZm9ybWF0aW9uIE9wdGlvbiBjb3ZlcmluZyB0aGUgYWRkcmVzc2VzIGFzc2lnbmVk IHZpYSBESENQdjYsIHRoZW4gdGhvc2UgYWRkcmVzc2VzIGNhbm5vdCBiZSB1c2VkIGZvciBhbnkg Y29tbXVuaWNhdGlvbiwgZXZlbiBvbi1saW5rIGNvbW11bmljYXRpb24uIFRoaXMgaXMgYmVjYXVz ZSBESENQdjYgZG9lcyBub3QgcHJvdmlkZSBhIHdheSB0byBjb25maWd1cmUgcm91dGluZywgYW5k IHVubGVzcyByb3V0aW5nIGlzIGNvbmZpZ3VyZWQgYnkgc29tZSBvdGhlciBtZWFucywgaG9zdHMg d2lsbCBjb25zaWRlciBhbGwgZGVzdGluYXRpb25zIHRvIGJlIHVucmVhY2hhYmxlIFtSRkM0OTQz XS4gVGh1cywgdXNpbmcgREhDUHY2IHdpdGhvdXQgYW4gUkEgZG9lcyBub3QgY3VycmVudGx5IHBy b3ZpZGUgYW55IGZ1bmN0aW9uYWxpdHkuDQpbQmluZ10gSSB0aGluayB0aGlzIGlzIGEgZ29vZCB3 YXkgdG8gY2xhcmlmeSB0aGUgcHJvYmxlbS4gVGhhbmtzIG11Y2ggZm9yIGNvbnRyaWJ1dGluZyB0 aGUgdGV4dHMsIHdl4oCZbGwgY29uc2lkZXIgdG8gaW5jb3Jwb3JhdGUgdGhlbSBpbnRvIHRoZSBu ZXh0IHZlcnNpb24uDQpBbHNvIG5vdGUgdGhhdCB1bmxpa2UgU0xBQUMsIERIQ1B2NiBpcyBub3Qg YSBzdHJpY3QgcmVxdWlyZW1lbnQgZm9yIElQdjYgaG9zdHMgW1JGQzY0MzRdLCBhbmQgc29tZSBu b2RlcyBkbyBub3Qgc3VwcG9ydCBESENQdjYuIFRodXMsIHRoaXMgbW9kZWwgY2FuIG9ubHkgYmUg dXNlZCBpZiBhbGwgdGhlIGhvc3RzIHRoYXQgbmVlZCBJUHY2IGNvbm5lY3Rpdml0eSBzdXBwb3J0 IERIQ1B2Ni4NCg0KDQpQZXIgcHJvYmxlbSAjMiwgaWYgdGhlIGFkbWluaXN0cmF0b3JzIHdhbnQg dG8gc3dpdGNoIHRoZSBESENQdjYtb25seSBjb25maWd1cmVkIGhvc3RzIHRvIFNMQUFDLW9ubHks IHRoaXMgaXMgbm90IHBvc3NpYmxlIG9uIHNvbWUgaG9zdHMgd2l0aG91dCBtYW51YWxseSBjaGFu Z2luZyB0aGUgaG9zdHMnIGNvbmZpZ3VyYXRpb24gb3IgdXNpbmcgYWRkaXRpb25hbCBtYW5hZ2Vt ZW50IHRvb2xzLg0KDQpQZXIgcHJvYmxlbSAjNCwgZm9yIHNvbWUgcGxhdGZvcm1zLCB0aGUgQSBm bGFnIGFuZCBPIGZsYWcgbWlnaHQgbm90IGJlIGluZGVwZW5kZW50LCB3aGVuIFNMQUFDIGlzIG9m ZiwgYSBzdGFuZC1hbG9uZSBzdGF0ZWxlc3MgREhDUHY2IHNlc3Npb24gd291bGQgbm90IGJlIGFw cGxpY2FibGUuIEhvd2V2ZXIsIHRoaXMgbWlnaHQgbm90IGJlIGEgY29tbW9uIHVzZSBjYXNlLg0K DQo9PT0NCg0KKE5vdGU6IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IHlvdSBtZWFudCBieSB0aGUg bGFzdCBwYXJhZ3JhcGggYWJvdXQgcHJvYmxlbSAjNCwgc28gSSBqdXN0IHJlcGVhdGVkIGl0IGFz IGlzIGluIHRoZSBzdWdnZXN0aW9uIGFib3ZlLiBCdXQgaXQgc2hvdWxkIGJlIGNsYXJpZmllZCkN CltCaW5nXSBQcm9ibGVtICM0IGluZGljYXRlcyBzb21lIGltcGxpY2l0IHJlbGF0aW9uc2hpcCBi ZXR3ZWVuIHRoZSBmbGFncy4gRm9yIGV4YW1wbGUsIHdoZW4gQT0wLCBNPTAsIE89MSwgc29tZSBv cGVyYXRpbmcgc3lzdGVtcyB3b3VsZCBzdGFydCBhIHN0YW5kLWFsb25lIHN0YXRlbGVzcyBESENQ djYgc2Vzc2lvbiwgYnV0IHNvbWUganVzdCB3b3VsZCBub3QuIEZvciB0aG9zZSB3aG8gd291bGQg bm90LCBpdCBpcyBqdXN0IGFuIGltcGxpY2F0aW9uIHRoYXQgd2hlbiBBIGlzIG9mZiwgdGhlIHN0 YW5kLWFsb25lIHN0YXRlbGVzcyBESENQdjYgaXMgYWxzbyBvZmYuIFRoaXMgaXMgdGhlIHByb2Js ZW0gIzQg4oCcRGVwZW5kZW5jaWVzIGJldHdlZW4gZmxhZ3PigJ0uDQpXZSBuZWVkIHRvIG1ha2Ug aXQgY2xlYXJlciBpbiB0aGUgbmV4dCB2ZXJzaW9uLg0KDQpCZXN0IFJlZ2FyZHMsDQpCaW5nDQoN CkNoZWVycywNCkxvcmVuem8NCg== --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D829778nkgeml506mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcy LjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQov KiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNTUxNzcwOTc5 Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczozNjI1NzMxMDQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRv bTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgTG9yZW56byw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0K PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKYW51YXJ5IDA5LCAyMDE0IDk6MDIgQU08YnI+ DQo8Yj5Ubzo8L2I+IExpdWJpbmcgKExlbyk8YnI+DQo8Yj5DYzo8L2I+IHY2b3BzQGlldGYub3Jn OyBkcmFmdC1saXUtdjZvcHMtZGhjcHY2LXNsYWFjLWd1aWRhbmNlQHRvb2xzLmlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIERIQ1B2Ni9TTEFBQyBJbnRlcmFjdGlvbiBP cGVyYXRpb25hbCBHdWlkYW5jZS0vL1JFOiBuZXcgZHJhZnQ6IGRyYWZ0LWxpdS12Nm9wcy1kaGNw djYtc2xhYWMtZ3VpZGFuY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5PbiBXZWQsIEphbiA4LCAyMDE0IGF0IDEwOjM5IFBNLCBMaXViaW5n IChMZW8pICZsdDs8YSBocmVmPSJtYWlsdG86bGVvLmxpdWJpbmdAaHVhd2VpLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmxlby5saXViaW5nQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiM1MDAwNTAiPkNhbiB5b3UgcmVtb3ZlIGl0LCB0 aGVuPyBBcyBhbiBvcGVyYXRpb25hbCBncm91cCB3ZSBkb24ndCB3YW50IHRvIHByb3ZpZGUgZ3Vp ZGFuY2Ugb24gaW52YWxpZCB1c2UgY2FzZXMuIDotKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPltCaW5nXSBJIGFncmVlIHdpdGggeW91IHRoYXQg4oCcREhDUHY2 LW9ubHkgd2l0aG91dCBSQeKAnSBzaG91bGQgbm90IGJlIGlkZW50aWZpZWQgYXMgYQ0KIHZhbGlk IHVzZSBjYXNlLiBCdXQgaW4gdGhlIGRvY3VtZW50LCB3aGF0IHdlIHdhbnQgdG8gY2F1dGlvbiB0 aGUgcmVhZGVyIGlzIHRoYXQgc29tZSBvcGVyYXRpbmcgc3lzdGVtcyB3b3VsZCByZWx5IFJBcyB0 byB0cmlnZ2VyIERIQ1B2Ni4gSSB0aGluayDigJxSQXMgYXJlIG5lY2Vzc2FyeSBmb3IgSVB2NiBj b25maWd1cmF0aW9u4oCdICZuYnNwO2FuZCDigJxSQXMgYXJlIG5lY2Vzc2FyeSB0byB0cmlnZ2Vy IERIQ1B2NuKAnSBhcmUgdHdvIGRpZmZlcmVudCB0aGluZ3MNCiBpbiBjb25jZXB0LiBXZSBqdXN0 IHdhbnQgdG8gZW1waGFzaXplIHRoZSBsYXR0ZXIgb25lLiBNYXliZSBpdCBpcyBhIGxpdHRsZSBy ZWR1bmRhbnQgaW4gd29yZGluZywgYnV0IGF0IGxlYXN0IGl0IGlzIG5vdCBoYXJtZnVsPyBFc3Bl Y2lhbGx5IGNvbnNpZGVyaW5nIHRoYXQgaW4gcmVhbCBwcmFjdGljZSwgYWRtaW5zIGNvdWxkIGVu YWJsZSByb3V0aW5nIGNvbmZpZ3VyYXRpb24gaW4gREhDUHY2IGJ5IHByaXZhdGUvY3VzdG9taXpl ZCBleHRlbnNpb24NCiAoSVNDIGRoY3BkICZhbXA7IGRpYmJsZXIgYm90aCBwcm92aWRlIHRoZSBj YXBhYmlsaXR5KSAuIEkgdGhpbmsgbWF5YmUgdGhlIHJlZHVuZGFuY3kgd29yZGluZyBjb3VsZCBi ZSB1c2VmdWwgZm9yIHRoZSBzaXR1YXRpb25zLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9rLCBzbyBpZiB0aGF0J3Mgd2hhdCB5b3Ugd2FudCB0byBz YXksIGhvdyBhYm91dCByZXBsYWNpbmcgc2VjdGlvbiAzLjIgd2l0aCBzb21ldGhpbmcgbGlrZSB0 aGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PT09 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ My4yLiBHdWlkYW5jZSBmb3IgREhDUHY2LW9ubHkgRGVwbG95bWVudDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Tb21lIG5ldHdvcmtzIHBy ZWZlciBjZW50cmFsIG1hbmFnZW1lbnQgb2YgYWxsIElQIGFkZHJlc3NpbmcuIFRoZXNlIG5ldHdv cmtzIG1heSB3YW50IHRvIGFzc2lnbiBhZGRyZXNzZXMgb25seSB2aWEgREhDUHY2LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhpcyBjYW4gYmUgYWNj b21wbGlzaGVkIGJ5IHNlbmRpbmcgYW4gUkEgdGhhdCBpbmRpY2F0ZXMgdGhhdCBESENQdjYgYWRk cmVzcyBhc3NpZ25tZW50IGlzIGF2YWlsYWJsZSAoaS5lLiwgTT0xKSwgaW5zdGFsbGluZyBESENQ djYgc2VydmVycyBvciBESENQdjYgcmVsYXlzIG9uIGFsbCBsaW5rcywgYW5kIHNldHRpbmcgQT0w IGluIHRoZSBQcmVmaXggSW5mb3JtYXRpb24gT3B0aW9ucw0KIG9mIGFsbCBwcmVmaXhlcyBpbiB0 aGUgUkEuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5O b3RlIHRoYXQgYW4gUkEgaXMgc3RpbGwgbmVjZXNzYXJ5IGluIG9yZGVyIGZvciBob3N0cyB0byBi ZSBhYmxlIHRvIHVzZSB0aGVzZSBhZGRyZXNzZXMuIFRoaXMgaXMgZm9yIHR3byByZWFzb25zOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxvbCBzdGFydD0iMSIgdHlwZT0i MSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxz cGFuIGxhbmc9IkVOLVVTIj5QZXIgcHJvYmxlbSAjMSwgaWYgdGhlcmUgaXMgbm8gUkEsIHNvbWUg aG9zdHMgd2lsbCBub3QgYXR0ZW1wdCB0byBvYnRhaW4gYWRkcmVzcyBjb25maWd1cmF0aW9uIHZp YSBESENQdjYgYXQgYWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+SWYgdGhl cmUgaXMgbm8gUkEsIG9yIGlmIHRoZSBSQSBkb2VzIG5vdCBpbmNsdWRlIGEgUHJlZml4IEluZm9y bWF0aW9uIE9wdGlvbiBjb3ZlcmluZyB0aGUgYWRkcmVzc2VzIGFzc2lnbmVkIHZpYSBESENQdjYs IHRoZW4gdGhvc2UgYWRkcmVzc2VzIGNhbm5vdCBiZSB1c2VkIGZvciBhbnkgY29tbXVuaWNhdGlv biwgZXZlbiBvbi1saW5rIGNvbW11bmljYXRpb24uIFRoaXMgaXMgYmVjYXVzZSBESENQdjYgZG9l cyBub3QNCiBwcm92aWRlIGEgd2F5IHRvIGNvbmZpZ3VyZSByb3V0aW5nLCBhbmQgdW5sZXNzIHJv dXRpbmcgaXMgY29uZmlndXJlZCBieSBzb21lIG90aGVyIG1lYW5zLCBob3N0cyB3aWxsIGNvbnNp ZGVyIGFsbCBkZXN0aW5hdGlvbnMgdG8gYmUgdW5yZWFjaGFibGUgW1JGQzQ5NDNdLiBUaHVzLCB1 c2luZyBESENQdjYgd2l0aG91dCBhbiBSQSBkb2VzIG5vdCBjdXJyZW50bHkgcHJvdmlkZSBhbnkg ZnVuY3Rpb25hbGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+W0JpbmddIEkgdGhpbmsgdGhpcyBpcyBhIGdvb2Qgd2F5IHRvIGNsYXJpZnkgdGhl IHByb2JsZW0uIFRoYW5rcyBtdWNoIGZvciBjb250cmlidXRpbmcNCiB0aGUgdGV4dHMsIHdl4oCZ bGwgY29uc2lkZXIgdG8gaW5jb3Jwb3JhdGUgdGhlbSBpbnRvIHRoZSBuZXh0IHZlcnNpb24uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkFsc28gbm90ZSB0aGF0IHVubGlrZSBTTEFBQywgREhDUHY2IGlz IG5vdCBhIHN0cmljdCByZXF1aXJlbWVudCBmb3IgSVB2NiBob3N0cyBbUkZDNjQzNF0sIGFuZCBz b21lIG5vZGVzIGRvIG5vdCBzdXBwb3J0IERIQ1B2Ni4gVGh1cywgdGhpcyBtb2RlbCBjYW4gb25s eSBiZSB1c2VkIGlmIGFsbCB0aGUgaG9zdHMgdGhhdCBuZWVkIElQdjYgY29ubmVjdGl2aXR5IHN1 cHBvcnQgREhDUHY2LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+UGVyIHByb2JsZW0gIzIsIGlmIHRoZSBhZG1pbmlzdHJhdG9ycyB3YW50IHRvIHN3aXRj aCB0aGUgREhDUHY2LW9ubHkgY29uZmlndXJlZCBob3N0cyB0byBTTEFBQy1vbmx5LCB0aGlzIGlz IG5vdCBwb3NzaWJsZSBvbiBzb21lIGhvc3RzIHdpdGhvdXQgbWFudWFsbHkgY2hhbmdpbmcgdGhl IGhvc3RzJyBjb25maWd1cmF0aW9uIG9yIHVzaW5nIGFkZGl0aW9uYWwgbWFuYWdlbWVudA0KIHRv b2xzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UGVy IHByb2JsZW0gIzQsIGZvciBzb21lIHBsYXRmb3JtcywgdGhlIEEgZmxhZyBhbmQgTyBmbGFnIG1p Z2h0IG5vdCBiZSBpbmRlcGVuZGVudCwgd2hlbiBTTEFBQyBpcyBvZmYsIGEgc3RhbmQtYWxvbmUg c3RhdGVsZXNzIERIQ1B2NiBzZXNzaW9uIHdvdWxkIG5vdCBiZSBhcHBsaWNhYmxlLiBIb3dldmVy LCB0aGlzIG1pZ2h0IG5vdCBiZSBhIGNvbW1vbiB1c2UgY2FzZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PT09PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4oTm90ZTogSSBkb24ndCB1bmRlcnN0 YW5kIHdoYXQgeW91IG1lYW50IGJ5IHRoZSBsYXN0IHBhcmFncmFwaCBhYm91dCBwcm9ibGVtICM0 LCBzbyBJIGp1c3QgcmVwZWF0ZWQgaXQgYXMgaXMgaW4gdGhlIHN1Z2dlc3Rpb24gYWJvdmUuIEJ1 dCBpdCBzaG91bGQgYmUgY2xhcmlmaWVkKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0JpbmddIFByb2JsZW0gIzQgaW5kaWNhdGVzIHNv bWUgaW1wbGljaXQgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIGZsYWdzLiBGb3IgZXhhbXBsZSwg d2hlbiBBPTAsIE09MCwgTz0xLCBzb21lIG9wZXJhdGluZyBzeXN0ZW1zIHdvdWxkIHN0YXJ0IGEN CiBzdGFuZC1hbG9uZSBzdGF0ZWxlc3MgREhDUHY2IHNlc3Npb24sIGJ1dCBzb21lIGp1c3Qgd291 bGQgbm90LiBGb3IgdGhvc2Ugd2hvIHdvdWxkIG5vdCwgaXQgaXMganVzdCBhbiBpbXBsaWNhdGlv biB0aGF0IHdoZW4gQSBpcyBvZmYsIHRoZSBzdGFuZC1hbG9uZSBzdGF0ZWxlc3MgREhDUHY2IGlz IGFsc28gb2ZmLiBUaGlzIGlzIHRoZSBwcm9ibGVtICM0IOKAnERlcGVuZGVuY2llcyBiZXR3ZWVu IGZsYWdz4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2Ug bmVlZCB0byBtYWtlIGl0IGNsZWFyZXIgaW4gdGhlIG5leHQgdmVyc2lvbi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNoZWVycyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+TG9yZW56bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D829778nkgeml506mbxchi_-- From owen@delong.com Wed Jan 8 20:02:36 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D6D1AE14A for ; Wed, 8 Jan 2014 20:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsG80mbTP5cr for ; Wed, 8 Jan 2014 20:02:33 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 77A521AE123 for ; Wed, 8 Jan 2014 20:02:32 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s093w74b024900 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 8 Jan 2014 19:58:07 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s093w74b024900 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1389239887; bh=p5Iwo0Am+UREUMRheNh2WNDogN8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=SAkFn1SMHtppiUuBLJskrcgQIcmFT9E07kAA0sYoMI4yk+6qFgc76N9D4olL8UB9U rWIX0+xt+ztGWVAWEgZ0fiK3DPq1xk/bFmJfKYmt2BDcF0bXYozTK3dCo057af+WQX XRkqhMJKDlSA/UL5gbcr9hkkYbRdIQDRm9vyys/c= Content-Type: multipart/alternative; boundary="Apple-Mail=_57D3F96A-7370-44F9-BF65-0A7CD43849D0" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Owen DeLong In-Reply-To: Date: Wed, 8 Jan 2014 19:58:05 -0800 Message-Id: <1F806192-0F02-4DED-BF27-A9DB753CF621@delong.com> References: <24CFBACC-7994-47D2-AAC5-F4CCAB4B29D8@delong.com> To: Matthew Petach X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 08 Jan 2014 19:58:07 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 04:02:37 -0000 --Apple-Mail=_57D3F96A-7370-44F9-BF65-0A7CD43849D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jan 8, 2014, at 19:34 , Matthew Petach wrote: >=20 >=20 >=20 > On Wed, Jan 8, 2014 at 7:17 PM, Owen DeLong wrote: >=20 > On Jan 8, 2014, at 18:56 , Matthew Petach = wrote: >=20 >>=20 >>=20 >> I'm sorry, it's been a really busy week, so I'm a bit behind in >> following up to the people who have asked for further clarification. >>=20 >> Here's the slightly more detailed description of the situation: >>=20 >> 4 groups of hosts on the subnet; >> groupA, groupB, groupC, groupD; >> four different policies on the DHCP server. >> subnet has 4 different upstream routers. >> groupA is handed IP address on routerA as default gateway >> groupB is handed IP address on routerB as default gateway >> groupC is handed IP address on routerC as default gateway >> groupD is handed IP address on routerD as default gateway >>=20 >> all four groups are within the same L2 broadcast domain, >> and have applications that make use of that same-subnet >> relationship. >=20 > Ignoring for the moment that this is an incredibly convoluted corner = case which is likely fragile, at best, in IPv4... >=20 >=20 > It's actually not that convoluted; it allows you to segment > your traffic flows across different upstream devices/interfaces > without having to forklift upgrade your network infrastructure > completely. defaultA is actually an HSRP address that is > master on routerA, backup on routerB; defaultB is master > on routerB, backup on routerC; defaultC is master on > routerC, backup on routerD; and defaultD is master > on routerD, backup on routerA. Each router takes > care of 25% of the host load for the network that way. > =20 Meh... There are better ways to achieve that, and, in that case, you = don't care so much that group A goes to router A, you care that the = traffic is semi-evenly divided between the routers. Having multiple RAs = with equal preference will come reasonably close to that automatically. > In IPv4, that makes sense. In IPv6, it does not. >=20 > In IPv6, you don't have broadcasts, it's all multicast. You can define = a multicast scope (ff04 perhaps?) that incorporates those 4 distinct = IPv6 subnets. >=20 > But it requires your router be configured to route > multicast traffic between subnets in order for that > to work, when in the v4 space, the traffic between > hosts doesn't require participation from the router > for host-to-host communication to function. So? >> In looking at DHCPv6 vs RAs, I don't see how to give the >> different groups of hosts the appropriate default router IP >> unless the default router is provided by the DHCP server. >=20 > That's because you haven't looked at the fact that in IPv6, these = don't need a shared broadcast domain to continue working the way you = describe. >=20 > It's somewhat awkward telling a group of users > "so, in v4, you're on the same subnet and can > communicate directly; but in v6, you're on > different subnets and can't communicate > directly". Yes, I suppose we could try to do=20 > do non-homologous topologies for v4 and > v6 for dual-stacked hosts, but troubleshooting > that kinda scares me a bit. :( It's not all that frightening, and, I agree that the cleaner solution is = to just deploy RAs and not worry about it. However, you stated that you specifically wanted group A using router A = rather than just dividing up the traffic. >> The routers don't have a way to target their respective >> RAs to just members of the appropriate group of hosts, >> and there doesn't seem to be an option to tell the hosts >> in groupA to only listen to RAs from routerA. >=20 > You could, but it would involve elaborate configuration on the = routers. It makes more sense to divide these groups of hosts into = separate IPv6 networks. >=20 > Would that mean having to go back and break > up the v4 topology to match what's best for v6, > or run a different topology for v6 and v4 on the > same hosts? I think you'd have to break up the L2 broadcast domain to make it work = correctly with RAs, but you might be able to get creative with switch = filters on which RAs are allowed to reach which hosts and leave them in = a single L2 broadcast domain. In the latter case, you could also use an = FF02:: multicast and reach all the hosts without crossing a router. = Seems like a huge pain to maintain, however. > It kinda sounds like the message is "v6 is a=20 > different beast, and to use it, you have to > redo your network, including your v4 topology, > to best match what v6 wants." More like "IPv6 is a different beast and if you've done truly strange = things to work around deficiencies in IPv4, then the clean solutions = available in IPv6 may be incompatible." Seems to me that for the purpose you have described, advertising RAs = from all 4 routers and letting the hosts each pick one would do the = trick in IPv6 without modifying your IPv4 topology. If you have other = reasons that you really want group A going out through router A, = however, then things get trickier and you've got that pesky "IPv4 hack = incompatible with IPv6 solution" problem. >> As to getting software to do it, that=92s not really the problem. The = problem is that there=92s already lots of deployed hardware and software = that is implemented as defined in the current RFCs. >>=20 >> It=92s the elimination of RAs that is problematic. Using DHCP = exclusively for address assignment isn=92t difficult. Adding routing = information to DHCPv6 wouldn=92t be all that difficult. >>=20 >>=20 >> So, I apologize for the confusion. I didn't mean that RAs need >> to go away; I simply meant we need a way for the hosts to >> ignore the default router information from the RA, and instead >> to obtain that from DHCPv6. Essentially, having the RA only >> pass the "go ask DHCPv6" option bits to the hosts, and >> everything else gets superseded by what the DHCPv6 >> server sends to the host. >=20 > I don't see a mechanism for not treating a router announcing RAs as a = candidate default route is likely to succeed. I think it would require = modifications to host stacks that could not be backward compatible with = existing implementations. Actually, I forgot about router lifetime=3D0... As Mark suggested, that = works now and is a readily available hack if you want to disable = learning IPv6 default routes by RA. >=20 > I'm all for adding RIO equivalence in DHCPv6, though I think it is = significantly less useful than advocated. >=20 >>=20 >> =20 >> Eliminating RAs from the process would require a major change that = would likely pose some level of compatibility problem with existing = deployments. >>=20 >> Owen >>=20 >>=20 >> Sorry; it's not really eliminating the RAs from the process as much >> as saying "ignore what the RA is sending you, other than the >> option bits telling you to go ask the DHCPv6 server for your info, >> and use what the DHCPv6 server gives you, including your >> default route information." >=20 > I can certainly see ways to suggest that DHCPv6 route information, if = presented, should supersede any route information learned via RA. I = don't see ignoring the RA information completely. >=20 > Sure, supersede vs ignore is fine; main point being > the DHCPv6 server knows better what that group of > hosts should be using than the router does, so the > host should use what the DHCPv6 server sends it, > not the RA message from the router. For some definitions of "knows" and some contexts of "better". >> I hope that's a bit clearer; sorry to not have been clearer >> earlier. >=20 > Much clearer. I have to ask... Do you have a running network where = this actually is still in use? I've seen a few environments like this, = but most of them were deprecated years ago due to various problems that = they create in IPv4. >=20 > Owen >=20 >=20 > Virtualization is actually increasing the number of deployments > in that mode, rather than decreasing them. Seems to me that there are much better ways to do what you describe for = virtualization, but that's getting into a bit of a digression from the = WG charter. Hopefully the information I have provided above can prove = useful in addressing your issues without requiring major protocol = surgery. Owen --Apple-Mail=_57D3F96A-7370-44F9-BF65-0A7CD43849D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jan 8, 2014, at 19:34 , Matthew = Petach <mpetach@netflight.com> = wrote:




On Wed, Jan 8, 2014 at 7:17 PM, Owen DeLong <owen@delong.com> wrote:

On = Jan 8, 2014, at 18:56 , Matthew Petach <mpetach@netflight.com> wrote:



I'm = sorry, it's been a really busy week, so I'm a bit behind in
following = up to the people who have asked for further clarification.

Here's the slightly more detailed description of the = situation:

4 groups of hosts on the = subnet;
groupA, groupB, groupC, groupD;
four different = policies on the DHCP server.
subnet has 4 different upstream routers.
groupA is handed = IP address on routerA as default gateway
groupB is handed IP address = on routerB as default gateway
groupC is handed IP address = on routerC as default gateway
groupD is handed IP address on routerD as default = gateway

all four groups are within the same L2 = broadcast domain,
and have applications that make use of that = same-subnet
relationship.
=

Ignor= ing for the moment that this is an incredibly convoluted corner case = which is likely fragile, at best, in = IPv4...


It's actually not that convoluted; it allows you to = segment
your traffic flows across different upstream = devices/interfaces
without having to forklift upgrade your network = infrastructure
completely.  defaultA is actually an HSRP address that is
master = on routerA, backup on routerB; defaultB is master
on routerB, backup = on routerC; defaultC is master on
routerC, backup on routerD; and = defaultD is master
on routerD, backup on routerA.  Each router = takes
care of 25% of the host load for the network that = way.
 

Meh.= .. There are better ways to achieve that, and, in that case, you don't = care so much that group A goes to router A, you care that the traffic is = semi-evenly divided between the routers. Having multiple RAs with equal = preference will come reasonably close to that = automatically.


In IPv4, that makes = sense. In IPv6, it does not.

In IPv6, you don't = have broadcasts, it's all multicast. You can define a multicast scope = (ff04 perhaps?) that incorporates those 4 distinct IPv6 subnets.

But it requires your router be = configured to route
multicast traffic between subnets in order for = that
to work, when in the v4 space, the traffic between
hosts = doesn't require participation from the router
for host-to-host communication to = function.

So?
=

In looking at = DHCPv6 vs RAs, I don't see how to give the
different groups of = hosts the appropriate default router IP
unless the default router is provided by the DHCP = server.

That'= s because you haven't looked at the fact that in IPv6, these don't need = a shared broadcast domain to continue working the way you = describe.

It's somewhat awkward telling a = group of users
"so, in v4, you're on the same subnet and = can
communicate directly; but in v6, you're on
different subnets = and can't communicate
directly".  Yes, I suppose we could try to do
do non-homologous = topologies for v4 and
v6 for dual-stacked hosts, but = troubleshooting
that kinda scares me a bit.  = :(

It's not all = that frightening, and, I agree that the cleaner solution is to just = deploy RAs and not worry about it.

However, you = stated that you specifically wanted group A using router A rather than = just dividing up the traffic.

The routers don't = have a way to target their respective
RAs to just members of the = appropriate group of hosts,
and there doesn't seem to be = an option to tell the hosts
in groupA to only listen to RAs from = routerA.

You could, but = it would involve elaborate configuration on the routers. It makes more = sense to divide these groups of hosts into separate IPv6 networks.

Would that mean having to go back and = break
up the v4 topology to match what's best for v6,
or run a = different topology for v6 and v4 on the
same = hosts?

I think = you'd have to break up the L2 broadcast domain to make it work correctly = with RAs, but you might be able to get creative with switch filters on = which RAs are allowed to reach which hosts and leave them in a single L2 = broadcast domain. In the latter case, you could also use an FF02:: = multicast and reach all the hosts without crossing a router. Seems like = a huge pain to maintain, however.

It kinda sounds like the message is "v6 is = a 
different beast, and to use it, you have to
redo your network, = including your v4 topology,
to best match what v6 = wants."

More like = "IPv6 is a different beast and if you've done truly strange things to = work around deficiencies in IPv4, then the clean solutions available in = IPv6 may be incompatible."

Seems to me that for = the purpose you have described, advertising RAs from all 4 routers and = letting the hosts each pick one would do the trick in IPv6 without = modifying your IPv4 topology. If you have other reasons that you really = want group A going out through router A, however, then things get = trickier and you've got that pesky "IPv4 hack incompatible with IPv6 = solution" problem.

As to getting software = to do it, that=92s not really the problem. The problem is that there=92s = already lots of deployed hardware and software that is implemented as = defined in the current RFCs.

It=92s the elimination of RAs that is problematic. = Using DHCP exclusively for address assignment isn=92t difficult. Adding = routing information to DHCPv6 wouldn=92t be all that = difficult.


So, I apologize for the = confusion.  I didn't mean that RAs need
to go away; I simply = meant we need a way for the hosts to
ignore the default = router information from the RA, and instead
to obtain that from DHCPv6.  Essentially, having the RA = only
pass the "go ask DHCPv6" option bits to the hosts, = and
everything else gets superseded by what the DHCPv6
server = sends to the host.

I don't = see a mechanism for not treating a router announcing RAs as a candidate = default route is likely to succeed. I think it would require = modifications to host stacks that could not be backward compatible with = existing = implementations.

Actually, I forgot about router lifetime=3D0... As = Mark suggested, that works now and is a readily available hack if you = want to disable learning IPv6 default routes by = RA.


I'm all for adding RIO equivalence in DHCPv6, though = I think it is significantly less useful than advocated.


 
Eliminating RAs from the = process would require a major change that would likely pose some level = of compatibility problem with existing deployments.

Owen


Sorry; = it's not really eliminating the RAs from the process as much
as saying "ignore what the RA is sending you, other than the
option = bits telling you to go ask the DHCPv6 server for your = info,
and use what the DHCPv6 server = gives you, including your
default route = information."

I can = certainly see ways to suggest that DHCPv6 route information, if = presented, should supersede any route information learned via RA. I = don't see ignoring the RA information completely.

Sure, supersede vs ignore is = fine; main point being
the DHCPv6 server knows better what that group = of
hosts should be using than the router does, so the
host should = use what the DHCPv6 server sends it,
not the RA message from the = router.

For some = definitions of "knows" and some contexts of = "better".

I hope that's a bit clearer; sorry to not have = been clearer
earlier.

=
Much clearer. I have to ask... Do you have a running network where = this actually is still in use? I've seen a few environments like this, = but most of them were deprecated years ago due to various problems that = they create in IPv4.

Owen


Virtualization is actually increasing the number = of deployments
in that mode, rather than decreasing = them.

Seems to me that = there are much better ways to do what you describe for virtualization, = but that's getting into a bit of a digression from the WG charter. = Hopefully the information I have provided above can prove useful in = addressing your issues without requiring major protocol = surgery.

Owen

= --Apple-Mail=_57D3F96A-7370-44F9-BF65-0A7CD43849D0-- From marka@isc.org Wed Jan 8 20:06:48 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6B81AE027 for ; Wed, 8 Jan 2014 20:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMutHKLq4TMM for ; Wed, 8 Jan 2014 20:06:46 -0800 (PST) Received: from mx.ams1.isc.org (amstel.isc.org [IPv6:2001:500:60:d::56]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5591AE15D for ; Wed, 8 Jan 2014 20:06:46 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id F16142383C8; Thu, 9 Jan 2014 04:06:24 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 49964160446; Thu, 9 Jan 2014 04:16:50 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id E3DE8160389; Thu, 9 Jan 2014 04:16:49 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id E8188C981CE; Thu, 9 Jan 2014 15:07:38 +1100 (EST) To: Owen DeLong From: Mark Andrews References: <24CFBACC-7994-47D2-AAC5-F4CCAB4B29D8@delong.com> In-reply-to: Your message of "Wed, 08 Jan 2014 19:17:08 -0800." <24CFBACC-7994-47D2-AAC5-F4CCAB4B29D8@delong.com> Date: Thu, 09 Jan 2014 15:07:38 +1100 Message-Id: <20140109040738.E8188C981CE@rock.dv.isc.org> Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 04:06:49 -0000 In message <24CFBACC-7994-47D2-AAC5-F4CCAB4B29D8@delong.com>, Owen DeLong write s: > On Jan 8, 2014, at 18:56 , Matthew Petach wrote: > > > > > > > > > On Tue, Jan 7, 2014 at 10:10 AM, Owen DeLong wrote: > > > >> > >> As such, the options are not DHCPv6 only, RA-only, and Both, but, > >> RA-only and Both. > >> > >> The scenarios where RA-Only make sense are any scenario where you do > >> not need greater control of the client configuration than Prefix > >> information, routing information, and DNS resolver addresses and search > >> strings. > >> > >> In any scenario where you need to supply the host with more > >> configuration information on a dynamic basis, DHCPv6 is also required. > >> > >> Also, if you want dynamic DNS updates, deterministic assigned > >> suffixes, etc., these fall into the DHCPv6 realm. > >> > >> It's really as simple as that as near as I can tell. > >> > >> If you want to run without RAs, then you are into the realm of static > >> configuration. I, personally, do not see this as a problem. > >> > >> Or, you're a company with tens of thousands > >> of desktops, where static configuration is not > >> a viable option, but control over address > >> assignment from central servers is a must; > >> in that environment, DHCPv6-assignment-only is > >> a reality, and will exist; it is already being explored > >> today, and to to deny that it is coming is equally as > >> useful as cursing the coming of nightfall; it > >> will happen, with or without your agreement > >> or support. > >> > > > > We are talking about two different things... > > > > > DHCPv6-assignment-only is possible today. It is what happens if you set > > the M bit in the RA. DHCPv6 will then have full control of address > > assignment. > > > > What is not possible today is to do that DHCPv6 assignment without > > receiving an RA to instruct the host to do so. > > > > Why is that a problem for the network environments you have described? > > > > > > I'm sorry, it's been a really busy week, so I'm a bit behind in > > following up to the people who have asked for further clarification. > > > > Here's the slightly more detailed description of the situation: > > > > 4 groups of hosts on the subnet; > > groupA, groupB, groupC, groupD; > > four different policies on the DHCP server. > > subnet has 4 different upstream routers. > > groupA is handed IP address on routerA as default gateway > > groupB is handed IP address on routerB as default gateway > > groupC is handed IP address on routerC as default gateway > > groupD is handed IP address on routerD as default gateway > > > > all four groups are within the same L2 broadcast domain, > > and have applications that make use of that same-subnet > > relationship. > > Ignoring for the moment that this is an incredibly convoluted corner case > which is likely fragile, at best, in IPv4... So what? > In IPv4, that makes sense. In IPv6, it does not. In your opinion. > In IPv6, you don't have broadcasts, it's all multicast. You can define a > multicast scope (ff04 perhaps?) that incorporates those 4 distinct IPv6 > subnets. And how do the nodes know to listen to that address? Just turn off default router assignment at the RA level and do it via DHCPv6 for per host route assignment. > > In looking at DHCPv6 vs RAs, I don't see how to give the > > different groups of hosts the appropriate default router IP > > unless the default router is provided by the DHCP server. > > That's because you haven't looked at the fact that in IPv6, these don't > need a shared broadcast domain to continue working the way you describe. > > > The routers don't have a way to target their respective > > RAs to just members of the appropriate group of hosts, > > and there doesn't seem to be an option to tell the hosts > > in groupA to only listen to RAs from routerA. > > You could, but it would involve elaborate configuration on the routers. > It makes more sense to divide these groups of hosts into separate IPv6 > networks. Yes, but that makes lots of other assumptions of capabilities of the existing components of the network at both layer 1 and layer 2. One should be able to upgrade just that nodes and the routers without touching cabling, switches and hubs and get similar functionality in both IPv4 and IPv6. RA's as the only source of default routes are not able to meet this requirement. > > As to getting software to do it, that's not really the problem. The > > problem is that there's already lots of deployed hardware and software > > that is implemented as defined in the current RFCs. > > > > It's the elimination of RAs that is problematic. Using DHCP exclusively > > for address assignment isn't difficult. Adding routing information to > > DHCPv6 wouldn't be all that difficult. > > > > > > So, I apologize for the confusion. I didn't mean that RAs need > > to go away; I simply meant we need a way for the hosts to > > ignore the default router information from the RA, and instead > > to obtain that from DHCPv6. Essentially, having the RA only > > pass the "go ask DHCPv6" option bits to the hosts, and > > everything else gets superseded by what the DHCPv6 > > server sends to the host. > > I don't see a mechanism for not treating a router announcing RAs as a > candidate default route is likely to succeed. I think it would require > modifications to host stacks that could not be backward compatible with > existing implementations. The existing host stacks should already be capable of using router lifetime for this. > I'm all for adding RIO equivalence in DHCPv6, though I think it is > significantly less useful than advocated. > > > Eliminating RAs from the process would require a major change that > > would likely pose some level of compatibility problem with existing > > deployments. > > > > Owen > > > > > > Sorry; it's not really eliminating the RAs from the process as much > > as saying "ignore what the RA is sending you, other than the > > option bits telling you to go ask the DHCPv6 server for your info, > > and use what the DHCPv6 server gives you, including your > > default route information." > > I can certainly see ways to suggest that DHCPv6 route information, if > presented, should supersede any route information learned via RA. I don't > see ignoring the RA information completely. > > > I hope that's a bit clearer; sorry to not have been clearer > > earlier. > > Much clearer. I have to ask... Do you have a running network where this > actually is still in use? I've seen a few environments like this, but > most of them were deprecated years ago due to various problems that they > create in IPv4. > > Owen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From sthaug@nethelp.no Wed Jan 8 21:35:39 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49AAF1ADF63 for ; Wed, 8 Jan 2014 21:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMVY8FDLCtK1 for ; Wed, 8 Jan 2014 21:35:37 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id D7C851ACCF9 for ; Wed, 8 Jan 2014 21:35:36 -0800 (PST) Received: (qmail 57075 invoked from network); 9 Jan 2014 05:35:24 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 9 Jan 2014 05:35:24 -0000 Date: Thu, 09 Jan 2014 06:35:24 +0100 (CET) Message-Id: <20140109.063524.74693853.sthaug@nethelp.no> To: mpetach@netflight.com From: sthaug@nethelp.no In-Reply-To: References: <20140109032919.77E84C97CF5@rock.dv.isc.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 05:35:39 -0000 > OMG. Yes! That's perfect! So, I need to change to > set the M and O bits, set lifetime to 0, and then > send the default route info via DHCPv6 and I should > be golden! You're a lifesaver, thank you! ... except that you can't send the default route info via DHCPv6 today. Steinar Haug, AS2116 From swmike@swm.pp.se Wed Jan 8 22:05:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2C31ACCF5 for ; Wed, 8 Jan 2014 22:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6s8qc5OlC2i for ; Wed, 8 Jan 2014 22:05:50 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 1D73E1ACCF9 for ; Wed, 8 Jan 2014 22:05:49 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7E41C9C; Thu, 9 Jan 2014 07:05:38 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 73B2F9A; Thu, 9 Jan 2014 07:05:38 +0100 (CET) Date: Thu, 9 Jan 2014 07:05:38 +0100 (CET) From: Mikael Abrahamsson To: Lorenzo Colitti In-Reply-To: Message-ID: References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7@nkgeml506-mbx.china.huawei.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org, "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 06:05:52 -0000 On Thu, 9 Jan 2014, Lorenzo Colitti wrote: > 2. If there is no RA, or if the RA does not include a Prefix Information > Option covering the addresses assigned via DHCPv6, then those addresses > cannot be used for any communication, even on-link communication. This is The above text doesn't make sense to me. It's perfectly legal to have an RA without on-link prefix, meaning host has only a default-route, and then give this host a /128 via DHCPv6 IA_NA. The host routing table will then see its own /128 and a default-route. Perfectly usable deployment scenario. -- Mikael Abrahamsson email: swmike@swm.pp.se From lorenzo@google.com Wed Jan 8 22:17:33 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797091ADBD5 for ; Wed, 8 Jan 2014 22:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLahzlNyRTBt for ; Wed, 8 Jan 2014 22:17:31 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id D1D611AD948 for ; Wed, 8 Jan 2014 22:17:31 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id tp5so3152911ieb.36 for ; Wed, 08 Jan 2014 22:17:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=b4jjCVcMC4YWMtzvuDmHLhIJ3mTf9UwI09bhvplSw5o=; b=fIi1hRqmTHZu4WZu/jz5W4ieag1c2/pqcMYrZF5R8mDvzdFlR21mX+sDx4/xOUVN+G aY8EFhBtU7Oivg/cvsJ+vMzj2nPe3cX2187iR2RpKMayiHUxyPidU85gN/1y3Lw69KLg fNGRqeK11xHpHcALlu4GXLvGT9yOtJgFjPL/b33nI96SkE5jpWP81jG5R0h5mDi2yodz 7b4u4cTL4JPY9NKukJ5NdA6xNgejSrLBO/8Yt7JCY68lKqBxGOugo3nTSvltsJJoh3cZ 18u+CB8hCSBwm6O7JcESGI1cLic7ShIsgwTYJaD7DHCgX4k/91tUzAonc8gT4iZJBWWw A3rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=b4jjCVcMC4YWMtzvuDmHLhIJ3mTf9UwI09bhvplSw5o=; b=jMvIFSmVnCPCbodJVCEaru7oI4BMxCZgkdlagXfwJ/gmCE5thTRov8ePaciTYTZpg+ sKGC5sqL5lzPi7Ssw/V9XTH/Fyqtu0KyIqWuYlJmTM8EFQTlCzz8f6gjViazvEVgDCLJ A8EriiFyt0LKxvw+EiFOVXkKCUrADWP5J+uaXV32RHseERwF8M9MHKr47rRTaz8hQvKV JUuq3nr2DYoS69VBcioH5jFIouogfhj2Z0i/KLnfJtGiUviV9v6ks78N6yINWVsPsoE+ QpulHQXiRgXn3pj1jHxCoNeXX/azsyO3voVhaR/vPn/gYdahmVylYg8EqgWxk6pjKAxf Czww== X-Gm-Message-State: ALoCoQn9wauzl/r8DsT+6AkV5t2qDG/4RSiHm0opKmTOXDCIyT2kg3WRRIxLzlq1ftcuLLT0VUtUXuOFFpXqK96fzolYYcWdQLn4OLpN985F3AKTO9oUVxZc0dUmd+uYBhdnVO73vQbEHZqVZSR/sbyukTdIi+JYTgZbwjmlzVcqXtUhL+ufOcSq1OwS0Uq6nirNB/XWHO4t X-Received: by 10.50.36.67 with SMTP id o3mr1577230igj.47.1389248242249; Wed, 08 Jan 2014 22:17:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Wed, 8 Jan 2014 22:17:02 -0800 (PST) In-Reply-To: References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7@nkgeml506-mbx.china.huawei.com> From: Lorenzo Colitti Date: Thu, 9 Jan 2014 15:17:02 +0900 Message-ID: To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=089e01160174fc0eff04ef838f37 Cc: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org, "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 06:17:33 -0000 --089e01160174fc0eff04ef838f37 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 9, 2014 at 3:05 PM, Mikael Abrahamsson wrote: > > 2. If there is no RA, or if the RA does not include a Prefix Information >> >> Option covering the addresses assigned via DHCPv6, then those addresses >> cannot be used for any communication, even on-link communication. This >> is >> > > The above text doesn't make sense to me. It's perfectly legal to have an > RA without on-link prefix, meaning host has only a default-route, and then > give this host a /128 via DHCPv6 IA_NA. The host routing table will then > see its own /128 and a default-route. Perfectly usable deployment scenario. You're right, that text is incorrect. How about: "2. Addresses assigned by DHCPv6 can only reach destinations specified by a received Router Advertisement (either via default route, a Prefix Information Option with O=1, or a Route Information Option). If there is no RA, or the RA does not specify any routes, then those addresses cannot be used ..." --089e01160174fc0eff04ef838f37 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 9, 2014 at 3:05 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
=C2=A0 2. If there is no RA, or if the RA does not include a Prefix Informa= tion

=C2=A0 Option covering the addresses assigned via DHCPv6, then those addres= ses
=C2=A0 cannot be used for any communication, even on-link communication. Th= is is

The above text doesn't make sense to me. It's perfectly legal to ha= ve an RA without on-link prefix, meaning host has only a default-route, and= then give this host a /128 via DHCPv6 IA_NA. The host routing table will t= hen see its own /128 and a default-route. Perfectly usable deployment scena= rio.

You're right, that text is incorrect. How about:

"2. Addresses assigned by DHCPv6 can only reach= destinations specified by a received Router Advertisement (either via defa= ult route, a Prefix Information Option with O=3D1, or a Route Information O= ption). If there is no RA, or the RA does not specify any routes, then thos= e addresses cannot be used ..."
--089e01160174fc0eff04ef838f37-- From sthaug@nethelp.no Wed Jan 8 22:44:25 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62AEB1ADEC1 for ; Wed, 8 Jan 2014 22:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4GCBhtiyrhR for ; Wed, 8 Jan 2014 22:44:23 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 07CB91ADEA7 for ; Wed, 8 Jan 2014 22:44:22 -0800 (PST) Received: (qmail 58648 invoked from network); 9 Jan 2014 06:44:11 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 9 Jan 2014 06:44:11 -0000 Date: Thu, 09 Jan 2014 07:44:11 +0100 (CET) Message-Id: <20140109.074411.74692067.sthaug@nethelp.no> To: lorenzo@google.com From: sthaug@nethelp.no In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 06:44:25 -0000 > > The above text doesn't make sense to me. It's perfectly legal to have an > > RA without on-link prefix, meaning host has only a default-route, and then > > give this host a /128 via DHCPv6 IA_NA. The host routing table will then > > see its own /128 and a default-route. Perfectly usable deployment scenario. > > > You're right, that text is incorrect. How about: > > "2. Addresses assigned by DHCPv6 can only reach destinations specified by a > received Router Advertisement (either via default route, a Prefix > Information Option with O=1, or a Route Information Option). If there is no > RA, or the RA does not specify any routes, then those addresses cannot be > used ..." Which I read as an address assigned by DHCPv6 cannot use a statically configured default route. Are you sure this is what you intend to say? Steinar Haug, AS2116 From lorenzo@google.com Wed Jan 8 22:51:15 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85761AC8F5 for ; Wed, 8 Jan 2014 22:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r931Lkuw22_j for ; Wed, 8 Jan 2014 22:51:13 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id AA4E11A1F61 for ; Wed, 8 Jan 2014 22:51:13 -0800 (PST) Received: by mail-ig0-f175.google.com with SMTP id j1so15316385iga.2 for ; Wed, 08 Jan 2014 22:51:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+KpN6i4lRXuvof7OPZfyxrKzw26xxcUzmAkv8azZx24=; b=jhqwlmJTGrqkh5PQEBsHuehk3rdvHjug240TV6Ynb44mqGkW4BlbJxnAfjettKU9iU bfkwbYIr1KKc7QE4yuReEULSgxHlSLujNTXC2jubtvNLndy2OzJZ1FdBVmnqv+uPowam jJQTpakzTlPAzoPLk2cbBBD+tuterlnCrn+kwavEoxLPDx7xUD1Pl5Mb3s7p8BPZO0eH O6J62aVvcotfz4adfabVHcfJQTbeP9FWJFH4r+89V6gyOe+WQTbyumPctfn7vOuzbl1R 2uJK11uQfQU6tY1qE+RiPMeAqHnsSxBCT1U6P5QNxKKiayp8JzMH6hUlmgxQ3+KEwJgR RjPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+KpN6i4lRXuvof7OPZfyxrKzw26xxcUzmAkv8azZx24=; b=JLvlB8lGJefRnfRft/eMF3ssRr32o1f9pZsbYaHJlOqb8sM91y0qVZBLeRuT7yGzL3 CyhCtvWeHuC4h4oxwtqSO9n9H0X7Dt0QAgGxTW2eWt40xTafxpeeRMwpBNYT4tjM6OYL CWTjfuuQWC0F28YSDeNEzyz8FSwnftC3ZrkciPxra0zg+5aJmnLD+1ifwrv6csuUvgIt tvRmATrtErYDyq2dvSNI6IvgiErrKrFrOeKpxat95EBWh6RDGf6DwmnE9d7kzW0L4GKb t+3jrX7bbEdo6UMwTJedF3aTakIm+8Fa21izJKFEr7DeSt5/Ekm6BMoBtAcCLdk9PsaU Tu4w== X-Gm-Message-State: ALoCoQm+2PpRVGxH8vGarar+PlB86ghwRNv6iz9kVuLSPHk22vrtxxxRvkSCTvLNA0EJcYVBylF4ahLkcEXcAI45GEINbjl6hVODRSKpKb40kU5zjdE36qLwoHxJ8SSEp7ZOh8kg3XZDWfB6tTREg+m+HZE20OBcvXsfVxLlZ9suduS16Rk/OvQjJxIjjIgjSr7Y+Lceu7Pf X-Received: by 10.42.35.5 with SMTP id o5mr1077484icd.8.1389250264019; Wed, 08 Jan 2014 22:51:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Wed, 8 Jan 2014 22:50:43 -0800 (PST) In-Reply-To: References: From: Lorenzo Colitti Date: Thu, 9 Jan 2014 15:50:43 +0900 Message-ID: To: Matthew Petach Content-Type: multipart/alternative; boundary=90e6ba5bbabd7e016d04ef84084e Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 06:51:15 -0000 --90e6ba5bbabd7e016d04ef84084e Content-Type: text/plain; charset=UTF-8 On Thu, Jan 9, 2014 at 11:56 AM, Matthew Petach wrote: > Here's the slightly more detailed description of the situation: > > 4 groups of hosts on the subnet; > groupA, groupB, groupC, groupD; > four different policies on the DHCP server. > subnet has 4 different upstream routers. > groupA is handed IP address on routerA as default gateway > groupB is handed IP address on routerB as default gateway > groupC is handed IP address on routerC as default gateway > groupD is handed IP address on routerD as default gateway > > all four groups are within the same L2 broadcast domain, > and have applications that make use of that same-subnet > relationship. > Ok, I see two ways to do this: One way is to have the hosts simply ECMP over the 4 routers. That way you get better load-sharing, too. The other is to use unicast RAs. I think you could do it like this: 1. When the 4 first-hop routers receive an RA, they each make a RADIUS request. 2. The RADIUS server would return a Route-IPv6-Information attribute containing a default route with an infinite lifetime. 3. The designated router sends an unicast RA to the specified client, the other three do nothing. 4. When renewal time comes up, have the host send an RS again and repeat. Before you say "that's insane", consider the fact that it's almost exactly the same flow as a relayed DHCPv6 request, and that it involves a similar number of packets and the same amount of state. You do have to keep MAC-to-default-gateway mappings in the RADIUS server, but if you're doing this I suspect you already have MAC-to-IP mappings and IP-to-default-gateway mappings in the DHCPv4 server. I doubt there's any hardware that does this today, but you jumped into this discussion by saying that there are multibillion-dollar enterprises that are willing to pay vendors to implement the features they need. Why not pay them to implement this? Yes, it's not DHCP, but on the plus side, it's all IETF standard technology, and it should do what you want. BTW - if this is a datacenter architecture built for load-sharing, I have a feeling you might evolve away from it in the future (either to ECMP or to something else) so you can get better load-sharing - even with four routers, you're leaving bandwidth on the table. Cheers, Lorenzo --90e6ba5bbabd7e016d04ef84084e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 9, 2014 at 11:56 AM, Matthew Petach <mpetach@netflight.com> wrote:
Here's the slightly more detailed description of the situation:
4 groups of hosts on the subnet;
groupA, grou= pB, groupC, groupD;
four different policies on the DHCP server.
subnet has 4 different upstream routers.
groupA is handed IP = address on routerA as default gateway
groupB is handed IP address on rou= terB as default gateway
groupC is handed IP address on router= C as default gateway
groupD is handed IP address on routerD as default gateway
all four groups are within the same L2 broadcast domain,
and= have applications that make use of that same-subnet
relationship.
=C2=A0
Ok, I see two ways to = do this:

One way is to have the hosts simply ECMP = over the 4 routers. That way you get better load-sharing, too.
The other is to use unicast RAs. I think you could do it like th= is:

1. When the 4 first-hop routers receive an RA,= they each make a RADIUS request.
2. The RADIUS server would retu= rn a Route-IPv6-Information attribute containing a default route with an in= finite lifetime.
3. The designated router sends an unicast RA to the specified client, = the other three do nothing.
4. When renewal time comes up, have t= he host send an RS again and repeat.

Before you sa= y "that's insane", consider the fact that it's almost exa= ctly the same flow as a relayed DHCPv6 request, and that it involves a simi= lar number of packets and the same amount of state.

You do have to keep MAC-to-default-gateway mappings in = the RADIUS server, but if you're doing this I suspect you already have = MAC-to-IP mappings and IP-to-default-gateway mappings in the DHCPv4 server.=

I doubt there's any hardware that does this today, = but you jumped into this discussion by saying that there are multibillion-d= ollar enterprises that are willing to pay vendors to implement the features= they need. Why not pay them to implement this? Yes, it's not DHCP, but= on the plus side, it's all IETF standard technology, and it should do = what you want.

BTW - if this is a datacenter architecture built for lo= ad-sharing, I have a feeling you might evolve away from it in the future (e= ither to ECMP or to something else) so you can get better load-sharing - ev= en with four routers, you're leaving bandwidth on the table.

Cheers,
Lorenzo
--90e6ba5bbabd7e016d04ef84084e-- From lorenzo@google.com Wed Jan 8 22:54:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E101ADFA9 for ; Wed, 8 Jan 2014 22:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdYo92MYYHHA for ; Wed, 8 Jan 2014 22:54:46 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id EBE2B1A1F61 for ; Wed, 8 Jan 2014 22:54:45 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id uq1so486368igb.1 for ; Wed, 08 Jan 2014 22:54:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8/2a531MogvAEuczRmXyxzQ//XwDNhBNU9y0C6+Z8DA=; b=jXvkLFG58Pu63Dj5N8JHV03rh01KjhpxgWVcuEFLCGZF4rLil2XhNVH2m3atjtiZSa aBMLiB06M+cr862jLtmHXtcCeYb0t0LT8idDHRGd0EPvhLcM5B5gDHhYJVdGCf89Pc8h asNSUQIi4l3HISeHcRM0k/50NWDdpyNFPi/JqICmIBoQDLvrqmVtU03PR9GBsqFKDbOX 9zf99xijfvrFJzdSi+DH7MRupMmqf/4CHIwmvw5+IPofjLOOZHIDYwOYF5eMGGU2tLX8 JxCAaaWuaaQ8ZFc8XcfiMXSvsdRexw454RXgy1raFR1S6WeLAVIEBBE0Ry010j9B5Em3 BNvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8/2a531MogvAEuczRmXyxzQ//XwDNhBNU9y0C6+Z8DA=; b=f1XRVF+b7NBZxo+gzAS6m96p/qU99f6hCf6I9lXxdbkuo16kMtB0Nj96AcG4l1MGd4 taJKN7SgOGzbx4Jg34C/9hLrNR75i8ukthdHWlxcNYoCP0LPELj+7cKFn79A5NVpQX5B b19fYpNKwTkCuxaNujHFxUdjfhr1iOz/DTYyzt/18g71lR22uXhxqPua95agrIN6czt0 D/fOeHoPbXMTK4O5tAdJRV0aOALDTpVSjHoLEzggvfslBaqenVH4aN9sy6KB+OzPoPlF d9/5iEq2d0upXWaDyDXZVKj84djbhitQPmF8UkhO9QQSnpAqZfmvXqb03j0zmZmQmxOr n/FA== X-Gm-Message-State: ALoCoQn8MxczEedmSYUlpeisvuyySB72aUEHBXZHuxzashIL/Zzkfxr5CiQnWZTLAFOWAUd9Eyl3KwUwWjgo6834O8A3nyeZan+UkENSx1YeI5eQnXlFveLGShSMrgakVFLM2TSHzYEEpziyR/WmNySJUSjuOV5xs2GFuHg2wYjFuwWxSndu3s2wBHiB2oOpzV/MIgOEjLxo X-Received: by 10.42.62.196 with SMTP id z4mr982820ich.49.1389250476426; Wed, 08 Jan 2014 22:54:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Wed, 8 Jan 2014 22:54:16 -0800 (PST) In-Reply-To: <20140109.074411.74692067.sthaug@nethelp.no> References: <20140109.074411.74692067.sthaug@nethelp.no> From: Lorenzo Colitti Date: Thu, 9 Jan 2014 15:54:16 +0900 Message-ID: To: sthaug@nethelp.no Content-Type: multipart/alternative; boundary=90e6ba614a7626eb2104ef84156f Cc: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org, "v6ops@ietf.org WG" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 06:54:47 -0000 --90e6ba614a7626eb2104ef84156f Content-Type: text/plain; charset=UTF-8 On Thu, Jan 9, 2014 at 3:44 PM, wrote: > > "2. Addresses assigned by DHCPv6 can only reach destinations specified > by a > > received Router Advertisement (either via default route, a Prefix > > Information Option with O=1, or a Route Information Option). If there is > no > > RA, or the RA does not specify any routes, then those addresses cannot be > > used ..." > > Which I read as an address assigned by DHCPv6 cannot use a statically > configured default route. Are you sure this is what you intend to say? > Oh, it can. I didn't mention manual configuration because I think it's a bad idea to do so in an operational guidance document. It will work, but it doesn't seem like something to recommend. I mean - what if you renumber the link, or you change the router IP, or...? --90e6ba614a7626eb2104ef84156f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 9, 2014 at 3:44 PM, <sthaug@nethelp.no> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
> "2. Addresses assigned by DHCPv6 can only reach= destinations specified by a
> received Router Advertisement (either via default route, a Prefix
> Information Option with O=3D1, or a Route Information Option). If ther= e is no
> RA, or the RA does not specify any routes, then those addresses cannot= be
> used ..."

Which I read as an address assigned by DHCPv6 cannot use a statically=
configured default route. Are you sure this is what you intend to say?
<= /blockquote>

Oh, it can. I didn't mention manual con= figuration because I think it's a bad idea to do so in an operational g= uidance document. It will work, but it doesn't seem like something to r= ecommend. I mean - what if you renumber the link, or you change the router = IP, or...?
--90e6ba614a7626eb2104ef84156f-- From swmike@swm.pp.se Wed Jan 8 23:02:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE80F1ADEA6 for ; Wed, 8 Jan 2014 23:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.389 X-Spam-Level: X-Spam-Status: No, score=-4.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERkP4lQGFzk8 for ; Wed, 8 Jan 2014 23:02:02 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 95BAC1ADD9A for ; Wed, 8 Jan 2014 23:02:02 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B4F4C9C; Thu, 9 Jan 2014 08:01:52 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id AAC4D9A; Thu, 9 Jan 2014 08:01:52 +0100 (CET) Date: Thu, 9 Jan 2014 08:01:52 +0100 (CET) From: Mikael Abrahamsson To: Lorenzo Colitti In-Reply-To: Message-ID: References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7@nkgeml506-mbx.china.huawei.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org, "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 07:02:03 -0000 On Thu, 9 Jan 2014, Lorenzo Colitti wrote: > > You're right, that text is incorrect. How about: > > "2. Addresses assigned by DHCPv6 can only reach destinations specified by a > received Router Advertisement (either via default route, a Prefix > Information Option with O=1, or a Route Information Option). If there is no > RA, or the RA does not specify any routes, then those addresses cannot be > used ..." or something like this: 2. DHCPv6 can assign addresses but not routing. Routing can be implemented on hosts by means of accepting and implementing information from RA messages containing default-route, Prefix Information Option with O=1, or Route Information Option, or by configuring manual routing. Without routing, IPv6 addresses won't be used for commmunication outside the host. -- Mikael Abrahamsson email: swmike@swm.pp.se From lorenzo@google.com Wed Jan 8 23:13:25 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8821AE030 for ; Wed, 8 Jan 2014 23:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEM-G67g8mz9 for ; Wed, 8 Jan 2014 23:13:23 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4207F1AC8F5 for ; Wed, 8 Jan 2014 23:13:23 -0800 (PST) Received: by mail-ig0-f172.google.com with SMTP id hl1so15347466igb.5 for ; Wed, 08 Jan 2014 23:13:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QEPaKbkekGZED3RQN+2sa+0PQVPekz6V8Lwx57OI8Jk=; b=A9KWjceD9EEN0okPkZYrhV4sjU1r2wLVoGNL9DzUtxZOd4WcOsXufgd7J89/y8xjOb 3UTsI9LYsrtWkT2ZjKvaSK/SjMdBsvX046SkFOB1M+oRhGfTiBrgwgbTMGEi84TC7htc gysQwFK9ayu/yiBLliYneYpl2gzDhbfxjDQ/cJpIG0MprbR8TWgRuAXfLOvAb/+kFJaZ 20SPAS6p48W05KXqxg7aRlhSpTACiC/L17/7n/kxf2XxDE72NGQo1HFFqbZvtm3Jip1U ZStJ9KSAj2ogz2La8FtpOesWv0oWiRSwImhHZ/PWBHGm+CNd8ikW6VjskAzPvCj8lnlc vHvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=QEPaKbkekGZED3RQN+2sa+0PQVPekz6V8Lwx57OI8Jk=; b=F5OOUOq2ooxmmY/4kBMqzLHzo9O6ZdVHILKbAOedPPXt0IS/GGprDhS/ZzjRU4RGL9 pxDyUQWxg8mg0QPkL5FSrL8cEC2/Qxjh745JMiXbhXOvQGrzIIhSPl4oiY0Caq0RQAza 56md7QFd/V3RWnvMyBzO7/T5Kw8bT6zrdLxiUPRDtptbqdhGAmb5f36CsvY3M6/d+IPf 4FA0J4epja3+uaS6mf/faSWxj9DHveGwEMqCZUIoJps+FSt1bnCIeQeIs/9FvSmZ7/KV 2TOxuOgibmreksDD1ulAViMjbvKJ29ImMc8/RpG9Cad3/X9E/JJVqsEEiJrWEzQBXm0u GFYQ== X-Gm-Message-State: ALoCoQkjawWqmH+u7upTKjNhqpppoVxlWOjSf8ueDg/dqIoRazEbyGUqyA90eQRzBjgXwtqQz0eXK1HU4bPHU6MU9vhVu9UphsOfwkk9CVmq3PqtEhxODkG8aCvfBaWaxmdBtWbXq0ck7WiIliGuSNpl2DVjDarOddO2T6uWoLoSmyTwAYnowEznnM6muJ6S8+OdpFb7P6e3 X-Received: by 10.42.226.66 with SMTP id iv2mr1073700icb.11.1389251593699; Wed, 08 Jan 2014 23:13:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Wed, 8 Jan 2014 23:12:52 -0800 (PST) In-Reply-To: References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7@nkgeml506-mbx.china.huawei.com> From: Lorenzo Colitti Date: Thu, 9 Jan 2014 16:12:52 +0900 Message-ID: To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=001a113323b8bf23de04ef8457ff Cc: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org, "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 07:13:25 -0000 --001a113323b8bf23de04ef8457ff Content-Type: text/plain; charset=UTF-8 On Thu, Jan 9, 2014 at 4:01 PM, Mikael Abrahamsson wrote: > 2. DHCPv6 can assign addresses but not routing. Routing can be implemented > on hosts by means of accepting and implementing information from RA > messages containing default-route, Prefix Information Option with O=1, or > Route Information Option, or by configuring manual routing. Without > routing, IPv6 addresses won't be used for commmunication outside the host. > That's better, but people might not grasp the implication that if you assign addresses using DHCPv6, and have no RA and no static routing, you can't even use the addresses to communicate on-link. You do say "outside the host", but I think people might miss that. Consider: people used to DHCPv4 might naturally think that you can use DHCPv6 to assign address 2001:db8::1/64, and that this will allow on-link communication even in the absence of a default route, PIO, or RIO. But in DHCPv6 you can't do that, you can only assign address 2001:db8::1/128, and that can't talk to *anything at all* without routing. Technically, even in DHCPv4 you can assign addresses without a subnet mask, but since that's not very useful, people don't tend to do it. :-) What about adding the following? "Thus, for example, if there is no RA and no static routing, then addresses assigned by DHCPv6 cannot be used even for communication between hosts on the same link." --001a113323b8bf23de04ef8457ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 9, 2014 at 4:01 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
2. DHCPv6 can assign addresses but not routing. Routing can be im= plemented on hosts by means of accepting and implementing information from = RA messages containing default-route, Prefix Information Option with O=3D1,= or Route Information Option, or by configuring manual routing. Without rou= ting, IPv6 addresses won't be used for commmunication outside the host.=

That's better, but people might not gr= asp the implication that if you assign addresses using DHCPv6, and have no = RA and no static routing, you can't even use the addresses to communica= te on-link. You do say "outside the host", but I think people mig= ht miss that.

Consider: people used to DHCPv4 might naturally think t= hat you can use DHCPv6 to assign address 2001:db8::1/64, and that this will= allow on-link communication even in the absence of a default route, PIO, o= r RIO. But in DHCPv6 you can't do that, you can only assign address 200= 1:db8::1/128, and that can't talk to *anything at all* without routing.= Technically, even in DHCPv4 you can assign addresses without a subnet mask= , but since that's not very useful, people don't tend to do it. :-)=

What about adding the following? "Thus, for exampl= e, if there is no RA and no static routing, then addresses assigned by DHCP= v6 cannot be used even for communication between hosts on the same link.&qu= ot;
--001a113323b8bf23de04ef8457ff-- From swmike@swm.pp.se Wed Jan 8 23:16:43 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7441AC8F5 for ; Wed, 8 Jan 2014 23:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.389 X-Spam-Level: X-Spam-Status: No, score=-4.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9P6UhRy8TmUx for ; Wed, 8 Jan 2014 23:16:41 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5136B1AE06D for ; Wed, 8 Jan 2014 23:16:41 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 3B37F9C; Thu, 9 Jan 2014 08:16:31 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 339DB9A; Thu, 9 Jan 2014 08:16:31 +0100 (CET) Date: Thu, 9 Jan 2014 08:16:31 +0100 (CET) From: Mikael Abrahamsson To: Lorenzo Colitti In-Reply-To: Message-ID: References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7@nkgeml506-mbx.china.huawei.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org, "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 07:16:43 -0000 On Thu, 9 Jan 2014, Lorenzo Colitti wrote: > What about adding the following? "Thus, for example, if there is no RA > and no static routing, then addresses assigned by DHCPv6 cannot be used > even for communication between hosts on the same link." Fine by me! -- Mikael Abrahamsson email: swmike@swm.pp.se From sthaug@nethelp.no Wed Jan 8 23:19:24 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACC01AE0B5 for ; Wed, 8 Jan 2014 23:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvRUlTCPsuEx for ; Wed, 8 Jan 2014 23:19:22 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 1C98A1AE08C for ; Wed, 8 Jan 2014 23:19:21 -0800 (PST) Received: (qmail 58963 invoked from network); 9 Jan 2014 07:19:11 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 9 Jan 2014 07:19:11 -0000 Date: Thu, 09 Jan 2014 08:19:11 +0100 (CET) Message-Id: <20140109.081911.41687735.sthaug@nethelp.no> To: swmike@swm.pp.se From: sthaug@nethelp.no In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 07:19:24 -0000 > > What about adding the following? "Thus, for example, if there is no RA > > and no static routing, then addresses assigned by DHCPv6 cannot be used > > even for communication between hosts on the same link." > > Fine by me! Agree, this sounds good. Steinar Haug, AS2116 From randy@psg.com Thu Jan 9 00:04:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2A81ADF75 for ; Thu, 9 Jan 2014 00:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1I_CnbeZ0iD4 for ; Thu, 9 Jan 2014 00:04:31 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 4053B1AE15D for ; Thu, 9 Jan 2014 00:04:31 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1W1AbD-0007c6-VB; Thu, 09 Jan 2014 08:04:20 +0000 Date: Thu, 09 Jan 2014 17:04:18 +0900 Message-ID: From: Randy Bush To: Lorenzo Colitti In-Reply-To: References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> <20140107104001.GM81676@Space.Net> <72626BC4-CB9E-49E8-8A54-48A141F52C0C@nominum.com> <6A64F619-4A0E-423A-A5E7-4C3234B461AE@nominum.com> <7F9988DB-00B8-47FF-928A-E346164BEAFD@puck.nether.net> <7183B360-FD11-479E-9361-5A57D42F0308@employees.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Thu_Jan__9_17:04:13_2014-1"; micalg=pgp-sha512; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 08:04:32 -0000 --pgp-sign-Multipart_Thu_Jan__9_17:04:13_2014-1 Content-Type: text/plain; charset=US-ASCII > The one-sentence summary is "we want to do it the same way as we do in > IPv4". close. we want the paying customer to be able to move to ipv6 with as little cost and effort as possible. we know this violates the one true religion. so did getting rid of tlas and 42 other symptoms of arrogance in ipv6. randy --pgp-sign-Multipart_Thu_Jan__9_17:04:13_2014-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAABCgAGBQJSzlgCAAoJEMzMBey4OgLtr7AH/iDzuqlog7xTQZscDEopZUSK aXwQpDB1JGe3EtVm86GA/bcupOTARkHMY/Eo+H8ivetf0of19K7pPvkk2EF7pOZV 8ALtko33FP/8EWp75cmnOdqBGt3gp65vYGCYboT8GGmcTNIwc+LF6mezpZbjSIEs fcVC5mNYOft4kROaE/Ua/EdEekoTHK5p5cWOwd9/5MqzMyN2xMQ9QNZRe5GO1r4O CVwom/7t+tmZbTOslcZ2jsu5ewJTt5OmFBWTV8kzpJJpn0PabxjWlU3/hwLL1AHH J/yAc0xxMuwvbkru1xiH5QGw/1sV12BEN9so9NTL/CuBum0GX74AZdb/X+9u8Mc= =yNlg -----END PGP SIGNATURE----- --pgp-sign-Multipart_Thu_Jan__9_17:04:13_2014-1-- From tore@fud.no Thu Jan 9 00:10:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2D91AE06F for ; Thu, 9 Jan 2014 00:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqREXanpc4X0 for ; Thu, 9 Jan 2014 00:10:45 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) by ietfa.amsl.com (Postfix) with ESMTP id DDECD1AE181 for ; Thu, 9 Jan 2014 00:10:44 -0800 (PST) Received: from [2a02:c0:2:1:1194:6:0:1002] (port=43935 helo=echo.linpro.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1W1AhD-0004Rt-AJ; Thu, 09 Jan 2014 09:10:31 +0100 Message-ID: <52CE5977.4030107@fud.no> Date: Thu, 09 Jan 2014 09:10:31 +0100 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mikael Abrahamsson , Lorenzo Colitti References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7@nkgeml506-mbx.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org, "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 08:10:47 -0000 * Mikael Abrahamsson > Prefix Information Option with O=1 This should be L=1 (cf. RFC 4861 section 4.6.2). The O flag means something completely different, and is in any case not part of the Prefix Information (definition in RFC 4861 section 4.2). Other than that I agree with your text. Perhaps the "containing default-route" could be elaborated on a little bit, though. It might not be obvious to everyone that an RA doesn't "contain" a default route option in the same way it does Prefix/Route Information Option. For example: «Routing can be implemented on hosts by means of accepting and implementing information from RA messages containing default-route (i.e., RAs whose Router Lifetime field is nonzero), [...]» Tore From gert@Space.Net Thu Jan 9 00:15:58 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1F11AE1BD for ; Thu, 9 Jan 2014 00:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhXcg2ZlirYZ for ; Thu, 9 Jan 2014 00:15:56 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3911AE146 for ; Thu, 9 Jan 2014 00:15:55 -0800 (PST) Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id A36B16046A for ; Thu, 9 Jan 2014 09:15:45 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 3D7DF60356 for ; Thu, 9 Jan 2014 09:15:45 +0100 (CET) Received: (qmail 58634 invoked by uid 1007); 9 Jan 2014 09:15:45 +0100 Date: Thu, 9 Jan 2014 09:15:45 +0100 From: Gert Doering To: Randy Bush Message-ID: <20140109081545.GD81676@Space.Net> References: <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> <20140107104001.GM81676@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PWczQuM56qutXCxo" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 08:15:58 -0000 --PWczQuM56qutXCxo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Jan 09, 2014 at 06:00:07AM +0900, Randy Bush wrote: > > Your multi-million-dollar enterprise can do DHCPv6-based IPv6 address > > assignment perfectly well today. Client and server implementations > > exist, and RFCs back that. > > > > The thing that can not be done today is "do that if you do not have RAs > > on your network, that will tell the clients 'go to the DHCPv6 server > > for address information, but route the packets to me'". >=20 > the multi-million-euro enterprise can continue to do ipv4. and that's > what they are doing. we can stick our heads and pretend that > this is not a festering and embarrassing problem or we can fix it. The problem statement given for the "multi-million-euro enterprise" was=20 "they want to use DHCPv6!!!!" (not "DHCPv6 without RA"). And they *can*. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --PWczQuM56qutXCxo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBUs5asN9WwGXkzn/FAQLysw//d+YPrtZ3AoGkVIJKTMlUkoJcnYQ9GcN5 cA2zoZ7V51YuaHIXV6EUWgaUohGIUrCSC31ea6ihe1okAEJ/xSNGahG3vGEK90k0 Ee+ti0NUTYaMXgcqspWri+zucvzSdJ3SdfHp3x4EMNKFGp7VG1Lt7ioE3Iq6A93w by6mH4AU301AAtLfwU0Gjc1ex1/TxPt0BOOVTK9BX4mUMKWyogg6yAfRh6+N8/XJ Qzhep4ZmRBNYk9j+yDGiCjqgTcC7Rq+X7qgvg0D6SEwuWC1eXPht0Y+/+ciYwE86 X42m17KGLD+kuSvwjxo4Tzfp00Q3Haz/mBheIP+fP2R3Pl8B72j2f91/zpmMuWPi DOM5xjmDVyCckNGm7OcN5Yr/fvwf9PViFZFqtm/oc+KSH5KnXSlb76536czH9go8 c6k8jHESnQIpgGz48COB3o143y1ubfloXJ1JTFAsZwz/cLlVM3JF/tH78YcIIYqM KqDs0aLJIEOsA1XU1PE9YPvNEta3RUNJCo4T0u9+7yiGMvHiS9jFzLhPIMZiztFs tX4Zh+t32d9oXSKU4fCStjuF0lya/a8Fi+aW4biYuV6OGil0GF3xXePf86WTcFqj 5dMJGjIcwSFoBh9a6hZDtYp22NhDQpbDF1fcxCT7jJfecaoNXGv0zJfyl/5B6zNG vslqZj4R4NQ= =ZcpH -----END PGP SIGNATURE----- --PWczQuM56qutXCxo-- From alexandru.petrescu@gmail.com Thu Jan 9 00:26:22 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37CF1ADBE5 for ; Thu, 9 Jan 2014 00:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5ikrD_7KQn8 for ; Thu, 9 Jan 2014 00:26:20 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1A51AD0F0 for ; Thu, 9 Jan 2014 00:26:20 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s098Q5iP013146; Thu, 9 Jan 2014 09:26:05 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2DB142069B5; Thu, 9 Jan 2014 09:27:06 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1F725203594; Thu, 9 Jan 2014 09:27:06 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s098PP0w017505; Thu, 9 Jan 2014 09:26:05 +0100 Message-ID: <52CE5CF5.4070807@gmail.com> Date: Thu, 09 Jan 2014 09:25:25 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ole Troan , Lorenzo Colitti References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <20140108.104016.74707582.sthaug@nethelp.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 08:26:23 -0000 Le 08/01/2014 11:54, Ole Troan a écrit : >> The authors may well agree that this a DHCPv6-only configuration without >> RAs doesn't do anything useful. I'd be inclined to agree *today* - but I >> certainly wouldn't want to rule out DHCPv6-only configuration without >> RAs in the future. >> >> It's not the role of an operational group to surmise on what future standards might exist, or to make future standards. So I agree this document shouldn't rule out DHCPv6-only configuration. But for precisely the same reason, it should also not imply that it may exist in the future. >> >> So the correct course of action is to remove it, because it is inappropriate to cite something that's not a standard (and, given *years* of lack of consensus, is unlikely to become a standard anytime soon) in an operational guidance document. >> >>> Can you remove it, then? As an operational group we don't want to provide >>> guidance on invalid use cases. :-) >> >> Removing it is not going to make the demand for DHCPv6-only configuration >> without RAs magically disapppear. >> >> Sure, but v6ops doesn't do protocol work. That discussion belongs in 6man. And until 6man has that discussion and changes the standards, then DHCPv6-only configuration is not a standard and it's inappropriate to cite it in an operational guidance document. > > I would expect the operational working group to come up with the problem statement / use cases. Maybe someone get together and draft text? Alex > > those I have not seen yet, at least no in a language I can understand. > > cheers, > Ole > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From lorenzo@google.com Thu Jan 9 01:32:36 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F6E1AE097 for ; Thu, 9 Jan 2014 01:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2bm2FLwcHz9 for ; Thu, 9 Jan 2014 01:32:35 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id E1AC71AE04B for ; Thu, 9 Jan 2014 01:32:34 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id tp5so3304893ieb.36 for ; Thu, 09 Jan 2014 01:32:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3cxAyRqD2p0DwjjUbQldj/jKeUPeF4ls+y1qtniUvMY=; b=mLPfzN62nGzZi3NzOdSlfZZ6qSWx+j5vH/u7+f/tZUuiA7CITJthuMEGzp5CrAGwS5 DG5JLTTEG4GV+tLSodW+op5m5aS94FlJ/p5ALnNsPXJQVt6T6JoZqOFEYx0vsZmKL0vG 4pVdF8C+uIKEsbLyBwQzyn2V38JZ1tQwFwNPeIXUowIgbSvfKVFD9sJvktB0WM825Nq6 4sfdxV8UeMmuY1IHEZtVfwD2JzEBaBTgIoyJMPgIWk1cajfIkNd1jju0DwNhicFwGoA/ sQmiTIYWi2woyXu+niKNVhsqa9k8GNcsa4e2IAnCHfhYtKEFa9p1olXCfiiNmauoIPv5 N+sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=3cxAyRqD2p0DwjjUbQldj/jKeUPeF4ls+y1qtniUvMY=; b=kGNqhGApYtwAFSAXKA2lnUjVUKIevJztXO3q6qWHlbZW7sprGNIXeuv7lmEiRbVMUH EVq++8N3wt9hNvgL7KOtugE0VD83T231cYl5swJEFcFK363WFB2Wb7noemwMmcxj6Atv QKktfYReC4wEvaoa4TyiWGcvqcA8s7EDsjl5lqEBvRamhlAkGR2Dcjmtz3SFLDce8i3s oj7SgiSMrg/y3+E3UGZeE3/OvwfzYoXlqGQK5PMkP+sxAm19GdI/pdKuyBlhRIPnnE00 tVN3eiK0wZA37KO1KGfXJCiCo8X35CU7ViMI0VDZ+fleudFEE1OI3w7CtmPeMKBocq27 394Q== X-Gm-Message-State: ALoCoQmxbBTHLXSGFndaBV0eHiMLr++cHgY0dEHHeumknF+eDFMgWuqsFzsRDk8VS4K5GVCvhkyr+MgHifp1dfyE5Dwn2KQf2fyd+Nybwv9sAjINjMENh2IROKkWZB0HVaxxFhm+y+g9qyOmvaH9kKUK78Qj/XmQcTcSvB+gbEarWSkjWCDnf5Z2AoD9FA3RVMZJRpXbXqIf X-Received: by 10.50.36.67 with SMTP id o3mr2250974igj.47.1389259945370; Thu, 09 Jan 2014 01:32:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Thu, 9 Jan 2014 01:32:04 -0800 (PST) In-Reply-To: <52CE5977.4030107@fud.no> References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7@nkgeml506-mbx.china.huawei.com> <52CE5977.4030107@fud.no> From: Lorenzo Colitti Date: Thu, 9 Jan 2014 18:32:04 +0900 Message-ID: To: Tore Anderson Content-Type: multipart/alternative; boundary=089e011601748be08c04ef86491b Cc: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org, "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 09:32:36 -0000 --089e011601748be08c04ef86491b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jan 9, 2014 at 5:10 PM, Tore Anderson wrote: > * Mikael Abrahamsson > > > Prefix Information Option with O=3D1 > > This should be L=3D1 (cf. RFC 4861 section 4.6.2). > > The O flag means something completely different, and is in any case not > part of the Prefix Information (definition in RFC 4861 section 4.2). > Yep, my mistake. I thought "onlink" and wrote "O". But as you point out, O =3D "Other config", and "L" =3D "onLink". > Other than that I agree with your text. Perhaps the "containing > default-route" could be elaborated on a little bit, though. It might not > be obvious to everyone that an RA doesn't "contain" a default route > option in the same way it does Prefix/Route Information Option. > > For example: =C2=ABRouting can be implemented on hosts by means of accept= ing > and implementing information from RA messages containing default-route > (i.e., RAs whose Router Lifetime field is nonzero), [...]=C2=BB > "Hosts can acquire routing information by accepting RA messages with a nonzero Default Lifetime, Prefix Information Options with O=3D1, or Route Information Options"? --089e011601748be08c04ef86491b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Jan 9, 2014 at 5:10 PM, Tore Anderson <tore@fud.no> wrote:=
* Mikael Abrahamsson

> Prefix Information Option with O=3D1

This should be L=3D1 (cf. RFC 4861 section 4.6.2).

The O flag means something completely different, and is in any case not
part of the Prefix Information (definition in RFC 4861 section 4.2).

Yep, my mistake. I thought "onlink"= and wrote "O". But as you point out, O =3D "Other config&qu= ot;, and "L" =3D "onLink".
=C2=A0
Other than that I agree with your text. P= erhaps the "containing
default-route" could be elaborated on a little bit, though. It might n= ot
be obvious to everyone that an RA doesn't "contain" a default= route
option in the same way it does Prefix/Route Information Option.

For example: =C2=ABRouting can be implemented on hosts by means of acceptin= g
and implementing information from RA messages containing = default-route
(i.e., RAs whose Router Lifetime field is nonzero), [...]=C2=BB

"Hosts can acquire routing information = by accepting RA messages with a nonzero Default Lifetime, Prefix Informatio= n Options with O=3D1, or Route Information Options"?
--089e011601748be08c04ef86491b-- From tore@fud.no Thu Jan 9 01:37:55 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2FC1AE10E for ; Thu, 9 Jan 2014 01:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrufuEVyhNpq for ; Thu, 9 Jan 2014 01:37:54 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8EC1AE105 for ; Thu, 9 Jan 2014 01:37:54 -0800 (PST) Received: from [2a02:c0:2:1:1194:6:0:1002] (port=45427 helo=echo.linpro.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1W1C3a-0001n0-S2; Thu, 09 Jan 2014 10:37:42 +0100 Message-ID: <52CE6DE6.8040800@fud.no> Date: Thu, 09 Jan 2014 10:37:42 +0100 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7@nkgeml506-mbx.china.huawei.com> <52CE5977.4030107@fud.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org, "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 09:37:55 -0000 * Lorenzo Colitti > "Hosts can acquire routing information by accepting RA messages with a > nonzero Default Lifetime, Prefix Information Options with O=1, or Route > Information Options"? s/Default Lifetime/Router Lifetime/ (at least I don't think the term «Default Lifetime» is defined anywhere; RFC4861 uses «Router Lifetime»). Other than that, +1 Tore From tore@fud.no Thu Jan 9 01:45:55 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCB41AE189 for ; Thu, 9 Jan 2014 01:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1_40hqA83vj for ; Thu, 9 Jan 2014 01:45:53 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) by ietfa.amsl.com (Postfix) with ESMTP id 9A62F1AE04B for ; Thu, 9 Jan 2014 01:45:53 -0800 (PST) Received: from [2a02:c0:2:1:1194:6:0:1002] (port=45541 helo=echo.linpro.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1W1CBK-0002My-N6; Thu, 09 Jan 2014 10:45:42 +0100 Message-ID: <52CE6FC6.2090100@fud.no> Date: Thu, 09 Jan 2014 10:45:42 +0100 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7@nkgeml506-mbx.china.huawei.com> <52CE5977.4030107@fud.no> <52CE6DE6.8040800@fud.no> In-Reply-To: <52CE6DE6.8040800@fud.no> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org, "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 09:45:55 -0000 * Tore Anderson > * Lorenzo Colitti > >> "Hosts can acquire routing information by accepting RA messages with a >> nonzero Default Lifetime, Prefix Information Options with O=1, or Route >> Information Options"? > > s/Default Lifetime/Router Lifetime/ (at least I don't think the term > «Default Lifetime» is defined anywhere; RFC4861 uses «Router Lifetime»). > > Other than that, +1 Scratch that, as I still insist on s/O=1/L=1/ :-D (and after that, +1) Tore From lorenzo@google.com Thu Jan 9 01:50:49 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC351AE1CA for ; Thu, 9 Jan 2014 01:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nIFbfzZMnJ0 for ; Thu, 9 Jan 2014 01:50:48 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 2841B1AE1B2 for ; Thu, 9 Jan 2014 01:50:48 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id as1so3342797iec.13 for ; Thu, 09 Jan 2014 01:50:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VCM56E9bVC4QSXhdBD5S4Cve5i1lWpcB8DzUmN3AtSE=; b=pzmdDxitecUJ9wb3eP/KK6P3khlBWqaU+gx6NUyugJPoWYvxyE6VtamwTMyAKSnsLu PHBIBi5jFeYzWFvmuutN06fjAiVJLZFjCRhDHJd5/6taIDqLVIm4PAsZbCwDmhhe79L7 9mruWBz4wj3VRuiC5t1/n7YIHshLZmcy3rz0dXZCA9iBkx2sgltv1vdgfcSggF3Sg1P3 iLWyTXQ16pXgk0Qy6gan42VwOUHfpOrPjdVf51S9/IiTlR0Azt5puaf/aC8/eYnywIef I+fhW6JW1v4BvampvYJEfDO+3+bpUL+1fPmrD2kcuSB9623gEXgGKD1m9vYvFv4AgoPc y+Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=VCM56E9bVC4QSXhdBD5S4Cve5i1lWpcB8DzUmN3AtSE=; b=PX8gOvMcNBkoS7Q4Uim6/1tgMk71Dq/vPdj0C7rBZLegpT3voFlwMCFhIWP6FxWozo +BBt38Aqi9CE52dW8/fmn2SpON3qSFkwxbGcCGQpkFZkfRdmkP1M9V9TM+s9l2qy1WmH vVySapdtpnAgfcNY1pVAONOMTRds3Zzrmxx6JSBfwDJR1y2U5ME8EF8jBb4ejJFv95oc oweveZVN3Yc3g/UDgYc8cMIYQQqOVKlKJjLCje9iH4OMWSUgdYRoOJPmBwrhavi3fY+J AKXKQp9mbwM5QENwJENBtmygDQQd65QPLQy8/INLcYcpuwTKJuo4u6X1s4/hA5xpnDaI qHEg== X-Gm-Message-State: ALoCoQnAwnAAwxRv+orxtDK9KVSN/+F25RHRP1qrpsrjINvN9MvBph/Ux3nLLrvIsdnu/Hsu1KTi5G0W64imHPbunu2u05QM1kBf2jl7Tvb91MKSApDAvnR3JlimnApE2tX2zInhZCReeAQyifnv3jewXL3WJEVx/qgYY7LYFoZSD0kl+hNJ/2s6p+ehJMwxJ+vLLx30MNVM X-Received: by 10.43.138.8 with SMTP id iq8mr1527199icc.37.1389261038627; Thu, 09 Jan 2014 01:50:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Thu, 9 Jan 2014 01:50:18 -0800 (PST) In-Reply-To: <52CE6FC6.2090100@fud.no> References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7@nkgeml506-mbx.china.huawei.com> <52CE5977.4030107@fud.no> <52CE6DE6.8040800@fud.no> <52CE6FC6.2090100@fud.no> From: Lorenzo Colitti Date: Thu, 9 Jan 2014 18:50:18 +0900 Message-ID: To: Tore Anderson Content-Type: multipart/alternative; boundary=001a11c20364b5525404ef868a9d Cc: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org, "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 09:50:49 -0000 --001a11c20364b5525404ef868a9d Content-Type: text/plain; charset=UTF-8 On Thu, Jan 9, 2014 at 6:45 PM, Tore Anderson wrote: > > Other than that, +1 > > Scratch that, as I still insist on s/O=1/L=1/ :-D (and after that, +1) > Send the final text? :) --001a11c20364b5525404ef868a9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 9, 2014 at 6:45 PM, Tore Anderson <tore@fud.no> wrote:
=
> Other than that, +1

Scratch that, as I still insist on s/O=3D1/L=3D1/ :-D (and afte= r that, +1)

Send the final text? :)
--001a11c20364b5525404ef868a9d-- From tore@fud.no Thu Jan 9 01:52:58 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAF11AE1F3 for ; Thu, 9 Jan 2014 01:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5wb4nienUoM for ; Thu, 9 Jan 2014 01:52:57 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) by ietfa.amsl.com (Postfix) with ESMTP id 1F09C1AE1E9 for ; Thu, 9 Jan 2014 01:52:57 -0800 (PST) Received: from [2a02:c0:2:1:1194:6:0:1002] (port=45659 helo=echo.linpro.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1W1CI9-0002oG-Vb; Thu, 09 Jan 2014 10:52:45 +0100 Message-ID: <52CE716D.1020801@fud.no> Date: Thu, 09 Jan 2014 10:52:45 +0100 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7@nkgeml506-mbx.china.huawei.com> <52CE5977.4030107@fud.no> <52CE6DE6.8040800@fud.no> <52CE6FC6.2090100@fud.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org, "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 09:52:58 -0000 * Lorenzo Colitti > Send the final text? :) Certainly: «Hosts can acquire routing information by accepting RA messages with a nonzero Router Lifetime, Prefix Information Options with L=1, or Route Information Options» Tore From otroan@employees.org Thu Jan 9 02:03:36 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1EEF1AE1FF for ; Thu, 9 Jan 2014 02:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mS_rRwqaNhYt for ; Thu, 9 Jan 2014 02:03:35 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 626121AE131 for ; Thu, 9 Jan 2014 02:03:35 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGZzzlKQ/khL/2dsb2JhbABZgwu6U4EOFnSCJQEBAQMBDlcSAgULCw44VwaIDwiqcZoQF44aaweDJIETAQOQM5l5gW+BPzs X-IronPort-AV: E=Sophos;i="4.95,630,1384300800"; d="asc'?scan'208";a="3377825" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 09 Jan 2014 10:03:25 +0000 Received: from dhcp-lys02-vla252-10-147-116-56.cisco.com (dhcp-lys02-vla252-10-147-116-56.cisco.com [10.147.116.56]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s09A3OBi001883 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jan 2014 10:03:24 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_117C34D0-95DC-450B-9D44-2433E90AC3B5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ole Troan In-Reply-To: Date: Thu, 9 Jan 2014 11:03:23 +0100 Message-Id: References: <24CFBACC-7994-47D2-AAC5-F4CCAB4B29D8@delong.com> To: Matthew Petach X-Mailer: Apple Mail (2.1827) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 10:03:36 -0000 --Apple-Mail=_117C34D0-95DC-450B-9D44-2433E90AC3B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Matthew, thanks for presenting a concrete use case. > It's actually not that convoluted; it allows you to segment > your traffic flows across different upstream devices/interfaces > without having to forklift upgrade your network infrastructure > completely. defaultA is actually an HSRP address that is > master on routerA, backup on routerB; defaultB is master > on routerB, backup on routerC; defaultC is master on > routerC, backup on routerD; and defaultD is master > on routerD, backup on routerA. Each router takes > care of 25% of the host load for the network that way. can I paraphrase the problem? "the problem is how to get hosts to load balance across multiple = first-hop routers?" or did I miss something? cheers, Ole --Apple-Mail=_117C34D0-95DC-450B-9D44-2433E90AC3B5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSznPrAAoJEFuJXizso86gf94H/A28J55ZjALDmMPFIk4UcxRh 1M9nRWhUTh6vxFYS3CncCkbjBkLXUn6Sm2tamhRxLrUzkXnn2/7X47VRpJ0ziDiO oKKD92H/PbEvEbDlAkutEpaP1y1bg1yr9lqECASV0WREvgu4htT3GWvnJsGZJJXB nqgdh6nhA/4p7uh89cvaTE6uvg3i/h3BaBTB5knGjoCInAVnzcbyydmno/gWxIcJ lj0VaksIaitI4bTKWaPpNKDGqN2/wMYUPjOQwFEuvB81PLN768hrkDi2g8kmukNT 3Zffw8ki3W4cRgV9mMjrH0OB9LDcFmgthDVe9oJFAz3HxGYhU3G5ve/ez1BGiUE= =sO90 -----END PGP SIGNATURE----- --Apple-Mail=_117C34D0-95DC-450B-9D44-2433E90AC3B5-- From lorenzo@google.com Thu Jan 9 02:06:22 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0710A1AE20E for ; Thu, 9 Jan 2014 02:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BT-8p1W6xdqV for ; Thu, 9 Jan 2014 02:06:20 -0800 (PST) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id A40751AE131 for ; Thu, 9 Jan 2014 02:06:20 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id x13so3336920ief.38 for ; Thu, 09 Jan 2014 02:06:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gvpE2UF00ek1CZIfVACHi23EJ5WUAHsIHYpdYwNpcRU=; b=QE5oIsR2jGdI1zngjHTr7PU2dg6ERJkF/rx1Fcjpx+xa/9TDxeyodKxNqpAG6tJtSJ zcosTUbsvi0otUleT4kSZ/SKZPhiTGsYmECxLTED6hEo8L041IofgvJcL7wvJywimYJD of0egHAv+eCrkd7WxXu/wP1H32XF7tV1QGcwDn1p4bR+RYYczBSUSlANQTdbpHSF8Z7c v2Bt0plkMh1WdjNT/gs0bepKEkPNfnFAr6gWw03b/FP/A/en/t4Ksbq76/Pv4/C9tTQw ssaTDlx8CFYrwAcbfKLcLr0UmJ+EqwqzNmqc5BiW1i0g1msEG2AtZ6/KaC9/WAe026oC l0kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=gvpE2UF00ek1CZIfVACHi23EJ5WUAHsIHYpdYwNpcRU=; b=ArOmD3u0J4XjBWYZdexidl3UIpiuGhDS2/oylJem6J+69CcZQDDVGMZJ6FmKB8gten xHJu5anyopx29th5MUJkJH4W14vpM0VahKTuXET5ZxPNV2Jlf5cetx9+HCBFixkpkIgv SaC0ANOY/+C9WPL3yEf/ZK7rJMvLKenSTI1qngIf05iLhWLtyMg49Qhh1yKSnbuckGQe 7ZFXUzZX1fYu4LfB/R4e5XvP+6q+MBZLqdDoUOEveKtcMrdxxRcXJf1ZMW+mZ01Ov2Ne K5I2M8xw6xGQeh09VNIDNADvsUvGqvyYKbW46LmTKc+sdeIPK9SjfXiQ5qh8stURRpaU x7EA== X-Gm-Message-State: ALoCoQkGOPpuiCcLlGDj2/v2fqgPM0eJnMcT1ybeJh+CT+C5rSnaYOfm/oN3bqVIhj6YCgzwuk6/30zIM4eyIFHRxahv3e1cAI2UPNhxz1S9TufVkpzqujnjs1O0yNhmRkjFcp40RnJ3W9n9vqzTO9/uio+1RgQpEBpBd4Gk01KJZEtValdfbAd8cKJI0jSsNRICgQa5gN/V X-Received: by 10.50.36.67 with SMTP id o3mr2376945igj.47.1389261971118; Thu, 09 Jan 2014 02:06:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Thu, 9 Jan 2014 02:05:49 -0800 (PST) In-Reply-To: References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> <20140107104001.GM81676@Space.Net> <72626BC4-CB9E-49E8-8A54-48A141F52C0C@nominum.com> <6A64F619-4A0E-423A-A5E7-4C3234B461AE@nominum.com> <7F9988DB-00B8-47FF-928A-E346164BEAFD@puck.nether.net> <7183B360-FD11-479E-9361-5A57D42F0308@employees.org> From: Lorenzo Colitti Date: Thu, 9 Jan 2014 19:05:49 +0900 Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=089e0116017449f60804ef86c2ee Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 10:06:22 -0000 --089e0116017449f60804ef86c2ee Content-Type: text/plain; charset=UTF-8 On Thu, Jan 9, 2014 at 5:04 PM, Randy Bush wrote: > > The one-sentence summary is "we want to do it the same way as we do in > > IPv4". > > close. we want the paying customer to be able to move to ipv6 with as > little cost and effort as possible. > > we know this violates the one true religion. so did getting rid of tlas > and 42 other symptoms of arrogance in ipv6. > I think the reason that people feel so strongly about it is that they feel that we as a community can do better than that, and that if we don't strive to do better than that now, the cumulative effect of operational familiarity with the old system, lack of developer familiarity, and buggy implementations will make it so that the new system cannot be made any better than the old. Also, TLAs were a fundamental change to the model. It wouldn't have worked. By comparison, not having routing in DHCPv6 is trivial, and we know that it works (even in enterprises). --089e0116017449f60804ef86c2ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 9, 2014 at 5:04 PM, Randy Bush <randy@psg.com> wrote:
> The one-sentence summary is "we want to do it t= he same way as we do in
> IPv4".

close. =C2=A0we want the paying customer to be able to move to ipv6 w= ith as
little cost and effort as possible.

we know this violates the one true religion. =C2=A0so did getting rid of tl= as
and 42 other symptoms of arrogance in ipv6.

=
I think the reason that people feel so strongly about it is that they = feel that we as a community can do better than that, and that if we don'= ;t strive to do better than that now, the cumulative effect of operational = familiarity with the old system, lack of developer familiarity, and buggy i= mplementations =C2=A0will make it so that the new system cannot be made any= better than the old.

Also, TLAs were a fundamental change to the model. It w= ouldn't have worked. By comparison, not having routing in DHCPv6 is tri= vial, and we know that it works (even in enterprises).
--089e0116017449f60804ef86c2ee-- From markzzzsmith@yahoo.com.au Thu Jan 9 02:06:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8B11AE21D for ; Thu, 9 Jan 2014 02:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePh2-FpSOoBm for ; Thu, 9 Jan 2014 02:06:43 -0800 (PST) Received: from nm39-vm5.bullet.mail.bf1.yahoo.com (nm39-vm5.bullet.mail.bf1.yahoo.com [72.30.239.149]) by ietfa.amsl.com (Postfix) with ESMTP id 31CB11AE21C for ; Thu, 9 Jan 2014 02:06:43 -0800 (PST) Received: from [66.196.81.170] by nm39.bullet.mail.bf1.yahoo.com with NNFMP; 09 Jan 2014 10:06:33 -0000 Received: from [98.139.212.245] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 09 Jan 2014 10:06:33 -0000 Received: from [127.0.0.1] by omp1054.mail.bf1.yahoo.com with NNFMP; 09 Jan 2014 10:06:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 511263.92373.bm@omp1054.mail.bf1.yahoo.com Received: (qmail 29365 invoked by uid 60001); 9 Jan 2014 10:06:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1389261993; bh=Tb252jweQkfPWwyo0PC9XBRrnjcmP9Vo/N5qcVJ3kWw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=r5VYtXnebF/nqwYDBKCgk8vVFJgkP8FnOsZ+PNZ1IoP1G4BE6jgo0YzvZjPhk8VHanjurD+gSO83oVTZGr2Oz3c1mlkj1ZXb/28GzwzF+sAo7ABDIts8VksF8WPstN03/WcqJCo+FCBO54RbGmaHWSfEimpqeGDBV/y1c5Te3AQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=LgYK2E0KswJNBkVetiw8Tmxt4ZiWLG0yWSFBI2cupRoIJ17j2L+TJ3JEtEnJtw7Kk5yaCeQPsxu6qDZz42NmW3q2k3ifvMLyZLJ4TiLM5ykFt3tbDfWWXnDocd7qXhPNM1WsgoTISuiuLKdHFrs+F2Sjie3xI7nf+Szj1z5o7i8=; X-YMail-OSG: ov7p1bEVM1kfioHF4UP.60IgJKyF.UB65OmOGRExbKKj1pn U_cDVVLdbgweApQ9yd499OaG.1l0nTzoPuecX1VScHKZq18EnM5pTlXTB8FH F4OikHG9zcXXf80Ky3DmrdJuMNwe9OG927fV587ItXYcYtpBPR5BTYslgtgD BI5VrKU2fcbR65rrt4EkUtDOrPkJ2D4a.GxbOWTaV1y7Nh4lvRGMFMPFiMQh Pgv6sIBI9ZRej4F.KceE63bd1JBBquQmEHxY_mYBOIzYOvDHcb6sQmacYaSf i5cIWGsCZcpU2QOXRGmtMfhkDWhek5MYSlUx3rWb4l0LBOhB7VN.zoB8h1nF LhaVaNz_8ISsffI6YsetYVvqV.xvSCvoaaDK2q_lM4q3n5WINt4HeTmUp.dp JGzhm0S0kyHgY_aIIedJDagTZ6cUMf89IWeF.hGmmJq5q2mp9.SOj7LbuQqK XR1KFWVEn63RElvPN79X4Id1mYButLYsQqZjOkzrqcL_6NR6lZOlilLwdzG_ GQDl1am5Z52LJ1LUoIQgBSC3fMDkGSiPlmbXO.lC5Jhy41s9DVEXEUFG4sfJ 9VqBj.WOKJca2hyY71S7WbTyF Received: from [150.101.221.237] by web161906.mail.bf1.yahoo.com via HTTP; Thu, 09 Jan 2014 02:06:33 PST X-Rocket-MIMEInfo: 002.001, CgoKCgoKCgoKCgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBSYW5keSBCdXNoIDxyYW5keUBwc2cuY29tPgo.IFRvOiBUZWQgTGVtb24gPHRlZC5sZW1vbkBub21pbnVtLmNvbT4KPiBDYzogInY2b3BzQGlldGYub3JnIiA8djZvcHNAaWV0Zi5vcmc.Cj4gU2VudDogVGh1cnNkYXksIDkgSmFudWFyeSAyMDE0IDg6NTcgQU0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9ywqDCoMKgIGRyYWZ0LXlvdXJ0Y2hlbmtvLXJhLWRoY3B2Ni1jb21wYXIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.172.614 References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> <20140107104001.GM81676@Space.Net> <72626BC4-CB9E-49E8-8A54-48A141F52C0C@nominum.com> <6A64F619-4A0E-423A-A5E7-4C3234B461AE@nominum.com> Message-ID: <1389261993.72423.YahooMailNeo@web161906.mail.bf1.yahoo.com> Date: Thu, 9 Jan 2014 02:06:33 -0800 (PST) From: Mark ZZZ Smith To: Randy Bush , Ted Lemon In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 10:06:45 -0000 =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A----- Original Message -----=0A> Fro= m: Randy Bush =0A> To: Ted Lemon =0A>= Cc: "v6ops@ietf.org" =0A> Sent: Thursday, 9 January 2014 8= :57 AM=0A> Subject: Re: [v6ops] New Version Notification for=A0=A0=A0 draft= -yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)=0A> =0A>>>=A0 if we want the= m to deploy ipv6, as opposed to more rfc1918 space, then=0A>>>=A0 we need t= o remove all speed bumps.=A0 not discuss them.=A0 not tell them=0A>>>=A0 th= at RA is the true religion.=A0 frelling remove the speed bump.=0A>> =0A>>= =A0 Can you name a specific speed bump?=A0 I've been listening to this=0A>>= =A0 conversation for eight years too, and have yet to hear one named.=A0 Yo= u=0A>>=A0 seem to be saying that RA is the speed bump, but that's not speci= fic.=0A>>=A0 What is it about RA that "they" need changed?=0A> =0A> the mis= sing dhcp function, exit router=0A>=A0=0A=0A=0AI don't think this is really= true at all. What motivates an enterprise to deploy a new technology is pr= imarily what it does for the enterprise, not specific features of it.=A0=0A= =0AIn the early 1990s, enterprises didn't deploy IPX for IPX's sake. They d= idn't say, "We want IPX." They said, "We want to be able to share files and= printers, because it is cheaper than floppy disks and sneakernet, and buyi= ng everybody individual printers." If they chose Novell Netware to share fi= les and printers, they then deployed IPX because Novell Netware required it= . Those who chose Banyan Vines for file and print sharing deployed the Bany= an Vines protocol instead.=0A=0AIn the middle to late 1990s, enterprises di= dn't deploy IPv4 for IPv4's sake.=A0=A0They didn't say, "We want IPv4." The= y said, "We want to be able to email other organisations and be able to acc= ess the WWW, because we can email customers and suppliers more quickly than= using slower fax and snail mail, and access information useful to our busi= ness on the Internet." They then needed IPv4 to do that, so they deployed I= Pv4 (and wondered why it all had to be so hard with address classes, subnet= masks and default gateways, compared to deploying and operating turn-key I= PX.)=0A=0AFor most enterprises, other than those that make their money from= information technology (like the ones that most people on this mailing lis= t work for), technology is a "necessary evil" to support their actual busin= ess of making some other type of widget. It is a cost that takes away from = the larger profit they could make on their widgets. If they can reduce thos= e costs, or even eliminate them, they will, because that increases their wi= dget profit.=A0=0A=0ASo a new technology has to either save the enterprise = money or make the enterprise money for it to be justified.=0A=0AThe "killer= app" for IPv6 for an enterprise is one that exclusively operates over IPv6= (instead of over their already deployed IPv4) _and_ makes or saves them mo= ney. Some enterprises may never encounter an IPv6-only application that doe= s this, so they may never have an incentive to deploy it on their network. = They may wish to have access to the IPv6 Internet eventually, but all that = might mean is IPv6 enabling the external interface of their corporate polic= y enforcing web proxy, reached over RFC1918 IPv4.=0A=0AChange IPv6 as much = as people want, but if it isn't possible to identify how it, or the applica= tions that exclusively run over it will save or make them money, enterprise= s will ignore it. More change and more options to it will only increase it'= s deployment costs, further increasing the barrier it has to jump before it= saves or makes an enterprise money.=A0=0A=0A=0ARegards,=0AMark. From lorenzo@google.com Thu Jan 9 02:10:20 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DC61AE205 for ; Thu, 9 Jan 2014 02:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2ppb7hD_36p for ; Thu, 9 Jan 2014 02:10:19 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 61CCC1AE1FE for ; Thu, 9 Jan 2014 02:10:19 -0800 (PST) Received: by mail-ig0-f177.google.com with SMTP id uy17so7127282igb.4 for ; Thu, 09 Jan 2014 02:10:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Bo3X35myMbtdkXzYpivZX5bVwSCFBa9k9CpeMfeSd6I=; b=BY55uyZnaw6dUPif7h9jJXX9CA76JWrGCFEvxhAyPDj68lX1DdrpSUWvAaNuCL71d7 A0/535PVg7aEGfwmKC6ckq5VBgjDiQDIwcxNxANYn1MSO6A+zUQN3Ccm6MFy1Vg9D5c8 Ydy4clt4HoH5cHFcvSxx+5+cFom2FUpEzbY8sdpNpWWaCIAAJioL1R4Z7cTl6ttsRe3B 6welZM301/EXHYENOFMwlEctWovZbNCDo2n8uiMIO7uqVINjvI0PiQOIqzonIDrhm1jq KVdA8ukFOYY9Jr+INOs8X6mTinyPIgbhrB1c4WXQ6C7mmRWffXPXyaB2ir0yTZlGzn39 4MUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Bo3X35myMbtdkXzYpivZX5bVwSCFBa9k9CpeMfeSd6I=; b=fHIze0CrTiQjDi8xs7i5tzCJP3tUZAgaq8ImW3UyY6cEc/CWnz7jtgwnPpxTApTwUf JNPFTXPubw2nef1wU/lXUafPQniq6OQB15qpBo8AfGhR3LCU0xUxGPafuEeYERlTy6jV MQ99wlN3Um5rv7tlxEbtA41PAzddTHo5k3yetsy8l1TaQDo8pV81leTAWqD6PK5iQ8C3 8nPfKvsR+SQ/E8u+DR4lp28jsjXjE+rzXGQ8GBNiafKqWkx2hNzmBYgQjHyUNa1gqTox v5lJXpZydg40G0UenrDPCongfaJaphH4iMGOeJ5wrKBzllFZ13hxf7geH6tglwTWoktH 5XnQ== X-Gm-Message-State: ALoCoQnxfLl7VD+g2wRCZEZQsbgDclfwYAt2TVz3pYLETyJuXQO45jpjyZSNLZddOO0Gyc0RmtkdQBJQOWaPP459IG6zFlQGM35WPvhxAXIe4vhoMu2Nnhiv2UPEuNtIltTwdMlzTOZVvYaPbQfcZvvAnS0WocoptjmjzHPCGGpyDL/Q+fcBVGlT3xz8zTZqRGl9RhFusUOv X-Received: by 10.42.144.201 with SMTP id c9mr1620561icv.16.1389262209850; Thu, 09 Jan 2014 02:10:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Thu, 9 Jan 2014 02:09:49 -0800 (PST) In-Reply-To: References: <24CFBACC-7994-47D2-AAC5-F4CCAB4B29D8@delong.com> From: Lorenzo Colitti Date: Thu, 9 Jan 2014 19:09:49 +0900 Message-ID: To: Ole Troan Content-Type: multipart/alternative; boundary=90e6ba6e8a1884c2b604ef86d0e9 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 10:10:20 -0000 --90e6ba6e8a1884c2b604ef86d0e9 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 9, 2014 at 7:03 PM, Ole Troan wrote: > can I paraphrase the problem? > "the problem is how to get hosts to load balance across multiple first-hop > routers?" > That's an easy problem to solve - do ECMP on the hosts. Unfortunately, though, I fear that the problem is "we want the IPv6 design to be the same as the IPv4 design we already have", and in general that's a problem that's impossible to solve without making IPv6 look the same as IPv4. --90e6ba6e8a1884c2b604ef86d0e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 9, 2014 at 7:03 PM, Ole Troan <otroan@employees.org> wrote:
can I paraphrase the problem?
"the problem is how to get hosts to load balance across multiple first= -hop routers?"

That's an easy = problem to solve - do ECMP on the hosts.

Unfortuna= tely, though, I fear that the problem is "we want the IPv6 design to b= e the same as the IPv4 design we already have", and in general that= 9;s a problem that's impossible to solve without making IPv6 look the s= ame as IPv4.
--90e6ba6e8a1884c2b604ef86d0e9-- From lorenzo@google.com Thu Jan 9 02:11:01 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C6F1AE226 for ; Thu, 9 Jan 2014 02:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUWuLk-9SAcO for ; Thu, 9 Jan 2014 02:11:00 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 36ED61AE228 for ; Thu, 9 Jan 2014 02:11:00 -0800 (PST) Received: by mail-ig0-f178.google.com with SMTP id ut6so7144334igb.5 for ; Thu, 09 Jan 2014 02:10:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gCM2S7/71Avpm4KzEUj1ac6sF9POCmMtzkAzopxO5DE=; b=NnaIPG7/hqOQdlutqs6qzfVqPx+tTYSAxhYqbP6p6V9TgGPBBgck3azCWZObHJjtk8 cAN3Befem2hmSaHTVM5/TNPZYsCohHwiZ2tzf7TQp1ixZ+kaS+iZib2nOy2cu5ukU0Fe /mP20lLv3WqzTUcKz/706r+lzmRR36bI3z6ErI1w/j5w1h49TgeODiZMVsIxD6h6sQnB NyQn36Kj0hR6Tkx56eWcN8kN4Zc9yYg89IZg2Ame8XW/cwS3K2iHcTPiyBz6StOSHlMH VErJUAdActzhP8eLUEqj+1PgMLguQbhz1ymkZ9Hy7XGarxTZur62Iw7keSC7/VXNxAQ5 X3UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=gCM2S7/71Avpm4KzEUj1ac6sF9POCmMtzkAzopxO5DE=; b=OltyYbE6kUgMKMe9nfJe1w531uxAbTU0N+LoXnQgMmgyThVzaGgcoHN9fLtBKtWmG8 1o3bTY8jtlDNKHzAFPgrSxHspiVNlh7IOqBa5WeWgOukOBfWv9Y4n0XLgOhN0xGFibsg Yia872qT+OF6asYt4oRxbuj829p99yJSl0l6VTeHRo8Ak1vYL0/HY1DrrBcl5VtOOpq2 houyrMw6IlDlkhE12VCn34OJyvuw/wkpit68OrOKzYhqlVuzWFhI82iF4nCoi5y5liRx fou8YSesRecOHdR2fvLMMtHEWtUJC/WH8f29111NxCDRi12O7Hxt/vARmgTHw2qtb4Ni zdiw== X-Gm-Message-State: ALoCoQnDl9Gzs6mCDqbeLBVD2MhcD4AdMbL8mvHjLBRv7ZBSX8YkdNBfYc/kZ6weSHSc5i12cYt+lMs9Z3+GB6Goo1PiooC9Bq3lVqzJNySh6soebPFSmsUwRGWPlAZQmUz0fSRTNuLdkRWbA4Qcyl+FWPjS5rdM0E1l2ZL8URjTTZKZWaCqZNIyUl3N3rNeyd/MtZEiiVFB X-Received: by 10.50.176.137 with SMTP id ci9mr37518537igc.31.1389262250727; Thu, 09 Jan 2014 02:10:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Thu, 9 Jan 2014 02:10:30 -0800 (PST) In-Reply-To: <1389261993.72423.YahooMailNeo@web161906.mail.bf1.yahoo.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> <20140107104001.GM81676@Space.Net> <72626BC4-CB9E-49E8-8A54-48A141F52C0C@nominum.com> <6A64F619-4A0E-423A-A5E7-4C3234B461AE@nominum.com> <1389261993.72423.YahooMailNeo@web161906.mail.bf1.yahoo.com> From: Lorenzo Colitti Date: Thu, 9 Jan 2014 19:10:30 +0900 Message-ID: To: Mark ZZZ Smith Content-Type: multipart/alternative; boundary=089e0111e0daf4806504ef86d2ac Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 10:11:01 -0000 --089e0111e0daf4806504ef86d2ac Content-Type: text/plain; charset=UTF-8 On Thu, Jan 9, 2014 at 7:06 PM, Mark ZZZ Smith wrote: > Change IPv6 as much as people want, but if it isn't possible to identify > how it, or the applications that exclusively run over it will save or make > them money, enterprises will ignore it. More change and more options to it > will only increase it's deployment costs, further increasing the barrier it > has to jump before it saves or makes an enterprise money. > Hear, hear. --089e0111e0daf4806504ef86d2ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 9, 2014 at 7:06 PM, Mark ZZZ Smith <markzzzsmith@yahoo.com= .au> wrote:
Change IPv6 as much as people want, but if i= t isn't possible to identify how it, or the applications that exclusive= ly run over it will save or make them money, enterprises will ignore it. Mo= re change and more options to it will only increase it's deployment cos= ts, further increasing the barrier it has to jump before it saves or makes = an enterprise money.=C2=A0

Hear, hear.=C2=A0
--089e0111e0daf4806504ef86d2ac-- From otroan@employees.org Thu Jan 9 02:26:53 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2624E1AE246 for ; Thu, 9 Jan 2014 02:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCisRjauj0-Z for ; Thu, 9 Jan 2014 02:26:52 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id BE92C1AE1AE for ; Thu, 9 Jan 2014 02:26:51 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPB4zlKQ/khN/2dsb2JhbABZgwu6U4ENFnSCJQEBAQMBDlcSAgULC0ZXBogPCKp4mhEXjwUHgySBEwEDkDOZeYFvgT87 X-IronPort-AV: E=Sophos;i="4.95,630,1384300800"; d="asc'?scan'208";a="2709302" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 09 Jan 2014 10:26:39 +0000 Received: from dhcp-lys02-vla252-10-147-116-56.cisco.com (dhcp-lys02-vla252-10-147-116-56.cisco.com [10.147.116.56]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s09AQcjf001818 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jan 2014 10:26:39 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_B6E22C15-EC4D-41F4-8AE3-6FFF42F100D4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ole Troan In-Reply-To: Date: Thu, 9 Jan 2014 11:26:37 +0100 Message-Id: References: <24CFBACC-7994-47D2-AAC5-F4CCAB4B29D8@delong.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1827) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 10:26:53 -0000 --Apple-Mail=_B6E22C15-EC4D-41F4-8AE3-6FFF42F100D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > can I paraphrase the problem? > "the problem is how to get hosts to load balance across multiple = first-hop routers?" >=20 > That's an easy problem to solve - do ECMP on the hosts. right. > Unfortunately, though, I fear that the problem is "we want the IPv6 = design to be the same as the IPv4 design we already have", and in = general that's a problem that's impossible to solve without making IPv6 = look the same as IPv4. that's not a class of problem I think we're able to solve in the IETF. I think it is a perfectly valid operational model to manually / = statically configure hosts though. Router Discovery provides a dynamic = way to discover a router for default, that handles multiple routers, = adjusts dynamically as the network changes. manual configuration doesn't do any of that, but that doesn't mean there = isn't a place for manual configuration. if operators want to configure the default route with something like = Puppet or Netconf isn't that acceptable with you? DHCP would just be another way to do manual configuration of static = information to hosts. if this was implemented in DHCP, and the expectation was that all hosts = should support it, how does the deployment model and transition phases look like? e.g. you have a mixed link with some hosts supporting the option and = some hosts that don't. is static DHCP configuration mutually exclusive with router discovery? cheers, Ole --Apple-Mail=_B6E22C15-EC4D-41F4-8AE3-6FFF42F100D4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSznleAAoJEFuJXizso86gbTEH/1mSsh6D5nJHpO+4Ju6bwQtc hK6Ia7XhYRz4/XU5HRaBV6jaYwhaoiwK+zoRvPRgRgqLj77AbZ4R5yN27hDQp9KF fCwiFjCNHYrVBCqDCJtfqQluXKkvdr9xLsHfptaXnYpFTVrUBU48VmYeJoa8kAfJ l3F2Lgoagx0WvBi3LP3688tWT4kAgvBWIM4qKTqVsVV0JSBtYjtr1Dx7pE36ml+Y NJtd9ySy+1gytjp3Nd+zLL7+gcvzopTnCc2DF5KIvELtVsnGyNEVV6IXo4FY73LB qfJo8UF/0lTQQGh0tdr9Hnd7umNWZhtwiCbwIFL93cU/Lo4CqXjW1CIOtQMqjUA= =8/D9 -----END PGP SIGNATURE----- --Apple-Mail=_B6E22C15-EC4D-41F4-8AE3-6FFF42F100D4-- From Ted.Lemon@nominum.com Thu Jan 9 03:56:57 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E021AE29B for ; Thu, 9 Jan 2014 03:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZ_J37EYjQAP for ; Thu, 9 Jan 2014 03:56:56 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 541E01AE29A for ; Thu, 9 Jan 2014 03:56:56 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUs6OfqF6/IWPTMzhV84qIHzXBM5X0O4s@postini.com; Thu, 09 Jan 2014 03:56:47 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 7C7841B82D7 for ; Thu, 9 Jan 2014 03:56:46 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 3DDCA19005C; Thu, 9 Jan 2014 03:56:46 -0800 (PST) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 9 Jan 2014 03:56:46 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Thu, 9 Jan 2014 06:56:42 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <71B4A0D3-B4F2-4B3C-B38E-ED7678BEA6FE@nominum.com> References: To: Matthew Petach X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 11:56:57 -0000 On Jan 8, 2014, at 9:56 PM, Matthew Petach = wrote: > 4 groups of hosts on the subnet; > groupA, groupB, groupC, groupD; > four different policies on the DHCP server. > subnet has 4 different upstream routers. > groupA is handed IP address on routerA as default gateway > groupB is handed IP address on routerB as default gateway > groupC is handed IP address on routerC as default gateway > groupD is handed IP address on routerD as default gateway >=20 > all four groups are within the same L2 broadcast domain, > and have applications that make use of that same-subnet > relationship. So is the problem you are trying to solve here essentially a cheap SDN = solution? Why not simply isolate the four groups of hosts onto four = separate VLANs? From alexandru.petrescu@gmail.com Thu Jan 9 05:11:31 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2CE71AE1C7 for ; Thu, 9 Jan 2014 05:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlmB6tby5IV1 for ; Thu, 9 Jan 2014 05:11:25 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 215821AE2BB for ; Thu, 9 Jan 2014 05:11:24 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s09DBFLg007027; Thu, 9 Jan 2014 14:11:15 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 11406206CE6; Thu, 9 Jan 2014 14:12:16 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 05440206CB1; Thu, 9 Jan 2014 14:12:16 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s09DB0WB013701; Thu, 9 Jan 2014 14:11:14 +0100 Message-ID: <52CE9FE4.9050309@gmail.com> Date: Thu, 09 Jan 2014 14:11:00 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <52CD7D0C.4010609@gmail.com> <52CD7EE8.9070008@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 13:11:31 -0000 Le 08/01/2014 18:16, Mikael Abrahamsson a écrit : > On Wed, 8 Jan 2014, Alexandru Petrescu wrote: > >> Well, have you tried IPv6 on a 1G system? I did and there is no >> RA, yet I set the default route to the tunnel I put in place. > > What do you mean by 1G? No, I haven't used 1G systems, as GSM is 2G > and this was launched in 1991 or so. We don't have any active 1G > systems left in my country, they were turned off long ago. I am not > aware that they had data capability anyway. Sorry, you are right. Yes, 1G analog is prior to 2G digital GSM. But, in some more detail, some mode of operation of 2G phones dates back to being used in 1G system. For example, the 'CSD' way of opening a connection amounts to having a data connection of a pure circuit switch. (prior to running IP on it). The CSD mode of connection of earliest GSM phones have ppp setup times in the order of minutes, as opposed to tens of seconds of GPRS. It's same mechanism as a modem of a 2400baud land copper phone line, if you see what I mean. Second, the earliest phones deployed in commercial aircraft carrying passengers have exclusively analog connections to the Earth (not GSM). That too support a speed of around 2400 to 9600baud. I'd call these two examples of '1G'. I may be wrong though, because nobody else talks '1G'. And one can run IPv6 on these '1G', by using IPv6 in IPv4 tunnels, and without RA. This is just to clarify what I meant, and to ack your correction. Alex PS: about 1G left in your country, I would double check... And I suppose if they exist they do support data connections with a simple modem. From alexandru.petrescu@gmail.com Thu Jan 9 05:19:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC231AE24D for ; Thu, 9 Jan 2014 05:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LGztW0jtrNc for ; Thu, 9 Jan 2014 05:19:28 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 980C51AE21A for ; Thu, 9 Jan 2014 05:19:28 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s09DJIiR008362; Thu, 9 Jan 2014 14:19:18 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 61194206CE6; Thu, 9 Jan 2014 14:20:19 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 53709206C26; Thu, 9 Jan 2014 14:20:19 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s09DJEWK019724; Thu, 9 Jan 2014 14:19:18 +0100 Message-ID: <52CEA1D2.3000109@gmail.com> Date: Thu, 09 Jan 2014 14:19:14 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Gert Doering References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> In-Reply-To: <20140108172808.GA81676@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" , Pete Vickers Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 13:19:31 -0000 Le 08/01/2014 18:28, Gert Doering a écrit : > Hi, > > On Wed, Jan 08, 2014 at 04:53:06PM +0100, Alexandru Petrescu wrote: >> Le 08/01/2014 16:04, Pete Vickers a écrit : >> [...] >>> All the arguments I've seen around control and security should be >>> addressed elsewhere rather than trying to hardwire the RA process. >> >> Addressing it elsewhere? Where? >> >> The lack of control and security in RA, compared to DHCP, means that >> people do not need to pre-register their laptops before connecting to an >> internal Enterprise network. That's a security risk. > > You're *so* misunderstanding the issues under discussion. > > First, nobody prevents doing this with DHCPv6 today. You don't need > "DHCPv6 and no RA" for this. Sorry, but I agree with you obviously there may be a misunderstanding somewhere. One would not appreciate an RA to allow an arbitrary Client to configure an IP address. If one did so, then there is a security risk: the Client is able to listen at IP level everything else in that network. This is a huge risk. In some settings, one would prefer the Client to pre-register its MAC address by some strongly authenticated means (strong == various speech and gesture only humans of a particular group are capable of). > Then, relying on DHCP to assure that a rogue laptop will not get an > address is fake security at best (it's trivial to sniff the network, If someone sniffs on an Ethernet cable then a red light is showing up somewhere warning there's a sniffer. If someone pretends a MAC address of somebody else then the second person is notified with a popup. > see what addresses are in use and just manually assign something) - > so this is actually an example of policies that do not serve what they > are claiming to do. This _may_ be an example, and may not be. > Registering the MAC addresses and not permitting access *to the network* > for unregistered devices is much more effective, but not strongly coupled > to "DHCP" or "no RA". Well, DHCP does have a database of these MAC addresses, whereas RA doesnt. Existing configuration tools are connected on DHCP part of these MAC addresses. Alex > > Gert Doering > -- NetMaster > From alexandru.petrescu@gmail.com Thu Jan 9 05:20:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B331AE2CF for ; Thu, 9 Jan 2014 05:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zgbs6nNsXG6V for ; Thu, 9 Jan 2014 05:20:43 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6EB1AE2CC for ; Thu, 9 Jan 2014 05:20:43 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s09DKWLK009861; Thu, 9 Jan 2014 14:20:32 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A307A206C5F; Thu, 9 Jan 2014 14:21:33 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8B80B206888; Thu, 9 Jan 2014 14:21:33 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s09DKVwf020674; Thu, 9 Jan 2014 14:20:32 +0100 Message-ID: <52CEA21F.20002@gmail.com> Date: Thu, 09 Jan 2014 14:20:31 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Gert Doering References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD70E7.6090406@gmail.com> <20140108172957.GB81676@Space.Net> In-Reply-To: <20140108172957.GB81676@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" , Pete Vickers Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 13:20:45 -0000 Le 08/01/2014 18:29, Gert Doering a écrit : > Hi, > > On Wed, Jan 08, 2014 at 04:38:15PM +0100, Alexandru Petrescu wrote: >> However, discussion whether DHCP-only deployments are possible, in >> theory or otherwise, may not be that mean. Just as we state RA-only >> deployments are the way to be we can also ack that DHCP-only deployments >> do work. > > *They* *do* *not* *work*, unless you add in "manual configuration" or > "other sources of configuration information". Checked that. > DHCPv6-only will give hosts IPv6 addresses that they can not use for > anything. If you add information about on-link prefixes or default > routing to that, from other sources, it's not "DHCP-only deployment". Ok, it would be DHCP+ICMP+NS+NA deployments? Alex > > Gert Doering > -- NetMaster > From swmike@swm.pp.se Thu Jan 9 05:21:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA721AE2CA for ; Thu, 9 Jan 2014 05:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.389 X-Spam-Level: X-Spam-Status: No, score=-4.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skkXCi3Zccn2 for ; Thu, 9 Jan 2014 05:21:44 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 292E31AE2CD for ; Thu, 9 Jan 2014 05:21:44 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id F237E9C; Thu, 9 Jan 2014 14:21:33 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id EEFC89A; Thu, 9 Jan 2014 14:21:33 +0100 (CET) Date: Thu, 9 Jan 2014 14:21:33 +0100 (CET) From: Mikael Abrahamsson To: Alexandru Petrescu In-Reply-To: <52CE9FE4.9050309@gmail.com> Message-ID: References: <52CD7D0C.4010609@gmail.com> <52CD7EE8.9070008@gmail.com> <52CE9FE4.9050309@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 13:21:46 -0000 On Thu, 9 Jan 2014, Alexandru Petrescu wrote: > Alex > PS: about 1G left in your country, I would double check... And I > suppose if they exist they do support data connections with a simple modem. The only 1G network in Sweden that I am aware of is , and it was shut down 2007 according to that article. For me 1G is out of scope as there is extremly little use, and the only volume of usage is on GSM, UMTS and LTE. All these support "native" IPv6 just fine. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Thu Jan 9 05:25:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68481AE2D7 for ; Thu, 9 Jan 2014 05:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vWQhIPhcth0 for ; Thu, 9 Jan 2014 05:25:02 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 332501AE2CD for ; Thu, 9 Jan 2014 05:25:02 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5FE659C; Thu, 9 Jan 2014 14:24:52 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5B19C9A; Thu, 9 Jan 2014 14:24:52 +0100 (CET) Date: Thu, 9 Jan 2014 14:24:52 +0100 (CET) From: Mikael Abrahamsson To: Alexandru Petrescu In-Reply-To: <52CEA1D2.3000109@gmail.com> Message-ID: References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CEA1D2.3000109@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" , Pete Vickers Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 13:25:04 -0000 On Thu, 9 Jan 2014, Alexandru Petrescu wrote: > One would not appreciate an RA to allow an arbitrary Client to configure an > IP address. If one did so, then there is a security risk: the Client is able > to listen at IP level everything else in that network. This is a huge risk. There is nothing stopping you from only using DHCPv6 IA_NA. Just set the A=0,M=1 flags in the RA messages, and clients won't autoconfigure themselves but instead just use DHCPv6 for IA_NA. You then secure this by means of DHCPv6 inspection and automatic installation of antispoofing rules. This has *nothing* to do with if RAs is required for routing or not. In the above solution DHCPv6 is the *only* way a client gets an IPv6 address, and RA is the *only* way it gets a default gateway. This has been a perfectly valid and intended deployment model for 15 years. -- Mikael Abrahamsson email: swmike@swm.pp.se From tore@fud.no Thu Jan 9 05:29:17 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF1F1AE2E2 for ; Thu, 9 Jan 2014 05:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kk-OdNydp_0f for ; Thu, 9 Jan 2014 05:29:16 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) by ietfa.amsl.com (Postfix) with ESMTP id DADEA1AE2CB for ; Thu, 9 Jan 2014 05:29:15 -0800 (PST) Received: from [2a02:c0:2:1:1194:6:0:1002] (port=49811 helo=echo.linpro.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1W1FfU-0000se-QA; Thu, 09 Jan 2014 14:29:04 +0100 Message-ID: <52CEA420.5020305@fud.no> Date: Thu, 09 Jan 2014 14:29:04 +0100 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Alexandru Petrescu , Gert Doering References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CEA1D2.3000109@gmail.com> In-Reply-To: <52CEA1D2.3000109@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Pete Vickers Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 13:29:17 -0000 * Alexandru Petrescu > One would not appreciate an RA to allow an arbitrary Client to configure > an IP address. If one did so, then there is a security risk: the Client > is able to listen at IP level everything else in that network. This is > a huge risk. So set the A flag to 0 in all/any Prefix Information Options included in the RA. Doing so ensures that the clients will not configure an IP address based on RA, as A=0 in a PIO means "no SLAAC for this prefix". If you also set M=1 in the RA, clients will go ask DHCPv6 for an address instead. Problem solved? Tore From alexandru.petrescu@gmail.com Thu Jan 9 05:34:21 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C451C1AE2EE for ; Thu, 9 Jan 2014 05:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phqn3D-jyRZu for ; Thu, 9 Jan 2014 05:34:19 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF381AE2D5 for ; Thu, 9 Jan 2014 05:34:19 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s09DY1ZT017648; Thu, 9 Jan 2014 14:34:01 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 63375206D5F; Thu, 9 Jan 2014 14:35:02 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5245B2068CE; Thu, 9 Jan 2014 14:35:02 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s09DXv3G030545; Thu, 9 Jan 2014 14:34:01 +0100 Message-ID: <52CEA545.5040709@gmail.com> Date: Thu, 09 Jan 2014 14:33:57 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Owen DeLong References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <52CD79EC.9060105@bogus.com> <52CD7BF9.8070104@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" , Pete Vickers Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 13:34:22 -0000 Le 08/01/2014 20:09, Owen DeLong a écrit : >>> >>> Because MAC addresses and host-IDs are really well protected >>> identifiers... >> >> Well yes. >> >> Sure, one knows how to sniff and fake one. And sure as well one >> knows how to identify someone who sniffs in the first place. >> 'Sniffing' to one can be perceived as active attack by someone >> else. >> > > I'm curious... How do you identify someone sniffing your wifi network > from 20 miles away? > > I can understand how you _MIGHT_ detect the forged MAC address, but > detecting the sniffing part has me very curious. Depends whether we talk WiFi or Ethernet... But here is my speculation: For Ethernet it's simple LED on on a port which is marked 'MUST be OFF'. For WiFi it's more complex, but I dont really understand your question. > Do you really believe you can detect someone doing a passive fiber > tap in the middle of one of your long-haul circuits? Do you really > believe that you can detect someone duplicating your traffic off to a > maintenance feed on one of the DACS that the circuit flows through? > > You might be able to detect sniffing in some circumstances, but > reliably detecting it in all circumstances is a hard problem and I > remain unconvinced that it is solved. Right, these things seem hard to do as put above, but on another hand I think these may have been done. Isn't it the same technology used by other people to find where precisely are there bugs in the cable, why is the cable not working, how many other people are on that cable. Send a wavelength and measure the response time. > Most of the time, faking a MAC address doesn't even really require > all that much sniffing. Grab something out of one of the OUIs for > Apple portable devices and you can usually get in to a lot of > places. Well, if one does that in an Enterprise where the Policy is forbidding Apple devices it would surely get noticed. Also, as I said many work environments store precisely the list of MAC addresses allowed to connect. > If that doesn't work, it only takes a few seconds to sniff one. Yes, but that gets noticed: popup. >> No - not everybody trusts certificates and Certificate >> Authorities. Some become CAs without caring that nobody else trusts >> that CA. > > So? So, would 802.1x work? Would RA security SeND work? >> Some big deployers become CA in 2003, last a few years, then revert >> back to pencil and paper security. >> >> Yes - some people do have processes in place that do work well, do >> afford security. >> >> YEs - some of these need to be migrated, but careful with >> security. > > Any security that depends on a "trusted MAC address" or "host > identifier" is the security equivalent of a screen door. Right. Many use that trusted MAC address together with host identifier and additional human-only means to avoid 'screen door' (not sure what that is). That would difficult be achieve with RA only. Alex > > Owen > >> >> Alex >> >>>> I think it would be easier to migrate all that from v4 to v6, >>>> rather than introducing new protocols with their new security >>>> risks. >>>> >>>> Alex >>>> >>>>> >>>>> /Pete _______________________________________________ v6ops >>>>> mailing list v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>> >>>> >>>> >>>> _______________________________________________ v6ops mailing >>>> list v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >>> >>> >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > > From lorenzo@google.com Thu Jan 9 05:35:23 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 690B81AE2EA for ; Thu, 9 Jan 2014 05:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tcq6pIICoT5l for ; Thu, 9 Jan 2014 05:35:22 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 834B71AE2FD for ; Thu, 9 Jan 2014 05:35:16 -0800 (PST) Received: by mail-ig0-f178.google.com with SMTP id ut6so7544185igb.5 for ; Thu, 09 Jan 2014 05:35:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5wdMM/2Cn/5yDBvg+rW5k1qYYbuHViMTSYnPlgA0I8g=; b=bNSeXwPqcLft8lTyLHjy0/U4hD7AzSqgCZscnLB4RFe9JPS6u4iDYJIQl6OziXnRWu YTaBXyz41weKRyrZj+6DMOcGQqpXQLmG0GRd93r7zBMrQJZ3kwKqTONWdceCrVf//L33 DBIjPJUbvSPztYDMOw/LSV1/chCGVAXvjEOFBwd7cwkZEjK22VcyiD8NZNv3OPVrmZjJ YEgeGhnwcNqQ8T2W4F4e3VlP9FPgRDz2+gX6k1KOZO5p06TJD0vDnH2WCozMO6rBgRhE Kpn1rrO2IunzWvODKB3mmoCJBq4Dzht/1w8Jix7thDtv8nDR4Li2THxV1UmmeqfOcYh0 wj9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5wdMM/2Cn/5yDBvg+rW5k1qYYbuHViMTSYnPlgA0I8g=; b=IAMRk6HZDT9bkCVL2UDBau1XsxwxXXBZIcnsWM1NsDb+q/dvvz4k0FaYt25vhJJPWh 5Pe0iLttYOPG/2t7vcznmT96bqjl7Q/y+xv1GR9etZuJIhA+oPeQSoEiYpcvUKN4KF5w hPEn8/75hpFJkUCzauW04UtbxHP7htptszi9/IltP5cIDSG01JqwC8yz9VpJERHOaW74 x4lw6Tm0SzA7iNBkvAqMBRg/qeHOLWFZHlSDHxTrWtgTayrV7H7vWow/aDBA04gPJKkn b3+7ZpRStrzYv1hPHvY7PLbo+ZCx1cHyrF7JLYd1KNkE16J4gzbrU0pYYIOzFXVlePrF kjpA== X-Gm-Message-State: ALoCoQkYcNyHOdouQV0XcGXT+iU7btFB7WQowIuRSTWQNOcrTEuOhvnXX61jyUxru5dJ8Yu2b3OiUc9EuvfFmqV8AyJJAASeqg+o5jPYl1nzTpVkydbEmPIlzq2pmBPrn/iZg0qZJVA7QyP0RqcCE5/dYSNIlPROXq/WMd5vU3Oz/K7512FlK6lCXbsx3gGtajR80GPaT0rQ X-Received: by 10.50.36.67 with SMTP id o3mr3286214igj.47.1389274507017; Thu, 09 Jan 2014 05:35:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Thu, 9 Jan 2014 05:34:46 -0800 (PST) In-Reply-To: <52CEA420.5020305@fud.no> References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CEA1D2.3000109@gmail.com> <52CEA420.5020305@fud.no> From: Lorenzo Colitti Date: Thu, 9 Jan 2014 22:34:46 +0900 Message-ID: To: Tore Anderson Content-Type: multipart/alternative; boundary=089e011601747cb15004ef89ada2 Cc: Pete Vickers , "v6ops@ietf.org" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 13:35:23 -0000 --089e011601747cb15004ef89ada2 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 9, 2014 at 10:29 PM, Tore Anderson wrote: > If you also set M=1 in the RA, clients will go ask DHCPv6 for an address > instead. Problem solved? > The ones that support DHCPv6, yes. --089e011601747cb15004ef89ada2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 9, 2014 at 10:29 PM, Tore Anderson <tore@fud.no> wrote:
If you also set M=3D1 in the RA, clients will go ask DHCPv6 for an address<= br> instead. Problem solved?

The ones that = support DHCPv6, yes.=C2=A0
--089e011601747cb15004ef89ada2-- From alexandru.petrescu@gmail.com Thu Jan 9 06:01:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3381E1AE310 for ; Thu, 9 Jan 2014 06:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkLkXXla5yqs for ; Thu, 9 Jan 2014 06:01:28 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 8136A1AE30F for ; Thu, 9 Jan 2014 06:01:28 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s09E1IgM025431 for ; Thu, 9 Jan 2014 15:01:18 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4A859200C8E for ; Thu, 9 Jan 2014 15:02:19 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 39715200808 for ; Thu, 9 Jan 2014 15:02:19 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s09E1EAK018370 for ; Thu, 9 Jan 2014 15:01:18 +0100 Message-ID: <52CEABAA.1010903@gmail.com> Date: Thu, 09 Jan 2014 15:01:14 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20140109.081911.41687735.sthaug@nethelp.no> In-Reply-To: <20140109.081911.41687735.sthaug@nethelp.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 14:01:30 -0000 Le 09/01/2014 08:19, sthaug@nethelp.no a écrit : >>> What about adding the following? "Thus, for example, if there is no RA >>> and no static routing, then addresses assigned by DHCPv6 cannot be used >>> even for communication between hosts on the same link." >> >> Fine by me! > > Agree, this sounds good. It sounds reasonable, but not as close as it could get. Alex > > Steinar Haug, AS2116 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From alexandru.petrescu@gmail.com Thu Jan 9 06:20:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793CE1AE334 for ; Thu, 9 Jan 2014 06:20:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EC7CeM8BJhtW for ; Thu, 9 Jan 2014 06:20:26 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id F30CA1AE07F for ; Thu, 9 Jan 2014 06:20:25 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s09EKFBw004980; Thu, 9 Jan 2014 15:20:15 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D8C91206C45; Thu, 9 Jan 2014 15:21:16 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C2447200C80; Thu, 9 Jan 2014 15:21:16 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s09EKCjT001237; Thu, 9 Jan 2014 15:20:15 +0100 Message-ID: <52CEB01C.3090809@gmail.com> Date: Thu, 09 Jan 2014 15:20:12 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <52CD7D0C.4010609@gmail.com> <52CD7EE8.9070008@gmail.com> <52CE9FE4.9050309@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 14:20:28 -0000 Le 09/01/2014 14:21, Mikael Abrahamsson a écrit : > On Thu, 9 Jan 2014, Alexandru Petrescu wrote: > >> Alex PS: about 1G left in your country, I would double check... >> And I suppose if they exist they do support data connections with a >> simple modem. > > The only 1G network in Sweden that I am aware of is > , and it was > shut down 2007 according to that article. Well, thank you for the info, that is good to know. I guess though older links are still in use there. > For me 1G is out of scope as there is extremly little use, and the > only volume of usage is on GSM, UMTS and LTE. All these support > "native" IPv6 just fine. YEs. New IoT operators may run on IPv6 on CSD lines of GSM (w/o native IPv6 on the other side). Or may not. Alex > From alexandru.petrescu@gmail.com Thu Jan 9 06:28:16 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759431AE33F for ; Thu, 9 Jan 2014 06:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74oC_XJBWa0Z for ; Thu, 9 Jan 2014 06:28:14 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 861351AE325 for ; Thu, 9 Jan 2014 06:28:14 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s09ES2wa004892; Thu, 9 Jan 2014 15:28:02 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8FDD1206D51; Thu, 9 Jan 2014 15:29:03 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7649D200C8E; Thu, 9 Jan 2014 15:29:03 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s09ERwN4007314; Thu, 9 Jan 2014 15:28:02 +0100 Message-ID: <52CEB1EE.1070708@gmail.com> Date: Thu, 09 Jan 2014 15:27:58 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Tore Anderson , Gert Doering References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CEA1D2.3000109@gmail.com> <52CEA420.5020305@fud.no> In-Reply-To: <52CEA420.5020305@fud.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" , Pete Vickers Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 14:28:16 -0000 Le 09/01/2014 14:29, Tore Anderson a écrit : > * Alexandru Petrescu > >> One would not appreciate an RA to allow an arbitrary Client to >> configure an IP address. If one did so, then there is a security >> risk: the Client is able to listen at IP level everything else in >> that network. This is a huge risk. > > So set the A flag to 0 in all/any Prefix Information Options included > in the RA. Doing so ensures that the clients will not configure an > IP address based on RA, as A=0 in a PIO means "no SLAAC for this > prefix". > > If you also set M=1 in the RA, clients will go ask DHCPv6 for an > address instead. Problem solved? That part of problem seems solved. But why should there be a PIO in the RA if nobody is allowed to use it anyway for configuring an address? Noise? And still there may be a problem in the publicizing the address of the Default Router as src in the RA. Alex > > Tore > > From alexandru.petrescu@gmail.com Thu Jan 9 06:32:02 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DB01AE35A for ; Thu, 9 Jan 2014 06:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QW4YDEAR0A3g for ; Thu, 9 Jan 2014 06:32:01 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id EB3BB1AE33F for ; Thu, 9 Jan 2014 06:32:00 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s09EVoNp010657; Thu, 9 Jan 2014 15:31:50 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DD2A7206DC5; Thu, 9 Jan 2014 15:32:51 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C32DD206DA1; Thu, 9 Jan 2014 15:32:51 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s09EVo4F010954; Thu, 9 Jan 2014 15:31:50 +0100 Message-ID: <52CEB2D6.9070608@gmail.com> Date: Thu, 09 Jan 2014 15:31:50 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CEA1D2.3000109@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" , Pete Vickers Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 14:32:03 -0000 Le 09/01/2014 14:24, Mikael Abrahamsson a écrit : > On Thu, 9 Jan 2014, Alexandru Petrescu wrote: > >> One would not appreciate an RA to allow an arbitrary Client to >> configure an IP address. If one did so, then there is a security >> risk: the Client is able to listen at IP level everything else in that >> network. This is a huge risk. > > There is nothing stopping you from only using DHCPv6 IA_NA. Just set the > A=0,M=1 flags in the RA messages, and clients won't autoconfigure > themselves but instead just use DHCPv6 for IA_NA. You then secure this > by means of DHCPv6 inspection and automatic installation of antispoofing > rules. > > This has *nothing* to do with if RAs is required for routing or not. > > In the above solution DHCPv6 is the *only* way a client gets an IPv6 > address, and RA is the *only* way it gets a default gateway. This has > been a perfectly valid and intended deployment model for 15 years. As you put it reads as only a tool for one purpose. Sounds natural and good to follow. But there's a error. Because RA also leads to auto-configuring an address (unless A). One would have to say: DHCPv6 is the *only* way a client gets an IPv6 address (with exception A), and RA is the *only* way it gets a default gateway (with exception B). Alex Alex > From swmike@swm.pp.se Thu Jan 9 06:33:27 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1E81AE351 for ; Thu, 9 Jan 2014 06:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCqE9h6ZsWZm for ; Thu, 9 Jan 2014 06:33:24 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id A9EE71AE350 for ; Thu, 9 Jan 2014 06:33:24 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 4C1109C; Thu, 9 Jan 2014 15:33:14 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 458949A; Thu, 9 Jan 2014 15:33:14 +0100 (CET) Date: Thu, 9 Jan 2014 15:33:14 +0100 (CET) From: Mikael Abrahamsson To: Alexandru Petrescu In-Reply-To: <52CEB1EE.1070708@gmail.com> Message-ID: References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CEA1D2.3000109@gmail.com> <52CEA420.5020305@fud.no> <52CEB1EE.1070708@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" , Pete Vickers Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 14:33:27 -0000 On Thu, 9 Jan 2014, Alexandru Petrescu wrote: > But why should there be a PIO in the RA if nobody is allowed to use it > anyway for configuring an address? Noise? RA is used for routing. The only mechanism that can configure routing is RA. Both DHCPv6 and RA can be used for deciding addressing policy. RA can indicate to hosts that it should point a default-route or more-specific routes towards a certain router. DHCPv6 cannot do this. > And still there may be a problem in the publicizing the address of the > Default Router as src in the RA. Why? -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Thu Jan 9 06:34:59 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF561AE30F for ; Thu, 9 Jan 2014 06:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TC_HepbNYjQ for ; Thu, 9 Jan 2014 06:34:58 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id D937F1AE2E3 for ; Thu, 9 Jan 2014 06:34:57 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 152799C; Thu, 9 Jan 2014 15:34:48 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0E7F29A; Thu, 9 Jan 2014 15:34:48 +0100 (CET) Date: Thu, 9 Jan 2014 15:34:48 +0100 (CET) From: Mikael Abrahamsson To: Alexandru Petrescu In-Reply-To: <52CEB2D6.9070608@gmail.com> Message-ID: References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CEA1D2.3000109@gmail.com> <52CEB2D6.9070608@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-1981639454-1389278073=:20074" Cc: "v6ops@ietf.org" , Pete Vickers Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 14:34:59 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-1981639454-1389278073=:20074 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; FORMAT=flowed Content-Transfer-Encoding: 8BIT On Thu, 9 Jan 2014, Alexandru Petrescu wrote: > Le 09/01/2014 14:24, Mikael Abrahamsson a écrit : >> >> There is nothing stopping you from only using DHCPv6 IA_NA. Just set the >> A=0,M=1 flags in the RA messages, and clients won't autoconfigure > > But there's a error. > > Because RA also leads to auto-configuring an address (unless A). I wrote A=0. What's the error? > One would have to say: > > DHCPv6 is the *only* way a client gets an IPv6 address (with exception A), > and RA is the *only* way it gets a default gateway (with exception B). If A=0, then DHCPv6 is the only wau to get an address, yes. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1981639454-1389278073=:20074-- From tore@fud.no Thu Jan 9 06:41:25 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CD51AE36B for ; Thu, 9 Jan 2014 06:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3-kvA0MLIWl for ; Thu, 9 Jan 2014 06:41:24 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2AA1AE338 for ; Thu, 9 Jan 2014 06:41:24 -0800 (PST) Received: from [2a02:c0:2:1:1194:6:0:1002] (port=51102 helo=echo.linpro.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1W1GnI-0005sA-SW; Thu, 09 Jan 2014 15:41:12 +0100 Message-ID: <52CEB508.7080108@fud.no> Date: Thu, 09 Jan 2014 15:41:12 +0100 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Alexandru Petrescu , Gert Doering References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CEA1D2.3000109@gmail.com> <52CEA420.5020305@fud.no> <52CEB1EE.1070708@gmail.com> In-Reply-To: <52CEB1EE.1070708@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Pete Vickers Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 14:41:26 -0000 * Alexandru Petrescu > But why should there be a PIO in the RA if nobody is allowed to use it > anyway for configuring an address? Noise? If L=1 is set in the PIO, then the host gets to configure a on-link route to the prefix in question. So say you have an RA: M=1 PIO 2001:db8::/124 (A=0, L=1), you may use DHCPv6 to configure hosts A and B to have addresses 2001:db8::A and 2001:db8::A (assuming they support DHCPv6 to begin with of course) The PIO with L=1 tells the hosts to install a direct interface route to 2001:db8::/124 on the interface they received the RA. This means 2001:db8::A may communicate directly with 2001:db8::B without their traffic passing through the router (they'd need use NS/NA to discover each other's MAC address first though, not unlinke ARP in IPv4). [Side note: A PIO with both A and L flags set to zero is meaningless and might as well be dropped entirely. In this case 2001:db8::A and 2008:db8::B could still communicate, but traffic would pass through the router. This is actually useful in NBMA networks, like DOCSIS. My ISP sends me PIO-less RAs and provides me with addresses only through DHCPv6 (IA_NA & IA_PD). If I want to communicate with my neighbour, traffic needs to first pass through my ISP's CMTS.] > And still there may be a problem in the publicizing the address of the > Default Router as src in the RA. If you don't want the RA originator to appear as the next-hop of a default route on the hosts, you simply set the Router Lifetime field to 0. The hosts could still then communicate with each other (thanks to the L=1 PIO), but wouldn't then have any way off the link unless you give it to them some other way (manual/static config, use of subnet-router anycast, puppet, etc.) Tore From alexandru.petrescu@gmail.com Thu Jan 9 06:48:50 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACE41AE37B for ; Thu, 9 Jan 2014 06:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.383 X-Spam-Level: X-Spam-Status: No, score=-4.383 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_24=0.6, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kIjPAWNd-Wo for ; Thu, 9 Jan 2014 06:48:48 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id B6C271AE338 for ; Thu, 9 Jan 2014 06:48:47 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s09Emb3w012697; Thu, 9 Jan 2014 15:48:37 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A2372206D75; Thu, 9 Jan 2014 15:49:38 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9471D206C8B; Thu, 9 Jan 2014 15:49:38 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s09EmXJQ023712; Thu, 9 Jan 2014 15:48:37 +0100 Message-ID: <52CEB6C1.8050105@gmail.com> Date: Thu, 09 Jan 2014 15:48:33 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CEA1D2.3000109@gmail.com> <52CEA420.5020305@fud.no> <52CEB1EE.1070708@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" , Pete Vickers Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 14:48:50 -0000 Le 09/01/2014 15:33, Mikael Abrahamsson a écrit : > On Thu, 9 Jan 2014, Alexandru Petrescu wrote: > >> But why should there be a PIO in the RA if nobody is allowed to use >> it anyway for configuring an address? Noise? > > RA is used for routing. Well, that's a principle put very briefly, but in details one may notice that RA is used for other less-routingly aspects such as MTU which is a pure local variable. (and which DHCP doesnt do either). > The only mechanism that can configure routing is RA. Well, as you discuss, it reads head-on with a routing protocol... Many say that it is not that good for RA to configure routing. Actually, if you take your statement that RA is used to configure routing and extend it to new work at IETF, you'd realize that RA is claimed to do routing which is actually very little of more real routing. RA does routing without computing shortest paths, without avoiding loops, without avoiding split horizon, without converging, without exchanging route databases, etc. > Both DHCPv6 and RA can be used for deciding addressing policy. Well, not both; it looks more as now RA can decide the addressing policy whereas DHCP only executes (these M/O flags). > RA can indicate to hosts that it should point a default-route or > more-specific routes towards a certain router. Yes it can. But I wonder whether it knows what it does. Or is it somebody else that must think on its belhalf and update some policy on it from a remote control location? Something like what is done with updating DHCP databases, in IPv4. > DHCPv6 cannot do this. Right, currently DHCPv6 can not communicate a default router or a more specific route to the Client. If it did, then it'd take advantage of all the existing software tools which help it make informed decisions, inherited from IPv4. >> And still there may be a problem in the publicizing the address of >> the Default Router as src in the RA. > > Why? Because there is a risk in diligently allowing maps to be built about important routers in some area. Just as there is a risk in allowing maps of BSSIDs and MAC addresses of Access Points in some area and why networks are 'hidden' by not always advertising important data. YEs, these ids could be found by active scanning as well (WiFi Probe Requests, Router Solicitations, DHCPv6 Solicitations); but active scanning is an observable operation which can be filtered early. And yes, you are right that the existing RA+DHCP mechanics have a sense and seem to follow. Alex > From tjc@ecs.soton.ac.uk Thu Jan 9 06:49:35 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927621AE351 for ; Thu, 9 Jan 2014 06:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.759 X-Spam-Level: X-Spam-Status: No, score=-1.759 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_gwrLCBLMsB for ; Thu, 9 Jan 2014 06:49:32 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id BA4681AE393 for ; Thu, 9 Jan 2014 06:49:31 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s09EnGL1024694; Thu, 9 Jan 2014 14:49:16 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s09EnGL1024694 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1389278956; bh=LJqClrdX9y/kGtuHKdWa5gJxv0g=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=ANzhx4JWvg7+zGaXpDLWBAktoSbjbfZ4C4k/KHkNc6poNQ8kMH6F7qdoUwegPaTQ0 2oDRpBNenBr9WrWxYP0sHM/jZzPtKeklgsCawoROFbIebL/HT3QNxx9Au28UZXmlNh YP+jxdY1g5vhwPNFvQbzvwT7ELKuc9LR7k5AtjJY= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id q08EnG0959654806rK ret-id none; Thu, 09 Jan 2014 14:49:16 +0000 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s09EnEbQ029281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jan 2014 14:49:14 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Tim Chown In-Reply-To: Date: Thu, 9 Jan 2014 14:49:19 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CEA1D2.3000109@gmail.com> <52CEA420.5020305@fud.no> <52CEB1EE.1070708@gmail.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1510) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q08EnG095965480600; tid=q08EnG0959654806rK; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s09EnGL1024694 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: Pete Vickers , "v6ops@ietf.org" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 14:49:35 -0000 On 9 Jan 2014, at 14:33, Mikael Abrahamsson wrote: > On Thu, 9 Jan 2014, Alexandru Petrescu wrote: >=20 >> But why should there be a PIO in the RA if nobody is allowed to use = it anyway for configuring an address? Noise? >=20 > RA is used for routing. The only mechanism that can configure routing = is RA. Both DHCPv6 and RA can be used for deciding addressing policy. >=20 > RA can indicate to hosts that it should point a default-route or = more-specific routes towards a certain router. DHCPv6 cannot do this. Well, RFC7078 can influence address selection which, if routing within a = site is based on both src and dst (as has been demonstrated in simple = homenet scenarios), can allow traffic to pass out through the preferred = exit router. Tim= From alexandru.petrescu@gmail.com Thu Jan 9 06:50:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3191AE39C for ; Thu, 9 Jan 2014 06:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNB4AxB9sEnU for ; Thu, 9 Jan 2014 06:50:27 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id D8FBB1AE364 for ; Thu, 9 Jan 2014 06:50:26 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s09EoGbB013425; Thu, 9 Jan 2014 15:50:16 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9BCCB206C8B; Thu, 9 Jan 2014 15:51:17 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 82130206DC8; Thu, 9 Jan 2014 15:51:17 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s09EoFVV025117; Thu, 9 Jan 2014 15:50:16 +0100 Message-ID: <52CEB727.1050701@gmail.com> Date: Thu, 09 Jan 2014 15:50:15 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CEA1D2.3000109@gmail.com> <52CEB2D6.9070608@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" , Pete Vickers Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 14:50:28 -0000 Le 09/01/2014 15:34, Mikael Abrahamsson a écrit : > On Thu, 9 Jan 2014, Alexandru Petrescu wrote: > >> Le 09/01/2014 14:24, Mikael Abrahamsson a écrit : >>> >>> There is nothing stopping you from only using DHCPv6 IA_NA. Just >>> set the A=0,M=1 flags in the RA messages, and clients won't >>> autoconfigure >> >> But there's a error. >> >> Because RA also leads to auto-configuring an address (unless A). > > I wrote A=0. What's the error? > >> One would have to say: >> >> DHCPv6 is the *only* way a client gets an IPv6 address (with >> exception A), and RA is the *only* way it gets a default gateway >> (with exception B). > > If A=0, then DHCPv6 is the only wau to get an address, yes. Right. And what's the bit such that DHCPv6 be the only way to get routing information? Alex > From swmike@swm.pp.se Thu Jan 9 06:52:55 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A061AE3AA for ; Thu, 9 Jan 2014 06:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5klSaKqghH0s for ; Thu, 9 Jan 2014 06:52:54 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 3727A1AE191 for ; Thu, 9 Jan 2014 06:52:54 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 6041B9C; Thu, 9 Jan 2014 15:52:44 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 595E49A; Thu, 9 Jan 2014 15:52:44 +0100 (CET) Date: Thu, 9 Jan 2014 15:52:44 +0100 (CET) From: Mikael Abrahamsson To: Alexandru Petrescu In-Reply-To: <52CEB727.1050701@gmail.com> Message-ID: References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CEA1D2.3000109@gmail.com> <52CEB2D6.9070608@gmail.com> <52CEB727.1050701@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 14:52:55 -0000 On Thu, 9 Jan 2014, Alexandru Petrescu wrote: >> If A=0, then DHCPv6 is the only wau to get an address, yes. > > Right. > > And what's the bit such that DHCPv6 be the only way to get routing > information? I don't understand this statement/question. Please re-phrase. -- Mikael Abrahamsson email: swmike@swm.pp.se From alexandru.petrescu@gmail.com Thu Jan 9 07:01:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47481AE3BD for ; Thu, 9 Jan 2014 07:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.383 X-Spam-Level: X-Spam-Status: No, score=-4.383 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_42=0.6, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k00YdsqIsnv9 for ; Thu, 9 Jan 2014 07:01:53 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 776B31AE3B9 for ; Thu, 9 Jan 2014 07:01:53 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s09F1ftV016785; Thu, 9 Jan 2014 16:01:41 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9AFAB206C8B; Thu, 9 Jan 2014 16:02:42 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8ADCF200C8E; Thu, 9 Jan 2014 16:02:42 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s09F1eZH002586; Thu, 9 Jan 2014 16:01:41 +0100 Message-ID: <52CEB9D4.1040509@gmail.com> Date: Thu, 09 Jan 2014 16:01:40 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Tore Anderson , Gert Doering References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CEA1D2.3000109@gmail.com> <52CEA420.5020305@fud.no> <52CEB1EE.1070708@gmail.com> <52CEB508.7080108@fud.no> In-Reply-To: <52CEB508.7080108@fud.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" , Pete Vickers Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 15:01:55 -0000 Le 09/01/2014 15:41, Tore Anderson a écrit : > * Alexandru Petrescu > >> But why should there be a PIO in the RA if nobody is allowed to >> use it anyway for configuring an address? Noise? > > If L=1 is set in the PIO, then the host gets to configure a on-link > route to the prefix in question. > > So say you have an RA: M=1 PIO 2001:db8::/124 (A=0, L=1), you may use > DHCPv6 to configure hosts A and B to have addresses 2001:db8::A and > 2001:db8::A (assuming they support DHCPv6 to begin with of course) > > The PIO with L=1 tells the hosts to install a direct interface route > to 2001:db8::/124 on the interface they received the RA. Why should it be so? The prefix length of the IPv6 address delivered by DHCPv6 should be delivered by... DHCPv6. With that the Client could install the 'on-link' or 'connected' route. No? > This means 2001:db8::A may communicate directly with 2001:db8::B > without their traffic passing through the router (they'd need use > NS/NA to discover each other's MAC address first though, not unlinke > ARP in IPv4). Right. And this can be realized with DHCPv6 providing the prefix length, and then Client do NS/NA. > [Side note: A PIO with both A and L flags set to zero is meaningless > and might as well be dropped entirely. In this case 2001:db8::A and > 2008:db8::B could still communicate, but traffic would pass through > the router. This is actually useful in NBMA networks, like DOCSIS. > My ISP sends me PIO-less RAs and provides me with addresses only > through DHCPv6 (IA_NA & IA_PD). If I want to communicate with my > neighbour, traffic needs to first pass through my ISP's CMTS.] I agree with you in some sense where some combination of A and L bits of RA's PIO may make little sense. Especially because they're so different than IPv4. (IPv4 RAs like RFC1256). >> And still there may be a problem in the publicizing the address of >> the Default Router as src in the RA. > > If you don't want the RA originator to appear as the next-hop of a > default route on the hosts, you simply set the Router Lifetime field > to 0. Yes, I agree. But an RA without PIO and a reset Router Lifetime would make little sense other than suggesting an attacker that is a candidate of being the default router. The address of the default router is in the src field of that RA. > The hosts could still then communicate with each other (thanks to the > L=1 PIO), but wouldn't then have any way off the link unless you give > it to them some other way (manual/static config, use of subnet-router > anycast, puppet, etc.) Ok. I understand you and you explain well. The DHCP+RA mechanics do work for some purposes, but not for all. As of now, they're still a manner to unsecurely advertise information, mandatory everywhere. Alex > > Tore > > > From swmike@swm.pp.se Thu Jan 9 07:06:10 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3143B1AE386 for ; Thu, 9 Jan 2014 07:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.789 X-Spam-Level: X-Spam-Status: No, score=-3.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNf3tCrhh_BV for ; Thu, 9 Jan 2014 07:06:09 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id E63801AE30B for ; Thu, 9 Jan 2014 07:06:08 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0BF9D9C; Thu, 9 Jan 2014 16:05:59 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 00A6C9A; Thu, 9 Jan 2014 16:05:58 +0100 (CET) Date: Thu, 9 Jan 2014 16:05:58 +0100 (CET) From: Mikael Abrahamsson To: Alexandru Petrescu In-Reply-To: <52CEB9D4.1040509@gmail.com> Message-ID: References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CEA1D2.3000109@gmail.com> <52CEA420.5020305@fud.no> <52CEB1EE.1070708@gmail.com> <52CEB508.7080108@fud.no> <52CEB9D4.1040509@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" , Tore Anderson , Pete Vickers Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 15:06:10 -0000 On Thu, 9 Jan 2014, Alexandru Petrescu wrote: > Why should it be so? Becase that is how it was designed. > The prefix length of the IPv6 address delivered by DHCPv6 should be > delivered by... DHCPv6. With that the Client could install the > 'on-link' or 'connected' route. Nope, DHCPv6 hands out /128. Addresses. Not networks, not routing. Addresses. By design. > I understand you and you explain well. The DHCP+RA mechanics do work > for some purposes, but not for all. As of now, they're still a manner > to unsecurely advertise information, mandatory everywhere. Why are they less secure than DHCPv6? -- Mikael Abrahamsson email: swmike@swm.pp.se From alexandru.petrescu@gmail.com Thu Jan 9 07:06:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4271AE3BD for ; Thu, 9 Jan 2014 07:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdXDsxZ3FcFy for ; Thu, 9 Jan 2014 07:06:53 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id C580A1AE386 for ; Thu, 9 Jan 2014 07:06:52 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s09F6gN1025317; Thu, 9 Jan 2014 16:06:42 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CEE0A206E43; Thu, 9 Jan 2014 16:07:43 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BCB34206E54; Thu, 9 Jan 2014 16:07:43 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s09F6giO007261; Thu, 9 Jan 2014 16:06:42 +0100 Message-ID: <52CEBB02.7050000@gmail.com> Date: Thu, 09 Jan 2014 16:06:42 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CEA1D2.3000109@gmail.com> <52CEB2D6.9070608@gmail.com> <52CEB727.1050701@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 15:06:55 -0000 Le 09/01/2014 15:52, Mikael Abrahamsson a écrit : > On Thu, 9 Jan 2014, Alexandru Petrescu wrote: > >>> If A=0, then DHCPv6 is the only wau to get an address, yes. >> >> Right. >> >> And what's the bit such that DHCPv6 be the only way to get routing >> information? > > I don't understand this statement/question. Please re-phrase. I meant to say it would be good to have - a RA bit to state that DHCPv6 is the only way to get routing information (as there is a bit to state that DHCP is the only way to get an address.) - a DHCPv6 bit to state that the Client should use RA to auto-configure an address (as there is a RA bit to state to use DHCP to auto-configure an address). Alex From alexandru.petrescu@gmail.com Thu Jan 9 07:17:37 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A801AE3D8 for ; Thu, 9 Jan 2014 07:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.383 X-Spam-Level: X-Spam-Status: No, score=-4.383 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_42=0.6, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFeYRadBTRtC for ; Thu, 9 Jan 2014 07:17:36 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id A9E251AE3D7 for ; Thu, 9 Jan 2014 07:17:35 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s09FHNUP022942; Thu, 9 Jan 2014 16:17:23 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7D1E8206E15; Thu, 9 Jan 2014 16:18:24 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 69D00206DEB; Thu, 9 Jan 2014 16:18:24 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s09FHJY2016368; Thu, 9 Jan 2014 16:17:23 +0100 Message-ID: <52CEBD7F.4020602@gmail.com> Date: Thu, 09 Jan 2014 16:17:19 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CEA1D2.3000109@gmail.com> <52CEA420.5020305@fud.no> <52CEB1EE.1070708@gmail.com> <52CEB508.7080108@fud.no> <52CEB9D4.1040509@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" , Tore Anderson , Pete Vickers Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 15:17:37 -0000 Le 09/01/2014 16:05, Mikael Abrahamsson a écrit : > On Thu, 9 Jan 2014, Alexandru Petrescu wrote: > >> Why should it be so? > > Becase that is how it was designed. > >> The prefix length of the IPv6 address delivered by DHCPv6 should be >> delivered by... DHCPv6. With that the Client could install the >> 'on-link' or 'connected' route. > > Nope, DHCPv6 hands out /128. Addresses. Not networks, not routing. > Addresses. By design. I will not say that is wrong design, but one may imagine what I think about it when comparing to DHCPv4. And I'll get back wondering what to tell customer about migrating to IPv6? Just like IPv4 plus a few bits? It's huge bits... >> I understand you and you explain well. The DHCP+RA mechanics do >> work for some purposes, but not for all. As of now, they're still >> a manner to unsecurely advertise information, mandatory >> everywhere. > > Why are they less secure than DHCPv6? Because if a DHCPv6 server received a hypothetical request about the Default Router it may compare the src MAC address against of pre-established list, and may reply 'No Such Number'. Whereas RA multicasts it to anyone without being asked. And yes, there may be a question of comparing RA security (SeND) against DHCPv6 security and we could discuss that separately if you wish. Alex > From nick@inex.ie Thu Jan 9 08:01:57 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0321ADF7D for ; Thu, 9 Jan 2014 08:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHSQRLaLb-EX for ; Thu, 9 Jan 2014 08:01:55 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 256371ACC81 for ; Thu, 9 Jan 2014 08:01:54 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::126]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id s09G1dWk086689 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 9 Jan 2014 16:01:40 GMT (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::126] claimed to be cupcake.foobar.org Message-ID: <52CEC7E4.8060103@inex.ie> Date: Thu, 09 Jan 2014 16:01:40 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Lorenzo Colitti , Mikael Abrahamsson References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7@nkgeml506-mbx.china.huawei.com> In-Reply-To: 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: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org, "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 16:01:57 -0000 On 09/01/2014 07:12, Lorenzo Colitti wrote: > What about adding the following? "Thus, for example, if there is no RA and > no static routing, then addresses assigned by DHCPv6 cannot be used even > for communication between hosts on the same link." Lorenzo, Can you provide a reference for the assumption that the host will define the netmask to be /128 if it receives an address assignment from DHCPv6 without a specific subnet mask assignment via RA? Nick From Fred.L.Templin@boeing.com Thu Jan 9 08:55:19 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1BC1ADFA2 for ; Thu, 9 Jan 2014 08:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4AA8Qi6xrf8 for ; Thu, 9 Jan 2014 08:55:17 -0800 (PST) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 1256F1ADEBB for ; Thu, 9 Jan 2014 08:55:17 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s09Gt7Sc005470; Thu, 9 Jan 2014 10:55:07 -0600 Received: from XCH-PHX-212.sw.nos.boeing.com (xch-phx-212.sw.nos.boeing.com [130.247.25.141]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s09Gt5c1005457 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 9 Jan 2014 10:55:06 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.203]) by XCH-PHX-212.sw.nos.boeing.com ([169.254.12.8]) with mapi id 14.03.0158.001; Thu, 9 Jan 2014 08:55:05 -0800 From: "Templin, Fred L" To: Mark ZZZ Smith , Randy Bush , Ted Lemon Thread-Topic: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet) Thread-Index: AQHPDSKElDFPtBy1ak+oH31lDGSyjpp8jTAg Date: Thu, 9 Jan 2014 16:55:04 +0000 Message-ID: <2134F8430051B64F815C691A62D98318193C5C@XCH-BLV-504.nw.nos.boeing.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> <20140107104001.GM81676@Space.Net> <72626BC4-CB9E-49E8-8A54-48A141F52C0C@nominum.com> <6A64F619-4A0E-423A-A5E7-4C3234B461AE@nominum.com> <1389261993.72423.YahooMailNeo@web161906.mail.bf1.yahoo.com> In-Reply-To: <1389261993.72423.YahooMailNeo@web161906.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 16:55:19 -0000 Hi Mark, In our enterprise we are seeing an emerging network-layer "killer app" for IPv6; namely, the deployment of mobile multi-access end user devices that need to maintain a stable IP address or subnet. These devices are commonly tablets or handsets of various manufacturers that have wireless access technologies that get (re)assigned different access addresses as they move around, and so tunneling is needed to maintain stable end-user addresses. As the number of mobile devices grows, the end user addresses assigned to mobiles would soon exhaust and fragment the RFC1918 space - hence the need for IPv6. But, we only see a need to deploy IPv6 on the mobiles themselves and we do not necessarily see a need to upgrade the entire enterprise routing structure to IPv6. Think of the tablet/handset as a miniature "mobile router" - a device that should be able to connect up its own applications plus any number of additional end user devices (Internet connection sharing). The mobile router gets an IPv6 prefix (/64 or shorter), and a routing system inside the enterprise network tracks the mobiles as they move around. What I am describing is AERO: http://tools.ietf.org/html/draft-templin-aerolink Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark ZZZ Smith > Sent: Thursday, January 09, 2014 2:07 AM > To: Randy Bush; Ted Lemon > Cc: v6ops@ietf.org > Subject: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they d= idn't IPv4, IPX, XNS, or > DECNet) > ----- Original Message ----- > > From: Randy Bush > > To: Ted Lemon > > Cc: "v6ops@ietf.org" > > Sent: Thursday, 9 January 2014 8:57 AM > > Subject: Re: [v6ops] New Version Notification for=A0=A0=A0 draft-yourtc= henko-ra-dhcpv6-comparison-00.txt > (fwd) > > > >>>=A0 if we want them to deploy ipv6, as opposed to more rfc1918 space, = then > >>>=A0 we need to remove all speed bumps.=A0 not discuss them.=A0 not tel= l them > >>>=A0 that RA is the true religion.=A0 frelling remove the speed bump. > >> > >>=A0 Can you name a specific speed bump?=A0 I've been listening to this > >>=A0 conversation for eight years too, and have yet to hear one named.= =A0 You > >>=A0 seem to be saying that RA is the speed bump, but that's not specifi= c. > >>=A0 What is it about RA that "they" need changed? > > > > the missing dhcp function, exit router > > >=20 >=20 > I don't think this is really true at all. What motivates an enterprise to= deploy a new technology is > primarily what it does for the enterprise, not specific features of it. >=20 > In the early 1990s, enterprises didn't deploy IPX for IPX's sake. They di= dn't say, "We want IPX." They > said, "We want to be able to share files and printers, because it is chea= per than floppy disks and > sneakernet, and buying everybody individual printers." If they chose Nove= ll Netware to share files and > printers, they then deployed IPX because Novell Netware required it. Thos= e who chose Banyan Vines for > file and print sharing deployed the Banyan Vines protocol instead. >=20 > In the middle to late 1990s, enterprises didn't deploy IPv4 for IPv4's sa= ke.=A0=A0They didn't say, "We > want IPv4." They said, "We want to be able to email other organisations a= nd be able to access the WWW, > because we can email customers and suppliers more quickly than using slow= er fax and snail mail, and > access information useful to our business on the Internet." They then nee= ded IPv4 to do that, so they > deployed IPv4 (and wondered why it all had to be so hard with address cla= sses, subnet masks and > default gateways, compared to deploying and operating turn-key IPX.) >=20 > For most enterprises, other than those that make their money from informa= tion technology (like the > ones that most people on this mailing list work for), technology is a "ne= cessary evil" to support > their actual business of making some other type of widget. It is a cost t= hat takes away from the > larger profit they could make on their widgets. If they can reduce those = costs, or even eliminate > them, they will, because that increases their widget profit. >=20 > So a new technology has to either save the enterprise money or make the e= nterprise money for it to be > justified. >=20 > The "killer app" for IPv6 for an enterprise is one that exclusively opera= tes over IPv6 (instead of > over their already deployed IPv4) _and_ makes or saves them money. Some e= nterprises may never > encounter an IPv6-only application that does this, so they may never have= an incentive to deploy it on > their network. They may wish to have access to the IPv6 Internet eventual= ly, but all that might mean > is IPv6 enabling the external interface of their corporate policy enforci= ng web proxy, reached over > RFC1918 IPv4. >=20 > Change IPv6 as much as people want, but if it isn't possible to identify = how it, or the applications > that exclusively run over it will save or make them money, enterprises wi= ll ignore it. More change and > more options to it will only increase it's deployment costs, further incr= easing the barrier it has to > jump before it saves or makes an enterprise money. >=20 >=20 > Regards, > Mark. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From tjc@ecs.soton.ac.uk Thu Jan 9 09:05:16 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C87E1ADF96 for ; Thu, 9 Jan 2014 09:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.758 X-Spam-Level: X-Spam-Status: No, score=-1.758 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnvZ7H2SuMyR for ; Thu, 9 Jan 2014 09:05:14 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 695911AD8D5 for ; Thu, 9 Jan 2014 09:05:13 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s09H4xWl006844; Thu, 9 Jan 2014 17:04:59 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s09H4xWl006844 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1389287100; bh=7KQViICt98JBAoicfIn6cJT2nj8=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=xutMJZOn5F23nEQFUy1SG6H4Gnnacib4W+u1Dwx4KHIEK14XTv2IiyJYRZIEHwjoH bVjnKJzm6heBg8egZQRVEgaw5w5GpjxoHux7dtyCpuzRiAIyurJzeZplM13m9FP6Hv PqK+J7hY78LubTtviA0tnq3I8Ab9f6KAlEFrDMnA= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id q08H4x0959656420aj ret-id none; Thu, 09 Jan 2014 17:04:59 +0000 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s09H4tmc006563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jan 2014 17:04:55 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_B419BE13-3D0D-402D-8BCF-9F5BA9580B67" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Tim Chown In-Reply-To: <2134F8430051B64F815C691A62D98318193C5C@XCH-BLV-504.nw.nos.boeing.com> Date: Thu, 9 Jan 2014 17:04:59 +0000 Message-ID: References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> <20140107104001.GM81676@Space.Net> <72626BC4-CB9E-49E8-8A54-48A141F52C0C@nominum.com> <6A64F619-4A0E-423A-A5E7-4C3234B461AE@nominum.com> <1389261993.72423.YahooMailNeo@web161906.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D98318193C5C@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1510) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q08H4x095965642000; tid=q08H4x0959656420aj; client=relay,ipv6; mail=; rcpt=; nrcpt=5:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s09H4xWl006844 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 17:05:16 -0000 --Apple-Mail=_B419BE13-3D0D-402D-8BCF-9F5BA9580B67 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, On 9 Jan 2014, at 16:55, "Templin, Fred L" = wrote: > Hi Mark, >=20 > In our enterprise we are seeing an emerging network-layer "killer app" > for IPv6; namely, the deployment of mobile multi-access end user = devices > that need to maintain a stable IP address or subnet. These devices are > commonly tablets or handsets of various manufacturers that have = wireless > access technologies that get (re)assigned different access addresses = as > they move around, and so tunneling is needed to maintain stable = end-user > addresses. >=20 > As the number of mobile devices grows, the end user addresses assigned > to mobiles would soon exhaust and fragment the RFC1918 space - hence = the > need for IPv6. But, we only see a need to deploy IPv6 on the mobiles > themselves and we do not necessarily see a need to upgrade the entire > enterprise routing structure to IPv6. The campus wireless solutions I've seen from vendors to date that = support IPv6 do some "interesting" things to support devices roaming = between IPv6 wireless subnets. They certainly don't seem to use MIPv6, = rather it seems common to use either unicast RAs and/or L2 tunnelling = between controllers. e.g. see = http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080ba= e506.shtml#mobility. Tim > Think of the tablet/handset as a miniature "mobile router" - a device > that should be able to connect up its own applications plus any number > of additional end user devices (Internet connection sharing). The = mobile > router gets an IPv6 prefix (/64 or shorter), and a routing system = inside > the enterprise network tracks the mobiles as they move around. What I = am > describing is AERO: >=20 > http://tools.ietf.org/html/draft-templin-aerolink >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark ZZZ = Smith >> Sent: Thursday, January 09, 2014 2:07 AM >> To: Randy Bush; Ted Lemon >> Cc: v6ops@ietf.org >> Subject: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as = they didn't IPv4, IPX, XNS, or >> DECNet) >> ----- Original Message ----- >>> From: Randy Bush >>> To: Ted Lemon >>> Cc: "v6ops@ietf.org" >>> Sent: Thursday, 9 January 2014 8:57 AM >>> Subject: Re: [v6ops] New Version Notification for = draft-yourtchenko-ra-dhcpv6-comparison-00.txt >> (fwd) >>>=20 >>>>> if we want them to deploy ipv6, as opposed to more rfc1918 = space, then >>>>> we need to remove all speed bumps. not discuss them. not tell = them >>>>> that RA is the true religion. frelling remove the speed bump. >>>>=20 >>>> Can you name a specific speed bump? I've been listening to this >>>> conversation for eight years too, and have yet to hear one named. = You >>>> seem to be saying that RA is the speed bump, but that's not = specific. >>>> What is it about RA that "they" need changed? >>>=20 >>> the missing dhcp function, exit router >>>=20 >>=20 >>=20 >> I don't think this is really true at all. What motivates an = enterprise to deploy a new technology is >> primarily what it does for the enterprise, not specific features of = it. >>=20 >> In the early 1990s, enterprises didn't deploy IPX for IPX's sake. = They didn't say, "We want IPX." They >> said, "We want to be able to share files and printers, because it is = cheaper than floppy disks and >> sneakernet, and buying everybody individual printers." If they chose = Novell Netware to share files and >> printers, they then deployed IPX because Novell Netware required it. = Those who chose Banyan Vines for >> file and print sharing deployed the Banyan Vines protocol instead. >>=20 >> In the middle to late 1990s, enterprises didn't deploy IPv4 for = IPv4's sake. They didn't say, "We >> want IPv4." They said, "We want to be able to email other = organisations and be able to access the WWW, >> because we can email customers and suppliers more quickly than using = slower fax and snail mail, and >> access information useful to our business on the Internet." They then = needed IPv4 to do that, so they >> deployed IPv4 (and wondered why it all had to be so hard with address = classes, subnet masks and >> default gateways, compared to deploying and operating turn-key IPX.) >>=20 >> For most enterprises, other than those that make their money from = information technology (like the >> ones that most people on this mailing list work for), technology is a = "necessary evil" to support >> their actual business of making some other type of widget. It is a = cost that takes away from the >> larger profit they could make on their widgets. If they can reduce = those costs, or even eliminate >> them, they will, because that increases their widget profit. >>=20 >> So a new technology has to either save the enterprise money or make = the enterprise money for it to be >> justified. >>=20 >> The "killer app" for IPv6 for an enterprise is one that exclusively = operates over IPv6 (instead of >> over their already deployed IPv4) _and_ makes or saves them money. = Some enterprises may never >> encounter an IPv6-only application that does this, so they may never = have an incentive to deploy it on >> their network. They may wish to have access to the IPv6 Internet = eventually, but all that might mean >> is IPv6 enabling the external interface of their corporate policy = enforcing web proxy, reached over >> RFC1918 IPv4. >>=20 >> Change IPv6 as much as people want, but if it isn't possible to = identify how it, or the applications >> that exclusively run over it will save or make them money, = enterprises will ignore it. More change and >> more options to it will only increase it's deployment costs, further = increasing the barrier it has to >> jump before it saves or makes an enterprise money. >>=20 >>=20 >> Regards, >> Mark. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_B419BE13-3D0D-402D-8BCF-9F5BA9580B67 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Fred.L.Templin@boeing.com>= ; wrote:

Hi Mark,

In our enterprise we are seeing an = emerging network-layer "killer app"
for IPv6; namely, the deployment = of mobile multi-access end user devices
that need to maintain a = stable IP address or subnet. These devices are
commonly tablets or = handsets of various manufacturers that have wireless
access = technologies that get (re)assigned different access addresses as
they = move around, and so tunneling is needed to maintain stable = end-user
addresses.

As the number of mobile devices grows, the = end user addresses assigned
to mobiles would soon exhaust and = fragment the RFC1918 space - hence the
need for IPv6. But, we only = see a need to deploy IPv6 on the mobiles
themselves and we do not = necessarily see a need to upgrade the entire
enterprise routing = structure to IPv6.

The campus wireless = solutions I've seen from vendors to date that support IPv6 do some = "interesting" things to support devices roaming between IPv6 wireless = subnets.  They certainly don't seem to use MIPv6, rather it seems = common to use either unicast RAs and/or L2 tunnelling between = controllers. e.g. see http://www.cisco.com/en/US/products/ps10315/p= roducts_tech_note09186a0080bae506.shtml#mobility.

=
Tim

Think of the = tablet/handset as a miniature "mobile router" - a device
that should = be able to connect up its own applications plus any number
of = additional end user devices (Internet connection sharing). The = mobile
router gets an IPv6 prefix (/64 or shorter), and a routing = system inside
the enterprise network tracks the mobiles as they move = around. What I am
describing is AERO:

http://tools.ie= tf.org/html/draft-templin-aerolink

Thanks - Fred
fred.l.templin@boeing.com
-----Original Message-----
From: v6ops = [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark ZZZ Smith
Sent: = Thursday, January 09, 2014 2:07 AM
To: Randy Bush; Ted Lemon
Cc: = v6ops@ietf.org
Subject: [v6ops] Enterprises won't deploy IPv6 for = IPv6's sake (as they didn't IPv4, IPX, XNS, or
DECNet)
----- = Original Message -----
From: Randy Bush = <randy@psg.com>
To: Ted Lemon = <ted.lemon@nominum.com>
Cc: "v6ops@ietf.org" = <v6ops@ietf.org>
Sent: Thursday, 9 January 2014 8:57 = AM
Subject: Re: [v6ops] New Version Notification = for    = draft-yourtchenko-ra-dhcpv6-comparison-00.txt
(fwd)

  if we want them to deploy ipv6, as opposed to more = rfc1918 space, then
  we need to remove all speed bumps.  = not discuss them.  not tell them
  that RA is the true = religion.  frelling remove the speed = bump.

  Can you name a specific speed = bump?  I've been listening to this
  conversation for eight = years too, and have yet to hear one named.  You
  seem to = be saying that RA is the speed bump, but that's not specific.
  = What is it about RA that "they" need changed?

the = missing dhcp function, exit router



I don't = think this is really true at all. What motivates an enterprise to deploy = a new technology is
primarily what it does for the enterprise, not = specific features of it.

In the early 1990s, enterprises didn't = deploy IPX for IPX's sake. They didn't say, "We want IPX." They
said, = "We want to be able to share files and printers, because it is cheaper = than floppy disks and
sneakernet, and buying everybody individual = printers." If they chose Novell Netware to share files and
printers, = they then deployed IPX because Novell Netware required it. Those who = chose Banyan Vines for
file and print sharing deployed the Banyan = Vines protocol instead.

In the middle to late 1990s, enterprises = didn't deploy IPv4 for IPv4's sake.  They didn't say, = "We
want IPv4." They said, "We want to be able to email other = organisations and be able to access the WWW,
because we can email = customers and suppliers more quickly than using slower fax and snail = mail, and
access information useful to our business on the Internet." = They then needed IPv4 to do that, so they
deployed IPv4 (and wondered = why it all had to be so hard with address classes, subnet masks = and
default gateways, compared to deploying and operating turn-key = IPX.)

For most enterprises, other than those that make their = money from information technology (like the
ones that most people on = this mailing list work for), technology is a "necessary evil" to = support
their actual business of making some other type of widget. It = is a cost that takes away from the
larger profit they could make on = their widgets. If they can reduce those costs, or even = eliminate
them, they will, because that increases their widget = profit.

So a new technology has to either save the enterprise = money or make the enterprise money for it to be
justified.

The = "killer app" for IPv6 for an enterprise is one that exclusively operates = over IPv6 (instead of
over their already deployed IPv4) _and_ makes = or saves them money. Some enterprises may never
encounter an = IPv6-only application that does this, so they may never have an = incentive to deploy it on
their network. They may wish to have access = to the IPv6 Internet eventually, but all that might mean
is IPv6 = enabling the external interface of their corporate policy enforcing web = proxy, reached over
RFC1918 IPv4.

Change IPv6 as much as = people want, but if it isn't possible to identify how it, or the = applications
that exclusively run over it will save or make them = money, enterprises will ignore it. More change and
more options to it = will only increase it's deployment costs, further increasing the barrier = it has to
jump before it saves or makes an enterprise = money.


Regards,
Mark.
___________________________________= ____________
v6ops mailing = list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
<= /blockquote>_______________________________________________
v6ops = mailing = list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
<= /blockquote>

= --Apple-Mail=_B419BE13-3D0D-402D-8BCF-9F5BA9580B67-- From ales.vizdal@t-mobile.cz Thu Jan 9 09:09:02 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC57A1AE3CA for ; Thu, 9 Jan 2014 09:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.79 X-Spam-Level: X-Spam-Status: No, score=-0.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snnPkgQ41YOJ for ; Thu, 9 Jan 2014 09:09:01 -0800 (PST) Received: from ctxmailhub.t-mobile.cz (ctxmailhub.t-mobile.cz [93.153.104.87]) by ietfa.amsl.com (Postfix) with ESMTP id 3538B1ADFB7 for ; Thu, 9 Jan 2014 09:09:01 -0800 (PST) From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Alexandru Petrescu , Mikael Abrahamsson Date: Thu, 9 Jan 2014 18:08:49 +0100 Thread-Topic: [v6ops] control and security of DHCP Thread-Index: Ac8NTHVeUmaBWxlQQAmXNicCYVmaWgAEJ+fw Message-ID: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB0@SRVHKE02.rdm.cz> References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CEA1D2.3000109@gmail.com> <52CEB2D6.9070608@gmail.com> <52CEB727.1050701@gmail.com> <52CEBB02.7050000@gmail.com> In-Reply-To: <52CEBB02.7050000@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-loop: 2 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 17:09:03 -0000 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of > Alexandru Petrescu > Sent: Thursday, January 09, 2014 4:07 PM > To: Mikael Abrahamsson > Cc: v6ops@ietf.org > Subject: Re: [v6ops] control and security of DHCP >=20 > Le 09/01/2014 15:52, Mikael Abrahamsson a =E9crit : > > On Thu, 9 Jan 2014, Alexandru Petrescu wrote: =20 > I meant to say it would be good to have >=20 > - a RA bit to state that DHCPv6 is the only way to get > routing > information (as there is a bit to state that DHCP is the > only way to > get an address.) =20 There is no routing delivered by DHCPv6 as it is by design delivering no ro= uting information, it's done by the RAs. > Alex Ales From tjc@ecs.soton.ac.uk Thu Jan 9 09:12:34 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABBF11AE419 for ; Thu, 9 Jan 2014 09:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.758 X-Spam-Level: X-Spam-Status: No, score=-1.758 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxsSCRJ6TgYw for ; Thu, 9 Jan 2014 09:12:32 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 489061AE406 for ; Thu, 9 Jan 2014 09:12:32 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s09HCLCN009371; Thu, 9 Jan 2014 17:12:21 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s09HCLCN009371 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1389287541; bh=ZfQoWKUtlssZ7yRv9LDHQNS4npg=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=eCuf58b0sX1rEzrWTzmp1cCLA4jlnpncIr3+v4sLGQkGOcPtF3vOhClOJ5p/xQdiI G86jZMtgRlt0HkJxB48fvagjV5SF41TtEVQlPM7ZYcCxhMpju7woHJ7Bayfk0MH+q9 KfqYVFsgysLTbkj+UEy/mRiobTw+Sk0uEYvYtn3c= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id q08HCL09596564962Z ret-id none; Thu, 09 Jan 2014 17:12:21 +0000 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s09HCJZS009051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jan 2014 17:12:19 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_AF438823-5C93-4042-9172-3D84CD5BD8BE" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Tim Chown In-Reply-To: Date: Thu, 9 Jan 2014 17:12:24 +0000 Message-ID: References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> <20140107104001.GM81676@Space.Net> <72626BC4-CB9E-49E8-8A54-48A141F52C0C@nominum.com> To: Randy Bush X-Mailer: Apple Mail (2.1510) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q08HCL095965649600; tid=q08HCL09596564962Z; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s09HCLCN009371 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 17:12:34 -0000 --Apple-Mail=_AF438823-5C93-4042-9172-3D84CD5BD8BE Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 8 Jan 2014, at 21:31, Randy Bush wrote: > > if we want them to deploy ipv6, as opposed to more rfc1918 space, then > we need to remove all speed bumps. not discuss them. not tell them > that RA is the true religion. frelling remove the speed bump. > > there is no harm and there is trivial cost in giving the customer what > she wants. > > that the ietf has refused to do so for years is characteristic of the > arrogance and ignorance which leaves ipv6's survival still at risk. I was reminded of this paper in another discussion recently. http://groups.csail.mit.edu/ana/Publications/PubPDFs/Tussle2002.pdf It could be argued there's a tussle here... Tim --Apple-Mail=_AF438823-5C93-4042-9172-3D84CD5BD8BE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii randy@psg.com> = wrote:

if we want them to deploy = ipv6, as opposed to more rfc1918 space, then
we need to remove all = speed bumps.  not discuss them.  not tell them
that RA is = the true religion.  frelling remove the speed bump.

there is = no harm and there is trivial cost in giving the customer what
she = wants.

that the ietf has refused to do so for years is = characteristic of the
arrogance and ignorance which leaves ipv6's = survival still at risk.

I was reminded of = this paper in another discussion recently.


It could be argued there's a tussle = here...

Tim
= --Apple-Mail=_AF438823-5C93-4042-9172-3D84CD5BD8BE-- From ales.vizdal@t-mobile.cz Thu Jan 9 09:15:59 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68721AE45C for ; Thu, 9 Jan 2014 09:15:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.79 X-Spam-Level: X-Spam-Status: No, score=-0.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ru6rB8pplf7N for ; Thu, 9 Jan 2014 09:15:58 -0800 (PST) Received: from ctxmailhub.t-mobile.cz (ctxmailhub.t-mobile.cz [93.153.104.87]) by ietfa.amsl.com (Postfix) with ESMTP id 73B8D1AE45B for ; Thu, 9 Jan 2014 09:15:58 -0800 (PST) From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Alexandru Petrescu , Mikael Abrahamsson Date: Thu, 9 Jan 2014 18:15:47 +0100 Thread-Topic: [v6ops] control and security of DHCP Thread-Index: Ac8NSfO5JsXvydH5QfWWUrqWGO2XkQAE7BXQ Message-ID: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CEA1D2.3000109@gmail.com> <52CEA420.5020305@fud.no> <52CEB1EE.1070708@gmail.com> <52CEB6C1.8050105@gmail.com> In-Reply-To: <52CEB6C1.8050105@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-loop: 2 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" , Pete Vickers Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 17:15:59 -0000 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of > Alexandru Petrescu > Sent: Thursday, January 09, 2014 3:49 PM > To: Mikael Abrahamsson > Cc: v6ops@ietf.org; Pete Vickers > Subject: Re: [v6ops] control and security of DHCP >=20 > Le 09/01/2014 15:33, Mikael Abrahamsson a =E9crit : > > On Thu, 9 Jan 2014, Alexandru Petrescu wrote: > > > >> But why should there be a PIO in the RA if nobody is > allowed to use > >> it anyway for configuring an address? Noise? > > > > RA is used for routing. >=20 > Well, that's a principle put very briefly, but in details one > may notice that RA is used for other less-routingly aspects > such as MTU which is a pure local variable. (and which DHCP > doesnt do either). As MTU is usually link specific, RA/ICMPv6 seems to be a good fit. =20 > > The only mechanism that can configure routing is RA. >=20 > Well, as you discuss, it reads head-on with a routing > protocol... Many say that it is not that good for RA to > configure routing. >=20 > Actually, if you take your statement that RA is used to > configure routing and extend it to new work at IETF, you'd > realize that RA is claimed to do routing which is actually > very little of more real routing. >=20 > RA does routing without computing shortest paths, without > avoiding loops, without avoiding split horizon, without > converging, without exchanging route databases, etc. RA does provide the host with routing information. It is not a dynamic=20 routing protocol as per your description above. > Alex Ales From Fred.L.Templin@boeing.com Thu Jan 9 09:21:57 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E76D1AE4B0 for ; Thu, 9 Jan 2014 09:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFu8-XmlaLgC for ; Thu, 9 Jan 2014 09:21:54 -0800 (PST) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7C11AE432 for ; Thu, 9 Jan 2014 09:21:54 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s09HLiSv026564; Thu, 9 Jan 2014 09:21:44 -0800 Received: from XCH-PHX-411.sw.nos.boeing.com (xch-phx-411.sw.nos.boeing.com [10.57.37.42]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s09HLgW6026558 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 9 Jan 2014 09:21:43 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.203]) by XCH-PHX-411.sw.nos.boeing.com ([169.254.11.54]) with mapi id 14.03.0158.001; Thu, 9 Jan 2014 09:21:42 -0800 From: "Templin, Fred L" To: Tim Chown Thread-Topic: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet) Thread-Index: AQHPDVztlDFPtBy1ak+oH31lDGSyjpp8oDvw Date: Thu, 9 Jan 2014 17:21:41 +0000 Message-ID: <2134F8430051B64F815C691A62D98318193CD6@XCH-BLV-504.nw.nos.boeing.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> <20140107104001.GM81676@Space.Net> <72626BC4-CB9E-49E8-8A54-48A141F52C0C@nominum.com> <6A64F619-4A0E-423A-A5E7-4C3234B461AE@nominum.com> <1389261993.72423.YahooMailNeo@web161906.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D98318193C5C@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 17:21:57 -0000 Hi Tim, > The campus wireless solutions I've seen from vendors to date that > support IPv6 do some "interesting" things to support devices roaming > between IPv6 wireless subnets. =A0They certainly don't seem to use > MIPv6, rather it seems common to use either unicast RAs and/or L2 > tunnelling between controllers. e.g. see http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080bae= 506.shtml#mobility. I am thinking of mobiles that have WiFi plus 3G/4G. When the mobile is in proximity of my enterprise infrastructure then it can certainly be managed as it hops between WLCs as you suggest. But, when the mobile leaves the campus and goes in via a Starbucks WiFi (or maybe my home WiFi) it is beyond the management realm of the enterprise and has to do something if it wants to maintain a stable IP address/subnet. Or, if the mobile goes off the "WiFi grid" it has to fire up its 3G/4G link and then still somehow maintain stability. This is not about MIPv6 - it is about AERO: http://tools.ietf.org/html/draft-templin-aerolink Thanks - Fred fred.l.templin@boeing.com PS I shouldn't have to ask, but please keep this as plaintext instead of converting to something else. From tjc@ecs.soton.ac.uk Thu Jan 9 09:24:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2830D1AE391 for ; Thu, 9 Jan 2014 09:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.538, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvoAJ8bTLUJy for ; Thu, 9 Jan 2014 09:24:43 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 3B18F1ADFB7 for ; Thu, 9 Jan 2014 09:24:43 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s09HOUnK013145; Thu, 9 Jan 2014 17:24:30 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s09HOUnK013145 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1389288270; bh=CEbC+25Wbp4a0brLJm4YA3g4y+o=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=E+NVtIS6lUP2RCvOrSt58VsiXUFP8Exxwx/ld2//8VxByEimTDJAttFrDgNXv7DDe BHL+MBQ7zBS+g5y7+UnyA/k/5li8NmmhTXh0IKTN0631y3zHLTEeardZN13y7iJOGy b3Zn1tf3i6d/sroCBNQHq0j6JKdQ6DErj/4AhocY= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id q08HOU0959656612vC ret-id none; Thu, 09 Jan 2014 17:24:30 +0000 Received: from dhcp-163-17.wireless.soton.ac.uk (dhcp-163-17.wireless.soton.ac.uk [152.78.163.17] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s09HOR5n011917 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jan 2014 17:24:27 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Tim Chown In-Reply-To: <2134F8430051B64F815C691A62D98318193CD6@XCH-BLV-504.nw.nos.boeing.com> Date: Thu, 9 Jan 2014 17:23:48 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> <20140107104001.GM81676@Space.Net> <72626BC4-CB9E-49E8-8A54-48A141F52C0C@nominum.com> <6A64F619-4A0E-423A-A5E7-4C3234B461AE@nominum.com> <1389261993.72423.YahooMailNeo@web161906.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D98318193C5C@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D98318193CD6@XCH-BLV-504.nw.nos.boeing.com> <597F58BD-DCEA-4C4E-B7AB-DCCB416B3CFD@ecs.soton.ac.uk> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1510) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q08HOU095965661200; tid=q08HOU0959656612vC; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=5:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s09HOUnK013145 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 17:24:45 -0000 On 9 Jan 2014, at 17:21, "Templin, Fred L" = wrote: > Hi Tim, >=20 >> The campus wireless solutions I've seen from vendors to date that >> support IPv6 do some "interesting" things to support devices roaming >> between IPv6 wireless subnets. They certainly don't seem to use >> MIPv6, rather it seems common to use either unicast RAs and/or L2 >> tunnelling between controllers. e.g. see >=20 > = http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080ba= e506.shtml#mobility. >=20 > I am thinking of mobiles that have WiFi plus 3G/4G. When the mobile is > in proximity of my enterprise infrastructure then it can certainly be > managed as it hops between WLCs as you suggest. But, when the mobile > leaves the campus and goes in via a Starbucks WiFi (or maybe my home > WiFi) it is beyond the management realm of the enterprise and has to > do something if it wants to maintain a stable IP address/subnet. Or, > if the mobile goes off the "WiFi grid" it has to fire up its 3G/4G > link and then still somehow maintain stability. MPTCP? A la Siri on iOS7 etc :) > This is not about MIPv6 - it is about AERO: Well, the thread is about something else, so back to that.... Tim >=20 > http://tools.ietf.org/html/draft-templin-aerolink >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > PS I shouldn't have to ask, but please keep this as plaintext instead > of converting to something else. From Fred.L.Templin@boeing.com Thu Jan 9 09:29:09 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611F11AE3DC for ; Thu, 9 Jan 2014 09:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkFaLx-OxNRk for ; Thu, 9 Jan 2014 09:29:07 -0800 (PST) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 03C741AE391 for ; Thu, 9 Jan 2014 09:29:06 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s09HSvhp032248; Thu, 9 Jan 2014 09:28:57 -0800 Received: from XCH-PHX-112.sw.nos.boeing.com (xch-phx-112.sw.nos.boeing.com [130.247.25.134]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s09HSq8m032180 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 9 Jan 2014 09:28:52 -0800 Received: from XCH-BLV-108.nw.nos.boeing.com (130.247.25.137) by XCH-PHX-112.sw.nos.boeing.com (130.247.25.134) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 9 Jan 2014 09:28:51 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.203]) by XCH-BLV-108.nw.nos.boeing.com ([169.254.13.207]) with mapi id 14.03.0158.001; Thu, 9 Jan 2014 09:28:51 -0800 From: "Templin, Fred L" To: Tim Chown Thread-Topic: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet) Thread-Index: AQHPDV+sxP36KFapgEy8h/U9IKX/EJp8pOLA Date: Thu, 9 Jan 2014 17:28:50 +0000 Message-ID: <2134F8430051B64F815C691A62D98318193D30@XCH-BLV-504.nw.nos.boeing.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> <20140107104001.GM81676@Space.Net> <72626BC4-CB9E-49E8-8A54-48A141F52C0C@nominum.com> <6A64F619-4A0E-423A-A5E7-4C3234B461AE@nominum.com> <1389261993.72423.YahooMailNeo@web161906.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D98318193C5C@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D98318193CD6@XCH-BLV-504.nw.nos.boeing.com> <597F58BD-DCEA-4C4E-B7AB-DCCB416B3CFD@ecs.soton.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 17:29:09 -0000 Hi Tim, > -----Original Message----- > From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] > Sent: Thursday, January 09, 2014 9:24 AM > To: Templin, Fred L > Cc: Mark ZZZ Smith; Randy Bush; Ted Lemon; v6ops@ietf.org > Subject: Re: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as th= ey didn't IPv4, IPX, XNS, or > DECNet) >=20 >=20 > On 9 Jan 2014, at 17:21, "Templin, Fred L" wr= ote: >=20 > > Hi Tim, > > > >> The campus wireless solutions I've seen from vendors to date that > >> support IPv6 do some "interesting" things to support devices roaming > >> between IPv6 wireless subnets. They certainly don't seem to use > >> MIPv6, rather it seems common to use either unicast RAs and/or L2 > >> tunnelling between controllers. e.g. see > > > > http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a008= 0bae506.shtml#mobility. > > > > I am thinking of mobiles that have WiFi plus 3G/4G. When the mobile is > > in proximity of my enterprise infrastructure then it can certainly be > > managed as it hops between WLCs as you suggest. But, when the mobile > > leaves the campus and goes in via a Starbucks WiFi (or maybe my home > > WiFi) it is beyond the management realm of the enterprise and has to > > do something if it wants to maintain a stable IP address/subnet. Or, > > if the mobile goes off the "WiFi grid" it has to fire up its 3G/4G > > link and then still somehow maintain stability. >=20 > MPTCP? A la Siri on iOS7 etc :) That won't get me to a mobile router - it only addresses the apps on the mobile itself.=20 =20 > > This is not about MIPv6 - it is about AERO: >=20 > Well, the thread is about something else, so back to that.... The thread is about IPv6 deployment in enterprise networks. AERO is about IPv6 deployment in enterprise networks (which should also be taken as input to your IPv6 enterprise deployment doc). Thanks - Fred fred.l.templin@boeing.com > Tim >=20 > > > > http://tools.ietf.org/html/draft-templin-aerolink > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > PS I shouldn't have to ask, but please keep this as plaintext instead > > of converting to something else. From Fred.L.Templin@boeing.com Thu Jan 9 09:36:42 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDCB1AE4E9 for ; Thu, 9 Jan 2014 09:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hL45QBk0JVZW for ; Thu, 9 Jan 2014 09:36:40 -0800 (PST) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECB71AE4D9 for ; Thu, 9 Jan 2014 09:36:40 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s09HaVbF006162; Thu, 9 Jan 2014 09:36:31 -0800 Received: from XCH-PHX-313.sw.nos.boeing.com (xch-phx-313.sw.nos.boeing.com [130.247.25.175]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s09HaMp6006114 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 9 Jan 2014 09:36:23 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.203]) by XCH-PHX-313.sw.nos.boeing.com ([169.254.13.112]) with mapi id 14.03.0158.001; Thu, 9 Jan 2014 09:36:22 -0800 From: "Templin, Fred L" To: Tim Chown Thread-Topic: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet) Thread-Index: AQHPDV+sxP36KFapgEy8h/U9IKX/EJp8pOLAgAACEfA= Date: Thu, 9 Jan 2014 17:36:21 +0000 Message-ID: <2134F8430051B64F815C691A62D98318193D82@XCH-BLV-504.nw.nos.boeing.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> <20140107104001.GM81676@Space.Net> <72626BC4-CB9E-49E8-8A54-48A141F52C0C@nominum.com> <6A64F619-4A0E-423A-A5E7-4C3234B461AE@nominum.com> <1389261993.72423.YahooMailNeo@web161906.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D98318193C5C@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D98318193CD6@XCH-BLV-504.nw.nos.boeing.com> <597F58BD-DCEA-4C4E-B7AB-DCCB416B3CFD@ecs.soton.ac.uk> <2134F8430051B64F815C691A62D98318193D30@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D98318193D30@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 17:36:42 -0000 > > MPTCP? A la Siri on iOS7 etc :) >=20 > That won't get me to a mobile router - it only addresses the apps > on the mobile itself. Should also say, I want my corporate assets to have a stable address in the DNS that doesn't change even if the assets are mobile and frequently changing their network point of attachment. Thanks - Fred fred.l.templin@boeing.com From swmike@swm.pp.se Thu Jan 9 10:44:50 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6281AE50A for ; Thu, 9 Jan 2014 10:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aEVtRsW2Z1X for ; Thu, 9 Jan 2014 10:44:48 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id C0A211AE029 for ; Thu, 9 Jan 2014 10:44:48 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8A6029C; Thu, 9 Jan 2014 19:44:38 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8474F9A; Thu, 9 Jan 2014 19:44:38 +0100 (CET) Date: Thu, 9 Jan 2014 19:44:38 +0100 (CET) From: Mikael Abrahamsson To: Nick Hilliard In-Reply-To: <52CEC7E4.8060103@inex.ie> Message-ID: References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7@nkgeml506-mbx.china.huawei.com> <52CEC7E4.8060103@inex.ie> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org, "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 18:44:51 -0000 On Thu, 9 Jan 2014, Nick Hilliard wrote: > Can you provide a reference for the assumption that the host will define > the netmask to be /128 if it receives an address assignment from DHCPv6 > without a specific subnet mask assignment via RA? what else would it do? I get zero hits on the word "netmask" in RFC3315. DHCPv6 will hand out addresses, which in IPv6 implicitly is a /128? -- Mikael Abrahamsson email: swmike@swm.pp.se From joelja@bogus.com Thu Jan 9 10:50:41 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0004C1AE532 for ; Thu, 9 Jan 2014 10:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6L9i0wSSdO3i for ; Thu, 9 Jan 2014 10:50:39 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id E6DE61AE52B for ; Thu, 9 Jan 2014 10:50:38 -0800 (PST) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s09IoO8u067666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 9 Jan 2014 18:50:25 GMT (envelope-from joelja@bogus.com) Message-ID: <52CEEF6B.3000104@bogus.com> Date: Thu, 09 Jan 2014 10:50:19 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: "Templin, Fred L" , Tim Chown References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <72626BC4-CB9E-49E8-8A54-48A141F52C0C@nominum.com> <6A64F619-4A0E-423A-A5E7-4C3234B461AE@nominum.com> <1389261993.72423.YahooMailNeo@web161906.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D98318193C5C@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D98318193CD6@XCH-BLV-504.nw.nos.boeing.com> <597F58BD-DCEA-4C4E-B7AB-DCCB416B3CFD@ecs.soton.ac.uk> <2134F8430051B64F815C691A62D98318193D30@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D98318193D82@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D98318193D82@XCH-BLV-504.nw.nos.boeing.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mfVUAfKBLqArJir42uc3S0E9AgP53Wigj" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Thu, 09 Jan 2014 18:50:25 +0000 (UTC) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 18:50:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mfVUAfKBLqArJir42uc3S0E9AgP53Wigj Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On 1/9/14, 9:36 AM, Templin, Fred L wrote: >>> MPTCP? A la Siri on iOS7 etc :) >> >> That won't get me to a mobile router - it only addresses the apps >> on the mobile itself. >=20 > Should also say, I want my corporate assets to have a stable address > in the DNS that doesn't change even if the assets are mobile and > frequently changing their network point of attachment. As a consumer, the mechanic by which my connectivity to my assets is rendered seamless is irrelevant, it's the doing it part that's important.= > Thanks - Fred > fred.l.templin@boeing.com >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --mfVUAfKBLqArJir42uc3S0E9AgP53Wigj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLO72sACgkQ8AA1q7Z/VrLyjgCfSVCtumL4wrOjYJ70Ewt9173t /4AAnjjOZTHryFTaKmn207DUv4N/T+09 =/1E5 -----END PGP SIGNATURE----- --mfVUAfKBLqArJir42uc3S0E9AgP53Wigj-- From nick@inex.ie Thu Jan 9 11:11:26 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD701AE005 for ; Thu, 9 Jan 2014 11:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaQdxUViD1dG for ; Thu, 9 Jan 2014 11:11:24 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id C65901ADFB2 for ; Thu, 9 Jan 2014 11:11:23 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id s09JB5bx088019 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 9 Jan 2014 19:11:10 GMT (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org Message-ID: <52CEF448.4020900@inex.ie> Date: Thu, 09 Jan 2014 19:11:04 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7@nkgeml506-mbx.china.huawei.com> <52CEC7E4.8060103@inex.ie> In-Reply-To: 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: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org, "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 19:11:26 -0000 On 09/01/2014 18:44, Mikael Abrahamsson wrote: > what else would it do? > > I get zero hits on the word "netmask" in RFC3315. DHCPv6 will hand out > addresses, which in IPv6 implicitly is a /128? It's context / configuration dependent. If the interface already has an address+netmask configured which contains the address received from DHCP, then local connectivity will work just fine. This necessarily will lead to either mealy-mouthed expressions like "may work, or may not", or else further qualification of when and how it may or may not work, maybe, depending on what the implementer did. I'd suggest it might be better not to have the phrase at all. Nick From tore@fud.no Thu Jan 9 11:36:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D27F61AE411 for ; Thu, 9 Jan 2014 11:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFRBWaPyAeiA for ; Thu, 9 Jan 2014 11:36:45 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) by ietfa.amsl.com (Postfix) with ESMTP id 197921AE0B4 for ; Thu, 9 Jan 2014 11:36:45 -0800 (PST) Received: from [2a02:fe0:c410:1d30:b6b6:76ff:fe17:2e83] (port=42097 helo=sloth.fud.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1W1LP5-0000Bf-SI; Thu, 09 Jan 2014 20:36:31 +0100 Message-ID: <52CEFA3F.4050603@fud.no> Date: Thu, 09 Jan 2014 20:36:31 +0100 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nick Hilliard , Lorenzo Colitti , Mikael Abrahamsson References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7@nkgeml506-mbx.china.huawei.com> <52CEC7E4.8060103@inex.ie> In-Reply-To: <52CEC7E4.8060103@inex.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org, "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 19:36:48 -0000 * Nick Hilliard > Can you provide a reference for the assumption that the host will define > the netmask to be /128 if it receives an address assignment from DHCPv6 > without a specific subnet mask assignment via RA? http://tools.ietf.org/search/rfc5942#section-5 Tore From Fred.L.Templin@boeing.com Thu Jan 9 12:28:14 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209F81AE4D9 for ; Thu, 9 Jan 2014 12:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3v4bGruNIqi for ; Thu, 9 Jan 2014 12:28:12 -0800 (PST) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACD01AE0C6 for ; Thu, 9 Jan 2014 12:28:12 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s09KS23U002150; Thu, 9 Jan 2014 12:28:02 -0800 Received: from XCH-PHX-211.sw.nos.boeing.com (xch-phx-211.sw.nos.boeing.com [130.247.25.140]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s09KRt5K002078 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 9 Jan 2014 12:27:56 -0800 Received: from XCH-BLV-402.nw.nos.boeing.com (130.247.25.31) by XCH-PHX-211.sw.nos.boeing.com (130.247.25.140) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 9 Jan 2014 12:27:55 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.203]) by XCH-BLV-402.nw.nos.boeing.com ([169.254.2.86]) with mapi id 14.03.0158.001; Thu, 9 Jan 2014 12:27:55 -0800 From: "Templin, Fred L" To: joel jaeggli , Tim Chown Thread-Topic: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet) Thread-Index: AQHPDWukxP36KFapgEy8h/U9IKX/EJp81MTw Date: Thu, 9 Jan 2014 20:27:54 +0000 Message-ID: <2134F8430051B64F815C691A62D98318194194@XCH-BLV-504.nw.nos.boeing.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <72626BC4-CB9E-49E8-8A54-48A141F52C0C@nominum.com> <6A64F619-4A0E-423A-A5E7-4C3234B461AE@nominum.com> <1389261993.72423.YahooMailNeo@web161906.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D98318193C5C@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D98318193CD6@XCH-BLV-504.nw.nos.boeing.com> <597F58BD-DCEA-4C4E-B7AB-DCCB416B3CFD@ecs.soton.ac.uk> <2134F8430051B64F815C691A62D98318193D30@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D98318193D82@XCH-BLV-504.nw.nos.boeing.com> <52CEEF6B.3000104@bogus.com> In-Reply-To: <52CEEF6B.3000104@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 20:28:14 -0000 Hi Joel, > -----Original Message----- > From: joel jaeggli [mailto:joelja@bogus.com] > Sent: Thursday, January 09, 2014 10:50 AM > To: Templin, Fred L; Tim Chown > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as th= ey didn't IPv4, IPX, XNS, or > DECNet) >=20 > On 1/9/14, 9:36 AM, Templin, Fred L wrote: > >>> MPTCP? A la Siri on iOS7 etc :) > >> > >> That won't get me to a mobile router - it only addresses the apps > >> on the mobile itself. > > > > Should also say, I want my corporate assets to have a stable address > > in the DNS that doesn't change even if the assets are mobile and > > frequently changing their network point of attachment. >=20 > As a consumer, the mechanic by which my connectivity to my assets is > rendered seamless is irrelevant, it's the doing it part that's important. What AERO is suggesting is mobile networks that retain the same IPv6 addresses/prefixes wherever they happen to move to. So, if my tablet is a mobile router that serves all of my other personal networked devices for example, those devices all get stable IPv6 addresses. Or, if maybe my airplane is a mobile router that changes its network point of attachment frequently as it travels across continents, the airline should still be able to address the airplane and all of its addressable components. I guess you are asking whether we need IPv6 routing and addressing all the way out to the end systems or whether just getting to some sort of middlebox "concentrator" is sufficient. I think that comes down to whether we truly want IPv6 end-to-end. Thanks - Fred fred.l.templin@boeing.com =20 > > Thanks - Fred > > fred.l.templin@boeing.com > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > >=20 From gert@Space.Net Thu Jan 9 13:35:23 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C243F1A1F3E for ; Thu, 9 Jan 2014 13:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fNmvg5S__Sd for ; Thu, 9 Jan 2014 13:35:21 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 0380F1A1F05 for ; Thu, 9 Jan 2014 13:35:20 -0800 (PST) Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 4F2BB6049E for ; Thu, 9 Jan 2014 22:35:09 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 1623060126 for ; Thu, 9 Jan 2014 22:35:09 +0100 (CET) Received: (qmail 28140 invoked by uid 1007); 9 Jan 2014 22:35:08 +0100 Date: Thu, 9 Jan 2014 22:35:08 +0100 From: Gert Doering To: Nick Hilliard Message-ID: <20140109213508.GC40453@Space.Net> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7@nkgeml506-mbx.china.huawei.com> <52CEC7E4.8060103@inex.ie> <52CEF448.4020900@inex.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52CEF448.4020900@inex.ie> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org, "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 21:35:24 -0000 Hi, On Thu, Jan 09, 2014 at 07:11:04PM +0000, Nick Hilliard wrote: > On 09/01/2014 18:44, Mikael Abrahamsson wrote: > > what else would it do? > > > > I get zero hits on the word "netmask" in RFC3315. DHCPv6 will hand out > > addresses, which in IPv6 implicitly is a /128? > > It's context / configuration dependent. If the interface already has an > address+netmask configured which contains the address received from DHCP, > then local connectivity will work just fine. "If I add routing using some other way it does not matter that DHCPv6 will not add it". True. And, how exactly is this relevant to the fact that DHCPv6 *alone* will not get you anywhere today? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From lorenzo@google.com Thu Jan 9 19:18:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA8B31ADFBC for ; Thu, 9 Jan 2014 19:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2xnwA5prLaF for ; Thu, 9 Jan 2014 19:18:27 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1374E1ADFAF for ; Thu, 9 Jan 2014 19:18:27 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id u16so2135758iet.32 for ; Thu, 09 Jan 2014 19:18:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VnaEd7qSPIWkV3UUxC1fh6tbwg1HAtEkfrmVXVMSBX8=; b=nfL8K++U9/1ttgn9tm5JmLvhFHkL+9tqe/JupDy6vAbG3RKrtwm1TT1c2s1gyId9Y3 D4KjcAIh7xK07Z6p5EutOqokZKvr+DTfRvqbbt/fN44dmimkS9gWOmV37a7C9NT7r/Fi BsUosOMiXkV3p8KfwXNV8w6cDMwrEaDw0UNX06VMtKJlrUDxoCqda1i62ts1tjXgZ11e DXZ6FIXL5Evrm9zwiBjb6Rk8N/1QF/PL674mhAvUcbRoyqi6xIROvyYmF1mXg3fia+vo 0CNcy5XTJHQQMhzwnzubRzTTeiYdXhpeNtu95Vmn/sORBq5rH9IKbn9zmVPh6K50K148 9qeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=VnaEd7qSPIWkV3UUxC1fh6tbwg1HAtEkfrmVXVMSBX8=; b=XEiW4R126+QigxBJlMUxyquefZ57wC25anXjSZfeyNHo99yqftFqj+EjIfbLsBlrzU LwDgsqzr02OJGyCuSOqZrkUq7lDVcG4NEj+/LTeuT7/I3ceLEqqKUe5Fht2mds1bjYyo CrnKfP1vWBJFZU6pa5hT5+jTfZoDW4xp77KD9fz3MoFPJP1r6tdUa71tUO7G1i3mrTaa quw21yuixINS/Yj31+Fe7qh1M+XkU0EdiZfCmJNTF9R6YKocQwNS1AstWPL9GX+IG8gW EYHFvH86IXMrwbll97iEal9ahZm8lk4kI9SIn17a+WF57TTBgySvOWBsufeTK0S9URfu /wLQ== X-Gm-Message-State: ALoCoQnZDufJfrK7Se6q7qk435VCxrdVsUQ57mohsP4ba7D/9sF6RLM8gEHYokgGuwiq16dhP8k3KcLwhnRNwAnUI3/yMOLqc1dd09yNqf1tqK3f5prohXYclXjf4ww6cTAlkCBivVdFWSVaHtVoctCSw0kVqYdXjYM5y4R7ZxLgdBTpiG17JuZEr4ejz6ZZhHTUnHPYlCCq X-Received: by 10.43.49.1 with SMTP id uy1mr5557570icb.48.1389323897203; Thu, 09 Jan 2014 19:18:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Thu, 9 Jan 2014 19:17:57 -0800 (PST) In-Reply-To: <52CEF448.4020900@inex.ie> References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7@nkgeml506-mbx.china.huawei.com> <52CEC7E4.8060103@inex.ie> <52CEF448.4020900@inex.ie> From: Lorenzo Colitti Date: Fri, 10 Jan 2014 12:17:57 +0900 Message-ID: To: Nick Hilliard Content-Type: multipart/alternative; boundary=bcaec529a0235f1e6104ef952de7 Cc: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org, "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 03:18:29 -0000 --bcaec529a0235f1e6104ef952de7 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 10, 2014 at 4:11 AM, Nick Hilliard wrote: > > I get zero hits on the word "netmask" in RFC3315. DHCPv6 will hand out > > addresses, which in IPv6 implicitly is a /128? > > It's context / configuration dependent. If the interface already has an > address+netmask configured which contains the address received from DHCP, > then local connectivity will work just fine. > Correct, but that's already covered in the proposed text, which is as follows. The text basically says "to use addresses to talk to anything that's not yourself, you need routing; you can't get configure via DHCPv6; you can configure routing by doing X, Y, and Z)". X, Y and Z does not include manual configuration, because people seemed to feel that manual configuration is not recommended and thus should not be included in an operational guidance document, but we could certainly add it if there's consensus to do so. ==== 3.2. Guidance for DHCPv6-only Deployment Some networks prefer central management of all IP addressing. These networks may want to assign addresses only via DHCPv6. This can be accomplished by sending an RA that indicates that DHCPv6 address assignment is available (i.e., M=1), installing DHCPv6 servers or DHCPv6 relays on all links, and setting A=0 in the Prefix Information Options of all prefixes in the RA. Note that an RA is still necessary in order for hosts to be able to use these addresses. This is for two reasons: 1. Per problem #1, if there is no RA, some hosts will not attempt to obtain address configuration via DHCPv6. 2. DHCPv6 can assign addresses but not routing. Hosts can acquire routing information by accepting RA messages with a nonzero Router Lifetime, Prefix Information Options with L=1, or Route Information Options. Without routing, IPv6 addresses won't be used for commmunication outside the host. Thus, for example, if there is no RA and no static routing, then addresses assigned by DHCPv6 cannot be used even for communication between hosts on the same link. Also note that unlike SLAAC, DHCPv6 is not a strict requirement for IPv6 hosts [RFC6434], and some nodes do not support DHCPv6. Thus, this model can only be used if all the hosts that need IPv6 connectivity support DHCPv6. Per problem #2, if the administrators want to switch the DHCPv6-only configured hosts to SLAAC-only, this is not possible on some hosts without manually changing the hosts' configuration or using additional management tools. Per problem #4, for some platforms, the A flag and O flag might not be independent, when SLAAC is off, a stand-alone stateless DHCPv6 session would not be applicable. However, this might not be a common use case. ==== --bcaec529a0235f1e6104ef952de7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 10, 2014 at 4:11 AM, Nick Hilliard <nick@inex.ie> wrote:<= br>
> I get zero hits on the word "netmask" in R= FC3315. DHCPv6 will hand out
> addresses, which in IPv6 implicitly is a /128?

It's context / configuration dependent. =C2=A0If the interface al= ready has an
address+netmask configured which contains the address received from DHCP, then local connectivity will work just fine.

Correct, but that's already covered in the proposed text, which i= s as follows. The text basically says "to use addresses to talk to any= thing that's not yourself, you need routing; you can't get configur= e via DHCPv6; you can configure routing by doing X, Y, and Z)". X, Y a= nd Z does not include manual configuration, because people seemed to feel t= hat manual configuration is not recommended and thus should not be included= in an operational guidance document, but we could certainly add it if ther= e's consensus to do so.

=3D=3D=3D=3D
3.2. Guidance for DHCPv6-on= ly Deployment
=C2=A0
Some networks prefer central manag= ement of all IP addressing. These networks may want to assign addresses onl= y via DHCPv6.
=C2=A0
This can be accomplished by sending an RA that indica= tes that DHCPv6 address assignment is available (i.e., M=3D1), installing D= HCPv6 servers or DHCPv6 relays on all links, and setting A=3D0 in the Prefi= x Information Options of all prefixes in the RA.

Note that an RA is still necessary in order for hosts t= o be able to use these addresses. This is for two reasons:

1. Per problem #1, if there is no RA, some hosts will not attempt = to obtain address configuration via DHCPv6.

2. DHCPv6 can assign addresses but not routing. Hosts c= an acquire routing information by accepting RA messages with a nonzero Rout= er Lifetime, Prefix Information Options with L=3D1, or Route Information Op= tions. Without routing, IPv6 addresses won't be used for commmunication= outside the host. Thus, for example, if there is no RA and no static routi= ng, then addresses assigned by DHCPv6 cannot be used even for communication= between hosts on the same link.

Also note that unlike SLAAC, DHCPv6 is not a strict req= uirement for IPv6 hosts [RFC6434], and some nodes do not support DHCPv6. Th= us, this model can only be used if all the hosts that need IPv6 connectivit= y support DHCPv6.
=C2=A0
Per problem #2, if the administrators want to switch = the DHCPv6-only configured hosts to SLAAC-only, this is not possible on som= e hosts without manually changing the hosts' configuration or using add= itional management tools.
=C2=A0
Per problem #4, for some platforms, the A flag and O = flag might not be independent, when SLAAC is off, a stand-alone stateless D= HCPv6 session would not be applicable. However, this might not be a common = use case.
=3D=3D=3D=3D
--bcaec529a0235f1e6104ef952de7-- From lorenzo@google.com Thu Jan 9 19:19:24 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58531ADFCE for ; Thu, 9 Jan 2014 19:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9av_HVs3AanD for ; Thu, 9 Jan 2014 19:19:23 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 735971ADFCD for ; Thu, 9 Jan 2014 19:19:23 -0800 (PST) Received: by mail-ig0-f173.google.com with SMTP id ut6so17976329igb.0 for ; Thu, 09 Jan 2014 19:19:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lvRDX39HfpI2BQ9CTWtt2hKK1rjSKwXmek3O+chYrnM=; b=kj0PVeaSI0PNsVOn9m4bHTH/V9Iet5+suBZUPHPX/Jfo7A7ctDJylQoVG8rxgw99SH AKObwJvpI8guV0pRpbg+TD3/Rrj9SqEOovpU5acL0Sr0lbHf4eZGtuKjBQHQgIB9gCu9 l+gEtnE69Ru3CKjm8Y0/VeEYtFq9kw/o9o2B2H4iMSTrmtZC2p2uwgwPj1mz6YFgNpdl gfw25FhenaIthB/AhNQ/UfoeqoV7/HGn0CnyhC0ZcVRtEvkKa3NfUBvDeqZwN5EDpwHR 4QrgTEht17Typeyvtw6ZKyoxrFf6GQWSpBR3g/haZh0dSJaZveBYokZt+tKLe+7QsAwP bNzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=lvRDX39HfpI2BQ9CTWtt2hKK1rjSKwXmek3O+chYrnM=; b=FKn/IDqqQTfa8qIHi+naUgs6ry6PeQS6XD6dATDQLGPjousBd4zAkrWA/5AFS2vb9A eftSLwOFF5Qf4C5pw4DqzIendlu1n0+0dNtnqFUgwFpPmgy04z+TpIOZdj06ySvCOo7b rE5vcQ/yvQOifoHGOP/IcUStchW4+05I+vFm8dMmuDkfWVacgn6ag9qK9N/NIVV2rpHL QjyeWQB0QMDdZNPeVJz/HxIkHwhX2mI1LGls30R1or1uleB647L8Lbmt/z55rfx/sWAo zMXBXdMkoWKKOFh9ORAZawDM0rbNBRI2Q1cPRsmRqc3Zd888fNGn+G217xMTCv8Fjnt0 jv3w== X-Gm-Message-State: ALoCoQnZC7smyQ2nFDQhLsMwhedn9SlmYfZYtMjMbnWIWCd5TNkoFV1gF/USRHUtjVR3Jss3Xz5DveS5uU3HDNLjt+aKKbyj5WIYC42Ss0rEX9vAT0PZhGldumN6fcCZBvyBfMYZOgLYBRZCnW1NU7pc4UPGKEsyVWxNAx3iwvbNTeE2IsGN8IqDeq+AInszZ3J0+9MhBVyQ X-Received: by 10.42.214.202 with SMTP id hb10mr11779icb.76.1389323953749; Thu, 09 Jan 2014 19:19:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Thu, 9 Jan 2014 19:18:52 -0800 (PST) In-Reply-To: References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7@nkgeml506-mbx.china.huawei.com> <52CEC7E4.8060103@inex.ie> <52CEF448.4020900@inex.ie> From: Lorenzo Colitti Date: Fri, 10 Jan 2014 12:18:52 +0900 Message-ID: To: Nick Hilliard Content-Type: multipart/alternative; boundary=20cf301cc3b2bdf2fc04ef9530b5 Cc: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org, "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 03:19:24 -0000 --20cf301cc3b2bdf2fc04ef9530b5 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 10, 2014 at 12:17 PM, Lorenzo Colitti wrote: > you can't get configure via DHCPv6 > Er, that should be "you can't configure routing via DHCPv6". --20cf301cc3b2bdf2fc04ef9530b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 10, 2014 at 12:17 PM, Lorenzo Colitti <lorenzo@google.com>= wrote:
=
you can't get configure via DHCPv6

Er, that should be "= ;you can't configure routing via DHCPv6".
--20cf301cc3b2bdf2fc04ef9530b5-- From alexandru.petrescu@gmail.com Fri Jan 10 01:04:37 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B521ACCE6 for ; Fri, 10 Jan 2014 01:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.683 X-Spam-Level: X-Spam-Status: No, score=-4.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pa6m6iuauJU2 for ; Fri, 10 Jan 2014 01:04:36 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id CBDAC1A1F5B for ; Fri, 10 Jan 2014 01:04:35 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s0A94PT9011095; Fri, 10 Jan 2014 10:04:25 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 647F620700F; Fri, 10 Jan 2014 10:05:27 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 56E502039A3; Fri, 10 Jan 2014 10:05:27 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s0A94KkX015551; Fri, 10 Jan 2014 10:04:25 +0100 Message-ID: <52CFB794.6080203@gmail.com> Date: Fri, 10 Jan 2014 10:04:20 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: =?ISO-8859-2?Q?V=EDzdal_Ale=B9?= , Mikael Abrahamsson References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CEA1D2.3000109@gmail.com> <52CEB2D6.9070608@gmail.com> <52CEB727.1050701@gmail.com> <52CEBB02.7050000@gmail.com> <1808340F7EC362469DDFFB112B37E2FCDA31A30EB0@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB0@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 09:04:38 -0000 Le 09/01/2014 18:08, Vízdal Ale¹ a écrit : >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of >> Alexandru Petrescu >> Sent: Thursday, January 09, 2014 4:07 PM >> To: Mikael Abrahamsson >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] control and security of DHCP >> >> Le 09/01/2014 15:52, Mikael Abrahamsson a écrit : >>> On Thu, 9 Jan 2014, Alexandru Petrescu wrote: > >> I meant to say it would be good to have >> >> - a RA bit to state that DHCPv6 is the only way to get >> routing >> information (as there is a bit to state that DHCP is the >> only way to >> get an address.) > > There is no routing delivered by DHCPv6 as it is by design delivering no routing information, > it's done by the RAs. Well it's good to have principles like that, but is one really sure. Would address selection policy qualify as part or some form of some routing information? Similary, would Prefix Delegation qualify as parts of routing information? I would say yes they qualify and yes they are delivered by DHCP; and seem to be exceptions to the rule that DHCP design is not delivering routing information. Alex > >> Alex > > Ales > > From alexandru.petrescu@gmail.com Fri Jan 10 01:09:55 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7431ACCFF for ; Fri, 10 Jan 2014 01:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.683 X-Spam-Level: X-Spam-Status: No, score=-4.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvQz9zT5hzLs for ; Fri, 10 Jan 2014 01:09:53 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 2D66A1A1F5D for ; Fri, 10 Jan 2014 01:09:53 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s0A99g1k007603; Fri, 10 Jan 2014 10:09:42 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7E715206FFE; Fri, 10 Jan 2014 10:10:44 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6E19520324C; Fri, 10 Jan 2014 10:10:44 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s0A99f8a020076; Fri, 10 Jan 2014 10:09:42 +0100 Message-ID: <52CFB8D5.70900@gmail.com> Date: Fri, 10 Jan 2014 10:09:41 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: =?ISO-8859-2?Q?V=EDzdal_Ale=B9?= , Mikael Abrahamsson References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CEA1D2.3000109@gmail.com> <52CEA420.5020305@fud.no> <52CEB1EE.1070708@gmail.com> <52CEB6C1.8050105@gmail.com> <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" , Pete Vickers Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 09:09:56 -0000 Le 09/01/2014 18:15, Vízdal Ale¹ a écrit : >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of >> Alexandru Petrescu >> Sent: Thursday, January 09, 2014 3:49 PM >> To: Mikael Abrahamsson >> Cc: v6ops@ietf.org; Pete Vickers >> Subject: Re: [v6ops] control and security of DHCP >> >> Le 09/01/2014 15:33, Mikael Abrahamsson a écrit : >>> On Thu, 9 Jan 2014, Alexandru Petrescu wrote: >>> >>>> But why should there be a PIO in the RA if nobody is >> allowed to use >>>> it anyway for configuring an address? Noise? >>> >>> RA is used for routing. >> >> Well, that's a principle put very briefly, but in details one >> may notice that RA is used for other less-routingly aspects >> such as MTU which is a pure local variable. (and which DHCP >> doesnt do either). > > As MTU is usually link specific, RA/ICMPv6 seems to be a good fit. Yes. link-specific vs network-specific I suppose? Isn't MTU part of PMTUD which is network-specific? DHCP seems a good fit to provide MTU as well. >>> The only mechanism that can configure routing is RA. >> >> Well, as you discuss, it reads head-on with a routing >> protocol... Many say that it is not that good for RA to >> configure routing. >> >> Actually, if you take your statement that RA is used to >> configure routing and extend it to new work at IETF, you'd >> realize that RA is claimed to do routing which is actually >> very little of more real routing. >> >> RA does routing without computing shortest paths, without >> avoiding loops, without avoiding split horizon, without >> converging, without exchanging route databases, etc. > > RA does provide the host with routing information. It is not a dynamic > routing protocol as per your description above. Right, but routing would not work without a good dynamic routing protocol. It would make little sense to have good RAs without being backed by a good dynamic routing protocol, right? And, since other parts of this dynamic routing would need Prefix Delegation (which is exclusively a DHCP or OSPF feature, not RA), one may find that it may make little sense for RA to provide routing. In some contexts where DHCP and OSPF already prevail. Alex > >> Alex > > Ales > > From alexandru.petrescu@gmail.com Fri Jan 10 01:18:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752371AD8CD for ; Fri, 10 Jan 2014 01:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLR_7QAcc7Vt for ; Fri, 10 Jan 2014 01:18:01 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id CA8A61ACCE6 for ; Fri, 10 Jan 2014 01:18:00 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s0A9HoWS016808 for ; Fri, 10 Jan 2014 10:17:50 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AF541207043 for ; Fri, 10 Jan 2014 10:18:52 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4158F20700F for ; Fri, 10 Jan 2014 10:18:46 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s0A9HeeR027233 for ; Fri, 10 Jan 2014 10:17:43 +0100 Message-ID: <52CFBAB4.4040105@gmail.com> Date: Fri, 10 Jan 2014 10:17:40 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <20140107104001.GM81676@Space.Net> <72626BC4-CB9E-49E8-8A54-48A141F52C0C@nominum.com> <6A64F619-4A0E-423A-A5E7-4C3234B461AE@nominum.com> <1389261993.72423.YahooMailNeo@web161906.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D98318193C5C@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D98318193CD6@XCH-BLV-504.nw.nos.boeing.com> <597F58BD-DCEA-4C4E-B7AB-DCCB416B3CFD@ecs.soton.ac.uk> <2134F8430051B64F815C691A62D98318193D30@XCH-BLV-504.nw.nos.boei! ng.com> In-Reply-To: <2134F8430051B64F815C691A62D98318193D30@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 09:18:03 -0000 Le 09/01/2014 18:28, Templin, Fred L a écrit : > Hi Tim, > >> -----Original Message----- From: Tim Chown >> [mailto:tjc@ecs.soton.ac.uk] Sent: Thursday, January 09, 2014 9:24 >> AM To: Templin, Fred L Cc: Mark ZZZ Smith; Randy Bush; Ted Lemon; >> v6ops@ietf.org Subject: Re: [v6ops] Enterprises won't deploy IPv6 >> for IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet) >> >> >> On 9 Jan 2014, at 17:21, "Templin, Fred L" >> wrote: >> >>> Hi Tim, >>> >>>> The campus wireless solutions I've seen from vendors to date >>>> that support IPv6 do some "interesting" things to support >>>> devices roaming between IPv6 wireless subnets. They certainly >>>> don't seem to use MIPv6, rather it seems common to use either >>>> unicast RAs and/or L2 tunnelling between controllers. e.g. see >>> >>> http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080bae506.shtml#mobility. >>> >>> >>> I am thinking of mobiles that have WiFi plus 3G/4G. When the mobile is >>> in proximity of my enterprise infrastructure then it can >>> certainly be managed as it hops between WLCs as you suggest. But, >>> when the mobile leaves the campus and goes in via a Starbucks >>> WiFi (or maybe my home WiFi) it is beyond the management realm of >>> the enterprise and has to do something if it wants to maintain a >>> stable IP address/subnet. Or, if the mobile goes off the "WiFi >>> grid" it has to fire up its 3G/4G link and then still somehow >>> maintain stability. >> >> MPTCP? A la Siri on iOS7 etc :) > > That won't get me to a mobile router - it only addresses the apps on > the mobile itself. YEs, and only apps using a particular transport protocols, not all. (and yes the news of MPTCP at Apple is encouraging about that particular protocol). > >>> This is not about MIPv6 - it is about AERO: >> >> Well, the thread is about something else, so back to that.... > > The thread is about IPv6 deployment in enterprise networks. AERO is > about IPv6 deployment in enterprise networks (which should also be > taken as input to your IPv6 enterprise deployment doc). Right. But since this thread relates to the DHCP discussion, would AERO have an aspect related to DHCP? Or to RA? How would an AERO Router self-configure its address, its mobile network prefix and its default route? Would it accept many combinations or just one? Alex > > Thanks - Fred fred.l.templin@boeing.com > >> Tim >> >>> >>> http://tools.ietf.org/html/draft-templin-aerolink >>> >>> Thanks - Fred fred.l.templin@boeing.com >>> >>> PS I shouldn't have to ask, but please keep this as plaintext >>> instead of converting to something else. > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From alexandru.petrescu@gmail.com Fri Jan 10 01:27:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F741A1F56 for ; Fri, 10 Jan 2014 01:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udGUmqdT0CPx for ; Fri, 10 Jan 2014 01:27:51 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id A845C1A1F33 for ; Fri, 10 Jan 2014 01:27:50 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s0A9ReLw008914 for ; Fri, 10 Jan 2014 10:27:40 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6E4C7207082 for ; Fri, 10 Jan 2014 10:28:42 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6586E20709F for ; Fri, 10 Jan 2014 10:28:42 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s0A9RaBY003926 for ; Fri, 10 Jan 2014 10:27:40 +0100 Message-ID: <52CFBD08.3030100@gmail.com> Date: Fri, 10 Jan 2014 10:27:36 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7@nkgeml506-mbx.china.huawei.com> <52CEC7E4.8060103@inex.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 09:27:52 -0000 Le 09/01/2014 19:44, Mikael Abrahamsson a écrit : > On Thu, 9 Jan 2014, Nick Hilliard wrote: > >> Can you provide a reference for the assumption that the host will >> define the netmask to be /128 if it receives an address assignment >> from DHCPv6 without a specific subnet mask assignment via RA? > > what else would it do? > > I get zero hits on the word "netmask" in RFC3315. DHCPv6 will hand > out addresses, which in IPv6 implicitly is a /128? Right, good assumption... but please allow me another interpretation. It's interesting to note that that RFC3315 does define the term 'prefix length' although it does not employ it. This as such may make wonder why is that term there, and what are the implications to the ongoing editing of that document. 'Prefix length' is IPv6 language for 'subnet mask' or 'netmask'. Moreover, if one searches for 'prefix' in that RFC, one may find occurences which may be hard to implement, RFC3315: > Each IA_TA option contains at most one temporary address for each of > the prefixes on the link to which the client is attached. Would Server know each of the prefixes on the link on which the client is attached? I suppose yes, by pre-configuration. If it knows it, then why not delivering it to the client. RFC3315: > 18.1.2. Creation and Transmission of Confirm Messages > > Whenever a client may have moved to a new link, the prefixes from the > addresses assigned to the interfaces on that link may no longer be > appropriate for the link to which the client is attached. Examples > of times when a client may have moved to a new link include: [...] > Any responding servers will indicate whether those > addresses are appropriate for the link to which the client is > attached with the status in the Reply message it returns to the > client. RFC3315: > If the relay agent received the message to be relayed from a client, > the relay agent places a global or site-scoped address with a prefix > assigned to the link on which the client should be assigned an > address in the link-address field. RFC3315: > NotOnLink 4 The prefix for the address is not appropriate for > the link to which the client is attached. Each of these suggest that the Server does know the prefixes on the link on which the client is attached. Alex From swmike@swm.pp.se Fri Jan 10 01:32:12 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540021ACC81 for ; Fri, 10 Jan 2014 01:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NB5y1vW5i1RK for ; Fri, 10 Jan 2014 01:32:10 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id DD13A1A1F33 for ; Fri, 10 Jan 2014 01:32:09 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 215CD9C; Fri, 10 Jan 2014 10:31:59 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0E1E59A; Fri, 10 Jan 2014 10:31:59 +0100 (CET) Date: Fri, 10 Jan 2014 10:31:59 +0100 (CET) From: Mikael Abrahamsson To: Alexandru Petrescu In-Reply-To: <52CFB8D5.70900@gmail.com> Message-ID: References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CEA1D2.3000109@gmail.com> <52CEA420.5020305@fud.no> <52CEB1EE.1070708@gmail.com> <52CEB6C1.8050105@gmail.com> <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 09:32:12 -0000 On Fri, 10 Jan 2014, Alexandru Petrescu wrote: > Yes. link-specific vs network-specific I suppose? > > Isn't MTU part of PMTUD which is network-specific? No, MTU is by definiteion link-specific. A network can choose to run the same MTU everywhere, but it's still decided on a per-link basis. > DHCP seems a good fit to provide MTU as well. *Sigh*. No, it doesn't. MTU is derived from settings on the router. This is why RA is a great fit, as the router sends the RAs and can derive the MTU settings from it's interface setting. In order for this to work decently, the DHCPv6 forwarding agent in the router would have to gain functionality to re-write MTU if it does forwarding. > It would make little sense to have good RAs without being backed by a > good dynamic routing protocol, right? And, since other parts of this > dynamic routing would need Prefix Delegation (which is exclusively a > DHCP or OSPF feature, not RA), one may find that it may make little > sense for RA to provide routing. In some contexts where DHCP and OSPF > already prevail. DHCP configures hosts. DHCPv6-PD is an exception, since it configures a router. There is little else in DHCP that configures routers. There was a long discussion on the DHC list about what DHCP configures. I don't know if consensus was reached. Guess that depends on who you ask as well... -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Fri Jan 10 01:35:22 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675201A1F33 for ; Fri, 10 Jan 2014 01:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z60ODqeevP5z for ; Fri, 10 Jan 2014 01:35:21 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 062121ACCEC for ; Fri, 10 Jan 2014 01:35:21 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id DE2979C; Fri, 10 Jan 2014 10:35:10 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DA1269A; Fri, 10 Jan 2014 10:35:10 +0100 (CET) Date: Fri, 10 Jan 2014 10:35:10 +0100 (CET) From: Mikael Abrahamsson To: Alexandru Petrescu In-Reply-To: <52CFBD08.3030100@gmail.com> Message-ID: References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7@nkgeml506-mbx.china.huawei.com> <52CEC7E4.8060103@inex.ie> <52CFBD08.3030100@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 09:35:22 -0000 On Fri, 10 Jan 2014, Alexandru Petrescu wrote: > Each of these suggest that the Server does know the prefixes on the link > on which the client is attached. I thought this was included by the DHCPv6 forwarding agent? So yes, it does. However, if you change the address of the default gateway then you need to reconfigure the DHCPv6 server. With RAs, you don't need to do that, this is now purely router configuration. -- Mikael Abrahamsson email: swmike@swm.pp.se From ales.vizdal@t-mobile.cz Fri Jan 10 01:56:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13EE81ADD9A for ; Fri, 10 Jan 2014 01:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.79 X-Spam-Level: X-Spam-Status: No, score=-0.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPW3uTyR1oDb for ; Fri, 10 Jan 2014 01:56:38 -0800 (PST) Received: from ctxmailhub.t-mobile.cz (ctxmailhub.t-mobile.cz [93.153.104.87]) by ietfa.amsl.com (Postfix) with ESMTP id 58ED21ACC82 for ; Fri, 10 Jan 2014 01:56:38 -0800 (PST) From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Alexandru Petrescu Date: Fri, 10 Jan 2014 10:56:26 +0100 Thread-Topic: [v6ops] control and security of DHCP Thread-Index: Ac8N6Cfsd0CJsfY/QsaYhG/O7r7IcAAAMACA Message-ID: <1808340F7EC362469DDFFB112B37E2FCDA31A30F7D@SRVHKE02.rdm.cz> References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CEA1D2.3000109@gmail.com> <52CEB2D6.9070608@gmail.com> <52CEB727.1050701@gmail.com> <52CEBB02.7050000@gmail.com> <1808340F7EC362469DDFFB112B37E2FCDA31A30EB0@SRVHKE02.rdm.cz> <52CFB794.6080203@gmail.com> In-Reply-To: <52CFB794.6080203@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-loop: 2 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 09:56:40 -0000 > -----Original Message----- > From: Alexandru Petrescu > [mailto:alexandru.petrescu@gmail.com] > Sent: Friday, January 10, 2014 10:04 AM > To: V=EDzdal Ale=B9; Mikael Abrahamsson > Cc: v6ops@ietf.org > Subject: Re: [v6ops] control and security of DHCP >=20 > Le 09/01/2014 18:08, V=EDzdal Ale=B9 a =E9crit : > >> -----Original Message----- > >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of > Alexandru > >> Petrescu > >> Sent: Thursday, January 09, 2014 4:07 PM > >> To: Mikael Abrahamsson > >> Cc: v6ops@ietf.org > >> Subject: Re: [v6ops] control and security of DHCP > >> > >> Le 09/01/2014 15:52, Mikael Abrahamsson a =E9crit : > >>> On Thu, 9 Jan 2014, Alexandru Petrescu wrote: > > > >> I meant to say it would be good to have > >> > >> - a RA bit to state that DHCPv6 is the only way to get > routing > >> information (as there is a bit to state that DHCP is > the only way > >> to > >> get an address.) > > > > There is no routing delivered by DHCPv6 as it is by design > delivering > > no routing information, it's done by the RAs. >=20 > Well it's good to have principles like that, but is one > really sure. >=20 > Would address selection policy qualify as part or some form > of some routing information? >=20 > Similary, would Prefix Delegation qualify as parts of routing > information? >=20 > I would say yes they qualify and yes they are delivered by > DHCP; and seem to be exceptions to the rule that DHCP design > is not delivering routing information. >=20 > Alex DHCP-PD is delivering a Prefix (an IP resource), so in my eyes DHCP-PD is n= ot providing routing. Following your generalisation, you could say that DHCPv4 is providing an ad= dress that is installed=20 into the routing table, so it is providing a routing information, so DHCPv4= is a routing protocol. Let's stop it here.=20 > >> Alex > > > > Ales Ales From alexandru.petrescu@gmail.com Fri Jan 10 01:58:38 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8791AD9B7 for ; Fri, 10 Jan 2014 01:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n65ZzB9TH8Zs for ; Fri, 10 Jan 2014 01:58:37 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id C1DBB1ACC82 for ; Fri, 10 Jan 2014 01:58:36 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s0A9wQ5b013057 for ; Fri, 10 Jan 2014 10:58:26 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 762F520156E for ; Fri, 10 Jan 2014 10:59:28 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5EB1C2070E1 for ; Fri, 10 Jan 2014 10:59:28 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s0A9wMXa030338 for ; Fri, 10 Jan 2014 10:58:25 +0100 Message-ID: <52CFC43E.10009@gmail.com> Date: Fri, 10 Jan 2014 10:58:22 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7@nkgeml506-mbx.china.huawei.com> <52CEC7E4.8060103@inex.ie> <52CEFA3F.4050603@fud.no> In-Reply-To: <52CEFA3F.4050603@fud.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 09:58:38 -0000 Le 09/01/2014 20:36, Tore Anderson a écrit : > * Nick Hilliard > >> Can you provide a reference for the assumption that the host will define >> the netmask to be /128 if it receives an address assignment from DHCPv6 >> without a specific subnet mask assignment via RA? > > http://tools.ietf.org/search/rfc5942#section-5 That to me reads that some wrong implementations wrongly assume the prefix length of a link when RA doesnt tell it. And the solution to that to be to put the prefix length in the RA and use it. I agree with the first part and partially with the second part. Alex > > Tore > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From alexandru.petrescu@gmail.com Fri Jan 10 02:06:37 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437B91ADF59 for ; Fri, 10 Jan 2014 02:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7VbLTPwljTQ for ; Fri, 10 Jan 2014 02:06:36 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id ACEA11ADF28 for ; Fri, 10 Jan 2014 02:06:35 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s0AA6PtZ028724; Fri, 10 Jan 2014 11:06:25 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C1371207084; Fri, 10 Jan 2014 11:07:27 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B512920705C; Fri, 10 Jan 2014 11:07:27 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s0AA6LBh006900; Fri, 10 Jan 2014 11:06:25 +0100 Message-ID: <52CFC61D.8090100@gmail.com> Date: Fri, 10 Jan 2014 11:06:21 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7@nkgeml506-mbx.china.huawei.com> <52CEC7E4.8060103@inex.ie> <52CFBD08.3030100@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 10:06:37 -0000 Le 10/01/2014 10:35, Mikael Abrahamsson a écrit : > On Fri, 10 Jan 2014, Alexandru Petrescu wrote: > >> Each of these suggest that the Server does know the prefixes on >> the link on which the client is attached. > > I thought this was included by the DHCPv6 forwarding agent? One of them yes (the last cited paragraph). But the other paragraphs no. For example it is the Server which assigns the address (not the Relay) and it is the server which must decide whether or not the temporary, or the already existing, are relevant within a subnet ('prefix length') or not. It can only do that if it compares the prefix length of the address with a prefix length pre-stored in a configuration file. > So yes, it does. > > However, if you change the address of the default gateway then you > need to reconfigure the DHCPv6 server. With RAs, you don't need to > do that, this is now purely router configuration. I agree with this point. If one changes the Router, or its interface, one is forced to update the conf file of the DHCP server. Compared to RA mechanism this change necessity is an inconvenient (RA allows to change routers and a bit automatically get that new IP address to the client). Alex > From alexandru.petrescu@gmail.com Fri Jan 10 02:07:55 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A6E1AD8F6 for ; Fri, 10 Jan 2014 02:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.683 X-Spam-Level: X-Spam-Status: No, score=-4.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbX0bmw0CyMR for ; Fri, 10 Jan 2014 02:07:54 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2627F1ACD04 for ; Fri, 10 Jan 2014 02:07:53 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s0AA7h1m005695; Fri, 10 Jan 2014 11:07:43 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D4853207084; Fri, 10 Jan 2014 11:08:45 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C928D201547; Fri, 10 Jan 2014 11:08:45 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s0AA7hap008100; Fri, 10 Jan 2014 11:07:43 +0100 Message-ID: <52CFC66F.8060509@gmail.com> Date: Fri, 10 Jan 2014 11:07:43 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: =?ISO-8859-2?Q?V=EDzdal_Ale=B9?= References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CEA1D2.3000109@gmail.com> <52CEB2D6.9070608@gmail.com> <52CEB727.1050701@gmail.com> <52CEBB02.7050000@gmail.com> <1808340F7EC362469DDFFB112B37E2FCDA31A30EB0@SRVHKE02.rdm.cz> <52CFB794.6080203@gmail.com> <1808340F7EC362469DDFFB112B37E2FCDA31A30F7D@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCDA31A30F7D@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 10:07:56 -0000 Le 10/01/2014 10:56, Vízdal Ale¹ a écrit : >> -----Original Message----- >> From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] >> Sent: Friday, January 10, 2014 10:04 AM >> To: Vízdal Ale¹; Mikael Abrahamsson >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] control and security of DHCP >> >> Le 09/01/2014 18:08, Vízdal Ale¹ a écrit : >>>> -----Original Message----- >>>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of >> Alexandru >>>> Petrescu >>>> Sent: Thursday, January 09, 2014 4:07 PM >>>> To: Mikael Abrahamsson >>>> Cc: v6ops@ietf.org >>>> Subject: Re: [v6ops] control and security of DHCP >>>> >>>> Le 09/01/2014 15:52, Mikael Abrahamsson a écrit : >>>>> On Thu, 9 Jan 2014, Alexandru Petrescu wrote: >>> >>>> I meant to say it would be good to have >>>> >>>> - a RA bit to state that DHCPv6 is the only way to get >> routing >>>> information (as there is a bit to state that DHCP is >> the only way >>>> to >>>> get an address.) >>> >>> There is no routing delivered by DHCPv6 as it is by design >> delivering >>> no routing information, it's done by the RAs. >> >> Well it's good to have principles like that, but is one >> really sure. >> >> Would address selection policy qualify as part or some form >> of some routing information? >> >> Similary, would Prefix Delegation qualify as parts of routing >> information? >> >> I would say yes they qualify and yes they are delivered by >> DHCP; and seem to be exceptions to the rule that DHCP design >> is not delivering routing information. >> >> Alex > > DHCP-PD is delivering a Prefix (an IP resource), so in my eyes DHCP-PD is not providing routing. Well, when one tries to build more expanded and dynamic networks with DHCP and RA one notices all these routing complexities and looses many of the hardcoded principles. > Following your generalisation, you could say that DHCPv4 is providing an address that is installed > into the routing table, so it is providing a routing information, so DHCPv4 is a routing protocol. > > Let's stop it here. Ok. Alex > >>>> Alex >>> >>> Ales > > Ales > > From gert@Space.Net Fri Jan 10 02:14:29 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43401ACD04 for ; Fri, 10 Jan 2014 02:14:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9_kAYnviCTdc for ; Fri, 10 Jan 2014 02:14:27 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9E71AD8F6 for ; Fri, 10 Jan 2014 02:14:27 -0800 (PST) Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id F2A56604E6 for ; Fri, 10 Jan 2014 11:14:16 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id CC76D6049E for ; Fri, 10 Jan 2014 11:14:16 +0100 (CET) Received: (qmail 54012 invoked by uid 1007); 10 Jan 2014 11:14:16 +0100 Date: Fri, 10 Jan 2014 11:14:16 +0100 From: Gert Doering To: Alexandru Petrescu Message-ID: <20140110101416.GI40453@Space.Net> References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CEA1D2.3000109@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PW0Eas8rCkcu1VkF" Content-Disposition: inline In-Reply-To: <52CEA1D2.3000109@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" , Pete Vickers Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 10:14:30 -0000 --PW0Eas8rCkcu1VkF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Jan 09, 2014 at 02:19:14PM +0100, Alexandru Petrescu wrote: > One would not appreciate an RA to allow an arbitrary Client to configure= =20 > an IP address. If one did so, then there is a security risk: the Client= =20 > is able to listen at IP level everything else in that network. This is= =20 > a huge risk. The client is able to listen to everything else in that network, even if it has no IP or IPv6 address at all. It does not even have to have a MAC address to listen. Please. Some reality check. Just a little bit. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --PW0Eas8rCkcu1VkF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBUs/H+N9WwGXkzn/FAQLKxxAAssu7fWJdvGWSigmGQpObVkIA35fxp99K W3hDvZCS5EUDwRdHlg7EgmQ1eetjImnHCmRmbwUs/5ofB9c9aVhozThIi1h/FC7W X8mgerBhKPcnXL+2t3lIdYpAV1mm7fWoGV0PAxWcpRHrCUL16yL32kkkmoLnIQKs WrfgSpD1XdVEZ7hpKbgbF6qaYzkEgLsoqYB0S1bHCXuR46BDlb6V3Spktx32LQiK aYxkBt8+rN9hnsDhzsA2a8nw4IEjeiWfOqnGnNVZjde4+pRdt8ZIfFNvp9vaYElA 4rNsYNKImXhbNBZW0jVaRRq7IYNogruCQhcEaXmIzyefoVcsC5jgr5ToigbOEihi gbKw/BZBH9LaryqWdRdhIwPxR3OPCv9enQqxZXDbwTQAVg+JyncJx8cva/0W8Q7R 9uLGXLsMilxwpf6687grkDzeYfvrZFCHm0vHrg9o3xHSNzV30W55I2O9pD+8XDuZ eVuLWXRPMi7vQsxby5eKS/WJkJDtmkxjlwL9AOSb71ZQCAK8S2h04skWPFH7NHqC FTKgjhiYE8BamUwyHy+QFDsMMMI4EKGWt3lhI01tJ0KKu5kPwGAPex6Z90mgSE4p NiketFzEve4AH6tELefBs0eCg5cImGf463bjtkwCXXowcUDxEzrMch6kLyJ5tI4y s5S+zgrgE74= =7dGZ -----END PGP SIGNATURE----- --PW0Eas8rCkcu1VkF-- From alexandru.petrescu@gmail.com Fri Jan 10 02:17:21 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2881A8033 for ; Fri, 10 Jan 2014 02:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNrYgJNX0yKN for ; Fri, 10 Jan 2014 02:17:19 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 4583A1A8026 for ; Fri, 10 Jan 2014 02:17:19 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s0AAH8xk031303; Fri, 10 Jan 2014 11:17:08 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 12B08207057; Fri, 10 Jan 2014 11:18:11 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0715F2070ED; Fri, 10 Jan 2014 11:18:11 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s0AAH4Qe016975; Fri, 10 Jan 2014 11:17:08 +0100 Message-ID: <52CFC8A0.2050207@gmail.com> Date: Fri, 10 Jan 2014 11:17:04 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CEA1D2.3000109@gmail.com> <52CEA420.5020305@fud.no> <52CEB1EE.1070708@gmail.com> <52CEB6C1.8050105@gmail.com> <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 10:17:21 -0000 Le 10/01/2014 10:31, Mikael Abrahamsson a écrit : > On Fri, 10 Jan 2014, Alexandru Petrescu wrote: > >> Yes. link-specific vs network-specific I suppose? >> >> Isn't MTU part of PMTUD which is network-specific? > > No, MTU is by definiteion link-specific. I know the principle yes, a link's MTU is link-specific. But this does not forbid clients to try to figure out the MTU of an entire path. PMTUD Path MTU Discovery is such a thing, works with ICMP messages which are not restricted to one single link. > A network can choose to run the > same MTU everywhere, but it's still decided on a per-link basis. YEs, except that that decision is not communicated to Clients and they may need it, because rarely Clients talk to others just on same link. >> DHCP seems a good fit to provide MTU as well. > > *Sigh*. No, it doesn't. MTU is derived from settings on the router. This > is why RA is a great fit, as the router sends the RAs and can derive the > MTU settings from it's interface setting. In order for this to work > decently, the DHCPv6 forwarding agent in the router would have to gain > functionality to re-write MTU if it does forwarding. A-ha. >> It would make little sense to have good RAs without being backed by a >> good dynamic routing protocol, right? And, since other parts of this >> dynamic routing would need Prefix Delegation (which is exclusively a >> DHCP or OSPF feature, not RA), one may find that it may make little >> sense for RA to provide routing. In some contexts where DHCP and OSPF >> already prevail. > > DHCP configures hosts. DHCPv6-PD is an exception, since it configures a > router. There is little else in DHCP that configures routers. One other principle that has many exceptions. DHCPv6-PD configures routers which act as hosts as well. > There was a long discussion on the DHC list about what DHCP configures. > I don't know if consensus was reached. Guess that depends on who you ask > as well... I agree with you on that. Alex > From alexandru.petrescu@gmail.com Fri Jan 10 02:19:21 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0F61ADFA1 for ; Fri, 10 Jan 2014 02:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uc-S2rTCp81 for ; Fri, 10 Jan 2014 02:19:19 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id CE3861ADF98 for ; Fri, 10 Jan 2014 02:19:18 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s0AAJ8Go010300; Fri, 10 Jan 2014 11:19:08 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 57E5B200C1D; Fri, 10 Jan 2014 11:20:10 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 40060203952; Fri, 10 Jan 2014 11:20:10 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s0AAJ76b018667; Fri, 10 Jan 2014 11:19:07 +0100 Message-ID: <52CFC91B.8000302@gmail.com> Date: Fri, 10 Jan 2014 11:19:07 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Gert Doering References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CEA1D2.3000109@gmail.com> <20140110101416.GI40453@Space.Net> In-Reply-To: <20140110101416.GI40453@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" , Pete Vickers Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 10:19:21 -0000 Le 10/01/2014 11:14, Gert Doering a écrit : > Hi, > > On Thu, Jan 09, 2014 at 02:19:14PM +0100, Alexandru Petrescu wrote: >> One would not appreciate an RA to allow an arbitrary Client to configure >> an IP address. If one did so, then there is a security risk: the Client >> is able to listen at IP level everything else in that network. This is >> a huge risk. > > The client is able to listen to everything else in that network, even > if it has no IP or IPv6 address at all. It does not even have to have > a MAC address to listen. YEs and no, depends on many things. It may listed without even having a MAC address, and it will get noticed. Also, without a MAC address it may listen but hear less than if it had a MAC address. Alex > > Please. Some reality check. Just a little bit. > > Gert Doering > -- NetMaster > From peter.vickers@gmail.com Fri Jan 10 02:20:15 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F6F1ADFA1 for ; Fri, 10 Jan 2014 02:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0qXwFMz34Lj for ; Fri, 10 Jan 2014 02:20:13 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 075121ADF9D for ; Fri, 10 Jan 2014 02:20:12 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id c11so3244315lbj.15 for ; Fri, 10 Jan 2014 02:20:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IrMaIafYyaKumK9IKfs5OA5rkdvJ1ycdW7q1OdC7RCg=; b=dv/A4fnnwlBTrMVzx7kGvFYcRayRRQYQKpCb/Z6f/9tXRnrb/xEc2gqHXic/Ko+uEN VQEPxPtVnmGY54dIJmuONJzJWSGG6m8I4i47jjpOEfvASrFXmVIKwKyCyaJvswQrt3jK mC5aGNfYySrs/+sD5LWjZYbaVJ12clc+toAqdvmH54zYqddZUrSUVMX+VI2aCuVGepn5 d5aq2Iaynxap6eHgNR+mvuAIneQKxonouuSErv/u7dRQ1FPs39GzFl6rjyixk8NXZ+ef HbUhM1fHfVqgfqfKwF24kpS51DVQbKJzLZCLM46xFg6KwM6+PPFVHWKfFyHSt3FFz5PQ 8kQA== X-Received: by 10.152.87.211 with SMTP id ba19mr3416725lab.13.1389349202472; Fri, 10 Jan 2014 02:20:02 -0800 (PST) Received: from [192.0.2.116] ([87.248.7.97]) by mx.google.com with ESMTPSA id c15sm3069981lbq.11.2014.01.10.02.20.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 Jan 2014 02:20:02 -0800 (PST) Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Pete Vickers In-Reply-To: <52CFB8D5.70900@gmail.com> Date: Fri, 10 Jan 2014 11:20:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CEA1D2.3000109@gmail.com> <52CEA420.5020305@fud.no> <52CEB1EE.1070708@gmail.com> <52CEB6C1.8050105@gmail.com> <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1510) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 10:20:15 -0000 After my last email, I have yet to see a reply with any valid reason [1] = for not using RAs in addition to DHCPv6 for completing host = configuration at a site where DHCPv6 is desired. If someone is = squirreling one away, I'd love to hear it. Otherwise, I don't see the = problem with deploying (existing) standards compliant solutions. The IPv6 protocol suite is complex enough as it is today, so why make it = unnecessarily more complicated by adding duplicate functionality without = good (documented) reason. The recent discussions have shown that = existing options (in RA and RFC defined host behaviour) seem to give = more than enough flexibility to give Ops staff the tools to achieve = connectivity goals. A router is going to have a _much_ better idea of the network = infrastructure's topology, availability and configuration, than a remote = (DHCP) server - and is therefore a much better source of relevant = network information to advise hosts (via RAs). Even in DHCPv4 it is = common to provide a HSRP/VRRP IPv4 address as the default gateway, and = thus essentially delegating that 'configuration option' to the router(s) = not DHCP server.=20 It would have been a very different history if site Ops had said "we're = not moving from (e.g.) IPX to IPv4, since XYZ-IPX-specific-feature works = in a different way'. We need to take a more pragmatic approach to such = migrations if we're ever to actually achieve it. [1] DHCP is realistically a (great) convience tool rather a security = tool. There is little that DHCP can do that you cannot alternatively do = via manual host configuration. The withholding of a suitable IPv* address for a network that a host is = already connected to, is merely security through obscurity and as such a = very poor (although arguably populate) imitation. As others have = pointed out here, merely guessing a random MAC with a popular vendor's = OUI could easily defeat such 'security' hurdels. It is clearly documented from numerous sources that proper 'first layer' = network security can be achieved by a blend of physical security (wired = ports), and/or appropriate solutions such as 802.1x and switch/AP = configuration; and then complemented where necessary via encryption & = AAA etc etc etc. as per organisation's security policy. /Pete On 10. jan. 2014, at 10:09, Alexandru Petrescu = wrote: > Le 09/01/2014 18:15, V=EDzdal Ale=B9 a =E9crit : >>> -----Original Message----- >>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of >>> Alexandru Petrescu >>> Sent: Thursday, January 09, 2014 3:49 PM >>> To: Mikael Abrahamsson >>> Cc: v6ops@ietf.org; Pete Vickers >>> Subject: Re: [v6ops] control and security of DHCP >>>=20 >>> Le 09/01/2014 15:33, Mikael Abrahamsson a =E9crit : >>>> On Thu, 9 Jan 2014, Alexandru Petrescu wrote: >>>>=20 >>>>> But why should there be a PIO in the RA if nobody is >>> allowed to use >>>>> it anyway for configuring an address? Noise? >>>>=20 >>>> RA is used for routing. >>>=20 >>> Well, that's a principle put very briefly, but in details one >>> may notice that RA is used for other less-routingly aspects >>> such as MTU which is a pure local variable. (and which DHCP >>> doesnt do either). >>=20 >> As MTU is usually link specific, RA/ICMPv6 seems to be a good fit. >=20 > Yes. link-specific vs network-specific I suppose? >=20 > Isn't MTU part of PMTUD which is network-specific? >=20 > DHCP seems a good fit to provide MTU as well. >=20 >>>> The only mechanism that can configure routing is RA. >>>=20 >>> Well, as you discuss, it reads head-on with a routing >>> protocol... Many say that it is not that good for RA to >>> configure routing. >>>=20 >>> Actually, if you take your statement that RA is used to >>> configure routing and extend it to new work at IETF, you'd >>> realize that RA is claimed to do routing which is actually >>> very little of more real routing. >>>=20 >>> RA does routing without computing shortest paths, without >>> avoiding loops, without avoiding split horizon, without >>> converging, without exchanging route databases, etc. >>=20 >> RA does provide the host with routing information. It is not a = dynamic >> routing protocol as per your description above. >=20 > Right, but routing would not work without a good dynamic routing = protocol. >=20 > It would make little sense to have good RAs without being backed by a = good dynamic routing protocol, right? And, since other parts of this = dynamic routing would need Prefix Delegation (which is exclusively a = DHCP or OSPF feature, not RA), one may find that it may make little = sense for RA to provide routing. In some contexts where DHCP and OSPF = already prevail. >=20 > Alex >=20 >>=20 >>> Alex >>=20 >> Ales >>=20 >>=20 >=20 >=20 From gert@Space.Net Fri Jan 10 03:19:57 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC8F1ADBC7 for ; Fri, 10 Jan 2014 03:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cq1bzswQir_y for ; Fri, 10 Jan 2014 03:19:56 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 821A41AD7BE for ; Fri, 10 Jan 2014 03:19:55 -0800 (PST) Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 3886E60944 for ; Fri, 10 Jan 2014 12:19:45 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 1C86D607FD for ; Fri, 10 Jan 2014 12:19:45 +0100 (CET) Received: (qmail 78184 invoked by uid 1007); 10 Jan 2014 12:19:45 +0100 Date: Fri, 10 Jan 2014 12:19:45 +0100 From: Gert Doering To: Alexandru Petrescu Message-ID: <20140110111945.GK40453@Space.Net> References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CEA1D2.3000109@gmail.com> <20140110101416.GI40453@Space.Net> <52CFC91B.8000302@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UlxN1C6awaFNesUv" Content-Disposition: inline In-Reply-To: <52CFC91B.8000302@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" , Pete Vickers Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 11:19:58 -0000 --UlxN1C6awaFNesUv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Jan 10, 2014 at 11:19:07AM +0100, Alexandru Petrescu wrote: > Also, without a MAC address it may listen but hear less than if it had a= =20 > MAC address. Get a basic networking course. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --UlxN1C6awaFNesUv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBUs/XUN9WwGXkzn/FAQK9zg//fe0+Bygm0rVsMF42SnEQ0usb5S5pkb4c khgWR/XQXyUxhlUZIrbZ3PtKZiJC+2OPqBY16HeIn556YL6f5kK1hqy/vC1LBuDs UvQcR9WL/LbdXmYtYJ+83yWIcrRzSLknWtTDUbhY9pbIgsz07rfWzX7ecfjoNAIe l8i68+P4BgGS0RGn02wr+U3Kh+hL9cdw7WacdLMmIfugFJKWmAqXQMj2o8R1dpbb z7vTT0HOBIvIl8SC0++2mIVUOZSgvWxB+q3lDsMFej/nvyMPafKMv/+pKsBpObmp 7bucZP3CqD3TfXYb/+Y9So9cDjFC1axvPfpueHK2Rd+eTdNvvvxaUt6fNPHhxvGw /xmutWPv89JTXqroESqyCk2k4x2BdQzcCcF85uY4PSQHTFcQycSQst49zUdFRjIO oeJelSLBWU84nGhyRIJkHX+9zphEBZnuPrS5uY6mVmuN1VKhZKA6NSBA4X05XaTa gck3q2ySKZQh5g+MjktHc/PdgOMEuWQDWB7FnFY+LatFLAkEm9Q9hePOXw/M4ucT bj/ZKJBDjtNjR30xH1TjccM7K8corBAlKX3D79nrmd8EDPN6ZTPY9h/Yplbp6kBs Iz8UiCfxxJAnLIpHjk4x4Pi2sOrWVzbMLDudhzivpWuDjkxzSNajtlsHZR90vXUI EFw8n7Y07QE= =FfjG -----END PGP SIGNATURE----- --UlxN1C6awaFNesUv-- From alexandru.petrescu@gmail.com Fri Jan 10 03:39:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7FE91ADFBC for ; Fri, 10 Jan 2014 03:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55gxREad2tM2 for ; Fri, 10 Jan 2014 03:39:44 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 682111ACD00 for ; Fri, 10 Jan 2014 03:39:44 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s0ABdXIT010603; Fri, 10 Jan 2014 12:39:33 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DCAA120700F; Fri, 10 Jan 2014 12:40:35 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C57FF205F5A; Fri, 10 Jan 2014 12:40:35 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s0ABdJFG021644; Fri, 10 Jan 2014 12:39:33 +0100 Message-ID: <52CFDBE7.3030703@gmail.com> Date: Fri, 10 Jan 2014 12:39:19 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Gert Doering References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CEA1D2.3000109@gmail.com> <20140110101416.GI40453@Space.Net> <52CFC91B.8000302@gmail.com> <20140110111945.GK40453@Space.Net> In-Reply-To: <20140110111945.GK40453@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" , Pete Vickers Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 11:39:46 -0000 Le 10/01/2014 12:19, Gert Doering a écrit : > Hi, > > On Fri, Jan 10, 2014 at 11:19:07AM +0100, Alexandru Petrescu wrote: >> Also, without a MAC address it may listen but hear less than if it had a >> MAC address. > > Get a basic networking course. Hmm, is this some arrogance? Alex > > Gert Doering > -- NetMaster > From sthaug@nethelp.no Fri Jan 10 03:46:26 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92DB41ADFF2 for ; Fri, 10 Jan 2014 03:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33buG8MMljTr for ; Fri, 10 Jan 2014 03:46:24 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 5451E1ACD00 for ; Fri, 10 Jan 2014 03:46:23 -0800 (PST) Received: (qmail 86795 invoked from network); 10 Jan 2014 11:46:10 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 10 Jan 2014 11:46:10 -0000 Date: Fri, 10 Jan 2014 12:46:10 +0100 (CET) Message-Id: <20140110.124610.74672987.sthaug@nethelp.no> To: peter.vickers@gmail.com From: sthaug@nethelp.no In-Reply-To: References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 11:46:26 -0000 > The withholding of a suitable IPv* address for a network that a host is already connected to, is merely security through obscurity and as such a very poor (although arguably populate) imitation. As others have pointed out here, merely guessing a random MAC with a popular vendor's OUI could easily defeat such 'security' hurdels. Some of us run BRAS boxes where a customer simply won't be able to get on the net unless the BRAS relay agent has sent a DHCPACK to the customer. In such configurations it is *not* merely security by obscurity. I certainly agree that DHCP *by itself* doesn't prevent IP or MAC address spoofing. Steinar Haug, AS2116 From peter.vickers@gmail.com Fri Jan 10 06:10:57 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E29E31AE07D for ; Fri, 10 Jan 2014 06:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3S2ZyXyWHflI for ; Fri, 10 Jan 2014 06:10:56 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD741AE057 for ; Fri, 10 Jan 2014 06:10:55 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id l4so3453802lbv.27 for ; Fri, 10 Jan 2014 06:10:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DTFWmuwPPvFMso6znmnkAy9H8jNvQP5gVyOxWbN3OfU=; b=SCFbKIttESNpPiuBf6n4M7R0nEKwr57tH/TE3MkznvhVBKro5KBkKrLrBr6Do0yHYj pCUFUv5E3ugNEng6MXYKoZ4Wv2uYPEHbXs0hNjT98HU5KJYYlg+43vCmI7K3xsAIcj7N bZ5FAPhPRGHvMxNe3oiFUKa2hUKyOEv1Ty9CQlY0vj/HZieqZRVaNP4LgsSZ++3fXA5b c3OJmO7TyMQPkmvIEdJLNfm4vsVZ4IGa2Gb8fvTGVLVlwJNiQSzuLEwNsBH9Sz4xNaCt eseW8MKs2j+YMP8Bx2sXGD1iSdgfpyXTH9m76PMhuDpwk3alJCTI8ZV3PPh0SeZStwMu P+yQ== X-Received: by 10.152.10.10 with SMTP id e10mr3845983lab.56.1389363045075; Fri, 10 Jan 2014 06:10:45 -0800 (PST) Received: from [192.0.2.116] ([87.248.7.97]) by mx.google.com with ESMTPSA id tc8sm3458075lbb.9.2014.01.10.06.10.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 Jan 2014 06:10:44 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Pete Vickers In-Reply-To: <20140110.124610.74672987.sthaug@nethelp.no> Date: Fri, 10 Jan 2014 15:10:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> To: sthaug@nethelp.no X-Mailer: Apple Mail (2.1510) Cc: v6ops@ietf.org Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 14:10:58 -0000 On 10. jan. 2014, at 12:46, sthaug@nethelp.no wrote: >> The withholding of a suitable IPv* address for a network that a host = is already connected to, is merely security through obscurity and as = such a very poor (although arguably populate) imitation. As others have = pointed out here, merely guessing a random MAC with a popular vendor's = OUI could easily defeat such 'security' hurdels. >=20 > Some of us run BRAS boxes where a customer simply won't be able to get = on > the net unless the BRAS relay agent has sent a DHCPACK to the = customer. > In such configurations it is *not* merely security by obscurity. >=20 > I certainly agree that DHCP *by itself* doesn't prevent IP or MAC = address > spoofing. >=20 > Steinar Haug, AS2116 Sure, I agree port control that is tightly linked to specific DHCP = packet dialogue could limit the pre 'authorised' access. (although = rogues could potentially still listen, or even DoS your DHCP server). However if you're relying on MAC address to verify identity, then = consider that many/most ethernet devices have their MAC address declared = on the outside of the box, so this appears to me to be the same as = requiring users to write their non-expiring password on a post-it note = on their screen, where anyone can see and duplicate it. More relevant to the subject in hand, what is it that prevents your = users from utilising RAs to discover a default gateway (in addition to = address allocation via DHCPv6 ?) /Pete= From ietfc@btconnect.com Fri Jan 10 07:26:41 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894611AE0B6 for ; Fri, 10 Jan 2014 07:26:41 -0800 (PST) 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=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rL1sx9U6kjQX for ; Fri, 10 Jan 2014 07:26:38 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id A314A1AE06F for ; Fri, 10 Jan 2014 07:26:38 -0800 (PST) Received: from mail6-ch1-R.bigfish.com (10.43.68.231) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.22; Fri, 10 Jan 2014 15:26:28 +0000 Received: from mail6-ch1 (localhost [127.0.0.1]) by mail6-ch1-R.bigfish.com (Postfix) with ESMTP id 4069F800D8; Fri, 10 Jan 2014 15:26:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -16 X-BigFish: PS-16(zz98dI9371I542I1432I1418Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h20f7h2189h1d1ah1d2ah1fc6hzz1de098h1033IL8275bh8275dh1de097h186068hz2dh2a8h5a9h839h93fhd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah2222h224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h2218h2216h226dh22d0h2327h2336h2438h304l1d11m1155h) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(51704005)(51444003)(13464003)(377454003)(24454002)(189002)(199002)(74502001)(47446002)(74876001)(51856001)(89996001)(74662001)(44736004)(50226001)(88136002)(74706001)(46102001)(31966008)(77096001)(77156001)(33646001)(76796001)(50466002)(76786001)(74366001)(83072002)(80976001)(85852003)(90146001)(56816005)(87976001)(49866001)(87286001)(4396001)(47736001)(23676002)(47976001)(87266001)(50986001)(85306002)(81342001)(47776003)(63696002)(54316002)(14496001)(59766001)(77982001)(44716002)(79102001)(62236002)(56776001)(83322001)(19580405001)(19580395003)(69226001)(65816001)(53806001)(61296002)(84392001)(42186004)(15975445006)(66066001)(76482001)(80022001)(81542001)(62966002)(92566001)(92726001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB060; H:AMXPRD0310HT002.eurprd03.prod.outlook.com; CLIP:157.56.248.133; FPR:; RD:InfoNoRecords; MX:1; A:0; LANG:en; Received: from mail6-ch1 (localhost.localdomain [127.0.0.1]) by mail6-ch1 (MessageSwitch) id 1389367586526431_32160; Fri, 10 Jan 2014 15:26:26 +0000 (UTC) Received: from CH1EHSMHS021.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252]) by mail6-ch1.bigfish.com (Postfix) with ESMTP id 716C3340047; Fri, 10 Jan 2014 15:26:26 +0000 (UTC) Received: from AM2PRD0710HT001.eurprd07.prod.outlook.com (157.56.249.213) by CH1EHSMHS021.bigfish.com (10.43.70.21) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 10 Jan 2014 15:26:26 +0000 Received: from DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) by AM2PRD0710HT001.eurprd07.prod.outlook.com (10.255.165.36) with Microsoft SMTP Server (TLS) id 14.16.395.1; Fri, 10 Jan 2014 15:26:25 +0000 Received: from AMXPRD0310HT002.eurprd03.prod.outlook.com (157.56.248.133) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.842.7; Fri, 10 Jan 2014 15:26:24 +0000 Message-ID: <00cb01cf0e17$c6591fc0$4001a8c0@gateway.2wire.net> From: t.petch To: Lorenzo Colitti References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7@nkgeml506-mbx.china.huawei.com> <52CEC7E4.8060103@inex.ie> <52CEF448.4020900@inex.ie> Date: Fri, 10 Jan 2014 15:22:20 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.133] X-ClientProxiedBy: DB3PR07CA010.eurprd07.prod.outlook.com (10.242.134.50) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Forefront-PRVS: 00872B689F X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: v6ops@ietf.org Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 15:26:41 -0000 Lorenzo At some point, when this text has stabilized, I think that you must change the word 'routing'. I appreciate that this word is being used extensively in these threads and we all know that it does not mean routing; but for the world at large, this will be just another source of confusion around IPv6. Partly it is that in many if not most I-D, routing is distinguished from forwarding and it is forwarding that is being discussed here. More importantly, both routing and forwarding are functions of routers. If you have no routing, then you have no routers and no network and we can end this discussion! Rather it is the inability of DHCP to provide a forwarding (routing:-( table entry, or a default route or a route for any other prefix, that is being discussed. Tom Petch ----- Original Message ----- From: "Lorenzo Colitti" To: "Nick Hilliard" Cc: ; Sent: Friday, January 10, 2014 3:17 AM > On Fri, Jan 10, 2014 at 4:11 AM, Nick Hilliard wrote: > > > > I get zero hits on the word "netmask" in RFC3315. DHCPv6 will hand out > > > addresses, which in IPv6 implicitly is a /128? > > > > It's context / configuration dependent. If the interface already has an > > address+netmask configured which contains the address received from DHCP, > > then local connectivity will work just fine. > > > > Correct, but that's already covered in the proposed text, which is as > follows. The text basically says "to use addresses to talk to anything > that's not yourself, you need routing; you can't get configure via DHCPv6; > you can configure routing by doing X, Y, and Z)". X, Y and Z does not > include manual configuration, because people seemed to feel that manual > configuration is not recommended and thus should not be included in an > operational guidance document, but we could certainly add it if there's > consensus to do so. > > ==== > 3.2. Guidance for DHCPv6-only Deployment > > Some networks prefer central management of all IP addressing. These > networks may want to assign addresses only via DHCPv6. > > This can be accomplished by sending an RA that indicates that DHCPv6 > address assignment is available (i.e., M=1), installing DHCPv6 servers or > DHCPv6 relays on all links, and setting A=0 in the Prefix Information > Options of all prefixes in the RA. > > Note that an RA is still necessary in order for hosts to be able to use > these addresses. This is for two reasons: > > 1. Per problem #1, if there is no RA, some hosts will not attempt to obtain > address configuration via DHCPv6. > > 2. DHCPv6 can assign addresses but not routing. Hosts can acquire routing > information by accepting RA messages with a nonzero Router Lifetime, Prefix > Information Options with L=1, or Route Information Options. Without > routing, IPv6 addresses won't be used for commmunication outside the host. > Thus, for example, if there is no RA and no static routing, then addresses > assigned by DHCPv6 cannot be used even for communication between hosts on > the same link. > > Also note that unlike SLAAC, DHCPv6 is not a strict requirement for IPv6 > hosts [RFC6434], and some nodes do not support DHCPv6. Thus, this model can > only be used if all the hosts that need IPv6 connectivity support DHCPv6. > > Per problem #2, if the administrators want to switch the DHCPv6-only > configured hosts to SLAAC-only, this is not possible on some hosts without > manually changing the hosts' configuration or using additional management > tools. > > Per problem #4, for some platforms, the A flag and O flag might not be > independent, when SLAAC is off, a stand-alone stateless DHCPv6 session > would not be applicable. However, this might not be a common use case. > ==== > ------------------------------------------------------------------------ -------- > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nick@foobar.org Fri Jan 10 07:45:38 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB181AE0D6 for ; Fri, 10 Jan 2014 07:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WrXvZy8eWL8 for ; Fri, 10 Jan 2014 07:45:36 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 29D621AE0B6 for ; Fri, 10 Jan 2014 07:45:35 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id s0AFjMPs097033 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 10 Jan 2014 15:45:22 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host pancake.netability.ie [87.198.142.197] claimed to be crumpet.local Message-ID: <52D0157D.6040009@foobar.org> Date: Fri, 10 Jan 2014 15:45:01 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Pete Vickers References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> In-Reply-To: <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 15:45:38 -0000 On 10/01/2014 14:10, Pete Vickers wrote: > More relevant to the subject in hand, what is it that prevents your > users from utilising RAs to discover a default gateway (in addition to > address allocation via DHCPv6 ?) The RA model is critically weak regarding security. In a shared tenant l2 domain, a single rogue RA packet can wipe out connectivity for an entire network within nanoseconds. At least in the IPv4 world where we use DHCP, an unprotected rogue DHCP server can be detected in human time and cannot take out an entire network with a single unsolicited packet, even if it might do a small amount of damage before the rogue server is taken out of operation. With the current RA model, the only way to prevent this is to ensure that the l2 edge is fully secured against RA leaks. Most shared L2 domain networking equipment does not support this at the moment (VM hypervisors are what concern me right now, but the problem is not limited to just them). Consequently the requirement for hosts to listen to and act on RAs means that dynamically configured IPv6 is largely undeployable in shared tenant configurations. Even if RA guard were ubiquitous, the RA model will never have functional defence in depth or damage limitation capabilities which means that it will always be highly susceptible to operator error. As a separate issue, we need to stop pretending that SEND will be a cure for this problem because apart from anything else it's completely impractical. I don't want my routers' control planes processing thousands of pps of encrypted NS/ND for the thousands or tens of thousands of connected hosts that they will be handling, and that's assuming there will ever be widespread support for SEND - which is not at all clear at this point. I find this behaviour mode of RAs to be deeply harmful and this is the reason I do not wish my tenant hosts to listen to RAs in the first place. RAs may be fine for many situations, but not for this one. Whether people like this or not, this works well with the dhcp model in ipv4. If the same capabilities were available in ipv6, it would be vastly preferable to RAs from a technical point of view. Nick From swmike@swm.pp.se Fri Jan 10 07:54:48 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5D21AE089 for ; Fri, 10 Jan 2014 07:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.389 X-Spam-Level: X-Spam-Status: No, score=-4.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNJ-q_FvDAnR for ; Fri, 10 Jan 2014 07:54:46 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 58EAA1AE097 for ; Fri, 10 Jan 2014 07:54:46 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 248749C; Fri, 10 Jan 2014 16:54:35 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1F1929A; Fri, 10 Jan 2014 16:54:35 +0100 (CET) Date: Fri, 10 Jan 2014 16:54:35 +0100 (CET) From: Mikael Abrahamsson To: Nick Hilliard In-Reply-To: <52D0157D.6040009@foobar.org> Message-ID: References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 15:54:48 -0000 On Fri, 10 Jan 2014, Nick Hilliard wrote: > The RA model is critically weak regarding security. In a shared tenant l2 > domain, a single rogue RA packet can wipe out connectivity for an entire > network within nanoseconds. At least in the IPv4 world where we use DHCP, > an unprotected rogue DHCP server can be detected in human time and cannot > take out an entire network with a single unsolicited packet, even if it > might do a small amount of damage before the rogue server is taken out of > operation. Yet IPv4 has the same kind of problems, like gratuitous ARP or L2 spoofing, or whatever. So unless you secure against these, you're screwed. So whilst I will agree that SEND isn't a good solution, the only way to fix this is to actually implement L2 equipment doing L3 inspection and security, both for IPv4 and for IPv6. Yes this is a problem, but it's not a motivator to implement handing out routing via DHCPv6. -- Mikael Abrahamsson email: swmike@swm.pp.se From nick@foobar.org Fri Jan 10 07:56:33 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15281AE0DA for ; Fri, 10 Jan 2014 07:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awexkwxsRaZz for ; Fri, 10 Jan 2014 07:56:31 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 62C351AE0D6 for ; Fri, 10 Jan 2014 07:56:31 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id s0AFuJxd097227 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 10 Jan 2014 15:56:19 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host pancake.netability.ie [87.198.142.197] claimed to be crumpet.local Message-ID: <52D0180D.6030505@foobar.org> Date: Fri, 10 Jan 2014 15:55:57 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 15:56:33 -0000 On 10/01/2014 15:54, Mikael Abrahamsson wrote: > So whilst I will agree that SEND isn't a good solution, the only way to fix > this is to actually implement L2 equipment doing L3 inspection and > security, both for IPv4 and for IPv6. Yes this is a problem, but it's not a > motivator to implement handing out routing via DHCPv6. Then we need to politely disagree on this point. Nick From Fred.L.Templin@boeing.com Fri Jan 10 08:01:11 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C001AE0EB for ; Fri, 10 Jan 2014 08:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_UFEMKEKuLO for ; Fri, 10 Jan 2014 08:01:09 -0800 (PST) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id A30DF1AE0E7 for ; Fri, 10 Jan 2014 08:01:09 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s0AG0xFJ027884; Fri, 10 Jan 2014 10:00:59 -0600 Received: from XCH-PHX-310.sw.nos.boeing.com (xch-phx-310.sw.nos.boeing.com [130.247.25.169]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s0AG0w07027870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 10 Jan 2014 10:00:58 -0600 Received: from XCH-BLV-405.nw.nos.boeing.com (130.247.25.158) by XCH-PHX-310.sw.nos.boeing.com (130.247.25.169) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Jan 2014 08:00:57 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.203]) by XCH-BLV-405.nw.nos.boeing.com ([169.254.5.142]) with mapi id 14.03.0158.001; Fri, 10 Jan 2014 08:00:56 -0800 From: "Templin, Fred L" To: Alexandru Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet) Thread-Index: AQHPDeTPxP36KFapgEy8h/U9IKX/EJp+GvgQ Date: Fri, 10 Jan 2014 16:00:56 +0000 Message-ID: <2134F8430051B64F815C691A62D9831819663D@XCH-BLV-504.nw.nos.boeing.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <20140107104001.GM81676@Space.Net> <72626BC4-CB9E-49E8-8A54-48A141F52C0C@nominum.com> <6A64F619-4A0E-423A-A5E7-4C3234B461AE@nominum.com> <1389261993.72423.YahooMailNeo@web161906.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D98318193C5C@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D98318193CD6@XCH-BLV-504.nw.nos.boeing.com> <597F58BD-DCEA-4C4E-B7AB-DCCB416B3CFD@ecs.soton.ac.uk> <2134F8430051B64F815C691A62D98318193D30@XCH-BLV-504.nw.nos.boei! ng.com> <52CFBAB4.4040105@gmail.com> In-Reply-To: <52CFBAB4.4040105@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Subject: Re: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 16:01:12 -0000 Hi Alex, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petres= cu > Sent: Friday, January 10, 2014 1:18 AM > To: v6ops@ietf.org > Subject: Re: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as th= ey didn't IPv4, IPX, XNS, or > DECNet) >=20 > Le 09/01/2014 18:28, Templin, Fred L a =E9crit : > > Hi Tim, > > > >> -----Original Message----- From: Tim Chown > >> [mailto:tjc@ecs.soton.ac.uk] Sent: Thursday, January 09, 2014 9:24 > >> AM To: Templin, Fred L Cc: Mark ZZZ Smith; Randy Bush; Ted Lemon; > >> v6ops@ietf.org Subject: Re: [v6ops] Enterprises won't deploy IPv6 > >> for IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet) > >> > >> > >> On 9 Jan 2014, at 17:21, "Templin, Fred L" > >> wrote: > >> > >>> Hi Tim, > >>> > >>>> The campus wireless solutions I've seen from vendors to date > >>>> that support IPv6 do some "interesting" things to support > >>>> devices roaming between IPv6 wireless subnets. They certainly > >>>> don't seem to use MIPv6, rather it seems common to use either > >>>> unicast RAs and/or L2 tunnelling between controllers. e.g. see > >>> > >>> http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0= 080bae506.shtml#mobility. > >>> > >>> > >>> > I am thinking of mobiles that have WiFi plus 3G/4G. When the mobile is > >>> in proximity of my enterprise infrastructure then it can > >>> certainly be managed as it hops between WLCs as you suggest. But, > >>> when the mobile leaves the campus and goes in via a Starbucks > >>> WiFi (or maybe my home WiFi) it is beyond the management realm of > >>> the enterprise and has to do something if it wants to maintain a > >>> stable IP address/subnet. Or, if the mobile goes off the "WiFi > >>> grid" it has to fire up its 3G/4G link and then still somehow > >>> maintain stability. > >> > >> MPTCP? A la Siri on iOS7 etc :) > > > > That won't get me to a mobile router - it only addresses the apps on > > the mobile itself. >=20 > YEs, and only apps using a particular transport protocols, not all. >=20 > (and yes the news of MPTCP at Apple is encouraging about that > particular protocol). >=20 > > > >>> This is not about MIPv6 - it is about AERO: > >> > >> Well, the thread is about something else, so back to that.... > > > > The thread is about IPv6 deployment in enterprise networks. AERO is > > about IPv6 deployment in enterprise networks (which should also be > > taken as input to your IPv6 enterprise deployment doc). >=20 > Right. But since this thread relates to the DHCP discussion, would AERO > have an aspect related to DHCP? Or to RA? How would an AERO > Router self-configure its address, its mobile network prefix and its > default route? Would it accept many combinations or just one? AERO certainly has aspects related to both DHCP and RA. AERO nodes are all routers (not hosts) and so they would use DHCP as requesting routers for Prefix Delegation but not for address configuration. And, they would use unicast RS/RA for neighbor cache and default route maintenance to their default router. AERO nodes self-configure link-local addresses through the AERO address format specified in the document. AERO nodes only assign link-local addresses to their AERO interfaces; they do not assign addresses of other scopes. AERO nodes connect IPv6 end user networks to the AERO link, and use the AERO link only as transit to get to other IPv6 networks. AERO nodes use unicast IPv6 ND for neighbor cache maintenance and route optimization. That is it in a nutshell. Reading and understanding this is enough basis for understanding the document as a whole. Thanks - Fred fred.l.templin@boeing.com =20 > Alex >=20 > > > > Thanks - Fred fred.l.templin@boeing.com > > > >> Tim > >> > >>> > >>> http://tools.ietf.org/html/draft-templin-aerolink > >>> > >>> Thanks - Fred fred.l.templin@boeing.com > >>> > >>> PS I shouldn't have to ask, but please keep this as plaintext > >>> instead of converting to something else. > > > > _______________________________________________ v6ops mailing list > > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > > > >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From alexandru.petrescu@gmail.com Fri Jan 10 08:18:51 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF731ADF82 for ; Fri, 10 Jan 2014 08:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoVLuvcz__iP for ; Fri, 10 Jan 2014 08:18:47 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id E05381AE0D9 for ; Fri, 10 Jan 2014 08:18:45 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s0AGIVad007079; Fri, 10 Jan 2014 17:18:31 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 231D02073EA; Fri, 10 Jan 2014 17:19:34 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 17028206FFE; Fri, 10 Jan 2014 17:19:34 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s0AGIRUW000331; Fri, 10 Jan 2014 17:18:31 +0100 Message-ID: <52D01D53.60107@gmail.com> Date: Fri, 10 Jan 2014 17:18:27 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Templin, Fred L" , "v6ops@ietf.org" References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <72626BC4-CB9E-49E8-8A54-48A141F52C0C@nominum.com> <6A64F619-4A0E-423A-A5E7-4C3234B461AE@nominum.com> <1389261993.72423.YahooMailNeo@web161906.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D98318193C5C@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D98318193CD6@XCH-BLV-504.nw.nos.boeing.com> <597F58BD-DCEA-4C4E-B7AB-DCCB416B3CFD@ecs.soton.ac.uk> <2134F8430051B64F815C691A62D98318193D30@XCH-BLV-504.nw.nos.boei! ng.com> <52CFBAB4.4040105@gmail.com> <2134F8430051B64F815C691A62D9831819663D@XCH-BLV-504.nw.nos.boeing! .com> In-Reply-To: <2134F8430051B64F815C691A62D9831819663D@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 16:18:51 -0000 Le 10/01/2014 17:00, Templin, Fred L a écrit : > Hi Alex, > >> -----Original Message----- From: v6ops >> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: Friday, January 10, 2014 1:18 AM To: v6ops@ietf.org Subject: >> Re: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they >> didn't IPv4, IPX, XNS, or DECNet) >> >> Le 09/01/2014 18:28, Templin, Fred L a écrit : >>> Hi Tim, >>> >>>> -----Original Message----- From: Tim Chown >>>> [mailto:tjc@ecs.soton.ac.uk] Sent: Thursday, January 09, 2014 >>>> 9:24 AM To: Templin, Fred L Cc: Mark ZZZ Smith; Randy Bush; Ted >>>> Lemon; v6ops@ietf.org Subject: Re: [v6ops] Enterprises won't >>>> deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or >>>> DECNet) >>>> >>>> >>>> On 9 Jan 2014, at 17:21, "Templin, Fred L" >>>> wrote: >>>> >>>>> Hi Tim, >>>>> >>>>>> The campus wireless solutions I've seen from vendors to >>>>>> date that support IPv6 do some "interesting" things to >>>>>> support devices roaming between IPv6 wireless subnets. >>>>>> They certainly don't seem to use MIPv6, rather it seems >>>>>> common to use either unicast RAs and/or L2 tunnelling >>>>>> between controllers. e.g. see >>>>> >>>>> http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080bae506.shtml#mobility. >>>>> >>>>> >>>>> >> >>>>> I am thinking of mobiles that have WiFi plus 3G/4G. When the mobile is >>>>> in proximity of my enterprise infrastructure then it can >>>>> certainly be managed as it hops between WLCs as you suggest. >>>>> But, when the mobile leaves the campus and goes in via a >>>>> Starbucks WiFi (or maybe my home WiFi) it is beyond the >>>>> management realm of the enterprise and has to do something if >>>>> it wants to maintain a stable IP address/subnet. Or, if the >>>>> mobile goes off the "WiFi grid" it has to fire up its 3G/4G >>>>> link and then still somehow maintain stability. >>>> >>>> MPTCP? A la Siri on iOS7 etc :) >>> >>> That won't get me to a mobile router - it only addresses the apps >>> on the mobile itself. >> >> YEs, and only apps using a particular transport protocols, not >> all. >> >> (and yes the news of MPTCP at Apple is encouraging about that >> particular protocol). >> >>> >>>>> This is not about MIPv6 - it is about AERO: >>>> >>>> Well, the thread is about something else, so back to that.... >>> >>> The thread is about IPv6 deployment in enterprise networks. AERO >>> is about IPv6 deployment in enterprise networks (which should >>> also be taken as input to your IPv6 enterprise deployment doc). >> >> Right. But since this thread relates to the DHCP discussion, would >> AERO have an aspect related to DHCP? Or to RA? How would an AERO >> Router self-configure its address, its mobile network prefix and >> its default route? Would it accept many combinations or just one? > > AERO certainly has aspects related to both DHCP and RA. AERO nodes > are all routers (not hosts) and so they would use DHCP as requesting > routers for Prefix Delegation but not for address configuration. And, > they would use unicast RS/RA for neighbor cache and default route > maintenance to their default router. All while I understand what is said above, I wonder whether running two protocols simultaneously on slow AERO links is maybe little optimal, or not. Alex > > AERO nodes self-configure link-local addresses through the AERO > address format specified in the document. AERO nodes only assign > link-local addresses to their AERO interfaces; they do not assign > addresses of other scopes. AERO nodes connect IPv6 end user networks > to the AERO link, and use the AERO link only as transit to get to > other IPv6 networks. AERO nodes use unicast IPv6 ND for neighbor > cache maintenance and route optimization. > > That is it in a nutshell. Reading and understanding this is enough > basis for understanding the document as a whole. > > Thanks - Fred fred.l.templin@boeing.com > >> Alex >> >>> >>> Thanks - Fred fred.l.templin@boeing.com >>> >>>> Tim >>>> >>>>> >>>>> http://tools.ietf.org/html/draft-templin-aerolink >>>>> >>>>> Thanks - Fred fred.l.templin@boeing.com >>>>> >>>>> PS I shouldn't have to ask, but please keep this as >>>>> plaintext instead of converting to something else. >>> >>> _______________________________________________ v6ops mailing >>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>> >>> >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From Fred.L.Templin@boeing.com Fri Jan 10 08:38:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43631ACCE2 for ; Fri, 10 Jan 2014 08:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nllCqPujAGOu for ; Fri, 10 Jan 2014 08:38:06 -0800 (PST) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 003FB1ADF46 for ; Fri, 10 Jan 2014 08:38:05 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s0AGbuJB021189; Fri, 10 Jan 2014 08:37:56 -0800 Received: from XCH-PHX-413.sw.nos.boeing.com (xch-phx-413.sw.nos.boeing.com [10.57.37.45]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s0AGblwP021049 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 10 Jan 2014 08:37:47 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.203]) by XCH-PHX-413.sw.nos.boeing.com ([169.254.13.69]) with mapi id 14.03.0158.001; Fri, 10 Jan 2014 08:37:47 -0800 From: "Templin, Fred L" To: Alexandru Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet) Thread-Index: AQHPDh+XxP36KFapgEy8h/U9IKX/EJp+J3UA Date: Fri, 10 Jan 2014 16:37:46 +0000 Message-ID: <2134F8430051B64F815C691A62D9831819676E@XCH-BLV-504.nw.nos.boeing.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <72626BC4-CB9E-49E8-8A54-48A141F52C0C@nominum.com> <6A64F619-4A0E-423A-A5E7-4C3234B461AE@nominum.com> <1389261993.72423.YahooMailNeo@web161906.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D98318193C5C@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D98318193CD6@XCH-BLV-504.nw.nos.boeing.com> <597F58BD-DCEA-4C4E-B7AB-DCCB416B3CFD@ecs.soton.ac.uk> <2134F8430051B64F815C691A62D98318193D30@XCH-BLV-504.nw.nos.boei! ng.com> <52CFBAB4.4040105@gmail.com> <2134F8430051B64F815C691A62D9831819663D@XCH-BLV-504.nw.nos.boeing! .com> <52D01D53.60107@gmail.com> In-Reply-To: <52D01D53.60107@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Subject: Re: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 16:38:08 -0000 Hi Alex, > >> Right. But since this thread relates to the DHCP discussion, would > >> AERO have an aspect related to DHCP? Or to RA? How would an AERO > >> Router self-configure its address, its mobile network prefix and > >> its default route? Would it accept many combinations or just one? > > > > AERO certainly has aspects related to both DHCP and RA. AERO nodes > > are all routers (not hosts) and so they would use DHCP as requesting > > routers for Prefix Delegation but not for address configuration. And, > > they would use unicast RS/RA for neighbor cache and default route > > maintenance to their default router. >=20 > All while I understand what is said above, I wonder whether running two > protocols simultaneously on slow AERO links is maybe little optimal, or n= ot. I will give you that the AERO document is currently using RS/RA primarily because "it's there". For AERO, there is nothing magical about RS/RA that could not also be accommodated by NS/NA. But, we will certainly want DHCP-PD. Thanks - Fred fred.l.templin@boeing.com > Alex >=20 > > > > AERO nodes self-configure link-local addresses through the AERO > > address format specified in the document. AERO nodes only assign > > link-local addresses to their AERO interfaces; they do not assign > > addresses of other scopes. AERO nodes connect IPv6 end user networks > > to the AERO link, and use the AERO link only as transit to get to > > other IPv6 networks. AERO nodes use unicast IPv6 ND for neighbor > > cache maintenance and route optimization. From Fred.L.Templin@boeing.com Fri Jan 10 09:13:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FE61AE0D9 for ; Fri, 10 Jan 2014 09:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fia7Wkmz0D0X for ; Fri, 10 Jan 2014 09:13:50 -0800 (PST) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id D40101AE017 for ; Fri, 10 Jan 2014 09:13:50 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s0AHDfcq018073; Fri, 10 Jan 2014 09:13:41 -0800 Received: from XCH-PHX-210.sw.nos.boeing.com (xch-phx-210.sw.nos.boeing.com [130.247.25.65]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s0AHDXpa017978 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Fri, 10 Jan 2014 09:13:34 -0800 Received: from XCH-BLV-108.nw.nos.boeing.com (130.247.25.137) by XCH-PHX-210.sw.nos.boeing.com (130.247.25.65) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Jan 2014 09:13:33 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.203]) by XCH-BLV-108.nw.nos.boeing.com ([169.254.13.207]) with mapi id 14.03.0158.001; Fri, 10 Jan 2014 09:13:33 -0800 From: "Templin, Fred L" To: "v6ops@ietf.org" Thread-Topic: [v6ops] control and security of DHCP Thread-Index: AQHPDhyNvrqr7XBnbE2EhhsUuWc00Zp+L0+Q Date: Fri, 10 Jan 2014 17:13:32 +0000 Message-ID: <2134F8430051B64F815C691A62D98318196839@XCH-BLV-504.nw.nos.boeing.com> References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D0180D.6030505@foobar.org> In-Reply-To: <52D0180D.6030505@foobar.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 17:13:52 -0000 Hi, I am just beginning to get the flavor for this discussion but what I am finding lacking is a consideration for the _different link types_ for which DHCPv6 vs RS/RA would apply. For example, AERO links are link-local only an= d there is actually very little useful information that could be gotten from an RS/RA exchange that could not just as easily be gotten from NS/NA. There= , DHCPv6-PD may be all that is needed. Similarly, on managed network links DHCPv6 gives a central administrative control point for coordinating all of the managed links. So, what are the link types where we would expect to see RS/RA? Unmanaged edge links where visiting nodes come and go at random times? Others? Thanks - Fred fred.l.templin@boeing.com From Ted.Lemon@nominum.com Fri Jan 10 09:54:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D124E1AE145 for ; Fri, 10 Jan 2014 09:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhHAVslvh-fU for ; Fri, 10 Jan 2014 09:54:45 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0F91AE144 for ; Fri, 10 Jan 2014 09:54:45 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUtAz22CUgQ8xY92r2BHmSfvnCTDMhsaz@postini.com; Fri, 10 Jan 2014 09:54:36 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 622E01B80CC for ; Fri, 10 Jan 2014 09:54:35 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 43A2E19005C; Fri, 10 Jan 2014 09:54:35 -0800 (PST) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Jan 2014 09:54:35 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Fri, 10 Jan 2014 12:54:30 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 17:54:47 -0000 On Jan 10, 2014, at 10:54 AM, Mikael Abrahamsson = wrote: > On Fri, 10 Jan 2014, Nick Hilliard wrote: >=20 >> The RA model is critically weak regarding security. In a shared = tenant l2 >> domain, a single rogue RA packet can wipe out connectivity for an = entire >> network within nanoseconds. At least in the IPv4 world where we use = DHCP, >> an unprotected rogue DHCP server can be detected in human time and = cannot >> take out an entire network with a single unsolicited packet, even if = it >> might do a small amount of damage before the rogue server is taken = out of >> operation. >=20 > Yet IPv4 has the same kind of problems, like gratuitous ARP or L2 = spoofing, or whatever. So unless you secure against these, you're = screwed. Mikael, you've entirely missed Nick's point. A gratuitous RA can have = the effect he's talking about without any intentional action. In order = to take down an IPv4 network with ARP, you either have to have a device = configured to proxy arp, which is easy to detect and the effects of = which clear up rapidly, or else you have to have someone intentionally = attacking the network, which again is easy to detect and fix. I don't know how serious the problem Nick has described really is in = practice, but it is quite clearly different than the problem you are = talking about, and at least potentially does seem to have the impact = that Nick ascribes to it: that it makes multi-tenant networking more = expensive. From swmike@swm.pp.se Fri Jan 10 10:04:42 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5961AE150 for ; Fri, 10 Jan 2014 10:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=2.393] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UspPZiVPiep for ; Fri, 10 Jan 2014 10:04:40 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id EC23A1AE165 for ; Fri, 10 Jan 2014 10:04:39 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 472859C; Fri, 10 Jan 2014 19:04:29 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3AFE29A; Fri, 10 Jan 2014 19:04:29 +0100 (CET) Date: Fri, 10 Jan 2014 19:04:29 +0100 (CET) From: Mikael Abrahamsson To: Ted Lemon In-Reply-To: Message-ID: References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 18:04:42 -0000 On Fri, 10 Jan 2014, Ted Lemon wrote: > I don't know how serious the problem Nick has described really is in > practice, but it is quite clearly different than the problem you are > talking about, and at least potentially does seem to have the impact > that Nick ascribes to it: that it makes multi-tenant networking more > expensive. My point is that if you're building multi tenant networks without this kind of protection you're screwed for both IPv4 and IPv6. IPv6 is no worse than IPv4 in this aspect. http://secureenduserconnection.se/certifications/sec-access-certification/ There is a lot of stuff you need to do for both IPv4 and IPv6 in order to secure it. The document linked on the previous URL lists a lot of it. Direct URL to the document: This is SAVI stuff, but I'd still consider SAVI WG a fairly big fail since there is no activity now and yet when new standards are being developed, the SAVI WG working area isn't taken into account and its documents updated. -- Mikael Abrahamsson email: swmike@swm.pp.se From Ted.Lemon@nominum.com Fri Jan 10 10:09:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255951AE14E for ; Fri, 10 Jan 2014 10:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibykc0vlD4Qj for ; Fri, 10 Jan 2014 10:09:12 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id B8D0A1AE139 for ; Fri, 10 Jan 2014 10:09:11 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUtA3PYyKx6tFpay/nYuG7sTBZFeUrJ+4@postini.com; Fri, 10 Jan 2014 10:09:02 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id AB54E1B82C5 for ; Fri, 10 Jan 2014 10:09:01 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id A436919005C; Fri, 10 Jan 2014 10:09:01 -0800 (PST) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Jan 2014 10:09:01 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Fri, 10 Jan 2014 13:08:57 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <8EBE3D62-D6BA-470A-B9E4-E58B2C4ACB44@nominum.com> References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 18:09:13 -0000 On Jan 10, 2014, at 1:04 PM, Mikael Abrahamsson = wrote: > My point is that if you're building multi tenant networks without this = kind of protection you're screwed for both IPv4 and IPv6. IPv6 is no = worse than IPv4 in this aspect. I understood your point, but you are incorrect. The operational = characteristics of IPv4 and IPv6 in this context _are_ substantially = different. It's certainly true that it's better to keep tenants = isolated on their own networks if you can afford to do so, and it may be = that the IETF's answer is that if you can't afford to do so, tough luck. = But that doesn't mean the use case Nick has presented isn't a valid one = to consider. The IETF's response, should we choose not to address it, = should be "we've considered that, and don't think it's worth = addressing," not "that's not a problem." From swmike@swm.pp.se Fri Jan 10 10:14:02 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B588A1AE17E for ; Fri, 10 Jan 2014 10:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OF45pS7arZG5 for ; Fri, 10 Jan 2014 10:13:56 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id D634D1AE173 for ; Fri, 10 Jan 2014 10:13:53 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 48B68A1; Fri, 10 Jan 2014 19:13:43 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 43F9C9C; Fri, 10 Jan 2014 19:13:43 +0100 (CET) Date: Fri, 10 Jan 2014 19:13:43 +0100 (CET) From: Mikael Abrahamsson To: Ted Lemon In-Reply-To: <8EBE3D62-D6BA-470A-B9E4-E58B2C4ACB44@nominum.com> Message-ID: References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <8EBE3D62-D6BA-470A-B9E4-E58B2C4ACB44@nominum.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 18:14:02 -0000 On Fri, 10 Jan 2014, Ted Lemon wrote: > I understood your point, but you are incorrect. The operational > characteristics of IPv4 and IPv6 in this context _are_ substantially > different. It's certainly true that it's better to keep tenants > isolated on their own networks if you can afford to do so, and it may be > that the IETF's answer is that if you can't afford to do so, tough luck. > But that doesn't mean the use case Nick has presented isn't a valid one > to consider. The IETF's response, should we choose not to address it, > should be "we've considered that, and don't think it's worth > addressing," not "that's not a problem." I'm considering it a huge problem in both IPv4 and IPv6 and I consider operators deploying multi tentant networks without these security features as hugely irresponsible. However, using RA characteristics for this use-case as a reason to try to get default-route provisioning into DHCPv6 just doesn't make sense to me. Yes, it can be argued IPv6 might be a little worse than IPv4, but it's still "rock and a hard place" and the proper response is "secure your access", not "make it a little less sucky by putting default route provisioning into DHCPv6". -- Mikael Abrahamsson email: swmike@swm.pp.se From tore@fud.no Fri Jan 10 10:19:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348821AE103 for ; Fri, 10 Jan 2014 10:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viHwIiNjJ4yM for ; Fri, 10 Jan 2014 10:19:44 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) by ietfa.amsl.com (Postfix) with ESMTP id 3B99D1AE169 for ; Fri, 10 Jan 2014 10:19:43 -0800 (PST) Received: from [2a02:fe0:c410:1d30:21d:60ff:fe48:f59e] (port=35011 helo=wrath.fud.no) by greed.fud.no with esmtpa (Exim 4.80) (envelope-from ) id 1W1gg7-0005Ct-MC; Fri, 10 Jan 2014 19:19:31 +0100 Message-ID: <52D039B3.4020402@fud.no> Date: Fri, 10 Jan 2014 19:19:31 +0100 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nick Hilliard , Pete Vickers References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> In-Reply-To: <52D0157D.6040009@foobar.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 18:19:46 -0000 * Nick Hilliard > Consequently the requirement for hosts to listen to and act on RAs > means that dynamically configured IPv6 is largely undeployable in > shared tenant configurations. > > [...] > > I find this behaviour mode of RAs to be deeply harmful and this is > the reason I do not wish my tenant hosts to listen to RAs in the > first place. RAs may be fine for many situations, but not for this > one. Your tenant hosts are in all likelihood *already* soliciting and listening for RAs, and acting on any they receive. This means that deploying IPv6 in your network is actually *increasing* the chance for a rogue RA attack (deliberate or accidental) to be successful, as the false information in the rogue RA does not have to contend with any true information your routers would provide. > Whether people like this or not, this works well with the dhcp model > in ipv4. If the same capabilities were available in ipv6, it would > be vastly preferable to RAs from a technical point of view. Extending DHCPv6 to have feature parity with DHCPv4 (i.e., providing a default router option and a on-link prefix option), would not help you at all with the problem you described above, as your tenants would still be soliciting and listening for and acting on the (rogue) RAs. Unless if what you are actually proposing is to also completely deprecate the RS/RA part of ND? Tore From gert@Space.Net Fri Jan 10 10:30:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428F71AE1BA for ; Fri, 10 Jan 2014 10:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQ4KWjpAyckt for ; Fri, 10 Jan 2014 10:30:05 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 2470C1AE037 for ; Fri, 10 Jan 2014 10:29:59 -0800 (PST) Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 4DCC5604FD for ; Fri, 10 Jan 2014 19:29:49 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 172446046A for ; Fri, 10 Jan 2014 19:29:49 +0100 (CET) Received: (qmail 43242 invoked by uid 1007); 10 Jan 2014 19:29:48 +0100 Date: Fri, 10 Jan 2014 19:29:48 +0100 From: Gert Doering To: Tore Anderson Message-ID: <20140110182948.GQ40453@Space.Net> References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D039B3.4020402@fud.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52D039B3.4020402@fud.no> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org, Pete Vickers Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 18:30:08 -0000 Hi, On Fri, Jan 10, 2014 at 07:19:31PM +0100, Tore Anderson wrote: > Extending DHCPv6 to have feature parity with DHCPv4 (i.e., providing a > default router option and a on-link prefix option), would not help you > at all with the problem you described above, as your tenants would still > be soliciting and listening for and acting on the (rogue) RAs. Unless if > what you are actually proposing is to also completely deprecate the > RS/RA part of ND? For Nick's use case, configuring all his systems with the equivalent of accept_ra=0 and having address + prefix information in DHCPv6 would work, and be safe against rogue RAs (as in "rogue RAs are just ignored, and machines still get addresses and know their local neighbours"). Default-Route could be manually set to fe80::1234 which would then be the VRRP address used in every single VLAN (something you can't do with IPv4). Default-Route in DHCPv6 would provide more flexibility in assigning different default gateways for different machines, but I'm not sure *Nick* mentioned that as a desired use case. So I'm nearly convinced that having on-link prefix information in DHCPv6 is good (after all, the DHCPv6 server has to know this *anyway* to pick the proper address range...). Default-Route still reeks of "we did it that way in DHCPv4!"... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From joelja@bogus.com Fri Jan 10 10:38:31 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0241ADFB9 for ; Fri, 10 Jan 2014 10:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIq2hcnyQVRy for ; Fri, 10 Jan 2014 10:38:29 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id AF6201AE09F for ; Fri, 10 Jan 2014 10:38:29 -0800 (PST) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s0AIc28B076934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 10 Jan 2014 18:38:02 GMT (envelope-from joelja@bogus.com) Message-ID: <52D03E04.10207@bogus.com> Date: Fri, 10 Jan 2014 10:37:56 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: Tore Anderson , Nick Hilliard , Pete Vickers References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D039B3.4020402@fud.no> In-Reply-To: <52D039B3.4020402@fud.no> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QOxPK0uh6sblBG8WolCUDvEIKeC8t2sgS" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Fri, 10 Jan 2014 18:38:03 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 18:38:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QOxPK0uh6sblBG8WolCUDvEIKeC8t2sgS Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1/10/14, 10:19 AM, Tore Anderson wrote: > Extending DHCPv6 to have feature parity with DHCPv4 (i.e., providing a > default router option and a on-link prefix option), would not help you > at all with the problem you described above, as your tenants would stil= l > be soliciting and listening for and acting on the (rogue) RAs. Unless i= f > what you are actually proposing is to also completely deprecate the > RS/RA part of ND? If you goal is to use DHCPv6 exclusively you have to ignore them. which also gets you back to the IPv4 problem of there's no basis for deciding when to stop sending DHCP requests if you hear nothing. > Tore > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --QOxPK0uh6sblBG8WolCUDvEIKeC8t2sgS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLQPgQACgkQ8AA1q7Z/VrJlvQCfZW5KhX0h2x/73t8DNAmZ8BKB Mo0An1JAF7rdzfycDwn0kTxybwpVTNec =MrTl -----END PGP SIGNATURE----- --QOxPK0uh6sblBG8WolCUDvEIKeC8t2sgS-- From gert@Space.Net Fri Jan 10 10:41:11 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53FF21AE1AD for ; Fri, 10 Jan 2014 10:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEGuiu1hakXg for ; Fri, 10 Jan 2014 10:41:10 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC081ADFB9 for ; Fri, 10 Jan 2014 10:41:10 -0800 (PST) Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id CE20F604FD for ; Fri, 10 Jan 2014 19:40:59 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id AC016604B0 for ; Fri, 10 Jan 2014 19:40:59 +0100 (CET) Received: (qmail 48161 invoked by uid 1007); 10 Jan 2014 19:40:59 +0100 Date: Fri, 10 Jan 2014 19:40:59 +0100 From: Gert Doering To: joel jaeggli Message-ID: <20140110184059.GR40453@Space.Net> References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D039B3.4020402@fud.no> <52D03E04.10207@bogus.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3rMDlCEgcaHQQFB+" Content-Disposition: inline In-Reply-To: <52D03E04.10207@bogus.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org, Tore Anderson , Pete Vickers Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 18:41:11 -0000 --3rMDlCEgcaHQQFB+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Jan 10, 2014 at 10:37:56AM -0800, joel jaeggli wrote: > If you goal is to use DHCPv6 exclusively you have to ignore them. which > also gets you back to the IPv4 problem of there's no basis for deciding > when to stop sending DHCP requests if you hear nothing. Nick's use case is fairly specific. "If you want to live in my datacenter, these are the rules: do not listen to RA, use DHCPv6". This can be done. For a generic use case "here's my mobile device, I attach it to your=20 network, now I have to figure out whether this is RA, RA+DHCPv6, no-RA with DHCPv6, or no IPv6 at all" there is madness. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --3rMDlCEgcaHQQFB+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBUtA+u99WwGXkzn/FAQIEaw/7ByWMA0WDqpWL0irbJMfYmt2EZUMJW9J1 XpQQFJuGb3dQkxsBuYGv1OswDeXfH2hXeRjEpcX6kTwkbQKRLIOJBi5zfmqR3JMr kSk5B22oTeUm1F2HaqOlBuCfYamPhV7+eROfWBm0cTf0N9Z3VQKHJtEy4vKsqay0 rsdSrRiA1fwmhaGPCOlbO40G6pSTymqZ+M7zAueMTg0QVapEX9oIJZIsjZX3rqL+ HPka5XVu0Ap0YWaHgzmKAns9Pu3dtDtrWBHu6jAMMhWUbIqWIAoZ+hPQ0DCtKJLT oq4bvlxus/eRZCcIJw6z8tvBw0/ksOka+GOzpzv7lG+ZH8b09pAAbm/aV3E+/oKu DEOWq294UlLwudYiocJJ4CYQLfmGid3AKcBL/MFj0SO8ErfuprXvE8/Db3EQOJI0 BHlibRhh5CWpOosABfqfb9kG3YtK8nDrMlYQATI+aSuyNcb358XFe3+rBcEaioxG EO1UYn3TkLTVtbRJkGzHDL0JxKAQMNykM9HGpr8OZe8KXJ/n2Er1wrAAOcEnfGUz SdCueRji4wt/HxhdHwj0xxKC60Ep2Op8QebWbC0AcpXCf3o9VyyAEh/9fzrlfcJi IFTRHS5s9VGSBL0hJbX3YtgIkFJqgKyUYoatO5GDREt4q4QS0BhJypOqwicVUzlS iIuqtQZTD10= =LnpC -----END PGP SIGNATURE----- --3rMDlCEgcaHQQFB+-- From simon.perreault@viagenie.ca Fri Jan 10 10:42:29 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49191AE1C3 for ; Fri, 10 Jan 2014 10:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDRjbf0JzJgh for ; Fri, 10 Jan 2014 10:42:19 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB6C1AE191 for ; Fri, 10 Jan 2014 10:42:18 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 79D3A40372 for ; Fri, 10 Jan 2014 13:42:08 -0500 (EST) Message-ID: <52D03F00.4010206@viagenie.ca> Date: Fri, 10 Jan 2014 13:42:08 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D039B3.4020402@fud.no> <52D03E04.10207@bogus.com> In-Reply-To: <52D03E04.10207@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 18:42:30 -0000 Le 2014-01-10 13:37, joel jaeggli a écrit : > If you goal is to use DHCPv6 exclusively you have to ignore them. which > also gets you back to the IPv4 problem of there's no basis for deciding > when to stop sending DHCP requests if you hear nothing. Would you consider SOL_MAX_RT [RFC7083] a sufficient solution? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From swmike@swm.pp.se Fri Jan 10 10:46:01 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BA51AE17F for ; Fri, 10 Jan 2014 10:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.389 X-Spam-Level: X-Spam-Status: No, score=-4.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBm-qfWIYSsG for ; Fri, 10 Jan 2014 10:45:57 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 260411ADFF3 for ; Fri, 10 Jan 2014 10:45:57 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id AC6379C; Fri, 10 Jan 2014 19:45:46 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9C7769A; Fri, 10 Jan 2014 19:45:46 +0100 (CET) Date: Fri, 10 Jan 2014 19:45:46 +0100 (CET) From: Mikael Abrahamsson To: Gert Doering In-Reply-To: <20140110184059.GR40453@Space.Net> Message-ID: References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D039B3.4020402@fud.no> <52D03E04.10207@bogus.com> <20140110184059.GR40453@Space.Net> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org, Tore Anderson , Pete Vickers Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 18:46:01 -0000 On Fri, 10 Jan 2014, Gert Doering wrote: > Nick's use case is fairly specific. "If you want to live in my datacenter, > these are the rules: do not listen to RA, use DHCPv6". > > This can be done. Yes, but without intelligent inspection of RAs in the L2 network, there is basically no way to verify that this actually is the way things are configured. There are no RAs for a year, then a misconfiguration causes an RA to be emitted and then you find 5% of the machines in the DC haven't been configured to ignore RAs, and will now configure themselves by listening to this RA message. This there is an absolute need to inspect traffic in the L2 network and thus the whole "I want a way to do this that doesn't suck when I don't have this L2 inspection functionality" falls flat imnho. -- Mikael Abrahamsson email: swmike@swm.pp.se From joelja@bogus.com Fri Jan 10 10:48:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C28D1AE18D for ; Fri, 10 Jan 2014 10:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzY4o4owy_FZ for ; Fri, 10 Jan 2014 10:48:45 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id CAC1C1AE17F for ; Fri, 10 Jan 2014 10:48:45 -0800 (PST) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s0AImKHj077015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 10 Jan 2014 18:48:20 GMT (envelope-from joelja@bogus.com) Message-ID: <52D0406E.5000007@bogus.com> Date: Fri, 10 Jan 2014 10:48:14 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: Gert Doering References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D039B3.4020402@fud.no> <52D03E04.10207@bogus.com> <20140110184059.GR40453@Space.Net> In-Reply-To: <20140110184059.GR40453@Space.Net> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EI2CQnKm0u8bjrane3cjwuS5tqGkilix2" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Fri, 10 Jan 2014 18:48:21 +0000 (UTC) Cc: v6ops@ietf.org, Tore Anderson , Pete Vickers Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 18:48:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EI2CQnKm0u8bjrane3cjwuS5tqGkilix2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1/10/14, 10:40 AM, Gert Doering wrote: > Hi, >=20 > On Fri, Jan 10, 2014 at 10:37:56AM -0800, joel jaeggli wrote: >> If you goal is to use DHCPv6 exclusively you have to ignore them. whic= h >> also gets you back to the IPv4 problem of there's no basis for decidin= g >> when to stop sending DHCP requests if you hear nothing. >=20 > Nick's use case is fairly specific. "If you want to live in my datacen= ter, > these are the rules: do not listen to RA, use DHCPv6". >=20 > This can be done. Right, I don't need permission to stop listening for RAs today, I can just do it. > For a generic use case "here's my mobile device, I attach it to your=20 > network, now I have to figure out whether this is RA, RA+DHCPv6, no-RA > with DHCPv6, or no IPv6 at all" there is madness. One could imagine for example a dhcpv6 option to stop listening for RAs. But that's after this process has already occurred. > Gert Doering > -- NetMaster >=20 --EI2CQnKm0u8bjrane3cjwuS5tqGkilix2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLQQG4ACgkQ8AA1q7Z/VrI2kgCfeSExnMYLO8uEV4gxO4xyGnfG pgIAn3Zb++40bm3BS6Lv4/T+8ZJLJUd3 =BWrt -----END PGP SIGNATURE----- --EI2CQnKm0u8bjrane3cjwuS5tqGkilix2-- From joelja@bogus.com Fri Jan 10 11:08:16 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474AC1AE148 for ; Fri, 10 Jan 2014 11:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzlENppS9H3x for ; Fri, 10 Jan 2014 11:08:15 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id E2D6D1AE12E for ; Fri, 10 Jan 2014 11:08:14 -0800 (PST) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s0AJ7xYB077098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 10 Jan 2014 19:08:00 GMT (envelope-from joelja@bogus.com) Message-ID: <52D0450A.2010707@bogus.com> Date: Fri, 10 Jan 2014 11:07:54 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: Mikael Abrahamsson , Gert Doering References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D039B3.4020402@fud.no> <52D03E04.10207@bogus.com> <20140110184059.GR40453@Space.Net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1LPF8S5gs55ITHRXIux7nWLcdUAbn6vfC" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Fri, 10 Jan 2014 19:08:00 +0000 (UTC) Cc: v6ops@ietf.org, Tore Anderson , Pete Vickers Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 19:08:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1LPF8S5gs55ITHRXIux7nWLcdUAbn6vfC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1/10/14, 10:45 AM, Mikael Abrahamsson wrote: > On Fri, 10 Jan 2014, Gert Doering wrote: >=20 >> Nick's use case is fairly specific. "If you want to live in my >> datacenter, >> these are the rules: do not listen to RA, use DHCPv6". >> >> This can be done. >=20 > Yes, but without intelligent inspection of RAs in the L2 network, there= > is basically no way to verify that this actually is the way things are > configured. There are no RAs for a year, then a misconfiguration causes= > an RA to be emitted and then you find 5% of the machines in the DC > haven't been configured to ignore RAs, and will now configure themselve= s > by listening to this RA message. Today (baring deliberate action) you'll probably find 100% of them listening for RAs, which is either great because your deployment is going to be a lot easier when you get to the edge, a ticking bomb, or bot= h. Which is at least partly why this is sitting with the RFC editor right no= w. https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-implications-on-ip= v4-nets/ That is clearly not an IPv6 deployment solution. > This there is an absolute need to inspect traffic in the L2 network and= > thus the whole "I want a way to do this that doesn't suck when I don't > have this L2 inspection functionality" falls flat imnho. If you find it necessary to do that for IPv4 I have no doubt that you will find it necessary for IPv6. There are other approaches, such as limiting the diameter of the broadcast domain to a point you find acceptable that might also be appropriate, if not always feasible. --1LPF8S5gs55ITHRXIux7nWLcdUAbn6vfC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLQRQoACgkQ8AA1q7Z/VrJRYgCdFwLeNDc5WZSsCiP15+DLsc1m tgwAn39UjUnCPqc6rU7LhMawLTcctYZi =dyXO -----END PGP SIGNATURE----- --1LPF8S5gs55ITHRXIux7nWLcdUAbn6vfC-- From Ted.Lemon@nominum.com Fri Jan 10 11:25:00 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A870F1AE1C4 for ; Fri, 10 Jan 2014 11:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaRgTpF4SNAn for ; Fri, 10 Jan 2014 11:24:59 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 63D121AE1AD for ; Fri, 10 Jan 2014 11:24:59 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUtBJATE1KIxBS//fYaaAiSTxspaTkrr8@postini.com; Fri, 10 Jan 2014 11:24:49 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 1CFB81B82C5 for ; Fri, 10 Jan 2014 11:24:49 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id EFC0919005C; Fri, 10 Jan 2014 11:24:48 -0800 (PST) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Jan 2014 11:24:48 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Fri, 10 Jan 2014 14:24:41 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <663703AB-95AC-4A36-8C39-2BA5D81AA79B@nominum.com> References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <8EBE3D62-D6BA-470A-B9E4-E58B2C4ACB44@nominum.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 19:25:00 -0000 On Jan 10, 2014, at 1:13 PM, Mikael Abrahamsson = wrote: > However, using RA characteristics for this use-case as a reason to try = to get default-route provisioning into DHCPv6 just doesn't make sense to = me. This is the wrong way to think about it. It _is_ a use case. So you = shouldn't argue that it's not a use case. It may not be sufficient = motivation to justify using DHCPv6 to deliver router information, but = that's a different question. If we keep muddling it all together into = the same pot, we will never be able to come to a clear conclusion in = this discussion. > Yes, it can be argued IPv6 might be a little worse than IPv4, but it's = still "rock and a hard place" and the proper response is "secure your = access", not "make it a little less sucky by putting default route = provisioning into DHCPv6". You could make the case that this is the proper response, but that's = what you need to do. I think there's a fairly strong case to be made, = since the privacy implications of two service providers being on the = same wire are potentially dire. From Ted.Lemon@nominum.com Fri Jan 10 11:26:56 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53BE1AE073 for ; Fri, 10 Jan 2014 11:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RV2SfCu-NbAj for ; Fri, 10 Jan 2014 11:26:55 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 491431AE0CC for ; Fri, 10 Jan 2014 11:26:55 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUtBJdVnVxnwTP7HK1SWa4LW47X58JDdl@postini.com; Fri, 10 Jan 2014 11:26:45 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4D9431B82C5 for ; Fri, 10 Jan 2014 11:26:45 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 46DEF19005C; Fri, 10 Jan 2014 11:26:45 -0800 (PST) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Jan 2014 11:26:45 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Fri, 10 Jan 2014 14:26:39 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <686D3F1E-F356-4872-94E3-F27A3E35D6C3@nominum.com> References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D039B3.4020402@fud.no> <52D03E04.10207@bogus.com> <20140110184059.GR40453@Space.Net> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "v6ops@ietf.org WG" , Tore Anderson , Pete Vickers Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 19:26:57 -0000 On Jan 10, 2014, at 1:45 PM, Mikael Abrahamsson = wrote: > Yes, but without intelligent inspection of RAs in the L2 network, = there is basically no way to verify that this actually is the way things = are configured. There are no RAs for a year, then a misconfiguration = causes an RA to be emitted and then you find 5% of the machines in the = DC haven't been configured to ignore RAs, and will now configure = themselves by listening to this RA message. Or you could configure a host to send black-hole RAs all the time... :) From tore@fud.no Fri Jan 10 11:32:48 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595A81AE072 for ; Fri, 10 Jan 2014 11:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3Qyk5q88QUq for ; Fri, 10 Jan 2014 11:32:46 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) by ietfa.amsl.com (Postfix) with ESMTP id 447151AE058 for ; Fri, 10 Jan 2014 11:32:45 -0800 (PST) Received: from [2a02:fe0:c410:1d30:21d:60ff:fe48:f59e] (port=35455 helo=wrath.fud.no) by greed.fud.no with esmtpa (Exim 4.80) (envelope-from ) id 1W1hoo-0001e5-Gw; Fri, 10 Jan 2014 20:32:34 +0100 Message-ID: <52D04AD2.2010403@fud.no> Date: Fri, 10 Jan 2014 20:32:34 +0100 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Gert Doering References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D039B3.4020402@fud.no> <20140110182948.GQ40453@Space.Net> In-Reply-To: <20140110182948.GQ40453@Space.Net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Pete Vickers Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 19:32:48 -0000 * Gert Doering > On Fri, Jan 10, 2014 at 07:19:31PM +0100, Tore Anderson wrote: >> Extending DHCPv6 to have feature parity with DHCPv4 (i.e., providing a >> default router option and a on-link prefix option), would not help you >> at all with the problem you described above, as your tenants would still >> be soliciting and listening for and acting on the (rogue) RAs. Unless if >> what you are actually proposing is to also completely deprecate the >> RS/RA part of ND? > > For Nick's use case, configuring all his systems with the equivalent > of accept_ra=0 and having address + prefix information in DHCPv6 would > work, and be safe against rogue RAs (as in "rogue RAs are just ignored, and > machines still get addresses and know their local neighbours"). I am making the assumption that Nick cannot change accept_ra=0 on his tentants' hosts, because he have no control over them. If Nick do control his tenants' hosts, nobody is stopping him from using a DHCPv6 implementation that can signal a default route and an on-link prefix in non-standard options. (IIRC two separate DHCPv6 implementations with this capability have been mentioned on this list recently.) Two consenting DHCPv6 implementations can do what they want in the privacy of their own data centre. In a similar vein, I generally turn off RA processing on servers configured statically via Puppet (even though tenants do not share layer 2 domains in my data centres - VLANs are cheap). The fact that the IETF has not yet standardised IPv6 configuration using Puppet has so far not been a hindrance to my IPv6 deployment. Tore From swmike@swm.pp.se Fri Jan 10 11:40:23 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8752E1AE1C1 for ; Fri, 10 Jan 2014 11:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.389 X-Spam-Level: X-Spam-Status: No, score=-4.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHaGwuZvlzo3 for ; Fri, 10 Jan 2014 11:40:21 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5718B1ADFB2 for ; Fri, 10 Jan 2014 11:40:21 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C47059C; Fri, 10 Jan 2014 20:40:10 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id C0B549A; Fri, 10 Jan 2014 20:40:10 +0100 (CET) Date: Fri, 10 Jan 2014 20:40:10 +0100 (CET) From: Mikael Abrahamsson To: Ted Lemon In-Reply-To: <663703AB-95AC-4A36-8C39-2BA5D81AA79B@nominum.com> Message-ID: References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <8EBE3D62-D6BA-470A-B9E4-E58B2C4ACB44@nominum.com> <663703AB-95AC-4A36-8C39-2BA5D81AA79B@nominum.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 19:40:23 -0000 On Fri, 10 Jan 2014, Ted Lemon wrote: > This is the wrong way to think about it. It _is_ a use case. So you > shouldn't argue that it's not a use case. It may not be sufficient > motivation to justify using DHCPv6 to deliver router information, but > that's a different question. If we keep muddling it all together into > the same pot, we will never be able to come to a clear conclusion in > this discussion. Using enterprise L2 gear has been done commercially on a wide scale in Sweden since 1999 or 2000. I was myself involved in one of the first commercial ETTH providers here. The use-case is definitely there, that's how we did it initially, then in 2001-2002 we discovered there was a definite need for the L2 equipment to do DHCP snooping etc, because otherwise we ended up in the papers because neighbors could do weird things to each other. Saying there is a use-case for less-sucky DHCPv6 default router handout because one doesn't want to do proper L2 security, doesn't make sense to me. Either you do it properly or you take the consequences by doing nothing at all. > You could make the case that this is the proper response, but that's > what you need to do. I think there's a fairly strong case to be made, > since the privacy implications of two service providers being on the > same wire are potentially dire. Two service providers? I don't get it. -- Mikael Abrahamsson email: swmike@swm.pp.se From nick@foobar.org Fri Jan 10 11:59:36 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21661AE10C for ; Fri, 10 Jan 2014 11:59:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByQd0BARnEvC for ; Fri, 10 Jan 2014 11:59:35 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id ABDEF1ADEBF for ; Fri, 10 Jan 2014 11:59:34 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id s0AJxHiQ098931 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 10 Jan 2014 19:59:22 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org Message-ID: <52D05114.8040307@foobar.org> Date: Fri, 10 Jan 2014 19:59:16 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Gert Doering References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D039B3.4020402@fud.no> <52D03E04.10207@bogus.com> <20140110184059.GR40453@Space.Net> In-Reply-To: <20140110184059.GR40453@Space.Net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 19:59:36 -0000 On 10/01/2014 18:40, Gert Doering wrote: > Nick's use case is fairly specific. "If you want to live in my datacenter, > these are the rules: do not listen to RA, use DHCPv6". > > This can be done. it can't be done because I have no mechanism to deliver a default gateway without RA. It can only be done if I ditch the idea of autoconfigured default (or other routing) gateway and configure that statically (and also configure the netmask statically). But then I end up with a statically configured network and it's an expensive mess to operate. Even the IETF agrees that well known addresses are a bad idea. Also it's not "fairly specific" - it's generic to any organisation which has a requirement for hosting clients which are not fully trusted. E.g. BYOD on corp networks, any shared tenant hosting, etc, although in my case I will have limited control over the client (installed vm kernel versions, etc). On 10/01/2014 18:19, Tore Anderson wrote: > Your tenant hosts are in all likelihood *already* soliciting and > listening for RAs, and acting on any they receive. This means that They aren't doing anything at the moment because I haven't yet rolled out ipv6 to them - because I can't do so in a way which scales and is reasonably secure from abuse. Nick From nick@foobar.org Fri Jan 10 12:10:50 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E054C1AE10C for ; Fri, 10 Jan 2014 12:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUvNsKtuVSHw for ; Fri, 10 Jan 2014 12:10:49 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD1D1AE0BF for ; Fri, 10 Jan 2014 12:10:48 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id s0AKAULx098989 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 10 Jan 2014 20:10:36 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org Message-ID: <52D053B6.6080804@foobar.org> Date: Fri, 10 Jan 2014 20:10:30 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mikael Abrahamsson , Ted Lemon References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <8EBE3D62-D6BA-470A-B9E4-E58B2C4ACB44@nominum.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 20:10:51 -0000 On 10/01/2014 18:13, Mikael Abrahamsson wrote: > I'm considering it a huge problem in both IPv4 and IPv6 and I consider > operators deploying multi tentant networks without these security features > as hugely irresponsible. It's not just stupid, it doesn't work as a business proposition. I cannot roll out ipv6 to shared tenant customers knowing that any one of them could trash connectivity for everyone else. Broken connectivity loses customers. > Yes, it can be argued IPv6 might be a little worse than IPv4 You're stuck with a single line of defence: RA guard, and if that fails you have nothing else. Defence in depth is a sound engineering principal that one does not discard lightly. Also it makes no engineering sense to argue that just because we have a slightly similar protocol weakness in ipv4 (gratuituous arp), we should be happy about extending this to an additional protocol mechanism in ipv6. Nick From gert@Space.Net Fri Jan 10 12:18:21 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE9F1AE1BD for ; Fri, 10 Jan 2014 12:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aKl6VRMM0ne for ; Fri, 10 Jan 2014 12:18:19 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 373211AE171 for ; Fri, 10 Jan 2014 12:18:18 -0800 (PST) Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 0DB23604A9 for ; Fri, 10 Jan 2014 21:18:08 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id E13936046A for ; Fri, 10 Jan 2014 21:18:07 +0100 (CET) Received: (qmail 80691 invoked by uid 1007); 10 Jan 2014 21:18:07 +0100 Date: Fri, 10 Jan 2014 21:18:07 +0100 From: Gert Doering To: Nick Hilliard Message-ID: <20140110201807.GT40453@Space.Net> References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D039B3.4020402@fud.no> <52D03E04.10207@bogus.com> <20140110184059.GR40453@Space.Net> <52D05114.8040307@foobar.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9pS2hy4/DrI8BQlq" Content-Disposition: inline In-Reply-To: <52D05114.8040307@foobar.org> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 20:18:21 -0000 --9pS2hy4/DrI8BQlq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Jan 10, 2014 at 07:59:16PM +0000, Nick Hilliard wrote: > On 10/01/2014 18:40, Gert Doering wrote: > > Nick's use case is fairly specific. "If you want to live in my datacen= ter, > > these are the rules: do not listen to RA, use DHCPv6". > >=20 > > This can be done. >=20 > it can't be done because I have no mechanism to deliver a default gateway > without RA. It can only be done if I ditch the idea of autoconfigured > default (or other routing) gateway and configure that statically (and also > configure the netmask statically). But then I end up with a statically > configured network and it's an expensive mess to operate. =20 It would be nice if you bother to quote *all* of my mail. The part that you left off was "IPv6 permits you to have the same gateway address everywhere, like fe80::1234". If you can force your clients to never accept RAs, forcing a static default would be about the same order of complexity, no? > Even the IETF agrees that well known addresses are a bad idea. That's a fairly lame argument, as those are not well known addresses in the IETF sense, as in "it must be that way in all networks". Your network obviously has specific rules, "accept_ra=3D0" being one of them, so why can't it have a Nick's-network-gateway rule as well? > Also it's not "fairly specific" - it's generic to any organisation which > has a requirement for hosting clients which are not fully trusted. E.g. > BYOD on corp networks, any shared tenant hosting, etc, although in my case > I will have limited control over the client (installed vm kernel versions, > etc). No. Especially BYOD is a completely different case, as there is just=20 no way to tell joe random device to ignore RAs that might be sent by=20 john doe's windows ICS... "work without RA" is something different from "force random devices that need to work on other networks *with* RA to all of a sudden ignore RAs on your network". > On 10/01/2014 18:19, Tore Anderson wrote: > > Your tenant hosts are in all likelihood *already* soliciting and=20 > > listening for RAs, and acting on any they receive. This means that >=20 > They aren't doing anything at the moment because I haven't yet rolled out > ipv6 to them - because I can't do so in a way which scales and is > reasonably secure from abuse. There will never be any way if you insist that "the IETF must ensure that my tenant's machine will ignore RAs!" is the only solution. Hint: by not giving your clients IPv6, you're forcing those that use Windows to use 6to4 or Teredo unless they explicitely (manually again) disable it. Thanks, job well done. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --9pS2hy4/DrI8BQlq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBUtBVf99WwGXkzn/FAQJvRw/5Ad8cfKtEfp2ikgG491FN0QL1FDejF7GN LppbVbCQsRHaA7ENcBoVpYQldnMPYUA1/cwOYCeSZtCesW8IXSodWV9dwqzRrVT0 5L1Duqs6GYhFxSZ0m1eQ1YyJzrW5lJd5oFCRzMY36xHxeLLJL/gDabndRjxsnbZr eWlaXGnUlO7CRYY4xoivdKKXqrGKQtBa0r1T9X4hfIL8U/R211JIxBfoHoRTozZS eKkDUhkWYqNoJ/KDCLLCX7jEzM+lsZz8OiyyhwieZp67HxE0FmhEQD21/LSs0lnC UE6JJ+peGirTxRTxDpwFgPxKLKjIlMH2+P4lsrSLWEAb2aIlj/bwDiY9vNNnIDbv jkaHFtQlZAKWCSh8f3NFdTVgQKXPsrQqM5zdI+A2t+BeVoVS4lRZya+i8KXukkqz oJm4X89WBUcDcVm4dUYf2CutDtCClWv4Mu5ZT8deh1OgE9Nwx3C+VcIhdfM73c7y swQbxBQZ8VA9yIsrqgAnfXs4AI465LLkbO5c48MDegW6VxLBlF4fKZZYxjS1tH4Q HsQwg127lXTml+wd7w6TLjdRkcaw/5B2bnuHmP03TZddynzSuDBNjUoYUnzVxJW2 90+NSFYedgxxmmZUinp7UCNfPw8xIFid0kzA1yc57qv5LIpC7sdO5HKpUcBg1TZZ 3yKNW3Oee5E= =vreQ -----END PGP SIGNATURE----- --9pS2hy4/DrI8BQlq-- From Fred.L.Templin@boeing.com Fri Jan 10 12:25:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D99371AE0EF for ; Fri, 10 Jan 2014 12:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id be1sH1XAjAdC for ; Fri, 10 Jan 2014 12:25:12 -0800 (PST) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 340E01AE02E for ; Fri, 10 Jan 2014 12:25:12 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s0AKP1JG014405; Fri, 10 Jan 2014 14:25:02 -0600 Received: from XCH-PHX-309.sw.nos.boeing.com (xch-phx-309.sw.nos.boeing.com [130.247.25.163]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s0AKOtfQ014274 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 10 Jan 2014 14:24:56 -0600 Received: from XCH-BLV-501.nw.nos.boeing.com (130.247.25.190) by XCH-PHX-309.sw.nos.boeing.com (130.247.25.163) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Jan 2014 12:24:55 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.203]) by XCH-BLV-501.nw.nos.boeing.com ([169.254.1.208]) with mapi id 14.03.0158.001; Fri, 10 Jan 2014 12:24:55 -0800 From: "Templin, Fred L" To: Nick Hilliard , Gert Doering Thread-Topic: [v6ops] control and security of DHCP Thread-Index: AQHPDj5wvrqr7XBnbE2EhhsUuWc00Zp+Zp9A Date: Fri, 10 Jan 2014 20:24:54 +0000 Message-ID: <2134F8430051B64F815C691A62D98318196D8E@XCH-BLV-504.nw.nos.boeing.com> References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D039B3.4020402@fud.no> <52D03E04.10207@bogus.com> <20140110184059.GR40453@Space.Net> <52D05114.8040307@foobar.org> In-Reply-To: <52D05114.8040307@foobar.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 20:25:14 -0000 > On 10/01/2014 18:40, Gert Doering wrote: > > Nick's use case is fairly specific. "If you want to live in my datacen= ter, > > these are the rules: do not listen to RA, use DHCPv6". > > > > This can be done. >=20 > it can't be done because I have no mechanism to deliver a default gateway > without RA. It can only be done if I ditch the idea of autoconfigured > default (or other routing) gateway and configure that statically (and als= o > configure the netmask statically). But then I end up with a statically > configured network and it's an expensive mess to operate. Even the IETF > agrees that well known addresses are a bad idea. If there is some way to discover both the link-local address and link-layer address of the router, then you can configure a default route without RA. AERO is an example link type where this is possible, and there may be others. Thanks - Fred fred.l.templin@boeing.com From swmike@swm.pp.se Fri Jan 10 16:01:39 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4141AE0BF for ; Fri, 10 Jan 2014 16:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.389 X-Spam-Level: X-Spam-Status: No, score=-4.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47wLQzlC3rhB for ; Fri, 10 Jan 2014 16:01:38 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id DC83F1ADF7E for ; Fri, 10 Jan 2014 16:01:35 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id ADFC29C; Sat, 11 Jan 2014 01:01:24 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A92FE9A; Sat, 11 Jan 2014 01:01:24 +0100 (CET) Date: Sat, 11 Jan 2014 01:01:24 +0100 (CET) From: Mikael Abrahamsson To: Nick Hilliard In-Reply-To: <52D053B6.6080804@foobar.org> Message-ID: References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <8EBE3D62-D6BA-470A-B9E4-E58B2C4ACB44@nominum.com> <52D053B6.6080804@foobar.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 00:01:40 -0000 On Fri, 10 Jan 2014, Nick Hilliard wrote: > You're stuck with a single line of defence: RA guard, and if that fails > you have nothing else. Defence in depth is a sound engineering > principal that one does not discard lightly. No, that is not the only mechanism, you can also do forced-forwarding towards the router, or you can do L2 separation. Actually, as IPv6 is today you can make this even more elegant than in IPv4, because the way IPv6 was designed you don't need local-proxy-arp. > Also it makes no engineering sense to argue that just because we have a > slightly similar protocol weakness in ipv4 (gratuituous arp), we should > be happy about extending this to an additional protocol mechanism in > ipv6. Still, I don't see that changing DHCPv6 in the manner you propose actually solves the problem. It just changes the problem. Now you're relying on DHCPv6 inspection as the sole mechanism, if that fails then people can do whatever they want. -- Mikael Abrahamsson email: swmike@swm.pp.se From lorenzo@google.com Fri Jan 10 23:16:21 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B8B1AE0A4 for ; Fri, 10 Jan 2014 23:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFOCty_vE1NU for ; Fri, 10 Jan 2014 23:16:17 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 757531ACCFE for ; Fri, 10 Jan 2014 23:16:17 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id to1so2082638ieb.30 for ; Fri, 10 Jan 2014 23:16:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gJOZynzUYUusvmJddTgI5jh0l0jX6i84SVZYdnFqvAE=; b=FfPeATqegQw78HV2hm/6AcwovcmPxTnynwbg99LWa3dObZlquF7GCit0rNLd2r2SGH 5bjjpqkSqYGbQycdBOgtFbEKXL5uOmCtLVz7q0D2oxq7nrp4rr0Y7laMfbo5kV7CuGQI 5WFjSXXluHO8XkaGjHX9uAKyOdkrZrFuhhBZjzcm7CPwO/hIKjbVNAuTWzo16F5NHUg+ QxYk9a2nrwKBvuFX5128B2NBMNm4z2DnZyWiB0afkid6gSJsKrDqk480JsmUDzI/KlmI tii9O3pzZoPbndVlIwankyM2pnrHA2AMA/IZBWu6kqai7JZNNw+9MM20uL6jecW8kGwQ CSTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=gJOZynzUYUusvmJddTgI5jh0l0jX6i84SVZYdnFqvAE=; b=eg4haEEOZc5Au8k38VdwCWVMoxL8cLXwuhhnJ3AUWvKMB2XvdMPALTCaPedpr31ZOn iSdGSUOHKYSOPBWCE/YYGpAXuYvtb3UqzVKkRpICG+ZO0+WVgQgEZakwGnAU7onPiCue u2tVNmWawEm2ccoyK6WngS+Y2nV7R0FeJdpyj3rz50e9Zr+V8duYRVmXL7RSDHKlZl16 P/nk5GYo2tZBEYIA2xUKscy1rXIlZK8LRZzGEvD+x0yT+a0BpxjyeGdqKhiQEbdyOc23 /oKj+3E/aglOzGal+Cux0mqyJzfpgqE7nP0XB3HWHXQcDsHVXhNQO6yXb0uvIXK8Vc6L Jqpw== X-Gm-Message-State: ALoCoQmR3m0N+oNno2KqX743r90jJKfo/MkxoWc4DGSqIyaBClbA+sz9ZgwojTEB15cu1bG3flpDPRylO6vUMZ5+zyApQV2OaJUBZOl7cAT/wmI1omXYUnfcOp8aUu79lhM/jz8g04CyyR9rigiXZyqHDQR6sAYzH4MJS8gBGfl11daTs10tloqsrfxfhL9hLyl9yz9yC5OC X-Received: by 10.50.79.228 with SMTP id m4mr8056461igx.47.1389424567180; Fri, 10 Jan 2014 23:16:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Fri, 10 Jan 2014 23:15:47 -0800 (PST) In-Reply-To: References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> From: Lorenzo Colitti Date: Sat, 11 Jan 2014 16:15:47 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=089e013a1f16c546b804efac9d4d Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 07:16:21 -0000 --089e013a1f16c546b804efac9d4d Content-Type: text/plain; charset=UTF-8 On Sat, Jan 11, 2014 at 2:54 AM, Ted Lemon wrote: > > Yet IPv4 has the same kind of problems, like gratuitous ARP or L2 > spoofing, or whatever. So unless you secure against these, you're screwed. > > Mikael, you've entirely missed Nick's point. A gratuitous RA can have > the effect he's talking about without any intentional action. ... and ARP spoofing the first-hop router's MAC address can't? Sorry to be the bearer of bad news, but Mikael is right. A malicious host on your link WILL take down your network. You either defend against that or you cross your fingers. And using DHCP is NOT a defense. Ok, so ARP spoofing is not the same as a rogue RA. So here's the moral equivalent: I set up a covert DHCP server that hands out, as next-hop router, an on-link IP address which, by responding to ARP requests, I can point at any on-link machine I want (including, most interestingly, either me or the first-hop router). When doing so, I'm careful to ensure that I hand out the proper address to every machine, such that everything continues to work. I know what those addresses are, because I'm on-link and ARP is a broadcast protocol. Since I'm on-link and the "real" DHCP request has to go through 23 relays and 4 autonomous systems (because In Enterprises, Centralized Management Is Good), I will always win the race against the real DHCP server, so the trusting client will use the settings I gave it. When that happens, I can spoof a confirmation to the real server (DHCPACK or whatever it's called) so that it doesn't know that anything is wrong. As more and more leases are renewed, more and more trusting hosts use me as next-hop router, but they don't notice, because I forward their packets to the proper destination. At a key time, I start dropping all their packets, and I am free to do so until the lease expires. It seems to me that: 1. The effect of such an attack is no different from a rogue RA. 2. That attack is no more difficult than a rogue RA attack to pull off. (I mean - it's more sophisticated technically, but it's not any more difficult in terms of the barriers the operator can put in place to stop it). > In order to take down an IPv4 network with ARP, you either have to have > a device configured to proxy arp, which is easy to detect and the effects > of which clear up rapidly, or else you have to have someone intentionally > attacking the network, which again is easy to detect and fix. > For configuration errors, there's RA guard. For malicious hosts, there's real layer 2 security and VLAN segmentation. There is *nothing else*. I know people don't do VLAN segmentation, but I'd argue that that's because in IPv4 there is not enough address space to do it. Fortunately IPv6 provides that address space, so we won't have to waste our time doing layering violations and gross hacks like DHCP snooping and forced forwarding in order to defend this sort of attack - just give each tenant their own subnet (ideally, /64) and you're done. > I don't know how serious the problem Nick has described really is in > practice, but it is quite clearly different than the problem you are > talking about, and at least potentially does seem to have the impact that > Nick ascribes to it: that it makes multi-tenant networking more expensive. Ted - next time you support yet another of the endless use cases that routing-in-DHCPv6 supporters put forth to justify that the Only Possible Protocol Under The Sun To Configure Host Routing is DHCP, please do spend a little more time thinking about "how serious the problem is". Thanks, Lorenzo --089e013a1f16c546b804efac9d4d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Jan 11, 2014 at 2:54 AM, Ted Lemon <ted.lemon@nominum.com><= /span> wrote:
> Yet IPv4 has the same kind of probl= ems, like gratuitous ARP or L2 spoofing, or whatever. So unless you secure = against these, you're screwed.

Mikael, you've entirely missed Nick's point. =C2=A0 A gratuit= ous RA can have the effect he's talking about without any intentional a= ction.

... and ARP spoofing the first-hop r= outer's MAC address can't?

Sorry to be the bearer of bad news, but Mikael is right= . A malicious host on your link WILL take down your network. You either def= end against that or you cross your fingers. And using DHCP is NOT a defense= .

Ok, so ARP spoofing is not the same as a rogue RA. So h= ere's the moral equivalent: I set up a covert DHCP server that hands ou= t, as next-hop router, an on-link IP address which, by responding to ARP re= quests, I can point at any on-link machine I want (including, most interest= ingly, either me or the first-hop router). When doing so, I'm careful t= o ensure that I hand out the proper address to every machine, such that eve= rything continues to work. I know what those addresses are, because I'm= on-link and ARP is a broadcast protocol.

Since I'm on-link and the "real" DHCP req= uest has to go through 23 relays and 4 autonomous systems (because In Enter= prises, Centralized Management Is Good), I will always win the race against= the real DHCP server, so the trusting client will use the settings I gave = it. When that happens, I can spoof a confirmation to the real server (DHCPA= CK or whatever it's called) so that it doesn't know that anything i= s wrong.

As more and more leases are renewed, more and more trus= ting hosts use me as next-hop router, but they don't notice, because I = forward their packets to the proper destination. At a key time, I start dro= pping all their packets, and I am free to do so until the lease expires.

It seems to me that:

1. The ef= fect of such an attack is no different from a rogue RA.
2. That a= ttack is no more difficult than a rogue RA attack to pull off. (I mean - it= 's more sophisticated technically, but it's not any more difficult = in terms of the barriers the operator can put in place to stop it).
=C2=A0
=C2=A0 In order to take down an IPv4 net= work with ARP, you either have to have a device configured to proxy arp, wh= ich is easy to detect and the effects of which clear up rapidly, or else yo= u have to have someone intentionally attacking the network, which again is = easy to detect and fix.

For configuration errors, there's RA g= uard. For malicious hosts, there's real layer 2 security and VLAN segme= ntation. There is *nothing else*.

I know people do= n't do VLAN segmentation, but I'd argue that that's because in = IPv4 there is not enough address space to do it. Fortunately IPv6 provides = that address space, so we won't have to waste our time doing layering v= iolations and gross hacks like DHCP snooping and forced forwarding in order= to defend this sort of attack - just give each tenant their own subnet (id= eally, /64) and you're done.
=C2=A0
I don't know how serious the prob= lem Nick has described really is in practice, but it is quite clearly diffe= rent than the problem you are talking about, and at least potentially does = seem to have the impact that Nick ascribes to it: that it makes multi-tenan= t networking more expensive.

Ted - next time you support yet another of the end= less use cases that routing-in-DHCPv6 supporters put forth to justify that = the Only Possible Protocol Under The Sun To Configure Host Routing is DHCP,= please do spend a little more time thinking about "how serious the pr= oblem is".

Thanks,
Lorenzo
--089e013a1f16c546b804efac9d4d-- From alexandru.petrescu@gmail.com Sat Jan 11 02:09:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD171AD7C1 for ; Sat, 11 Jan 2014 02:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FElfk-46rwmp for ; Sat, 11 Jan 2014 02:09:42 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id D81341ACC81 for ; Sat, 11 Jan 2014 02:09:41 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s0BA9Vui026302 for ; Sat, 11 Jan 2014 11:09:31 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E10DF201185 for ; Sat, 11 Jan 2014 11:10:34 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D9204201149 for ; Sat, 11 Jan 2014 11:10:34 +0100 (CET) Received: from [127.0.0.1] ([132.166.86.19]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s0BA9RRu029961 for ; Sat, 11 Jan 2014 11:09:30 +0100 Message-ID: <52D11856.9040904@gmail.com> Date: Sat, 11 Jan 2014 11:09:26 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 10:09:44 -0000 Le 11/01/2014 08:15, Lorenzo Colitti a écrit : > On Sat, Jan 11, 2014 at 2:54 AM, Ted Lemon > wrote: > >> Yet IPv4 has the same kind of problems, like gratuitous ARP or L2 > spoofing, or whatever. So unless you secure against these, you're > screwed. > > Mikael, you've entirely missed Nick's point. A gratuitous RA can > have the effect he's talking about without any intentional action. > > > ... and ARP spoofing the first-hop router's MAC address can't? > > Sorry to be the bearer of bad news, but Mikael is right. A malicious > host on your link WILL take down your network. You either defend > against that or you cross your fingers. And using DHCP is NOT a > defense. Maybe DHCP with pre-registered MAC addresses is not full defense but looks maybe better than nothing. > Ok, so ARP spoofing is not the same as a rogue RA. So here's the > moral equivalent: I set up a covert DHCP server that hands out, as > next-hop router, an on-link IP address which, by responding to ARP > requests, I can point at any on-link machine I want (including, most > interestingly, either me or the first-hop router). The attack seems reasonable. One possible way to initiate protection is to pre-register the MAC address of all machines allowed to connect; this pre-registration should be done by an out-of-band means. This could help raise an alarm when someone connected a rogue DHCP server using the MAC address of the legitimate server. A popup on its screen would say it. > When doing so, I'm careful to ensure that I hand out the proper > address to every machine, such that everything continues to work. I > know what those addresses are, because I'm on-link and ARP is a > broadcast protocol. > > Since I'm on-link and the "real" DHCP request has to go through 23 > relays and 4 autonomous systems (because In Enterprises, Centralized > Management Is Good), I will always win the race against the real DHCP > server, so the trusting client will use the settings I gave it. When > that happens, I can spoof a confirmation to the real server (DHCPACK > or whatever it's called) so that it doesn't know that anything is > wrong. > > As more and more leases are renewed, more and more trusting hosts > use me as next-hop router, but they don't notice, because I forward > their packets to the proper destination. At a key time, I start > dropping all their packets, and I am free to do so until the lease > expires. > > It seems to me that: > > 1. The effect of such an attack is no different from a rogue RA. 2. > That attack is no more difficult than a rogue RA attack to pull off. > (I mean - it's more sophisticated technically, but it's not any more > difficult in terms of the barriers the operator can put in place to > stop it). > > In order to take down an IPv4 network with ARP, you either have to > have a device configured to proxy arp, which is easy to detect and > the effects of which clear up rapidly, or else you have to have > someone intentionally attacking the network, which again is easy to > detect and fix. > > > For configuration errors, there's RA guard. For malicious hosts, > there's real layer 2 security and VLAN segmentation. There is > *nothing else*. Well... is RA guard a panacea solution for protecting ND? Not sure what you mean by RA guard protecting against configuration errors, but RA guard RFC1605 is only for some particular wired deployments (e.g. not for shared media, link must ensure always go through router, etc.). In addition to these particular wired environments there are the other particular wired environments, and the other particular wired environments. For example that would not protect Ethernet links where neighbors talk directly at IP layer, or cellular links, or WiFi adhoc mode links, or 802.11p not-through-router links. 802.1x is also good in some environments, but not all. Some links are so permissive in terms of who talks to who inside it, and so strict in what they do _not_ trust outside of it, that one considers to rather try just a little bit of security rather than keep these networks fully disconnected from the Internet. Alex > I know people don't do VLAN segmentation, but I'd argue that that's > because in IPv4 there is not enough address space to do it. > Fortunately IPv6 provides that address space, so we won't have to > waste our time doing layering violations and gross hacks like DHCP > snooping and forced forwarding in order to defend this sort of > attack - just give each tenant their own subnet (ideally, /64) and > you're done. > > I don't know how serious the problem Nick has described really is in > practice, but it is quite clearly different than the problem you are > talking about, and at least potentially does seem to have the impact > that Nick ascribes to it: that it makes multi-tenant networking more > expensive. > > > Ted - next time you support yet another of the endless use cases > that routing-in-DHCPv6 supporters put forth to justify that the Only > Possible Protocol Under The Sun To Configure Host Routing is DHCP, > please do spend a little more time thinking about "how serious the > problem is". > > Thanks, Lorenzo > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From alexandru.petrescu@gmail.com Sat Jan 11 02:21:39 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72AE31ACCEC for ; Sat, 11 Jan 2014 02:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTJUeyCaBxB6 for ; Sat, 11 Jan 2014 02:21:37 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 8419E1A1F4C for ; Sat, 11 Jan 2014 02:21:37 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s0BALQGR028561 for ; Sat, 11 Jan 2014 11:21:26 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C261920115C for ; Sat, 11 Jan 2014 11:22:30 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BAC61201135 for ; Sat, 11 Jan 2014 11:22:30 +0100 (CET) Received: from [127.0.0.1] ([132.166.86.19]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s0BALNdA001553 for ; Sat, 11 Jan 2014 11:21:26 +0100 Message-ID: <52D11B22.2070603@gmail.com> Date: Sat, 11 Jan 2014 11:21:22 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D0180D.6030505@foobar.org> <2134F8430051B64F815C691A62D98318196839@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D98318196839@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] link types for both RA and DHCP 'was: control and security of DHCP) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 10:21:39 -0000 Le 10/01/2014 18:13, Templin, Fred L a écrit : > Hi, I am just beginning to get the flavor for this discussion but > what I am finding lacking is a consideration for the _different link > types_ for which DHCPv6 vs RS/RA would apply. For example, AERO > links are link-local only and there is actually very little useful > information that could be gotten from an RS/RA exchange that could > not just as easily be gotten from NS/NA. There, DHCPv6-PD may be all > that is needed. > > Similarly, on managed network links DHCPv6 gives a central > administrative control point for coordinating all of the managed > links. > > So, what are the link types where we would expect to see RS/RA? > Unmanaged edge links where visiting nodes come and go at random > times? Others? Fred, The use of DHCP and ND would apply supposedly to the as many links as possible. The links I am concerned with are: cellular 1G, 2G, 3G, 4G and in the future 5G, 869MHZ 'Alarm' IoT/M2M networks, 5.9GHz 802.11p, WiFi, wired Ethernet, Fiber to the RSU, satellite, and more. The additional links I have heard about here are: wired Ethernet in Enterprise, virtual links between virtual machines ('virtual' by name but transmitting real packets), and more. Yes, some of these links would be termed unmanaged links where visiting nodes come and go at random times. On some of them it would be better to just use RA (e.g. WiFi handovers on IPv6 hotspots), on others just DHCP (e.g. on constrained links of machine-class devices), and yet on others both ND and DHCP (e.g. some visitor networks in Enterprise). Sorry if this reads too generic, but I couldnt synthesize it better than that. Alex > > Thanks - Fred fred.l.templin@boeing.com > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From alexandru.petrescu@gmail.com Sat Jan 11 02:31:23 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD09E1AD8CD for ; Sat, 11 Jan 2014 02:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bHyuBpNXrLR for ; Sat, 11 Jan 2014 02:31:22 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id C2D1D1ACCEC for ; Sat, 11 Jan 2014 02:31:21 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s0BAV7qY030946; Sat, 11 Jan 2014 11:31:07 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 07300201146; Sat, 11 Jan 2014 11:32:11 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id EEE2B201128; Sat, 11 Jan 2014 11:32:10 +0100 (CET) Received: from [127.0.0.1] ([132.166.86.19]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s0BAV3t9004703; Sat, 11 Jan 2014 11:31:06 +0100 Message-ID: <52D11D67.1080106@gmail.com> Date: Sat, 11 Jan 2014 11:31:03 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Templin, Fred L" , "v6ops@ietf.org" References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <6A64F619-4A0E-423A-A5E7-4C3234B461AE@nominum.com> <1389261993.72423.YahooMailNeo@web161906.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D98318193C5C@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D98318193CD6@XCH-BLV-504.nw.nos.boeing.com> <597F58BD-DCEA-4C4E-B7AB-DCCB416B3CFD@ecs.soton.ac.uk> <2134F8430051B64F815C691A62D98318193D30@XCH-BLV-504.nw.nos.boei! ng.com> <52CFBAB4.4040105@gmail.com> <2134F8430051B64F815C691A62D9831819663D@XCH-BLV-504.nw.nos.boeing! .com> <52D01D53.60107@gmail.com> <2134F8430051B64F815C691A62D9831819676E@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831819676E@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 10:31:24 -0000 Fred, Thanks for the message. Le 10/01/2014 17:37, Templin, Fred L a écrit : > Hi Alex, > >>>> Right. But since this thread relates to the DHCP discussion, >>>> would AERO have an aspect related to DHCP? Or to RA? How >>>> would an AERO Router self-configure its address, its mobile >>>> network prefix and its default route? Would it accept many >>>> combinations or just one? >>> >>> AERO certainly has aspects related to both DHCP and RA. AERO >>> nodes are all routers (not hosts) and so they would use DHCP as >>> requesting routers for Prefix Delegation but not for address >>> configuration. And, they would use unicast RS/RA for neighbor >>> cache and default route maintenance to their default router. >> >> All while I understand what is said above, I wonder whether >> running two protocols simultaneously on slow AERO links is maybe >> little optimal, or not. > > I will give you that the AERO document is currently using RS/RA > primarily because "it's there". I think that is very good and should be used. I think there are many IPv6 deployments where RS/RA are there and should be used. I also use it whenever it's there and I would like it to. However, let me try to suggest an alternative perspective for other kinds of work. There are a number of networks which are not there, but which need to design and plan. Their goal is not to satisfy some IETF discussion, but to satisfy some professional need. E.g. a new large building of offices needs to connect to the Internet, or a new highway IP network needs to be deployed. When planning this, in the environment where I live, very often the absolute requirement is to do IPv4 first, and keep IPv6 in mind, prepare for it, be ready for IPv6 in maybe 2-7 years. That is the topmost and absolute requirement, can't change. This is a different approach than deploying IPv6 in an Enterprise on top of IPv4 already there, or the requirement where one builds a new IP network from scratch and make it IPv6 native and only. Given that, one wants to make it first IPv4 (IPv4 innovation is still needed in some protcols), and plan for as little effort as possible to deploy to IPv6. I.e. make them as much as possible look the same. If not, there is additional software effort, additional money to look for, additional time to add to end of project. > For AERO, there is nothing magical about RS/RA that could not also > be accommodated by NS/NA. But, we will certainly want DHCP-PD. Ok. Alex > > Thanks - Fred fred.l.templin@boeing.com > >> Alex >> >>> >>> AERO nodes self-configure link-local addresses through the AERO >>> address format specified in the document. AERO nodes only assign >>> link-local addresses to their AERO interfaces; they do not >>> assign addresses of other scopes. AERO nodes connect IPv6 end >>> user networks to the AERO link, and use the AERO link only as >>> transit to get to other IPv6 networks. AERO nodes use unicast >>> IPv6 ND for neighbor cache maintenance and route optimization. > > > From Ted.Lemon@nominum.com Sat Jan 11 05:36:10 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735D01AD9AC for ; Sat, 11 Jan 2014 05:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yNDNwEhbeSH for ; Sat, 11 Jan 2014 05:36:09 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id CF69A1AD8F3 for ; Sat, 11 Jan 2014 05:36:08 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUtFIvnLH7bbsTyfmWmwTsinMCO/FNmgE@postini.com; Sat, 11 Jan 2014 05:35:59 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 77B1C1B82E4 for ; Sat, 11 Jan 2014 05:35:58 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 4CA5D19005C; Sat, 11 Jan 2014 05:35:58 -0800 (PST) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 11 Jan 2014 05:35:58 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Sat, 11 Jan 2014 08:35:54 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <2CECDE88-E00F-4826-9C86-2F4A9A5A9857@nominum.com> References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 13:36:10 -0000 On Jan 11, 2014, at 2:15 AM, Lorenzo Colitti wrote: > Sorry to be the bearer of bad news, but Mikael is right. A malicious = host on your link WILL take down your network. You either defend against = that or you cross your fingers. And using DHCP is NOT a defense. An RA can take down the network quickly, with a single multicast, and = need not be malicious=97it could simply be a mistake. A device = misconfigured to proxy ARP can do a lot of damage, but once you turn it = off the damage stops in about 180 seconds (or is it 120?). Please don't mistake my devil's advocate position here for a position = advocating that we change how RA and DHCP work. What I am trying to do = is get clarity, not advocate one thing or another. Lots of people have = been arguing that they really want a DHCPv6 route option for a long = time. If it really didn't matter, they would have stopped by now, and = at least it would be _different_ people arguing for it. So, it's important to understand _why_ they are arguing for it. It's = not clear to me that there's a use case that would motivate any = architectural change, but documenting the use cases that exist is = worthwhile, and is something we've failed to do several times. So when = I hear people like Nick describing their use cases, I think this is = constructive, and I really want to see it documented. I do not want to = see him shouted down because you are concerned that if his use cases are = documented, it will motivate changes to the architecture. That's = really not how IETF process is supposed to work. This is why I originally encouraged Andrew to work on his draft. From nick@foobar.org Sat Jan 11 10:36:42 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6B41AE117 for ; Sat, 11 Jan 2014 10:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pe2C3aVc-2uR for ; Sat, 11 Jan 2014 10:36:39 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id D821B1AE113 for ; Sat, 11 Jan 2014 10:36:38 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id s0BIaI5k008537 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 11 Jan 2014 18:36:23 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org Message-ID: <52D18F22.1070708@foobar.org> Date: Sat, 11 Jan 2014 18:36:18 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Lorenzo Colitti , Ted Lemon References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 18:36:42 -0000 Lorenzo, You're arguing that just because we have a protocol weakness in ipv4 that it's ok to accept an additional instance of this kind of protocol weakness in ipv6. This is not a sensible approach to protocol engineering. Nick On 11/01/2014 07:15, Lorenzo Colitti wrote: > On Sat, Jan 11, 2014 at 2:54 AM, Ted Lemon > wrote: > > > Yet IPv4 has the same kind of problems, like gratuitous ARP or L2 > spoofing, or whatever. So unless you secure against these, you're screwed. > > Mikael, you've entirely missed Nick's point. A gratuitous RA can have > the effect he's talking about without any intentional action. > > > ... and ARP spoofing the first-hop router's MAC address can't? > > Sorry to be the bearer of bad news, but Mikael is right. A malicious host > on your link WILL take down your network. You either defend against that or > you cross your fingers. And using DHCP is NOT a defense. > > Ok, so ARP spoofing is not the same as a rogue RA. So here's the moral > equivalent: I set up a covert DHCP server that hands out, as next-hop > router, an on-link IP address which, by responding to ARP requests, I can > point at any on-link machine I want (including, most interestingly, either > me or the first-hop router). When doing so, I'm careful to ensure that I > hand out the proper address to every machine, such that everything > continues to work. I know what those addresses are, because I'm on-link and > ARP is a broadcast protocol. > > Since I'm on-link and the "real" DHCP request has to go through 23 relays > and 4 autonomous systems (because In Enterprises, Centralized Management Is > Good), I will always win the race against the real DHCP server, so the > trusting client will use the settings I gave it. When that happens, I can > spoof a confirmation to the real server (DHCPACK or whatever it's called) > so that it doesn't know that anything is wrong. > > As more and more leases are renewed, more and more trusting hosts use me as > next-hop router, but they don't notice, because I forward their packets to > the proper destination. At a key time, I start dropping all their packets, > and I am free to do so until the lease expires. > > It seems to me that: > > 1. The effect of such an attack is no different from a rogue RA. > 2. That attack is no more difficult than a rogue RA attack to pull off. (I > mean - it's more sophisticated technically, but it's not any more difficult > in terms of the barriers the operator can put in place to stop it). > > > In order to take down an IPv4 network with ARP, you either have to > have a device configured to proxy arp, which is easy to detect and the > effects of which clear up rapidly, or else you have to have someone > intentionally attacking the network, which again is easy to detect and fix. > > > For configuration errors, there's RA guard. For malicious hosts, there's > real layer 2 security and VLAN segmentation. There is *nothing else*. > > I know people don't do VLAN segmentation, but I'd argue that that's because > in IPv4 there is not enough address space to do it. Fortunately IPv6 > provides that address space, so we won't have to waste our time doing > layering violations and gross hacks like DHCP snooping and forced > forwarding in order to defend this sort of attack - just give each tenant > their own subnet (ideally, /64) and you're done. > > > I don't know how serious the problem Nick has described really is in > practice, but it is quite clearly different than the problem you are > talking about, and at least potentially does seem to have the impact > that Nick ascribes to it: that it makes multi-tenant networking more > expensive. > > > Ted - next time you support yet another of the endless use cases that > routing-in-DHCPv6 supporters put forth to justify that the Only Possible > Protocol Under The Sun To Configure Host Routing is DHCP, please do spend a > little more time thinking about "how serious the problem is". > > Thanks, > Lorenzo > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nick@foobar.org Sat Jan 11 10:57:01 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5BEE1AE09F for ; Sat, 11 Jan 2014 10:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1tTqHzcBe85 for ; Sat, 11 Jan 2014 10:57:00 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id B55D91AE08F for ; Sat, 11 Jan 2014 10:56:59 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id s0BIudBN008638 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 11 Jan 2014 18:56:44 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org Message-ID: <52D193E7.7060403@foobar.org> Date: Sat, 11 Jan 2014 18:56:39 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Lorenzo Colitti , Matthew Petach References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 18:57:01 -0000 Lorenzo, In IPv4, Matt's approach will work out of the box on any router with any dhcp implementation, no fancy configuration required. Matt needs to run DHCPv6 anyway, but your proposal requires him to tie RADIUS into RAs via the next-hop router for gateway selection. Apart from the fact that this is three protocols instead of one, two of which are policy management protocols (direction violation of KISS principal), it requires the routers to maintain a pile of RADIUS state which they don't need to do, opens them up to DoS attacks (requests from multiple v6 addresses), looks unnecessarily fragile and looks like the sort of proposal that no vendor in their right mind would ever implement. Whether you want to refer to this as "insane" is of course your own choice, but I am glad that you have at least some appreciation that this suggestion hails from the Heath Robinson school of network design. Nick On 09/01/2014 06:50, Lorenzo Colitti wrote: > The other is to use unicast RAs. I think you could do it like this: > > 1. When the 4 first-hop routers receive an RA, they each make a RADIUS request. > 2. The RADIUS server would return a Route-IPv6-Information attribute > containing a default route with an infinite lifetime. > 3. The designated router sends an unicast RA to the specified client, the > other three do nothing. > 4. When renewal time comes up, have the host send an RS again and repeat. > > Before you say "that's insane", consider the fact that it's almost exactly > the same flow as a relayed DHCPv6 request, and that it involves a similar > number of packets and the same amount of state. > > You do have to keep MAC-to-default-gateway mappings in the RADIUS server, > but if you're doing this I suspect you already have MAC-to-IP mappings and > IP-to-default-gateway mappings in the DHCPv4 server. > > I doubt there's any hardware that does this today, but you jumped into this > discussion by saying that there are multibillion-dollar enterprises that > are willing to pay vendors to implement the features they need. Why not pay > them to implement this? Yes, it's not DHCP, but on the plus side, it's all > IETF standard technology, and it should do what you want. > > BTW - if this is a datacenter architecture built for load-sharing, I have a > feeling you might evolve away from it in the future (either to ECMP or to > something else) so you can get better load-sharing - even with four > routers, you're leaving bandwidth on the table. > > Cheers, > Lorenzo From markzzzsmith@yahoo.com.au Sat Jan 11 16:10:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59801A1F62 for ; Sat, 11 Jan 2014 16:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2S-kclPJ2rp for ; Sat, 11 Jan 2014 16:10:44 -0800 (PST) Received: from nm47-vm1.bullet.mail.bf1.yahoo.com (nm47-vm1.bullet.mail.bf1.yahoo.com [216.109.115.124]) by ietfa.amsl.com (Postfix) with ESMTP id 390D21A1F3E for ; Sat, 11 Jan 2014 16:10:44 -0800 (PST) Received: from [98.139.212.152] by nm47.bullet.mail.bf1.yahoo.com with NNFMP; 12 Jan 2014 00:10:33 -0000 Received: from [98.139.212.249] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 12 Jan 2014 00:10:33 -0000 Received: from [127.0.0.1] by omp1058.mail.bf1.yahoo.com with NNFMP; 12 Jan 2014 00:10:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 674690.99771.bm@omp1058.mail.bf1.yahoo.com Received: (qmail 90743 invoked by uid 60001); 12 Jan 2014 00:10:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1389485433; bh=3nEzwFDeSkYtYteGT0V+kgnyiInIGY6Jr2fy2HPx5iI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=1kEGj3VpSL6fh/KXQyhFJP1dj70nWvN7y9jK7Q2+Mk4/PrK9BWaCdTbWC7UgHQbUmGCLyC0/EEbHzM/wEoT4Mi+HvsDmuQSRf66wht0wKPFpVkH5SEf07cdl4nC84amymDQEAW2x2JB9q84wG5C+H44LBj2ynGgpEtHpkz6n3YU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=PYy1uAgxu8HiZ2gtCcfU5qeHaab385DdpZzaJZFRwyRZnKAwVW62b+eSjmmBotCQ4vkob2GreoAPNAYdF3L4/QgQzie6jTftrPWKCXcpGtEz0uxNFP4IEYfUx9Cm7xbAPe7cxe4yedupFpjjDF/PBgM5tKBEQbLVLWKKCfWULOs=; X-YMail-OSG: uVhxjdgVM1mln8x0MaG805tKnA3k1Dj9ZJVX95978vCO0wb _Vw3R.815gEBZPsaHb6gEfKIy6W9soVIof4mzsBBOjy7m_ZrV_nvYVOqokVg r4_tg6ypxOyArGdV829GtYq7Ls5rox3CERR_oXLE7Jx_o6A1j96uD4xMxU4e vXZCDk9LSLjtbCWDZ9yT6N2_itpUhmV1GdfwG9yMAO4YliHpYIIQ7jEusAvK kQvsYAlWjUmgvjhrjQNzFwRKQKDHCWsxg1IwuSS5MKF8.wV4LySoxSqao9Q5 c0F5KYGqGu38W2IkSsbYOx8yLGTABm6SJAYmeUjWNNsjKTTHMLpSVUSl6ZMU EX5VDtcNK0D8tXw24d15TCfwP6_mOwloDdG8WEdMnQCg_kKFsohC_wAUiS42 3G3apUJ7ytD27G2_VtbIUfAVVKHZYOiQFmeacCQfhf8QzakDavt8_BmgWaIA PuGHKhiCjUmkjZaE8Ccl.BQhchlsGRBqqu4BHrCiGI1O.FO1KgptEhCB8iFR i.88ndMkCzvQaevc3eD6gifkfE5NjgqHOJ0GX4JNT00mRa.krZ84M0K4IOs2 HknBNPbO8V_A42C48AV0lOQ-- Received: from [150.101.221.237] by web161903.mail.bf1.yahoo.com via HTTP; Sat, 11 Jan 2014 16:10:33 PST X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBBbGV4YW5kcnUgUGV0cmVzY3UgPGFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb20.Cj4gVG86ICJUZW1wbGluLCBGcmVkIEwiIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPjsgInY2b3BzQGlldGYub3JnIiA8djZvcHNAaWV0Zi5vcmc.Cj4gQ2M6IAo.IFNlbnQ6IFNhdHVyZGF5LCAxMSBKYW51YXJ5IDIwMTQgOTozMSBQTQo.IFN1YmplY3Q6IFJlOiBbdjZvcHNdIEVudGVycHJpc2VzIHdvbid0IGRlcGxveSBJUHY2IGZvciBJUHY2J3MBMAEBAQE- X-Mailer: YahooMailWebService/0.8.172.614 References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <6A64F619-4A0E-423A-A5E7-4C3234B461AE@nominum.com> <1389261993.72423.YahooMailNeo@web161906.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D98318193C5C@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D98318193CD6@XCH-BLV-504.nw.nos.boeing.com> <597F58BD-DCEA-4C4E-B7AB-DCCB416B3CFD@ecs.soton.ac.uk> <2134F8430051B64F815C691A62D98318193D30@XCH-BLV-504.nw.nos.boei! ng.com> <52CFBAB4.4040105@gmail.com> <2134F8430051B64F815C691A62D9831819663D@XCH-BLV-504.nw.nos.boeing! .com> <52D01D53.60107@gmail.com> <2134F8430051B64F815C691A62D9831819676E@XCH-BLV-504.nw.nos.boeing.com> <52D11D67.1080 106@gmail.com> Message-ID: <1389485433.43458.YahooMailNeo@web161903.mail.bf1.yahoo.com> Date: Sat, 11 Jan 2014 16:10:33 -0800 (PST) From: Mark ZZZ Smith To: Alexandru Petrescu , "Templin, Fred L" , "v6ops@ietf.org" In-Reply-To: <52D11D67.1080106@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 00:10:45 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Alexandru Petrescu =0A> To: "Templin, Fred L" ; "v6ops@ietf.org" =0A> Cc: =0A> Sent: Saturday, 11 Jan= uary 2014 9:31 PM=0A> Subject: Re: [v6ops] Enterprises won't deploy IPv6 fo= r IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet)=0A> =0A> Fred,=0A>= =0A> Thanks for the message.=0A> =0A> Le 10/01/2014 17:37, Templin, Fred L= a =E9crit :=0A>> Hi Alex,=0A>>=A0=0A=0A=0A=0A> =0A> Given that, one= wants to make it first IPv4 (IPv4 innovation is still=0A> needed in some p= rotcols), and plan for as little effort as possible to=0A> deploy to IPv6.= =A0 I.e. make them as much as possible look the same.=A0 If=0A> not, there = is additional software effort, additional money to look for,=0A> additional= time to add to end of project.=0A>=A0=0A=0A=0ASo let's imagine IPv6 was ju= st IPv4 with bigger addresses, nothing else changed, which is what I think = you're saying some people think it should have been. How would deploying IP= v4 with bigger addresses, in addition to IPv4 with small addresses, save or= make an enterprise money today or in the near future?=0A=0ATo pick a hypot= hetical example, imagine a golf club manufacturer. How would deploying IPv6= (of either IPv4 + bigger addresses, or what we have today) decrease the co= st of manufacturing golf clubs, or increase the sales of golf clubs? I can'= t think of how IPv6 would decrease their manufacturing costs, and I don't t= hink a "We've got an IPv6 network" sticker on the box will increase golf cl= ub sales significantly (they might sell a extra few hundred to network engi= neers, but that would be it).=0A=0AIn the views of some, if IPv6 had just b= een IPv4 with bigger addresses it might slightly improve the business case = to deploy it, because it would have been less to learn, and therefore theor= etically less cost to operate. Lower costs are great, but less costs don't = matter if you don't need what the technology provides.=0A=0AI used the foll= owing in another off-list email about this topic, I think it is worth posti= ng here:=0A=0A"I once read that when you go to the hardware store to buy a = drill, what you're really buying is a hole. The drill is the means, the hol= e is the end.=0A=0ANo matter how fancy the drill is, there will be some peo= ple who don't need a hole, and therefore will never buy a drill.=A0That's n= ot a statement of the success or failure of the drill to make holes, and no= r will adding further features and enhancements to the drill increase the d= emand for holes.=0A=0ASo IPv6 is the means, and an IPv6-only application, o= r an IPv6 application that works much better than an IPv4 one, is the end. = It is only when enterprises (and others) want the IPv6 end will they then b= e prepared to deploy the IPv6 means."=0A=0A=0A=0AIf people want to stimulat= e IPv6 adoption in enterprises, then it would seem to me that the focus nee= ds to be on developing or demonstrating the value of either moving applicat= ions to using IPv6 instead of IPv4, or creating applications that cannot or= cannot easily be operated over IPv4. While I don't know if it is used much= , one example of such an application is Apple's Back to My Mac service, des= cribed in RFC6281.=0A=0ARegards,=0AMark. From lorenzo@google.com Sat Jan 11 16:15:20 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA301AD687 for ; Sat, 11 Jan 2014 16:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id az6jNW5KWwFL for ; Sat, 11 Jan 2014 16:15:18 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C24271A1F3E for ; Sat, 11 Jan 2014 16:15:18 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id c10so2501217igq.4 for ; Sat, 11 Jan 2014 16:15:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=g4BSpdY8+cTCaAPETqc/jB6NHy5A8pZlLmqyxis962c=; b=QiDKWkps2wupNaC3LAEOnMRkuI6ZrFkG4z2iW5/Lj8c5asZuFiTILTgpW0+eR7g4RZ Zda78Bz0LbULE8qkssNxhcygQWI6EVffPrwPzuN3fVv8p/evLhBxToYW93xRBQkKbpIx YlgXcKuKorHilUmZpqz0EW5O6AqOhDoYVfI6Tup69v44qzOZkUcESZMK1hSSilLXPqoV RgkogTFrH+QTCHlH65/tvfdYVAfwDC2oJNqfdrY9BFIayTEDiugFyDpm087wOgwSLcSK JWafI6pWR+mDPgCnyJCP+Be7QOHAWXt2o/l6bDLFVQVV8kXrUqgYEv4npF94i9gHj52f EPtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=g4BSpdY8+cTCaAPETqc/jB6NHy5A8pZlLmqyxis962c=; b=hYBboPgdWckhz0XotZhqmho3azjiqjTiid50YPrHYThH8cUopXyQOGvtd82HWBJfur cxyu0kuYSOagfGZ14aO+gC0dBpU/IAHepqNnYcyK+bqHkNwyUJaeKqh4UwoNo9v1l/Iv Mxfo3sGELq0L4qxaJO7gRe3qhcPgLmLOPJJcO4x0RxeeC1pdfSBX19usUow42DCXUfdl ijzBu/1Gesot48EHFrr2B88l8cpflK63YIYxtxnV5CE80lcfceudEONftqJ+N0HS/S7O zNx9Zcg55sRvsWo6DWLeGBywlBfgiws9xeRHVzJIXJ0aT0BN39tNHgv9svIhLKbzGrSp HmXw== X-Gm-Message-State: ALoCoQkQOpXL8NPqoZvkskbo6j7msnpY1l3IYfNhUg7Zkflf+ETGTxJWuu+deG1FGvNZlRWuyWSM5izflTTmykxXVSzbgKlzilGFR253pOE5bafvO/NHTdSHnkTq7y1hzcJw6W//ZSlptSdju1YLm4Y9swtoOd4RlE92dy45wrPOCmCfvPayTBVVOZPSKYaXWLtB6Fwa2apm X-Received: by 10.50.36.67 with SMTP id o3mr11268044igj.47.1389485707737; Sat, 11 Jan 2014 16:15:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Sat, 11 Jan 2014 16:14:46 -0800 (PST) In-Reply-To: <52D18F22.1070708@foobar.org> References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D18F22.1070708@foobar.org> From: Lorenzo Colitti Date: Sun, 12 Jan 2014 09:14:46 +0900 Message-ID: To: Nick Hilliard Content-Type: multipart/alternative; boundary=089e0116017407f81704efbadac6 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 00:15:20 -0000 --089e0116017407f81704efbadac6 Content-Type: text/plain; charset=UTF-8 On Sun, Jan 12, 2014 at 3:36 AM, Nick Hilliard wrote: > You're arguing that just because we have a protocol weakness in ipv4 that > it's ok to accept an additional instance of this kind of protocol weakness > in ipv6. This is not a sensible approach to protocol engineering. > Actually, I think it is - because the fundamental weakness (i.e., malicious host on L2 link) is the same, the impact is the same, and the countermeasures are the same. Thinking it's different just because the IPv6 case uses a spoofed RA packet and the IPv4 case uses spoofed DHCP packets is what's not sensible, I think. In other words: you already have this problem in IPv4 with DHCP. And the things you have to do to defend against it in IPv4 with DHCP and in IPv6 with RA are the same - either strong L2 security or link segmentation. - If you don't care about this problem, that's fine, but then you can't reasonably argue that we need routing in DHCPv6 to solve it - because routing in DHCPv6 can't solve it. - If you do care about this problem, then you will presumably put proper safeguards in place, and those safeguards will work for both IPv4 and IPv6, so you won't need routing in DHCPv6. I do understand that you want routing in DHCPv6 for other reasons that make sense. But I don't think this one is a reasonable justification. --089e0116017407f81704efbadac6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Jan 12, 2014 at 3:36 AM, Nick Hilliard <nick@foobar.org> w= rote:
You're arguing that just because we have a protocol we= akness in ipv4 that
it's ok to accept an additional instance of this kind of protocol weakn= ess
in ipv6. =C2=A0This is not a sensible approach to protocol engineering.
=

Actually, I think it is - because the fund= amental weakness (i.e., malicious host on L2 link) is the same, the impact = is the same, and the countermeasures are the same. Thinking it's differ= ent just because the IPv6 case uses a spoofed RA packet and the IPv4 case u= ses spoofed DHCP packets is what's not sensible, I think.

In other words: you already have this problem in IPv4 w= ith DHCP. And the things you have to do to defend against it in IPv4 with D= HCP and in IPv6 with RA are the same - either strong L2 security or link se= gmentation.
  • If you don't care about this problem, that's fine, but= then you can't reasonably argue that we need routing in DHCPv6 to solv= e it - because routing in DHCPv6 can't solve it.
  • If you do = care about this problem, then you will presumably put proper safeguards in = place, and those safeguards will work for both IPv4 and IPv6, so you won= 9;t need routing in DHCPv6.
I do understand that you want routing in DHCPv6 for other reasons= that make sense. But I don't think this one is a reasonable justificat= ion.
--089e0116017407f81704efbadac6-- From lorenzo@google.com Sat Jan 11 16:50:57 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3DC61A1F7D for ; Sat, 11 Jan 2014 16:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcRGH2Jln0K2 for ; Sat, 11 Jan 2014 16:50:55 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7D71A1F71 for ; Sat, 11 Jan 2014 16:50:55 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id j1so1517288iga.2 for ; Sat, 11 Jan 2014 16:50:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=G4yQmsAdNSlVYkwN41Oziigy/jVetdkRsKRK5sGVw/E=; b=e6RBSk4Ryq24i1V0xFjUiJzNJyfSc01e+ZbXgADp61NdyfULEn0tyLb5ujiV+yUhVu 9vjizpX8ohGM30Rzax5d9b94607nuHjIvThHtm0woPqpR5R0TbNez0kRx3pwaujpBfC3 pFVHh8rF7KTO/BBb/WOzr77IQ2PiLFag6eCqs53QEpSKXg+BpaKAO9FPMCbiKbckt/Dm G3VGDYwJRFc1x6MpHX/XSj/j2OeXmDwsa46SzKBrmtkuP6pAfaljRu3gId4PNMPyPnD1 GuuLkWBp7S2QoLrKqEd76c8O7Yo0ZSaszdHXFtJtlMbtudZZeVyRZOyVB12Hc7EIiVmW JYnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=G4yQmsAdNSlVYkwN41Oziigy/jVetdkRsKRK5sGVw/E=; b=Znr8RfYDAM0/DJt7HvymTgpYg6f/dqR1Ibeg01yhtNzHvvfWftGleLTEvJWZbogbAd vYU2wWG+c5H2CIgph2zSsslNLBw1pqinHEjghZx/DoWSd6VBTdJI9sLa5w+IzRt7Kj0N cyPDiSsfsNlPtBXYuSXsQyqYFzGm5mOj7G1gjgeaBZDKk8uSl6/C26X53t5ZMxXJ8sjO Us8mGn79WjrgVFhEIc079+x5om0OcYJj6/n293Gfu2/TQnhbV40t8PiKoAQFab2fzSP0 ukiOnpzBoxXeSYY70p4AFD3kPWIIoztnqIvCEwGFjEjU7JKzpyh/wvNbNBd30aQA49M5 ZGng== X-Gm-Message-State: ALoCoQn6+fvN/kT/sgqn/dJoCProGsmGC1H6fxSBd/rhB8wXzRy1+WCWRDwffVFb70/Pc/zrj3efAJhpC5y9hNY1PHmmTja/uf09AKZyExPvgud3DAFM7VngltrOckoKJxgx6pR2jxhO/HTbompHy0KTpGFOa8Qm59HbVIltR+gpk+1yyDUGr0cX49obX5W4BuuMY44wSZ+A X-Received: by 10.50.238.162 with SMTP id vl2mr11595799igc.45.1389487844678; Sat, 11 Jan 2014 16:50:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Sat, 11 Jan 2014 16:50:24 -0800 (PST) In-Reply-To: <2CECDE88-E00F-4826-9C86-2F4A9A5A9857@nominum.com> References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <2CECDE88-E00F-4826-9C86-2F4A9A5A9857@nominum.com> From: Lorenzo Colitti Date: Sun, 12 Jan 2014 09:50:24 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=001a11335cfc6703a704efbb598b Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 00:50:58 -0000 --001a11335cfc6703a704efbb598b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Jan 11, 2014 at 10:35 PM, Ted Lemon wrote: > > Sorry to be the bearer of bad news, but Mikael is right. A malicious > host on your link WILL take down your network. You either defend against > that or you cross your fingers. And using DHCP is NOT a defense. > > An RA can take down the network quickly, with a single multicast, and nee= d > not be malicious=E2=80=94it could simply be a mistake. RA guard is more than adequate to protect against mistakes. > A device misconfigured to proxy ARP can do a lot of damage, but once yo= u > turn it off the damage stops in about 180 seconds (or is it 120?). > Please read the other attack I mentioned in the same email. That's more sophisticated than a single RA packet, but it has exactly the same effects in DHCPv4 that a rogue RA would have. > Please don't mistake my devil's advocate position here for a position > advocating that we change how RA and DHCP work. What I am trying to do = is > get clarity, not advocate one thing or another. Lots of people have bee= n > arguing that they really want a DHCPv6 route option for a long time. If > it really didn't matter, they would have stopped by now, and at least it > would be _different_ people arguing for it. > Ok, but if you want clarity, then please take the first step of analyzing and understanding the problem yourself (you said yourself that you weren't sure about it) before playing devil's advocate? Otherwise you're not creating clarity, you're creating confusion. > So, it's important to understand _why_ they are arguing for it. It's no= t > clear to me that there's a use case that would motivate any architectural > change, but documenting the use cases that exist is worthwhile, and is > something we've failed to do several times. That's right - because many of the use cases that have been proposed look reasonable on the surface, like this one, but then don't turn out to be real. I think the majority of the reason that people argue for routing in DHCPv6 is that they want their IPv6 designs to look like their IPv4 designs. There are a couple of other reasons that do make sense, but they are minor, and I think they can be fixed in other IPv6 protocols. So what happens is that the opponents of routing in DHCPv6 ask "We don't think this is a good idea. Do you have use cases that require it?". Then, a bunch of use cases are documented, but unfortunately, since none of the use cases are the actual reason ("we want IPv6 provisioning to look like IPv4"), most of them are not convincing. We've been through this before - if you remember, the use cases in the latest routing-in-dhcp draft were a) written after the rest of the draft (which is already a bit strange - in general you'd expect to document the solution after the problem, right?), and b) determined by the WG to be mostly bogus and thrown out. Another recent example is http://www.ietf.org/mail-archive/web/v6ops/current/msg18372.html . The assertion was "we need routing in DHCPv6, and if the IETF doesn't give it to us, we will pay for it and make it happen anyway". That seems well and good, but the actual use case is not actually convincing. The IPv4 design is based on static sharding hosts to four IPv4 default gateways. If you think about it for a bit, you'll realize that four RAs and ECMP would not only do the job, but would actually be a much better design. That fact didn't stop this scenario from being cited as a use case. So when I hear people like Nick describing their use cases, I think this > is constructive, and I really want to see it documented. I do not want t= o > see him shouted down because you are concerned that if his use cases are > documented, it will motivate changes to the architecture. That's really > not how IETF process is supposed to work. > I'm not shouting down Nick - in fact, I replied to you, not to him. I do think we should ensure we as a community don't decide to put routing into DHCPv6 based on weak or invalid use cases, and I would hope that you agree with that and will help me with it. --001a11335cfc6703a704efbb598b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Jan 11, 2014 at 10:35 PM, Ted Lemon <ted.lemon@nominum.com>= wrote:
> Sorry to be the bearer of bad news, but Mikael i= s right. A malicious host on your link WILL take down your network. You eit= her defend against that or you cross your fingers. And using DHCP is NOT a = defense.

An RA can take down the network quickly, with a single multicast, and= need not be malicious=E2=80=94it could simply be a mistake.

RA guard is more than adequate to protect against mistake= s.
=C2=A0
=C2=A0 A device misconfigured to proxy A= RP can do a lot of damage, but once you turn it off the damage stops in abo= ut 180 seconds (or is it 120?).

Please read the other attack I mentioned i= n the same email. That's more sophisticated than a single RA packet, bu= t it has exactly the same effects in DHCPv4 that a rogue RA would have.
=C2=A0
Please don't mistake my devil's a= dvocate position here for a position advocating that we change how RA and D= HCP work. =C2=A0 What I am trying to do is get clarity, not advocate one th= ing or another. =C2=A0 Lots of people have been arguing that they really wa= nt a DHCPv6 route option for a long time. =C2=A0 If it really didn't ma= tter, they would have stopped by now, and at least it would be _different_ = people arguing for it.

Ok, but if you want clarity, then please t= ake the first step of analyzing and understanding the problem yourself (you= said yourself that you weren't sure about it) before playing devil'= ;s advocate? Otherwise you're not creating clarity, you're creating= confusion.
=C2=A0
So, it's important to understand _why= _ they are arguing for it. =C2=A0 It's not clear to me that there's= a use case that would motivate any architectural change, but documenting t= he use cases that exist is worthwhile, and is something we've failed to= do several times.

That's right - because many of the use cases that h= ave been proposed look reasonable on the surface, like this one, but then d= on't turn out to be real.

I think the majority= of the reason that people argue for routing in DHCPv6 is that they want th= eir IPv6 designs to look like their IPv4 designs. There are a couple of oth= er reasons that do make sense, but they are minor, and I think they can be = fixed in other IPv6 protocols. So what happens is that the opponents of rou= ting in DHCPv6 ask "We don't think this is a good idea. Do you hav= e use cases that require it?". Then, a bunch of use cases are document= ed, but unfortunately, since none of the use cases are the actual reason (&= quot;we want IPv6 provisioning to look like IPv4"), most of them are n= ot convincing.

We've been through this before - if you remember, t= he use cases in the latest routing-in-dhcp draft were a) written after the = rest of the draft (which is already a bit strange - in general you'd ex= pect to document the solution after the problem, right?), and b) determined= by the WG to be mostly bogus and thrown out.

Another recent example is http://www.ietf.org/ma= il-archive/web/v6ops/current/msg18372.html . The assertion was "we= need routing in DHCPv6, and if the IETF doesn't give it to us, we will= pay for it and make it happen anyway". That seems well and good, but = the actual use case is not actually convincing. The IPv4 design is based on= static sharding hosts to four IPv4 default gateways. If you think about it= for a bit, you'll realize that four RAs and ECMP would not only do the= job, but would actually be a much better design. That fact didn't stop= this scenario from being cited as a use case.

=C2=A0 So when I hear people like Ni= ck describing their use cases, I think this is constructive, and I really w= ant to see it documented. =C2=A0I do not want to see him shouted down becau= se you are concerned that if his use cases are documented, it will motivate= changes to the architecture. =C2=A0 That's really not how IETF process= is supposed to work.

I'm not shouting down Nick - in fact, = I replied to you, not to him. I do think we should ensure we as a community= don't decide to put routing into DHCPv6 based on weak or invalid use c= ases, and I would hope that you agree with that and will help me with it.
--001a11335cfc6703a704efbb598b-- From lorenzo@google.com Sat Jan 11 17:08:00 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C571AD944 for ; Sat, 11 Jan 2014 17:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfjW75pGD03g for ; Sat, 11 Jan 2014 17:07:58 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D4FD21A1F7B for ; Sat, 11 Jan 2014 17:07:58 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id tp5so836096ieb.20 for ; Sat, 11 Jan 2014 17:07:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0KaGPlFwasqa/k8rrlYVXD3Il8uzx90dLuauySgquKc=; b=DPhavXNcrRphJGRD8h4nk5kIXIJ+jE5IeVHpIL4znry3P6ZtHiJ+DNK9yMRErpQ5aI ajdy6ns9VS3i+nI9cZiGuDkhF+neuQ+XtdpuWnkE4ZbpTQZlCsvjfrWsDFqmkCtDvqpB yAJa+2rx0yLBdMl32tcUzQfDagrtZEh27PMdJ1W/z6SJe7wNzrWnHHPaCUceJZD6JbeF oCE21XV1vgDnduvU3lfZqGDms0khMz3K13o4V559Hqd37YN/9UQ4iDDFuetD+fJH3J0H V9aCUY//YJNuNb916R9Id4LcjOVR3aKcJFfRHvdnzMI3UAhgU2aD07Q+wxL2OPxsN0sS vPdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0KaGPlFwasqa/k8rrlYVXD3Il8uzx90dLuauySgquKc=; b=BLgjnXSZekqnKHS+XLX6ltABCKGoZHkF1Q8V/iYJW1tSlOaAqZY0xw3BhJDL9YURFG ar/FeUvSfd1K4RDxIlSicK31OTb/Q9fZc4MUVO7gsul6hE1dvNx5MZ0Mr5iO1A6MWI/R OFVS+ZUBTbpenDbuWNrUnz6yjzKGGTE+BFApv9omHSKBVIuKQeFhq0LhYqtvLv8LL7nb yLX46IU26Ns6Xb81+CTo5psjUAyO1qPUym6cv8SWzzgXeEmWFWxmp8njEcYpmX8nqSue ytkWBobqM3Hb+mQawegOlxdrIosthpfwFttkq3mIORfsCUodtjNTNsIvfhSQ5BKGg6WW Ky2A== X-Gm-Message-State: ALoCoQlh7TMb+D+j1mhujt8we7bwIItp+llx6/2A2xSMZ1K20PG5FP1KN4EVlszxeRFN/PiC2L1eVb6prwYYM/OfYOjqB4flRgvPqirA9oMOXryzvjzvfY9r2YqPSBjATkSYofcAdlNTFJTDglkoL+Kw5GB/G216SVWhKiGkNx+x5ZF+SXvJPFW+vMwunbV4DJVTNoUDixZH X-Received: by 10.50.61.101 with SMTP id o5mr11670971igr.31.1389488868105; Sat, 11 Jan 2014 17:07:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Sat, 11 Jan 2014 17:07:28 -0800 (PST) In-Reply-To: <52D193E7.7060403@foobar.org> References: <52D193E7.7060403@foobar.org> From: Lorenzo Colitti Date: Sun, 12 Jan 2014 10:07:28 +0900 Message-ID: To: Nick Hilliard Content-Type: multipart/alternative; boundary=001a113603506744ef04efbb96f8 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 01:08:00 -0000 --001a113603506744ef04efbb96f8 Content-Type: text/plain; charset=UTF-8 On Sun, Jan 12, 2014 at 3:56 AM, Nick Hilliard wrote: > Matt needs to run DHCPv6 anyway, Because... ? If Matt works for the same billion-dollar enterprise he worked for a while ago, then he runs a single-tenant datacenter, where it's perfectly reasonable to configure the hosts via other protocols than DHCPv6. > it requires the routers to maintain a pile of RADIUS state Nope: RS in, RADIUS request out, RADIUS reply in, RA out. No state. > which they don't need to do, opens them up to DoS attacks (requests from > multiple v6 addresses), Which they have to in DHCPv6, too - anyone on the link can send them a request. > Whether you want to refer to this as "insane" is of course your own > choice, but I am glad that you have at least some appreciation that this > suggestion hails from the Heath Robinson school of network design. > I don't know how you can say that, given that the number of packets is the same: In DHCPv6, a multicast solicit request gets sent. The router receives it and sends a request to a server, the server sends an answer back to the router, and the router relays it to the host. In this scheme, a multicast RS gets sent. The router receives it and sends a RADIUS request to the server, the server sends an answer back to the router, and the router sends an RA to the host. Regardless of that - it seems to me that in a single-tenant architecture, ECMP over multiple RAs is a much better solution, and the only reason that Matt has this design in the first place is that *you can't do that in DHCPv4*. --001a113603506744ef04efbb96f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Jan 12, 2014 at 3:56 AM, Nick Hilliard <nick@foobar.org> w= rote:
Matt needs to run DHCPv6 anyway,

Because... ? If Matt works for the same billion-dollar= enterprise he worked for a while ago, then he runs a single-tenant datacen= ter, where it's perfectly reasonable to configure the hosts via other p= rotocols than DHCPv6.
=C2=A0=C2=A0
it=C2=A0requires the = routers to maintain a pile of RADIUS state

= Nope: RS in, RADIUS request out, RADIUS reply in, RA out. No state.
=C2=A0
which they don't=C2=A0= need to do, opens them up to DoS attacks (requests from multiple v6=C2=A0ad= dresses),

Which they have to in DHCPv6, too - anyone on the link = can send them a request.
=C2=A0=C2=A0
Whether you want to refer to this as "insane" is of course your o= wn choice,=C2=A0but I am glad that you have at least some appreciation that= this suggestion=C2=A0hails from the Heath Robinson school of network desig= n.

I don't know how you can say that, giv= en that the number of packets is the same:

In DHCP= v6, a multicast solicit request gets sent. The router receives it and sends= a request to a server, the server sends an answer back to the router, and = the router relays it to the host.

In this scheme, a multicast RS gets sent. The router re= ceives it and sends a RADIUS request to the server, the server sends an ans= wer back to the router, and the router sends an RA to the host.

Regardless of that - it seems to me that in a single-tenant = architecture, ECMP over multiple RAs is a much better solution, and the onl= y reason that Matt has this design in the first place is that *you can'= t do that in DHCPv4*.
--001a113603506744ef04efbb96f8-- From markzzzsmith@yahoo.com.au Sat Jan 11 17:37:00 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7061AD948 for ; Sat, 11 Jan 2014 17:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtC8M87pQF1s for ; Sat, 11 Jan 2014 17:36:58 -0800 (PST) Received: from n6-vm6.bullet.mail.bf1.yahoo.com (n6-vm6.bullet.mail.bf1.yahoo.com [72.30.234.93]) by ietfa.amsl.com (Postfix) with SMTP id 69CF81AD945 for ; Sat, 11 Jan 2014 17:36:58 -0800 (PST) Received: from [66.196.81.179] by n6.bullet.mail.bf1.yahoo.com with NNFMP; 12 Jan 2014 01:36:47 -0000 Received: from [98.139.212.230] by t9.bullet.mail.bf1.yahoo.com with NNFMP; 12 Jan 2014 01:36:47 -0000 Received: from [127.0.0.1] by omp1039.mail.bf1.yahoo.com with NNFMP; 12 Jan 2014 01:36:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 863455.71820.bm@omp1039.mail.bf1.yahoo.com Received: (qmail 74718 invoked by uid 60001); 12 Jan 2014 01:36:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1389490607; bh=r0RQjXOvw2bGtwldnwUJ6RMUIHBt7z4yjTA35hcIARs=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=k2yE6rvvMdwlMf2zvbYoCdGAI3WpMCQfq2WaNiIF6ACTzm/o+ihN6SlzSAT6VC7LxE9oYI+y1vPyMSJaR/hGIJYzwnliDxmU11V1C9zL9XR5XL3WBoGffgFzg7Pqvj0Fcd+6fWa3nJY2659opoxiKW60DoqNO0n6qK7bhEAEd4M= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HpcdWHzpq9Sy4WIBa7PYruSD1skQMKaxm5q5lvqQhDvo5Yh73jB7V3rtzIfpzTTh6TTvT6dUOj8ivO7bNmOwWPnDt8fNVn5UYwoAK6ZvC8nyvD7UTBsB/Q8j26bKHZvt6WSGFUK+zH1gdW9wn6q0mX1cgCbCvHiQtjbcmeCd+xQ=; X-YMail-OSG: 1VtW_cgVM1nSoqh_Fr8Q9br1P_TEQwrzmCbFTcMAGwdgGdf tVK5dlH5fwzGU76T30AHChC8P7F8WShpp3D_VZgDdDhiQiaBpTgNxohevCPo k_1HIavBPk4lbk4mklxiFMHnXvj0S1OTr88.XUMG.nPFJnvX7toHI_kp9o.p 7eNR6WYGcc_WBLclwniel9XxR56iZhq3x5GhJ_8.0ipBAQKyV_c1LiUsKhWu MEGwLrzKueUeVN7UUZYls.Y4NF_ucon7.zLY7Prpo0WduvUbhCsQKiaMJ9Gr DlOn8tqQpBn6DhR8Fi8ffJ37ldEe9ikAg3ShNVz0zQaBTH43j223EBq_UQbi UgvH9gsqXjP8FayGjilDAwih6PbV23GeJFnGzFPJ8uCbF6dR7KGNUiDfuHQu EIKUlG.BS0kNzWJmwMEnF.FOYce8LHDRdRXKCmiElSBJ8.qrAH_SWzb.5Mcq abLDsKAmSnZsi5E6t16JC59TexNloHsEM5YIWTnPSLgAxP0T4CBVMcpNKn1P lhk9PAdNmIsTLICfejQWMWDQqzHX3T9lldBdiSAy4UbvGFWRY.XgsaSE1.0j ojOOQYOpsjQmG7rPpTeCgTpM- Received: from [150.101.221.237] by web161904.mail.bf1.yahoo.com via HTTP; Sat, 11 Jan 2014 17:36:47 PST X-Rocket-MIMEInfo: 002.001, CgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbT4KPlRvOiBOaWNrIEhpbGxpYXJkIDxuaWNrQGZvb2Jhci5vcmc.IAo.Q2M6ICJ2Nm9wc0BpZXRmLm9yZyBXRyIgPHY2b3BzQGlldGYub3JnPiAKPlNlbnQ6IFN1bmRheSwgMTIgSmFudWFyeSAyMDE0IDExOjE0IEFNCj5TdWJqZWN0OiBSZTogW3Y2b3BzXSBjb250cm9sIGFuZCBzZWN1cml0eSBvZiBESENQCj4gCj4KPgo.T24gU3VuLCBKYW4gMTIsIDIwMTQgYXQgMzoBMAEBAQE- X-Mailer: YahooMailWebService/0.8.172.614 References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D18F22.1070708@foobar.org> Message-ID: <1389490607.51957.YahooMailNeo@web161904.mail.bf1.yahoo.com> Date: Sat, 11 Jan 2014 17:36:47 -0800 (PST) From: Mark ZZZ Smith To: Lorenzo Colitti , Nick Hilliard In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 01:37:00 -0000 =0A=0A=0A=0A=0A>________________________________=0A> From: Lorenzo Colitti = =0A>To: Nick Hilliard =0A>Cc: "v6ops@= ietf.org WG" =0A>Sent: Sunday, 12 January 2014 11:14 AM=0A= >Subject: Re: [v6ops] control and security of DHCP=0A> =0A>=0A>=0A>On Sun, = Jan 12, 2014 at 3:36 AM, Nick Hilliard wrote:=0A>=0A>You'= re arguing that just because we have a protocol weakness in ipv4 that=0A>>i= t's ok to accept an additional instance of this kind of protocol weakness= =0A>>in ipv6. =A0This is not a sensible approach to protocol engineering.= =0A>>=0A>=0A>=0A>Actually, I think it is - because the fundamental weakness= (i.e., malicious host on L2 link) is the same, the impact is the same, and= the countermeasures are the same. Thinking it's different just because the= IPv6 case uses a spoofed RA packet and the IPv4 case uses spoofed DHCP pac= kets is what's not sensible, I think.=0A>=0A=0A=0ASo recently I've been thi= nking about this issue more broadly. I haven't fully thought through all th= e topics and content, however the title I've come up with is:=0A=0A'Are Bro= adcast Multi-Access Subnetworks becoming "Considered Harmful"'?=0A=0ABMAs, = such as Ethernets, do and have provided a number of advantages:=0A=0A(1) th= e boundary of the BMA subnetwork has been used as the boundary of an IPv4/I= Pv6 prefix. As a IPv4/IPv6 prefix summarises a range of addresses, that is = one of the things that has allowed the routing system to scale.=0A=0A(2) th= ey've also corresponded to or been made to correspond to security domains, = using e.g, VLANs. The IPv4/IPv6 prefix has then been used as a security pol= icy tool, grouping the hosts together, to grant group rather than individua= l access to other resources.=0A=0A(3) they could provide direct link-layer = unicast, broadcast or multicast access to all other nodes (i.e., peer-to-pe= er or full-mesh connectivity), such as a locally attached server, reducing = the costly to forward layer 3 traffic.=0A=0AI think (2) is starting to be f= alse. It assumes that all hosts can equally be trusted to not disrupt other= s, by either attacking them directly (via spoofing e.g., RAs, or via traffi= c DoS to an individual node), or by abusing the shared transmission resourc= e the BMA provides, impacting all hosts. For this to be always and continue= to be true, the trust level of each host must not change, and for it to no= t change it needs to be continuously operated by a trusted party and attach= ed to the same and single BMA subnet.=0A=0A=0AI think mobility of hosts (i.= e., laptops) has made that false, because something as simple as the host b= eing attached to a different network with a different administration (e.g.,= a home or hotel network) may mean that the host now should not be trusted.= BYOD is a more extreme case - the BMA subnetwork operator will have less o= r no opportunity for control over the hosts.=0A=0AI think (3) has also beco= me mostly false. Servers are grouped to together on server subnets, with th= e clients being on their own subnets, 1 or more layer 3 hops away. "Cloud c= omputing" is the most extreme case of this. There is very little direct nod= e-to-node traffic, other than traffic to operate the BMA subnetwork itself.= Application traffic is mostly to or from off-link destinations or sources.= =0A=0AThe only advantage that we still get from BMA subnetworks is being ab= le to group hosts' layer 3 addresses together as a single prefix and then u= sing that to scale the routing system. That is still a useful property beca= use it avoids host routing or per-host prefix routing.=0A=0A=0AMeasures suc= h as RA guard or DHCP guard attempt to address the issue of lack of host tr= ust, however they struggle because they're layer 2 devices attempting to pe= rform layer 3 or higher layer analysis.=0A=0ASo why not properly isolate th= e hosts at layer 2, removing the implicit trust they have, at the cost of u= niversal direct peer-to-peer transmission that is rarely used? Move to a hu= b-and-spoke forwarding model, such that they always have to go through a la= yer 3 intermediary that is a security policy enforcement point to reach any= other host, even those within the same IPv4/IPv6 prefix, while still prese= rving the ability to group hosts within a single IPv4/IPv6 prefix for the b= enefit of scaling the routing system? Preserve broadcast/multicast to some/= all hosts capability only for the trusted layer 3 intermediary.=0A=0AThis i= s certainly not a new idea - it is the "Private VLANs" or Broadband forum N= :1 model (and might go by other names). However, my thoughts are that it ne= eds to become far more common, and perhaps the default. There might be some= open issues such as multicast (is it legal for a router to forward multica= st back out the interface it received them from, assuming they're ok to for= ward, and how would a host deal with receiving it's own multicasts if the r= outer simplistically forwards them back to all hosts, including the hosts t= hat sent them).=0A=0AI think this fundamentally means start working from an= assumption that all hosts are untrusted, rather than assuming that the maj= ority are trusted, and then putting in place less than completely effective= partial measures to deal with the assumed occasional attachment of unstrus= ted hosts.=0A=0A=0ARegards,=0AMark. From nick@foobar.org Sun Jan 12 06:39:05 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB131ADFB1 for ; Sun, 12 Jan 2014 06:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzEc8ugh3j6O for ; Sun, 12 Jan 2014 06:39:03 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 21EE91ADE84 for ; Sun, 12 Jan 2014 06:39:02 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id s0CEcg34016595 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 12 Jan 2014 14:38:48 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org Message-ID: <52D2A8EF.2040901@foobar.org> Date: Sun, 12 Jan 2014 14:38:39 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mark ZZZ Smith , Lorenzo Colitti References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D18F22.1070708@foobar.org> <1389490607.51957.YahooMailNeo@web161904.mail.bf1.yahoo.com> In-Reply-To: <1389490607.51957.YahooMailNeo@web161904.mail.bf1.yahoo.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 14:39:05 -0000 On 12/01/2014 01:36, Mark ZZZ Smith wrote: > 'Are Broadcast Multi-Access Subnetworks becoming "Considered Harmful"'? They're probably the worst possible way of handling multiple access networks, with the exception of all the others. And if anyone mentions ATM, I'm totally claiming godwin. Nick From internet-drafts@ietf.org Sun Jan 12 11:21:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0B11AE013; Sun, 12 Jan 2014 11:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFvGdQQHbd_d; Sun, 12 Jan 2014 11:21:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C83E01AE01A; Sun, 12 Jan 2014 11:21:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140112192103.21333.46615.idtracker@ietfa.amsl.com> Date: Sun, 12 Jan 2014 11:21:03 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-incremental-ipv6-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 19:21:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Enterprise IPv6 Deployment Guidelines Authors : Kiran K. Chittimaneni Tim Chown Lee Howard Victor Kuarsingh Yanick Pouffary Eric Vyncke Filename : draft-ietf-v6ops-enterprise-incremental-ipv6-05.txt Pages : 34 Date : 2014-01-12 Abstract: Enterprise network administrators worldwide are in various stages of preparing for or deploying IPv6 into their networks. The administrators face different challenges than operators of Internet access providers, and have reasons for different priorities. The overall problem for many administrators will be to offer Internet- facing services over IPv6, while continuing to support IPv4, and while introducing IPv6 access within the enterprise IT network. The overall transition will take most networks from an IPv4-only environment to a dual stack network environment and eventually an IPv6-only operating mode. This document helps provide a framework for enterprise network architects or administrators who may be faced with many of these challenges as they consider their IPv6 support strategies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-enterprise-incremental-ip= v6/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-enterprise-incremental-= ipv6-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mpetach@gmail.com Sun Jan 12 23:27:34 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72F31AE048 for ; Sun, 12 Jan 2014 23:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.352 X-Spam-Level: ** X-Spam-Status: No, score=2.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FB_INCREASE_VOL=3.629, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dEhbotienL7 for ; Sun, 12 Jan 2014 23:27:33 -0800 (PST) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 365B51AE02E for ; Sun, 12 Jan 2014 23:27:33 -0800 (PST) Received: by mail-pd0-f176.google.com with SMTP id r10so3069222pdi.35 for ; Sun, 12 Jan 2014 23:27:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=1bv/aL7f4uY7n6yICu7zfKm7D7nLJPjVWtUVCdDAv0U=; b=lZ20qw62BCy+jQNZIf5qQiXtS9xJEU6uicngNpIzs2gYDVfSvIRY3XExbWbQkrDUPm RxFpOM7QtQ/TvdIImnziMTcTrEkMIPAA9y/gQoWcuV0QAxIdA8TySkr3iZJM0ohwFNH6 X7BLj46ByVgzvajoVv3zJK1HDaJbBslw2199+f4ELvbyqZT1SS4m7tSZhXctqu46Xm7v 1bKaMYPY2+Hju1y0CbVJW6/6GIJmnAAFYmkTsSIF5M6pLFdbLlgDq5PiZFyaVdjJkvdk WwrBjNN6OI/oykV3QQmIY1xG/dwv8D6qf7pEJ7/HiaRdBX3aafTZsKMl6NwiRTvRpGP9 JqlA== MIME-Version: 1.0 X-Received: by 10.66.66.202 with SMTP id h10mr28209028pat.70.1389598042462; Sun, 12 Jan 2014 23:27:22 -0800 (PST) Sender: mpetach@gmail.com Received: by 10.70.1.130 with HTTP; Sun, 12 Jan 2014 23:27:22 -0800 (PST) In-Reply-To: <71B4A0D3-B4F2-4B3C-B38E-ED7678BEA6FE@nominum.com> References: <71B4A0D3-B4F2-4B3C-B38E-ED7678BEA6FE@nominum.com> Date: Sun, 12 Jan 2014 23:27:22 -0800 X-Google-Sender-Auth: Db7iQemocJmGs_lvM51pqJ_vYgc Message-ID: From: Matthew Petach To: Ted Lemon Content-Type: multipart/alternative; boundary=001a1134a866b3a10a04efd5010c Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 07:27:35 -0000 --001a1134a866b3a10a04efd5010c Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 9, 2014 at 3:56 AM, Ted Lemon wrote: > On Jan 8, 2014, at 9:56 PM, Matthew Petach wrote: > > 4 groups of hosts on the subnet; > > groupA, groupB, groupC, groupD; > > four different policies on the DHCP server. > > subnet has 4 different upstream routers. > > groupA is handed IP address on routerA as default gateway > > groupB is handed IP address on routerB as default gateway > > groupC is handed IP address on routerC as default gateway > > groupD is handed IP address on routerD as default gateway > > > > all four groups are within the same L2 broadcast domain, > > and have applications that make use of that same-subnet > > relationship. > > So is the problem you are trying to solve here essentially a cheap SDN > solution? Why not simply isolate the four groups of hosts onto four > separate VLANs? > > That would either require rewriting the applications running on the hosts to use unicast communication between them, with a corresponding increase in the volume of traffic, or implement some scheme for handling non-unicast frames between VLANs that I'm not currently aware of. I realize this setup isn't typical; but it's there, and I find it odd that the reaction from the community seems to be "people should stop trying to stretch the lifespan of IPv4 and just move to IPv6" at the same time saying "you should stop doing things the v4 way, and change your mindset and topology to match the v6 way". The more impediments and roadblocks there are to seamlessly converting from v4 to v6 there are, the less incentive there is to move away from v4, and the longer it is we'll continue to have v4-only sites on the internet...which will continue to ensure that the v6-only internet can never become reality. As long as we're OK with v6 being a cute side project, and not a fully functional replacement for v4, that's a fine mindset to have. But if we're serious about wanting to move the Internet wholesale to v6, we need to ease up a bit on this whole "If you won't convert to the One True V6 Way, you should just stay on v4" mantra. I get that what we're doing in the v4 world can't currently be done in the v6 world. What I don't understand is why there's so much resistance to making it possible to do it in the v6 world? Matt --001a1134a866b3a10a04efd5010c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Jan 9, 2014 at 3:56 AM, Ted Lemon <ted.lemon@nominum.c= om> wrote:
On Jan 8, 2014, at 9:56 PM= , Matthew Petach <mpetach@netfl= ight.com> wrote:
> 4 groups of hosts on the subnet;
> groupA, groupB, groupC, groupD;
> four different policies on the DHCP server.
> subnet has 4 different upstream routers.
> groupA is handed IP address on routerA as default gateway
> groupB is handed IP address on routerB as default gateway
> groupC is handed IP address on routerC as default gateway
> groupD is handed IP address on routerD as default gateway
>
> all four groups are within the same L2 broadcast domain,
> and have applications that make use of that same-subnet
> relationship.

So is the problem you are trying to solve here essentially a cheap SD= N solution? =A0 Why not simply isolate the four groups of hosts onto four s= eparate VLANs?


That would either r= equire rewriting the applications running on the
hosts to use unicast co= mmunication between them, with a
corresponding increase in the volume of= traffic, or implement
some scheme for handling non-unicast frames between
VLANs that I'm n= ot currently aware of.

I realize th= is setup isn't typical; but it's there, and I find it
odd that t= he reaction from the community seems to be
"people should stop trying to stretch= the lifespan of
IPv4 and just move to IPv6" at the same time sayin= g
"you should stop doing things th= e v4 way, and change
your mindset and topology to match the v6 way".

The more impediments and roadblocks there
are to seaml= essly converting from v4 to v6 there
are, the less incentive there is to= move away from
v4, and the longer it is we'll continue to have v4-only
sites on the= internet...which will continue to ensure
that the v6-only internet can = never become reality.

As long as we= 're OK with v6 being a cute side project,
and not a fully functional replacement for v4, that's
a fine mindset= to have.=A0 But if we're serious about
wanting to move the Internet wholesale to v6, we
need to ease up a = bit on this whole "If you won't
convert to the One True V6 Way, you should just
stay on v4" mantra.= =A0 I get that what we're doing in
the v4 world can't currently = be done in the v6 world.=A0
What I don't understand is why there= 9;s so much
resistance to making it possible to do it in the v6 world?

Matt

--001a1134a866b3a10a04efd5010c-- From otroan@employees.org Mon Jan 13 00:42:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0E01AE062 for ; Mon, 13 Jan 2014 00:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xzz3QdvL9kq for ; Mon, 13 Jan 2014 00:42:54 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id B10B61AE061 for ; Mon, 13 Jan 2014 00:42:53 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAKum01KQ/khM/2dsb2JhbABagwu6doELFnSCJQEBAQMBdwIFCwsOOFcGJ4doCKoxmhcXjwcHgySBEwEDkDOZeYFvgT87 X-IronPort-AV: E=Sophos;i="4.95,651,1384300800"; d="asc'?scan'208";a="3548836" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 13 Jan 2014 08:42:42 +0000 Received: from dhcp-lys01-vla250-10-147-113-220.cisco.com (dhcp-lys01-vla250-10-147-113-220.cisco.com [10.147.113.220]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0D8geZM030042 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Jan 2014 08:42:41 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_B2E88736-8F62-4E01-9C6B-74D5B945C430"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ole Troan In-Reply-To: Date: Mon, 13 Jan 2014 09:42:41 +0100 Message-Id: <8BD83F50-65CF-4017-9786-171DB7561319@employees.org> References: <71B4A0D3-B4F2-4B3C-B38E-ED7678BEA6FE@nominum.com> To: Matthew Petach X-Mailer: Apple Mail (2.1827) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 08:42:55 -0000 --Apple-Mail=_B2E88736-8F62-4E01-9C6B-74D5B945C430 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 > I realize this setup isn't typical; but it's there, and I find it > odd that the reaction from the community seems to be > "people should stop trying to stretch the lifespan of > IPv4 and just move to IPv6" at the same time saying > "you should stop doing things the v4 way, and change > your mindset and topology to match the v6 way". the problem you are trying to solve is load-balancing among multiple = first-hop routers on the link, right? RFC4311 doesn't do what you want? (assuming it was implemented). cheers, Ole --Apple-Mail=_B2E88736-8F62-4E01-9C6B-74D5B945C430 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS06cBAAoJEFuJXizso86gQL8IAJXwQ3+3MBHW0PtGlOtb2hqq rVB/mY7U6C80OBxGLwSaT17uQ+n1BYX6fp/r9T/n/4O27kRpCBu1TlktIfzBUOJ+ qG+U3lJ0b1P3SZFB8ad3VVb5+uMRT7GzsvOaDAJyccOH/Lkn8cPAIxap7zTxYpzX ehJ2mVV1J7vxL9zWeKmex0APu7GxdznC7X+UVSbVwQ6E5ZVnGSiJE2IAM+uxdfdU aV2IgIrn0IgNlXW0XwUssTGoGDTteiuJUOjQJxvH0qXYHUIl+BLmGdV9/wuzRbLi 3n4YT9Yw9ovLUHmvIu+okLSwNWnobC9dCYq7DMWxQNf/L5xERZ7kYpA5f+RkZI0= =FnON -----END PGP SIGNATURE----- --Apple-Mail=_B2E88736-8F62-4E01-9C6B-74D5B945C430-- From markzzzsmith@yahoo.com.au Mon Jan 13 01:21:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6706A1AE07C for ; Mon, 13 Jan 2014 01:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTHHqYwQcESi for ; Mon, 13 Jan 2014 01:21:39 -0800 (PST) Received: from nm38-vm4.bullet.mail.bf1.yahoo.com (nm38-vm4.bullet.mail.bf1.yahoo.com [72.30.239.20]) by ietfa.amsl.com (Postfix) with ESMTP id 548241ADF81 for ; Mon, 13 Jan 2014 01:21:39 -0800 (PST) Received: from [98.139.212.149] by nm38.bullet.mail.bf1.yahoo.com with NNFMP; 13 Jan 2014 09:21:28 -0000 Received: from [98.139.212.244] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 13 Jan 2014 09:20:28 -0000 Received: from [127.0.0.1] by omp1053.mail.bf1.yahoo.com with NNFMP; 13 Jan 2014 09:20:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 253247.49861.bm@omp1053.mail.bf1.yahoo.com Received: (qmail 77058 invoked by uid 60001); 13 Jan 2014 09:20:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1389604828; bh=cimGW4gSRqO6fu+KShvAMfO2ynn4ZIKhMaZmikGTfnI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=DYpkYWUAGgvudJfdNunmUsiAqjZ9r4X2aEUkMWTOrq+a7PZB+WxN5mvKF4y+ylVPDXeGbdzG2yBXRp8oJlKQghS6WD8rg4egYTnlBggoyB6DttKJ1MLE8FRRq49AIpCmtQpb14k+D01GWEYFSyuQ4NgnF17ehKCUXnF4E20gTB8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=tUZe2o/H61OrpTk+kBeCFojEUVDBJwQB2H7c0cnRweTrotECyteSdbgfxBh/eVprebdC+hGNL3PI4KYoMLuwBFmD4GhJ6YWA9lz2eqL/bfWoTFF/cwHSlQdKUq98g9cbpeBCS75w3atgs3pAh6Le7J0zHCdePvl6V6FxA6FS4+4=; X-YMail-OSG: WLqUKmMVM1nKfZDlrFFgEGhtEtyRp2zfsRCwlcIHp0pYUPD uodeShOwt7Rzu0NibTGcddFOZu46GTiJvFMJIZG0gXaqq6Ae5IB1N8oFEx_B iY8yj6dUCYPJxAeOUtV.gSOCzcADbuWld5YArGPQWsEjZrMYVXCdhKrXo3TL meaxUW951PMM4rjc.3.G_Vf8ygRxeYlKeW7X8qUvOsSgFNNwmsR7fRfVf69X 2TMRS1WjiFjincMv1igjByt3aRhMYgNfnvM5vBKoR6XaJHFPjgpV6k4RFWIR zvXNMP6f7vk6XmAXoOHKHTYR07trSh4i3POmK4L4hIgV63gKG90VHLfhl4Gh ZBtxtL47tAAYuzQaTiGyoE_cVdBQ1zKTEuU1Hv3fg0540AiN_fM3Spr3_Hct wIbAIqA9d78MC1BIJby_PYIk3evMeXvEC_O8h9v69CaqsN95ubtr1cAnURnz 73kM0wibC29OO4e1kH1vICUnaWHGvhliPI7gCQTjLaKBsenkYt0sgpcWzIdj xjpTlhf_z64y.MnE99LBzUciYDI94x.cgUMBMuBiFQDUNce4Yv6au.94eGWG ZzFbp2fGemXL6ubTtc5flkIY- Received: from [150.101.221.237] by web161904.mail.bf1.yahoo.com via HTTP; Mon, 13 Jan 2014 01:20:27 PST X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBOaWNrIEhpbGxpYXJkIDxuaWNrQGZvb2Jhci5vcmc.Cj4gVG86IE1hcmsgWlpaIFNtaXRoIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1PjsgTG9yZW56byBDb2xpdHRpIDxsb3JlbnpvQGdvb2dsZS5jb20.Cj4gQ2M6ICJ2Nm9wc0BpZXRmLm9yZyBXRyIgPHY2b3BzQGlldGYub3JnPgo.IFNlbnQ6IE1vbmRheSwgMTMgSmFudWFyeSAyMDE0IDE6MzggQU0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBjb250cm9sIGFuZCBzZWN1cml0eSBvZiABMAEBAQE- X-Mailer: YahooMailWebService/0.8.172.614 References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D18F22.1070708@foobar.org> <1389490607.51957.YahooMailNeo@web161904.mail.bf1.yahoo.com> <52D2A8EF.2040901@foobar.org> Message-ID: <1389604827.58550.YahooMailNeo@web161904.mail.bf1.yahoo.com> Date: Mon, 13 Jan 2014 01:20:27 -0800 (PST) From: Mark ZZZ Smith To: Nick Hilliard , Lorenzo Colitti In-Reply-To: <52D2A8EF.2040901@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 09:21:40 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Nick Hilliard =0A> To: Mark ZZZ Smith ; Lorenzo Colitti= =0A> Cc: "v6ops@ietf.org WG" =0A> Sent= : Monday, 13 January 2014 1:38 AM=0A> Subject: Re: [v6ops] control and secu= rity of DHCP=0A> =0A> On 12/01/2014 01:36, Mark ZZZ Smith wrote:=0A>> 'Are= Broadcast Multi-Access Subnetworks becoming "Considered =0A> Harmful"'?=0A= > =0A> They're probably the worst possible way of handling multiple access= =0A> networks, with the exception of all the others.=0A> =0A> And if anyone= mentions ATM, I'm totally claiming godwin.=0A>=A0=0A=0AI think either I'm = confused by what you're saying, or your confused by what I'm saying.=0A=0AI= 'm using the term BMA to be the opposite of NBMA, and using it to be a more= general description of nothing more than standard Ethernet, Wifi, Token ri= ng etc., links i.e. a single layer 2 link or segment that supports more tha= n two nodes ("multi-access"), allowing a single IPv4/IPv6 prefix to be used= for all nodes, where any of the nodes can equally transmit or receive unic= ast, multicast or broadcast traffic to any, some or all of the others ("bro= adcast").=0A=0AThe fundamental capability of these links that facilitates t= hings such as ARP spoofing, rogue DHCPv4 or DHCPv6 servers, or rogue RAs, i= s the ability for any node to be able to send anything to any other node wi= thout restriction. This capability may have been useful when all the attach= ed nodes were trusted to behave, usually meaning they were operated by the = same party, were always attached to the same link, meaning that they couldn= 't "go away" and then "bring back" malicious software, and the majority of = traffic stayed within the link.=0A=0ANow that we have laptops and BYOD, and= the majority of traffic is to or from off-link destinations and sources, I= think it would be better to move to a default hub-and-spoke forwarding mod= el within the link, inserting an router or smarter device between each host= and every other destination, including those attached to the same link/sam= e IPv4/IPv6 prefix. The router or smarter device can then ensure that any o= f the attacks that rely on anything to any node within the link are suppres= sed/prevented.=0A=0AThis forwarding model may not be useful for a server fa= rm subnet, because they're usually operated by the same party and therefore= equally trustworthy. In those cases the default could be switched off, res= toring anything to any node forwarding within the link.=0A=0ARegards,=0AMar= k. From internet-drafts@ietf.org Mon Jan 13 01:58:35 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43301ADF4F; Mon, 13 Jan 2014 01:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iuDn93saOf9; Mon, 13 Jan 2014 01:58:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B97C91AE0E0; Mon, 13 Jan 2014 01:58:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140113095833.27376.37313.idtracker@ietfa.amsl.com> Date: Mon, 13 Jan 2014 01:58:33 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 09:58:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : NAT64 Operational Experience Authors : Gang Chen Zhen Cao Chongfeng Xie David Binet Filename : draft-ietf-v6ops-nat64-experience-09.txt Pages : 22 Date : 2014-01-13 Abstract: This document summarizes NAT64 function deployment scenarios and operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) and NAT64 server Front End (NAT64-FE) are considered in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-nat64-experience-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jan 13 02:20:36 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F0E1AE0C4; Mon, 13 Jan 2014 02:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvPkuQWKhk3s; Mon, 13 Jan 2014 02:20:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8215D1AE076; Mon, 13 Jan 2014 02:20:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140113102034.27405.92344.idtracker@ietfa.amsl.com> Date: Mon, 13 Jan 2014 02:20:34 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 10:20:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Roaming Behavior Analysis Authors : Gang Chen Hui Deng Dave Michaud Jouni Korhonen Mohamed Boucadair Vizdal Ales Cameron Byrne Filename : draft-ietf-v6ops-ipv6-roaming-analysis-00.txt Pages : 14 Date : 2014-01-13 Abstract: This document identifies as set of failure cases encountered by an IPv6-enabled IPv6 customers in roaming scenarios. The investigations on those failed cases reveal the causes in order to notice improper configurations, equipment's incomplete functions or inconsistent IPv6 introduction strategy. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-roaming-analysis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-roaming-analysis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Ted.Lemon@nominum.com Mon Jan 13 05:04:33 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0D51AE15A for ; Mon, 13 Jan 2014 05:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.571 X-Spam-Level: X-Spam-Status: No, score=-0.571 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_INCREASE_VOL=3.629, RCVD_IN_DNSWL_MED=-2.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMiXLjXbrioS for ; Mon, 13 Jan 2014 05:04:32 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id BB5D01ADEDC for ; Mon, 13 Jan 2014 05:04:32 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUtPkVUwxogIhT6NEUX6QKnuUljpeJ/3J@postini.com; Mon, 13 Jan 2014 05:04:22 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 962781B82E0 for ; Mon, 13 Jan 2014 05:04:21 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id D1A3D19005C; Mon, 13 Jan 2014 05:04:20 -0800 (PST) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Jan 2014 05:04:20 -0800 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Mon, 13 Jan 2014 08:04:21 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <036EBAD1-C459-466B-ADB5-C1A7EA5BAFC6@nominum.com> References: <71B4A0D3-B4F2-4B3C-B38E-ED7678BEA6FE@nominum.com> To: Matthew Petach X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 13:04:33 -0000 > On Jan 13, 2014, at 2:27 AM, Matthew Petach = wrote: >> So is the problem you are trying to solve here essentially a cheap = SDN solution? Why not simply isolate the four groups of hosts onto = four separate VLANs? > That would either require rewriting the applications running on the > hosts to use unicast communication between them, with a > corresponding increase in the volume of traffic, or implement > some scheme for handling non-unicast frames between > VLANs that I'm not currently aware of. I didn't say any of the things you said someone had said to you after = this paragraph, so I won't respond to that, but could you please explain = the application that drives you to use this configuration? From fred@cisco.com Mon Jan 13 05:45:26 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53381ADFA7 for ; Mon, 13 Jan 2014 05:45:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.039 X-Spam-Level: X-Spam-Status: No, score=-115.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ALIr5aP49Lj for ; Mon, 13 Jan 2014 05:45:25 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 48B5F1ADFA2 for ; Mon, 13 Jan 2014 05:45:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=140; q=dns/txt; s=iport; t=1389620714; x=1390830314; h=date:from:message-id:to:subject:cc; bh=SupQ5oiJh1AUdZcrJ536A6DrxsbRCXV3XcnDj4lP6a8=; b=GGSmULeDAtJv+04p+njeuq/njDKDlKG71kQy4NrGsTCc4bcA0ecrBApq IQvDyl05T8oIcehDwjl51o5VfhAXHz6S1wvB+6O6335Alu8tFYduKDllp 8rY24R75++cs1b0RLgSbtg7ekErFwlsyulps8JeiYq/EmKZ0PILvjeBmB U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcKAG3t01KrRDoJ/2dsb2JhbABagws4qFYBkWMDBAKBEBZ0gyU8LQeIZA7EdxePBx2EIQSJQ5AEkGWDTg X-IronPort-AV: E=Sophos;i="4.95,653,1384300800"; d="scan'208";a="100330567" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 13 Jan 2014 13:45:12 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0DDj1NO028082; Mon, 13 Jan 2014 13:45:09 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id s0DDj1R06954; Mon, 13 Jan 2014 05:45:01 -0800 (PST) Date: Mon, 13 Jan 2014 05:45:01 -0800 (PST) From: Message-Id: <201401131345.s0DDj1R06954@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-ietf-v6ops-ipv6-roaming-analysis@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 13:45:27 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-roaming-analysis. Please take a look at it and comment. From Fred.L.Templin@boeing.com Mon Jan 13 08:23:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35DED1AE115 for ; Mon, 13 Jan 2014 08:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jj4Yyo1n6iLg for ; Mon, 13 Jan 2014 08:23:11 -0800 (PST) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id E9A761ADFDD for ; Mon, 13 Jan 2014 08:23:10 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s0DGN0UG010430; Mon, 13 Jan 2014 08:23:00 -0800 Received: from XCH-PHX-411.sw.nos.boeing.com (xch-phx-411.sw.nos.boeing.com [10.57.37.42]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s0DGMseU009878 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 13 Jan 2014 08:22:54 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.203]) by XCH-PHX-411.sw.nos.boeing.com ([169.254.11.54]) with mapi id 14.03.0158.001; Mon, 13 Jan 2014 08:22:54 -0800 From: "Templin, Fred L" To: Alexandru Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] link types for both RA and DHCP 'was: control and security of DHCP) Thread-Index: AQHPDrbsGksE3iLXw02DzecWSXac+ZqC2aKg Date: Mon, 13 Jan 2014 16:22:53 +0000 Message-ID: <2134F8430051B64F815C691A62D98318198549@XCH-BLV-504.nw.nos.boeing.com> References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D0180D.6030505@foobar.org> <2134F8430051B64F815C691A62D98318196839@XCH-BLV-504.nw.nos.boeing.com> <52D11B22.2070603@gmail.com> In-Reply-To: <52D11B22.2070603@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Subject: Re: [v6ops] link types for both RA and DHCP 'was: control and security of DHCP) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 16:23:13 -0000 Alex, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petres= cu > Sent: Saturday, January 11, 2014 2:21 AM > To: v6ops@ietf.org > Subject: Re: [v6ops] link types for both RA and DHCP 'was: control and se= curity of DHCP) >=20 > Le 10/01/2014 18:13, Templin, Fred L a =E9crit : > > Hi, I am just beginning to get the flavor for this discussion but > > what I am finding lacking is a consideration for the _different link > > types_ for which DHCPv6 vs RS/RA would apply. For example, AERO > > links are link-local only and there is actually very little useful > > information that could be gotten from an RS/RA exchange that could > > not just as easily be gotten from NS/NA. There, DHCPv6-PD may be all > > that is needed. > > > > Similarly, on managed network links DHCPv6 gives a central > > administrative control point for coordinating all of the managed > > links. > > > > So, what are the link types where we would expect to see RS/RA? > > Unmanaged edge links where visiting nodes come and go at random > > times? Others? >=20 > Fred, >=20 > The use of DHCP and ND would apply supposedly to the as many links as > possible. >=20 > The links I am concerned with are: cellular 1G, 2G, 3G, 4G and in the > future 5G, 869MHZ 'Alarm' IoT/M2M networks, 5.9GHz 802.11p, WiFi, wired > Ethernet, Fiber to the RSU, satellite, and more. >=20 > The additional links I have heard about here are: wired Ethernet in > Enterprise, virtual links between virtual machines ('virtual' by name > but transmitting real packets), and more. >=20 > Yes, some of these links would be termed unmanaged links where visiting > nodes come and go at random times. On some of them it would be better > to just use RA (e.g. WiFi handovers on IPv6 hotspots), on others just > DHCP (e.g. on constrained links of machine-class devices), and yet on > others both ND and DHCP (e.g. some visitor networks in Enterprise). >=20 > Sorry if this reads too generic, but I couldnt synthesize it better than > that. I think we are seeing it the same way. Thanks for confirming. Fred fred.l.templin@boeing.com > Alex >=20 > > > > Thanks - Fred fred.l.templin@boeing.com > > _______________________________________________ v6ops mailing list > > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > > > >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Mon Jan 13 08:25:23 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00AF1AE17E for ; Mon, 13 Jan 2014 08:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkKGdDER9O1c for ; Mon, 13 Jan 2014 08:25:21 -0800 (PST) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1571ADFDD for ; Mon, 13 Jan 2014 08:25:21 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s0DGPAI1029707; Mon, 13 Jan 2014 10:25:10 -0600 Received: from XCH-PHX-313.sw.nos.boeing.com (xch-phx-313.sw.nos.boeing.com [130.247.25.175]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s0DGP5Tn029621 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 13 Jan 2014 10:25:06 -0600 Received: from XCH-BLV-108.nw.nos.boeing.com (130.247.25.137) by XCH-PHX-313.sw.nos.boeing.com (130.247.25.175) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Jan 2014 08:25:05 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.203]) by XCH-BLV-108.nw.nos.boeing.com ([169.254.13.207]) with mapi id 14.03.0158.001; Mon, 13 Jan 2014 08:25:05 -0800 From: "Templin, Fred L" To: Mark ZZZ Smith , Alexandru Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet) Thread-Index: AQHPDrg6xP36KFapgEy8h/U9IKX/EJqAvheAgAIaPfA= Date: Mon, 13 Jan 2014 16:25:04 +0000 Message-ID: <2134F8430051B64F815C691A62D98318198577@XCH-BLV-504.nw.nos.boeing.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <6A64F619-4A0E-423A-A5E7-4C3234B461AE@nominum.com> <1389261993.72423.YahooMailNeo@web161906.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D98318193C5C@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D98318193CD6@XCH-BLV-504.nw.nos.boeing.com> <597F58BD-DCEA-4C4E-B7AB-DCCB416B3CFD@ecs.soton.ac.uk> <2134F8430051B64F815C691A62D98318193D30@XCH-BLV-504.nw.nos.boei! ng.com> <52CFBAB4.4040105@gmail.com> <2134F8430051B64F815C691A62D9831819663D@XCH-BLV-504.nw.nos.boeing! .com> <52D01D53.60107@gmail.com> <2134F8430051B64F815C691A62D9831819676E@XCH-BLV-504.nw.nos.boeing.com> <52D1! 1D67.1080106@gmail.com> <1389485433.43458.YahooMailNeo@web161903.mail.bf1.yahoo.com> In-Reply-To: <1389485433.43458.YahooMailNeo@web161903.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Subject: Re: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 16:25:23 -0000 Hi Mark, > -----Original Message----- > From: Mark ZZZ Smith [mailto:markzzzsmith@yahoo.com.au] > Sent: Saturday, January 11, 2014 4:11 PM > To: Alexandru Petrescu; Templin, Fred L; v6ops@ietf.org > Subject: Re: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as th= ey didn't IPv4, IPX, XNS, or > DECNet) >=20 >=20 >=20 >=20 >=20 > ----- Original Message ----- > > From: Alexandru Petrescu > > To: "Templin, Fred L" ; "v6ops@ietf.org" > > Cc: > > Sent: Saturday, 11 January 2014 9:31 PM > > Subject: Re: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as = they didn't IPv4, IPX, XNS, > or DECNet) > > > > Fred, > > > > Thanks for the message. > > > > Le 10/01/2014 17:37, Templin, Fred L a =E9crit : > >> Hi Alex, > >> >=20 > >=20 > > > > Given that, one wants to make it first IPv4 (IPv4 innovation is still > > needed in some protcols), and plan for as little effort as possible to > > deploy to IPv6.=A0 I.e. make them as much as possible look the same.=A0= If > > not, there is additional software effort, additional money to look for, > > additional time to add to end of project. > > >=20 >=20 > So let's imagine IPv6 was just IPv4 with bigger addresses, nothing else c= hanged, which is what I think > you're saying some people think it should have been. How would deploying = IPv4 with bigger addresses, > in addition to IPv4 with small addresses, save or make an enterprise mone= y today or in the near > future? >=20 > To pick a hypothetical example, imagine a golf club manufacturer. How wou= ld deploying IPv6 (of either > IPv4 + bigger addresses, or what we have today) decrease the cost of manu= facturing golf clubs, or > increase the sales of golf clubs? I can't think of how IPv6 would decreas= e their manufacturing costs, > and I don't think a "We've got an IPv6 network" sticker on the box will i= ncrease golf club sales > significantly (they might sell a extra few hundred to network engineers, = but that would be it). >=20 > In the views of some, if IPv6 had just been IPv4 with bigger addresses it= might slightly improve the > business case to deploy it, because it would have been less to learn, and= therefore theoretically less > cost to operate. Lower costs are great, but less costs don't matter if yo= u don't need what the > technology provides. >=20 > I used the following in another off-list email about this topic, I think = it is worth posting here: >=20 > "I once read that when you go to the hardware store to buy a drill, what = you're really buying is a > hole. The drill is the means, the hole is the end. >=20 > No matter how fancy the drill is, there will be some people who don't nee= d a hole, and therefore will > never buy a drill.=A0That's not a statement of the success or failure of = the drill to make holes, and > nor will adding further features and enhancements to the drill increase t= he demand for holes. >=20 > So IPv6 is the means, and an IPv6-only application, or an IPv6 applicatio= n that works much better than > an IPv4 one, is the end. It is only when enterprises (and others) want th= e IPv6 end will they then be > prepared to deploy the IPv6 means." >=20 >=20 >=20 > If people want to stimulate IPv6 adoption in enterprises, then it would s= eem to me that the focus > needs to be on developing or demonstrating the value of either moving app= lications to using IPv6 > instead of IPv4, or creating applications that cannot or cannot easily be= operated over IPv4. While I > don't know if it is used much, one example of such an application is Appl= e's Back to My Mac service, > described in RFC6281. There are "killer apps" for IPv6 and they are here today. One "app" is mobility management of mobile networks. A second is numbering of large scale virtual networks that may at some point need to connect up to the physical enterprise network. Nothing in existing enterprise networks needs to change to accommodate this, but future growth in mobile and virtual nodes will require IPv6. Thanks - Fred fred.l.templin@boeing.com > Regards, > Mark. From Fred.L.Templin@boeing.com Mon Jan 13 13:21:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C621AE1C0; Mon, 13 Jan 2014 13:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFJE7RiJJtom; Mon, 13 Jan 2014 13:21:06 -0800 (PST) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 858111AE196; Mon, 13 Jan 2014 13:21:06 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s0DLKt0I019516; Mon, 13 Jan 2014 15:20:55 -0600 Received: from XCH-PHX-209.sw.nos.boeing.com (xch-phx-209.sw.nos.boeing.com [130.247.25.29]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s0DLKPrl018646 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 13 Jan 2014 15:20:48 -0600 Received: from XCH-BLV-308.nw.nos.boeing.com (2002:82f7:19dc::82f7:19dc) by XCH-PHX-209.sw.nos.boeing.com (2002:82f7:191d::82f7:191d) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Jan 2014 13:20:35 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.203]) by XCH-BLV-308.nw.nos.boeing.com ([169.254.8.220]) with mapi id 14.03.0158.001; Mon, 13 Jan 2014 13:20:35 -0800 From: "Templin, Fred L" To: "v6ops@ietf.org" , "ipv6@ietf.org" Thread-Topic: I-D Action: draft-templin-aerolink-02.txt Thread-Index: AQHPEKQ4UlaOJp9uoECc6bip3DA7E5qDJ5yQ Date: Mon, 13 Jan 2014 21:20:34 +0000 Message-ID: <2134F8430051B64F815C691A62D98318198AFF@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Subject: [v6ops] FW: I-D Action: draft-templin-aerolink-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 21:21:08 -0000 Hi, Here is an update to AERO that makes some significant changes based on recent list discussions. Most importantly, it deprecates the use of RS/RA on AERO links (now, only NS/NA and Redirect are used). This really is close to a finished product now. This is how IPv6 can be deployed in enterprise network without having to cause upheaval in day-to-day operations. Comments? Fred fred.l.templin@boeing.com -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Monday, January 13, 2014 1:13 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-templin-aerolink-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Transmission of IPv6 Packets over AERO Links Author : Fred L. Templin Filename : draft-templin-aerolink-02.txt Pages : 24 Date : 2014-01-13 Abstract: This document specifies the operation of IPv6 over tunnel virtual Non-Broadcast, Multiple Access (NBMA) links using Automatic Extended Route Optimization (AERO). Nodes attached to AERO links can exchange packets via trusted intermediate routers on the link that provide forwarding services to reach off-link destinations and/or redirection services to inform the node of an on-link neighbor that is closer to the final destination. Operation of the IPv6 Neighbor Discovery (ND) protocol over AERO links is based on an IPv6 link local address format known as the AERO address. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-templin-aerolink/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-templin-aerolink-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-templin-aerolink-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From Fred.L.Templin@boeing.com Mon Jan 13 14:43:07 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704541A1F4A for ; Mon, 13 Jan 2014 14:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBbtMVGvZqu2 for ; Mon, 13 Jan 2014 14:43:05 -0800 (PST) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA7C1A1F1B for ; Mon, 13 Jan 2014 14:43:05 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s0DMgsIL001010; Mon, 13 Jan 2014 14:42:54 -0800 Received: from XCH-PHX-511.sw.nos.boeing.com (xch-phx-511.sw.nos.boeing.com [10.57.37.28]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s0DMgkc3000925 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Mon, 13 Jan 2014 14:42:46 -0800 Received: from XCH-BLV-505.nw.nos.boeing.com (130.247.25.195) by XCH-PHX-511.sw.nos.boeing.com (10.57.37.28) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Jan 2014 14:42:46 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.203]) by XCH-BLV-505.nw.nos.boeing.com ([169.254.5.41]) with mapi id 14.03.0158.001; Mon, 13 Jan 2014 14:42:45 -0800 From: "Templin, Fred L" To: "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-incremental-ipv6-05.txt Thread-Index: AQHPD8tzbcMfkfj46kOaQyEoH+klm5qDQM3g Date: Mon, 13 Jan 2014 22:42:44 +0000 Message-ID: <2134F8430051B64F815C691A62D98318198D2F@XCH-BLV-504.nw.nos.boeing.com> References: <20140112192103.21333.46615.idtracker@ietfa.amsl.com> In-Reply-To: <20140112192103.21333.46615.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-incremental-ipv6-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 22:43:07 -0000 Authors, Please see the following for input to your document: http://www.ietf.org/mail-archive/web/v6ops/current/msg18488.html Please add a reference for AERO, and preferably a new section describing incremental deployment of IPv6 in enterprise networks using AERO. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of internet-drafts@= ietf.org > Sent: Sunday, January 12, 2014 11:21 AM > To: i-d-announce@ietf.org > Cc: v6ops@ietf.org > Subject: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-incremental-ipv6= -05.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the IPv6 Operations Working Group of the IE= TF. >=20 > Title : Enterprise IPv6 Deployment Guidelines > Authors : Kiran K. Chittimaneni > Tim Chown > Lee Howard > Victor Kuarsingh > Yanick Pouffary > Eric Vyncke > Filename : draft-ietf-v6ops-enterprise-incremental-ipv6-05.txt > Pages : 34 > Date : 2014-01-12 >=20 > Abstract: > Enterprise network administrators worldwide are in various stages of > preparing for or deploying IPv6 into their networks. The > administrators face different challenges than operators of Internet > access providers, and have reasons for different priorities. The > overall problem for many administrators will be to offer Internet- > facing services over IPv6, while continuing to support IPv4, and > while introducing IPv6 access within the enterprise IT network. The > overall transition will take most networks from an IPv4-only > environment to a dual stack network environment and eventually an > IPv6-only operating mode. This document helps provide a framework > for enterprise network architects or administrators who may be faced > with many of these challenges as they consider their IPv6 support > strategies. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-enterprise-incremental-= ipv6/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6-0= 5 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-enterprise-incrementa= l-ipv6-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From tjc@ecs.soton.ac.uk Mon Jan 13 16:13:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED5F1AC7F3 for ; Mon, 13 Jan 2014 16:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.759 X-Spam-Level: X-Spam-Status: No, score=-1.759 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDtqtQ7PqzIT for ; Mon, 13 Jan 2014 16:13:51 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 4523D1A8033 for ; Mon, 13 Jan 2014 16:13:50 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s0E0DYaB002147; Tue, 14 Jan 2014 00:13:34 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s0E0DYaB002147 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1389658414; bh=VwfYnjcC7oRwrqbwdz5rVDN1eSU=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=DQA2Pm7hiQRPgIfam1cw+7jMy+Bf7XzLjOwOsU6nx13JRVhxt38gMC3DSFddnXdEU 1zZa1KsFNGcbeXDEMinpO0qV3br6AzM1Sk6OMJyiNPZZ55I/p7t3137yd64CQUSUtM Ch7uP7zBwVfIQ3LOiFu4+D/FneOKhaK41nJRoFvI= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id q0D0DY0959631597lb ret-id none; Tue, 14 Jan 2014 00:13:34 +0000 Received: from [192.168.1.107] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s0E0DTju007523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Jan 2014 00:13:30 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Tim Chown In-Reply-To: <2134F8430051B64F815C691A62D98318198D2F@XCH-BLV-504.nw.nos.boeing.com> Date: Tue, 14 Jan 2014 00:13:29 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140112192103.21333.46615.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D98318198D2F@XCH-BLV-504.nw.nos.boeing.com> <1AB324DF-C922-4049-BB4D-77BFF50ACFDE@ecs.soton.ac.uk> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1827) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q0D0DY095963159700; tid=q0D0DY0959631597lb; client=relay,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s0E0DYaB002147 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-incremental-ipv6-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 00:13:54 -0000 Hi Fred, My concern with that is that we're tending towards methods and processes = that have been proven in the document. I'm not at all sure that AERO has had any widespread use in IPv6 = enterprise sites. What implementations/deployments have there been? Tim On 13 Jan 2014, at 22:42, Templin, Fred L = wrote: > Authors, >=20 > Please see the following for input to your document: >=20 > http://www.ietf.org/mail-archive/web/v6ops/current/msg18488.html >=20 > Please add a reference for AERO, and preferably a new section > describing incremental deployment of IPv6 in enterprise networks > using AERO. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of = internet-drafts@ietf.org >> Sent: Sunday, January 12, 2014 11:21 AM >> To: i-d-announce@ietf.org >> Cc: v6ops@ietf.org >> Subject: [v6ops] I-D Action: = draft-ietf-v6ops-enterprise-incremental-ipv6-05.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the IPv6 Operations Working Group of the = IETF. >>=20 >> Title : Enterprise IPv6 Deployment Guidelines >> Authors : Kiran K. Chittimaneni >> Tim Chown >> Lee Howard >> Victor Kuarsingh >> Yanick Pouffary >> Eric Vyncke >> Filename : = draft-ietf-v6ops-enterprise-incremental-ipv6-05.txt >> Pages : 34 >> Date : 2014-01-12 >>=20 >> Abstract: >> Enterprise network administrators worldwide are in various stages = of >> preparing for or deploying IPv6 into their networks. The >> administrators face different challenges than operators of Internet >> access providers, and have reasons for different priorities. The >> overall problem for many administrators will be to offer Internet- >> facing services over IPv6, while continuing to support IPv4, and >> while introducing IPv6 access within the enterprise IT network. = The >> overall transition will take most networks from an IPv4-only >> environment to a dual stack network environment and eventually an >> IPv6-only operating mode. This document helps provide a framework >> for enterprise network architects or administrators who may be = faced >> with many of these challenges as they consider their IPv6 support >> strategies. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-ietf-v6ops-enterprise-incremental-i= pv6/ >>=20 >> There's also a htmlized version available at: >> = http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6-05= >>=20 >> A diff from the previous version is available at: >> = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-enterprise-incremental= -ipv6-05 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From v6ops@globis.net Mon Jan 13 23:30:42 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BD01AE1F2 for ; Mon, 13 Jan 2014 23:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4FWkxhNKiNb for ; Mon, 13 Jan 2014 23:30:42 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 379DC1AE053 for ; Mon, 13 Jan 2014 23:30:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 5E656871498; Tue, 14 Jan 2014 08:30:30 +0100 (CET) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2wy9OJdxhJ8; Tue, 14 Jan 2014 08:30:30 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 32A2F871497; Tue, 14 Jan 2014 08:30:30 +0100 (CET) Message-ID: <52D4E794.3070109@globis.net> Date: Tue, 14 Jan 2014 08:30:28 +0100 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Nick Hilliard References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D18F22.1070708@foobar.org> <1389490607.51957.YahooMailNeo@web161904.mail.bf1.yahoo.com> <52D2A8EF.2040901@foobar.org> In-Reply-To: <52D2A8EF.2040901@foobar.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 07:30:43 -0000 Nick Hilliard wrote: > On 12/01/2014 01:36, Mark ZZZ Smith wrote: >> 'Are Broadcast Multi-Access Subnetworks becoming "Considered Harmful"'? > > They're probably the worst possible way of handling multiple access > networks, with the exception of all the others. > > And if anyone mentions ATM, I'm totally claiming godwin. > > Nick > > Would the combination: IPv6/64 + L2 PVLAN + DHCPv6 setting the address + DHCPv6 setting default router + HSRPv6 + input ACLs, provide you a solution to your requirements in a multi-tenant environment? [Yes I know DHCPv6 setting default router does not yet exist in the world of IETF.] Why would that be better than IPv6/64 + L2 PVLAN + RA + RA Router preference (4941) + DHCPv6 setting the address ? If anything at all were possible, would your preferred combination for a bullet proof and predictable solution not be: prefix length >> 64 + PVLAN + DHCPv6 + DHCPv6 setting default router + HSRPv6 ? [Yes I know prefix length >> 64 is heresy in IETF] Then you'd have path equivalence and functional equivalence with IPv4 to ease operations and debugging. Especially when stuff starts flapping, I suspect it's going to be a right royal pain to debug otherwise. -- Regards, RayH From Fred.L.Templin@boeing.com Tue Jan 14 07:43:10 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58ED81AE0DA for ; Tue, 14 Jan 2014 07:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwfF8hhn5Jcz for ; Tue, 14 Jan 2014 07:43:08 -0800 (PST) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id E7CD81ADF7F for ; Tue, 14 Jan 2014 07:43:07 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s0EFgui7023576; Tue, 14 Jan 2014 09:42:56 -0600 Received: from XCH-PHX-310.sw.nos.boeing.com (xch-phx-310.sw.nos.boeing.com [130.247.25.169]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s0EFgpgY023550 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 14 Jan 2014 09:42:51 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.203]) by XCH-PHX-310.sw.nos.boeing.com ([169.254.10.30]) with mapi id 14.03.0158.001; Tue, 14 Jan 2014 07:42:50 -0800 From: "Templin, Fred L" To: Tim Chown Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-incremental-ipv6-05.txt Thread-Index: AQHPEL1zbcMfkfj46kOaQyEoH+klm5qEWg4w Date: Tue, 14 Jan 2014 15:42:49 +0000 Message-ID: <2134F8430051B64F815C691A62D9831819A9C8@XCH-BLV-504.nw.nos.boeing.com> References: <20140112192103.21333.46615.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D98318198D2F@XCH-BLV-504.nw.nos.boeing.com> <1AB324DF-C922-4049-BB4D-77BFF50ACFDE@ecs.soton.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-incremental-ipv6-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 15:43:10 -0000 Hi Tim, > -----Original Message----- > From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] > Sent: Monday, January 13, 2014 4:13 PM > To: Templin, Fred L > Cc: v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-incremental-= ipv6-05.txt >=20 > Hi Fred, >=20 > My concern with that is that we're tending towards methods and processes = that have been proven in the > document. >=20 > I'm not at all sure that AERO has had any widespread use in IPv6 enterpri= se sites. What > implementations/deployments have there been? AERO is a simple set of modifications to standard IPv6 ND. I have created an early implementation here: http://linkupnetworks.com/seal/sealv2-1.0.tgz but needs to be updated to more closely match the latest draft version. With AERO, enterprise IPv6 deployment can be accomplished by simply touching the end systems and by deploying a few servers - nothing else needs to change. So, for example, if a handset manufacturer wanted to supply an enterprise with IPv6-enabled product, they could add AERO to their handset code base and have the enterprise stand up a few servers (maybe something like a linux box). Thanks - Fred fred.l.templin@boeing.com=20 =20 > Tim >=20 > On 13 Jan 2014, at 22:42, Templin, Fred L wro= te: >=20 > > Authors, > > > > Please see the following for input to your document: > > > > http://www.ietf.org/mail-archive/web/v6ops/current/msg18488.html > > > > Please add a reference for AERO, and preferably a new section > > describing incremental deployment of IPv6 in enterprise networks > > using AERO. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> -----Original Message----- > >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of internet-draf= ts@ietf.org > >> Sent: Sunday, January 12, 2014 11:21 AM > >> To: i-d-announce@ietf.org > >> Cc: v6ops@ietf.org > >> Subject: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-incremental-i= pv6-05.txt > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. > >> This draft is a work item of the IPv6 Operations Working Group of the = IETF. > >> > >> Title : Enterprise IPv6 Deployment Guidelines > >> Authors : Kiran K. Chittimaneni > >> Tim Chown > >> Lee Howard > >> Victor Kuarsingh > >> Yanick Pouffary > >> Eric Vyncke > >> Filename : draft-ietf-v6ops-enterprise-incremental-ipv6-05.txt > >> Pages : 34 > >> Date : 2014-01-12 > >> > >> Abstract: > >> Enterprise network administrators worldwide are in various stages of > >> preparing for or deploying IPv6 into their networks. The > >> administrators face different challenges than operators of Internet > >> access providers, and have reasons for different priorities. The > >> overall problem for many administrators will be to offer Internet- > >> facing services over IPv6, while continuing to support IPv4, and > >> while introducing IPv6 access within the enterprise IT network. The > >> overall transition will take most networks from an IPv4-only > >> environment to a dual stack network environment and eventually an > >> IPv6-only operating mode. This document helps provide a framework > >> for enterprise network architects or administrators who may be faced > >> with many of these challenges as they consider their IPv6 support > >> strategies. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-enterprise-increment= al-ipv6/ > >> > >> There's also a htmlized version available at: > >> http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv= 6-05 > >> > >> A diff from the previous version is available at: > >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-enterprise-increme= ntal-ipv6-05 > >> > >> > >> Please note that it may take a couple of minutes from the time of subm= ission > >> until the htmlized version and diff are available at tools.ietf.org. > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops From tjc@ecs.soton.ac.uk Tue Jan 14 07:48:29 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8FA21ADF7F for ; Tue, 14 Jan 2014 07:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.759 X-Spam-Level: X-Spam-Status: No, score=-1.759 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmFqBwBN2hVC for ; Tue, 14 Jan 2014 07:48:27 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id AC9EE1AE0EF for ; Tue, 14 Jan 2014 07:48:26 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s0EFm9Pa025893; Tue, 14 Jan 2014 15:48:09 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s0EFm9Pa025893 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1389714489; bh=Fbw0Ek1UnbDOUp6Dxx7YvUZCGEY=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=3Ad6CjHXIKh/FgkvrOWTtv5TE7aSnHAfKNr9zztgpCe95R9D0X/HFYhyNACSxxhlj IfBGiq3ta4OUnIwSuPoioE+lxBtG7lsXdzh+dNprI7LKKkbrbIagc8mcuh8+9lY669 aybnq0g5J4Dzh4AnuyDVO3RTN025APEEn7IQRL44= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id q0DFm909596395512Z ret-id none; Tue, 14 Jan 2014 15:48:09 +0000 Received: from dhcp-160-57.wireless.soton.ac.uk (dhcp-160-57.wireless.soton.ac.uk [152.78.160.57]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s0EFm4OG022206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Jan 2014 15:48:04 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Tim Chown In-Reply-To: <2134F8430051B64F815C691A62D9831819A9C8@XCH-BLV-504.nw.nos.boeing.com> Date: Tue, 14 Jan 2014 15:48:03 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140112192103.21333.46615.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D98318198D2F@XCH-BLV-504.nw.nos.boeing.com> <1AB324DF-C922-4049-BB4D-77BFF50ACFDE@ecs.soton.ac.uk> <2134F8430051B64F815C691A62D9831819A9C8@XCH-BLV-504.nw.nos.boeing.com> <85A9F644-D11A-47D2-A3EB-70A43434824F@ecs.soton.ac.uk> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1510) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q0DFm9095963955100; tid=q0DFm909596395512Z; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s0EFm9Pa025893 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-incremental-ipv6-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 15:48:30 -0000 Hi, On 14 Jan 2014, at 15:42, "Templin, Fred L" = wrote: > Hi Tim, >=20 >> -----Original Message----- >> From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] >> Sent: Monday, January 13, 2014 4:13 PM >> To: Templin, Fred L >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] I-D Action: = draft-ietf-v6ops-enterprise-incremental-ipv6-05.txt >>=20 >> Hi Fred, >>=20 >> My concern with that is that we're tending towards methods and = processes that have been proven in the >> document. >>=20 >> I'm not at all sure that AERO has had any widespread use in IPv6 = enterprise sites. What >> implementations/deployments have there been? >=20 > AERO is a simple set of modifications to standard IPv6 ND. I have = created > an early implementation here: >=20 > http://linkupnetworks.com/seal/sealv2-1.0.tgz >=20 > but needs to be updated to more closely match the latest draft = version. OK, that's interesting, and I may take a look, but not sure it's at a = level where we'd add it to the document. Tim > With AERO, enterprise IPv6 deployment can be accomplished by simply > touching the end systems and by deploying a few servers - nothing else > needs to change. So, for example, if a handset manufacturer wanted to > supply an enterprise with IPv6-enabled product, they could add AERO > to their handset code base and have the enterprise stand up a few > servers (maybe something like a linux box). >=20 > Thanks - Fred > fred.l.templin@boeing.com=20 >=20 >> Tim >>=20 >> On 13 Jan 2014, at 22:42, Templin, Fred L = wrote: >>=20 >>> Authors, >>>=20 >>> Please see the following for input to your document: >>>=20 >>> http://www.ietf.org/mail-archive/web/v6ops/current/msg18488.html >>>=20 >>> Please add a reference for AERO, and preferably a new section >>> describing incremental deployment of IPv6 in enterprise networks >>> using AERO. >>>=20 >>> Thanks - Fred >>> fred.l.templin@boeing.com >>>=20 >>>> -----Original Message----- >>>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of = internet-drafts@ietf.org >>>> Sent: Sunday, January 12, 2014 11:21 AM >>>> To: i-d-announce@ietf.org >>>> Cc: v6ops@ietf.org >>>> Subject: [v6ops] I-D Action: = draft-ietf-v6ops-enterprise-incremental-ipv6-05.txt >>>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>> This draft is a work item of the IPv6 Operations Working Group of = the IETF. >>>>=20 >>>> Title : Enterprise IPv6 Deployment Guidelines >>>> Authors : Kiran K. Chittimaneni >>>> Tim Chown >>>> Lee Howard >>>> Victor Kuarsingh >>>> Yanick Pouffary >>>> Eric Vyncke >>>> Filename : = draft-ietf-v6ops-enterprise-incremental-ipv6-05.txt >>>> Pages : 34 >>>> Date : 2014-01-12 >>>>=20 >>>> Abstract: >>>> Enterprise network administrators worldwide are in various stages = of >>>> preparing for or deploying IPv6 into their networks. The >>>> administrators face different challenges than operators of = Internet >>>> access providers, and have reasons for different priorities. The >>>> overall problem for many administrators will be to offer Internet- >>>> facing services over IPv6, while continuing to support IPv4, and >>>> while introducing IPv6 access within the enterprise IT network. = The >>>> overall transition will take most networks from an IPv4-only >>>> environment to a dual stack network environment and eventually an >>>> IPv6-only operating mode. This document helps provide a framework >>>> for enterprise network architects or administrators who may be = faced >>>> with many of these challenges as they consider their IPv6 support >>>> strategies. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> = https://datatracker.ietf.org/doc/draft-ietf-v6ops-enterprise-incremental-i= pv6/ >>>>=20 >>>> There's also a htmlized version available at: >>>> = http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6-05= >>>>=20 >>>> A diff from the previous version is available at: >>>> = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-enterprise-incremental= -ipv6-05 >>>>=20 >>>>=20 >>>> Please note that it may take a couple of minutes from the time of = submission >>>> until the htmlized version and diff are available at = tools.ietf.org. >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >=20 From Fred.L.Templin@boeing.com Tue Jan 14 07:57:15 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6159B1AE0DC for ; Tue, 14 Jan 2014 07:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOLM6AFlUsVY for ; Tue, 14 Jan 2014 07:57:13 -0800 (PST) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id B39141ADFCD for ; Tue, 14 Jan 2014 07:57:13 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s0EFv2vp015609; Tue, 14 Jan 2014 09:57:02 -0600 Received: from XCH-PHX-411.sw.nos.boeing.com (xch-phx-411.sw.nos.boeing.com [10.57.37.42]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s0EFur1P015403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 14 Jan 2014 09:56:53 -0600 Received: from XCH-BLV-308.nw.nos.boeing.com (130.247.25.220) by XCH-PHX-411.sw.nos.boeing.com (10.57.37.42) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 14 Jan 2014 07:56:52 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.203]) by XCH-BLV-308.nw.nos.boeing.com ([169.254.8.220]) with mapi id 14.03.0158.001; Tue, 14 Jan 2014 07:56:52 -0800 From: "Templin, Fred L" To: Tim Chown Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-incremental-ipv6-05.txt Thread-Index: AQHPEUAOzxRkuhMCp06AK1XZT8XzSJqEXh+g Date: Tue, 14 Jan 2014 15:56:51 +0000 Message-ID: <2134F8430051B64F815C691A62D9831819AA8C@XCH-BLV-504.nw.nos.boeing.com> References: <20140112192103.21333.46615.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D98318198D2F@XCH-BLV-504.nw.nos.boeing.com> <1AB324DF-C922-4049-BB4D-77BFF50ACFDE@ecs.soton.ac.uk> <2134F8430051B64F815C691A62D9831819A9C8@XCH-BLV-504.nw.nos.boeing.com> <85A9F644-D11A-47D2-A3EB-70A43434824F@ecs.soton.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-incremental-ipv6-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 15:57:15 -0000 Hi Tim, > -----Original Message----- > From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] > Sent: Tuesday, January 14, 2014 7:48 AM > To: Templin, Fred L > Cc: v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-incremental-= ipv6-05.txt >=20 > Hi, >=20 > On 14 Jan 2014, at 15:42, "Templin, Fred L" w= rote: >=20 > > Hi Tim, > > > >> -----Original Message----- > >> From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] > >> Sent: Monday, January 13, 2014 4:13 PM > >> To: Templin, Fred L > >> Cc: v6ops@ietf.org > >> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-increment= al-ipv6-05.txt > >> > >> Hi Fred, > >> > >> My concern with that is that we're tending towards methods and process= es that have been proven in > the > >> document. > >> > >> I'm not at all sure that AERO has had any widespread use in IPv6 enter= prise sites. What > >> implementations/deployments have there been? > > > > AERO is a simple set of modifications to standard IPv6 ND. I have creat= ed > > an early implementation here: > > > > http://linkupnetworks.com/seal/sealv2-1.0.tgz > > > > but needs to be updated to more closely match the latest draft version. >=20 > OK, that's interesting, and I may take a look, but not sure it's at a lev= el where we'd add it to the > document. OK, but there are obvious interactions and overlaps. For example, if an enterprise decides to just use AERO it may not need most of the guidance in enterprise-incremental. Or, if the enterprise follows the enterprise-incremental guidance and deploys IPv6 in the network it can still use AERO for its mobility management services. One thing to be sure of is that AERO is not a transition tool - it is intended as a long-term service. Thanks - Fred fred.l.templin@boeing.com > Tim >=20 > > With AERO, enterprise IPv6 deployment can be accomplished by simply > > touching the end systems and by deploying a few servers - nothing else > > needs to change. So, for example, if a handset manufacturer wanted to > > supply an enterprise with IPv6-enabled product, they could add AERO > > to their handset code base and have the enterprise stand up a few > > servers (maybe something like a linux box). > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> Tim > >> > >> On 13 Jan 2014, at 22:42, Templin, Fred L = wrote: > >> > >>> Authors, > >>> > >>> Please see the following for input to your document: > >>> > >>> http://www.ietf.org/mail-archive/web/v6ops/current/msg18488.html > >>> > >>> Please add a reference for AERO, and preferably a new section > >>> describing incremental deployment of IPv6 in enterprise networks > >>> using AERO. > >>> > >>> Thanks - Fred > >>> fred.l.templin@boeing.com > >>> > >>>> -----Original Message----- > >>>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of internet-dr= afts@ietf.org > >>>> Sent: Sunday, January 12, 2014 11:21 AM > >>>> To: i-d-announce@ietf.org > >>>> Cc: v6ops@ietf.org > >>>> Subject: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-incremental= -ipv6-05.txt > >>>> > >>>> > >>>> A New Internet-Draft is available from the on-line Internet-Drafts d= irectories. > >>>> This draft is a work item of the IPv6 Operations Working Group of th= e IETF. > >>>> > >>>> Title : Enterprise IPv6 Deployment Guidelines > >>>> Authors : Kiran K. Chittimaneni > >>>> Tim Chown > >>>> Lee Howard > >>>> Victor Kuarsingh > >>>> Yanick Pouffary > >>>> Eric Vyncke > >>>> Filename : draft-ietf-v6ops-enterprise-incremental-ipv6-05.t= xt > >>>> Pages : 34 > >>>> Date : 2014-01-12 > >>>> > >>>> Abstract: > >>>> Enterprise network administrators worldwide are in various stages o= f > >>>> preparing for or deploying IPv6 into their networks. The > >>>> administrators face different challenges than operators of Internet > >>>> access providers, and have reasons for different priorities. The > >>>> overall problem for many administrators will be to offer Internet- > >>>> facing services over IPv6, while continuing to support IPv4, and > >>>> while introducing IPv6 access within the enterprise IT network. Th= e > >>>> overall transition will take most networks from an IPv4-only > >>>> environment to a dual stack network environment and eventually an > >>>> IPv6-only operating mode. This document helps provide a framework > >>>> for enterprise network architects or administrators who may be face= d > >>>> with many of these challenges as they consider their IPv6 support > >>>> strategies. > >>>> > >>>> > >>>> The IETF datatracker status page for this draft is: > >>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-enterprise-increme= ntal-ipv6/ > >>>> > >>>> There's also a htmlized version available at: > >>>> http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-i= pv6-05 > >>>> > >>>> A diff from the previous version is available at: > >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-enterprise-incre= mental-ipv6-05 > >>>> > >>>> > >>>> Please note that it may take a couple of minutes from the time of su= bmission > >>>> until the htmlized version and diff are available at tools.ietf.org. > >>>> > >>>> Internet-Drafts are also available by anonymous FTP at: > >>>> ftp://ftp.ietf.org/internet-drafts/ > >>>> > >>>> _______________________________________________ > >>>> v6ops mailing list > >>>> v6ops@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/v6ops > >>> _______________________________________________ > >>> v6ops mailing list > >>> v6ops@ietf.org > >>> https://www.ietf.org/mailman/listinfo/v6ops > > From nick@foobar.org Tue Jan 14 09:21:43 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7501AE139 for ; Tue, 14 Jan 2014 09:21:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOFQ5aa17eSt for ; Tue, 14 Jan 2014 09:21:41 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 173C11AE0DC for ; Tue, 14 Jan 2014 09:21:40 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::126]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id s0EHLORW040393 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 14 Jan 2014 17:21:25 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::126] claimed to be cupcake.foobar.org Message-ID: <52D57214.1070505@foobar.org> Date: Tue, 14 Jan 2014 17:21:24 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ray Hunter References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D18F22.1070708@foobar.org> <1389490607.51957.YahooMailNeo@web161904.mail.bf1.yahoo.com> <52D2A8EF.2040901@foobar.org> <52D4E794.3070109@globis.net> In-Reply-To: <52D4E794.3070109@globis.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 17:21:44 -0000 On 14/01/2014 07:30, Ray Hunter wrote: > Would the combination: IPv6/64 + L2 PVLAN + DHCPv6 setting the address + private vlans are troublesome, to say the least. In a virtualised environment, you need multi-switch support for specific types of pvlans. This places vendor restrictions on the types of kit you need to deploy. Nick From Ted.Lemon@nominum.com Tue Jan 14 09:35:55 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EED71AE1B8 for ; Tue, 14 Jan 2014 09:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6YGvJOB_kYP for ; Tue, 14 Jan 2014 09:35:53 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAB31AE153 for ; Tue, 14 Jan 2014 09:35:53 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUtV1blv0iqVnoOek2DLJHznf70FmckTg@postini.com; Tue, 14 Jan 2014 09:35:42 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D38251B82C9 for ; Tue, 14 Jan 2014 09:35:41 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 9EEF5190052; Tue, 14 Jan 2014 09:35:41 -0800 (PST) Received: from divertimento.ddns.nominum.com (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 14 Jan 2014 09:35:41 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <52D57214.1070505@foobar.org> Date: Tue, 14 Jan 2014 09:35:38 -0800 Content-Transfer-Encoding: quoted-printable Message-ID: <4A3E0E3F-992A-44F6-9878-388233BA59ED@nominum.com> References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D18F22.1070708@foobar.org> <1389490607.51957.YahooMailNeo@web161904.mail.bf1.yahoo.com> <52D2A8EF.2040901@foobar.org> <52D4E794.3070109@globis.net> <52D57214.1070505@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 17:35:55 -0000 On Jan 14, 2014, at 9:21 AM, Nick Hilliard wrote: > private vlans are troublesome, to say the least. In a virtualised > environment, you need multi-switch support for specific types of = pvlans. > This places vendor restrictions on the types of kit you need to = deploy. VLAN tagging is an IEEE standard. It works on my cheap D-link switch at = home, and I am using it there to isolate VLANs. TRILL is another = standard that supports VLAN tagging in precisely the sort of virtualized = environment you are talking about, and that several vendors claim to = support. I'm pretty sure there's another IEEE standard that does = something similar to what TRILL does, but I can't remember the number = off the top of my head. So is the missing piece that leads you to say = what you are saying above? Is it that switches supporting TRILL and/or = the IEEE mechanism are too expensive? From nick@foobar.org Tue Jan 14 09:45:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2F11AE131 for ; Tue, 14 Jan 2014 09:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zh16zdEEzTe for ; Tue, 14 Jan 2014 09:45:51 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id AC4301AE117 for ; Tue, 14 Jan 2014 09:45:50 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::126]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id s0EHjYeY040584 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 14 Jan 2014 17:45:35 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::126] claimed to be cupcake.foobar.org Message-ID: <52D577BF.1020502@foobar.org> Date: Tue, 14 Jan 2014 17:45:35 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ted Lemon References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D18F22.1070708@foobar.org> <1389490607.51957.YahooMailNeo@web161904.mail.bf1.yahoo.com> <52D2A8EF.2040901@foobar.org> <52D4E794.3070109@globis.net> <52D57214.1070505@foobar.org> <4A3E0E3F-992A-44F6-9878-388233BA59ED@nominum.com> In-Reply-To: <4A3E0E3F-992A-44F6-9878-388233BA59ED@nominum.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 17:45:52 -0000 On 14/01/2014 17:35, Ted Lemon wrote: > VLAN tagging is an IEEE standard. vlan tagging is something else. Private vlans are vlans with vendor specific internal segmentation so that some hosts cannot talk to other hosts, even though they nominally inhabit the same vlan. This is not standardised in any meaningful way that I'm aware of and each vendor takes their own approach per type of kit that they sell. They have interesting features which make them appropriate for some but not all shared tenancy models. Cisco documented some of their approach in rfc5517. Nick From v6ops@globis.net Tue Jan 14 10:11:36 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412981AE167 for ; Tue, 14 Jan 2014 10:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbiGJpTvX5-9 for ; Tue, 14 Jan 2014 10:11:35 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id ECD061AE176 for ; Tue, 14 Jan 2014 10:11:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 0DFF687149A; Tue, 14 Jan 2014 19:11:19 +0100 (CET) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NUcMxZ+F9En; Tue, 14 Jan 2014 19:11:18 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id E0AF3871499; Tue, 14 Jan 2014 19:11:18 +0100 (CET) Message-ID: <52D57DC5.9080603@globis.net> Date: Tue, 14 Jan 2014 19:11:17 +0100 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Nick Hilliard References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D18F22.1070708@foobar.org> <1389490607.51957.YahooMailNeo@web161904.mail.bf1.yahoo.com> <52D2A8EF.2040901@foobar.org> <52D4E794.3070109@globis.net> <52D57214.1070505@foobar.org> In-Reply-To: <52D57214.1070505@foobar.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 18:11:36 -0000 > Nick Hilliard > 14 January 2014 18:21 > > private vlans are troublesome, to say the least. In a virtualised > environment, you need multi-switch support for specific types of pvlans. > This places vendor restrictions on the types of kit you need to deploy. > > Nick > ------------------------------------------------------------------------ Yes. I've read posts from a number of DC operators who have expressly chosen for PVLANs compared to deploying dedicated L3 ports per server/ customer in multi-tenant environments, driven by a desire to save on very scarce public IPv4 addresses. That of course will likely bring problems migrating to IPv6 in the future e.g. DAD is probably not going to be able to detect duplicate addresses via multicast. Hence my suggestion of prefix length >> 64 + PVLAN + DHCPv6 + DHCPv6 setting default router + HSRPv6/VRRPv3 to exactly mirror the IPv4 setup. It would also mean that any failovers are likely to be very similar for both IPv4 and IPv6 paths, and that HSRPv6//VRRPv3 generally has more features (track/ preempt/ MD5 authentication) which RA clearly doesn't have (yet), which I see as clear operational advantages. My opinion is that combination is a pretty valid use case for transitioning a multi-tenant IPv4 environment to IPv6 using dual stack, and which requires the additional functionality you want. Otherwise people running IPv4 PVLANs are going to get painted into a corner. So what security are you suggesting to deploy to ensure that your set up remains sufficiently isolated between customers, even though they share a L2 LAN? I'm not saying necessarily that RA should be the only game in town, but it is there today. And we all know how hard it is to prevent attacks by on-link attackers (not just RA). -- Regards, RayH From owen@delong.com Tue Jan 14 10:18:10 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DC31ADF8F for ; Tue, 14 Jan 2014 10:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.529 X-Spam-Level: X-Spam-Status: No, score=-1.529 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZbuFA2hHxmg for ; Tue, 14 Jan 2014 10:18:09 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id D63D61ADEB4 for ; Tue, 14 Jan 2014 10:18:08 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s0EIH8tq031563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Jan 2014 10:17:08 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s0EIH8tq031563 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1389723428; bh=2VQ650Gvu6hoQZDOaV64vmX9py4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=rhwnhDEUBXdr334CgZze2p2U/hTgSvieYq7YumQStHgGWgEd4mF+HOWF77T5cO8m5 Kmx+4WgSEeFR90D0qGfWBbyRfXh8NFBdmUwGhXZzO7oJB9BGWYQcBQK9KR0b6KIwc+ FPxOxrwoilfFhl3R9nuBtvdioL3zuNm4a7988cLE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Owen DeLong In-Reply-To: <52D57DC5.9080603@globis.net> Date: Tue, 14 Jan 2014 10:17:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <807E80E4-40CA-49CD-AC7D-F512D5B51B23@delong.com> References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D18F22.1070708@foobar.org> <1389490607.51957.YahooMailNeo@web161904.mail.bf1.yahoo.com> <52D2A8EF.2040901@foobar.org> <52D4E794.3070109@globis.net> <52D57214.1070505@foobar.org> <52D57DC5.9080603@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 14 Jan 2014 10:17:08 -0800 (PST) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 18:18:10 -0000 On Jan 14, 2014, at 10:11 , Ray Hunter wrote: >> Nick Hilliard >> 14 January 2014 18:21 >>=20 >> private vlans are troublesome, to say the least. In a virtualised >> environment, you need multi-switch support for specific types of = pvlans. >> This places vendor restrictions on the types of kit you need to = deploy. >>=20 >> Nick >> = ------------------------------------------------------------------------ > Yes. >=20 > I've read posts from a number of DC operators who have expressly = chosen for PVLANs compared to deploying dedicated L3 ports per server/ = customer in multi-tenant environments, driven by a desire to save on = very scarce public IPv4 addresses. Which might make sense when the customers are on separate hardware. When the customers are separate virtuals on the same hardware, PVLANs = become a bit less useful, though at that point, dedicated L3 ports in = the virtual switch on the host become much more feasible, though you = still have the network addressing cost issue if you're tied to IPv4. > That of course will likely bring problems migrating to IPv6 in the = future e.g. DAD is probably not going to be able to detect duplicate = addresses via multicast. Depends on how the PVLANs treat link-scoped IPv6 multicast. > Hence my suggestion of prefix length >> 64 + PVLAN + DHCPv6 + DHCPv6 = setting default router + HSRPv6/VRRPv3 to exactly mirror the IPv4 setup. Not sure how that really helps. Why is a longer prefix length allegedly = useful in this context? Owen From nick@foobar.org Tue Jan 14 10:38:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF241AE249 for ; Tue, 14 Jan 2014 10:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFt7BAPhRgfe for ; Tue, 14 Jan 2014 10:38:27 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 333991AE23F for ; Tue, 14 Jan 2014 10:38:26 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::126]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id s0EIcB67041011 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 14 Jan 2014 18:38:11 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::126] claimed to be cupcake.foobar.org Message-ID: <52D58413.3050506@foobar.org> Date: Tue, 14 Jan 2014 18:38:11 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ray Hunter References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D18F22.1070708@foobar.org> <1389490607.51957.YahooMailNeo@web161904.mail.bf1.yahoo.com> <52D2A8EF.2040901@foobar.org> <52D4E794.3070109@globis.net> <52D57214.1070505@foobar.org> <52D57DC5.9080603@globis.net> In-Reply-To: <52D57DC5.9080603@globis.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 18:38:30 -0000 On 14/01/2014 18:11, Ray Hunter wrote: > So what security are you suggesting to deploy to ensure that your set up > remains sufficiently isolated between customers, even though they share a > L2 LAN? Right now? I have nothing. I can't deploy ipv6 without holes large enough to drive trucks through. Nick From lorenzo@google.com Tue Jan 14 10:52:35 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183561ADF90 for ; Tue, 14 Jan 2014 10:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoqZVT9eB0sE for ; Tue, 14 Jan 2014 10:52:33 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A53B61ADF8F for ; Tue, 14 Jan 2014 10:52:33 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id e14so747781iej.17 for ; Tue, 14 Jan 2014 10:52:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5eHOoCIsoZ2P6S/LXq7C+Id0vBk+FaY+B9iXVTiZgV0=; b=Ge3/GraO3weYYRVyw8pJvjMDSEkhk/RRzzKfsBMbVl3TFBzwVxhJSRsltUTGYsjcfV 1adwOetacRCPCNylshYugkvwxeSjyYOJMbYEo2O+3L+WaaFOx0xOMcXFOlTKlu2I8Zja p/Iuyl34JHldPUL4593SHbnRbelXO4dkU3xzICHsPfwQLJ9iWJvzR8Se501s8wABLCoE jBiUIzsG3A1tgF5Ztq113Lj7doqKuOyUfHglM2JReJ/oH0LPAZpcALHC1kLUepkTri4Z uTz73rijIbFSV30+XH9tjDvtS/yzzAeWsii0gtaRFsrcatKUWnAmlQICF+CNMjU0hJ8X DwsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5eHOoCIsoZ2P6S/LXq7C+Id0vBk+FaY+B9iXVTiZgV0=; b=kZSJKtEVPaJBPgC6N5p2ie0mD4tJ1vJNGDaEwieJWKBdEkWbs4RtAptDHZBN4694Vw jkmDitTfgj8wBEpOk1ylDR6LGWeuqo3rGDAapMlthKICax3/fnzURRtX6NJaEZZaWP2N vPYHTta65Y1PM+FkluUL2mCQFM2hNSgQPeQqhZlbIel/wdkFyVVW+AaI9QjIe1lx9En4 4mTU0aCoymanfyIkAFcjSZLbC6fTIQ3GBTxeMLhuBkiJe9pJQJJwFkdIBmW1PS/6sCa5 JkJDHkKcMhmiuRBiwQ9IC8CmWXemOIVgeKJSBGMVcT67T2oEtpDcwIJn7d7XWIOGDYCa nHPw== X-Gm-Message-State: ALoCoQnpuZ29E12vpQNpe3jrQq5fsx7HkJPMSZb/ROH+7KxRj1XAIJSgPjyEAXeWLID3XAplwwOQFgEnDP9523Lt/lncWySHDw7NLfd+aLk+H8PF1bXnSEDo4nyKjjf2xbedvsJnGpxzUoL1WRgot3NUavw9xW4NvaYWC4t//ZIhfAD9PeS3rGXcLqXWmRfvXaejTM3B1Khg X-Received: by 10.50.61.101 with SMTP id o5mr4614238igr.31.1389725541974; Tue, 14 Jan 2014 10:52:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Tue, 14 Jan 2014 10:52:01 -0800 (PST) In-Reply-To: <52D58413.3050506@foobar.org> References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D18F22.1070708@foobar.org> <1389490607.51957.YahooMailNeo@web161904.mail.bf1.yahoo.com> <52D2A8EF.2040901@foobar.org> <52D4E794.3070109@globis.net> <52D57214.1070505@foobar.org> <52D57DC5.9080603@globis.net> <52D58413.3050506@foobar.org> From: Lorenzo Colitti Date: Wed, 15 Jan 2014 03:52:01 +0900 Message-ID: To: Nick Hilliard Content-Type: multipart/alternative; boundary=001a1136035043ee7c04eff2b1fa Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 18:52:35 -0000 --001a1136035043ee7c04eff2b1fa Content-Type: text/plain; charset=UTF-8 On Wed, Jan 15, 2014 at 3:38 AM, Nick Hilliard wrote: > > So what security are you suggesting to deploy to ensure that your set up > > remains sufficiently isolated between customers, even though they share a > > L2 LAN? > > Right now? I have nothing. I can't deploy ipv6 without holes large enough > to drive trucks through. > You can't give every customer their own /64? --001a1136035043ee7c04eff2b1fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 15, 2014 at 3:38 AM, Nick Hilliard <nick@foobar.org> w= rote:
> So what security are = you suggesting to deploy to ensure that your set up
> remains sufficiently isolated between customers, even though they shar= e a
> L2 LAN?

Right now? =C2=A0I have nothing. =C2=A0I can't deploy ipv6 withou= t holes large enough
to drive trucks through.

You can't = give every customer their own /64?=C2=A0
--001a1136035043ee7c04eff2b1fa-- From nick@foobar.org Tue Jan 14 10:58:07 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21141AE17E for ; Tue, 14 Jan 2014 10:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgi8eSUj1PZN for ; Tue, 14 Jan 2014 10:58:05 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8331ADF8F for ; Tue, 14 Jan 2014 10:58:05 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::126]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id s0EIvn5c041132 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 14 Jan 2014 18:57:50 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::126] claimed to be cupcake.foobar.org Message-ID: <52D588AD.4010506@foobar.org> Date: Tue, 14 Jan 2014 18:57:49 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D18F22.1070708@foobar.org> <1389490607.51957.YahooMailNeo@web161904.mail.bf1.yahoo.com> <52D2A8EF.2040901@foobar.org> <52D4E794.3070109@globis.net> <52D57214.1070505@foobar.org> <52D57DC5.9080603@globis.net> <52D58413.3050506@foobar.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 18:58:07 -0000 On 14/01/2014 18:52, Lorenzo Colitti wrote: > You can't give every customer their own /64? Not without setting up vrrp per customer. Doesn't scale. Nick From v6ops@globis.net Tue Jan 14 11:23:58 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 239191AE139 for ; Tue, 14 Jan 2014 11:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.521 X-Spam-Level: X-Spam-Status: No, score=-0.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_26=0.6, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltoNf9Qdpyv7 for ; Tue, 14 Jan 2014 11:23:53 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 86A471ADFB1 for ; Tue, 14 Jan 2014 11:23:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id B3CC987149F; Tue, 14 Jan 2014 20:23:40 +0100 (CET) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJVHAqCKSMCo; Tue, 14 Jan 2014 20:23:40 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 8F80987006A; Tue, 14 Jan 2014 20:23:40 +0100 (CET) Message-ID: <52D58EBB.1070008@globis.net> Date: Tue, 14 Jan 2014 20:23:39 +0100 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Owen DeLong References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D18F22.1070708@foobar.org> <1389490607.51957.YahooMailNeo@web161904.mail.bf1.yahoo.com> <52D2A8EF.2040901@foobar.org> <52D4E794.3070109@globis.net> <52D57214.1070505@foobar.org> <52D57DC5.9080603@globis.net> <807E80E4-40CA-49CD-AC7D-F512D5B51B23@delong.com> In-Reply-To: <807E80E4-40CA-49CD-AC7D-F512D5B51B23@delong.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 19:23:58 -0000 > Owen DeLong > 14 January 2014 19:17 > On Jan 14, 2014, at 10:11 , Ray Hunter wrote: > >>> Nick Hilliard >>> 14 January 2014 18:21 >>> >>> private vlans are troublesome, to say the least. In a virtualised >>> environment, you need multi-switch support for specific types of pvlans. >>> This places vendor restrictions on the types of kit you need to deploy. >>> >>> Nick >>> ------------------------------------------------------------------------ >> Yes. >> >> I've read posts from a number of DC operators who have expressly chosen for PVLANs compared to deploying dedicated L3 ports per server/ customer in multi-tenant environments, driven by a desire to save on very scarce public IPv4 addresses. > > Which might make sense when the customers are on separate hardware. Agreed. But if you can emulate a L2 LAN, or a L3 router, you can presumably also emulate a PVLAN. > When the customers are separate virtuals on the same hardware, PVLANs become a bit less useful, though at that point, dedicated L3 ports in the virtual switch on the host become much more feasible, though you still have the network addressing cost issue if you're tied to IPv4. Right.. >> That of course will likely bring problems migrating to IPv6 in the future e.g. DAD is probably not going to be able to detect duplicate addresses via multicast. > > Depends on how the PVLANs treat link-scoped IPv6 multicast. Yes. There's no standard AFAIK. > >> Hence my suggestion of prefix length>> 64 + PVLAN + DHCPv6 + DHCPv6 setting default router + HSRPv6/VRRPv3 to exactly mirror the IPv4 setup. > > Not sure how that really helps. Why is a longer prefix length allegedly useful in this context? > > Owen > > The context of this thread was a request for DHCPv6 to be able to set the default router, and avoid using RA. That's an interesting topic. I'm happy to continue the discussion about prefix length in detail, but shall we do that another time? Is it sufficient for now to say that in a virtual environment, I think it's even more important to contain resource depletion problems and potential cross-contamination between environments? The memory used to contain e.g. an ND table on one virtual LAN switch or router is almost certainly allocated from a shared pool that may not be well protected from overflowing. And it's going to be very easy to fill up the TCP session tables in e.g. machine firewalls using ip6tables, if a single rogue source on the local DC LAN can spoof source addresses from the equivalent of an entire continent today. -- Regards, RayH From iesg-secretary@ietf.org Tue Jan 14 11:40:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4AC1AE22F; Tue, 14 Jan 2014 11:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WnD1TCAr7eo; Tue, 14 Jan 2014 11:40:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0072B1ADF9A; Tue, 14 Jan 2014 11:40:12 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140114194011.585.43805.idtracker@ietfa.amsl.com> Date: Tue, 14 Jan 2014 11:40:11 -0800 Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (NAT64 Operational Experience) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 19:40:14 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'NAT64 Operational Experience' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-01-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document summarizes NAT64 function deployment scenarios and operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) and NAT64 server Front End (NAT64-FE) are considered in this document. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience/ballot/ No IPR declarations have been submitted directly on this I-D. From owen@delong.com Tue Jan 14 11:53:22 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DAEC1ADFB1 for ; Tue, 14 Jan 2014 11:53:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.928 X-Spam-Level: X-Spam-Status: No, score=-0.928 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrFAa86bsqxM for ; Tue, 14 Jan 2014 11:53:21 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 553021AE241 for ; Tue, 14 Jan 2014 11:53:21 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s0EJo9qI003020 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Jan 2014 11:50:09 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s0EJo9qI003020 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1389729010; bh=9zZ2m81lqXkrWevWm2fXpnaz2H0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=sCTEPBqiddQTqvKBZBpDjT53CP3sdNLTg1Q367qdn0nIfJQ39cuuHvxKUeWBKoYnc bL3kZVKx6RVgZd4fb0yC5lxhKdi+1Gl+PTtcSnzzB5Fc1rDvGPVH0A6XMBwo/6BSdm ++7x8WUIzkwfRa6EaD2PlCdiXhrnK1EugJiOhdjM= Content-Type: multipart/alternative; boundary="Apple-Mail=_B82E6D68-2B56-42FC-BBA1-32DF8368B54E" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Owen DeLong In-Reply-To: <52D58EBB.1070008@globis.net> Date: Tue, 14 Jan 2014 11:50:13 -0800 Message-Id: References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D18F22.1070708@foobar.org> <1389490607.51957.YahooMailNeo@web161904.mail.bf1.yahoo.com> <52D2A8EF.2040901@foobar.org> <52D4E794.3070109@globis.net> <52D57214.1070505@foobar.org> <52D57DC5.9080603@globis.net> <807E80E4-40CA-49CD-AC7D-F512D5B51B23@delong.com> <52D58EBB.1070008@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 14 Jan 2014 11:50:10 -0800 (PST) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 19:53:22 -0000 --Apple-Mail=_B82E6D68-2B56-42FC-BBA1-32DF8368B54E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jan 14, 2014, at 11:23 , Ray Hunter wrote: >> Owen DeLong >> 14 January 2014 19:17 >> On Jan 14, 2014, at 10:11 , Ray Hunter wrote: >>=20 >>>> Nick Hilliard >>>> 14 January 2014 18:21 >>>>=20 >>>> private vlans are troublesome, to say the least. In a virtualised >>>> environment, you need multi-switch support for specific types of = pvlans. >>>> This places vendor restrictions on the types of kit you need to = deploy. >>>>=20 >>>> Nick >>>> = ------------------------------------------------------------------------ >>> Yes. >>>=20 >>> I've read posts from a number of DC operators who have expressly = chosen for PVLANs compared to deploying dedicated L3 ports per server/ = customer in multi-tenant environments, driven by a desire to save on = very scarce public IPv4 addresses. >>=20 >> Which might make sense when the customers are on separate hardware. > Agreed. But if you can emulate a L2 LAN, or a L3 router, you can = presumably also emulate a PVLAN. That doesn't necessarily follow, actually. At least in Linux, to the = best of my knowledge, it's easy to set up multiple bridge groups, route = between them and connect your virtual hosts accordingly. I don't know of = any way to set up PVLAN emulation. OTOH, I've always regarded PVLAN as a really horrible hackish technique = for IPv4 address conservation where segmentation would be the preferred = solution, so I can't imagine preferring a PVLAN solution when a VLAN = solution is available unless I'm stuck in IPv4 land and short on = addresses. >> When the customers are separate virtuals on the same hardware, PVLANs = become a bit less useful, though at that point, dedicated L3 ports in = the virtual switch on the host become much more feasible, though you = still have the network addressing cost issue if you're tied to IPv4. > Right.. >>> That of course will likely bring problems migrating to IPv6 in the = future e.g. DAD is probably not going to be able to detect duplicate = addresses via multicast. >>=20 >> Depends on how the PVLANs treat link-scoped IPv6 multicast. > Yes. There's no standard AFAIK. There are no standards for PVLANs at all to the best of my knowledge. I = suspect each vendor has a subtly different implementation and definition = of the term to begin with. They're simply a terrible terrible hack that = makes sense only in the context of extreme address shortage. >>=20 >>> Hence my suggestion of prefix length>> 64 + PVLAN + DHCPv6 + DHCPv6 = setting default router + HSRPv6/VRRPv3 to exactly mirror the IPv4 setup. >>=20 >> Not sure how that really helps. Why is a longer prefix length = allegedly useful in this context? >>=20 >> Owen >>=20 >>=20 > The context of this thread was a request for DHCPv6 to be able to set = the default router, and avoid using RA. > That's an interesting topic. Still not understanding how the longer prefix helps with that. >=20 > I'm happy to continue the discussion about prefix length in detail, = but shall we do that another time? >=20 > Is it sufficient for now to say that in a virtual environment, I think = it's even more important to contain resource depletion problems and = potential cross-contamination between environments? The memory used to = contain e.g. an ND table on one virtual LAN switch or router is almost = certainly allocated from a shared pool that may not be well protected = from overflowing. And it's going to be very easy to fill up the TCP = session tables in e.g. machine firewalls using ip6tables, if a single = rogue source on the local DC LAN can spoof source addresses from the = equivalent of an entire continent today. I still don't see the cost benefit ratio of such attacks being such that = they are all that likely to occur. There are easy enough ways to commit = such attacks in IPv4, yet they remain quite rare. I don't see any reason = they would increase in IPv6. They are high risk, low reward types of = attacks. Owen --Apple-Mail=_B82E6D68-2B56-42FC-BBA1-32DF8368B54E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Jan 14, 2014, at 11:23 , Ray Hunter = <v6ops@globis.net> = wrote:

Owen DeLong = <mailto:owen@delong.com>
14 = January 2014 19:17
On Jan 14, 2014, at 10:11 , Ray Hunter<v6ops@globis.net> =  wrote:

Nick Hilliard<mailto:nick@foobar.org>
14 = January 2014 18:21

private vlans are troublesome, to say the = least. In a virtualised
environment, you need multi-switch support = for specific types of pvlans.
This places vendor restrictions on the = types of kit you need to = deploy.

Nick
---------------------------------------------------= ---------------------
Yes.

I've read posts from a = number of DC operators who have expressly chosen for PVLANs compared to = deploying dedicated L3 ports per server/ customer in multi-tenant = environments, driven by a desire to save on very scarce public IPv4 = addresses.

Which might make sense when the customers = are on separate hardware.
Agreed. But if you can emulate = a L2 LAN, or a L3 router, you can presumably also emulate a = PVLAN.

That doesn't necessarily = follow, actually. At least in Linux, to the best of my knowledge, it's = easy to set up multiple bridge groups, route between them and connect = your virtual hosts accordingly. I don't know of any way to set up PVLAN = emulation.

OTOH, I've always regarded PVLAN as = a really horrible hackish technique for IPv4 address conservation where = segmentation would be the preferred solution, so I can't imagine = preferring a PVLAN solution when a VLAN solution is available unless I'm = stuck in IPv4 land and short on addresses.

When the = customers are separate virtuals on the same hardware, PVLANs become a = bit less useful, though at that point, dedicated L3 ports in the virtual = switch on the host become much more feasible, though you still have the = network addressing cost issue if you're tied to = IPv4.
Right..
That of course will likely bring problems migrating to = IPv6 in the future e.g. DAD is probably not going to be able to detect = duplicate addresses via multicast.

Depends on how = the PVLANs treat link-scoped IPv6 multicast.
Yes. = There's no standard AFAIK.

There = are no standards for PVLANs at all to the best of my knowledge. I = suspect each vendor has a subtly different implementation and definition = of the term to begin with. They're simply a terrible terrible hack that = makes sense only in the context of extreme address = shortage.


Hence my = suggestion of prefix length>>  64 + PVLAN + DHCPv6 + DHCPv6 = setting default router + HSRPv6/VRRPv3 to exactly mirror the IPv4 = setup.

Not sure how that really helps. Why is a = longer prefix length allegedly useful in this = context?

Owen


The context of this thread = was a request for DHCPv6 to be able to set the default router, and avoid = using RA.
That's an interesting = topic.

Still not understanding how = the longer prefix helps with that.


I'm happy to continue the = discussion about prefix length in detail, but shall we do that another = time?

Is it sufficient for now to say that in a virtual = environment, I think it's even more important to contain resource = depletion problems and potential cross-contamination between = environments? The memory used to contain e.g. an ND table on one virtual = LAN switch or router is almost certainly allocated from a shared pool = that may not be well protected from overflowing. And it's going to be = very easy to fill up the TCP session tables in e.g. machine firewalls = using ip6tables, if a single rogue source on the local DC LAN can spoof = source addresses from the equivalent of an entire continent = today.

I still don't see the cost = benefit ratio of such attacks being such that they are all that likely = to occur. There are easy enough ways to commit such attacks in IPv4, yet = they remain quite rare. I don't see any reason they would increase in = IPv6. They are high risk, low reward types of = attacks.

Owen

= --Apple-Mail=_B82E6D68-2B56-42FC-BBA1-32DF8368B54E-- From markzzzsmith@yahoo.com.au Tue Jan 14 15:29:34 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A62C1AE101 for ; Tue, 14 Jan 2014 15:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tV8UmnPksNPH for ; Tue, 14 Jan 2014 15:29:32 -0800 (PST) Received: from nm45.bullet.mail.ne1.yahoo.com (nm45.bullet.mail.ne1.yahoo.com [98.138.120.52]) by ietfa.amsl.com (Postfix) with ESMTP id 41C981ADBE5 for ; Tue, 14 Jan 2014 15:29:32 -0800 (PST) Received: from [127.0.0.1] by nm45.bullet.mail.ne1.yahoo.com with NNFMP; 14 Jan 2014 23:29:20 -0000 Received: from [98.138.226.180] by nm45.bullet.mail.ne1.yahoo.com with NNFMP; 14 Jan 2014 23:26:34 -0000 Received: from [98.139.214.32] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 14 Jan 2014 23:26:34 -0000 Received: from [98.139.212.198] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 14 Jan 2014 23:26:34 -0000 Received: from [127.0.0.1] by omp1007.mail.bf1.yahoo.com with NNFMP; 14 Jan 2014 23:26:34 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 480471.24474.bm@omp1007.mail.bf1.yahoo.com Received: (qmail 76797 invoked by uid 60001); 14 Jan 2014 23:26:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1389741994; bh=ufDMgo/BEJiJu34+coPHhM2raBICUh5nwdLBcm7SoLg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=PmlSKuuXTrCH+5yMweczgJFi9S6CygxvXzlgmHk01yzJF7ImZbp1KkKLwew5IKsFLhsNyORjL75YccslXrrq4eN3cdjiS/KR+Xsu/fHF7ucYQdoox6jkYI/1jVzUqjf1vLGFPtGOrVLiAXZ/+XPA84yZUVeUlaRbfVP3QmtTaUQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=2LHCvvKnnJ+78g6Fl+6urao5xIwkoIpWIpXy2+FPvpdJC1Ng9K4ilV0PDtlsglDIlx0u5qACbgWJn3YcqatZ92zyy+kD+cc7LXquy+qa7yQ6yO09JozGjpNaA0QGQoXPq2buhbvvC9mSQL8bpVzdqcFPFKZFJos9H6wmjiuxz0o=; X-YMail-OSG: kJKg6dYVM1knhAXbDiOhu_E5NTjsCRBNuLrsSaaSmCo1S05 XA9C0KvyHxMzS9QxddYaaqF_.gOZ.HHhadueypNtZuEAs6WKmVOM_7KUzYXZ YfC.0B3pnQcXTmVZedre8dIyM8RxhOWjC_IdEwm.3AiOtuUSiowFOS8fLP4A haJES4ilMZbfZzkOEOt8oVcSxL87_9n7HvXKVrFHCBby0GknsTULyIu.Jxhm O.d9WHBTr1Qm_6GnvpK0dCzXCO1Zk9Niiv0IBr.AwoLU7V_G7XrFthOlbXtg Lk0Xop8aTUmkni7D_n1dDwUTY2AWcSmUy6lyTpWm9nBdkTP24rQDsMlUWDbN YgKoTIJBSfuZouhl0fG2nxBsAx7dNMsNhdZG9QxKyX.xisMB.3X.z2jhiSVv zUX9U7_Zi9biDiVNKDG8aEwtjgcB005aSCA6JoOzM1AxPfU3JhVhSY_Rru7m Mp8fMAu00HbYqDGfj9lAGOpgXs6rMvmyPse8RuLVgkeb8aoun4f_lbz0bpu7 XT_ZD5lPSpYhTixYD4X.iFPJY9ezPOKoCP85fgeLmAwlMeqmklV7vQInrfxV SIr35R80jww0DNwEB087wdL.BipbdMqc- Received: from [121.200.231.211] by web161905.mail.bf1.yahoo.com via HTTP; Tue, 14 Jan 2014 15:26:34 PST X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBSYXkgSHVudGVyIDx2Nm9wc0BnbG9iaXMubmV0Pgo.IFRvOiBOaWNrIEhpbGxpYXJkIDxuaWNrQGZvb2Jhci5vcmc.Cj4gQ2M6ICJ2Nm9wc0BpZXRmLm9yZyBXRyIgPHY2b3BzQGlldGYub3JnPgo.IFNlbnQ6IFdlZG5lc2RheSwgMTUgSmFudWFyeSAyMDE0IDU6MTEgQU0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBjb250cm9sIGFuZCBzZWN1cml0eSBvZiBESENQCj4gCj4.ICBOaWNrIEhpbGxpYXJkIDxtYWlsdG86bmlja0Bmb29iYXIub3IBMAEBAQE- X-Mailer: YahooMailWebService/0.8.172.614 References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D18F22.1070708@foobar.org> <1389490607.51957.YahooMailNeo@web161904.mail.bf1.yahoo.com> <52D2A8EF.2040901@foobar.org> <52D4E794.3070109@globis.net> <52D57214.1070505@foobar.org> <52D57DC5.9080603@globis.net> Message-ID: <1389741994.37525.YahooMailNeo@web161905.mail.bf1.yahoo.com> Date: Tue, 14 Jan 2014 15:26:34 -0800 (PST) From: Mark ZZZ Smith To: Ray Hunter , Nick Hilliard In-Reply-To: <52D57DC5.9080603@globis.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 23:29:34 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Ray Hunter =0A> To: Nick Hilliard =0A> Cc: "v6ops@ietf.org WG" <= v6ops@ietf.org>=0A> Sent: Wednesday, 15 January 2014 5:11 AM=0A> Subject: R= e: [v6ops] control and security of DHCP=0A> =0A>> Nick Hilliard =0A>> 14 January 2014 18:21=0A>> =0A>> private vlans are tr= oublesome, to say the least. In a virtualised=0A>> environment, you need m= ulti-switch support for specific types of pvlans.=0A>> This places vendor = restrictions on the types of kit you need to deploy.=0A>> =0A>> Nick=0A>> = ------------------------------------------------------------------------= =0A> Yes.=0A> =0A> I've read posts from a number of DC operators who have e= xpressly chosen =0A> for PVLANs compared to deploying dedicated L3 ports pe= r server/ customer =0A> in multi-tenant environments, driven by a desire to= save on very scarce =0A> public IPv4 addresses.=0A> =0A> That of course wi= ll likely bring problems migrating to IPv6 in the =0A> future e.g. DAD is p= robably not going to be able to detect duplicate =0A> addresses via multica= st.=0A>=A0=0A=0AJust an FYI,=0A=0ADuplicate Address Detection Proxy=0Ahttp:= //tools.ietf.org/html/rfc6957=0A=0A=0AMy perspective on private VLANs etc. = type problem has come from experience in the residential broadband environm= ent with BYO CPE. Not only can't you control the type of CPE that is purcha= sed, you can't assume that the people who operate them are capable of even = the most basic security administration. It is a completely untrusted enviro= nment, and therefore I think solutions that work in that environment are al= so going to be quite effective in DC or enterprise environments.=0A=0AThese= sorts of spoofing etc. problems are solved by per-subscriber PPPoE session= s, per subscriber single or double VLAN tags, or the N:1 / "private VLAN" m= odel. All of them are isolating subscribers/CPE/hosts, however from a routi= ng perspective the last one is the most scalable, because multiple subscrib= ers/CPE/hosts are collected together within a single subnet (obviously we g= et use things such as routing aggregation to scale further, however there c= an still can be value in reducing FIB entries/PPPoE/QinQ session entries on= the BRAS itself.)=0A=0A=0A=0A> Hence my suggestion of prefix length >> 64 = + PVLAN + DHCPv6 + DHCPv6 =0A> setting default router + HSRPv6/VRRPv3 to ex= actly mirror the IPv4 setup.=0A> =0A> It would also mean that any failovers= are likely to be very similar for =0A> both IPv4 and IPv6 paths, and that = HSRPv6//VRRPv3 generally has more =0A> features (track/ preempt/ MD5 authen= tication) which RA clearly doesn't =0A> have (yet), which I see as clear op= erational advantages. My opinion is =0A> that combination is a pretty valid= use case for transitioning a =0A> multi-tenant IPv4 environment to IPv6 us= ing dual stack, and which =0A> requires the additional functionality you wa= nt. Otherwise people running =0A> IPv4 PVLANs are going to get painted into= a corner.=0A> =0A> =0A> So what security are you suggesting to deploy to e= nsure that your set up =0A> remains sufficiently isolated between customers= , even though they share =0A> a L2 LAN?=0A> =0A> I'm not saying necessarily= that RA should be the only game in town, but =0A> it is there today. And w= e all know how hard it is to prevent attacks by =0A> on-link attackers (not= just RA).=0A> =0A> -- =0A> Regards,=0A> =0A> RayH=0A> =0A> _______________= ________________________________=0A> v6ops mailing list=0A> v6ops@ietf.org= =0A> https://www.ietf.org/mailman/listinfo/v6ops=0A> From markzzzsmith@yahoo.com.au Tue Jan 14 15:33:57 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7AA1AE0CC for ; Tue, 14 Jan 2014 15:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.802 X-Spam-Level: * X-Spam-Status: No, score=1.802 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJJbKblc9x6H for ; Tue, 14 Jan 2014 15:33:55 -0800 (PST) Received: from nm41.bullet.mail.ne1.yahoo.com (nm41.bullet.mail.ne1.yahoo.com [98.138.120.48]) by ietfa.amsl.com (Postfix) with ESMTP id 428961AE077 for ; Tue, 14 Jan 2014 15:33:54 -0800 (PST) Received: from [127.0.0.1] by nm41.bullet.mail.ne1.yahoo.com with NNFMP; 14 Jan 2014 23:33:42 -0000 Received: from [98.138.100.113] by nm41.bullet.mail.ne1.yahoo.com with NNFMP; 14 Jan 2014 23:30:42 -0000 Received: from [98.139.215.141] by tm104.bullet.mail.ne1.yahoo.com with NNFMP; 14 Jan 2014 23:30:42 -0000 Received: from [98.139.212.205] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 14 Jan 2014 23:30:42 -0000 Received: from [127.0.0.1] by omp1014.mail.bf1.yahoo.com with NNFMP; 14 Jan 2014 23:30:42 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 226126.35753.bm@omp1014.mail.bf1.yahoo.com Received: (qmail 14155 invoked by uid 60001); 14 Jan 2014 23:30:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1389742242; bh=MGUB2PYdp4vR7FXxFwjk/qp8hgAwFt7Zay5mL+B4GPQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Q/0XploN9svpJxIjBGZ7mqZ7TIj8hibLBpNv7+A030k7IcK0HJONyFM4Q4UV+pZdhwBS1u4ezGggjJNetf3b51yjrQIx1ArXKz8tFODb471NB+UMhXkrSnwKY6iNz3QDoqXh+Gm1sxUWKmoP6sv636AecLFS5p59qskN6GtTmao= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=D2ZrrQNjhhpBs50aozZKBNaecmK5OY7k4c1Jv2yai9ACF+DyrkhmEss1CupP7aQYOl0TRCT1zYzUUSR0UwICng/HHkS27Bh4e8AWZBcSpGGbEt3Tp8kKQo6RNQKVo3m8HqaOdCEhg/5F+CW3t7ld2p8cCu3XSwpb0jB3na2knjU=; X-YMail-OSG: 4NlKs2AVM1kFzssM9hfZ0GOxSbFoyOsnjhka_HGa05us02O j7GNAQwQGuddSgkiLbKZMRZ5jvDJ6mO0O0Z04RgkljnArkcrmjy1vNGvCaoK Tay5bG08u264NWxvbMIAidANCoHyYjn4.mlOsTfoYs_cPMB7j5y9xHToTZxT kyBIU0Hqi7y1gF9hCu2ucpy1CYhdImBhTmoQdcS3ZNDwvjmJlJevj_ogOjfo NbvYZuRhFo5sXV7tLRPO9O5jxNeszeE6yU7y2kWLxmgyjeHk1chEl1yf_pDl AFlehze.HDKz2krbSZXfPWspP5nySpfQODyhazeQILWLGaaRNM1eDoQOzGM_ nNpg6lCFVilj6xhBSfaMROn.5VfcPlhdmWE4WoTBlP5QuGik70TD8sUaL8ka w6_vTzpPUKxeFc.jRoUlzAMxxyExMzzdF8xjHpD7DnhwbrQ2ooSAC2A7YOv4 l7UTwosL6V5068fw8Sl3bSAaMFYsh9WogSrPt3GnM9mJikNa02vds4ewUF4O GPNRp09PP2.mehSq.oAyRyq44Yeazq72ctObXTpBALV.GPjqQiEJRLleeWCw jcKoKd3lLG5qQwrzpvdpG9CkZ Received: from [121.200.231.211] by web161903.mail.bf1.yahoo.com via HTTP; Tue, 14 Jan 2014 15:30:41 PST X-Rocket-MIMEInfo: 002.001, CgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBPd2VuIERlTG9uZyA8b3dlbkBkZWxvbmcuY29tPgo.VG86IFJheSBIdW50ZXIgPHY2b3BzQGdsb2Jpcy5uZXQ.IAo.Q2M6ICJ2Nm9wc0BpZXRmLm9yZyBXRyIgPHY2b3BzQGlldGYub3JnPiAKPlNlbnQ6IFdlZG5lc2RheSwgMTUgSmFudWFyeSAyMDE0IDY6NTAgQU0KPlN1YmplY3Q6IFJlOiBbdjZvcHNdIGNvbnRyb2wgYW5kIHNlY3VyaXR5IG9mIERIQ1AKPiAKPgo.Cj4KPgo.T24gSmFuIDE0LCAyMDE0LCBhdCAxMToyMyAsIFIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.172.614 References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D18F22.1070708@foobar.org> <1389490607.51957.YahooMailNeo@web161904.mail.bf1.yahoo.com> <52D2A8EF.2040901@foobar.org> <52D4E794.3070109@globis.net> <52D57214.1070505@foobar.org> <52D57DC5.9080603@globis.net> <807E80E4-40CA-49CD-AC7D-F512D5B51B23@delong.com> <52D58EBB.1070008@globis.net> Message-ID: <1389742241.49365.YahooMailNeo@web161903.mail.bf1.yahoo.com> Date: Tue, 14 Jan 2014 15:30:41 -0800 (PST) From: Mark ZZZ Smith To: Owen DeLong , Ray Hunter In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 23:33:57 -0000 =0A=0A=0A=0A=0A>________________________________=0A> From: Owen DeLong =0A>To: Ray Hunter =0A>Cc: "v6ops@ietf.org = WG" =0A>Sent: Wednesday, 15 January 2014 6:50 AM=0A>Subjec= t: Re: [v6ops] control and security of DHCP=0A> =0A>=0A>=0A>=0A>=0A>On Jan = 14, 2014, at 11:23 , Ray Hunter wrote:=0A>=0A>Owen DeLon= g =0A>>>14 January 2014 19:17=0A>>>On Jan 14, 2014,= at 10:11 , Ray Hunter =A0wrote:=0A>>>=0A>>>=0A>>>Nick Hi= lliard=0A>>>>>14 January 2014 18:21=0A>>>>>=0A>>>>>= private vlans are troublesome, to say the least. In a virtualised=0A>>>>>en= vironment, you need multi-switch support for specific types of pvlans.=0A>>= >>>This places vendor restrictions on the types of kit you need to deploy.= =0A>>>>>=0A>>>>>Nick=0A>>>>>-----------------------------------------------= -------------------------=0A>>>>>Yes.=0A>>>>=0A>>>>I've read posts from a n= umber of DC operators who have expressly chosen for PVLANs compared to depl= oying dedicated L3 ports per server/ customer in multi-tenant environments,= driven by a desire to save on very scarce public IPv4 addresses.=0A>>>>=0A= >>>Which might make sense when the customers are on separate hardware.=0A>>= >Agreed. But if you can emulate a L2 LAN, or a L3 router, you can presumabl= y also emulate a PVLAN.=0A>>=0A>=0A>That doesn't necessarily follow, actual= ly. At least in Linux, to the best of my knowledge, it's easy to set up mul= tiple bridge groups, route between them and connect your virtual hosts acco= rdingly. I don't know of any way to set up PVLAN emulation.=0A>=0A>=0A>OTOH= , I've always regarded PVLAN as a really horrible hackish technique for IPv= 4 address conservation where segmentation would be the preferred solution, = so I can't imagine preferring a PVLAN solution when a VLAN solution is avai= lable unless I'm stuck in IPv4 land and short on addresses.=0A>=0A>=0A>When= the customers are separate virtuals on the same hardware, PVLANs become a = bit less useful, though at that point, dedicated L3 ports in the virtual sw= itch on the host become much more feasible, though you still have the netwo= rk addressing cost issue if you're tied to IPv4.=0A>>>Right..=0A>>=0A>>That= of course will likely bring problems migrating to IPv6 in the future e.g. = DAD is probably not going to be able to detect duplicate addresses via mult= icast.=0A>>>>=0A>>>Depends on how the PVLANs treat link-scoped IPv6 multica= st.=0A>>>Yes. There's no standard AFAIK.=0A>>=0A>=0A>There are no standards= for PVLANs at all to the best of my knowledge. I suspect each vendor has a= subtly different implementation and definition of the term to begin with. = They're simply a terrible terrible hack that makes sense only in the contex= t of extreme address shortage.=0A>=0A=0ATR-101 from the Broadband Forum wou= ld be close to a standard.=0A=0A>=0A>=0A>>>=0A>>>Hence my suggestion of pre= fix length>> =A064 + PVLAN + DHCPv6 + DHCPv6 setting default router + HSRPv= 6/VRRPv3 to exactly mirror the IPv4 setup.=0A>>>>=0A>>>Not sure how that re= ally helps. Why is a longer prefix length allegedly useful in this context?= =0A>>>=0A>>>Owen=0A>>>=0A>>>=0A>>>The context of this thread was a request = for DHCPv6 to be able to set the default router, and avoid using RA.=0A>>Th= at's an interesting topic.=0A>>=0A>=0A>Still not understanding how the long= er prefix helps with that.=0A>=0A>=0A>=0A>>I'm happy to continue the discus= sion about prefix length in detail, but shall we do that another time?=0A>>= =0A>>Is it sufficient for now to say that in a virtual environment, I think= it's even more important to contain resource depletion problems and potent= ial cross-contamination between environments? The memory used to contain e.= g. an ND table on one virtual LAN switch or router is almost certainly allo= cated from a shared pool that may not be well protected from overflowing. A= nd it's going to be very easy to fill up the TCP session tables in e.g. mac= hine firewalls using ip6tables, if a single rogue source on the local DC LA= N can spoof source addresses from the equivalent of an entire continent tod= ay.=0A>>=0A>=0A>I still don't see the cost benefit ratio of such attacks be= ing such that they are all that likely to occur. There are easy enough ways= to commit such attacks in IPv4, yet they remain quite rare. I don't see an= y reason they would increase in IPv6. They are high risk, low reward types = of attacks.=0A>=0A>=0A>Owen=0A>=0A>=0A>=0A>________________________________= _______________=0A>v6ops mailing list=0A>v6ops@ietf.org=0A>https://www.ietf= .org/mailman/listinfo/v6ops=0A>=0A>=0A> From tjc@ecs.soton.ac.uk Wed Jan 15 04:09:19 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7C81AE33A for ; Wed, 15 Jan 2014 04:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.758 X-Spam-Level: X-Spam-Status: No, score=-1.758 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUtRzxanrPBq for ; Wed, 15 Jan 2014 04:09:16 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id D65B71AE06A for ; Wed, 15 Jan 2014 04:09:15 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s0FC8plV006739; Wed, 15 Jan 2014 12:08:51 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s0FC8plV006739 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1389787731; bh=KjA34ZJm/+roMQUJ4gXiBgtoh0Q=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=EzbtYiP0NfZsYx9XrPsl0IuIQl/FfMGmpMJYkIjEPCQRQDuFq6NoaI7IYweVjtyct Fa7ViOxEF9quWTfThwGoUdZa5PSeP768gLi8ugb+lej8AEDV/XBlle3tEGtZ6/UcUn v/ICkfMaCvwBv52lh5sQgGt/3QKi0IB6LtoYswd4= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id q0EC8p0959649316DC ret-id none; Wed, 15 Jan 2014 12:08:51 +0000 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s0FC8m8o020775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Jan 2014 12:08:48 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_FB10414E-E845-4639-AFDD-976FA12F8893" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Tim Chown In-Reply-To: Date: Wed, 15 Jan 2014 12:08:49 +0000 Message-ID: References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D18F22.1070708@foobar.org> <1389490607.51957.YahooMailNeo@web161904.mail.bf1.yahoo.com> <52D2A8EF.2040901@foobar.org> <52D4E794.3070109@globis.net> <52D57214.1070505@foobar.org> <52D57DC5.9080603@globis.net> <52D58413.3050506@foobar.org> <02C4DFC9-847B-47B9-84B3-99967FCF2DE2@ecs.soton.ac.uk> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1510) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q0EC8p095964931600; tid=q0EC8p0959649316DC; client=relay,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s0FC8plV006739 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 12:09:19 -0000 --Apple-Mail=_FB10414E-E845-4639-AFDD-976FA12F8893 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 14 Jan 2014, at 18:52, Lorenzo Colitti wrote: > On Wed, Jan 15, 2014 at 3:38 AM, Nick Hilliard = wrote: > > So what security are you suggesting to deploy to ensure that your = set up > > remains sufficiently isolated between customers, even though they = share a > > L2 LAN? >=20 > Right now? I have nothing. I can't deploy ipv6 without holes large = enough > to drive trucks through. >=20 > You can't give every customer their own /64?=20 As a slight aside, we found that at certain vendors charge rather more = for images with L3 functionality than for L2 functionality, so it costs = more in real =A3=A3=A3 to put /64 per interface. So even if the device = is capable of doing it, it's frustrating that there's a tiered pricing = structure. I'd rather the vendor recognised the potential change in = IPv6 usage here and had price parity (on the lower price!). Tim --Apple-Mail=_FB10414E-E845-4639-AFDD-976FA12F8893 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 lorenzo@google.com> = wrote:

On Wed, Jan 15, 2014 at 3:38 AM, Nick Hilliard = <nick@foobar.org> wrote:
> = So what security are you suggesting to deploy to ensure that your set = up
> remains sufficiently isolated between customers, even though they = share a
> L2 LAN?

Right now?  I have nothing.  I can't deploy ipv6 without = holes large enough
to drive trucks through.

You can't = give every customer their own = /64? 

As a = slight aside, we found that at certain vendors charge rather more for = images with L3 functionality than for L2 functionality, so it costs more = in real =A3=A3=A3 to put /64 per interface.  So even if the device = is capable of doing it, it's frustrating that there's a tiered pricing = structure.  I'd rather the vendor recognised the potential change = in IPv6 usage here and had price parity (on the lower = price!).

Tim

= --Apple-Mail=_FB10414E-E845-4639-AFDD-976FA12F8893-- From michelg@upperside.fr Wed Jan 15 06:00:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA501AE364 for ; Wed, 15 Jan 2014 06:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.429 X-Spam-Level: ** X-Spam-Status: No, score=2.429 tagged_above=-999 required=5 tests=[BAYES_80=2, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKfOgXkV-Fbb for ; Wed, 15 Jan 2014 06:00:26 -0800 (PST) Received: from smtp07.msg.oleane.net (smtp07.msg.oleane.net [62.161.4.7]) by ietfa.amsl.com (Postfix) with ESMTP id 28B2B1AE36A for ; Wed, 15 Jan 2014 06:00:24 -0800 (PST) Received: from MGosseDellM6800 ([195.6.217.229]) (authenticated) by smtp07.msg.oleane.net (MSA) with ESMTP id s0FE0AGM009913 for ; Wed, 15 Jan 2014 15:00:11 +0100 X-Oleane-Rep: REPA From: "Michel Gosse" To: Date: Wed, 15 Jan 2014 15:00:09 +0100 Message-ID: <000001cf11fa$1a7a1ba0$4f6e52e0$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CF1202.7C3F9510" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac8R+fH+ZCkLfZBETWiR/FUHRfC4pg== Content-Language: fr X-Backend: vm-smtp-sophos06 X-PMX-Spam: Probability=9% X-PFSI-Info: PMX 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.15.132415 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Subject: [v6ops] V6 World 2014: IP on everything X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 14:00:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01CF1202.7C3F9510 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The 4th edition of V6 World will take place in Paris from 18 to 21 March, 2014. The agenda will pay particular attention to large scale deployments reports, content providers strategies and Internet of Things issues. More info: http://www.uppersideconferences.com/v6world2014/v6world2014program_day_1.htm l ------=_NextPart_000_0001_01CF1202.7C3F9510 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The 4th edition of V6 World will take = place in Paris from 18 to 21 March, 2014.

 

The agenda will pay particular = attention to large scale deployments reports, content providers = strategies and Internet of Things issues.

 

More info: http://www.uppersideconferences.com/v6w= orld2014/v6world2014program_day_1.html

 

------=_NextPart_000_0001_01CF1202.7C3F9510-- From Fred.L.Templin@boeing.com Wed Jan 15 07:32:04 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAD01AE0E2 for ; Wed, 15 Jan 2014 07:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSKiM2zhNnnq for ; Wed, 15 Jan 2014 07:32:02 -0800 (PST) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 79F541AE364 for ; Wed, 15 Jan 2014 07:32:02 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s0FFVoHv023084; Wed, 15 Jan 2014 09:31:50 -0600 Received: from XCH-PHX-109.sw.nos.boeing.com (xch-phx-109.sw.nos.boeing.com [130.247.25.36]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s0FFVjrY023028 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 15 Jan 2014 09:31:45 -0600 Received: from XCH-BLV-201.nw.nos.boeing.com (10.57.37.66) by XCH-PHX-109.sw.nos.boeing.com (130.247.25.36) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 15 Jan 2014 07:31:44 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.203]) by XCH-BLV-201.nw.nos.boeing.com ([169.254.1.214]) with mapi id 14.03.0158.001; Wed, 15 Jan 2014 07:31:44 -0800 From: "Templin, Fred L" To: Tim Chown , Lorenzo Colitti Thread-Topic: [v6ops] control and security of DHCP Thread-Index: AQHPEeqixUfnEblz6kmhegwZf+ZskZqF6ZaQ Date: Wed, 15 Jan 2014 15:31:44 +0000 Message-ID: <2134F8430051B64F815C691A62D9831819C017@XCH-BLV-504.nw.nos.boeing.com> References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D18F22.1070708@foobar.org> <1389490607.51957.YahooMailNeo@web161904.mail.bf1.yahoo.com> <52D2A8EF.2040901@foobar.org> <52D4E794.3070109@globis.net> <52D57214.1070505@foobar.org> <52D57DC5.9080603@globis.net> <52D58413.3050506@foobar.org> <02C4DFC9-847B-47B9-84B3-99967FCF2DE2@ecs.soton.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D9831819C017XCHBLV504nwnosboe_" MIME-Version: 1.0 X-TM-AS-MML: disable Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 15:32:04 -0000 --_000_2134F8430051B64F815C691A62D9831819C017XCHBLV504nwnosboe_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, a /64 per customer (or maybe even a /56 or shorter) is what AERO expect= s. Thanks - Fred From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Tim Chown Sent: Wednesday, January 15, 2014 4:09 AM To: Lorenzo Colitti Cc: Ray Hunter; v6ops@ietf.org WG Subject: Re: [v6ops] control and security of DHCP On 14 Jan 2014, at 18:52, Lorenzo Colitti > wrote: On Wed, Jan 15, 2014 at 3:38 AM, Nick Hilliard > wrote: > So what security are you suggesting to deploy to ensure that your set up > remains sufficiently isolated between customers, even though they share a > L2 LAN? Right now? I have nothing. I can't deploy ipv6 without holes large enough to drive trucks through. You can't give every customer their own /64? As a slight aside, we found that at certain vendors charge rather more for = images with L3 functionality than for L2 functionality, so it costs more in= real =A3=A3=A3 to put /64 per interface. So even if the device is capable= of doing it, it's frustrating that there's a tiered pricing structure. I'= d rather the vendor recognised the potential change in IPv6 usage here and = had price parity (on the lower price!). Tim --_000_2134F8430051B64F815C691A62D9831819C017XCHBLV504nwnosboe_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi, a /64 per customer (o= r maybe even a /56 or shorter) is what AERO expects.

 <= /p>

Thanks - Fred<= /span>

 <= /p>

From: v6ops [m= ailto:v6ops-bounces@ietf.org] On Behalf Of Tim Chown
Sent: Wednesday, January 15, 2014 4:09 AM
To: Lorenzo Colitti
Cc: Ray Hunter; v6ops@ietf.org WG
Subject: Re: [v6ops] control and security of DHCP<= /p>

 

 

On 14 Jan 2014, at 18:52, Lorenzo Colitti <lorenzo@google.com> wrote:



On Wed, Jan 15, 2014 at 3:38 AM, Nick Hilliard <<= a href=3D"mailto:nick@foobar.org" target=3D"_blank">nick@foobar.org>= wrote:

> So what security= are you suggesting to deploy to ensure that your set up
> remains sufficiently isolated between customers, even though they shar= e a
> L2 LAN?

Right now?  I have nothing.  I can't deplo= y ipv6 without holes large enough
to drive trucks through.

 

You can't give every customer their own /64? 

 

As a slight aside, we found that at certain vendors = charge rather more for images with L3 functionality than for L2 functionali= ty, so it costs more in real =A3=A3=A3 to put /64 per interface.  So e= ven if the device is capable of doing it, it's frustrating that there's a tiered pricing structure.  I'd rather the = vendor recognised the potential change in IPv6 usage here and had price par= ity (on the lower price!).

 

Tim

 

--_000_2134F8430051B64F815C691A62D9831819C017XCHBLV504nwnosboe_-- From owen@delong.com Wed Jan 15 11:13:22 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0378A1AE13F for ; Wed, 15 Jan 2014 11:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.528 X-Spam-Level: X-Spam-Status: No, score=-1.528 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjOltP-EWCLx for ; Wed, 15 Jan 2014 11:13:20 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id A217F1AE12A for ; Wed, 15 Jan 2014 11:13:19 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s0FJ8XSu020079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 15 Jan 2014 11:08:34 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s0FJ8XSu020079 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1389812915; bh=/g0sTJUJsm1aI1gVlYr2HphLyOQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=xwDtbIYDGYO3z4edlxEwe+/rbFxbvpzdL8VH4doEssQteXC2HksEibemo+t7vFAns COUp3AB9gSqSiBrgCut9rrQtyVAMD+b8PwHEId5WEsyf9Ug+DKTjFsQz9pHGviCycs cAwdVpw+HPNK4hbzVf3FLw83vPdbw/Ov0zcGPl2I= Content-Type: multipart/alternative; boundary="Apple-Mail=_56D94978-0FCE-4A5E-AA22-9C970539B09E" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Owen DeLong In-Reply-To: Date: Wed, 15 Jan 2014 11:08:40 -0800 Message-Id: <952FF407-0A03-48B4-802E-8DA36C4C1A1F@delong.com> References: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz> <52CFB8D5.70900@gmail.com> <20140110.124610.74672987.sthaug@nethelp.no> <60C5513D-B8DA-48D6-82D3-53E148F9F7BA@gmail.com> <52D0157D.6040009@foobar.org> <52D18F22.1070708@foobar.org> <1389490607.51957.YahooMailNeo@web161904.mail.bf1.yahoo.com> <52D2A8EF.2040901@foobar.org> <52D4E794.3070109@globis.net> <52D57214.1070505@foobar.org> <52D57DC5.9080603@globis.net> <52D58413.3050506@foobar.org> <02C4DFC9-847B-47B9-84B3-99967FCF2DE2@ecs.soton.ac.uk> To: Tim Chown X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 15 Jan 2014 11:08:35 -0800 (PST) Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] control and security of DHCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 19:13:22 -0000 --Apple-Mail=_56D94978-0FCE-4A5E-AA22-9C970539B09E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jan 15, 2014, at 04:08 , Tim Chown wrote: >=20 > On 14 Jan 2014, at 18:52, Lorenzo Colitti wrote: >=20 >> On Wed, Jan 15, 2014 at 3:38 AM, Nick Hilliard = wrote: >> > So what security are you suggesting to deploy to ensure that your = set up >> > remains sufficiently isolated between customers, even though they = share a >> > L2 LAN? >>=20 >> Right now? I have nothing. I can't deploy ipv6 without holes large = enough >> to drive trucks through. >>=20 >> You can't give every customer their own /64?=20 >=20 > As a slight aside, we found that at certain vendors charge rather more = for images with L3 functionality than for L2 functionality, so it costs = more in real =A3=A3=A3 to put /64 per interface. So even if the device = is capable of doing it, it's frustrating that there's a tiered pricing = structure. I'd rather the vendor recognised the potential change in = IPv6 usage here and had price parity (on the lower price!). >=20 There certainly are vendors who do, so it seems to me that this is a = valid vendor selection criteria. Owen --Apple-Mail=_56D94978-0FCE-4A5E-AA22-9C970539B09E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Jan 15, 2014, at 04:08 , Tim Chown = <tjc@ecs.soton.ac.uk> = wrote:

lorenzo@google.com> = wrote:

On Wed, Jan 15, 2014 at 3:38 AM, Nick Hilliard = <nick@foobar.org> wrote:
> = So what security are you suggesting to deploy to ensure that your set = up
> remains sufficiently isolated between customers, even though they = share a
> L2 LAN?

Right now?  I have nothing.  I can't deploy ipv6 without = holes large enough
to drive trucks through.

You can't = give every customer their own = /64? 

As a = slight aside, we found that at certain vendors charge rather more for = images with L3 functionality than for L2 functionality, so it costs more = in real =A3=A3=A3 to put /64 per interface.  So even if the device = is capable of doing it, it's frustrating that there's a tiered pricing = structure.  I'd rather the vendor recognised the potential change = in IPv6 usage here and had price parity (on the lower = price!).


There = certainly are vendors who do, so it seems to me that this is a valid = vendor selection = criteria.

Owen

= --Apple-Mail=_56D94978-0FCE-4A5E-AA22-9C970539B09E-- From lorenzo@google.com Fri Jan 17 16:54:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA11A1AD8EA for ; Fri, 17 Jan 2014 16:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHl0zY0qjK56 for ; Fri, 17 Jan 2014 16:54:31 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id ABDDE1ACCDF for ; Fri, 17 Jan 2014 16:54:31 -0800 (PST) Received: by mail-ig0-f178.google.com with SMTP id uq10so3104494igb.5 for ; Fri, 17 Jan 2014 16:54:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0Vt/qAETU2MrqWYlgEV3ajxr7qlEiSGYmQykhFdof9Y=; b=MyyLENHznQ0kUT5PqrK8UJ6bl1yl2lKzZ8BYNajEmw3koy+juZPVwypWvcaewLZ602 C5rxHVvnyZpHNizFKXQofp1wK0dT7X1dwV1yFuuPGtTwyAQRAOuKnZesWy4YcGyUkzGd aAoz/UM/z8qrOtjkL3GnM5laOTSK1ia0TeaWyv9g889qWn1gfzx9i06N9xLwwpIxbimM Sj+X6c6QoUWvVguBgD6feUl08Mr0t/m2jX+3PzetzPirIHub8Nr/r5QKdhs1Dt+HVzHq FbeX8RVR8x2ptYiJxQUWgLOLZVPoEmEQzduzXqZtNPr227PZ4tPhuqr86DwI0ndoSyQ4 +bnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0Vt/qAETU2MrqWYlgEV3ajxr7qlEiSGYmQykhFdof9Y=; b=BqdCDmWjzkEGWBvKjalIRzGd1ZXD4UPX8Arl8N3748LK0Nov6IFRkfflhXbYPOR7AR +NbdTgu+ytutFKJfBzk4QFnl1LaHARKQrrsMcPa6cPcaB6D5G1Cy4duvKscirwduzx3i u2ouiz28XfwtJhbcZncvPKxuPuACLM2c1lAiKTkos/DMr6XI3kjzbeephsanrgwLEe6K FNJ0899cDIWuMKrgW1/YAb/ndSA2teNIcslb0H/KXHJIsoiWqIap4uyQLrl8732VJhRI Ma7+83Y/IBLCgaedWHL8D31kfQXfFt8Jp0eddx4wjS2Arr5mobI8Dg5HPqAiPPOltfy2 6tWw== X-Gm-Message-State: ALoCoQkRto3bAtjTqAgikHHozyLWb8SdTxGR5sma5QwGXM38oSZf6Y3Q1Ic9l0/Gb4EZDiiv2XhcMhbH3k5vsIuJbClY68JulNNFr1J8STtgPz848WRcuvY9SZKPrsQLfLZ365cGDmGC7CHTJK4St3r9q0483rGxtaZcX/VNusDMqBwe2nqOQ1slG1xDgGRRT65c0Yzh39wu X-Received: by 10.50.61.137 with SMTP id p9mr1110744igr.45.1390006458969; Fri, 17 Jan 2014 16:54:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Fri, 17 Jan 2014 16:53:58 -0800 (PST) In-Reply-To: <20140112192103.21333.46615.idtracker@ietfa.amsl.com> References: <20140112192103.21333.46615.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Sat, 18 Jan 2014 09:53:58 +0900 Message-ID: To: internet-drafts Content-Type: multipart/alternative; boundary=047d7bdca5dc390dd204f03419b8 Cc: "v6ops@ietf.org WG" , i-d-announce@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-incremental-ipv6-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 00:54:33 -0000 --047d7bdca5dc390dd204f03419b8 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 13, 2014 at 4:21 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations Working Group of the > IETF. > > Title : Enterprise IPv6 Deployment Guidelines > A couple of comments: Section 3.5: - I think the draft should note that NPTv6 is an experimental technology, since RFC 6296 is experimental. - Do we have any actual deployment experience of deployment, or is there any public deployment experience? If not, the draft should note that this model is untested. - The statement "Use of NPTv6 can be chosen independently from how addresses are assigned and routed within the internal network" is not entirely accurate. For example, if an operator decides to use NPTv6 with ULA addresses, hosts will never use IPv6 to talk to external destinations, because IPv4->IPv4 is preferred over ULA -> IPv6. This might be a surprise. Section 2.6: - I think the draft should mention that ULAs are only intended for local communications and *not* for communication outside of a site (RFC 4193 section 1). This is important because otherwise readers might think that ULAs are an equivalent to RFC1918 space with NAT, which they are not intended to be. Regards, Lorenzo --047d7bdca5dc390dd204f03419b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jan 13, 2014 at 4:21 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the IPv6 Operations Working Group of the= IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Ente= rprise IPv6 Deployment Guidelines

A cou= ple of comments:

Section 3.5:
  • I = think the draft should note that NPTv6 is an experimental technology, since= RFC=C2=A06296 is experimental.
  • Do we have any actual deployment experience of =C2=A0deployment, o= r is there any public deployment experience? If not, the draft should note = that this model is untested.
  • The statement "Use of NPTv6 can b= e chosen independently from how addresses are assigned and routed within th= e internal network" is not entirely accurate. For example, if an opera= tor decides to use NPTv6 with ULA addresses, hosts will never use IPv6 to t= alk to external destinations, because IPv4->IPv4 is preferred over ULA -= > IPv6. This might be a surprise.
Section 2.6:
  • I think the draft should men= tion that ULAs are only intended for local communications and *not* for com= munication outside of a site (RFC 4193 section 1). This is important becaus= e otherwise readers might think that ULAs are an equivalent to RFC1918 spac= e with NAT, which they are not intended to be.
Regards,
Lorenzo
--047d7bdca5dc390dd204f03419b8-- From lorenzo@google.com Wed Jan 22 09:48:35 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043291A013A for ; Wed, 22 Jan 2014 09:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUhMeLMKVLaa for ; Wed, 22 Jan 2014 09:48:32 -0800 (PST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 741CC1A011B for ; Wed, 22 Jan 2014 09:48:32 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id tp5so5485525ieb.5 for ; Wed, 22 Jan 2014 09:48:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Pr9HXdvVb35IR8DJWnyKx79w7jLho+b0VcT/XFeExBU=; b=O6C0P0/DBhL5CVAPUlBUebZB2xx8GJ1LHpiQldVqpyldngIbuA9lu1MupNp92JbB4v sFVXd2EqXhOJjenjoxEccYcPfEnHbUyVUv2XZAd5IWyWdOU5tOKMONiySizp3weIRtks q8ANaYlYhYPdtdPGMNRdWNX9b0cx04RURMEIEEpHDyZfmPkQJADmxue6DWxyo48RxTen aMTKYNVj7Dmslf/ftN2qsS5nQdhGZ1waAROYr/Y0hQKLfydzUW5f9IyofgZKRKRQD71q 7BD+/U6ftoVrdbNq6HbP4V+1aSlUDOF2lyeiz4BH6ZC53RSIzV5qhzgsrG3GWiiyhw4a zMDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Pr9HXdvVb35IR8DJWnyKx79w7jLho+b0VcT/XFeExBU=; b=HhJ1Qu0URMGRmbzpPONez3AdV+b93RzV4sp8+3WWPMtqIy90dffzSvjMxg0kKxnfp9 R5GEvI0CsLwzDsaOltmfSu9BmvyrGh7GFu6a3OCRpLvzTqaLcuijOip6XZTO+RKY06xM qbGpCZc4UtkeRLXOZOle0910e5CI9RkSEXBsfT6Nb7JJEwb8PpyE2cuRDgetsqs3A4UH ArU+UIkHg0pbhoX0XYXo98+/WsMOHcd3X1Bw/YSI47kJdYZzo5sApufJa9Llb8BZW1Lp vqhw9Upqxj1rKQoiDgOSLGGNLnNu82LRqwCMfHZgtTh+XpPrAbBpupzzzd4XGXZLHi75 6aJw== X-Gm-Message-State: ALoCoQlkXXlYnVibUFLzwCtnTTM+89r7zu/BKGt6jztbwxCUVniqQaIFKJSVGsg6cDsbohiEZDL7S3JdyRyVryyv3Un/nNWfdWHkzuioGieSiJ4mkr6Qc4LpZTOXsTAYe4xlGUqmy5LHiJZDWkRRPeyUVpS/AZf3OpZL/aSE7++XUSCL03o51Z+cdsrsZ/aVZjykSmtRksBN X-Received: by 10.50.36.67 with SMTP id o3mr4176921igj.47.1390412911716; Wed, 22 Jan 2014 09:48:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Wed, 22 Jan 2014 09:48:09 -0800 (PST) In-Reply-To: References: <71B4A0D3-B4F2-4B3C-B38E-ED7678BEA6FE@nominum.com> From: Lorenzo Colitti Date: Thu, 23 Jan 2014 02:48:09 +0900 Message-ID: To: Matthew Petach Content-Type: multipart/alternative; boundary=089e01160174b1ddf104f092bbe2 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 17:48:35 -0000 --089e01160174b1ddf104f092bbe2 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 13, 2014 at 4:27 PM, Matthew Petach wrote: > I realize this setup isn't typical; but it's there, and I find it > odd that the reaction from the community seems to be > "people should stop trying to stretch the lifespan of > IPv4 and just move to IPv6" at the same time saying > "you should stop doing things the v4 way, and change > your mindset and topology to match the v6 way". > > The more impediments and roadblocks there > are to seamlessly converting from v4 to v6 there > are, the less incentive there is to move away from > v4, and the longer it is we'll continue to have v4-only > sites on the internet...which will continue to ensure > that the v6-only internet can never become reality. > > As long as we're OK with v6 being a cute side project, > and not a fully functional replacement for v4, that's > a fine mindset to have. But if we're serious about > wanting to move the Internet wholesale to v6, we > need to ease up a bit on this whole "If you won't > convert to the One True V6 Way, you should just > stay on v4" mantra. I get that what we're doing in > the v4 world can't currently be done in the v6 world. > What I don't understand is why there's so much > resistance to making it possible to do it in the v6 world? > Because making IPv6 look like IPv4 in every way will inevitably mean that we'll lose the advantages that IPv6 has over IPv4. I'm not talking about "QoS" or "security", which were trumpeted as advantages of IPv6 ten years ago. I'm talking about the real advantages, like network statelessness, the freedom from on-link address scarcity, dynamic renumbering, etc. At the end of the day, it's a trade-off. Do you make IPv6 look more like IPv4, in the hope that it will get deployed more quickly? Or do we stick to the design and accept some temporary migration pain for a better end result? I'm for the latter, because this thing's going to be with us for thirty years - and because making it IPv6 more like IPv4 will *not* get IPv6 deployed faster, because that's a business decision, not a technical decision. Many have said, "Where's the harm? So let's define standards to put routing in DHCP. There's no harm in making the semantics compatible with IPv4, as long as we maintain the routing in RA compatibility as well". I think these people are either underestimating the network effect or the realities of operations, "modern corporate IT staffing" (as Owen puts it), and the code and process bugs that invariably crop up when you try to do something a little different. Using the IPv4-lookalike way will always be the path of least resistance, and at the end, there will only be one way to do communicate configuration parameters to general-purpose hosts. Everything else is simply too operationally expensive. In your specific case, I'd argue that - as Ole has said - what you want to do should be 100% solved - and with better load-sharing properties than your current IPv4 design - by simply having the hosts ECMP to the four routers. If your hosts don't support that, then I would see that as an excellent use of your "as a multibillion dollar company, we can afford to pay for the features we need" cachet. Regards, Lorenzo --089e01160174b1ddf104f092bbe2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jan 13, 2014 at 4:27 PM, Matthew Petach <mpetach@netflight.com> wrote:
I realize this setup isn't typical; but it's there, an= d I find it
odd that the reaction from the community s= eems to be
"people should stop trying to stretch= the lifespan of
IPv4 and just move to IPv6" at the same time sayin= g
"you should stop doing things th= e v4 way, and change
your mindset and topology to match the v6 way".

The more impediments and roadblocks there
are to seaml= essly converting from v4 to v6 there
are, the less incentive there is to= move away from
v4, and the longer it is we'll continue to have v4-only
sites on the= internet...which will continue to ensure
that the v6-only internet can = never become reality.

As long as we= 're OK with v6 being a cute side project,
and not a fully functional replacement for v4, that's
a fine mindset= to have.=C2=A0 But if we're serious about
wanting to move the Internet wholesale to v6, we
need to ease up= a bit on this whole "If you won't
convert to the One True V6 Way, you should just
stay on v4" mantra.= =C2=A0 I get that what we're doing in
the v4 world can't current= ly be done in the v6 world.=C2=A0
What I don't understand is why th= ere's so much
resistance to making it possible to do it in the v6 world?
<= /blockquote>

Because making IPv6 look like IPv4 in every= way will inevitably mean that we'll lose the advantages that IPv6 has = over IPv4. I'm not talking about "QoS" or "security"= ;, which were trumpeted as advantages of IPv6 ten years ago. I'm talkin= g about the real advantages, like network statelessness, the freedom from o= n-link address scarcity, dynamic renumbering, etc.

At the end of the day, it's a trade-off. Do you mak= e IPv6 look more like IPv4, in the hope that it will get deployed more quic= kly? Or do we stick to the design and accept some temporary migration pain = for a better end result? I'm for the latter, because this thing's g= oing to be with us for thirty years - and because making it IPv6 more like = IPv4 will *not* get IPv6 deployed faster, because that's a business dec= ision, not a technical decision.

Many have said, "Where's the harm? So let= 's define standards to put routing in DHCP. There's no harm in maki= ng the semantics compatible with IPv4, as long as we maintain the routing i= n RA compatibility as well". I think these people are either underesti= mating the network effect or the realities of operations, "modern corp= orate IT staffing" (as Owen puts it), and the code and process bugs th= at invariably crop up when you try to do something a little different. Usin= g the IPv4-lookalike way will always be the path of least resistance, and a= t the end, there will only be one way to do communicate configuration param= eters to general-purpose hosts. Everything else is simply too operationally= expensive.

In your specific case, I'd argue that - as Ol= e has said - what you want to do should be 100% solved - and with better lo= ad-sharing properties than your current IPv4 design - by simply having the = hosts ECMP to the four routers. If your hosts don't support that, then = I would see that as an excellent use of your "as a multibillion dollar= company, we can afford to pay for the features we need" cachet.

Regards,
Lorenzo
--089e01160174b1ddf104f092bbe2-- From nick@foobar.org Wed Jan 22 10:58:39 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3471A0186 for ; Wed, 22 Jan 2014 10:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwp8-eoMeLY8 for ; Wed, 22 Jan 2014 10:58:37 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id CC79D1A011D for ; Wed, 22 Jan 2014 10:58:36 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id s0MIwTxe049190 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 22 Jan 2014 18:58:30 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host pancake.netability.ie [87.198.142.197] claimed to be crumpet.local Message-ID: <52E014C7.1090707@foobar.org> Date: Wed, 22 Jan 2014 18:58:15 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Lorenzo Colitti , Matthew Petach References: <71B4A0D3-B4F2-4B3C-B38E-ED7678BEA6FE@nominum.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 18:58:40 -0000 On 22/01/2014 17:48, Lorenzo Colitti wrote: > Because making IPv6 look like IPv4 in every way will inevitably mean that > we'll lose the advantages that IPv6 has over IPv4. I'm not talking about > "QoS" or "security", which were trumpeted as advantages of IPv6 ten years > ago. I'm talking about the real advantages, like network statelessness, the > freedom from on-link address scarcity, dynamic renumbering, etc. network statelessness may be good on your network, but it's not a good thing on my networks; apparently not Matt's either. Nor is it good for the people who've been pushing for and who now use stateful address configuration on their v6 networks. 2^64 on-link addresses per configured subnet opens up a crippling DoS vector with neighbor cache exhaustion, and should be considered an danger to functional network operation in many production situations. dynamic renumbering is a fantasy in many configuration scenarios. > At the end of the day, it's a trade-off. Do you make IPv6 look more > like IPv4, in the hope that it will get deployed more quickly? Or do we > stick to the design and accept some temporary migration pain for a > better end result? I'm for the latter, because this thing's going to be > with us for thirty years - and because making it IPv6 more like IPv4 > will *not* get IPv6 deployed faster, because that's a business decision, > not a technical decision. You've inadvertently put your finger on exactly the problem. Each network is different and requires different configuration to operate optimally. Your and other peoples' continuing efforts to block standardisation of a DHCPv6 routing option using any means possible - endless arguments and continuously shouting everyone down - do nothing to hide the reality that your viewpoint of how ipv6 ought to operate is not the only valid viewpoint out there. Going back to what you said above, a "better end result" for your network is not necessarily the same as for my network. I do not want to stop you from using RAs and SLAAC if that's what works well for you. You are the best judge to know what's good for your networks and I respect that. Conversely, I ask you to accept that there are many people - including me - who hold a considered viewpoint that routing information auto- configuration using DHCPv6 would be a good fit for our requirements and that you are not the best judge of what is or is not appropriate for our networks. Nick > > Many have said, "Where's the harm? So let's define standards to put routing > in DHCP. There's no harm in making the semantics compatible with IPv4, as > long as we maintain the routing in RA compatibility as well". I think these > people are either underestimating the network effect or the realities of > operations, "modern corporate IT staffing" (as Owen puts it), and the code > and process bugs that invariably crop up when you try to do something a > little different. Using the IPv4-lookalike way will always be the path of > least resistance, and at the end, there will only be one way to do > communicate configuration parameters to general-purpose hosts. Everything > else is simply too operationally expensive. > > In your specific case, I'd argue that - as Ole has said - what you want to > do should be 100% solved - and with better load-sharing properties than > your current IPv4 design - by simply having the hosts ECMP to the four > routers. If your hosts don't support that, then I would see that as an > excellent use of your "as a multibillion dollar company, we can afford to > pay for the features we need" cachet. > > Regards, > Lorenzo > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From lorenzo@google.com Wed Jan 22 11:25:04 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE191A013E for ; Wed, 22 Jan 2014 11:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naLA4oyBVjmY for ; Wed, 22 Jan 2014 11:25:01 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id AC3DB1A011D for ; Wed, 22 Jan 2014 11:25:01 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id uy17so14795871igb.4 for ; Wed, 22 Jan 2014 11:25:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=R1UTxPYptFiIKjJE2ThIaaUVa5gn3my4sbemgtfu/yI=; b=CP+tG4/YVgGFqhsbgZn3DyasWA3oOjEDhDf6KXAvWLP+q98Rsc7iK9+qlwA2t1+5qw szOB4ujMqHjoYoreLQYeNHjZweWiYdkcALrc80Mq8vZjKp0F8C2v5rWymGsMz/jJxBE5 NjBeOx+RN3wm3jA9FxKcL4z5kRbb+/Jqu44ZQ7bo4TjFXMt0EVF35x2oZALcJ1YNd65G ddE8qczZgNxM8GD2/CK86kkK8SJtlxm8MkN9cF4IccudFo8lGaqmr3ac8J74t2olD+qj hAOmndY4no6cK5V9PI3A1lG2SHbfgWxgzWkUpYXGcY/oVcyaYFvm2rqY4M+AMi/bRNl3 gjzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=R1UTxPYptFiIKjJE2ThIaaUVa5gn3my4sbemgtfu/yI=; b=e3w6Q+z8znO3tVRUOxTpb6bHB9gsSP7FaXhWE6+9vdAiahqgW1lvXFxiKnQJ6Z8jDR rFHCpS82TDfqtSMfivuQybj0e19LmyfBF7dTNtMFo1TZgTpYLNNc/BeCbpB8QvGVz3O0 +ofdM0je7diUedZja7Ijkx6hpzQfS+QimM69xRUCpXHOqDaILN+iwY+jWtj/75fOxApp 1EUNPtReOoZ/F6sUFNxOClHvDSqYBGGyH1J1sBzHKxqSM5sdqAWOXEmpAFX+JbnzxPFY TWfXzIoS4e4G7cdIh36mnbatPJP2gmeCEZEA3GbCAQxdvPAXaKizrBQ0NvB6zzHEVkq4 SUGg== X-Gm-Message-State: ALoCoQmILzKIbsG6UIn3t9lM1+YGqRjhMwz88/gKFOEUhVSORKQCff0lYiEThhy7wsNgoRPsqwKGCseE/24vROwoaHIIHE+4sxNZ54ZYKbSuC+oQ/VpAWgYTLF3AVOv1ZuOAzzIH2E2WZcEn2xuiVu2CIaBTSx0GqhTdjupaDur9HBi/i9k2zEwnhTLL4BoPSZ9QM+JR+dhT X-Received: by 10.43.103.5 with SMTP id dg5mr2650942icc.50.1390418700997; Wed, 22 Jan 2014 11:25:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Wed, 22 Jan 2014 11:24:40 -0800 (PST) In-Reply-To: <52E014C7.1090707@foobar.org> References: <71B4A0D3-B4F2-4B3C-B38E-ED7678BEA6FE@nominum.com> <52E014C7.1090707@foobar.org> From: Lorenzo Colitti Date: Wed, 22 Jan 2014 11:24:40 -0800 Message-ID: To: Nick Hilliard Content-Type: multipart/alternative; boundary=bcaec5171b93c3374804f09414a1 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 19:25:04 -0000 --bcaec5171b93c3374804f09414a1 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 22, 2014 at 10:58 AM, Nick Hilliard wrote: > Your and other peoples' continuing efforts to block standardisation of a > DHCPv6 routing option using any means possible - endless arguments and > continuously shouting everyone down - do nothing to hide the reality that > your viewpoint of how ipv6 ought to operate is not the only valid > viewpoint out there. > I don't think that's a useful line of reasoning. You argue that I and people like me cause endless arguments, but I could just as well argue that you and people like you are causing the endless arguments are the people who are constantly calling for the specifications to change to support their views. > Conversely, I ask you to accept that there are many people - including me - > who hold a considered viewpoint that routing information auto- > configuration using DHCPv6 would be a good fit for our requirements and > that you are not the best judge of what is or is not appropriate for our > networks. > We've been through this before. I do accept that it's better in your network (though perhaps not in Matt's; ECMP does seem a better solution). I just don't agree that standardizing routing in DHCP to make your network work better is the right tradeoff for the Internet as a whole. The way I see it, changing the standards has knock-on effects on host implementations and other networks, and I believe that if you look at the system as a whole, it will be a net loss. --bcaec5171b93c3374804f09414a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 22, 2014 at 10:58 AM, Nick Hilliard <nick@foobar.org> wrote:
Your and other peoples' continuing efforts to block=C2=A0standardisation of a DHCPv6 routing = option using any means possible -=C2=A0endless arguments and continuously shouting everyone down - do nothi= ng to=C2=A0hide the reality that= your viewpoint of how ipv6 ought to operate is not=C2=A0the only valid viewpoint out there.

I don't think that's a useful line= of reasoning. You argue that I and people like me cause endless arguments,= but I could just as well argue that you and people like you are causing th= e endless arguments are the people who are constantly calling for the speci= fications to change to support their views.
=C2=A0
Conversely, I ask you to ac= cept that there are many people - including me -
who hold a considered viewpoint that routing information auto-
configuration using DHCPv6 would be a good fit for our requirements and
that you are not the best judge of what is or is not appropriate for our networks.

We've been through this b= efore. I do accept that it's better in your network (though perhaps not= in Matt's; ECMP does seem a better solution). I just don't agree t= hat standardizing routing in DHCP to make your network work better is the r= ight tradeoff for the Internet as a whole. The way I see it, changing the s= tandards has knock-on effects on host implementations and other networks, a= nd I believe that if you look at the system as a whole, it will be a net lo= ss.
--bcaec5171b93c3374804f09414a1-- From richih.mailinglist@gmail.com Wed Jan 22 14:38:10 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8DD1A04FC for ; Wed, 22 Jan 2014 14:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYHlItpx0sZh for ; Wed, 22 Jan 2014 14:38:08 -0800 (PST) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 819F81A04F9 for ; Wed, 22 Jan 2014 14:38:08 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id t61so567944wes.35 for ; Wed, 22 Jan 2014 14:38:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=JFdhN2l6DwLzea5j/bmVf57chOnKK2AEj9reZpJ5GN4=; b=K3IDZIRaHYIiDaNDMkigeQ1XAIzUTdw6OZQdeLRNmh8YFUO1xyHTV3lE4GpE9PWlki h9DPeFrYxojq5sbPphMkn79oHuF9oIKK9O6NCc6CD021MQZJ8tbWBIRIHb3gh5V9veHd U5tzB9D5Rfl+gf1ZqDcEFwMWPq3KtThsMAx2hwaZK1IV644u9cuvQ3mU70g3wbwDNFyC Ts8Defnb5BR+8Mg/x2P5yc/OlyLwZXwLiirp2320AUjuIi3TcZY3FdHdvUrfEh1IkS5I jl9I+dcaQPjGP36E1hofywonnckJ7P1nGCC7MVpTQ6IrHHFsU/mqlCm2upZKrVoHa9Bf 5kXg== X-Received: by 10.180.189.106 with SMTP id gh10mr22022510wic.18.1390430287346; Wed, 22 Jan 2014 14:38:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.36.168 with HTTP; Wed, 22 Jan 2014 14:37:47 -0800 (PST) From: Richard Hartmann Date: Wed, 22 Jan 2014 23:37:47 +0100 Message-ID: To: IPv6 Operations Content-Type: text/plain; charset=UTF-8 Subject: [v6ops] v6-only (with NAT64) as default network during a conference? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 22:38:10 -0000 Dear all, we (FOSDEM) are currently planning details of our WiFi setup during the upcoming edition. We already decided that we would like to run one dual-stack and one v6-only network with NAT64. The question is which option should be the default. >From what I have been told, IETF, RIPE, and TREX has had conferences with v6-only default networks, but those are geared towards netop and neteng people; from what we know, we would be the first conference with a different target audience. Obviously, our primary goal is to provide infrastructure for a smooth conference experience. On the other hand, this is one of very few opportunities where we can put developers, which came together to solve and discuss issues, into a real-world v6 scenario. Prodding people to fix issues is good; making them victims of failure scenarios outside of their control... not so much. Long story short: Is this feasible today? What problems should we, or our users, anticipate? Or should we play it safe, default to dual-stack, and not have horror stories about v6 propagate? Thanks, Richard From lorenzo@google.com Wed Jan 22 14:56:55 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48041A02F0 for ; Wed, 22 Jan 2014 14:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yc_A3KOGTjqK for ; Wed, 22 Jan 2014 14:56:54 -0800 (PST) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id C337F1A01F6 for ; Wed, 22 Jan 2014 14:56:54 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id ar20so271486iec.10 for ; Wed, 22 Jan 2014 14:56:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/6Sxakuf20iuEhkPACcxlQIx/gSSwOFClbL4mXL5qI8=; b=ntyyKDSaaTZZERwlWarw6AUE9R5bBwsh05DPmqEtmTgdOqbfcgsJ3aZHvlQU4LlHQB X8oVWI9rM8JZkPGXd4jFgcSixA/kBHgg9LN11r03DuQchiKDLoc5N+VVswpVT0Cg572d keoeZpceWSDajV86EB2K9lI1szF7mFg7FHJRhL7DSgto2i+7K3QMHhkRPAkqGtCQHU9n Y4zQat3zYwnfWNP38dtni5G6H+/h1z3UQ6X9fgpo7fmc4tscVM/ZSeHMLo1ZbQeLHfhz FlbyqGPsgMkgHAAqfdVG/knn4OPZyQ/TRgP9BMO+MGW/KPSEh8Vz9Fuype0WDLiHtgRj VfEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/6Sxakuf20iuEhkPACcxlQIx/gSSwOFClbL4mXL5qI8=; b=CFsCYGeMAyW0bgGJX0a6O6D2x6NNoILzr4k2lKYjgEs1saK31dnH2GK8pqdIRqEigZ 7KNBiCZGkwwej97Abk5MFuRoOgJUOzcos6pQ3/bGogRF9DJP3QURqP2dmQIMwZ81sDWR /2kuge2dCsQGKBFJq4rPkQoxpH7+HDsGvqnv065pu3jP7vUB+bCyLSUXlELi6BX/hW10 BkMEfQo40Tly67cRuf3lEKg530nuHBgsibM+1zno8xqR7KyyjNdDPuPhXw7ObXaH2Lml skOIWy+eMJCqYDYTEwj7OXlG71f/5Z8H7bYOE9xsWlEUFHxfAeOex4tFOaYhTdGE+enT BKHw== X-Gm-Message-State: ALoCoQnyxVqk94S3m2sGa4z2litYJdihPgGvfr5hIJnRGqOIkK6YcdtkPyVT3YDHGmaZrHv6GRr91KPc0ZO8ig5thPOEXGd5QAehEcxr8ENaiLC7J1ZcEmn0+V+exLRgXx80SRx3QtGb0xwqBd/1U91vOzrbZVvriwywakHRjMnJPdIKsbOsKqkcycTn5sBXhwJC6/yqiUwo X-Received: by 10.50.36.67 with SMTP id o3mr5471273igj.47.1390431414179; Wed, 22 Jan 2014 14:56:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Wed, 22 Jan 2014 14:56:34 -0800 (PST) In-Reply-To: References: From: Lorenzo Colitti Date: Wed, 22 Jan 2014 14:56:34 -0800 Message-ID: To: Richard Hartmann Content-Type: multipart/alternative; boundary=089e0116017486fe1404f0970af0 Cc: IPv6 Operations Subject: Re: [v6ops] v6-only (with NAT64) as default network during a conference? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 22:56:56 -0000 --089e0116017486fe1404f0970af0 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 22, 2014 at 2:37 PM, Richard Hartmann < richih.mailinglist@gmail.com> wrote: > Long story short: Is this feasible today? What problems should we, or > our users, anticipate? Or should we play it safe, default to > dual-stack, and not have horror stories about v6 propagate? > I guess it depends how much breakage you're willing to accept. Browser stuff will generally be fine, but some applications (e.g., skype, various video chat apps, SIP clients, some instant messengers etc. etc.) won't work at all without IPv4. Some hosts, like Android, don't support IPv6-only networks at all. --089e0116017486fe1404f0970af0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 22, 2014 at 2:37 PM, Richard Hartmann <richih.mailingli= st@gmail.com> wrote:
Long story short: Is this feasible today? Wh= at problems should we, or
our users, anticipate? Or should we play it safe, default to
dual-stack, and not have horror stories about v6 propagate?

I guess it depends how much breakage you're willin= g to accept. Browser stuff will generally be fine, but some applications (e= .g., skype, various video chat apps, SIP clients, some instant messengers e= tc. etc.) won't work at all without IPv4. Some hosts, like Android, don= 't support IPv6-only networks at all.
--089e0116017486fe1404f0970af0-- From nick@foobar.org Wed Jan 22 15:06:23 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 641971A0192 for ; Wed, 22 Jan 2014 15:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeJ3q7N0D_uY for ; Wed, 22 Jan 2014 15:06:21 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id C1EED1A0242 for ; Wed, 22 Jan 2014 15:06:20 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id s0MN6APH051217 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 22 Jan 2014 23:06:16 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org Message-ID: <52E04EE0.8090409@foobar.org> Date: Wed, 22 Jan 2014 23:06:08 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <71B4A0D3-B4F2-4B3C-B38E-ED7678BEA6FE@nominum.com> <52E014C7.1090707@foobar.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 23:06:23 -0000 On 22/01/2014 19:24, Lorenzo Colitti wrote: > I don't think that's a useful line of reasoning. You argue that I and > people like me cause endless arguments, but I could just as well argue that > you and people like you are causing the endless arguments are the people > who are constantly calling for the specifications to change to support > their views. That's how the IETF works: people perceive a need and make a proposal and have been doing so for a dhcpv6 defgw/routing option for several years. The reason it comes up regular as rain is that many people think it's a sensible thing to do. The difference in this situation is that one way or another, what I and others are suggesting will make exactly no difference whatsoever to how you want to run your networks, because you can continue to run your networks with RAs and SLAAC unimpeded and will be able to continue to do so in future. On the other hand, your position is that we should not have this standardised component to configure our networks in the way we see fit: not now, not ever. It is incredibly frustrating to be at the receiving end of this position. > We've been through this before. I do accept that it's better in your > network (though perhaps not in Matt's; ECMP does seem a better solution). I > just don't agree that standardizing routing in DHCP to make your network > work better is the right tradeoff for the Internet as a whole. The way I > see it, changing the standards has knock-on effects on host implementations > and other networks, and I believe that if you look at the system as a > whole, it will be a net loss. The proposal in itself does not have knock-on implications. It's just a dhcp option like ntp- or dns-server, end of story. Defining a set of semantics so that it can interoperate sensibly with RAs will take a modest amount of work. draft-ietf-v6ops-dhcpv6-slaac-problem will be an important part of this. What's important is that it's completely doable. Nick From Ted.Lemon@nominum.com Wed Jan 22 17:29:20 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 094A31A02C8 for ; Wed, 22 Jan 2014 17:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kym0Tkf5fKQp for ; Wed, 22 Jan 2014 17:29:18 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id A87B01A02B9 for ; Wed, 22 Jan 2014 17:29:18 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKUuBwboOB2nQnobpllrRehGqVjqiAQEsD@postini.com; Wed, 22 Jan 2014 17:29:18 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 75DAD1B82DE for ; Wed, 22 Jan 2014 17:29:08 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 037FC190043; Wed, 22 Jan 2014 17:29:08 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Jan 2014 17:29:07 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Wed, 22 Jan 2014 20:29:05 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <24696EC9-3CC7-4518-A029-E385F1C987DD@nominum.com> References: To: Richard Hartmann X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: IPv6 Operations Subject: Re: [v6ops] v6-only (with NAT64) as default network during a conference? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 01:29:20 -0000 We've had a production quality NAT64 network at the past two IETFs, and = it's worked wonderfully. However, some things do break. In = particular, Skype doesn't work, and I've heard reports that some Cisco = VPN implementation doesn't work. I've found that OpenVPN does work, = but needs to be configured differently because it can't automatically = switch to IPv6 when IPv4 isn't available=97it has to be configured to do = one or the other. If it were up to me, I'd make NAT64 the default and let people switch = away if they can't make it work, because particularly at an open source = conference I would expect this to generate a lot of frenetic bug fixing = rather than a sad migration. In theory free operating systems ought to = do IPv6 better, but your milage may, unfortunately, vary. From ggm@algebras.org Wed Jan 22 17:36:00 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A98791A01D5 for ; Wed, 22 Jan 2014 17:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 868zxmwFsafN for ; Wed, 22 Jan 2014 17:35:59 -0800 (PST) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) by ietfa.amsl.com (Postfix) with ESMTP id 0A28B1A01B7 for ; Wed, 22 Jan 2014 17:35:59 -0800 (PST) Received: by mail-pd0-f179.google.com with SMTP id q10so1137430pdj.10 for ; Wed, 22 Jan 2014 17:35:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rXyaOxWgP2Rq/YJvObuDfAN9lPw5wl1a0Ed64EvBfiU=; b=NcW209uhmj6L69XfDqA1yty4+qLS1cSpiK5d+psbrK2aWML7qJKoZXtiNETvrLHdGk GpUPmwHelPcvFShSbKkF5vhhrwxULWgNiv5hHFN8dTbn+T4ISJZ8pgBlB3hpAnOjuzOq k8vYMBwFprtvNXmAJs2gtc0MBWr/OYRX+oiL6oeBKEhPvhoMH5v4TDPxalvzZyXIMhKs HQ/4jN7WivxG923kjRn08rEktXkyVy0T0vRpBv1rfFT/pgM3Ju3gNIZRyQHWna9f7XPr Io0uuhL46/dWuYwmsGSjK0uBtdqX1D5QxdzBXYs46aw22qtNB9u119buN4Ynsfxu0StH Kd/Q== X-Gm-Message-State: ALoCoQlXBowqbtDFTy/CdymI3jfWej5ABiUu9gkRG3g3FrTmDYqXOQlabF27lJA+wWPfcCd8RWFc MIME-Version: 1.0 X-Received: by 10.68.197.66 with SMTP id is2mr5042599pbc.96.1390440958446; Wed, 22 Jan 2014 17:35:58 -0800 (PST) Received: by 10.70.88.203 with HTTP; Wed, 22 Jan 2014 17:35:58 -0800 (PST) X-Originating-IP: [2001:dc0:a000:4:24ec:c594:e4f3:af0] In-Reply-To: <24696EC9-3CC7-4518-A029-E385F1C987DD@nominum.com> References: <24696EC9-3CC7-4518-A029-E385F1C987DD@nominum.com> Date: Thu, 23 Jan 2014 11:35:58 +1000 Message-ID: From: George Michaelson To: Ted Lemon Content-Type: multipart/alternative; boundary=e89a8ff24e8f68e65d04f0994350 Cc: IPv6 Operations Subject: Re: [v6ops] v6-only (with NAT64) as default network during a conference? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 01:36:00 -0000 --e89a8ff24e8f68e65d04f0994350 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable naively, it would be lovely if we could do what an RIR has done, and secure alternate SIM for use within a limited horizon and price point, which will do 64XLAT for those of us who have Android 4.x enabled devices. I don't know if thats possible in all places, but there are Telco's who seem to be prepared to play nice with us. I feel back in the 802.11b days, we kind of did this with the loaner-stock cards, and the emerging wifi network. otherwise yes, I agree. with some fallback proviso, making the default NAT64 would be interesting. On Thu, Jan 23, 2014 at 11:29 AM, Ted Lemon wrote: > We've had a production quality NAT64 network at the past two IETFs, and > it's worked wonderfully. However, some things do break. In particular= , > Skype doesn't work, and I've heard reports that some Cisco VPN > implementation doesn't work. I've found that OpenVPN does work, but nee= ds > to be configured differently because it can't automatically switch to IPv= 6 > when IPv4 isn't available=97it has to be configured to do one or the othe= r. > > If it were up to me, I'd make NAT64 the default and let people switch awa= y > if they can't make it work, because particularly at an open source > conference I would expect this to generate a lot of frenetic bug fixing > rather than a sad migration. In theory free operating systems ought to = do > IPv6 better, but your milage may, unfortunately, vary. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --e89a8ff24e8f68e65d04f0994350 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
naively, it would be lovely if we could do what an RIR has= done, and secure alternate SIM for use within a limited horizon and price = point, which will do 64XLAT for those of us who have Android 4.x enabled de= vices.

I don't know if thats possible in all places, but there = are Telco's who seem to be prepared to play nice with us. I feel back i= n the 802.11b days, we kind of did this with the loaner-stock cards, and th= e emerging wifi network.

otherwise yes, I agree. with some fallback proviso, mak= ing the default NAT64 would be interesting.


On Thu, Jan 23, 2014 at 11:29 AM,= Ted Lemon <ted.lemon@nominum.com> wrote:
We've had a production quality NAT64 net= work at the past two IETFs, and it's worked wonderfully. =A0 However, s= ome things do break. =A0 In particular, Skype doesn't work, and I'v= e heard reports that some Cisco VPN implementation doesn't work. =A0 I&= #39;ve found that OpenVPN does work, but needs to be configured differently= because it can't automatically switch to IPv6 when IPv4 isn't avai= lable=97it has to be configured to do one or the other.

If it were up to me, I'd make NAT64 the default and let people switch a= way if they can't make it work, because particularly at an open source = conference I would expect this to generate a lot of frenetic bug fixing rat= her than a sad migration. =A0 In theory free operating systems ought to do = IPv6 better, but your milage may, unfortunately, vary.

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--e89a8ff24e8f68e65d04f0994350-- From cb.list6@gmail.com Wed Jan 22 17:41:11 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF701A0369 for ; Wed, 22 Jan 2014 17:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ylURwkpjE2C for ; Wed, 22 Jan 2014 17:41:10 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id E13BF1A0357 for ; Wed, 22 Jan 2014 17:41:09 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id x13so962813wgg.33 for ; Wed, 22 Jan 2014 17:41:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Au9MGdDn57z/0L0nWF8rG/RfxcvDeokKQUw5vTQ+Mnc=; b=lhOdQwgNugc/vcSmCZjxFyeizpYjRbvMTggXzJTBoH197Iwair7H140pf6i+DUK+j7 sls13qVN7O2A5UwtoEA2amCnPglcAYeJANXFLncSSb5zrEitVJ/gmfJPL9lkZqfhyNcG T1exyD0pjmq7THDC79sWiPqmOZfjwEdhAJVv1ZFSsJfqtWhR+Hn6g2XYnSsP6cGsYEJY fvJBW06tWhdUGbOkWHOoC5D+V2lmyM1ACkdAHaKYesJZjgKj/bSw8Qaf0V+wxGMIJRdr 6ad2lCJi9uqBxqfhYmWCklqZC/Rf42i73SYeo1U7GxoybkhTYU3SSjyzSUvAtRwJQ5PH VCHg== MIME-Version: 1.0 X-Received: by 10.194.93.67 with SMTP id cs3mr4616228wjb.26.1390441268720; Wed, 22 Jan 2014 17:41:08 -0800 (PST) Received: by 10.194.133.169 with HTTP; Wed, 22 Jan 2014 17:41:08 -0800 (PST) Received: by 10.194.133.169 with HTTP; Wed, 22 Jan 2014 17:41:08 -0800 (PST) In-Reply-To: <24696EC9-3CC7-4518-A029-E385F1C987DD@nominum.com> References: <24696EC9-3CC7-4518-A029-E385F1C987DD@nominum.com> Date: Wed, 22 Jan 2014 17:41:08 -0800 Message-ID: From: Cb B To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7bb04c26e73a4104f099555f Cc: IPv6 Operations Subject: Re: [v6ops] v6-only (with NAT64) as default network during a conference? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 01:41:11 -0000 --047d7bb04c26e73a4104f099555f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Jan 22, 2014 5:29 PM, "Ted Lemon" wrote: > > We've had a production quality NAT64 network at the past two IETFs, and it's worked wonderfully. However, some things do break. In particular, Skype doesn't work, and I've heard reports that some Cisco VPN implementation doesn't work. I've found that OpenVPN does work, but needs to be configured differently because it can't automatically switch to IPv6 when IPv4 isn't available=97it has to be configured to do one or the other. > > If it were up to me, I'd make NAT64 the default and let people switch away if they can't make it work, because particularly at an open source conference I would expect this to generate a lot of frenetic bug fixing rather than a sad migration. In theory free operating systems ought to do IPv6 better, but your milage may, unfortunately, vary. > > +1 for nat64 default with another ssid for dual-stack. This should be a good practice for ietf, nanog, rirs, and so on. This is the obvious way of things to come given the post ipv4 run out situation we are currently living. CB _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --047d7bb04c26e73a4104f099555f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable


On Jan 22, 2014 5:29 PM, "Ted Lemon" <ted.lemon@nominum.com> wrote:
>
> We've had a production quality NAT64 network at the past two IETFs= , and it's worked wonderfully. =A0 However, some things do break. =A0 I= n particular, Skype doesn't work, and I've heard reports that some = Cisco VPN implementation doesn't work. =A0 I've found that OpenVPN = does work, but needs to be configured differently because it can't auto= matically switch to IPv6 when IPv4 isn't available=97it has to be confi= gured to do one or the other.
>
> If it were up to me, I'd make NAT64 the default and let people swi= tch away if they can't make it work, because particularly at an open so= urce conference I would expect this to generate a lot of frenetic bug fixin= g rather than a sad migration. =A0 In theory free operating systems ought t= o do IPv6 better, but your milage may, unfortunately, vary.
>
>

+1 for nat64 default with another ssid for dual-stack.=A0 Th= is should be a good practice for ietf, nanog, rirs, and so on.

This is the obvious way of things to come given the post ipv= 4 run out situation we are currently living.

CB _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--047d7bb04c26e73a4104f099555f-- From Ted.Lemon@nominum.com Wed Jan 22 17:42:41 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBBA91A0379 for ; Wed, 22 Jan 2014 17:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r18nFQkJWb0j for ; Wed, 22 Jan 2014 17:42:40 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 96C8E1A0266 for ; Wed, 22 Jan 2014 17:42:40 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUuBzkGTuzvrTGN2nCZCyePn1RDvjQ9hJ@postini.com; Wed, 22 Jan 2014 17:42:40 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id F24401B82DC for ; Wed, 22 Jan 2014 17:42:39 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id DFB0A190043; Wed, 22 Jan 2014 17:42:39 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Jan 2014 17:42:39 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Wed, 22 Jan 2014 20:42:37 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <01E2D4B2-ECB1-4601-81A2-15C5D59F42EE@nominum.com> References: <24696EC9-3CC7-4518-A029-E385F1C987DD@nominum.com> To: George Michaelson X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: IPv6 Operations Subject: Re: [v6ops] v6-only (with NAT64) as default network during a conference? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 01:42:42 -0000 On Jan 22, 2014, at 8:35 PM, George Michaelson wrote: > naively, it would be lovely if we could do what an RIR has done, and = secure alternate SIM for use within a limited horizon and price point, = which will do 64XLAT for those of us who have Android 4.x enabled = devices. I don't think doing 464XLAT is interesting on the IETF network, because = it looks just like an IPv4 NATTed network to the host (with some NAT = traversal technology potentially broken). The point of setting up an IPv6-only network is to discover what breaks, = and hopefully to get people used to using IPv6, if it mostly doesn't = break. The point of enabling NAT64 is that it is more likely to reveal = than conceal breakage, and additionally makes it possible to actually = use the network, which is still a bit difficult on the completely = v6-only network, more's the pity. From ggm@algebras.org Wed Jan 22 17:48:41 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197101A037C for ; Wed, 22 Jan 2014 17:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIMBmnbxoqY9 for ; Wed, 22 Jan 2014 17:48:36 -0800 (PST) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id 458751A03A7 for ; Wed, 22 Jan 2014 17:48:36 -0800 (PST) Received: by mail-pb0-f49.google.com with SMTP id up15so1176997pbc.36 for ; Wed, 22 Jan 2014 17:48:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PWM4jVNAt5+JHMdxOsoN5lPkjI7KRCzTWdCcor3S2xg=; b=Abd4IFAsRipDd3vSjxGdMkX5B2DTPKCjbiujwNK0iZNh4sruCgUc48XLYJ3qvO7w80 EYzBx1MXYDPaaOnGXkPJR9oxChT5uIssVSyRRcXbB3LxepIPHKM9p1XOuP/+iT4qA73G SU3Oekgt4VBEeeLW2p4heAm1XzYH14/J1ciraXbS2ek0JzOPZNuJL2BrFsHus+wpeEfq XmJ4sZl8yCGFwFrSSP+30TVaVVcG5DHJwczPWcu+mVkkahJ7ekyLCp5hlKLWCZZJXha/ aO8rdhEdxpmrmwfTxLe5iGcJdaBMZYjhvJF97eSf8DgDC5YNXdFFDlTfAtVacYI+fcuo FUwg== X-Gm-Message-State: ALoCoQnxGO+gD02nFVq0I9xhbkZndsdLiOJrpECW5MU5K25+KyOLtJjRFQLucID5i9kS0GPumkZ5 MIME-Version: 1.0 X-Received: by 10.68.189.132 with SMTP id gi4mr5077680pbc.57.1390441715747; Wed, 22 Jan 2014 17:48:35 -0800 (PST) Received: by 10.70.88.203 with HTTP; Wed, 22 Jan 2014 17:48:35 -0800 (PST) X-Originating-IP: [2001:dc0:a000:4:24ec:c594:e4f3:af0] In-Reply-To: <01E2D4B2-ECB1-4601-81A2-15C5D59F42EE@nominum.com> References: <24696EC9-3CC7-4518-A029-E385F1C987DD@nominum.com> <01E2D4B2-ECB1-4601-81A2-15C5D59F42EE@nominum.com> Date: Thu, 23 Jan 2014 11:48:35 +1000 Message-ID: From: George Michaelson To: Ted Lemon Content-Type: multipart/alternative; boundary=e89a8ff1cc028c61f404f099701b Cc: IPv6 Operations Subject: Re: [v6ops] v6-only (with NAT64) as default network during a conference? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 01:48:41 -0000 --e89a8ff1cc028c61f404f099701b Content-Type: text/plain; charset=ISO-8859-1 A good point, and diluting focus is often not useful. But I do note that mobile device access is probably the most visible uptake we have now worldwide, and its somewhat amusing how little visibility that has inside IETF. I suspect the verizon customer base aside, few of the attendees realize half or more of the room could have been using V6 on the telephony radio spectrum, given a chance. And you do note there are also risks of breakage in '(with some NAT traversal technology potentially broken).' but I take your main point: the goal is to test what breaks, and NAT64 is probably the best path to do that while keeping a useful net. Aren't the VPN failure modes you mention in the NAT64 case also plausible examples which will break in a 464XLAT case? On Thu, Jan 23, 2014 at 11:42 AM, Ted Lemon wrote: > On Jan 22, 2014, at 8:35 PM, George Michaelson wrote: > > naively, it would be lovely if we could do what an RIR has done, and > secure alternate SIM for use within a limited horizon and price point, > which will do 64XLAT for those of us who have Android 4.x enabled devices. > > I don't think doing 464XLAT is interesting on the IETF network, because it > looks just like an IPv4 NATTed network to the host (with some NAT traversal > technology potentially broken). > > The point of setting up an IPv6-only network is to discover what breaks, > and hopefully to get people used to using IPv6, if it mostly doesn't break. > The point of enabling NAT64 is that it is more likely to reveal than > conceal breakage, and additionally makes it possible to actually use the > network, which is still a bit difficult on the completely v6-only network, > more's the pity. > > --e89a8ff1cc028c61f404f099701b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
A good point, and diluting focus is often not useful. But = I do note that mobile device access is probably the most visible uptake we = have now worldwide, and its somewhat amusing how little visibility that has= inside IETF. I suspect the verizon customer base aside, few of the attende= es realize half or more of the room could have been using V6 on the telepho= ny radio spectrum, given a chance.

And you do note there are also risks of breakage in '(with some NAT tra= versal technology potentially broken).' but I take your main point: the= goal is to test what breaks, and NAT64 is probably the best path to do tha= t while keeping a useful net.

Are= n't the VPN failure modes you mention in the NAT64 case also plausible = examples which will break in a 464XLAT case?


On Thu,= Jan 23, 2014 at 11:42 AM, Ted Lemon <ted.lemon@nominum.com> wrote:
On Jan 22, 2014, at 8:35 P= M, George Michaelson <ggm@algebras.o= rg> wrote:
> naively, it would be lovely if we could do what an RIR has done, and s= ecure alternate SIM for use within a limited horizon and price point, which= will do 64XLAT for those of us who have Android 4.x enabled devices.

I don't think doing 464XLAT is interesting on the IETF network, b= ecause it looks just like an IPv4 NATTed network to the host (with some NAT= traversal technology potentially broken).

The point of setting up an IPv6-only network is to discover what breaks, an= d hopefully to get people used to using IPv6, if it mostly doesn't brea= k. =A0 The point of enabling NAT64 is that it is more likely to reveal than= conceal breakage, and additionally makes it possible to actually use the n= etwork, which is still a bit difficult on the completely v6-only network, m= ore's the pity.


--e89a8ff1cc028c61f404f099701b-- From Ted.Lemon@nominum.com Wed Jan 22 17:57:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44321A0226 for ; Wed, 22 Jan 2014 17:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duc6Q0Le0as6 for ; Wed, 22 Jan 2014 17:57:46 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id E4F4F1A0147 for ; Wed, 22 Jan 2014 17:57:45 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKUuB3GUbc30U5Q1awwOTmQxQNSZf4jtJw@postini.com; Wed, 22 Jan 2014 17:57:45 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 46E511B82DE for ; Wed, 22 Jan 2014 17:57:45 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 3F043190043; Wed, 22 Jan 2014 17:57:45 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Jan 2014 17:57:45 -0800 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Wed, 22 Jan 2014 20:57:42 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <24696EC9-3CC7-4518-A029-E385F1C987DD@nominum.com> <01E2D4B2-ECB1-4601-81A2-15C5D59F42EE@nominum.com> To: George Michaelson X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: IPv6 Operations Subject: Re: [v6ops] v6-only (with NAT64) as default network during a conference? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 01:57:46 -0000 On Jan 22, 2014, at 8:48 PM, George Michaelson wrote: > Aren't the VPN failure modes you mention in the NAT64 case also = plausible examples which will break in a 464XLAT case? It depends. Often the bug in these cases is not in the bits on the = wire, but in the way the application uses the kernel plumbing. I think = that's why 464xlat sometimes succeeds where NAT64 doesn't. From gert@Space.Net Thu Jan 23 01:09:07 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114541A0282 for ; Thu, 23 Jan 2014 01:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5oddFpLTui6 for ; Thu, 23 Jan 2014 01:09:03 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 858A51A0355 for ; Thu, 23 Jan 2014 01:09:00 -0800 (PST) Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id E615062CBB for ; Thu, 23 Jan 2014 10:08:58 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id C265E62CB8 for ; Thu, 23 Jan 2014 10:08:58 +0100 (CET) Received: (qmail 9992 invoked by uid 1007); 23 Jan 2014 10:08:58 +0100 Date: Thu, 23 Jan 2014 10:08:58 +0100 From: Gert Doering To: George Michaelson Message-ID: <20140123090858.GS40453@Space.Net> References: <24696EC9-3CC7-4518-A029-E385F1C987DD@nominum.com> <01E2D4B2-ECB1-4601-81A2-15C5D59F42EE@nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Operations Subject: Re: [v6ops] v6-only (with NAT64) as default network during a conference? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 09:09:07 -0000 Hi, On Thu, Jan 23, 2014 at 11:48:35AM +1000, George Michaelson wrote: > Aren't the VPN failure modes you mention in the NAT64 case also plausible > examples which will break in a 464XLAT case? OpenVPN will not work if you force it to use 464xlat by connecting to an IPv4 literal. OTOH, the *Android* build of OpenVPN handles automatic failover from IPv4 to IPv6 just fine, so if you point your VPN client at the server's host name, NAT64 will do it's job. So the 464xlat case is only relevant if you put an IPv4 literal into your configs, and you're not supposed to do that anyway... The issue with NAT64 and OpenVPN affects the 2.3.x releases for "classic" OSes (MacOS, Linux, Windows) - this one has no AFI failover support, so it will be "IPv4-only" or "IPv6-only", and you need to manually change the AFI used if behind a NAT64. Then it will also work. (Fixed in git master, to be released as 2.4.0 eventually) Can't say anything about Cisco VPN client or any of the other ones floating around. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From Michal.Czerwonka1@orange.com Thu Jan 23 08:24:31 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7441A0014 for ; Thu, 23 Jan 2014 08:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.735 X-Spam-Level: * X-Spam-Status: No, score=1.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQJ1Vc3-rosJ for ; Thu, 23 Jan 2014 08:24:30 -0800 (PST) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDA81A0022 for ; Thu, 23 Jan 2014 08:24:29 -0800 (PST) Received: from 10.236.62.137 (EHLO OPE10HT03.tp.gk.corp.tepenet) ([10.236.62.137]) by mailin.tpsa.pl (MOS 4.4.2a-FCS FastPath queued) with ESMTP id AWQ47081; Thu, 23 Jan 2014 17:24:23 +0100 (CET) From: =?iso-8859-2?Q?Czerwonka_Micha=B3_-_Hurt?= To: Gert Doering , George Michaelson Thread-Topic: [v6ops] v6-only (with NAT64) as default network during a conference? Thread-Index: AQHPGBrLf3I8luPKiEakYA4MfnKgfJqSe7KQ Date: Thu, 23 Jan 2014 16:24:05 +0000 Message-ID: <2D29C51862222E49B991EF64EEB0B5B745F6AEB0@OPE10MB05.tp.gk.corp.tepenet> References: <24696EC9-3CC7-4518-A029-E385F1C987DD@nominum.com> <01E2D4B2-ECB1-4601-81A2-15C5D59F42EE@nominum.com> <20140123090858.GS40453@Space.Net> In-Reply-To: <20140123090858.GS40453@Space.Net> Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2014.1.23.131219:17:8.129, ip=217.113.224.9, rules=__HAS_FROM, FROM_NAME_PHRASE, __TO_MALFORMED_2, __IMS_MSGID, __HAS_MSGID, __SANE_MSGID, __IN_REP_TO, __CT, __CT_TEXT_PLAIN, __CTE, __MIME_VERSION, __ANY_URI, __URI_NO_PATH, __FRAUD_CONTACT_NUM, SUPERLONG_LINE, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, __URI_NS, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0C0207.52E14237.01C0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32, mode=multiengine X-Junkmail-IWF: false X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0C0207.52E14237.01C0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8611fa7222258b05a7cbc49fdf4e83fe Cc: IPv6 Operations Subject: [v6ops] ODP: v6-only (with NAT64) as default network during a conference? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 16:24:31 -0000 Hi, we use 464xlat for IPv6-only access, but without DNS64 and most of problem = are gone. In this scenario CLAT+NAT64+DNS-DualStack, Cisco VPN client works fine. It = does not matter if the server is ipv4 literal or ipv4 domain. Of course NAT= -T (IPSEC/UDP) is enabled, because android-clat does not process packet of = ESP protocol.=20 BR, mcz =20 -----Wiadomo=B6=E6 oryginalna----- Od: v6ops [mailto:v6ops-bounces@ietf.org] W imieniu Gert Doering Wys=B3ano: 23 stycznia 2014 10:09 Do: George Michaelson DW: IPv6 Operations Temat: Re: [v6ops] v6-only (with NAT64) as default network during a confere= nce? Hi, On Thu, Jan 23, 2014 at 11:48:35AM +1000, George Michaelson wrote: > Aren't the VPN failure modes you mention in the NAT64 case also plausible > examples which will break in a 464XLAT case? OpenVPN will not work if you force it to use 464xlat by connecting to an IPv4 literal. OTOH, the *Android* build of OpenVPN handles automatic failover from=20 IPv4 to IPv6 just fine, so if you point your VPN client at the server's=20 host name, NAT64 will do it's job. So the 464xlat case is only relevant if you put an IPv4 literal into your configs, and you're not supposed to do that anyway... The issue with NAT64 and OpenVPN affects the 2.3.x releases for "classic" OSes (MacOS, Linux, Windows) - this one has no AFI failover support, so it will be "IPv4-only" or "IPv6-only", and you need to manually change the AFI used if behind a NAT64. Then it will also work. (Fixed in=20 git master, to be released as 2.4.0 eventually) Can't say anything about Cisco VPN client or any of the other ones floating around. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From holger.metschulat@telekom.de Thu Jan 23 08:28:01 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA2D1A001F for ; Thu, 23 Jan 2014 08:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uraHo5exkfuB for ; Thu, 23 Jan 2014 08:27:59 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id B5B541A0016 for ; Thu, 23 Jan 2014 08:27:58 -0800 (PST) From: Received: from he113497.emea1.cds.t-internal.com ([10.206.92.154]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 23 Jan 2014 17:27:18 +0100 Received: from HE111490.emea1.cds.t-internal.com ([10.206.92.87]) by HE113497.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 23 Jan 2014 17:27:17 +0100 To: Date: Thu, 23 Jan 2014 17:27:16 +0100 Thread-Topic: [v6ops] v6-only (with NAT64) as default network during a conference? Thread-Index: Ac8Xwq12U4+3y3FtTpCLjZt4rN4sBQAlFzjg Message-ID: References: In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] v6-only (with NAT64) as default network during a conference? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 16:28:01 -0000 Hello *, I've been running the v6-only WiFi scenario in our department for quite a w= hile so that colleagues can get a feeling on how well v6-only works with NA= T64. This is a good thing to showcase IPv6 with one of the "IPv4 compatibil= ity modes", but as already discussed here, some stuff will not work and you= know that right from the start, so the question is, do you want to make th= e participants aware of this right from the start, or should they discover = this themselves? One major thing I found was that some devices (especially Apple iPhone) con= sider a physical connection only "up" if the interface gets an IPv4 address= , otherwise, the OS takes the interface down and retries (scanning for a di= fferent SSID or whatever) even an IPv6 address was there. So I had to also = hand out fake IPv4 addresses to satisfy these devices, but block all IPv4 c= ommunication. Not nice. Probably you could do the same and redirect all IPv= 4 traffic to an error page telling participants what to do (of course, this= will only work with HTTP traffic). Holger -----Urspr=FCngliche Nachricht----- Von: v6ops [mailto:v6ops-bounces@ietf.org] Im Auftrag von Richard Hartmann Gesendet: Mittwoch, 22. Januar 2014 23:38 An: IPv6 Operations Betreff: [v6ops] v6-only (with NAT64) as default network during a conferenc= e? Dear all, we (FOSDEM) are currently planning details of our WiFi setup during the upc= oming edition. We already decided that we would like to run one dual-stack and one v6-only= network with NAT64. The question is which option should be the default. >From what I have been told, IETF, RIPE, and TREX has had conferences with v= 6-only default networks, but those are geared towards netop and neteng peop= le; from what we know, we would be the first conference with a different ta= rget audience. Obviously, our primary goal is to provide infrastructure for a smooth confe= rence experience. On the other hand, this is one of very few opportunities where we can put d= evelopers, which came together to solve and discuss issues, into a real-wor= ld v6 scenario. Prodding people to fix issues is good; making them victims of failure scena= rios outside of their control... not so much. Long story short: Is this feasible today? What problems should we, or our u= sers, anticipate? Or should we play it safe, default to dual-stack, and not= have horror stories about v6 propagate? Thanks, Richard _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Thu Jan 23 09:59:51 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E20DF1A0040 for ; Thu, 23 Jan 2014 09:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.036 X-Spam-Level: X-Spam-Status: No, score=-110.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1xLLBSLWJwz for ; Thu, 23 Jan 2014 09:59:47 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 601581A002F for ; Thu, 23 Jan 2014 09:59:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3132; q=dns/txt; s=iport; t=1390499986; x=1391709586; h=from:to:subject:date:message-id:mime-version; bh=3euAbA34e1TGqOFbkQ4NOUHkiPh9JQV1s443mLb49pE=; b=eqvGdzGyeTnlBs5GB3sVRzVgoZbMvIgfOGCp+CF110M4XXWt0h1bLder PCRFynFRIo4EQDDyEGlbYu3rRk1KaJjCRDI2lzTGYvMcHPYKtwwKv6nN6 H6Yi2caKRUDRaHrL3MS9kJmvsCtWX+3hcfK744NFiUsOFU//DjgbzBlZl k=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFADhY4VKtJXHA/2dsb2JhbABbgwyBDr0OFnSCLB1ICR0BgQAnBCGHd5peqyYXkiuBFASQPIExhjaSGIMtgio X-IronPort-AV: E=Sophos;i="4.95,707,1384300800"; d="asc'?scan'208";a="15038881" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-5.cisco.com with ESMTP; 23 Jan 2014 17:59:46 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0NHxkrI031224 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 23 Jan 2014 17:59:46 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.230]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Thu, 23 Jan 2014 11:59:46 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: Working Group Status Thread-Index: AQHPGGTm0UsVQXrYY0WE6tEAI/rUtw== Date: Thu, 23 Jan 2014 17:59:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: multipart/signed; boundary="Apple-Mail=_8462964B-0A54-4CB6-9109-817FD2E898AA"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Subject: [v6ops] Working Group Status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 17:59:52 -0000 --Apple-Mail=_8462964B-0A54-4CB6-9109-817FD2E898AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'm thinking through possible agendas for IETF 89. The following is = where we stand. John is working through the two drafts that have = completed WGLC.=20 As we have over the past several years, we have two requirements for a = draft to be on the f2f agenda: it must be posted or updated since the = previous IETF meeting, and it must have supportive discussion on the = mailing list. I assume that working group drafts (draft-ietf-v6ops-*) = have interest, and if they have been updated include them regardless. = Individual submissions (draft-name-v6ops-*) come and go. Consider this a call for new or updated drafts, and for discussion of = those drafts. RFC Ed Queue: MISSREF Mar 18 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat I have commented to the authors on the process of unsticking this draft, = which I think will require some level of revision. RFC Ed Queue: AUTH48 Nov 14 draft-ietf-v6ops-ra-guard-implementation IESG: Jan 13 draft-ietf-v6ops-nat64-experience Completed WGLC: Oct 6 draft-ietf-v6ops-64share Jan 12 draft-ietf-v6ops-enterprise-incremental-ipv6 Working Group Document updated since IETF: Nov 26 draft-ietf-v6ops-dhcpv6-slaac-problem Dec 6 draft-ietf-v6ops-balanced-ipv6-security Jan 13 draft-ietf-v6ops-ipv6-roaming-analysis Individual Submission to v6ops updated since IETF: Nov 4 draft-chen-v6ops-ipv6-roaming-analysis Dec 3 draft-taylor-v6ops-fragdrop Dec 24 draft-liu-v6ops-dhcpv6-slaac-guidance Dec 28 draft-byrne-v6ops-clatip Jan 11 draft-osamu-v6ops-ipv4-literal-in-url Working Group Document NOT updated since IETF: Aug 13 draft-ietf-v6ops-dc-ipv6 Aug 14 draft-ietf-v6ops-monitor-ds-ipv6 Sep 10 draft-ietf-v6ops-mobile-device-profile Oct 21 draft-ietf-v6ops-ula-usage-recommendations Individual Submission to v6ops NOT updated since IETF: Jul 30 draft-smith-v6ops-ce-dhcpv6-transparency Oct 3 draft-elkins-v6ops-ipv6-end-to-end-rt-needed Oct 3 draft-elkins-v6ops-ipv6-packet-sequence-needed Oct 3 draft-elkins-v6ops-ipv6-pdm-recommended-usage Oct 18 draft-ma-v6ops-router-test Oct 21 draft-liu-bonica-v6ops-dhcpv6-slaac-problem Oct 21 draft-moreiras-v6ops-rfc3849bis Oct 21 draft-rafiee-v6ops-iid-lifetime Oct 21 draft-sun-v6ops-openv6-address-pool-management Oct 21 draft-yang-v6ops-ipv6tran-select --Apple-Mail=_8462964B-0A54-4CB6-9109-817FD2E898AA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFS4ViPbjEdbHIsm0MRAvSVAKCt6Vqm+7FHoVjY3JN2aqJKLd851gCaA1RS 5XhzPOHpia3bQH1HPx2s1DY= =Wrul -----END PGP SIGNATURE----- --Apple-Mail=_8462964B-0A54-4CB6-9109-817FD2E898AA-- From heard@pobox.com Thu Jan 30 09:15:04 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034D71A0456 for ; Thu, 30 Jan 2014 09:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_HDRS_LCASE=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08J4EcPWxcQ4 for ; Thu, 30 Jan 2014 09:15:02 -0800 (PST) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FA11A044A for ; Thu, 30 Jan 2014 09:15:02 -0800 (PST) Received: (qmail 10795 invoked from network); 30 Jan 2014 09:14:58 -0800 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 30 Jan 2014 09:14:58 -0800 Date: Thu, 30 Jan 2014 09:14:58 -0800 (PST) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: V6OPS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Fernando Gont Subject: [v6ops] Error in draft-ietf-v6ops-ra-guard-implementation-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 17:15:04 -0000 Hello, In Section 3, bullet #3, I see: RATIONALE: [RFC6564] specifies a uniform format for IPv6 Extension Header, thus meaning that an IPv6 node can parse an IPv6 header chain even if it contains Extension Headers that are not currently supported by that node. Actually, it's NOT possible for a node to safely parse an IPv6 header chain containing Next Header values that it does not know, even with the uniform TLV format for IPv6 extension headers defined in RFC 6564. The reason for that is because unkown Next Header value could represent an upper-layer protocol rather than an extension header, so it's not safe to attempt to follow the header chain any further. The document is now in AUTH48, so it's still possible to fix the problem before it becomes and RFC. Section 2.1 of RFC 7045 does have an applicable requirement: Forwarding nodes MUST be configurable to allow packets containing unrecognised extension headers, but the default configuration MAY drop such packets. It seems to me that the proper advice for an RA-Guard implementation is to include a configuration switch that specifies whether it passes or discards packets with unknown Next Header values, probably with a default discard. Thoughts? Mike Heard From touch@isi.edu Fri Jan 31 09:34:22 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B021A042F for ; Fri, 31 Jan 2014 09:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJzOL0B0JKLO for ; Fri, 31 Jan 2014 09:34:21 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 042901A03EC for ; Fri, 31 Jan 2014 09:34:20 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s0VHXQVO017270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 31 Jan 2014 09:33:26 -0800 (PST) Message-ID: <52EBDE66.7010306@isi.edu> Date: Fri, 31 Jan 2014 09:33:26 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "C. M. Heard" , V6OPS References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Fernando Gont Subject: Re: [v6ops] Error in draft-ietf-v6ops-ra-guard-implementation-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 17:34:22 -0000 On 1/30/2014 9:14 AM, C. M. Heard wrote: > Hello, > > In Section 3, bullet #3, I see: > > RATIONALE: [RFC6564] specifies a uniform format for IPv6 Extension > Header, thus meaning that an IPv6 node can parse an IPv6 header > chain even if it contains Extension Headers that are not currently > supported by that node. > > Actually, it's NOT possible for a node to safely parse an IPv6 > header chain containing Next Header values that it does not know, > even with the uniform TLV format for IPv6 extension headers defined > in RFC 6564. The reason for that is because unkown Next Header > value could represent an upper-layer protocol rather than an > extension header, so it's not safe to attempt to follow the header > chain any further. The header chain parsing at intermediate nodes is supposed to stop before the destination option headers (from the definition of destination options RFC2460). If that rule were followed, there wouldn't be a problem. Or this RFC, AFAICT. Joe