From nobody Tue Apr 1 08:17: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 57A641A079F for ; Tue, 1 Apr 2014 08:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 wP0HZHLoR85n for ; Tue, 1 Apr 2014 08:17:45 -0700 (PDT) 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 0E8361A06F4 for ; Tue, 1 Apr 2014 08:17:45 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id ur14so4969269igb.16 for ; Tue, 01 Apr 2014 08:17:41 -0700 (PDT) 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=0afI6UUVdJyvOUD6SYm1QzdekgtRtV/+h8ssjzDW67M=; b=jlmgDe4RH6wSsPjh/WDRJkqRXhsjg2lMWtMJnF7+fBY0EXf3pjzHdUmfWm8eLBNql6 Wi/cdco/BfMZFNvFUkO4gmVHijdIfz0hQoDiF4QgSe4PijjqwQFoy4RNzslddujZPPYM MVdhc+bipZAansAy3AI1/2XeVeU22r6wjuS+ERmtV1zb83YDiK1ZKvnB6GFFxqhFJuS2 WHVzaqxvQaJOCyu6wZdrxALQSy+N2Pp7wzuCB5zbLA9MF8HFj0eHLeSKr7/gYijHtjD/ /GfCce6cmHAMSgbRa9Q3/tYT5QFymVMUS66noYVLUrGoFwDTWYSrcJL5KLOb0rFhL8zb YQmA== 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=0afI6UUVdJyvOUD6SYm1QzdekgtRtV/+h8ssjzDW67M=; b=bDAzztacnF8gwgRJ5t37HvRNpctHVKwjRSL8Pcsy2Kmw54ajwmZf6JYwkNEUCZTgvN 9yHYczp1osO1dSNcIFhCdajEITS9y/mKJkv263AAtuLJg6Zs9k7JtGJ1KGqDPFG1jnTK yOUxkwYqjNtZktpoWe7oaFzvB1J8ME9zOTKq+Ed6XTV/b27xyHiry53NuXVUZum4sqMm hcVcStt9tHuVDcfYc1b8W8207ikBemxLuB4xceyb8sXHZVv4K8lX6CLAh/BzDCtaeQJ2 6SlDNAeIyL0xhq7r7eLY8oE7PGAqmOJeKHWLUOyM0poV5Dm1dN3SuSDRp+KbtDNQ2wQr 9Tlw== X-Gm-Message-State: ALoCoQlcKEWYX2x7Kb8RNbeRFSj1v6bYNJwonO9y/Aih9xLRutiS7PIBQ+QyT7jPWcEmr0GPtrGnajNqtmnY5/AQ/MMm7K5qCZFlPl8M/JkOjjcjhkHaTtUc4saHaYfAWDhzQSJjo/bDFvYmfIAUXGb1eeC8GhmfxSQ0DchVDsjh9jSSMmnZwzN3sH9x0xB5Ukeyq/WqjQOw X-Received: by 10.43.154.67 with SMTP id ld3mr31817549icc.60.1396365461316; Tue, 01 Apr 2014 08:17:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.136 with HTTP; Tue, 1 Apr 2014 08:17:21 -0700 (PDT) In-Reply-To: <1396301680.57607.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> References: <532C6E10.1040209@gmail.com> <20140331113541.GL43641@Space.Net> <1396274911.84934.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2A958356-CDB7-442F-8440-D775476A3909@lists.zabbadoz.net> <1396277061.74347.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1396277948.18387.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <4FC37E442D05A748896589E468752CAA0CB6B201@PWN401EA160.ent.corp.bcbsm.com> <4FC37E442D05A748896589E468752CAA0CB6B595@PWN401EA160.ent.corp.bcbsm.com> <1396301680.57607.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> From: Lorenzo Colitti Date: Wed, 2 Apr 2014 00:17:21 +0900 Message-ID: To: Nalini Elkins Content-Type: multipart/alternative; boundary=001a11c2f3a44c89db04f5fcabc3 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/BOvzxYdYZ9vGAdgaSycZ8217IuU Cc: IPv6 Operations Subject: Re: [v6ops] Comcast IPv6 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, 01 Apr 2014 15:17:46 -0000 --001a11c2f3a44c89db04f5fcabc3 Content-Type: text/plain; charset=UTF-8 Good on ya John! Convincing the world that IPv6 exists, one skeptic at a time. :-) On Tue, Apr 1, 2014 at 6:34 AM, Nalini Elkins < nalini.elkins@insidethestack.com> wrote: > Guys, > > John Brzozowski of Comcast has been EXTREMELY helpful & feels that indeed > my area DOES have IPv6 service. I will have to physically go to my local > office with the modem & see what I have to do. > May have to swap out the equipment. > > Unfortunately, it will take me a day or two to get to this because I have > to actually do my day job! > > Thanks very much, John! > > Will report back on my progress. > > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --001a11c2f3a44c89db04f5fcabc3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Good on ya John!

Convincing the world t= hat IPv6 exists, one skeptic at a time. :-)


On Tue, Apr 1, 2014 at 6:34 AM, N= alini Elkins <nalini.elkins@insidethestack.com> wrote:
Guys,

John = Brzozowski of Comcast has been EXTREMELY helpful & feels that indeed my= area DOES have IPv6 service. =C2=A0 I will have to physically go to my loc= al office with the modem & see what I have to do.
May have to swap out the equ= ipment.

Unfor= tunately, it will take me a day or two to get to this because I have to act= ually do my day job!

Thanks very much, John!
=C2=A0
= Will report back on my progress.

Nalini Elkins
Inside Products, Inc.
(83= 1) 659-8360
www.insidethest= ack.com

=C2=A0

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


--001a11c2f3a44c89db04f5fcabc3-- From nobody Tue Apr 1 16:15: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 BC6701A0011; Tue, 1 Apr 2014 16:14:56 -0700 (PDT) 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 j4n1SYva5lZD; Tue, 1 Apr 2014 16:14:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 235E01A001D; Tue, 1 Apr 2014 16:14:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140401231447.18485.85226.idtracker@ietfa.amsl.com> Date: Tue, 01 Apr 2014 16:14:47 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/awiviz-rt6A7BEfFO5uvjVt9_XE Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-64share-10.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: Tue, 01 Apr 2014 23:14:57 -0000 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 : Extending an IPv6 /64 Prefix from a 3GPP Mobile Interface to a LAN link Authors : Cameron Byrne Dan Drown Ales Vizdal Filename : draft-ietf-v6ops-64share-10.txt Pages : 9 Date : 2014-04-01 Abstract: This document describes requirements for extending an IPv6 /64 prefix from a User Equipment 3GPP radio interface to a LAN link as well as two implementation examples. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-64share/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-64share-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-64share-10 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 nobody Tue Apr 1 16:20: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 9E2EF1A0020 for ; Tue, 1 Apr 2014 16:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 4beiwra4KSFq for ; Tue, 1 Apr 2014 16:20:06 -0700 (PDT) Received: from ctxmailhub.t-mobile.cz (ctxmailhub.t-mobile.cz [93.153.104.87]) by ietfa.amsl.com (Postfix) with ESMTP id AB28B1A001F for ; Tue, 1 Apr 2014 16:20:06 -0700 (PDT) From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: "v6ops@ietf.org" Date: Wed, 2 Apr 2014 01:20:00 +0200 Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-64share-10.txt Thread-Index: Ac9OAEViYUr7RAPoQqCa05Fs+hMokwAAHbeg Message-ID: <1808340F7EC362469DDFFB112B37E2FCDA33129A67@SRVHKE02.rdm.cz> References: <20140401231447.18485.85226.idtracker@ietfa.amsl.com> In-Reply-To: <20140401231447.18485.85226.idtracker@ietfa.amsl.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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2e-1o8Fu_mbIORk5n_rbUa_ih3s Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-10.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, 01 Apr 2014 23:20:08 -0000 IESG review remarks have been incorporated. Ales > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Wednesday, April 02, 2014 1:15 AM > To: i-d-announce@ietf.org > Cc: v6ops@ietf.org > Subject: [v6ops] I-D Action: draft-ietf-v6ops-64share-10.txt > > > 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 : Extending an IPv6 /64 Prefix from a > 3GPP Mobile Interface to a LAN link > Authors : Cameron Byrne > Dan Drown > Ales Vizdal > Filename : draft-ietf-v6ops-64share-10.txt > Pages : 9 > Date : 2014-04-01 > > Abstract: > This document describes requirements for extending an IPv6 > /64 prefix > from a User Equipment 3GPP radio interface to a LAN link > as well as > two implementation examples. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-64share/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-64share-10 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-64share-10 > > > 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/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops Z=E1sady komunikace, kter=E9 spole=E8nost T-Mobile Czech Republic a.s. u=BE= =EDv=E1 p=F8i sjedn=E1v=E1n=ED smluv, jsou uvedeny zde http://www.t-mobile= .cz/zasady. Nen=ED-li v z=E1sad=E1ch uvedeno jinak, nep=F8edstavuje tato zp= r=E1va kone=E8n=FD n=E1vrh na uzav=F8en=ED =E8i zm=ECnu smlouvy ani p=F8ije= t=ED takov=E9ho n=E1vrhu. The communication principles which T-Mobile Czech= Republic a.s. applies when negotiating contracts are defined here http://w= ww.t-mobile.cz/principles. Unless otherwise stated in the principles, this = message does not constitute the final offer to contract or an amendment of = a contract or acceptance of such offer. From nobody Thu Apr 3 04:28: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 A0B241A01DB for ; Thu, 3 Apr 2014 04:28:21 -0700 (PDT) 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 cCuLXqw7niyI for ; Thu, 3 Apr 2014 04:28:17 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id C80B91A01B6 for ; Thu, 3 Apr 2014 04:28:16 -0700 (PDT) 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 s33BSBgl005178 for ; Thu, 3 Apr 2014 13:28:11 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 986EC2057D9 for ; Thu, 3 Apr 2014 13:30:00 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8F82D2057C3 for ; Thu, 3 Apr 2014 13:30:00 +0200 (CEST) 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 s33BS4cA028005 for ; Thu, 3 Apr 2014 13:28:11 +0200 Message-ID: <533D45C5.6070005@gmail.com> Date: Thu, 03 Apr 2014 13:28:05 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20140401231447.18485.85226.idtracker@ietfa.amsl.com> <1808340F7EC362469DDFFB112B37E2FCDA33129A67@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCDA33129A67@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/A-GzAXmY6Bd0g-XdWz6x4Fd2biA Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-10.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: Thu, 03 Apr 2014 11:28:21 -0000 Thanks for the update. I am happy this document advances. I don't comment after a IESG review, just a few points for when time allows: - the term 'mobile network' is inconsistently used across this document and a published RFC. - the method works for _a_ SLAACed (W)LAN - it wouldnt scale beyond one such link. Alex Le 02/04/2014 01:20, Vízdal Aleš a écrit : > IESG review remarks have been incorporated. > > Ales > >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: Wednesday, April 02, 2014 1:15 AM >> To: i-d-announce@ietf.org >> Cc: v6ops@ietf.org >> Subject: [v6ops] I-D Action: draft-ietf-v6ops-64share-10.txt >> >> >> 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 : Extending an IPv6 /64 Prefix from a >> 3GPP Mobile Interface to a LAN link >> Authors : Cameron Byrne >> Dan Drown >> Ales Vizdal >> Filename : draft-ietf-v6ops-64share-10.txt >> Pages : 9 >> Date : 2014-04-01 >> >> Abstract: >> This document describes requirements for extending an IPv6 >> /64 prefix >> from a User Equipment 3GPP radio interface to a LAN link >> as well as >> two implementation examples. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-64share/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-64share-10 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-64share-10 >> >> >> 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/ >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > Zásady komunikace, které společnost T-Mobile Czech Republic a.s. užívá při sjednávání smluv, jsou uvedeny zde http://www.t-mobile.cz/zasady. Není-li v zásadách uvedeno jinak, nepředstavuje tato zpráva konečný návrh na uzavření či změnu smlouvy ani přijetí takového návrhu. The communication principles which T-Mobile Czech Republic a.s. applies when negotiating contracts are defined here http://www.t-mobile.cz/principles. Unless otherwise stated in the principles, this message does not constitute the final offer to contract or an amendment of a contract or acceptance of such offer. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From nobody Thu Apr 3 08:55: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 091F01A0212 for ; Thu, 3 Apr 2014 08:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.191 X-Spam-Level: X-Spam-Status: No, score=-98.191 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, GB_I_LETTER=-2, J_CHICKENPOX_12=0.6, MANGLED_PILL=2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 HbohDleB-L0V for ; Thu, 3 Apr 2014 08:54:51 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2EB1A0273 for ; Thu, 3 Apr 2014 08:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=440972; q=dns/txt; s=iport; t=1396540485; x=1397750085; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ztrTAw9o/j01fThnW5AYx0bBNBt3VdyEznUSsaE98g8=; b=QXjJ54fYynZIDSQQz4zhawmPZ6BOJDhY4n2ntkXC0xH3REstqxDloFmU c9SxuDa+k4vDRmwagIt8EAdhhJrSJin9qSXK2JZT93U3uPHovRobsAI18 +OYrtr7TD9HeZ+CUZMpVsogmY7VWUa4h2q00hQOOFB/H/GeyhbZ9qhQ0l s=; X-Files: mobile-network-rfcs.txt, signature.asc : 424890, 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAKWDPVOtJA2L/2dsb2JhbADKGw X-IronPort-AV: E=Sophos;i="4.97,787,1389744000"; d="asc'?txt'?scan'208";a="32632937" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-8.cisco.com with ESMTP; 03 Apr 2014 15:54:44 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s33FsifA012115 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Apr 2014 15:54:44 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.247]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Thu, 3 Apr 2014 10:54:43 -0500 From: "Fred Baker (fred)" To: Alexandru Petrescu Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-64share-10.txt Thread-Index: AQHPT1UHKnZmRwi1OEKRH2OwuwoQhA== Date: Thu, 3 Apr 2014 15:54:42 +0000 Message-ID: <29E2A37D-7C52-4105-89FA-22F7F194A492@cisco.com> References: <20140401231447.18485.85226.idtracker@ietfa.amsl.com> <1808340F7EC362469DDFFB112B37E2FCDA33129A67@SRVHKE02.rdm.cz> <533D45C5.6070005@gmail.com> In-Reply-To: <533D45C5.6070005@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_4B258988-A23B-4996-A35B-FC1E332A1AE2"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/oTiEn8zdkHb4jaFS5wD5rMSTUXg Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-10.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: Thu, 03 Apr 2014 15:55:15 -0000 --Apple-Mail=_4B258988-A23B-4996-A35B-FC1E332A1AE2 Content-Type: multipart/mixed; boundary="Apple-Mail=_BECAF02E-0E2E-46FC-85B4-D318E64B6E46" --Apple-Mail=_BECAF02E-0E2E-46FC-85B4-D318E64B6E46 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1250 On Apr 3, 2014, at 4:28 AM, Alexandru Petrescu = wrote: > Thanks for the update. >=20 > I am happy this document advances. >=20 > I don't comment after a IESG review, just a few points for when time = allows: It=92s harder to change now. Time would have allowed at an earlier date. > - the term 'mobile network' is inconsistently used across this = document > and a published RFC. I=92m not quite sure what you mean here. In this document, the term is = used twice, in the second and third paragraphs of the security = considerations section: Despite the use of temporary IPv6 addresses, the mobile network provided /64 prefix is common to all the LAN attached devices potentially concerning privacy. A nomadic device (e.g. a smartphone) provided IPv6 prefix is not a long lived one due to re-attaches caused by a device reload, traveling through loosely covered areas, etc. The network will provide a new IPv6 prefix after a successful re-attach. 3GPP mobile network capable CPEs (e.g. a router) are likely to keep the mobile network data connection up for a longer time. Some mobile networks may be re-setting the mobile network connection regularly (e.g. every 24 hours) others may not. Privacy concerned users shall take appropriate measures to not to keep their IPv6 prefixes long- lived. In both cases, the term =93mobile network=94 refers to the 3G/4G/LTE = network operated by the network provider. The provider uses a common /64 = across the devices connected to it in a cell, and those devices, whether = traditional handsets or things more similar to traditional networking = equipment but equipped with 3G/4G/LTE interfaces, might keep those = connections up for a period of time. There are 121 RFCs that use the term =93mobile network=94. Some, such as = RFC 898 (dated 1984), predate commercial use of the term, and refer more = to the packet radio experiments carried on by SRI in that timeframe. Per = RFC 1726 (Requirements for IPng, 1994), the term is used at least to = include Reference [6] discusses possible future use of IP-based networks in the US Navy's ships, planes, and shore installations. Their basic model is that each ship, plane and shore installation represents at least one IP network. The ship- and plane-based networks, obviously, are mobile as these craft move around the world. Furthermore, most, if not all, Naval surface combatants carry some aircraft (at a minimum, a helicopter or two). So, not only must there be mobile networks (the ships that move around), but there must be mobile internetworks: the ships carrying the aircraft where each aircraft has its own network, which is connected to the ship's network and the whole thing is moving. By the way, I=92m not convinced that it is accurate to say that these = were =93future=94 requirements; The use case existed in deployment at = the time. RFC 2002 uses the term to refer to a subnet in motion within a larger = fixed network, or a network of individual devices in motion: A mobile node can be a router, which is responsible for the mobility of one or more entire networks moving together, perhaps on an airplane, a ship, a train, an automobile, a bicycle, or a kayak. The nodes connected to a network served by the mobile router may themselves be fixed nodes or mobile nodes or routers. In this document, such networks are called "mobile networks=94. If you=92re referring to the now-common usage of commercial mobile = networks based on cellular radio technology, yes, those are also = referred to as =93mobile networks=94. But they are a relatively recent = group to choose the term. I=92m not sure I understand your point. That the term has been used with = multiple definitions in the RFC series? See attached. > - the method works for _a_ SLAACed (W)LAN - it wouldnt scale beyond > one such link. That comment came up in working group discussion, I believe. Since that = was the target use case, it was deemed an acceptable limitation. To = scale to multiple (W)LANs, the device and the network would need to = implement RFC 3633 or something equivalent to it. > Alex >=20 > Le 02/04/2014 01:20, V=EDzdal Ale=9A a =E9crit : >> IESG review remarks have been incorporated. >>=20 >> Ales >>=20 >>> -----Original Message----- >>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of >>> internet-drafts@ietf.org >>> Sent: Wednesday, April 02, 2014 1:15 AM >>> To: i-d-announce@ietf.org >>> Cc: v6ops@ietf.org >>> Subject: [v6ops] I-D Action: draft-ietf-v6ops-64share-10.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 : Extending an IPv6 /64 Prefix from a >>> 3GPP Mobile Interface to a LAN link >>> Authors : Cameron Byrne >>> Dan Drown >>> Ales Vizdal >>> Filename : draft-ietf-v6ops-64share-10.txt >>> Pages : 9 >>> Date : 2014-04-01 >>>=20 >>> Abstract: >>> This document describes requirements for extending an IPv6 >>> /64 prefix >>> from a User Equipment 3GPP radio interface to a LAN link >>> as well as >>> two implementation examples. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-64share/ >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-v6ops-64share-10 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-64share-10 >>>=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 >>=20 >> Z=E1sady komunikace, kter=E9 spole=E8nost T-Mobile Czech Republic = a.s. u=9E=EDv=E1 p=F8i sjedn=E1v=E1n=ED smluv, jsou uvedeny zde = http://www.t-mobile.cz/zasady. Nen=ED-li v z=E1sad=E1ch uvedeno jinak, = nep=F8edstavuje tato zpr=E1va kone=E8n=FD n=E1vrh na uzav=F8en=ED =E8i = zm=ECnu smlouvy ani p=F8ijet=ED takov=E9ho n=E1vrhu. The communication = principles which T-Mobile Czech Republic a.s. applies when negotiating = contracts are defined here http://www.t-mobile.cz/principles. Unless = otherwise stated in the principles, this message does not constitute the = final offer to contract or an amendment of a contract or acceptance of = such offer. --Apple-Mail=_BECAF02E-0E2E-46FC-85B4-D318E64B6E46 Content-Disposition: attachment; filename=mobile-network-rfcs.txt Content-Type: text/plain; name="mobile-network-rfcs.txt" Content-Transfer-Encoding: 7bit http://www.ietf.org/rfc/rfc0898.txt 0898 Gateway special interest group meeting notes. R.M. Hinden, J. Postel, M. Muuss, J.K. Reynolds. April 1984. (Format: TXT=42112 bytes) (Status: UNKNOWN) Postel: This was a presentation of the design for the gateways to be used in the advanced SAC demo experiments on network partitioning and reconstitution, and communication between intermingiling mobile networks. Much of these demonstrations will be done with packet radio units and networks. Some of the ideas are to use a gateway-centered type of addressing and double encapsulation (i.e., an extra IP header) to route datagrams. http://www.ietf.org/rfc/rfc1726.txt 1726 Technical Criteria for Choosing IP The Next Generation (IPng). C. Partridge, F. Kastenholz. December 1994. (Format: TXT=74109 bytes) (Status: INFORMATIONAL) Reference [6] discusses possible future use of IP-based networks in the US Navy's ships, planes, and shore installations. Their basic model is that each ship, plane and shore installation represents at least one IP network. The ship- and plane-based networks, obviously, are mobile as these craft move around the world. Furthermore, most, if not all, Naval surface combatants carry some aircraft (at a minimum, a helicopter or two). So, not only must there be mobile networks (the ships that move around), but there must be mobile internetworks: the ships carrying the aircraft where each aircraft has its own network, which is connected to the ship's network and the whole thing is moving. http://www.ietf.org/rfc/rfc1821.txt 1821 Integration of Real-time Services in an IP-ATM Network Architecture. M. Borden, E. Crawley, B. Davie, S. Batsell. August 1995. (Format: TXT=64466 bytes) (Status: INFORMATIONAL) In developing an integrated IP-ATM network, potential new growth areas need to be included in the planning stages. One such area is mobile networking. Under the heading of mobile networks are included satellite extensions of the ATM cloud, mobile hosts that can join an IP subnetwork at random, and a true mobile network in which all The IP-ATM real-time service environment must be extended to include mobile networks so as to allow mobile users to access the same services as fixed network users. In doing so, a number of problems exist that need to be addressed. The principle problems are that mobile networks have constrained bandwidth compared to fiber and mobile links and are less stable than fixed fiber links. The impact of these limitations affect IP and ATM differently. In introducing one or more constrained components into the ATM cloud,the effects on congestion control in the overall network are unknown. One can envision significant buffering problems when a disadvantaged user on a mobile link attempts to access information from a high speed data stream. Likewise, as ATM uses out of band signalling to set up the connection, the stability of the mobile links that may have significant fading or complete loss of connectivity could have a significant effect on ATM performance. http://www.ietf.org/rfc/rfc1853.txt 1853 IP in IP Tunneling. W. Simpson. October 1995. (Format: TXT=14803 bytes) (Status: INFORMATIONAL) The IP in IP encapsulation Protocol/Payload number 4 [RFC-1700] has long been used to bridge portions of the Internet which have disjoint capabilities or policies. This document describes implementation techniques used for many years by the Amateur Packet Radio network for joining a large mobile network, and also by early implementations of IP Security protocols. http://www.ietf.org/rfc/rfc2000.txt 2000 Internet Official Protocol Standards. J. Postel, Ed.. February 1997. (Format: TXT=121356 bytes) (Obsoletes RFC1920) (Obsoleted by RFC2200) (Status: HISTORIC) 2041 - Mobile Network Tracing http://www.ietf.org/rfc/rfc2002.txt 2002 IP Mobility Support. C. Perkins, Ed.. October 1996. (Format: TXT=193103 bytes) (Obsoleted by RFC3220) (Updated by RFC2290) (Status: PROPOSED STANDARD) A mobile node can be a router, which is responsible for the mobility of one or more entire networks moving together, perhaps on an airplane, a ship, a train, an automobile, a bicycle, or a kayak. The nodes connected to a network served by the mobile router may themselves be fixed nodes or mobile nodes or routers. In this document, such networks are called "mobile networks". A mobile router MAY act as a foreign agent and provide a foreign agent care-of address to mobile nodes connected to the mobile network. Typical routing to a mobile node via a mobile router in this case is illustrated by the following example: This example illustrated the case in which a mobile node is attached to a mobile network. That is, the mobile node is mobile with respect to the network, which itself is also mobile (here with respect to the ground). If, instead, the node is fixed with respect to the mobile network (the mobile network is the fixed node's home network), then either of two methods may be used to cause datagrams from correspondent nodes to be routed to the fixed node. Alternatively, the mobile router MAY advertise connectivity to the entire mobile network using normal IP routing protocols through a bi-directional tunnel to its own home agent. This method avoids the need for recursive tunneling of datagrams. http://www.ietf.org/rfc/rfc2041.txt 2041 Mobile Network Tracing. B. Noble, G. Nguyen, M. Satyanarayanan, R. Katz. October 1996. (Format: TXT=64688 bytes) (Status: INFORMATIONAL) Mobile Network Tracing Mobile networks are both poorly understood and difficult to experiment with. This RFC argues that mobile network tracing provides both tools to improve our understanding of wireless channels, as well as to build realistic, repeatable testbeds for mobile software and systems. The RFC is a status report on our work tracing mobile networks. Our goal is to begin discussion on a standard format for mobile network tracing as well as a testbed for mobile systems research. We present our format for collecting mobile network traces, and tools to produce from such traces analytical models of mobile network behavior. RFC 2041 Mobile Network Tracing October 1996 Trace-based approaches have proved to be of great value in areas such as file system design [2, 10, 11] and computer architecture. [1, 5, 13] Similarly, we anticipate that network tracing will prove valuable in many aspects of mobile system design and implementation. For example, detailed analyses of traces can provide insights into the behavior of mobile networks and validate predictive models. As another example, it can play an important role in stress testing and debugging by providing the opportunity to reproduce the network conditions under which a bug was originally uncovered. As a third example, it enables a system under development to be subjected to network conditions observed in distant real-life environments. As a final example, a set of traces can be used as a benchmark family for evaluating and comparing the adaptive capabilities of alternative RFC 2041 Mobile Network Tracing October 1996 Our goal in writing this RFC is to encourage the development of a widely-accepted standard format for network traces. Such standardization will allow traces to be easily shared. It will also foster the development and widespread use of trace-based benchmarks. While wireless mobile networks are the primary motivation for this work, we have made every effort to ensure that our work is applicable to other types of networks. For example, the trace format and some of the tools may be valuable in analyzing and modeling ATM networks. RFC 2041 Mobile Network Tracing October 1996 RFC 2041 Mobile Network Tracing October 1996 RFC 2041 Mobile Network Tracing October 1996 RFC 2041 Mobile Network Tracing October 1996 RFC 2041 Mobile Network Tracing October 1996 RFC 2041 Mobile Network Tracing October 1996 RFC 2041 Mobile Network Tracing October 1996 RFC 2041 Mobile Network Tracing October 1996 RFC 2041 Mobile Network Tracing October 1996 RFC 2041 Mobile Network Tracing October 1996 In this section, we describe the set of tools that have been built to date for mobile network tracing. We believe many of these tools are widely applicable to network tracing tasks, but some have particular application to mobile network tracing. We begin with an overview of the tools, their applicability, and the platforms on which they are currently supported, as well as those they are being ported to. This information is summarized in Table 4. RFC 2041 Mobile Network Tracing October 1996 RFC 2041 Mobile Network Tracing October 1996 RFC 2041 Mobile Network Tracing October 1996 RFC 2041 Mobile Network Tracing October 1996 RFC 2041 Mobile Network Tracing October 1996 RFC 2041 Mobile Network Tracing October 1996 RFC 2041 Mobile Network Tracing October 1996 RFC 2041 Mobile Network Tracing October 1996 RFC 2041 Mobile Network Tracing October 1996 The previous work most relevant to mobile network tracing falls into two camps. The first, chiefly exemplified by tcpdump [7] and the BSD Packet Filter, or BPF [8], collect network traffic data. The second, notably Delayline [6], and the later Probe/Fault Injection Tool [4], and the University of Lancaster's netowrk emulator [3], provide network modulation similar to PaM. However, tcpdump cpatures only traffic data. It records neither information concerning mobile networking devices nor mobile host location. Rather than adding seperate software components to a host running tcpdump to capture this additional data, we have chosen to follow an integrative approach to ease trace file administration. We have kept the lessons of tcpdump and BPF to heart; namely copying only the information necessary, and transferring data up to user level in batches. It may well pay to investigate either incorporating device and location information directly into BPF, or taking the flexible filtering mechanism of BPF and including it in our trace collection software. For the moment, we do not know exactly what data we will need to explore the properties of mobile networks, and therefore do not exclude any data. RFC 2041 Mobile Network Tracing October 1996 The Lancaster network emulator was designed explicitly to model mobile networks. Rather than providing per-host modulation, it uses a single, central server through which all network traffic from instrumented applications passes. While this system also does not capture all traffic into and out of a particular host, it does allow modulation based on multiple hosts sharing a single emulated medium. There is a mechanism to change the parameters of emulation between hosts, though it is fairly cumbersome. The system uses a configuration file that can be changed and re-read while the system is running. This work is very much in its infancy; we have only begun to explore the possible uses for mobile network traces. We have uncovered several areas of further work. RFC 2041 Mobile Network Tracing October 1996 Finally, we are anxious to begin exploring the properties of real- world mobile networks, and subjecting our own mobile system designs to PaM to see how they perform. We hope others can make use of our tools to do the same. RFC 2041 Mobile Network Tracing October 1996 RFC 2041 Mobile Network Tracing October 1996 RFC 2041 Mobile Network Tracing October 1996 http://www.ietf.org/rfc/rfc2099.txt 2099 Request for Comments Summary RFC Numbers 2000-2099. J. Elliott. March 1997. (Format: TXT=40763 bytes) (Status: INFORMATIONAL) 2041 Noble Oct 96 Mobile Network Tracing This RFC argues that mobile network tracing provides both tools to improve our understanding of wireless channels, as well as to build realistic, repeatable testbeds for mobile software and systems. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. http://www.ietf.org/rfc/rfc2458.txt 2458 Toward the PSTN/Internet Inter-Networking--Pre-PINT Implementations. H. Lu, M. Krishnaswamy, L. Conroy, S. Bellovin, F. Burg, A. DeSimone, K. Tewani, P. Davidson, H. Schulzrinne, K. Vishwanathan. November 1998. (Format: TXT=139100 bytes) (Status: INFORMATIONAL) Key: W3S HTTP (Web) Server W3C HTTP (Web) Client/Browser CO Central Office (Telephone Exchange) MSC Mobile Switching Center (Mobile Network Telephone Exchange) SN Service Node SSP Service Switching Point SCP Service Control Point SMS Service Management System .-.-. Internet relationship ___ PSTN Access relationship ... PSTN "core" signaling relationship http://www.ietf.org/rfc/rfc2501.txt 2501 Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations. S. Corson, J. Macker. January 1999. (Format: TXT=28912 bytes) (Status: INFORMATIONAL) There is current and future need for dynamic ad hoc networking technology. The emerging field of mobile and nomadic computing, with its current emphasis on mobile IP operation, should gradually broaden and require highly-adaptive mobile networking technology to effectively manage multihop, ad hoc network clusters which can operate autonomously or, more than likely, be attached at some point(s) to the fixed Internet. Some applications of MANET technology could include industrial and commercial applications involving cooperative mobile data exchange. In addition, mesh-based mobile networks can be operated as robust, inexpensive alternatives or enhancements to cell-based mobile network infrastructures. There are also existing and future military networking requirements for robust, IP-compliant data services within mobile wireless communication networks [1]--many of these networks consist of highly-dynamic autonomous topology segments. Also, the developing technologies of "wearable" computing and communications may provide applications for MANET technology. When properly combined with satellite-based information delivery, MANET technology can provide an extremely flexible method for establishing communications for fire/safety/rescue operations or other scenarios requiring rapidly-deployable communications with survivable, efficient dynamic networking. There are likely other applications for MANET technology which are not presently realized or envisioned by the authors. It is, simply put, improved IP-based networking technology for dynamic, autonomous wireless networks. One effect of the relatively low to moderate link capacities is that congestion is typically the norm rather than the exception, i.e. aggregate application demand will likely approach or exceed network capacity frequently. As the mobile network is often simply an extension of the fixed network infrastructure, mobile ad hoc users will demand similar services. These demands will continue to increase as multimedia computing and collaborative networking applications rise. * provides for effective operation over a wide range of mobile networking "contexts" (a context is a set of characteristics describing a mobile network and its environment); * reacts efficiently to topological changes and traffic demands while maintaining effective routing in a mobile networking context. http://www.ietf.org/rfc/rfc2626.txt 2626 The Internet and the Millennium Problem (Year 2000). P. Nesser II. June 1999. (Format: TXT=547560 bytes) (Status: INFORMATIONAL) 16.2.4 Dates in Mobile Network Tracing Records (RFC 2041) 819:: :: Domain naming convention for Internet user applications 811:: :: Hostnames Server 810:: :: DoD Internet host table specification 799:: :: Internet name domains 796:: :: Address mappings 627:: :: ASCII text file of hostnames 625:: :: On-line hostnames service 623:: :: Comments on on-line host name service 620:: :: Request for monitor host table updates 608:: :: Host names on-line 606:: :: Host names on-line 289:: :: What we hope is an official list of host names 280:: :: Draft of host names 273:: :: More on standard host names 247:: :: Proffered set of standard host names 237:: :: NIC view of standard host names 236:: :: Standard host names 233:: :: Standardization of host call letters 229:: :: Standard host names 226:: :: Standardization of host mnemonics ===================================================================== Network Management 2128:: PS:: Dial Control Management Information Base using SMIv2 2127:: PS:: ISDN Management Information Base 2124:: I:: Light-weight Flow Admission Protocol Specification Version 1.0 2108:: PS:: Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2 2096:: PS:: IP Forwarding Table MIB 2089:: I:: V2ToV1 Mapping SNMPv2 onto SNMPv1 within a bi-lingual SNMP agent 2074:: PS:: Remote Network Monitoring MIB Protocol Identifiers 2064:: E:: Traffic Flow Measurement 2063:: E:: Traffic Flow Measurement 2051:: PS:: Definitions of Managed Objects for APPC 2041:: I:: Mobile Network Tracing 2039:: I:: Applicability of Standards Track MIBs to Management of World Wide Web Servers 2037:: PS:: Entity MIB 2024:: PS:: Definitions of Managed Objects for Data Link Switching using SNMPv2 2021:: PS:: Remote Network Monitoring Management Information Base Version 2 using SMIv2 2020:: PS:: Definitions of Managed Objects for IEEE 802.12 Interfaces 2013:: PS:: SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2 2012:: PS:: SNMPv2 Management Information Base for the Transmission Control Protocol http://www.ietf.org/rfc/rfc2719.txt 2719 Framework Architecture for Signaling Transport. L. Ong, I. Rytina, M. Garcia, H. Schwarzbauer, L. Coene, H. Lin, I. Juhasz, M. Holdrege, C. Sharp. October 1999. (Format: TXT=48646 bytes) (Status: INFORMATIONAL) The term SCN is used to refer to a network that carries traffic within channelized bearers of pre-defined sizes. Examples include Public Switched Telephone Networks (PSTNs) and Public Land Mobile Networks (PLMNs). Examples of signaling protocols used in SCN include Q.931, SS7 MTP Level 3 and SS7 Application/User parts. This section provides a protocol architecture for database access, for example providing signaling between two IN nodes or two mobile network nodes. There are a number of scenarios for the protocol stacks and the functionality contained in the SIG, depending on the SS7 application. CAS Channel-Associated Signaling DSS1 Digital Subscriber Signaling INAP Intelligent Network Application Part ISEP IP Signaling End Point ISUP Signaling System 7 ISDN User Part MAP Mobile Application Part MG Media Gateway MGU Media Gateway Unit MGC Media Gateway Controller MGCU Media Gateway Controller Unit MTP Signaling System 7 Message Transfer Part PLMN Public Land Mobile Network PSTN Public Switched Telephone Network S7AP SS7 Application Part S7UP SS7 User Part SCCP SS7 Signaling Connection Control Part SCN Switched Circuit Network SEP Signaling End Point SG Signaling Gateway SIG Signaling Transport protocol stack SS7 Signaling System No. 7 TCAP Signaling System 7 Transaction Capabilities Part http://www.ietf.org/rfc/rfc2757.txt 2757 Long Thin Networks. G. Montenegro, S. Dawkins, M. Kojo, V. Magret, N. Vaidya. January 2000. (Format: TXT=112988 bytes) (Status: INFORMATIONAL) Typically, the endpoints of the wireless segment are the intermediate node and the mobile device. However, the latter may be a wireless router to a mobile network. This is also important and has applications in, for example, disaster recovery. [BPK99] Balakrishnan, H., Padmanabhan, V., Katz, R., "The effects of asymmetry on TCP performance," ACM Mobile Networks and Applications (MONET), Vol. 4, No. 3, 1999, pp. 219-241. [MNCP] Piscitello, D., Phifer, L., Wang, Y., Hovey, R., "Mobile Network Computing Protocol (MNCP)", Work in Progress. http://www.ietf.org/rfc/rfc2956.txt 2956 Overview of 1999 IAB Network Layer Workshop. M. Kaat. October 2000. (Format: TXT=36830 bytes) (Status: INFORMATIONAL) Based on the discussion of these scenarios several trends and external influences were identified which could have a large impact on the status of the network layer, such as the deployment of wireless network technologies, mobile networked devices and special purpose IP devices. http://www.ietf.org/rfc/rfc3016.txt 3016 RTP Payload Format for MPEG-4 Audio/Visual Streams. Y. Kikuchi, T. Nomura, S. Fukunaga, Y. Matsui, H. Kimata. November 2000. (Format: TXT=47070 bytes) (Obsoleted by RFC6416) (Status: PROPOSED STANDARD) MPEG-4 Visual is a visual coding standard with many new features: high coding efficiency; high error resiliency; multiple, arbitrary shape object-based coding; etc. [2]. It covers a wide range of bitrates from scores of Kbps to several Mbps. It also covers a wide variety of networks, ranging from those guaranteed to be almost error-free to mobile networks with high error rates. http://www.ietf.org/rfc/rfc3095.txt 3095 RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed. C. Bormann, C. Burmeister, M. Degermark, H. Fukushima, H. Hannu, L-E. Jonsson, R. Hakenberg, T. Koren, K. Le, Z. Liu, A. Martensson, A. Miyazaki, K. Svanbro, T. Wiebke, T. Yoshimura, H. Zheng. July 2001. (Format: TXT=368746 bytes) (Updated by RFC3759, RFC4815) (Status: PROPOSED STANDARD) Khiem Le 2-700 Mobile Networks Laboratory Nokia Research Center 6000 Connection Drive Irving, TX 75039, USA Zhigang Liu 2-700 Mobile Networks Laboratory Nokia Research Center 6000 Connection Drive Irving, TX 75039, USA Haihong Zheng 2-700 Mobile Networks Laboratory Nokia Research Center 6000 Connection Drive Irving, TX 75039, USA http://www.ietf.org/rfc/rfc3177.txt 3177 IAB/IESG Recommendations on IPv6 Address Allocations to Sites. IAB, IESG. September 2001. (Format: TXT=23178 bytes) (Obsoleted by RFC6177) (Status: INFORMATIONAL) There have been many discussions between IETF and RIR experts on the topic of IPv6 address allocation policy. This memo addresses the issue of the boundary in between the public and the private topology in the Internet, that is, how much address space should an ISP allocate to homes, small and large enterprises, mobile networks and transient customers. - Mobile networks, such as vehicles or mobile phones with an additional network interface (such as bluetooth or 802.11b) should receive a static /64 prefix to allow the connection of multiple devices through one subnet. - A single PC, with no additional need to subnet, dialing-up from a hotel room may receive its /128 IPv6 address for a PPP style connection as part of a /64 prefix. http://www.ietf.org/rfc/rfc3220.txt 3220 IP Mobility Support for IPv4. C. Perkins, Ed.. January 2002. (Format: TXT=238343 bytes) (Obsoletes RFC2002) (Obsoleted by RFC3344) (Status: PROPOSED STANDARD) A mobile node can be a router that is responsible for the mobility of one or more entire networks moving together, perhaps on an airplane, a ship, a train, an automobile, a bicycle, or a kayak. The nodes connected to a network served by the mobile router may themselves be fixed nodes or mobile nodes or routers. In this document, such networks are called "mobile networks". A mobile router MAY act as a foreign agent and provide a foreign agent care-of address to mobile nodes connected to the mobile network. Typical routing to a mobile node via a mobile router in this case is illustrated by the following example: This example illustrated the case in which a mobile node is attached to a mobile network. That is, the mobile node is mobile with respect to the network, which itself is also mobile (here with respect to the ground). If, instead, the node is fixed with respect to the mobile network (the mobile network is the fixed node's home network), then either of two methods may be used to cause datagrams from correspondent nodes to be routed to the fixed node. Alternatively, the mobile router MAY advertise connectivity to the entire mobile network using normal IP routing protocols through a bi-directional tunnel to its own home agent. This method avoids the need for nested tunneling of datagrams. http://www.ietf.org/rfc/rfc3310.txt 3310 Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA). A. Niemi, J. Arkko, V. Torvinen. September 2002. (Format: TXT=36985 bytes) (Status: INFORMATIONAL) AuC Authentication Center. The network element in mobile networks that can authorize users either in GSM or in UMTS networks. http://www.ietf.org/rfc/rfc3344.txt 3344 IP Mobility Support for IPv4. C. Perkins, Ed.. August 2002. (Format: TXT=241041 bytes) (Obsoletes RFC3220) (Obsoleted by RFC5944) (Updated by RFC4636, RFC4721) (Status: PROPOSED STANDARD) A mobile node can be a router that is responsible for the mobility of one or more entire networks moving together, perhaps on an airplane, a ship, a train, an automobile, a bicycle, or a kayak. The nodes connected to a network served by the mobile router may themselves be fixed nodes or mobile nodes or routers. In this document, such networks are called "mobile networks". A mobile router MAY act as a foreign agent and provide a foreign agent care-of address to mobile nodes connected to the mobile network. Typical routing to a mobile node via a mobile router in this case is illustrated by the following example: This example illustrated the case in which a mobile node is attached to a mobile network. That is, the mobile node is mobile with respect to the network, which itself is also mobile (here with respect to the ground). If, instead, the node is fixed with respect to the mobile network (the mobile network is the fixed node's home network), then either of two methods may be used to cause datagrams from correspondent nodes to be routed to the fixed node. Alternatively, the mobile router MAY advertise connectivity to the entire mobile network using normal IP routing protocols through a bi-directional tunnel to its own home agent. This method avoids the need for nested tunneling of datagrams. http://www.ietf.org/rfc/rfc3366.txt 3366 Advice to link designers on link Automatic Repeat reQuest (ARQ). G. Fairhurst, L. Wood. August 2002. (Format: TXT=66097 bytes) (Also BCP0062) (Status: BEST CURRENT PRACTICE) [PAR00] Parsa, C. and J. J. Garcia-Luna-Aceves, "Improving TCP Performance over Wireless Networks at the Link Layer", ACM Mobile Networks and Applications Journal, (5)1, pp. 57-71, 2000. http://www.ietf.org/rfc/rfc3398.txt 3398 Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping. G. Camarillo, A. B. Roach, J. Peterson, L. Ong. December 2002. (Format: TXT=166197 bytes) (Status: PROPOSED STANDARD) An ACM message is sent in certain situations to indicate that the call is in progress in order to satisfy ISUP timers, rather than to signify that the callee is being alerted. This occurs for example in mobile networks, where roaming can delay call setup significantly. The early ACM is sent before the user is alerted to reset T7 and start T9. An ACM is considered an 'early ACM' if the Called Party's Status Indicator is set to 00 (no indication). http://www.ietf.org/rfc/rfc3482.txt 3482 Number Portability in the Global Switched Telephone Network (GSTN): An Overview. M. Foster, T. McGarry, J. Yu. February 2003. (Format: TXT=78552 bytes) (Status: INFORMATIONAL) In addition, mobile number portability (MNP) refers to specific NP implementation in mobile networks, either as part of a broader NP implementation in the GSTN or on a stand-alone basis. Where interoperation of LNP and MNP is supported, service portability between fixed and mobile service types is possible. http://www.ietf.org/rfc/rfc3680.txt 3680 A Session Initiation Protocol (SIP) Event Package for Registrations. J. Rosenberg. March 2004. (Format: TXT=35403 bytes) (Updated by RFC6140) (Status: PROPOSED STANDARD) A common service in current mobile networks are "welcome notices". When the user turns on their phone in a foreign country, they receive a message that welcomes them to the country, and provides information on transportation services, for example. http://www.ietf.org/rfc/rfc3684.txt 3684 Topology Dissemination Based on Reverse-Path Forwarding (TBRPF). R. Ogier, F. Templin, M. Lewis. February 2004. (Format: TXT=107963 bytes) (Status: EXPERIMENTAL) Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) is a proactive, link-state routing protocol designed for mobile ad-hoc networks, which provides hop-by-hop routing along shortest paths to each destination. Each node running TBRPF computes a source tree (providing paths to all reachable nodes) based on partial topology information stored in its topology table, using a modification of Dijkstra's algorithm. To minimize overhead, each node reports only *part* of its source tree to neighbors. TBRPF uses a combination of periodic and differential updates to keep all neighbors informed of the reported part of its source tree. Each node also has the option to report additional topology information (up to the full topology), to provide improved robustness in highly mobile networks. TBRPF performs neighbor discovery using "differential" HELLO messages which report only *changes* in the status of neighbors. This results in HELLO messages that are much smaller than those of other link-state routing protocols such as OSPF. TBRPF uses a combination of periodic and differential updates to keep all neighbors informed of the reported part of its source tree. Each node also has the option to report addition topology information (up to the full topology), to provide improved robustness in highly mobile networks. Each node is required to report RT, but may report additional links, e.g., to provide increased robustness in highly mobile networks. More precisely, a node may maintain any subgraph H of TG that contains T, and report the reported subgraph RH, which consists of links (u,v) of H such that u is in RN. For example, H can equal TG, which would provide each node with the full network topology if this is done by all nodes. H can also be a biconnected subgraph that contains T, which would provide each node with two disjoint paths to each other node, if this is done by all nodes. Each node is required to report its reported subtree RT to neighbors. However, each node (independently of the other nodes) MAY report additional links, e.g., to provide increased robustness in highly mobile networks. For example, a node may compute any subgraph H of TG that contains T, and may report the "reported subgraph" RH which consists of links (u,v) of H such that u is in RN. In this case, [14] Perkins, C., Belding-Royer, E. and S. Das, "IP Flooding in Ad Hoc Mobile Networks", Work in Progress, November 2001. http://www.ietf.org/rfc/rfc3724.txt 3724 The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture. J. Kempf, R. Austein, Eds., IAB. March 2004. (Format: TXT=37206 bytes) (Status: INFORMATIONAL) Despite this constraint, the vision emerging out of the IETF working groups developing standards for mobile networking is of a largely autonomous mobile node with multiple wireless link options, among which the mobile node picks and chooses. The end node is therefore responsible for maintaining the integrity of the communication, as the end-to-end principle implies. This kind of innovative application of the end-to-end principle derives from the same basic considerations of reliability and robustness (wireless link integrity, changes in connectivity and service availability with movement, etc.) that motivated the original development of the end- to-end principle. While the basic reliability of wired links, routing, and switching equipment has improved considerably since the end-to-end principle was formalized 15 years ago, the reliability or unreliability of wireless links is governed more strongly by the basic physics of the medium and the instantaneous radio propagation conditions. http://www.ietf.org/rfc/rfc3726.txt 3726 Requirements for Signaling Protocols. M. Brunner, Ed.. April 2004. (Format: TXT=98020 bytes) (Status: INFORMATIONAL) In mobile networks, the admission control process has to cope with far more admission requests than call setups alone would generate. For example, in the GSM (Global System for Mobile communications) case, mobility usually generates an average of one to two handovers http://www.ietf.org/rfc/rfc3753.txt 3753 Mobility Related Terminology. J. Manner, Ed., M. Kojo, Ed.. June 2004. (Format: TXT=74143 bytes) (Status: INFORMATIONAL) 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2 2. General Terms . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Mobile Access Networks and Mobile Networks. . . . . . . . . . 10 4. Handover Terminology. . . . . . . . . . . . . . . . . . . . . 15 4.1. Scope of Handover . . . . . . . . . . . . . . . . . . . 16 4.2. Handover Control. . . . . . . . . . . . . . . . . . . . 17 4.3. Simultaneous connectivity to Access Routers . . . . . . 19 4.4. Performance and Functional Aspects. . . . . . . . . . . 19 4.5. Micro Diversity, Macro Diversity, and IP Diversity. . . 21 4.6. Paging, and Mobile Node States and Modes. . . . . . . . 22 4.7. Context Transfer. . . . . . . . . . . . . . . . . . . . 24 4.8. Candidate Access Router Discovery . . . . . . . . . . . 24 4.9. Types of Mobility . . . . . . . . . . . . . . . . . . . 25 5. Specific Terminology for Mobile Ad-Hoc Networking . . . . . . 26 6. Security-related Terminology. . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 8. Contributors. . . . . . . . . . . . . . . . . . . . . . . . . 28 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 10. Informative References. . . . . . . . . . . . . . . . . . . . 29 Mobile network prefix A bit string that consists of some number of initial bits of an IP address which identifies the entire mobile network within the Internet topology. All nodes in a mobile network necessarily have an address containing this prefix. 3. Mobile Access Networks and Mobile Networks In addition, we present a few basic terms on mobile networks, that is, mobile network, mobile router (MR), and mobile network node (MNN). More terminology for discussing mobile networks can be found in [13]. A more thorough discussion of mobile networks can be found in the working group documents of the NEMO Working Group. Mobile network An entire network, moving as a unit, which dynamically changes its point of attachment to the Internet and thus its reachability in the topology. The mobile network is composed of one or more IP- subnets and is connected to the global Internet via one or more Mobile Routers (MR). The internal configuration of the mobile network is assumed to be relatively stable with respect to the MR. A MR acting as a gateway between an entire mobile network and the rest of the Internet has one or more egress interface(s) and one or more ingress interface(s). Packets forwarded upstream to the rest of the Internet are transmitted through one of the MR's egress interface; packets forwarded downstream to the mobile network are transmitted through one of the MR's ingress interface. The interface of a MR attached to a link inside the mobile network. Mobile Network Node (MNN) Any node (host or router) located within a mobile network, either permanently or temporarily. A Mobile Network Node may either be a mobile node or a fixed node. Refers to the function of allowing an entire network to change its point of attachment to the Internet, and, thus, its reachability in the topology, without interrupting IP packet delivery to/from that mobile network. Thierry Ernst has provided the terminology for discussing mobile networks. MNN ............................................................ 13 MPR ............................................................. 7 MR ............................................................. 12 Macro diversity ................................................ 21 Macro mobility ................................................. 26 Make-before-break .............................................. 19 Medium Access Protocol .......................................... 7 Micro diversity ................................................ 21 Micro mobility ................................................. 26 Mobile Host .................................................... 12 Mobile Network Node ............................................ 13 Mobile Node .................................................... 12 Mobile Router .................................................. 12 Mobile network ................................................. 12 Mobile network prefix ........................................... 7 Mobile-assisted handover ....................................... 18 Mobile-controlled handover ..................................... 18 Mobile-initiated handover ...................................... 17 Mobility factor ................................................. 7 Mobility security association .................................. 27 Multipoint relay ................................................ 7 NAR ............................................................ 14 Neighbor ........................................................ 7 Neighborhood .................................................... 7 Network mobility support ....................................... 25 Network-assisted handover ...................................... 18 Network-controlled handover .................................... 18 Network-initiated handover ..................................... 17 New Access Router .............................................. 14 Next hop ........................................................ 7 PAR ............................................................ 15 Paging ......................................................... 23 Paging area .................................................... 23 Paging area registrations ...................................... 23 Paging channel ................................................. 23 Pathloss ....................................................... 20 Pathloss matrix ................................................ 27 Payload ......................................................... 8 Planned handover ............................................... 19 Prefix .......................................................... 8 Previous Access Router ......................................... 15 Pull handover .................................................. 18 Push handover .................................................. 18 Radio Cell ..................................................... 13 Registration key ............................................... 28 Roaming ........................................................ 15 Route activation ................................................ 8 Route entry ..................................................... 8 http://www.ietf.org/rfc/rfc3869.txt 3869 IAB Concerns and Recommendations Regarding Internet Research and Evolution. R. Atkinson, Ed., S. Floyd, Ed., Internet Architecture Board. August 2004. (Format: TXT=78250 bytes) (Status: INFORMATIONAL) While some of the earliest DARPA-sponsored networking research involved packet radio networks, mobile routing [IM1993] and mobile ad-hoc routing [RFC-2501] are relatively recent arrivals in the Internet, and are not yet widely deployed. The current approaches are not the last word in either of those arenas. We believe that additional research into routing support for mobile hosts and mobile networks is needed. Additional research for ad-hoc mobile hosts and mobile networks is also worthwhile. Ideally, mobile routing and mobile ad-hoc routing capabilities should be native inherent capabilities of the Internet routing architecture. This probably will require a significant evolution from the existing Internet routing architecture. (NB: The term "mobility" as used here is not limited to mobile telephones, but instead is very broadly defined, including laptops that people carry, cars/trains/aircraft, and so forth.) Topics worthy of additional research include key management techniques, such as non-hierarchical key management architectures (e.g., to support non-hierarchical trust models; see above), that are useful by ad-hoc groups in mobile networks and/or distributed computing. http://www.ietf.org/rfc/rfc3963.txt 3963 Network Mobility (NEMO) Basic Support Protocol. V. Devarapalli, R. Wakikawa, A. Petrescu, P. Thubert. January 2005. (Format: TXT=75955 bytes) (Status: PROPOSED STANDARD) This document describes the Network Mobility (NEMO) Basic Support protocol that enables Mobile Networks to attach to different points in the Internet. The protocol is an extension of Mobile IPv6 and allows session continuity for every node in the Mobile Network as the network moves. It also allows every node in the Mobile Network to be reachable while moving around. The Mobile Router, which connects the network to the Internet, runs the NEMO Basic Support protocol with its Home Agent. The protocol is designed so that network mobility is transparent to the nodes inside the Mobile Network. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of the NEMO Protocol. . . . . . . . . . . . . . . . 4 4. Message Formats. . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Binding Update. . . . . . . . . . . . . . . . . . . . . 7 4.2. Binding Acknowledgement . . . . . . . . . . . . . . . . 7 4.3. Mobile Network Prefix Option. . . . . . . . . . . . . . 8 5. Mobile Router Operation. . . . . . . . . . . . . . . . . . . 9 5.1. Data Structures . . . . . . . . . . . . . . . . . . . . 10 5.2. Sending Binding Updates . . . . . . . . . . . . . . . . 10 5.3. Receiving Binding Acknowledgements. . . . . . . . . . . 11 5.4. Error Processing . . . . . . . . . . . . . . . . . . . 12 5.4.1. Implicit Mode. . . . . . . . . . . . . . . . . . 12 5.4.2. Explicit Mode. . . . . . . . . . . . . . . . . . 12 5.5. Establishment of Bi-directional Tunnel . . . . . . . . 13 5.6. Neighbor Discovery for Mobile Router . . . . . . . . . 13 5.7. Multicast Groups for Mobile Router . . . . . . . . . . 14 5.8. Returning Home . . . . . . . . . . . . . . . . . . . . 14 6. Home Agent Operation . . . . . . . . . . . . . . . . . . . . 15 6.1. Data Structures . . . . . . . . . . . . . . . . . . . . 15 6.1.1. Binding Cache. . . . . . . . . . . . . . . . . . 15 6.1.2. Prefix Table . . . . . . . . . . . . . . . . . . 15 6.2. Mobile Network Prefix Registration . . . . . . . . . . 16 6.3. Advertising Mobile Network Reachability . . . . . . . . 17 6.4. Establishment of Bi-directional Tunnel . . . . . . . . 18 6.5. Forwarding Packets . . . . . . . . . . . . . . . . . . 18 6.6. Sending Binding Acknowledgements . . . . . . . . . . . 19 6.7. Mobile Network Prefix De-Registration . . . . . . . . . 19 7. Modifications to Dynamic Home Agent Address Discovery. . . . 20 7.1. Modified Dynamic Home Agent Discovery Request . . . . . 20 7.2. Modified Dynamic Home Agent Discovery Address Request . 20 7.3. Modified Home Agent Information Option . . . . . . . . 21 8. Support for Dynamic Routing Protocols. . . . . . . . . . . . 22 9. Security Considerations. . . . . . . . . . . . . . . . . . . 23 10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 24 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 A. Examples of NEMO Basic Support Operation. . . . . . . . . 27 B. Running Link State Routing Protocol with NEMO Basic Support . . . . . . . . . . . . . . . . . . . . . . . . . 30 B.1. Tunnel Interface Considerations. . . . . . . . . . . 30 B.2. OSPF Area Considerations . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 33 The NEMO Basic Support ensures session continuity for all the nodes in the Mobile Network, even as the Mobile Router changes its point of attachment to the Internet. It also provides connectivity and reachability for all nodes in the Mobile Network as it moves. The solution supports both mobile nodes and hosts that do not support mobility in the Mobile Network. All traffic between the nodes in the Mobile Network and Correspondent Nodes passes through the Home Agent. This document does not describe route optimization of this traffic. The terminology document [10] describes Nested Mobility as a scenario where a Mobile Router allows another Mobile Router to attach to its Mobile Network. There could be arbitrary levels of nested mobility. The operation of each Mobile Router remains the same whether the Mobile Router attaches to another Mobile Router or to a fixed Access Router on the Internet. The solution described here does not place any restriction on the number of levels for nested mobility. But note that this might introduce significant overhead on the data packets as each level of nesting introduces another IPv6 header encapsulation. Mobile Network Prefix An IPv6 prefix delegated to a Mobile Router and advertised in the Mobile Network. More than one Mobile Network Prefix could be advertised in a Mobile Network. A list of Mobile Network Prefixes indexed by the Home Address of a Mobile Router. The Home Agent manages and uses Prefix Table to determine which Mobile Network Prefixes belong to a particular Mobile Router. A Mobile Network is a network segment or subnet that can move and attach to arbitrary points in the routing infrastructure. A Mobile Network can only be accessed via specific gateways called Mobile Routers that manage its movement. Mobile Networks have at least one Mobile Router serving them. A Mobile Router does not distribute the Mobile Network routes to the infrastructure at its point of attachment (i.e., in the visited network). Instead, it maintains a bi-directional tunnel to a Home Agent that advertises an aggregation of Mobile Networks to the infrastructure. The Mobile Router is also the default gateway for the Mobile Network. A Mobile Network can also comprise of multiple and nested subnets. A router without mobility support may be permanently attached to a Mobile Network for local distribution. Also, Mobile Routers may be attached to Mobile Networks owned by different Mobile Routers and may form a graph. In particular, with Basic NEMO Support, each Mobile Router is attached to another Mobile Network by a single interface. If loops are avoided, the graph is a tree. Router can have more than one Home Address if there are multiple prefixes in the home link. The Mobile Router also advertises one or more prefixes in the Mobile Network attached to it. The actual mechanism for assigning these prefixes to a given Mobile Router is outside the scope of this specification. When the Mobile Router moves away from the home link and attaches to a new access router, it acquires a Care-of Address from the visited link. The Mobile Router can at any time act either as a Mobile Host or as a Mobile Router. It acts as a Mobile Host as defined in [1] for sessions it originates and provides connectivity to the Mobile Network. As soon as the Mobile Router acquires a Care-of Address, it immediately sends a Binding Update to its Home Agent as described in [1]. When the Home Agent receives this Binding Update, it creates a cache entry binding the Mobile Router's Home Address to its Care-of Address at the current point of attachment. If the Mobile Router seeks to act as a Mobile Router and provide connectivity to nodes in the Mobile Network, it indicates this to the Home Agent by setting a flag (R) in the Binding Update. It MAY also include information about the Mobile Network Prefix in the Binding Update by using one of the modes described in section 5.2, so that the Home Agent can forward packets meant for nodes in the Mobile Network to the Mobile Router. A new Mobility Header Option for carrying prefix information is described in section 4.3. If the Mobile Network has more than one IPv6 prefix and wants the Home Agent to setup forwarding for all of these prefixes, it includes multiple prefix information options in a single Binding Update. The Home Agent sets up forwarding for each of these prefixes to the Mobile Router's Care-of Address. In some scenarios the Home Agent would already know which prefixes belong to a Mobile Router by an alternate mechanism such as static configuration. In these scenarios, the Mobile Router does not include any prefix information in the Binding Update. The Home Agent sets up forwarding for all prefixes owned by the Mobile Router when it receives a Binding Update from the Mobile Router with the Mobile Router Flag (R) set. The Home Agent acknowledges the Binding Update by sending a Binding Acknowledgement to the Mobile Router. A positive acknowledgement with the Mobile Router Flag (R) set means that the Home Agent has set up forwarding for the Mobile Network. Once the binding process finishes, a bi-directional tunnel is established between the Home Agent and the Mobile Router. The tunnel end points are the Mobile Router's Care-of Address and the Home Agent's address. If a packet with a source address belonging to the Mobile Network Prefix is received from the Mobile Network, the Mobile Router reverse-tunnels the packet to the Home Agent through this tunnel. This reverse- tunneling is done by using IP-in-IP encapsulation [3]. The Home When a Correspondent Node sends a data packet to a node in the Mobile Network, the packet is routed to the Home Agent that currently has the binding for the Mobile Router. The Mobile Router's network prefix would be aggregated at the Home Agent, which would advertise the resulting aggregation. Alternatively, the Home Agent may receive the data packets destined to the Mobile Network by advertising routes to the Mobile Network Prefix. The actual mechanism by which these routes are advertised is outside the scope of this document. When the Home Agent receives a data packet meant for a node in the Mobile Network, it tunnels the packet to the Mobile Router's current Care-of Address. The Mobile Router decapsulates the packet and forwards it onto the interface where the Mobile Network is connected. Before decapsulating the tunneled packet, the Mobile Router has to check whether the Source address on the outer IPv6 header is the Home Agent's address. This check is not necessary if the packet is protected by IPsec in tunnel mode. The Mobile Router also has to make sure that the destination address on the inner IPv6 header belongs to a prefix used in the Mobile Network before forwarding the packet to the Mobile Network. If it does not, the Mobile Router should drop the packet. The Mobile Network could include nodes that do not support mobility and nodes that do. A node in the Mobile Network can also be a fixed or a Mobile Router. The protocol described here ensures complete transparency of network mobility to the nodes in the Mobile Network. Mobile Nodes that attach to the Mobile Network treat it as a normal IPv6 access network and run the Mobile IPv6 protocol. The Mobile Router and the Home Agent can run a routing protocol through the bi-directional tunnel. In this case, the Mobile Router need not include prefix information in the Binding Update. Instead, the Home Agent uses the routing protocol updates to set up forwarding for the Mobile Network. When the routing protocol is running, the bi-directional tunnel must be treated as a tunnel interface. The tunnel interface is included in the list of interfaces on which routing protocol is active. The Mobile Router should be configured not to send any routing protocol messages on its egress interface when it is away from the home link and connected to a visited link. Finally, the Home Agent may be configured with static routes to the Mobile Network Prefix via the Mobile Router's Home Address. In this case, the routes are set independently of the binding flows and the returning home of a Mobile Router. The benefit is that such movement does not induce additional signalling in the form of routing updates The Mobile Router Flag is set to indicate to the Home Agent that the Binding Update is from a Mobile Router. If the flag is set to 0, the Home Agent assumes that the Mobile Router is behaving as a Mobile Node, and it MUST NOT forward packets destined for the Mobile Network to the Mobile Router. 4.3. Mobile Network Prefix Option The Mobile Network Prefix Option is included in the Binding Update to indicate the prefix information for the Mobile Network to the Home Agent. There could be multiple Mobile Network Prefix Options if the Mobile Router has more than one IPv6 prefix in the Mobile Network and wants the Home Agent to forward packets for each of these prefixes to the Mobile Router's current location. The Mobile Network Prefix Option has an alignment requirement of 8n+4. Its format is as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Mobile Network Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Mobile Network Prefix A sixteen-byte field containing the Mobile Network Prefix maintains forwarding information related to prefixes assigned to the Mobile Network. The distinction between the two modes is represented by the value of the Mobile Router Flag (R). In this mode, the Mobile Router does not include a Mobile Network Prefix Option in the Binding Update. The Home Agent can use any mechanism (not defined in this document) to determine the Mobile Network Prefix(es) owned by the Mobile Router and to set up forwarding for the Mobile Network. One example would be manual configuration at the Home Agent mapping the Mobile Router's Home Address to the information required for setting up forwarding for the Mobile Network. In this mode, the Mobile Router includes one or more Mobile Network Prefix Options in the Binding Update. These options contain information about the Mobile Network Prefix(es) configured on the Mobile Network. If the Mobile Router has a valid binding cache entry at the Home Agent, subsequent Binding Updates for the same Home Address should have the same value as the value in the binding cache for the Mobile Router Flag (R). In explicit mode, the Mobile Router MUST include prefix information in all Binding Updates, including those sent to refresh existing binding cache entries, if it wants forwarding enabled for the corresponding Mobile Network Prefixes. The Mobile Router receives Binding Acknowledgements from the Home Agent corresponding to the Binding Updates it sent. If the Binding Acknowledgement status is set to 0 (Binding Update accepted) and the Mobile Router Flag (R) is set to 1, the Mobile Router assumes that the Home Agent has successfully processed the Binding Update and has set up forwarding for the Mobile Network. The Mobile Router can then start using the bi-directional tunnel to reverse-tunnel traffic from the Mobile Network. If the Mobile Router Flag (R) is not set, then the Mobile Router concludes that its current Home Agent does not support Mobile Routers and it performs Dynamic Home Agent Address Discovery again to discover Home Agents that do. The Mobile Router MUST also de-register with the Home Agent that did not support it before attempting registration with another. home link. If no Home Agent replies positively, then the Mobile Router SHOULD refrain from sending Binding Updates to any Home Agent on the home link. The Mobile Router MUST also stop advertising the prefix in the Mobile Network and try to obtain new IPv6 prefix information for the Mobile Network. It would do this by the same means that it initially got assigned the current Mobile Network Prefix. Alternatively, the Mobile Router MAY send Binding Updates in Implicit mode to a Home Agent on the same home link. The bi-directional tunnel between the Mobile Router and the Home Agent allows packets to flow in both directions, while the Mobile Router is connected to a visited link. The bi-directional tunnel is created by merging two unidirectional tunnels, as described in RFC 2473 [3]. The tunnel from the Mobile Router to the Home Agent has the Care-of address of the Mobile Router as the tunnel entry point and the Home Agent's address as the tunnel exit point. The tunnel from the Home Agent to the Mobile Router has the Home Agent's address and the Mobile Router's Care-of Address as the tunnel entry point and exit point, respectively. All IPv6 traffic to and from the Mobile Network is sent through this bi-directional tunnel. When the Mobile Router sends a de-registration Binding Update in Explicit mode, it SHOULD NOT include any Mobile Network Prefix options in the Binding Update. When the Home Agent removes a binding cache entry, it deletes all associated Mobile Network Prefix routes. The Home Agent might need to store the Mobile Network Prefixes associated with a Mobile Router in the corresponding Binding Cache Entry. This is required if the Binding Update that created the Binding Cache Entry contained explicit prefix information. This information can be used later to clean up routes installed in explicit mode, when the Binding Cache Entry is removed, and to maintain the routing table, for instance, should the routes be removed manually. The Home Agent SHOULD be able to prevent a Mobile Router from claiming Mobile Network Prefixes belonging to another Mobile Router. The Home Agent can prevent such attacks if it maintains a Prefix Table and verifies the prefix information provided by the Mobile Router against Prefix Table entries. The Prefix Table SHOULD be used by the Home Agent when it processes a Binding Update in explicit mode. It is not required when a dynamic routing protocol is run between the Mobile Router and the Home Agent. - The Mobile Network Prefix of the Mobile Router associated with the Home Address. 6.2. Mobile Network Prefix Registration - The Home Registration (H) Flag MUST be set. If it is not, the Home Agent MUST reject the Binding Update and send a Binding Acknowledgement with status set to 140. Note: The basic support does not allow sending a Binding Update for a Mobile Network Prefix to correspondent nodes (for route optimization). If the Lifetime specified in the Binding Update is 0 or the specified Care-of address matches the Home Address in the Binding Update, then this is a request to delete the cached binding for the home address and specified Mobile Network Prefixes. The Binding Update is processed as described in section 6.7. If the Home Agent does not reject the Binding Update as invalid, and if a dynamic routing protocol is not run between the Home Agent and the Mobile Router as described in section 8, then the Home Agent retrieves the Mobile Network Prefix information as described below. - If a Mobile Network Prefix Option is present in the Binding Update, the prefix information for the Mobile Network Prefix is retrieved from the Mobile Network Prefix field and the Prefix Length field of the option. If the Binding Update contains more than one option, the Home Agent MUST set up forwarding for all the Mobile Network Prefixes. If the Home Agent fails to set up forwarding to all the prefixes listed in the Binding Update, then - If there is no option in the Binding Update carrying prefix information, the Home Agent uses manual pre-configured information to determine the prefixes assigned to the Mobile Router and to set up forwarding for the Mobile Network. If there is no information that the Home Agent can use, it MUST reject the Binding Update and send a Binding Acknowledgement with status set to 143 (Forwarding Setup failed). If the Home Agent has a valid binding cache entry for the Mobile Router, it should compare the list of prefixes in the Binding Update against the prefixes stored in the binding cache entry. If the binding cache entry contains prefixes that do not appear in the Binding Update, the Home Agent MUST disable forwarding for these Mobile Network Prefixes. The Home Agent also creates a bi-directional tunnel to the Mobile Router for the requested Mobile Network Prefix or updates an existing bi-directional tunnel as described in section 6.4. 6.3. Advertising Mobile Network Reachability To receive packets meant for the Mobile Network, the Home Agent advertises reachability to the Mobile Network. If the Home Link is configured with an aggregated prefix and the Mobile Network Prefix is aggregated under that prefix, then the routing changes related to the Mobile Network may be restricted to the Home Link. If the Home Agent is the only default router on the Home Link, routes to the Mobile Network Prefix are aggregated naturally under the Home Agent, which does not have to do anything special. - The Home Agent can tunnel packets meant for the Mobile Network prefix to the Mobile Router's current location, the Care-of Address. When the Home Agent receives a data packet destined for the Mobile Network, it MUST forward the packet to the Mobile Router through the bi-directional tunnel. The Home Agent uses either the routing table, the Binding Cache, or a combination to route packets to the Mobile Network. This is implementation specific. Two examples are shown below. 1. The Home Agent maintains a route to the Mobile Network Prefix with the next hop set to the Mobile Router's Home Address. When the Home Agent tries to forward the packet to the next hop, it finds a binding cache entry for the home address. Then the Home Agent extracts the Mobile Router's Care-of address and tunnels the packet to the Care-of address. 2. The Home Agent maintains a route to the Mobile Network Prefix with the outgoing interface set to the bi-directional tunnel interface between the Home Agent and the Mobile Router. For this purpose, the Home Agent MUST treat this tunnel as a tunnel interface. When the packets are forwarded through the tunnel interface, they are encapsulated automatically, with the source address and The Home Agent sets the status code in the Binding Acknowledgement to 0 (Binding Update accepted) to indicate to the Mobile Router that it successfully processed the Binding Update. It also sets the Mobile Router Flag (R) to indicate to the Mobile Router that it has set up forwarding for the Mobile Network. The Home Agent sets the status code to 143 (Forwarding Setup failed) if it is unable to determine the information needed to set up forwarding for the Mobile Network. This is used in the Implicit mode, in which the Mobile Router does not include any prefix information in the Binding Update. 6.7. Mobile Network Prefix De-registration In addition, the Home Agent removes the bi-directional tunnel and stops forwarding packets to the Mobile Network. The Home Agent should keep all necessary information to clean up whichever routes it installed, whether they come from an implicit or explicit source. In Explicit mode, the Home Agent MUST ignore any Mobile Network Prefix Options present in the de-registration Binding Update. In the solution described so far, forwarding to the Mobile Network at the Home Agent is set up when the Home Agent receives a Binding Update from the Mobile Router. An alternative to this is for the Home Agent and the Mobile Router to run an intra-domain routing protocol such as RIPng [12] and OSPF [13] through the bi-directional tunnel. The Mobile Router can continue running the same routing protocol that it ran when attached to the home link. This feature is very useful when the Mobile Network is large with multiple subnets containing different IPv6 prefixes. Routing changes in the Mobile Network are quickly propagated to the Home Agent. Routing changes in the home link are quickly propagated to the Mobile Router. When the Mobile Router is attached to the home link, it runs a routing protocol by sending routing updates through its egress interface. When the Mobile Router moves and attaches to a visited network, it should stop sending routing updates on the interface by which it attaches to the visited link. This reduces the chances that prefixes specific to the Mobile Network will be leaked to the visited network if routing protocol authentication is not enabled in the visited network and in the Mobile Network. It is expected that normal deployment practices will include proper authentication mechanisms to prevent unauthorized route announcements on both the home and visited networks. The Mobile Router then starts sending routing protocol messages through the bi-directional tunnel toward the Home Agent. Most routing protocols use link-local addresses as source addresses for the routing information messages. The Mobile Router is allowed to use link-local addresses for the inner IPv6 header of an encapsulated packet. But these MUST NOT be forwarded to another link by either the Mobile Router or the Home Agent. When the Mobile Router and the Home Agent exchange routes through a dynamic routing protocol, the Mobile Router SHOULD NOT include Mobile Network Prefixes in the Binding Update to the Home Agent. Depending on its configuration, the Home Agent might not add routes based on the prefix information in the Binding Updates and might use only the routing protocol updates. Moreover, including prefix information in both the Binding Updates and the routing protocol updates is redundant. The Mobile Router has to perform ingress filtering on packets received from the Mobile Network to ensure that nodes in the Mobile Network do not use the bi-directional tunnel to launch IP spoofing attacks. In particular, the Mobile Router SHOULD check that the IP source addresses in the packets received belong to the Mobile Network Prefix and are not the same as one of the addresses used by the Mobile Router. If the Mobile Router receives an IP-in-IP tunneled packet from a node in the Mobile Network and it has to forward the decapsulated packet, it SHOULD perform the above mentioned checks on the source address of the inner packet. The Home Agent has to verify that packets received through the bi- directional tunnel belong to the Mobile Network. This check is necessary to prevent nodes from using the Home Agent to launch attacks that would have otherwise been prevented by ingress filtering. The source address of the outer IPv6 header MUST be set to the Mobile Router's current Care-of Address. The source address of the inner IPv6 header MUST be topologically correct with respect to the IPv6 prefixes used in the Mobile Network. If the Mobile Router sends a Binding Update with a one or more Mobile Network Prefix options, the Home Agent MUST be able to verify that the Mobile Router is authorized for the prefixes before setting up forwarding for the prefixes. This document defines a new Mobility Header Option, the Mobile Network Prefix Option as described in section 4.3. The type value for this option MUST be assigned from the same space used by the mobility options defined in [1]. Souhwan Jung, Fan Zhao, S. Felix Wu, HyunGon Kim, and SungWon Sohn are acknowledged for identifying threats related to tunneling between the Mobile Network and the Home Agent. This section tries to illustrate the NEMO protocol by using a Mobile Router and a Mobile Node belonging to different administrative domains. The Mobile Router's Mobile Network consists of a Local Fixed Node (LFN) and a Local Fixed Router (LFR) [10]. The LFR has an access link to which other Mobile Nodes or Mobile Routers could attach. The Mobile Router then moves away from the home link and attaches to a visited link. This is shown in Figure 2. The Mobile Router sends a Binding Update to HA_MR when it attaches to a visited link and configures a Care-of Address. HA_MR creates a binding cache entry for the Mobile Router's Home Address and also sets up forwarding for the prefixes on the Mobile Network. Figure 3 shows the Mobile Node moving away from its home link and attaching to the Mobile Router. The Mobile Node configures a Care-of Address from the prefix advertised on the Mobile Network and sends a Binding Update to its Home Agent (HA_MN) and to its Correspondent Node (CN_MN). Both HA_MN and CN_MN create binding cache entries for the Mobile Node's Home Address. One disadvantage of running OSPFv3 with NEMO Basic Support is the possibility that the Mobile Networks will be told of the topology of the entire home network, including all the fixed and Mobile Routers. The only thing the Mobile Routers might really need is a default route through the Home Agent. http://www.ietf.org/rfc/rfc4017.txt 4017 Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs. D. Stanley, J. Walker, B. Aboba. March 2005. (Format: TXT=22183 bytes) (Status: INFORMATIONAL) The IEEE 802.11i MAC Security Enhancements Amendment requires that EAP authentication methods be available. Wireless LAN deployments are expected to use different credential types, including digital certificates, user-names and passwords, existing secure tokens, and mobile network credentials (GSM and UMTS secrets). Other credential types that may be used include public/private key (without necessarily requiring certificates) and asymmetric credential support (such as password on one side, public/private key on the other). http://www.ietf.org/rfc/rfc4094.txt 4094 Analysis of Existing Quality-of-Service Signaling Protocols. J. Manner, X. Fu. May 2005. (Format: TXT=103146 bytes) (Status: INFORMATIONAL) RSVP uses a soft state mechanism to maintain states and allows each node to define its own refresh timer. The protocol is also independent of underlying routing protocols. Still, in mobile networks the movement of the mobile nodes may not properly trigger a reservation refresh for the new path, and therefore a mobile node may be left without a reservation up to the length of the refresh timer. INSIGNIA [LGZC00] is proposed as a very simple signaling mechanism for supporting QoS in mobile ad-hoc networks. It avoids the need for separate signaling by carrying the QoS signaling data along with the normal data in IP packets using IP packet header options. This approach, known as "in-band signaling", is proposed as more suitable in the rapidly changing environment of mobile networks since the signaled QoS information is not tied to a particular path. It also allows the flows to be rapidly established and, thus, is suitable for short-lived and dynamic flows. [MA01] B. Moon, and H. Aghvami, "RSVP Extensions for Real- Time Services in Wireless Mobile Networks". IEEE Communications Magazine, December 2001, pp. 52-59. http://www.ietf.org/rfc/rfc4138.txt 4138 Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP). P. Sarolahti, M. Kojo. August 2005. (Format: TXT=55538 bytes) (Updated by RFC5682) (Status: EXPERIMENTAL) There are a number of potential reasons for spurious retransmission timeouts. First, some mobile networking technologies involve sudden delay spikes on transmission because of actions taken during a hand-off. Second, given a low-bandwidth link or some other change in available bandwidth, arrival of competing traffic (possibly with higher priority) can cause a sudden increase of round-trip time. This may trigger a spurious retransmission timeout. A persistently reliable link layer can also cause a sudden delay when a data frame and several retransmissions of it are lost for some reason. This document does not distinguish between the different causes of such a delay spike. Rather, it discusses the spurious retransmission timeouts caused by a delay spike in general. http://www.ietf.org/rfc/rfc4186.txt 4186 Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM). H. Haverinen, Ed., J. Salowey, Ed.. January 2006. (Format: TXT=220807 bytes) (Status: INFORMATIONAL) This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the Global System for Mobile Communications (GSM) Subscriber Identity Module (SIM). GSM is a second generation mobile network standard. The EAP-SIM mechanism specifies enhancements to GSM authentication and key agreement whereby multiple authentication triplets can be combined to create authentication responses and session keys of greater strength than the individual GSM triplets. The mechanism also includes network authentication, user anonymity support, result indications, and a fast re-authentication procedure. GSM is a second generation mobile network standard. Second generation mobile networks and third generation mobile networks use different authentication and key agreement mechanisms. EAP-AKA [EAP-AKA] specifies an EAP method that is based on the Authentication and Key Agreement (AKA) mechanism used in 3rd generation mobile networks. GSM subscribers are identified with the International Mobile Subscriber Identity (IMSI) [GSM-03.03]. The IMSI is a string of not more than 15 digits. It is composed of a three digit Mobile Country Code (MCC), a two or three digit Mobile Network Code (MNC), and a Mobile Subscriber Identification Number (MSIN) of no more than 10 digits. MCC and MNC uniquely identify the GSM operator and help identify the AuC from which the authentication vectors need to be retrieved for this subscriber. http://www.ietf.org/rfc/rfc4187.txt 4187 Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA). J. Arkko, H. Haverinen. January 2006. (Format: TXT=194958 bytes) (Updated by RFC5448) (Status: INFORMATIONAL) This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution that uses the Authentication and Key Agreement (AKA) mechanism. AKA is used in the 3rd generation mobile networks Universal Mobile Telecommunications System (UMTS) and CDMA2000. AKA is based on symmetric keys, and typically runs in a Subscriber Identity Module, which is a UMTS Subscriber Identity Module, USIM, or a (Removable) User Identity Module, (R)UIM, similar to a smart card. This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution that uses the 3rd generation Authentication and Key Agreement mechanism, specified for Universal Mobile Telecommunications System (UMTS) in [TS33.102] and for CDMA2000 in [S.S0055-A]. UMTS and CDMA2000 are global 3rd generation mobile network standards that use the same AKA mechanism. 2nd generation mobile networks and 3rd generation mobile networks use different authentication and key agreement mechanisms. The Global System for Mobile communications (GSM) is a 2nd generation mobile network standard, and EAP-SIM [EAP-SIM] specifies an EAP mechanism that is based on the GSM authentication and key agreement primitives. o The use of the AKA also as a secure PPP authentication method in devices that already contain an identity module. o The use of the 3rd generation mobile network authentication infrastructure in the context of wireless LANs o Relying on AKA and the existing infrastructure in a seamless way with any other technology that can use EAP. In the 3rd generation mobile networks, AKA is used for both radio network authentication and IP multimedia service authentication purposes. Different user identities and formats are used for these; the radio network uses the International Mobile Subscriber Identifier (IMSI), whereas the IP multimedia service uses the Network Access Identifier (NAI) [RFC4282]. Authentication Centre. The mobile network element that can authenticate subscribers in the mobile networks. After obtaining the subscriber identity, the EAP server obtains an authentication vector (RAND, AUTN, RES, CK, IK) for use in authenticating the subscriber. From the vector, the EAP server derives the keying material, as specified in Section 6.4. The vector may be obtained by contacting an Authentication Centre (AuC) on the mobile network; for example, per UMTS specifications, several vectors may be obtained at a time. Vectors may be stored in the EAP server for use at a later time, but they may not be reused. Subscribers of mobile networks are identified with the International Mobile Subscriber Identity (IMSI) [TS23.003]. The IMSI is a string of not more than 15 digits. It is composed of a Mobile Country Code (MCC) of 3 digits, a Mobile Network Code (MNC) of 2 or 3 digits, and a Mobile Subscriber Identification Number (MSIN) of not more than 10 digits. MCC and MNC uniquely identify the GSM operator and help identify the AuC from which the authentication vectors need to be retrieved for this subscriber. http://www.ietf.org/rfc/rfc4215.txt 4215 Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks. J. Wiljakka, Ed.. October 2005. (Format: TXT=52903 bytes) (Status: INFORMATIONAL) typically access both IPv4 and IPv6 services without additional translators in the network. However, it is good to remember that private IPv4 addresses and NATs [RFC2663] have been used and will be used in mobile networks. Public/global IP addresses are also needed for peer-to-peer services: the node needs a public/global IP address that is visible to other nodes. http://www.ietf.org/rfc/rfc4355.txt 4355 IANA Registration for Enumservices email, fax, mms, ems, and sms. R. Brandner, L. Conroy, R. Stastny. January 2006. (Format: TXT=30218 bytes) (Updated by RFC6118) (Status: PROPOSED STANDARD) When placing a fax call via the PSTN or a sending a message via the Public Land Mobile Network, the sender may be charged for this action. In both kinds of network, calling or messaging to some numbers is more expensive than sending to others; both networks have "premium rate" services that can charge considerably more than a "normal" call or message destination. As such, it is important that end-users be asked to confirm sending the message and that the destination number be presented to them. It is the originating user's choice on whether or not to send a message to this destination number, but end-users SHOULD be shown the destination number so that they can make this decision. http://www.ietf.org/rfc/rfc4415.txt 4415 IANA Registration for Enumservice Voice. R. Brandner, L. Conroy, R. Stastny. February 2006. (Format: TXT=15956 bytes) (Updated by RFC6118) (Status: PROPOSED STANDARD) This Enumservice indicates that the person responsible for the NAPTR is accessible via the Public Switched Telephone Network (PSTN) or Public Land Mobile Network (PLMN) using the value of the generated URI. When placing a voice call via the PSTN (or from the Public Land Mobile Network), the sender may be charged for this action. In both kinds of networks, calling some numbers is more expensive than sending to others; both kinds of networks have "premium rate" services that can be charged at a rate considerably more than a "normal" call. As such, it is important that end users be asked to confirm placing the call and that the destination number be presented to them. It is the originating user's choice whether or not to place a call to this destination number, but the originating user SHOULD be shown the destination number so that he or she can make this decision. http://www.ietf.org/rfc/rfc4416.txt 4416 Goals for Internet Messaging to Support Diverse Service Environments. J. Wong, Ed.. February 2006. (Format: TXT=93676 bytes) (Status: INFORMATIONAL) 2G mobile networks enabled wireless data communications, but only at very low bandwidths using circuit-switched data. 2.5G and 3G networks improve on this. However, existing email clients require very large files (up to several MBs) -- encountered in multi-media attachments such as presentations, images, voice, and video -- to be downloaded even though mobiles cannot exploit most of the data (because of color depth and screen size limitations). Transferring such large files over the air is of questionable value even when higher wireless bandwidth is available. Mobile network providers often operate on a "pay for use" service model. This brings in requirements for clearly delineated service transactions that can be reported to billing systems, and for Some mobile networks require network authentication as well as application authentication. http://www.ietf.org/rfc/rfc4487.txt 4487 Mobile IPv6 and Firewalls: Problem Statement. F. Le, S. Faccin, B. Patil, H. Tschofenig. May 2006. (Format: TXT=32022 bytes) (Status: INFORMATIONAL) This document captures the issues that may arise in the deployment of IPv6 networks when they support Mobile IPv6 and firewalls. The issues are not only applicable to firewalls protecting enterprise networks, but are also applicable in 3G mobile networks such as General Packet Radio Service / Universal Mobile Telecommunications System (GPRS/UMTS) and CDMA2000 networks. +----------------+ +----+ | | | HA | | | +----+ | | Home Agent | +---+ +----+ of B | |CN | | FW | | | C | +----+ | +---+ | +---+ | | | B | | | +---+ +----------------+ External Mobile Network protected Node by a firewall http://www.ietf.org/rfc/rfc4504.txt 4504 SIP Telephony Device Requirements and Configuration. H. Sinnreich, Ed., S. Lass, C. Stredicke. May 2006. (Format: TXT=84849 bytes) (Status: INFORMATIONAL) Implementers interested in a short list MAY, however, support a minimal number of codecs used in wireline Voice over IP (VoIP), and also codecs found in mobile networks for which the SIP UA is targeted. An ordered short list of preferences may look as follows: Req-73: Mobile SIP telephony devices MAY support codecs found in various wireless mobile networks. This can avoid codec conversion in network-based intermediaries. http://www.ietf.org/rfc/rfc4550.txt 4550 Internet Email to Support Diverse Service Environments (Lemonade) Profile. S. Maes, A. Melnikov. June 2006. (Format: TXT=48790 bytes) (Obsoleted by RFC5550) (Status: PROPOSED STANDARD) - Media conversion (static and possibly streamed) - Transport optimization for low or costly bandwidth and less reliable mobile networks (e.g., quick reconnect) - Server to client notifications, possibly outside of the traditional IMAP band - Dealing with firewall and intermediaries - Compression and other bandwidth optimization - Filtering - Other considerations for mobile clients http://www.ietf.org/rfc/rfc4565.txt 4565 Evaluation of Candidate Control and Provisioning of Wireless Access Points (CAPWAP) Protocols. D. Loher, D. Nelson, O. Volinsky, B. Sarikaya. July 2006. (Format: TXT=62929 bytes) (Status: INFORMATIONAL) I am currently Professor of Computer Science at UNBC. I have so far 5 years of experience in IETF as a member of mobile networking- related working groups. I have made numerous I-D contributions and am a coauthor of one RFC. I have submitted an evaluation draft (with Andy Lee) that evaluated LWAPP, CTP, and WiCoP. Also I submitted another draft (on CAPWAPHP) that used LWAPP, CTP, WiCoP, and SLAPP as transport. I also have research interests on next-generation access point/controller architectures. I have no involvement in any of the candidate protocol drafts, have not contributed any of the drafts. I have not worked in any of the companies whose staff has produced any of the candidate protocols. http://www.ietf.org/rfc/rfc4584.txt 4584 Extension to Sockets API for Mobile IPv6. S. Chakrabarti, E. Nordmark. July 2006. (Format: TXT=53995 bytes) (Status: INFORMATIONAL) This document does not address application access to either the Authentication Header or the Encapsulating Security Payload header. This document also does not address any API that might be necessary for Mobile Network [4] specific needs. Furthermore, note that this API document excludes discussion on application-level API. It assumes that address selection socket API [5] takes care of selection of care-of address or home address as the source address by the application, when source address selection is required due to the nature of the application. http://www.ietf.org/rfc/rfc4651.txt 4651 A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization. C. Vogt, J. Arkko. February 2007. (Format: TXT=79226 bytes) (Status: INFORMATIONAL) 1. Introduction ....................................................3 1.1. A Note on Public-Key Infrastructures .......................4 1.2. A Note on Source Address Filtering .........................5 2. Objectives for Route Optimization Enhancement ...................7 2.1. Latency Optimizations ......................................8 2.2. Security Enhancements ......................................8 2.3. Signaling Optimizations ....................................9 2.4. Robustness Enhancements ....................................9 3. Enhancements Toolbox ............................................9 3.1. IP Address Tests ..........................................10 3.2. Protected Tunnels .........................................10 3.3. Optimistic Behavior .......................................11 3.4. Proactive IP Address Tests ................................11 3.5. Concurrent Care-of Address Tests ..........................12 3.6. Diverted Routing ..........................................13 3.7. Credit-Based Authorization ................................14 3.8. Heuristic Monitoring ......................................17 3.9. Crypto-Based Identifiers ..................................18 3.10. Pre-Configuration ........................................19 3.11. Semi-Permanent Security Associations .....................20 3.12. Delegation ...............................................21 3.13. Mobile Networks ..........................................21 3.14. Location Privacy .........................................22 4. Discussion .....................................................22 4.1. Cross-Layer Interactions ..................................23 4.2. Experimentation and Measurements ..........................23 4.3. Future Research ...........................................24 5. Security Considerations ........................................24 6. Conclusions ....................................................25 7. Acknowledgments ................................................25 8. References .....................................................26 8.1. Normative References ......................................26 8.2. Informative References ....................................26 3.13. Mobile Networks http://www.ietf.org/rfc/rfc4728.txt 4728 The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4. D. Johnson, Y. Hu, D. Maltz. February 2007. (Format: TXT=265706 bytes) (Status: EXPERIMENTAL) [JOHNSON96b] David B. Johnson and David A. Maltz. Protocols for Adaptive Wireless and Mobile Networking. IEEE Personal Communications, 3(1):34-42, February 1996. http://www.ietf.org/rfc/rfc4830.txt 4830 Problem Statement for Network-Based Localized Mobility Management (NETLMM). J. Kempf, Ed.. April 2007. (Format: TXT=29815 bytes) (Status: INFORMATIONAL) An access network is a collection of fixed and mobile network components allowing access to the Internet all belonging to a single operational domain. It may consist of multiple air interface technologies (for example, 802.16e [7], Universal Mobile Telecommunications System (UMTS) [1], etc.) interconnected with multiple types of backhaul interconnections (such as Synchronous Optical Network (SONET) [9], metro Ethernet [15] [8], etc.). http://www.ietf.org/rfc/rfc4885.txt 4885 Network Mobility Support Terminology. T. Ernst, H-Y. Lach. July 2007. (Format: TXT=37967 bytes) (Status: INFORMATIONAL) 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Architectural Components . . . . . . . . . . . . . . . . . . . 3 2.1. Mobile Network (NEMO) . . . . . . . . . . . . . . . . . . 5 2.2. Mobile Subnet . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Mobile Router (MR) . . . . . . . . . . . . . . . . . . . . 6 2.4. Egress Interface . . . . . . . . . . . . . . . . . . . . . 6 2.5. Ingress Interface . . . . . . . . . . . . . . . . . . . . 6 2.6. Mobile Network Prefix (MNP) . . . . . . . . . . . . . . . 6 2.7. Mobile Network Node (MNN) . . . . . . . . . . . . . . . . 6 2.8. Correspondent Node (CN) . . . . . . . . . . . . . . . . . 7 2.9. Correspondent Router (CR) . . . . . . . . . . . . . . . . 7 2.10. Correspondent Entity (CE) . . . . . . . . . . . . . . . . 7 3. Functional Terms . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Local Fixed Node (LFN) . . . . . . . . . . . . . . . . . . 8 3.2. Visiting Mobile Node (VMN) . . . . . . . . . . . . . . . . 8 3.3. Local Mobile Node (LMN) . . . . . . . . . . . . . . . . . 9 3.4. NEMO-Enabled Node (NEMO-Node) . . . . . . . . . . . . . . 9 3.5. MIPv6-Enabled Node (MIPv6-Node) . . . . . . . . . . . . . 9 4. Nested Mobility Terms . . . . . . . . . . . . . . . . . . . . 9 4.1. Nested Mobile Network (nested-NEMO) . . . . . . . . . . . 9 4.2. Root-NEMO . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Parent-NEMO . . . . . . . . . . . . . . . . . . . . . . . 10 4.4. Sub-NEMO . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.5. Root-MR . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.6. Parent-MR . . . . . . . . . . . . . . . . . . . . . . . . 10 4.7. Sub-MR . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.8. Depth . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Multihoming Terms . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Multihomed Host or MNN . . . . . . . . . . . . . . . . . . 11 5.2. Multihomed Mobile Router . . . . . . . . . . . . . . . . . 11 5.3. Multihomed Mobile Network (multihomed-NEMO) . . . . . . . 12 5.4. Nested Multihomed Mobile Network . . . . . . . . . . . . . 12 5.5. Split-NEMO . . . . . . . . . . . . . . . . . . . . . . . . 12 5.6. Illustration . . . . . . . . . . . . . . . . . . . . . . . 12 6. Home Network Model Terms . . . . . . . . . . . . . . . . . . . 14 6.1. Home Link . . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Home Network . . . . . . . . . . . . . . . . . . . . . . . 14 6.3. Home Address . . . . . . . . . . . . . . . . . . . . . . . 14 6.4. Mobile Home Network . . . . . . . . . . . . . . . . . . . 14 6.5. Distributed Home Network . . . . . . . . . . . . . . . . . 14 6.6. Mobile Aggregated Prefix . . . . . . . . . . . . . . . . . 15 6.7. Aggregated Home Network . . . . . . . . . . . . . . . . . 15 6.8. Extended Home Network . . . . . . . . . . . . . . . . . . 15 6.9. Virtual Home Network . . . . . . . . . . . . . . . . . . . 15 7. Mobility Support Terms . . . . . . . . . . . . . . . . . . . . 15 7.1. Host Mobility Support . . . . . . . . . . . . . . . . . . 15 7.2. Network Mobility Support (NEMO Support) . . . . . . . . . 15 7.3. NEMO Basic Support . . . . . . . . . . . . . . . . . . . . 15 7.4. NEMO Extended Support . . . . . . . . . . . . . . . . . . 16 7.5. NEMO Routing Optimization (NEMO RO) . . . . . . . . . . . 16 7.6. MRHA Tunnel . . . . . . . . . . . . . . . . . . . . . . . 16 7.7. Pinball Route . . . . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 Network mobility support is concerned with managing the mobility of an entire network. This arises when a router connecting a network to the Internet dynamically changes its point of attachment to the fixed infrastructure, thereby causing the reachability of the entire network to be changed in relation to the fixed Internet topology. Such a network is referred to as a mobile network. Without appropriate mechanisms to support network mobility, sessions established between nodes in the mobile network and the global Internet cannot be maintained after the mobile router changes its point of attachment. As a result, existing sessions would break and connectivity to the global Internet would be lost. Note that the abbreviation NEMO stands for either "a NEtwork that is MObile" or "NEtwork MObility". The former (see Section 2.1) is used as a noun, e.g., "a NEMO" meaning "a mobile network". The latter (see Section 7) refers to the concept of "network mobility", as in "NEMO Basic Support", and is also the working group's name. Section 2 introduces terms to define the architecture, while terms needed to emphasize the distinct functionalities of those architectural components are described in Section 3. Section 4, Section 5, and Section 6 describe terms pertaining to nested mobility, multihoming, and different configurations of mobile networks at home, respectively. The different types of mobility are defined in Section 7. The last section lists miscellaneous terms that do not fit into any other section. A mobile network is composed of one or more mobile IP-subnets and is viewed as a single unit. This network unit is connected to the Internet by means of one or more mobile routers (MRs). Nodes behind the MR (referred to as MNNs) primarily comprise fixed nodes (nodes unable to change their point of attachment while maintaining ongoing sessions), and possibly mobile nodes (nodes able to change their point of attachment while maintaining ongoing sessions). In most cases, the internal structure of the mobile network will be stable (no dynamic change of the topology), but this is not always true. Figure 1 illustrates the architectural components involved in network mobility and are defined in the following paragraphs: Mobile Router (MR), Mobile Network (NEMO), Mobile Network Node (MNN), "ingress interface", "egress interface", and Correspondent Node (CN). The other terms, "access router" (AR), "Fixed Node (FN)", "Mobile Node (MN)", "home agent" (HA), "home link", and "foreign link", are not terms specific to network mobility and thus are defined in [3]. Figure 1: Mobile Network on the Home Link Figure 2 shows a single mobile subnet. Figure 3 illustrates a larger mobile network comprising several subnets, attached to a foreign link. Figure 3: Larger Mobile Network Made up of 2 Mobile Subnets At the network layer, MRs get access to the global Internet from an Access Router (AR) on a visited link. An MR maintains the Internet connectivity for the entire mobile network. A given MR has one or more egress interfaces and one or more ingress interfaces. When forwarding a packet to the Internet, the packet is transmitted upstream through one of the MR's egress interfaces to the AR; when forwarding a packet from the AR down to the mobile network, the packet is transmitted downstream through one of the MR's ingress interfaces. 2.1. Mobile Network (NEMO) An entire network, moving as a unit, which dynamically changes its point of attachment to the Internet and thus its reachability in the topology. The mobile network is composed of one or more IP-subnets and is connected to the global Internet via one or more Mobile Routers (MR). The internal configuration of the mobile network is assumed to be relatively stable with respect to the MR. Rearrangement of the mobile network and changing the attachment point of the egress interface to the foreign link are orthogonal processes and do no affect each other. A link (subnet) that comprises, or is located within, the mobile network. An MR acts as a gateway between an entire mobile network and the rest of the Internet, and has one or more egress interfaces and one or more ingress interfaces. Packets forwarded upstream to the rest of the Internet are transmitted through one of the MR's egress interfaces; packets forwarded downstream to the mobile network are transmitted through one of the MR's ingress interfaces. The interface of an MR attached to a link inside the mobile network. 2.6. Mobile Network Prefix (MNP) A bit string that consists of some number of initial bits of an IP address which identifies the entire mobile network within the Internet topology. All nodes in a mobile network necessarily have an address containing this prefix. 2.7. Mobile Network Node (MNN) Any node (host or router) located within a mobile network, either permanently or temporarily. A Mobile Network Node may be either a fixed node (LFN) or a mobile node (either VMN or LMN). Any node that is communicating with one or more MNNs. A CN could be either located within a fixed network or within a mobile network, and could be either fixed or mobile. Refers to the entity with which a Mobile Router or Mobile Network Node attempts to establish a Route Optimization session. Depending on the Route Optimization approach, the Correspondent Entity may be a Correspondent Node or Correspondent Router (see also NEMO Route Optimization in Section 7.5). Within the term Mobile Network Node (MNN), we can distinguish between Local Fixed Nodes (LFN), Visiting Mobile Nodes (VMN), and Local Mobile Nodes (LMN). The distinction is a property of how different types of nodes can move in the topology and is necessary to discuss issues related to mobility management and access control; however, it does not imply that network mobility or host mobility should be handled differently. Nodes are classified according to their function and capabilities with the rationale that nodes with different properties may have different requirements. Figure 4 illustrates a VMN changing its point of attachment from its home link located outside the mobile network to within a mobile network. The figure also illustrates an LMN changing its point of attachment within the mobile network. A fixed node (FN), either a host or a router, that belongs to the mobile network and is unable to change its point of attachment while maintaining ongoing sessions. Its address is taken from an MNP. Either a mobile node (MN) or a mobile router (MR), assigned to a home link that doesn't belong to the mobile network and that is able to change its point of attachment while maintaining ongoing sessions. A VMN that is temporarily attached to a mobile subnet (used as a foreign link) obtains an address on that subnet (i.e., the address is taken from an MNP). Either a mobile node (MN) or a mobile router (MR), assigned to a home link belonging to the mobile network and which is able to change its point of attachment while maintaining ongoing sessions. Its address is taken from an MNP. Nested mobility occurs when there is more than one level of mobility, i.e., when a mobile network acts as an access network and allows visiting nodes to attach to it. There are two cases of nested mobility: o The attaching node is an MR with nodes behind it, i.e., a mobile network (see Figure 5). For instance, when a passenger carrying a PAN gets Internet access from the public access network deployed on a bus. 4.1. Nested Mobile Network (nested-NEMO) A mobile network is said to be nested when a mobile network (sub- NEMO) is attached to a larger mobile network (parent-NEMO). The aggregated hierarchy of mobile networks becomes a single nested mobile network (see Figure 5). The mobile network at the top of the hierarchy connecting the aggregated nested mobile networks to the Internet (see Figure 5). The upstream mobile network providing Internet access to another mobile network further down the hierarchy (see Figure 5). The downstream mobile network attached to another mobile network up in the hierarchy. It becomes subservient of the parent-NEMO. The sub-NEMO is getting Internet access through the parent-NEMO and does not provide Internet access to the parent-NEMO (see Figure 5). The MR(s) of the root-NEMO used to connect the nested mobile network to the fixed Internet (see Figure 5). Figure 5: Nested Mobility: a sub-NEMO attached to a larger mobile network Multihoming, as currently defined by the IETF, covers site- multihoming [9] and host multihoming. We enlarge this terminology to include "multihomed mobile router" and "multihomed mobile network". The specific configurations and issues pertaining to multihomed mobile networks are covered in [10]. 5.3. Multihomed Mobile Network (multihomed-NEMO) A mobile network is multihomed when a MR is multihomed or there are multiple MRs to choose between (see the corresponding analysis in [10]). 5.4. Nested Multihomed Mobile Network A nested mobile network is multihomed when either a root-MR is multihomed or there are multiple root-MRs to choose between. Split-NEMO refers to the case where a mobile network becomes two or more independent mobile networks due to the separation of Mobile Routers that are handling the same MNP (or MNPs) in the original mobile network before the separation. Figure 6 and Figure 7 show two examples of multihomed mobile networks. Figure 8 shows two independent mobile networks. NEMO-1 is single-homed to the Internet through MR1. NEMO-2 is multihomed to the Internet through MR2a and MR2b. Both mobile networks offer access to visiting nodes and networks through an AR. * NEMO-1 becomes the parent-NEMO to NEMO-2 and the root-NEMO for the aggregated nested mobile network * MR1 is the root-MR for the aggregated nested mobile network * MR2a is a sub-MR in the aggregated nested mobile network * The aggregated nested mobile network is not multihomed, since NEMO-2 cannot be used as a transit network for NEMO-1 * NEMO-2 becomes the parent_NEMO to NEMO-1 and also the root-NEMO for the aggregated nested mobile network * MR2a and MR2b are both root-MRs for the aggregated nested mobile network * MR1 is a sub-MR in the aggregated nested mobile network * The aggregated nested mobile network is multihomed The terms in this section are useful to describe the possible configurations of mobile networks at the home. For a better understanding of the definitions, the reader is recommended to read [6], where such configurations are detailed. A Mobile Network (NEMO) that is also a Home Network. The MR, or one of the MR(s), that owns the MNP may act as the Home Agent for the mobile nodes in the Mobile Home Network. An aggregation of Mobile Network Prefixes. The network associated with the aggregation of one or more Home Network(s) and Mobile Network(s). As opposed to the Mobile IPv6 Home Network that is a subnet, the Extended Home Network is an aggregation and is further subnetted. An aggregation of Mobile Network Prefixes that is in turn advertised as the Home Link Prefix. The Extended Home Network and the Aggregated Home Network can be configured as Virtual Home Network. Network Mobility Support is a mechanism that maintains session continuity between mobile network nodes and their correspondents upon a mobile router's change of point of attachment. Solutions for this problem are classified into NEMO Basic Support, and NEMO Extended Support. The term "Route Optimization" is accepted in a broader sense than already defined for IPv6 Host Mobility in [4] to loosely refer to any approach that optimizes the transmission of packets between a Mobile Network Node and a Correspondent Node. A pinball route refers to the non-direct path taken by packets, which are routed via one or more Home Agents, as they transit between a Mobile Network Node and a Correspondent Node. http://www.ietf.org/rfc/rfc4886.txt 4886 Network Mobility Support Goals and Requirements. T. Ernst. July 2007. (Format: TXT=29083 bytes) (Status: INFORMATIONAL) Network mobility arises when a router connecting a network to the Internet dynamically changes its point of attachment to the Internet thereby causing the reachability of the said network to be changed in relation to the fixed Internet topology. Such a type of network is referred to as a mobile network. With appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet can be maintained after the mobile router changes its point of attachment. This document outlines the goals expected from network mobility support and defines the requirements that must be met by the NEMO Basic Support solution. Network mobility support (see [1] for the related terminology) is concerned with managing the mobility of an entire network, viewed as a single unit that changes its point of attachment to the Internet and thus its reachability in the Internet topology. Such a network is referred to as a mobile network and includes one or more mobile routers (MRs), which connect it to the global Internet. Nodes behind the MR(s) (MNNs) are both fixed (LFNs) and mobile (VMNs or LMNs). In most cases, the internal structure of the mobile network will be relatively stable (no dynamic change of the topology), but this is not always true. Cases of mobile networks include, for instance: o Networks attached to people (Personal Area Networks or PANs): a cell phone with one cellular interface and one Bluetooth interface together with a Bluetooth-enabled PDA constitute a very simple instance of a mobile network. The cell phone is the mobile router while the PDA is used for web browsing or runs a personal web server. Mobility of networks does not cause MNNs to change their own physical point of attachment; however, they do change their topological location with respect to the global Internet. If network mobility is not explicitly supported by some mechanisms, the mobility of the MR results in MNNs losing Internet access and breaking ongoing sessions between arbitrary correspondent nodes (CNs) in the global Internet and those MNNs located within the mobile network. In addition, the communication path between MNNs and correspondent nodes becomes sub- optimal, and multiple levels of mobility will cause extremely sub- optimal routing. The primary objective of the NEMO work is to specify a solution that allows mobile network nodes (MNNs) to remain connected to the Internet and continuously reachable while the mobile router serving the mobile network changes its point of attachment. The secondary goal of the work is to investigate the effects of network mobility on various aspects of Internet communication such as routing protocol changes, implications of real-time traffic and fast handovers, and optimizations. This should support the primary goal of reachability for mobile network nodes. Security is an important consideration too, and efforts should be made to use existing security solutions if they are appropriate. Although a well-designed solution may include security inherent in other protocols, mobile networks also introduce new challenges. To complete these tasks, the NEMO working group has decided to take a stepwise approach. The steps in this approach include standardizing a basic solution to preserve session continuity (NEMO Basic Support, see [3]) and studying the possible approaches and issues with providing more optimal routing with potentially nested mobile networks (NEMO Extended Support, see [6] and [7] for a discussion on routing optimization issues and [8] for a discussion on multihoming issues). However, the working group is not chartered to actually standardize a solution for Extended Support at this point in time. If deemed necessary, the working group will be rechartered based on the conclusions of the discussions. For NEMO Basic Support, the working group assumes that none of the nodes behind the MR is aware of the network's mobility; thus, the network's movement needs to be completely transparent to the nodes inside the mobile network. This assumption accommodates nodes inside the network that are not generally aware of mobility. The efforts of the Mobile IP working group have resulted in the Mobile IPv4 and Mobile IPv6 protocols, which have already solved the issue of host mobility support. Since challenges to enabling mobile networks are vastly reduced by this work, basic network mobility support has adopted the methods for host mobility support used in Mobile IP and has extended them in the simplest way possible to achieve its goals. The Basic Support solution, now defined in [3] following the requirements stated in Section 4 of the present document, is for each MR to have a Home Agent (HA), and use bi- directional tunneling between the MR and HA to preserve session continuity while the MR moves. The MR acquires a Care-of Address (CoA) at its attachment point much like what is done for mobile hosts (MHs), using Mobile IP. This approach allows nested mobile networks, since each MR will appear to its attachment point as a single node. MNNs behind the MR(s) do not change their own physical point of attachment as a result of the mobile network's displacement in the Internet topology. Consequently, NEMO support is expected to be performed only by the MR(s). Specific support functions on any node other than the MR(s) would better be avoided. The formation of a mobile network can occur in various levels of complexity. In the simplest case, a mobile network contains just a mobile router and a host. In the most complicated case, a mobile network is multihomed and is itself a multi-level aggregation of mobile networks with collectively thousands of mobile routers and hosts. While the list of potential configurations of mobile networks cannot be limited, at least the following ones are desirable: o Mobile networks of any size, ranging from a sole subnet with a few IP devices to a collection of subnets with a large number of IP devices. o Nodes that change their point of attachment within the mobile network. o Foreign mobile nodes that attach to the mobile network. o Multihomed mobile network: either when a single MR has multiple attachments to the internet, or when the mobile network is attached to the Internet by means of multiple MRs (see definition in [1] and the analysis in [8]). o Nested mobile networks (mobile networks attaching to other mobile networks (see definition in [1]). Although the complexity requirements of these nested networks are not clear, it is desirable to support arbitrary levels of recursive networks. The solution should only impose restrictions on nesting (e.g., path MTU) when this is impractical and protocol concerns preclude such support. Mobile networks and mobile nodes owned by different administrative entities are expected to be displaced within a domain boundary or between domain boundaries. Multihoming, vertical and horizontal handoffs, and access control mechanisms are desirable to achieve this goal. Such mobility is not expected to be limited for any consideration other than administrative and security policies. NEMO support signaling and processing is expected to scale to a potentially large number of mobile networks irrespective of their configuration, mobility frequency, size, and number of CNs. o Host mobility support: mobile nodes and correspondent nodes, either located within or outside the mobile network, are expected to continue operating protocols defined by the Mobile IP working group. This includes mechanisms for host mobility support (Mobile IPv6) and seamless mobility (FMIPv6). o Access control protocols and mechanisms used by visiting mobile hosts and routers to be authenticated and authorized, gaining access to the Internet via the mobile network infrastructure (MRs). o Mechanisms performed by routers deployed in both visited networks and mobile networks (routing protocols, Neighbor Discovery, ICMP, Router Renumbering). As one example of why this is necessary, consider the approach of advertising each mobile network's connectivity into BGP and, for every movement, withdrawing old routes and injecting new routes. If there were tens of thousands of mobile networks each advertising and withdrawing routes, for example, at the speed that an airplane can move from one ground station to another, the potential effect on BGP could be very unfortunate. In this example, the total amount of routing information advertised into BGP may be acceptable, but the dynamic instability of the information (i.e., the number of changes over time) would be unacceptable. For basic network mobility support, the NEMO WG is to specify a unified and unique "Network Mobility (NEMO) Basic Support" solution, hereafter referred to as "the solution". This solution is to allow all nodes in the mobile network to be reachable via permanent IP R07: The solution must support fixed nodes, mobile hosts, and mobile routers in the mobile network. R08: The solution must allow MIPv6-enabled MNNs to use a mobile network link as either a home link or a foreign link. R11: The solution must support at least 2 levels of nested mobile networks, while, in principle, arbitrary levels of recursive mobile networks should be supported. R12: The solution must function for multihomed MRs and multihomed mobile networks as defined in [1]. http://www.ietf.org/rfc/rfc4887.txt 4887 Network Mobility Home Network Models. P. Thubert, R. Wakikawa, V. Devarapalli. July 2007. (Format: TXT=40372 bytes) (Status: INFORMATIONAL) NEMO Extended Home Network: In this arrangement, the Home Network is only one subnet of a larger aggregation that encompasses the Mobile Networks, called Extended Home Network. When at home, a Mobile Router performs normal routing between the Home Link and the Mobile Networks. More in Section 5. NEMO Aggregated Home Network: In this arrangement, the Home Network actually overlaps with the Mobile Networks. When at home, a Mobile Router acts as a bridge between the Home Link and the Mobile Networks. More in Section 6. NEMO Mobile Home Network: In this arrangement, there is a bitwise hierarchy of Home Networks. A global Home Network is advertised to the infrastructure by a head Home Agent (HA) and further subnetted into Mobile Networks. Each subnet is owned by a Mobile Router that registers it in a NEMO fashion while acting as a Home Agent for that network. More in Section 8. In all cases, the Home Agents collectively advertise only the aggregation of the Mobile Networks. The subnetting is kept within the Home Agents and the Mobile Routers, as opposed to advertised by means of routing protocols to other parties. In addition, some terms were created or extended for NEMO. These specific terms are defined in the Mobile Network Terminology document [6]: When a Mobile Router, MR1, uses the Mobile Network Prefix (MNP) A:B: C:1::/64 with the NEMO Basic Support, MR1 may register using a Home Address from the Home network (i.e., A:B:C:0::1) or a Home Address from one of its MNPs (i.e., A:B:C:1::1) depending on the deployment. In a given deployment, one subnet may be reserved for the Home Link (A:B:C:0::/64) while the others are attributed to Mobile Routers as Mobile Networks (as A:B:C:1::/64 for MR1). Another approach could be to configure the aggregation of Mobile Networks as the subnet on the Home Link, and let the Mobile Routers manage the overlapping networks. Finally, the aggregation could be configured on a virtual network, with no physical Home Link at all, in which case home means topologically and administratively close to the Home Agent that advertises the virtual network. As we see, the concept of a Home Network for Mobile IPv6 is really a prefix on a link, served by one or more Home Agents as opposed to a routed mesh. We will see in the next sections that NEMO needs additional prefixes for use by the Mobile Networks. For that reason, NEMO extends the concept of Home Network into a more complex, aggregated structure. One simple way of extending the MIP Home Network is to use additional prefixes, contiguous to the Home Link Prefix inherited from MIPv6, as Mobile Network Prefixes. As this model trivially extends the MIP Home Network, the resulting aggregation is called a NEMO Extended Home Network. It is depicted in Figure 1. o There is one physical Home Network and multiple Mobile Networks When at home, the Mobile Router ensures the connectivity of the Mobile Network using standard router operations. But in explicit mode, or if the Mobile Router uses an IGP over the MRHA tunnel, then it needs to resume its IGP operations on the Home Link in order to advertise its Mobile Networks to the HA, unless some other means such as static routes are deployed to cover the case. Alternative procedures for ensuring the connectivity of the Mobile Networks when at home are described in Section 7. We saw that a natural extension of the MIP procedure is to derive the Home Address of a Mobile Router from the prefix on the Home Link. Alternatively, NEMO basic support allows that a Mobile Router forms its Home Address from one of its Mobile Network Prefixes. In that case, the Home Address does not match the Home Link Prefix, and there is a need to configure the Home Agent in a specific mode with the support for the Extended Home Network and the range of the Mobile Network Prefixes. Based on that new configuration, the Home Agent can accept a Home Address that is not from the Home Link, and it will know that it should not perform any DAD. In that model, it seems natural to subnet the whole range of addresses into Mobile Network prefixes, as opposed to reserving one prefix for the Home Link, which would boil down to the Extended Home Network model. If the prefix on the Home Link is really an aggregation and not a final prefix, it should not be allowed for autoconfiguration or Home Address allocation. The Mobile Router does not need to join the local IGP when returning home, even if it is using the explicit Prefix Mode. When the Mobile Router is not registered, the Home Agent simply expects that all Mobile Network Nodes (MNNs) will be reachable over the Home Link. Figure 4: Merging the Home and the Mobile Networks As a result, unless the node has a better (longest match) route to a given Mobile Network Prefix, it would look up all MNNs on that MNP using Neighbor Discovery over its interface to the Home Link, and fail. Thus, on the Home Link, the Home Agent must intercept all the packets for ALL the Mobile Network Nodes on the registered prefixes; that is, for ALL nodes attached to Mobile Routers that are away from home. This should be a layer 2 operation, rather than layer 3. The Home Agent might, for example, perform some form of ND proxying for all addresses in all registered Mobile Network Prefixes. The Home Agent must maintain a Binding Cache entry for a Mobile Router and forwarding state for its Mobile Network even when the Mobile Router is directly connected to it. All traffic to and from the Mobile Network is sent through the bi-directional tunnel regardless of the Mobile Router location. This results in a tunneling overhead even though the Mobile Router is connected to the Home Network. In this arrangement, there is a bitwise hierarchy of Home Networks. A global Home Network is advertised to the infrastructure by a head Home Agent(s) and further subnetted into Mobile Networks. As a result, only the Home Agent(s) responsible for the most global (shortest prefix) aggregation receive all the packets for all the MNPs, which are leaves in the hierarchy tree. SFO Home Network Mobile Networks for taxis for taxis <---------------------...---------------------> CAB:C0:5F0:5F0::/64 CAB:C0:5F0:CAB1::/64 CAB:C0:5F0:....::/64 <-------------------><-------------------> ... <-------------------> CAB:C0:5F0:5F0::5F0 | is HA on link with for | each taxi a route like | | CAB:C0:5F0:5F0::CAB1 <------ via is the Home Address of CAB 1 http://www.ietf.org/rfc/rfc4888.txt 4888 Network Mobility Route Optimization Problem Statement. C. Ng, P. Thubert, M. Watari, F. Zhao. July 2007. (Format: TXT=56756 bytes) (Status: INFORMATIONAL) With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the bi-directional tunnel established between the Mobile Router and Home Agent when the mobile network is away. This sub-optimal routing results in various inefficiencies associated with packet delivery, such as increased delay and bottleneck links leading to traffic congestion, which can ultimately disrupt all communications to and from the Mobile Network Nodes. Additionally, with nesting of Mobile Networks, these inefficiencies get compounded, and stalemate conditions may occur in specific dispositions. This document investigates such problems and provides the motivation behind Route Optimization (RO) for NEMO. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. NEMO Route Optimization Problem Statement . . . . . . . . . . 3 2.1. Sub-Optimality with NEMO Basic Support . . . . . . . . . . 4 2.2. Bottleneck in the Home Network . . . . . . . . . . . . . . 6 2.3. Amplified Sub-Optimality in Nested Mobile Networks . . . . 6 2.4. Sub-Optimality with Combined Mobile IPv6 Route Optimization . . . . . . . . . . . . . . . . . . . . . . . 8 2.5. Security Policy Prohibiting Traffic from Visiting Nodes . 9 2.6. Instability of Communications within a Nested Mobile Network . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.7. Stalemate with a Home Agent Nested in a Mobile Network . . 10 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Normative Reference . . . . . . . . . . . . . . . . . . . 12 6.2. Informative Reference . . . . . . . . . . . . . . . . . . 12 Appendix A. Various Configurations Involving Nested Mobile Networks . . . . . . . . . . . . . . . . . . . . . . 13 A.1. CN Located in the Fixed Infrastructure . . . . . . . . . . 13 A.1.1. Case A: LFN and Standard IPv6 CN . . . . . . . . . . . 14 A.1.2. Case B: VMN and MIPv6 CN . . . . . . . . . . . . . . . 14 A.1.3. Case C: VMN and Standard IPv6 CN . . . . . . . . . . . 14 A.2. CN Located in Distinct Nested NEMOs . . . . . . . . . . . 15 A.2.1. Case D: LFN and Standard IPv6 CN . . . . . . . . . . . 16 A.2.2. Case E: VMN and MIPv6 CN . . . . . . . . . . . . . . . 16 A.2.3. Case F: VMN and Standard IPv6 CN . . . . . . . . . . . 16 A.3. MNN and CN Located in the Same Nested NEMO . . . . . . . . 17 A.3.1. Case G: LFN and Standard IPv6 CN . . . . . . . . . . . 18 A.3.2. Case H: VMN and MIPv6 CN . . . . . . . . . . . . . . . 18 A.3.3. Case I: VMN and Standard IPv6 CN . . . . . . . . . . . 19 A.4. CN Located Behind the Same Nested MR . . . . . . . . . . . 19 A.4.1. Case J: LFN and Standard IPv6 CN . . . . . . . . . . . 20 A.4.2. Case K: VMN and MIPv6 CN . . . . . . . . . . . . . . . 20 A.4.3. Case L: VMN and Standard IPv6 CN . . . . . . . . . . . 21 Appendix B. Example of How a Stalemate Situation Can Occur . . . 22 With current Network Mobility (NEMO) Basic Support [1], all communications to and from nodes in a mobile network must go through the bi-directional tunnel established between the Mobile Router and its Home Agent (also known as the MRHA tunnel) when the mobile network is away. Although such an arrangement allows Mobile Network Nodes to reach and be reached by any node on the Internet, limitations associated to the base protocol degrade overall performance of the network and, ultimately, can prevent all communications to and from the Mobile Network Nodes. This document explores limitations inherent in NEMO Basic Support, and their effects on communications between a Mobile Network Node and its corresponding peer. This is detailed in Section 2. It is expected that readers are familiar with general terminologies related to mobility in [4][2], NEMO-related terms defined in [3], and NEMO goals and requirements [5]. Given the NEMO Basic Support protocol, all data packets to and from Mobile Network Nodes must go through the Home Agent, even though a shorter path may exist between the Mobile Network Node and its Correspondent Node. In addition, with the nesting of Mobile Routers, these data packets must go through multiple Home Agents and several levels of encapsulation, which may be avoided. This results in various inefficiencies and problems with packet delivery, which can ultimately disrupt all communications to and from the Mobile Network Nodes. nesting of mobile networks. Closely related to nesting, we will also look into the sub-optimality even when Mobile IPv6 Route Optimization is used over NEMO Basic Support. This is followed by a description of security policy in the Home Network that may forbid transit traffic from Visiting Mobile Nodes in mobile networks. In addition, we will explore the impact of the MRHA tunnel on communications between two Mobile Network Nodes on different links of the same mobile network. We will also provide additional motivations for Route Optimization by considering the potential stalemate situation when a Home Agent is part of a mobile network. With NEMO Basic Support, all packets sent between a Mobile Network Node and its Correspondent Node are forwarded through the MRHA tunnel, resulting in a pinball route between the two nodes. This has the following sub-optimal effects: Because a packet must transit from a mobile network to the Home Agent then to the Correspondent Node, the transit time of the packet is usually longer than if the packet were to go straight from the mobile network to the Correspondent Node. When the Correspondent Node (or the mobile network) resides near the Home Agent, the increase in packet delay can be very small. However, when the mobile network and the Correspondent Node are relatively near to one another but far away from the Home Agent on the Internet, the increase in delay is very large. Applications such as real-time multimedia streaming may not be able to tolerate such increase in packet delay. In general, the increase in delay may also impact the performance of transport protocols such as TCP, since the sending rate of TCP is partly determined by the round- trip time (RTT) perceived by the communication peers. Moreover, by using a longer route, the total resource utilization for the traffic would be much higher than if the packets were to follow a direct path between the Mobile Network Node and Correspondent Node. This would result in additional load in the infrastructure. Under the assumption that each link has the same probability of link failure, a longer routing path would be more susceptible to link failure. Thus, packets routed through the MRHA tunnel may be subjected to a higher probability of being lost or delayed due to link failure, compared to packets that traverse directly between the Mobile Network Node and its Correspondent Node. Apart from the increase in packet delay and infrastructure load, forwarding packets through the Home Agent may also lead to either the Home Agent or the Home Link becoming a bottleneck for the aggregated traffic from/to all the Mobile Network Nodes. A congestion at home would lead to additional packet delay, or even packet loss. In addition, Home Agent operations such as security check, packet interception, and tunneling might not be as optimized in the Home Agent software as plain packet forwarding. This could further limit the Home Agent capacity for data traffic. Furthermore, with all traffic having to pass through the Home Link, the Home Link becomes a single point of failure for the mobile network. A NEMO Route Optimization mechanism that allows the Mobile Network Nodes to communicate with their Correspondent Nodes via a path that is different from the MRHA tunneling and thereby avoiding the Home Agent may alleviate or even prevent the congestion at the Home Agent or Home Link. 2.3. Amplified Sub-Optimality in Nested Mobile Networks By allowing other mobile nodes to join a mobile network, and in particular mobile routers, it is possible to form arbitrary levels of nesting of mobile networks. With such nesting, the use of NEMO Basic Support further amplifies the sub-optimality of routing. We call this the amplification effect of nesting, where the undesirable effects of a pinball route with NEMO Basic Support are amplified with each level of nesting of mobile networks. This is best illustrated by an example shown in Figure 1. Figure 1: An Example of a Nested Mobile Network Using NEMO Basic Support, the flow of packets between a Mobile Network Node, MNN, and a Correspondent Node, CN1, would need to go through three separate tunnels, illustrated in Figure 2 below. Both inbound and outbound packets will flow via the Home Agents of all the Mobile Routers on their paths within the mobile network, with increased latency, less resilience, and more bandwidth usage. Appendix A illustrates in detail the packets' routes under different nesting configurations of the Mobile Network Nodes. When a Mobile IPv6 host joins a mobile network, it becomes a Visiting Mobile Node of the mobile network. Packets sent to and from the Visiting Mobile Node will have to be routed not only via the Home Agent of the Visiting Mobile Node, but also via the Home Agent of the Mobile Router in the mobile network. This suffers the same amplification effect of nested mobile network mentioned in Section 2.3. In addition, although Mobile IPv6 [4] allows a mobile host to perform Route Optimization with its Correspondent Node in order to avoid tunneling with its Home Agent, the "optimized" route is no longer optimized when the mobile host is attached to a mobile network. This is because the route between the mobile host and its Correspondent Node is subjected to the sub-optimality introduced by the MRHA tunnel. Interested readers may refer to Appendix A for examples of how the routes will appear with nesting of Mobile IPv6 hosts in mobile networks. The readers should also note that the same sub-optimality would apply when the mobile host is outside the mobile network and its Correspondent Node is in the mobile network. A Route Optimization mechanism that allows traffic from Mobile Network Nodes to bypass the bi-directional tunnel between a Mobile Router and its Home Agent would be a necessary first step towards a Tit for Tat model, where MRs would benefit from a reciprocal altruism, based on anonymity and innocuousness, to extend the Internet infrastructure dynamically. 2.6. Instability of Communications within a Nested Mobile Network Within a nested mobile network, two Mobile Network Nodes may communicate with each other. Let us consider the previous example illustrated in Figure 1 where MNN and CN2 are sharing a communication session. With NEMO Basic Support, a packet sent from MNN to CN2 will need to be forwarded to the Home Agent of each Mobile Router before reaching CN2, whereas, a packet following the direct path between them need not even leave the mobile network. Readers are referred to Appendix A.3 for detailed illustration of the resulting routing paths. o when the nested mobile network is disconnected from the Internet (e.g., MR1 loses its egress connectivity), MNN and CN2 can no o the egress link(s) of the root Mobile Router (i.e., MR1) becomes a bottleneck for all the traffic that is coming in and out of the nested mobile network. A Route Optimization mechanism could allow traffic between two Mobile Network Nodes nested within the same mobile network to follow a direct path between them, without being routed out of the mobile network. This may also off-load the processing burden of the upstream Mobile Routers when the direct path between the two Mobile Network Nodes does not traverse these Mobile Routers. 2.7. Stalemate with a Home Agent Nested in a Mobile Network Several configurations for the Home Network are described in [10]. In particular, there is a mobile home scenario where a (parent) Mobile Router is also a Home Agent for its mobile network. In other words, the mobile network is itself an aggregation of Mobile Network Prefixes assigned to (children) Mobile Routers. With current NEMO Basic Support, all communications to and from Mobile Network Nodes must go through the MRHA tunnel when the mobile network is away. This results in various inefficiencies associated with packet delivery. This document investigates such inefficiencies and provides the motivation behind Route Optimization for NEMO. We have described the sub-optimal effects of pinball routes with NEMO Basic Support, how they may cause a bottleneck to be formed in the Home Network, and how they get amplified with nesting of mobile networks. These effects will also be seen even when Mobile IPv6 Route Optimization is used over NEMO Basic Support. In addition, other issues concerning the nesting of mobile networks that might provide additional motivation for a NEMO Route Optimization mechanism were also explored, such as the prohibition of forwarding traffic from a Visiting Mobile Node through an MRHA tunnel due to security concerns, the impact of the MRHA tunnel on communications between two Mobile Network Nodes on different links of the same mobile network, and the possibility of a stalemate situation when Home Agents are nested within a mobile network. Appendix A. Various Configurations Involving Nested Mobile Networks In the following sections, we try to describe different communication models that involve a nested mobile network and to clarify the issues for each case. We illustrate the path followed by packets if we assume nodes only use Mobile IPv6 and NEMO Basic Support mechanisms. Different cases are considered where a Correspondent Node is located in the fixed infrastructure, in a distinct nested mobile network as the Mobile Network Node, or in the same nested mobile network as the Mobile Network Node. Additionally, cases where Correspondent Nodes and Mobile Network Nodes are either standard IPv6 nodes or Mobile IPv6 nodes are considered. As defined in [3], standard IPv6 nodes are nodes with no mobility functions whatsoever, i.e., they are not Mobile IPv6 or NEMO enabled. This means that they cannot move around keeping open connections and that they cannot process Binding Updates sent by peers. The most typical configuration is the case where a Mobile Network Node communicates with a Correspondent Node attached in the fixed infrastructure. Figure 3 below shows an example of such topology. The Correspondent Node may be located in another nested mobile network, different from the one MNN is attached to, as shown in Figure 7. We define such configuration as "distinct nested mobile networks". Similar to Case A, we start off with the case where both end nodes do not have any mobility functions. Packets are encapsulated at every Mobile Router on the way out of the nested mobile network, decapsulated by the Home Agents, and then encapsulated again on their way down the nested mobile network. Figure 11 below shows the case where the two communicating nodes are connected behind different Mobile Routers that are connected in the same nested mobile network, and thus behind the same root Mobile Router. Route Optimization can avoid packets being tunneled outside the nested mobile network. Again, we start off with the case where both end nodes do not have any mobility functions. Packets are encapsulated at every Mobile Router on the way out of the nested mobile network via the root Mobile Router, decapsulated and encapsulated by the Home Agents, and then make their way back to the nested mobile network through the same root Mobile Router. Therefore, the path between MNN and CN would go through: Similar to Case H, when both end nodes are Mobile IPv6 nodes, the two nodes may initiate Mobile IPv6 Route Optimization. Although few packets would go out the nested mobile network for the Return Routability initialization, however, unlike Case B and Case E, packets will not get tunneled outside the nested mobile network. Therefore, packets between MNN and CN would eventually go through: When the communication involves a Mobile IPv6 node either as a Visiting Mobile Network Node or as a Correspondent Node, Mobile IPv6 Route Optimization cannot be performed. Therefore, even though the two nodes are on the same link, MNN will establish a bi-directional tunnel with its Home Agent, which causes the flow to go out the nested mobile network. The path between MNN and CN would require another Home Agent (VMN_HA) to go through for this Mobile IPv6 node: Consider a mobility configuration depicted in Figure 19 below. MR1 is served by HA1/BR and MR2 is served by HA2. The 'BR' designation indicates that HA1 is a border router. Both MR1 and MR2 are at home in the initial step. HA2 is placed inside the first mobile network, thus representing a "mobile" Home Agent. In the next step, consider that the MR2's mobile network leaves home and visits a foreign network, under Access Router (AR) like in Figure 20 below. Figure 20: Mobile Network 2 Leaves Home Consider next the attachment of the first mobile network under the second mobile network, like in Figure 21 below. After this movement, MR1 acquires a Care-of Address valid in the second mobile network. Subsequently, it sends a Binding Update (BU) message addressed to HA1. This Binding Update is encapsulated by MR2 and sent towards HA2, which is expected to be placed in mobile net 1 and expected to be at home. Once HA1/BR receives this encapsulated BU, it tries to deliver to MR1. Since MR1 is not at home, and a tunnel has not yet been set up between MR1 and HA1, HA1 is not able to route this packet and drops it. Thus, the tunnel establishment procedure between MR1 and HA1 is not possible, because the tunnel between MR2 and HA2 had been previously torn down (when the mobile net 1 moved from home). The communications between CN and LFN stops, even though both mobile networks are connected to the Internet. http://www.ietf.org/rfc/rfc4889.txt 4889 Network Mobility Route Optimization Solution Space Analysis. C. Ng, F. Zhao, M. Watari, P. Thubert. July 2007. (Format: TXT=95880 bytes) (Status: INFORMATIONAL) With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the Mobile Router and Home Agent (MRHA) tunnel when the mobile network is away. This results in increased length of packet route and increased packet delay in most cases. To overcome these limitations, one might have to turn to Route Optimization (RO) for NEMO. This memo documents various types of Route Optimization in NEMO and explores the benefits and tradeoffs in different aspects of NEMO Route Optimization. 4.1. Additional Signaling Overhead . . . . . . . . . . . . . . 11 4.2. Increased Protocol Complexity and Processing Load . . . . 12 4.3. Increased Delay during Handoff . . . . . . . . . . . . . . 12 4.4. Extending Nodes with New Functionalities . . . . . . . . . 13 4.5. Detection of New Functionalities . . . . . . . . . . . . . 14 4.6. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14 4.7. Mobility Transparency . . . . . . . . . . . . . . . . . . 14 4.8. Location Privacy . . . . . . . . . . . . . . . . . . . . . 15 4.9. Security Consideration . . . . . . . . . . . . . . . . . . 15 4.10. Support of Legacy Nodes . . . . . . . . . . . . . . . . . 15 5. Analysis of Solution Space . . . . . . . . . . . . . . . . . . 16 5.1. Which Entities Are Involved? . . . . . . . . . . . . . . . 16 5.1.1. Mobile Network Node and Correspondent Node . . . . . . 16 5.1.2. Mobile Router and Correspondent Node . . . . . . . . . 17 5.1.3. Mobile Router and Correspondent Router . . . . . . . . 17 5.1.4. Entities in the Infrastructure . . . . . . . . . . . . 18 5.2. Who Initiates Route Optimization? When? . . . . . . . . . 18 5.3. How Is Route Optimization Capability Detected? . . . . . . 19 5.4. How is the Address of the Mobile Network Node Represented? . . . . . . . . . . . . . . . . . . . . . . . 20 5.5. How Is the Mobile Network Node's Address Bound to Location? . . . . . . . . . . . . . . . . . . . . . . . . 20 5.5.1. Binding to the Location of Parent Mobile Router . . . 21 5.5.2. Binding to a Sequence of Upstream Mobile Routers . . . 23 5.5.3. Binding to the Location of Root Mobile Router . . . . 24 5.6. How Is Signaling Performed? . . . . . . . . . . . . . . . 26 5.7. How Is Data Transmitted? . . . . . . . . . . . . . . . . . 27 5.8. What Are the Security Considerations? . . . . . . . . . . 28 5.8.1. Security Considerations of Address Binding . . . . . . 28 5.8.2. End-to-End Integrity . . . . . . . . . . . . . . . . . 30 5.8.3. Location Privacy . . . . . . . . . . . . . . . . . . . 30 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 31 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 9.1. Normative References . . . . . . . . . . . . . . . . . . . 32 9.2. Informative References . . . . . . . . . . . . . . . . . . 33 Network Mobility Route Optimization Problem Statement [1] describes operational limitations and overheads incurred in a deployment of Network Mobility (NEMO) Basic Support [2], which could be alleviated by a set of NEMO Route Optimization techniques to be defined. The term "Route Optimization" is used in a broader sense than already defined for IPv6 Host Mobility in [3] to loosely refer to any approach that optimizes the transmission of packets between a Mobile Network Node and a Correspondent Node. It should be beneficial for readers to keep in mind the design requirements of NEMO [4]. A point to note is that since this document discusses aspects of Route Optimization, the reader may assume that a mobile network or a mobile host is away when they are mentioned throughout this document, unless it is explicitly specified that they are at home. This refers to the entity that a Mobile Router or Mobile Network Node attempts to establish a Route Optimization session with. Depending on the Route Optimization approach, the Correspondent Entity may be a Correspondent Node or Correspondent Router. Route Optimization involves the selection and utilization of a lesser-cost (thus generally shorter and faster) route to be taken for traffic between a Mobile Network Node and its Correspondent Node. Hence, Route Optimization should improve the latency of the data traffic between the two end nodes. This may in turn lead to better overall Quality of Service characteristics, such as reduced jitter and packet loss. If a link along the bi-directional tunnel is disrupted, all traffic to and from the mobile network will be affected until IP routing recovers from the failure. An optimized route would conceivably utilize a smaller number of links between the two end nodes. Hence, the probability of a loss of connectivity due to a single point of failure at a link should be lower as compared to the longer non-optimized route. In a nested mobile network, the application of Route Optimization may eliminate the need for multiple encapsulations required by NEMO Basic Support, which may result in less processing delay at the points of encapsulation and decapsulation. However, it should be taken into consideration that a Route Optimization mechanism may not be an appropriate solution since the Mobile Router may still be held responsible for illegal traffic sent from its Mobile Network Nodes even when Route Optimization is used. In addition, there can be a variety of different policies that might conflict with the deployment of Route Optimization for Visiting Mobile Nodes. Being a policy issue, solving this with a protocol at the policy plane might be more appropriate. [1] described a potential stalemate situation when a Home Agent is nested within a mobile network. Route Optimization may circumvent such stalemate situations by directly forwarding traffic upstream. However, it should be noted that certain Route Optimization schemes may require signaling packets to be first routed via the Home Agent before an optimized route can be established. In such cases, a Route Optimization solution cannot avoid the stalemate. The Non-Nested NEMO Route Optimization involves a Mobile Router sending binding information to a Correspondent Entity. It does not involve nesting of Mobile Routers or Visiting Mobile Nodes. The Correspondent Entity can be a Correspondent Node or a Correspondent Router. The interesting case is when the Correspondent Entity is a Correspondent Router. With the use of Correspondent Router, Route Optimization session is terminated at the Correspondent Router on behalf of the Correspondent Node. As long as the Correspondent Router is located "closer" to the Correspondent Node than the Home Agent of the Mobile Router, the route between Mobile Network Node and the Correspondent Node can be said to be optimized. For this purpose, Correspondent Routers may be deployed to provide an optimal route as illustrated in Figure 1. The Correspondent Router is on the path of the traffic from the Correspondent Node to the Home Agent. In addition, it has an established tunnel with the current Care-of Address (CoA) of the Mobile Router and is aware of the Mobile Network Prefix(es) managed by the Mobile Router. The Correspondent Router can thus intercept packets going to the mobile network, and forward them to the Mobile Router over the established tunnel. A straightforward approach to Route Optimization in NEMO is for the Mobile Router to attempt Route Optimization with a Correspondent Entity. This can be viewed as a logical extension to NEMO Basic Support, where the Mobile Router would send Binding Updates containing one or more Mobile Network Prefix options to the Correspondent Entity. The Correspondent Entity, having received the Binding Update, can then set up a bi-directional tunnel with the Mobile Router at the current Care-of Address of the Mobile Router, and inject a route to its routing table so that packets destined for addresses in the Mobile Network Prefix will be routed through the bi- directional tunnel. The definition of Correspondent Router does not limit it to be a fixed router. Here we consider the case where the Correspondent Router is a Mobile Router. Thus, Route Optimization is initiated and performed between a Mobile Router and its peer Mobile Router. Such solutions are often posed with a requirement to leave the Mobile Network Nodes untouched, as with the NEMO Basic Support protocol, and therefore Mobile Routers handle the optimization management on behalf of the Mobile Network Nodes. Thus, providing Route Optimization for a Visiting Mobile Node is often out of scope for such a scenario because such interaction would require extensions to the Mobile IPv6 protocol. This scenario is illustrated in Figure 2. The Mobile Router locates the Correspondent Router, establishes a tunnel with that Correspondent Router, and sets up a route to the Mobile Network Node via the Correspondent Router over the tunnel. Traffic to the Mobile Networks Nodes would no longer flow through the Home Agents. Optimization in Nested Mobility targets scenarios where a nesting of mobility management protocols is created (i.e., Mobile IPv6-enabled host inside a mobile network or multiple Mobile Routers that attach behind one another creating a nested mobile network). Note that because Mobile IPv6 defines its own Route Optimization mechanism in its base protocol suite as a standard, collaboration between this and NEMO protocols brings various complexities. The aim is to reduce the amplification effect of nested tunnels due to the nesting of tunnels between the Visiting Mobile Node and its Home Agent within the tunnel between the parent Mobile Router and the parent Mobile Router's Home Agent. Such a solution will seek to minimize the number of tunnels, possibly by collapsing the amount of tunnels required through some form of signaling between Mobile Nodes, or between Mobile Nodes and their Home Agents, or by using routing headers to route packets through a discovered path. These limit the consequences of the amplification effect of nested tunnels, and at best, the performance of a nested mobile network will be the same as though there were no nesting at all. An infrastructure-based optimization is an approach where optimization is carried out fully in the infrastructure. One example is to make use of Mobility Anchor Points (MAPs) such as defined in HMIPv6 [13] to optimize routes between themselves. Another example is to make use of proxy Home Agent such as defined in the global Home Agent to Home Agent (HAHA) protocol [14]. A proxy Home Agent acts as a Home Agent for the Mobile Node, and acts as a Mobile Node for the Home Agent, Correspondent Node, Correspondent Router, and other proxies. In particular, the proxy Home Agent terminates the MRHA tunnel and the associated encryption, extracts the packets, and re- encapsulates them to the destination. In this case, proxy Home Agents are distributed in the infrastructure and each Mobile Router binds to the closest proxy. The proxy, in turn, performs a primary binding with a real Home Agent for that Mobile Router. Then, the proxy might establish secondary bindings with other Home Agents or proxies in the infrastructure, in order to improve the end-to-end path. In this case, the proxies discover each other using some form of Next Hop Resolution Protocol, establish a tunnel and exchange the relevant Mobile Network Prefix information in the form of explicit prefix routes. Alternatively, another approach is to use prefix delegation. Here, each Mobile Router in a nested mobile network is delegated a Mobile Network Prefix from the access router using DHCP Prefix Delegation [15]. Each Mobile Router also autoconfigures its Care-of Address from this delegated prefix. In this way, the Care-of Addresses of each Mobile Router are all formed from an aggregatable address space A Route Optimization solution may seek to improve the communications between two Mobile Network Nodes within a nested mobile network. This would avoid traffic being injected out of the nested mobile network and route them within the nested mobile network. An example is the optimized route taken between MNN1 and MNN2 in Figure 3 below. Figure 3: An Example of a Nested Mobile Network treat MR5 as Correspondent Routers for MNN2, and MR5 treats MR3 and MR2 as Correspondent Routers for MNN1. An example of this approach is [16], which has the Mobile Routers announce their Mobile Network Prefixes to other Mobile Routers in the same nested Mobile Network. Yet another approach is to flatten any nested Mobile Network so that all nested Mobile Network Nodes appear to be virtually on the same link. Examples of such approaches include delegating a single prefix to the nested Mobile Network, having Mobile Routers to perform Neighbor Discovery on behalf of their Mobile Network Nodes, and exposing a single prefix over the entire mobile network using a Mobile Ad-Hoc (MANET) protocol. In particular, it might prove useful to develop a new type of MANET, specialized for the NEMO problem, a MANET for NEMO (MANEMO). The MANEMO will optimize the formation of the nested NEMO and maintain inner connectivity, whether or not a connection to the infrastructure can be established. The nodes involved in performing Route Optimization would be expected to exchange additional signaling messages in order to establish Route Optimization. The required amount of signaling depends on the solution, but is likely to exceed the amount required in the home Binding Update procedure defined in NEMO Basic Support. The amount of signaling is likely to increase with the increasing number of Mobile Network Nodes and/or Correspondent Nodes, and may be amplified with nesting of mobile networks. It may scale to unacceptable heights, especially to the resource-scarce mobile node, which typically has limited power, memory, and processing capacity. This may lead to an issue that impacts NEMO Route Optimization, known as the phenomenon of "Binding Update Storm", or more generally, "Signaling Storm". This occurs when a change in point of attachment of the mobile network is accompanied with a sudden burst of signaling messages, resulting in temporary congestion, packet delays, or even packet loss. This effect will be especially significant for wireless environment where bandwidth is relatively limited. Even so, the amount of signaling required might be overwhelming, since large mobile networks (such as those deployed on a train or plane) may potentially have a large number of flows with a large number of Correspondent Nodes. This might suggest a need to have some adaptive behavior that depends on the amount of signaling required versus the effort needed to tunnel home. Due to the diversity of locations of different nodes that Mobile Network Node may signal with and the complexity of NEMO Route Optimization procedure that may cause several rounds of signaling messages, a NEMO Route Optimization procedure may take a longer time to finish its handoff than that in NEMO Basic Support. This may exacerbate the overall delay during handoffs and further cause performance degradation of the applications running on Mobile Network Nodes. Another NEMO-specific delay during handoff is that in a nested mobile network, a child Mobile Network Node may need to detect or be notified of the handoff of its parent Mobile Router so that it can begin signaling its own Correspondent Entities. Apart from the compromise of mobility transparency and location privacy (see Section 4.7 and Section 4.8), this mechanism also increases the delay during handoffs. Given the same number of nodes, the number of Route Optimization sessions would usually be more than the number of NEMO Basic Support tunnels. If all Route Optimization sessions of a mobile network are maintained by a single node (such as the Mobile Router), this would mean that the single node has to keep track of the states of all Route Optimization sessions. This may lead to scalability issues especially when that single node is a mobile device with limited memory and processing resources. One advantage of NEMO Basic Support is that the Mobile Network Nodes need not be aware of the actual location and mobility of the mobile network. With some approaches for Route Optimization, it might be necessary to reveal the point of attachment of the Mobile Router to the Mobile Network Nodes. This may mean a tradeoff between mobility transparency and Route Optimization. Without Route Optimization, the Correspondent Nodes are not aware of the actual location and mobility of the mobile network and its Mobile Network Nodes. To achieve Route Optimization, it might be necessary to reveal the point of attachment of the Mobile Router to the Correspondent Nodes. This may mean a tradeoff between location privacy [18] and Route Optimization. In Mobile IPv6, a mobile node can decide whether or not to perform Route Optimization with a given Correspondent Node. Thus, the mobile node is in control of whether to trade location privacy for an optimized route. In NEMO Route Optimization, if the decision to perform Router Optimization is made by the Mobile Router, it will be difficult for Mobile Network Nodes to control the decision of having this tradeoff. NEMO Basic Support is designed so that all legacy Mobile Network Nodes (such as those that are not aware of the mobility of the network they are in, and those that do not understand any mobility protocols) can still reach and be reached from the Internet. Some Route Optimization schemes, however, require that all Mobile Routers implement the same Route Optimization scheme in order for them to operate. Thus, a nested Mobile Router may not be able to achieve Route Optimization if it is attached to a legacy Local Fixed Router. 4. How is the address of the Mobile Network Node represented? 5. How is the Mobile Network Node's address bound to location? o Mobile Network Node and Correspondent Node 5.1.1. Mobile Network Node and Correspondent Node A Mobile Network Node can establish Route Optimization with its Correspondent Node, possibly the same way as a Mobile Node establishes Route Optimization with its Correspondent Node in Mobile IPv6. This would achieve the most optimal route, since the entire end-to-end path is optimized. However, there might be scalability issues since both the Mobile Network Node and the Correspondent Node may need to maintain many Route Optimization sessions. In addition, new functionalities would be required for both the Mobile Network Node and Correspondent Node. For the Mobile Network Node, it needs to be able to manage its mobility, and possibly be aware of the mobility of its upstream Mobile Router(s). For the Correspondent Node, it needs to be able to maintain the bindings sent by the Mobile Network Nodes. Alternatively, the Mobile Router can establish Route Optimization with a Correspondent Node on behalf of the Mobile Network Node. Since all packets to and from the Mobile Network Node must transit the Mobile Router, this effectively achieves an optimal route for the entire end-to-end path as well. Compared with Section 5.1.1, the scalability issue here may be remedied since it is possible for the Correspondent Node to maintain only one session with the Mobile Router if it communicates with many Mobile Network Nodes associated with the same Mobile Router. Furthermore, with the Mobile Router handling Route Optimization, there is no need for Mobile Network Nodes to implement new functionalities. However, new functionality is likely to be required on the Correspondent Node. An additional point of consideration is the amount of state information the Mobile Router is required to maintain. Traditionally, it has been generally avoided having state information in the routers to increase proportionally with the number of pairs of communicating peers. Approaches involving Mobile Routers and Correspondent Routers are described in Section 3.1. The advantage of these approaches is that no additional functionality is required for the Correspondent Node and Mobile Network Nodes. In addition, location privacy is relatively preserved, since the current location of the mobile network is only revealed to the Correspondent Router and not to the Correspondent Node (please refer to Section 5.8.3 for more discussions). Furthermore, if the Mobile Router and Correspondent Router exchange prefix information, this approach may scale well since a single Route Optimization session between the Mobile Router and Correspondent Router can achieve Route Optimization between any Mobile Network Node in the mobile network, and any Correspondent Node managed by the Correspondent Router. Approaches using entities in the infrastructure are described in Section 3.3. The advantages of this approach include, firstly, not requiring new functionalities to be implemented on the Mobile Network Nodes and Correspondent Nodes, and secondly, having most of the complexity shifted to nodes in the infrastructure. However, one main issue with this approach is how the Mobile Router can detect the presence of such entities, and why the Mobile Router should trust these entities. This may be easily addressed if such entity is a Home Agent of the Mobile Router (such as in the global Home Agent to Home Agent protocol [14]). Another concern is that the resulting path may not be a true optimized one, since it depends on the relative positions of the infrastructure entities with respect to the mobile network and the Correspondent Node. Having determined the entities involved in the Route Optimization in the previous sub-section, the next question is which of these entities should initiate the Route Optimization session. Usually, the node that is moving (i.e., Mobile Network Node or Mobile Router) is in the best position to detect its mobility. Thus, in general, it is better for the mobile node to initiate the Route Optimization session in order to handle the topology changes in any kind of mobility pattern and achieve the optimized route promptly. However, when the mobile node is within a nested mobile network, the detection of the mobility of upstream Mobile Routers may need to be conveyed to the nested Mobile Network Node. This might incur longer signaling delay as discussed in Section 4.3. 5.4. How is the Address of the Mobile Network Node Represented? Normally, Route Optimization would mean that a binding between the address of a Mobile Network Node and the location of the mobile network is registered at the Correspondent Entity. Before exploring different ways of binding (see Section 5.5), one must first ask how the address of the Mobile Network Node is represented. Basically, there are two ways to represent the Mobile Network Node's address: o inferred by the use of the Mobile Network Prefix, or o explicitly specifying the address of the Mobile Network Node. Using the Mobile Network Prefix would usually mean that the initiator is the Mobile Router, and has the benefit of binding numerous Mobile Network Nodes with one signaling. However, it also means that if location privacy is compromised, the location privacy of an entire Mobile Network Prefix would be compromised. On the other hand, using the Mobile Network Node's address would mean that either the initiator is the Mobile Network Node itself or the Mobile Router is initiating Route Optimization on behalf of the Mobile Network Node. Initiation by the Mobile Network Node itself means that the Mobile Network Node must have new functionalities implemented, while initiation by the Mobile Router means that the Mobile Router must maintain some Route Optimization states for each Mobile Network Node. 5.5. How Is the Mobile Network Node's Address Bound to Location? In order for route to be optimized, it is generally necessary for the Correspondent Entity to create a binding between the address and the location of the Mobile Network Node. This can be done in the following ways: By binding the address of Mobile Network Node to the location of its parent Mobile Router, the Correspondent Entity would know how to reach the Mobile Network Node via the current location of the parent Mobile Router. This can be done by: o Binding Update with Mobile Network Prefix This can be viewed as a logical extension to NEMO Basic Support, where the Mobile Router would send binding updates containing one or more Mobile Network Prefix options to the Correspondent Entity. The Correspondent Entity having received the Binding Update, can then set up a bi-directional tunnel with the Mobile Router at the current Care-of Address of the Mobile Router, and inject a route to its routing table so that packets destined for addresses in the Mobile Network Prefix would be routed through the bi-directional tunnel. Note that in this case, the address of the Mobile Network Node is implied by the Mobile Network Prefix (see Section 5.4). This involves the Mobile Network Node sending the information of its Mobile Router to the Correspondent Entity, thus allowing the Correspondent Entity to establish a binding between the address of the Mobile Network Node to the location of the parent Mobile Router. An example of such an approach would be [11]. Another approach is for the parent Mobile Router to act as a "proxy" for its Mobile Network Nodes. In this case, the Mobile Router uses the standard Mobile IPv6 Route Optimization procedure to bind the address of a Mobile Network Node to the Mobile Router's Care-of Address. For instance, when the Mobile Network Node is a Local Fixed Node without Mobile IPv6 Route Optimization functionality, the Mobile Router may initiate the Return Routability procedure with a Correspondent Node on behalf of the Local Fixed Node. An example of such an approach would be [20][21][22]. On the other hand, if the Mobile Network Node is a Visiting Mobile Node, it might be necessary for the Visiting Mobile Node to delegate the rights of Route Optimization signaling to the Mobile Router (see [23] for an example of such delegation). With this delegation, either the Visiting Mobile Network Node or the Mobile Router can initiate the Return Routability procedure with the Correspondent Node. For the case where the Return Routability procedure is initiated by the Visiting Mobile Node, the Mobile Router will have to transparently alter the content of the Return Routability signaling messages so that packets sent from the Correspondent Node to the Visiting Node will be routed to the Care-of Address of the Mobile Router once Route Optimization is established. The case where the Return Routability procedure is initiated by the Mobile Router is similar to the case where the Mobile Network Node is a Local Fixed Node. For all of the approaches listed above, when the Mobile Network Node is deeply nested within a Mobile Network, the Correspondent Entity would need to gather Binding Updates from all the upstream Mobile Routers in order to build the complete route to reach the Mobile Network Node. This increases the complexity of the Correspondent Entity, as the Correspondent Entity may need to perform multiple binding cache look-ups before it can construct the complete route. Other than increasing the complexity of the Correspondent Entity, these approaches may incur extra signaling overhead and delay for a nested Mobile Network Node. For instance, every Mobile Router on the upstream of the Mobile Network Node needs to send Binding Updates to the Correspondent Entity. If this is done by the upstream Mobile Routers independently, it may incur additional signaling overhead. Also, since each Binding Update takes a finite amount of time to reach and be processed by the Correspondent Entity, the delay from the time an optimized route is changed till the time the change is registered on the Correspondent Entity will increase proportionally with the number of Mobile Routers on the upstream of the Mobile Network Node (i.e., the level of nesting of the Mobile Network Node). For "Binding Update with Mobile Network Prefix" and "Sending Information of Parent Mobile Router", new functionality is required at the Correspondent Entity, whereas "Mobile Router as a Proxy" keeps the functionality of the Correspondent Entity the same as a Mobile IPv6 Correspondent Node. However, this is done at an expense of the Mobile Routers, since in "Mobile Router as a Proxy", the Mobile Router must maintain state information for every Route Optimization session its Mobile Network Nodes have. Furthermore, in some cases, the Mobile Router needs to look beyond the standard IPv6 headers for ingress and egress packets, and alter the packet contents appropriately (this may impact end-to-end integrity, see 5.8.2). In addition, having upstream Mobile Routers send Binding Updates independently means that the Correspondent Entity can use the same binding cache entries of upstream Mobile Routers to construct the complete route to two Mobile Network Nodes that have common upstream Mobile Routers. This may translate to lower memory consumption since the Correspondent Entity need not store one complete route per Mobile Network Node when it is having Route Optimization sessions with multiple Mobile Network Nodes from the same mobile network. For a nested Mobile Network Node, it might be more worthwhile to bind its address to the sequence of points of attachment of upstream Mobile Routers. In this way, the Correspondent Entity can build a complete sequence of points of attachment from a single transmission of the binding information. Examples using this approach are [10] and [12]. Different from Section 5.5.1, this approach constructs the complete route to a specific Mobile Network Node at the mobile network side, thus offering the opportunity to reduce the signaling overhead. Since the complete route is conveyed to the Correspondent Entity in a single transmission, it is possible to reduce the delay from the time an optimized route is changed till the time the change is registered on the Correspondent Entity to its minimum. One question that immediately comes to mind is how the Mobile Network Node gets hold of the sequence of locations of its upstream Mobile Routers. This is usually achieved by having such information inserted as special options in the Router Advertisement messages advertised by upstream Mobile Routers. To do so, not only must a Mobile Router advertise its current location to its Mobile Network Nodes, it must also relay information embedded in Router Advertisement messages it has received from its upstream Mobile Routers. This might imply a compromise of the mobility transparency of a mobile network (see Section 4.7). In addition, it also means that whenever an upstream Mobile Router changes its point of attachment, all downstream Mobile Network Nodes must perform Route Optimization signaling again, possibly leading to a "Signaling Storm" (see Section 4.1). within a packet sent by the Mobile Network Node. This may raise security concerns that will be discussed later in Section 5.8.2. In order for a Correspondent Entity to bind the address of a Mobile Network Node to a sequence of locations of upstream Mobile Routers, new functionalities need to be implemented on the Correspondent Entity. The Correspondent Entity also needs to store the complete sequence of locations of upstream Mobile Routers for every Mobile Network Node. This may demand more memory compared to Section 5.5.1 if the same Correspondent Entity has a lot of Route Optimization sessions with Mobile Network Nodes from the same nested Mobile Network. In addition, some amount of modifications or extension to existing protocols is also required, such as a new type of IPv6 routing header or a new option in the Router Advertisement message. A third approach is to bind the address of the Mobile Network Node to the location of the root Mobile Router, regardless of how deeply nested the Mobile Network Node is within a nested Mobile Network. Whenever the Correspondent Entity needs to forward a packet to the Mobile Network Node, it only needs to forward the packet to this point of attachment. The mobile network will figure out how to forward the packet to the Mobile Network Node by itself. This kind of approach can be viewed as flattening the structure of a nested Mobile Network, so that it seems to the Correspondent Entity that every node in the Mobile Network is attached to the Internet at the same network segment. Here, each Mobile Router in a nested mobile network is delegated a Mobile Network Prefix from the access router (such as using Dynamic Host Configuration Protocol (DHCP) Prefix Delegation [15]). Each Mobile Router also autoconfigures its Care-of Address from this delegated prefix. In this way, the Care-of Addresses of Mobile Routers are all from an aggregatable address space starting from the access router. A Mobile Network Node with Mobile IPv6 functionality may also autoconfigure its Care-of Address from this delegated prefix, and use standard Mobile IPv6 mechanism's to bind its Home Address to this Care-of Address. router (or some other entity within the access network) and Mobile Router to possess prefix delegation functionality, and also maintain information on what prefix is delegated to which node. How to efficiently assign a subset of Mobile Network Prefix to child Mobile Routers could be an issue because Mobile Network Nodes may dynamically join and leave with an unpredictable pattern. In addition, a change in the point of attachment of the root Mobile Router will also require every nested Mobile Router (and possibly Visiting Mobile Nodes) to change their Care-of Addresses and delegated prefixes. These will cause a burst of Binding Updates and prefix delegation activities where every Mobile Router and every Visiting Mobile Node start sending Binding Updates to their Correspondent Entities. This approach (such as [27] and [28]) achieves Route Optimization by having the Mobile Router act as a Neighbor Discovery [29] proxy for its Mobile Network Nodes. The Mobile Router will configure a Care-of Address from the network prefix advertised by its access router, and also relay this prefix to its subnets. When a Mobile Network Node configures an address from this prefix, the Mobile Router will act as a Neighbor Discovery proxy on its behalf. In this way, the entire mobile network and its access network form a logical multilink subnet, thus eliminating any nesting. This approach has the advantage of keeping the implementations of Correspondent Nodes unchanged. However, it requires the root Mobile Router to act as a Neighbor Discovery proxy for all the Mobile Network Nodes that are directly or indirectly attached to it. This increases the processing load of the root Mobile Router. In addition, a change in the point of attachment of the root Mobile Router will require every nested Mobile Router (and possibly Visiting Mobile Nodes) to change their Care-of Addresses. Not only will this cause a burst of Binding Updates where every Mobile Router and every Visiting Mobile Node start sending Binding Updates to their Correspondent Entities, it will also cause a burst of Duplicate Address Discovery messages to be exchanged between the mobile network and the access network. Furthermore, Route Optimization for Local Fixed Nodes is not possible without new functionalities implemented on the Local Fixed Nodes. Hierarchical Registration involves Mobile Network Nodes (including nested Mobile Routers) registering themselves with either their parent Mobile Routers or the root Mobile Router itself. After registrations, Mobile Network Nodes would tunnel packets directly to the upstream Mobile Router they register with. At the root Mobile Router, packets tunneled from sub-Mobile Routers or Mobile Network Nodes are tunneled directly to the Correspondent Entities, thus avoiding nested tunneling. It is possible for nodes within a mobile network to use Mobile Ad- hoc routing for packet-forwarding between nodes in the same mobile network. An approach of doing so might involve a router acting as a gateway for connecting nodes in the mobile network to the global Internet. All nodes in the mobile network would configure their Care-of Addresses from one or more prefixes advertised by that gateway, while their parent Mobile Routers use Mobile Ad-hoc routing to forward packets to that gateway or other destinations inside the mobile network. One advantage that is common to all the approaches listed above is that local mobility of a Mobile Network Node within a nested mobile network is hidden from the Correspondent Entity. The advantage of in-plane signaling is that any change in the mobile network topology can be rapidly propagated to the Correspondent Entity as long as there is a continuous stream of data to be transmitted. However, this might incur a substantial overhead on the data packets. Off-plane signaling, on the other hand, sends signaling messages independently from the data packet. This has the advantage of reducing the signaling overhead in situations where there are relatively fewer topological changes to the mobile network. However, data packet transmission may be disrupted while off-plane signaling takes place. An entirely different method of signaling makes use of upper-layer protocols to establish the bindings between the address of a Mobile Network Node and the location of the mobile network. Such binding information can then be passed down to the IP layer to insert the appropriate entry in the Binding Cache or routing table. An example of such a mechanism is [34], which uses the Session Initiation Protocol (SIP) to relay binding information. One way to route packets through the optimized path is to use IP- in-IP encapsulations [35]. In this way, the original packet can be tunneled to the location bound to the address of the Mobile Network Node using the normal routing infrastructure. Depending on how the location is bound to the address of the Mobile Network Node, the number of encapsulations required might vary. contain multiple intermediate destinations. Each intermediate destination corresponds to a point of attachment bound to the address of the Mobile Network Node. The most important security consideration in Route Optimization is certainly the security risks a Correspondent Entity is exposed to by creating a binding between the address of a Mobile Network Node and the specified location(s) of the mobile network. Generally, it is assumed that the Correspondent Entity and Mobile Network Node do not share any pre-existing security association. However, the Correspondent Entity must have some ways of verifying the authenticity of the binding specified, else it will be susceptible to various attacks described in [19], such as snooping (sending packets meant for a Mobile Network Node to an attacker) or denial-of-service (DoS) (flooding a victim with packets meant for a Mobile Network Node) attacks. When the binding is performed between the address of the Mobile Network Node and one Care-of Address (possibly of the Mobile Router; see Section 5.5.1 and Section 5.5.3), the standard Return Routability procedure specified in Mobile IPv6 might be sufficient to provide a reasonable degree of assurance to the Correspondent Entity. This also allows the Correspondent Entity to re-use existing implementations. But in other situations, an extension to the Return Routability procedure might be necessary. For instance, consider the case where the Mobile Router sends a Binding Update containing Mobile Network Prefix information to the Correspondent Entity (see Section 5.5.1). Although the Return Routability procedure allows the Correspondent Entity to verify that the Care-of and Home Addresses of the Mobile Router are indeed collocated, it does not allow the Correspondent Entity to verify the validity of the Mobile Network Prefix. If the Correspondent Entity accepts the binding without verification, it will be exposed to attacks where the attacker tricks the Correspondent Entity into forwarding packets destined for a mobile network to the attacker (snooping) or victim (DoS); [39] discusses this security threat further. The need to verify the validity of network prefixes is not constrained to Correspondent Entities. In approaches that involve the Correspondent Routers (see Section 5.1.3), there have been suggestions for the Correspondent Router to advertise the network prefix(es) of Correspondent Nodes that the Correspondent Router is capable of terminating Route Optimization on behalf of to Mobile Network Nodes. In such cases, the Mobile Network Nodes also need a mechanism to check the authenticity of such claims. Even if the Correspondent Routers do not advertise the network prefix, the Mobile Network Nodes also have the need to verify that the Correspondent Router is indeed a valid Correspondent Router for a given Correspondent Node. In Section 5.5.2, the registration signaling involves sending the information about one or more upstream Mobile Routers. The Correspondent Entity (or Home Agent) must also have the means to verify such information. Again, the standard Return Routability procedure as defined in [3] is inadequate here, as it is not designed to verify the reachability of an address over a series of upstream routers. An extension such as attaching a routing header to the Care-of Test (CoT) message to verify the authenticity of the locations of upstream Mobile Routers is likely to be needed. The risk, however, is not confined to Correspondent Entities. The Mobile Network Nodes are also under the threat of receiving false information from their upstream Mobile Routers, which they might pass to Correspondent Entities (this also implies that Correspondent Entities cannot rely on any security associations they have with the Mobile Network Nodes to establish the validity of address bindings). There are some considerations that this kind of on-path threat exists in the current Internet anyway especially when no (or weak) end-to- end protection is used. ownership of Care-of Addresses. [42] employs the Home Agent to check the signaling messages sent by Mobile Routers to provide a way for Correspondent Entities to verify the authenticity of Mobile Network Prefixes specified. [18] documents various proposed enhancements to the Mobile IPv6 Route Optimization mechanism that might be applied to NEMO Route Optimization as well, such as [43], which allows the Correspondent Entity to authenticate a certain operator's Home Agent by verifying the associated certificate. The Host Identity Protocol (HIP) [44] with end-host mobility considerations [45] may be extended for NEMO Route Optimization as well. In addition, interested readers might want to refer to [46], which discussed the general problem of making Route Optimization in NEMO secure and explored some possible solution schemes. There is also a proposed mechanism in [23] for Mobile Network Node to delegate some rights to their Mobile Routers, which may be used to allow the Mobile Routers to prove their authenticities to Correspondent Entities when establishing Route Optimization sessions on behalf of the Mobile Network Nodes. In some of the approaches, such as "Mobile Router as a Proxy" in Section 5.5.1, the Mobile Router sends messages using the Mobile Network Node's address as the source address. This is done mainly to achieve zero new functionalities required at the Correspondent Entities and the Mobile Network Nodes. However, adopting such a strategy may interfere with existing or future protocols, most particularly security-related protocols. This is especially true when the Mobile Router needs to make changes to packets sent by Mobile Network Nodes. In a sense, these approaches break the end-to- end integrity of packets. A related concern is that this kind of approach may also require the Mobile Router to inspect the packet contents sent to/by Mobile Network Nodes. This may prove to be difficult or impossible if such contents are encrypted. The concern over end-to-end integrity arises for the use of a Reverse Routing Header (see Section 5.5.2) too, since Mobile Routers would insert new contents to the header of packets sent by downstream Mobile Network Nodes. This makes it difficult for Mobile Network Nodes to protect the end-to-end integrity of such information with security associations. Route optimization is achieved by creating a binding between the address of the Mobile Network Node and the current location of the Mobile Network. It is thus inevitable that the location of the Mobile Network Node be revealed to the Correspondent Entity. The concern may be alleviated if the Correspondent Entity is not the Correspondent Node, since this implies that the actual traffic end point (i.e., the Correspondent Node) would remain ignorant of the current location of the Mobile Network Node. With network mobility, the degree of location exposure varies, especially when one considers nested mobile networks. For instance, for approaches that bind the address of the Mobile Network Node to the location of the root Mobile Router (see Section 5.5.3), only the topmost point of attachment of the mobile network is revealed to the Correspondent Entity. For approaches such as those described in Section 5.5.1 and Section 5.5.2, more information (such as Mobile Network Prefixes and current locations of upstream Mobile Routers) is revealed. Techniques such as exposing only locally-scoped addresses of intermediate upstream mobile routers to Correspondent Entities may be used to reduce the degree of revelation. When Route Optimization is initiated by the Mobile Network Node itself, it is in control of whether or not to sacrifice location privacy for an optimized route. However, if it is the Mobile Router that initiates Route Optimization (e.g., "Binding Update with Mobile Network Prefix" and "Mobile Router as a Proxy" in Section 5.5.1), then control is taken away from the Mobile Network Node. An additional signaling mechanism between the Mobile Network Node and its Mobile Router can be used in this case to prevent the Mobile Router from attempting Route Optimization for a given traffic stream. [10] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and its application to Mobile Networks", Work in Progress, February 2007. [16] Baek, S., Yoo, J., Kwon, T., Paik, E., and M. Nam, "Routing Optimization in the same nested mobile network", Work in Progress, October 2005. [25] Lee, K., Park, J., and H. Kim, "Route Optimization for Mobile Nodes in Mobile Network based on Prefix Delegation", 58th IEEE Vehicular Technology Conference, vol 3, pp 2035-2038, October 2003. [26] Lee, K., Jeong, J., Park, J., and H. Kim, "Route Optimization for Mobile Nodes in Mobile Network based on Prefix Delegation", Work in Progress, February 2004. [27] Jeong, J., Lee, K., Park, J., and H. Kim, "Route Optimization based on ND-Proxy for Mobile Nodes in IPv6 Mobile Network", 59th IEEE Vehicular Technology Conference, vol 5, pp 2461-2465, May 2004. [28] Jeong, J., Lee, K., Kim, H., and J. Park, "ND-Proxy based Route Optimization for Mobile Nodes in Mobile Network", Work in Progress, February 2004. [30] Kang, H., Kim, K., Han, S., Lee, K., and J. Park, "Route Optimization for Mobile Network by Using Bi-directional Between Home Agent and Top Level Mobile Router", Work in Progress, June 2003. [31] Lee, D., Lim, K., and M. Kim, "Hierarchical FRoute Optimization for Nested Mobile Network", 18th Int'l Conf on Advance Information Networking and Applications, vol 1, pp 225-229, 2004. [33] Ohnishi, H., Sakitani, K., and Y. Takagi, "HMIP based Route optimization method in a mobile network", Work in Progress, October 2003. http://www.ietf.org/rfc/rfc4908.txt 4908 Multi-homing for small scale fixed network Using Mobile IP and NEMO. K. Nagami, S. Uda, N. Ogashiwa, H. Esaki, R. Wakikawa, H. Ohnishi. June 2007. (Format: TXT=20230 bytes) (Status: EXPERIMENTAL) Multihoming technology improves the availability of host and network connectivity. Since the behaviors of fixed and mobile networks differ, distinct architectures for each have been discussed and proposed. This document proposes a common architecture for both mobile and fixed networking environments, using mobile IP (RFC 3775) and Network Mobility (NEMO; RFC 3963). The proposed architecture requires a modification of mobile IP and NEMO so that multiple Care- of Addresses (CoAs) can be used. In addition, multiple Home Agents (HAs) that are located in different places are required for redundancy. Basically, mobile IP (MIP) and NEMO have been proposed for mobile hosts or mobile networks; however, their architecture and protocol can be used for fixed networks and to solve the problems mentioned above. The details of the solution are described in the sections below. 2.1. Mobile Network Includes Fixed Network In the proposed architecture, the xSP (Multihomed Service Provider) is introduced. The xSP is a conceptual service provider; it doesn't have to be connected to the Internet physically for all practical purposes. xSP has one or more aggregatable mobile network prefixes. xSP contracts with some ISPs that are physically connected to the Internet. The purpose of this contract is to set up some HAs in those ISPs' networks. Those HAs announce the xSP's aggregated mobile network prefixes. This means that HAs work just like border gateway routers, and this situation is the same as peering between the ISP and xSP. In this case, the origin Autonomous System (AS) announced from the HAs is the xSP. On the other hand, a multihomed user (a small office user or home user) contracts with the xSP to acquire a mobile network prefix from the xSP. Each multihomed user has an MR and multiple L3 connectivity to the Internet via multiple ISPs, and the MR will establish multiple tunnels to the HA. Since the user's mobile network prefixes are aggregated and announced from the HA, the packets to the user's mobile network will be sent to the nearest HA depending on global routing information at that time. The HA that received such packets will forward them to the user's network over the established multiple tunnels. http://www.ietf.org/rfc/rfc4968.txt 4968 Analysis of IPv6 Link Models for 802.16 Based Networks. S. Madanapalli, Ed.. August 2007. (Format: TXT=34536 bytes) (Status: INFORMATIONAL) Support for dormant MSs is critical in mobile networks, hence it is a necessary feature. Paging capability and optimizations possible for paging an MS are neither enhanced nor handicapped by the link model itself. However, the multicast capability within a link may cause for an MS to wake up for an unwanted packet. This can be avoided by filtering the multicast packets and delivering the packets to only for MSs that are listening for particular multicast packets. As the Shared IPv6 Prefix model does not have the multicast capability and the point-to-point link model has only one node on the link, neither has any effect on the dormant mode. The Ethernet-like link model may have the multicast capability, which requires filtering at the BS to support the dormant mode for the MSs. http://www.ietf.org/rfc/rfc4980.txt 4980 Analysis of Multihoming in Network Mobility Support. C. Ng, T. Ernst, E. Paik, M. Bagnulo. October 2007. (Format: TXT=88572 bytes) (Status: INFORMATIONAL) This document is an analysis of multihoming in the context of network mobility (NEMO) in IPv6. As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations. The possible deployment scenarios of multihomed mobile networks are described together with the associated issues when network mobility is supported by RFC 3963 (NEMO Basic Support). Recommendations are offered on how to address these issues. 3. Deployment Scenarios and Prerequisites . . . . . . . . . . . . 11 3.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 11 3.2. Prerequisites . . . . . . . . . . . . . . . . . . . . . . 13 4. Multihoming Issues . . . . . . . . . . . . . . . . . . . . . . 14 4.1. Fault Tolerance . . . . . . . . . . . . . . . . . . . . . 14 4.1.1. Failure Detection . . . . . . . . . . . . . . . . . . 15 4.1.2. Path Exploration . . . . . . . . . . . . . . . . . . . 16 4.1.3. Path Selection . . . . . . . . . . . . . . . . . . . . 17 4.1.4. Re-Homing . . . . . . . . . . . . . . . . . . . . . . 19 4.2. Ingress Filtering . . . . . . . . . . . . . . . . . . . . 19 4.3. HA Synchronization . . . . . . . . . . . . . . . . . . . . 21 4.4. MR Synchronization . . . . . . . . . . . . . . . . . . . . 22 4.5. Prefix Delegation . . . . . . . . . . . . . . . . . . . . 23 4.6. Multiple Bindings/Registrations . . . . . . . . . . . . . 23 4.7. Source Address Selection . . . . . . . . . . . . . . . . . 23 4.8. Loop Prevention in Nested Mobile Networks . . . . . . . . 24 4.9. Prefix Ownership . . . . . . . . . . . . . . . . . . . . . 24 4.10. Preference Settings . . . . . . . . . . . . . . . . . . . 25 5. Recommendations to the Working Group . . . . . . . . . . . . . 26 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 9.2. Informative References . . . . . . . . . . . . . . . . . . 29 Appendix A. Alternative Classifications Approach . . . . . . . . 32 A.1. Ownership-Oriented Approach . . . . . . . . . . . . . . . 32 A.1.1. ISP Model . . . . . . . . . . . . . . . . . . . . . . 32 A.1.2. Subscriber/Provider Model . . . . . . . . . . . . . . 33 A.2. Problem-Oriented Approach . . . . . . . . . . . . . . . . 34 Appendix B. Nested Tunneling for Fault Tolerance . . . . . . . . 35 B.1. Detecting Presence of Alternate Routes . . . . . . . . . . 35 B.2. Re-Establishment of Bi-Directional Tunnels . . . . . . . . 36 B.2.1. Using Alternate Egress Interface . . . . . . . . . . . 36 B.2.2. Using Alternate Mobile Router . . . . . . . . . . . . 36 B.3. To Avoid Tunneling Loop . . . . . . . . . . . . . . . . . 37 B.4. Points of Considerations . . . . . . . . . . . . . . . . . 37 The design goals and objectives of Network Mobility (NEMO) support in IPv6 are identified in [1], while the terminology is described in [2] and [3]. NEMO Basic Support (RFC 3963) [4] is the solution proposed by the NEMO Working Group to provide continuous Internet connectivity to nodes located in an IPv6 mobile network, e.g., like in an in- vehicle embedded IP network. The NEMO Basic Support solution does so by setting up bi-directional tunnels between the mobile routers (MRs) connecting the mobile network (NEMO) to the Internet and their respective home agents (HAs), much like how this is done in Mobile IPv6 [5], the solution for host mobility support. NEMO Basic Support is transparent to nodes located behind the MR (i.e., the mobile network nodes, or MNNs), and as such, does not require MNNs to take any action in the mobility management. However, mobile networks are typically connected by means of wireless and thus less reliable links; there could also be many nodes behind the MR. A loss of connectivity or a failure to connect to the Internet has thus a more significant impact than for a single mobile node. Scenarios illustrated in [6] demonstrate that providing a permanent access to mobile networks typically require the use of several interfaces and technologies. For example, this is particularly useful for Intelligent Transport Systems (ITS) applications since vehicles are moving across distant geographical locations. Access would be provided through different access technologies (e.g., Wimax, Wifi, 3G) and through different access operators. As specified in Section 5 of the NEMO Basic Support Requirements [1] (R.12), the NEMO WG must ensure that NEMO Basic Support does not prevent mobile networks to be multihomed, i.e., when there is more than one point of attachment between the mobile network and the Internet (see definitions in [3]). This arises either: o the mobile network has multiple MRs, or o the mobile network is associated with multiple HAs, or o multiple global prefixes are available in the mobile network. Using NEMO Basic Support, this would translate into having multiple bi-directional tunnels between the MR(s) and the corresponding HA(s), and may result in multiple Mobile Network Prefixes (MNPs) available The readers should note that this document considers multihoming only from the point of view of an IPv6 environment. In order to understand this memo, the reader is expected to be familiar with the above cited documents, i.e., with the NEMO terminology as defined in [2] (Section 3) and [3], Motivations and Scenarios for Multihoming [6], Goals and Requirements of Network Mobility Support [1], and the NEMO Basic Support specification [4]. Goals and benefits of multihoming as discussed in [6], are applicable to fixed nodes, mobile nodes, fixed networks, and mobile networks. As there are several configurations in which mobile networks are multihomed, there is a need to classify them into a clearly defined taxonomy. This can be done in various ways. A Configuration- Oriented taxonomy is described in this section. Two other Multihomed configurations can be classified depending on how many MRs are present, how many egress interfaces, Care-of Address (CoA), and Home Addresses (HoA) the MRs have, how many prefixes (MNPs) are available to the mobile network nodes, etc. We use three key parameters to differentiate the multihomed configurations. Using these parameters, each configuration is referred by the 3-tuple (x,y,z), where 'x', 'y', 'z' are defined as follows: x=1 implies that a mobile network has only a single MR, presumably multihomed. x=n implies that a mobile network has more than one MR. o 'y' indicates the number of HAs associated with the entire mobile network, where: y=1 implies that a single HA is assigned to the mobile network. y=n implies that multiple HAs are assigned to the mobile network. The (n,n,1) configuration has more than one MR advertising multiple global routes. The mobile network is simultaneously associated with multiple HAs and a single MNP is available in the NEMO. The (n,n,n) configuration has multiple MRs advertising different global routes. The mobile network is simultaneously associated with more than one HA and multiple MNPs are available in the NEMO. x=1: Multihomed mobile networks with a single MR x=n: Multihomed mobile networks with multiple MRs y=1: Multihomed mobile networks with a single HA y=n: Multihomed mobile networks with multiple HAs z=1: Multihomed mobile networks with a single MNP z=n: Multihomed mobile networks with multiple MNPs At least one bi-directional tunnel must be available at any point in time between the mobile network and the fixed network to meet all expectations. But for most goals to be effective, multiple tunnels must be maintained simultaneously: Multiple tunnels must be maintained simultaneously in order to increase the total aggregated bandwidth available to the mobile network. tunnel, while the other serves as a backup) or peer-to-peer (no tunnel has precedence over one another, they are used with the same priority). This questions which of the bi-directional tunnels would be selected, and based on which of the parameters (e.g., type of flow that goes into/out of the mobile network). As an example of how this could happen, consider the deployment scenario illustrated in Figure 9: the mobile network has two mobile routers MR1 and MR2, with home agents HA1 and HA2, respectively. Two bi-directional tunnels are established between the two pairs. Each MR advertises a different MNP (P1 and P2 respectively). MNP P1 is registered to HA1, and MNP P2 is registered to HA2. Thus, MNNs should be free to auto-configure their addresses on any of P1 or P2. Ingress filtering could thus happen in two cases: Figure 9: An (n,n,n) mobile network o for the (*,n,1) cases, how can multiple HAs delegate the same MNP to the mobile network? For doing so, the HAs may be somehow configured to advertise the same MNP (see also "HA Synchronization" in Section 4.3). Prefix delegation mechanisms [20][21][22] could be used to ensure all routers advertise the same MNP. Their applicability to a multihomed mobile network should be considered. 4.8. Loop Prevention in Nested Mobile Networks When a multihomed mobile network is nested within another mobile network, it can result in very complex topologies. For instance, a nested mobile network may be attached to two different root-MRs, thus the aggregated network no longer forms a simple tree structure. In such a situation, infinite loop within the mobile network may occur. This problem is specific to NEMO Basic Support. However, at the time of writing, more research is recommended to assess the probability of loops occurring in a multihomed mobile network. For related work, see [25] for a mechanism to avoid loops in nested NEMO. When a mobile network is multihomed, the MNNs may be able to benefit from this configuration, such as to choose among the available paths based on cost, transmission delays, bandwidth, etc. However, in some cases, such a choice is not made available to the MNNs. Particularly: This problem is general in the sense that IPv6 nodes may wish to influence the routing decision done by the upstream routers. Such a mechanism is currently being explored by various WGs, such as the NSIS and IPFIX WGs. It is also possible that the Shim6 layer in the MNNs may possess such a capability. It is recommended for vendors or operators to investigate into the solutions developed by these WGs when providing multihoming capabilities to mobile networks. Further research is recommended to assess the risk of having a loop in the nesting of multihomed mobile networks. The problem of Prefix Ownership only occurs when a mobile network with multiple MRs and a single MNP can arbitrarily join and split. Vendors and operators of mobile networks are encouraged to input their views on the applicability of deploying such kind of mobile networks. This memo presented an analysis of multihoming in the context of network mobility under the operation of NEMO Basic Support (RFC 3963). The purpose was to investigate issues related to such a bi- directional tunneling mechanism where mobile networks are multihomed and multiple bi-directional tunnels are established between Home Agent and Mobile Router pairs. For doing so, mobile networks were classified into a taxonomy comprising eight possible multihomed configurations. Issues were explained one by one and then summarized into a table showing the multihomed configurations where they apply, suggesting the most relevant IETF working group where they could be solved. This analysis will be helpful to extend the existing standards to support multihoming and to implementors of NEMO Basic Support and multihoming-related mechanisms. [22] Thubert, P. and TJ. Kniveton, "Mobile Network Prefix Delegation", Work in Progress, November 2006. [26] Kumazawa, M., "Token based Duplicate Network Detection for split mobile network (Token based DND)", Work in Progress, July 2005. An alternative approach to classifying a multihomed mobile network was proposed by Erik Nordmark (Sun Microsystems) by breaking the classification of multihomed network based on ownership. This is more of a tree-like, top-down classification. Starting from the control and ownership of the HA(s) and MR(s), there are two different possibilities: either (i) the HA(s) and MR(s) are controlled by a single entity, or (ii) the HA(s) and MR(s) are controlled by separate entities. We called the first possibility the 'ISP Model', and the second the 'Subscriber/Provider Model'. The case of the HA(s) and MR(s) are controlled by the same entity can be best illustrated as an Internet Service Provider (ISP) installing MRs on trains, ships, or planes. It is up to the ISP to deploy a certain configuration of mobile network; all 8 configurations, as described in the Configuration-Oriented Approach, are possible. In the remaining portion of this document, when specifically referring to a mobile network configuration that is controlled by a single entity, we will add an 'ISP' prefix; for example, ISP-(1,1,1) or ISP- (1,n,n). When the HA(s) and MR(s) are controlled by a single entity (such as an ISP), the ISP can decide whether it wants to assign one or multiple MNPs to the mobile network just like it can make the same decision for any other link in its network (wired or otherwise). In any case, the ISP will make the routing between the mobile networks and its core routers (such as the HAs) work. This includes not introducing any aggregation between the HAs, which will filter out routing announcements for the MNP(s). The case of the HA(s) and MR(s) controlled by the separate entities can be best illustrated with a subscriber/provider model, where the MRs belongs to a single subscriber and subscribes to one or more ISPs for HA services. There is two sub-categories in this case: when the subscriber subscribes to a single ISP, and when the subscriber subscribes to multiple ISPs. In the remaining portion of this document, when specifically referring to a mobile network configuration that is in the subscriber/provider model where the subscriber subscribes to only one ISP, we will add an 'S/P' prefix; for example, S/P-(1,1,1) or S/P-(1,n,n). When specifically referring to a mobile network configuration that is in the subscriber/provider model where the subscriber subscribes to multiple ISPs, we will add an 'S/mP' prefix; for example, S/mP-(1,1,1) or S/mP-(1,n,n). Not all 8 configurations are likely to be deployed for the S/P and S/mP models. For instance, it is unlikely to foresee a S/mP-(*,1,1) mobile network where there is only a single HA. For the S/P model, the following configurations are likely to be deployed: A third approach was proposed by Pascal Thubert (Cisco Systems). This focused on the problems of multihomed mobile networks rather than the configuration or ownership. With this approach, there is a set of 4 categories based on two orthogonal parameters: the number of HAs, and the number of MNPs advertised. Since the two parameters are orthogonal, the categories are not mutually exclusive. The four categories are: This is the case where one MR registers different CoAs to the same HA for the same subnet prefix. This is equivalent to the case of y=1, i.e., the (1,1,*) mobile network. This is the case where the MR registers different CoAs to different HAs for the same subnet prefix. This is equivalent to the case of y=n, i.e., the (1,n,*) mobile network. This is the case where one MNP is announced by different MRs. This is equivalent to the case of x=n and z=1, i.e., the (n,*,1) mobile network. This is the case where more than one MNPs are announced by the different MRs. This is equivalent to the case of x=n and z=n, i.e., the (n,*,n) mobile network. To actively utilize the robustness provided by multihoming, an MR must first be capable of detecting alternate routes. This can be manually configured into the MR by the administrators if the configuration of the mobile network is relatively static. It is however highly desirable for MRs to be able to discover alternate routes automatically for greater flexibility. In the case where multiple MRs are on the mobile network, each MR has to detect the presence of other MR. An MR can do so by listening for Router Advertisement message on its *ingress* interfaces. When an MR receives a Router Advertisement message with a non-zero Router Lifetime field from one of its ingress interfaces, it knows that another MR that can provide an alternate route to the global Internet is present in the mobile network. When an MR detects that the link by which its current bi-directional tunnel with its HA is using is down, it needs to re-establish the bi- directional tunnel using an alternate route detected. We consider two separate cases here: firstly, the alternate route is provided by another egress interface that belongs to the MR; secondly, the alternate route is provided by another MR connected to the mobile network. We refer to the former case as an alternate route provided by an alternate egress interface, and the latter case as an alternate route provided by an alternate MR. The method of re-establishing the bi-directional tunnel as described in Appendix B.2 may lead to infinite loops of tunneling. This happens when two MRs on a mobile network lose connection to the global Internet at the same time and each MR tries to re-establish bi-directional tunnel using the other MR. We refer to this phenomenon as tunneling loop. http://www.ietf.org/rfc/rfc4981.txt 4981 Survey of Research towards Robust Peer-to-Peer Networks: Search Methods. J. Risson, T. Moors. September 2007. (Format: TXT=239752 bytes) (Status: INFORMATIONAL) [244] S. Ratnasamy, B. Karp, S. Shenker, D. Estrin, R. Govindan, L. Yin, and F. Yu, Data Centric Storage in Sensornets with GHT, a geographic hash table, Mobile Networks and Applications 8 (4) (2003) 427-442. http://www.ietf.org/rfc/rfc4984.txt 4984 Report from the IAB Workshop on Routing and Addressing. D. Meyer, Ed., L. Zhang, Ed., K. Fall, Ed.. September 2007. (Format: TXT=96153 bytes) (Status: INFORMATIONAL) 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Key Findings from the Workshop . . . . . . . . . . . . . . . . 4 2.1. Problem #1: The Scalability of the Routing System . . . . 4 2.1.1. Implications of DFZ RIB Growth . . . . . . . . . . . . 5 2.1.2. Implications of DFZ FIB Growth . . . . . . . . . . . . 6 2.2. Problem #2: The Overloading of IP Address Semantics . . . 6 2.3. Other Concerns . . . . . . . . . . . . . . . . . . . . . . 7 2.4. How Urgent Are These Problems? . . . . . . . . . . . . . . 8 3. Current Stresses on the Routing and Addressing System . . . . 8 3.1. Major Factors Driving Routing Table Growth . . . . . . . . 8 3.1.1. Avoiding Renumbering . . . . . . . . . . . . . . . . . 9 3.1.2. Multihoming . . . . . . . . . . . . . . . . . . . . . 10 3.1.3. Traffic Engineering . . . . . . . . . . . . . . . . . 10 3.2. IPv6 and Its Potential Impact on Routing Table Size . . . 11 4. Implications of Moore's Law on the Scaling Problem . . . . . . 11 4.1. Moore's Law . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.1. DRAM . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.2. Off-chip SRAM . . . . . . . . . . . . . . . . . . . . 13 4.2. Forwarding Engines . . . . . . . . . . . . . . . . . . . . 13 4.3. Chip Costs . . . . . . . . . . . . . . . . . . . . . . . . 14 4.4. Heat and Power . . . . . . . . . . . . . . . . . . . . . . 14 4.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. What Is on the Horizon . . . . . . . . . . . . . . . . . . . . 15 5.1. Continual Growth . . . . . . . . . . . . . . . . . . . . . 15 5.2. Large Numbers of Mobile Networks . . . . . . . . . . . . . 16 5.3. Orders of Magnitude Increase in Mobile Edge Devices . . . 16 6. What Approaches Have Been Investigated . . . . . . . . . . . . 17 6.1. Lessons from MULTI6 . . . . . . . . . . . . . . . . . . . 17 6.2. SHIM6: Pros and Cons . . . . . . . . . . . . . . . . . . . 18 6.3. GSE/Indirection Solutions: Costs and Benefits . . . . . . 19 6.4. Future for Indirection . . . . . . . . . . . . . . . . . . 20 7. Problem Statements . . . . . . . . . . . . . . . . . . . . . . 21 7.1. Problem #1: Routing Scalability . . . . . . . . . . . . . 21 7.2. Problem #2: The Overloading of IP Address Semantics . . . 22 7.2.1. Definition of Locator and Identifier . . . . . . . . . 22 7.2.2. Consequence of Locator and Identifier Overloading . . 23 7.2.3. Traffic Engineering and IP Address Semantics Overload . . . . . . . . . . . . . . . . . . . . . . . 24 7.3. Additional Issues . . . . . . . . . . . . . . . . . . . . 24 7.3.1. Routing Convergence . . . . . . . . . . . . . . . . . 24 7.3.2. Misaligned Costs and Benefits . . . . . . . . . . . . 25 7.3.3. Other Concerns . . . . . . . . . . . . . . . . . . . . 25 7.4. Problem Recognition . . . . . . . . . . . . . . . . . . . 26 8. Criteria for Solution Development . . . . . . . . . . . . . . 26 8.1. Criteria on Scalability . . . . . . . . . . . . . . . . . 26 8.2. Criteria on Incentives and Economics . . . . . . . . . . . 27 5.2. Large Numbers of Mobile Networks Boeing's Connexion service pioneered the deployment of commercial mobile networks that may change their attachment points to the Internet on a global scale. It is believed that such in-flight Internet connectivity would likely become commonplace in the not-too- distant future. When that happens, there can be multiple thousands of airplane networks in the air at any given time. Given that today's DFZ RIB already handles over 200,000 prefixes [CIDRRPT], several thousands of mobile networks, each represented by a single prefix announcement, may not necessarily raise serious routing scalability or stability concerns. However, there is an open question regarding whether this number can become substantially larger if other types of mobile networks, such as networks on trains or ships, come into play. If such mobile networks become commonplace, then their impact on the global routing system needs to be assessed. http://www.ietf.org/rfc/rfc4988.txt 4988 Mobile IPv4 Fast Handovers. R. Koodli, C. Perkins. October 2007. (Format: TXT=57921 bytes) (Status: EXPERIMENTAL) [fh-ccr] R. Koodli and C. E. Perkins, "Fast Handovers and Context Transfers in Mobile Networks", ACM Computer Communications Review Special Issue on Wireless Extensions to the Internet, October 2001. http://www.ietf.org/rfc/rfc5062.txt 5062 Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures. R. Stewart, M. Tuexen, G. Camarillo. September 2007. (Format: TXT=29704 bytes) (Status: INFORMATIONAL) The attack is made possible by any mechanism that lets an endpoint acquire some other IP address that was recently in use by an SCTP endpoint. For example, DHCP may be used in a mobile network with short IP address lifetimes to reassign IP addresses to migrant hosts. http://www.ietf.org/rfc/rfc5067.txt 5067 Infrastructure ENUM Requirements. S. Lind, P. Pfautz. November 2007. (Format: TXT=14311 bytes) (Status: INFORMATIONAL) o where numbers are assigned directly to end users, the service provider that the end user number assignee has chosen to provide a Public Switched Telephone Network/Public Land Mobile Network (PSTN/ PLMN) point-of-interconnect for the number. http://www.ietf.org/rfc/rfc5072.txt 5072 IP Version 6 over PPP. S. Varada, Ed., D. Haskins, E. Allen. September 2007. (Format: TXT=33910 bytes) (Obsoletes RFC2472) (Status: DRAFT STANDARD) [11] 3GPP TS 29.061 V6.4.0, "Interworking between the Public Land Mobile Network (PLMN) Supporting packet based services and Packet Data Networks (PDN) (Release 6)," April 2005. http://www.ietf.org/rfc/rfc5113.txt 5113 Network Discovery and Selection Problem. J. Arkko, B. Aboba, J. Korhonen, Ed., F. Bari. January 2008. (Format: TXT=93250 bytes) (Status: INFORMATIONAL) The 3GPP stage 2 technical specification [3GPPSA2WLANTS] covers the architecture of 3GPP Interworking WLAN (I-WLAN) with 2G and 3G networks. This specification also discusses realm discovery and network selection issues. The I-WLAN realm discovery procedure borrows ideas from the cellular Public Land-based Mobile Network (PLMN) selection principles, known as "PLMN Selection". The I-WLAN specification requires that network discovery be performed as specified in the relevant WLAN link layer standards. In addition to network discovery, it is necessary to select intermediary realms to enable construction of source routes. In 3GPP, the intermediary networks are PLMNs, and it is assumed that an access network may have a roaming agreement with more than one PLMN. The PLMN may be a Home PLMN (HPLMN) or a Visited PLMN (VPLMN), where roaming is supported. GSM/UMTS roaming principles are employed for routing AAA requests from the VPLMN to the Home Public Land-based Mobile Network (HPLMN) using either RADIUS or Diameter. The procedure for selecting the intermediary network has been specified in the stage 3 technical specifications [3GPPCT1WLANTS] and [3GPPCT4WLANTS]. http://www.ietf.org/rfc/rfc5177.txt 5177 Network Mobility (NEMO) Extensions for Mobile IPv4. K. Leung, G. Dommety, V. Narayanan, A. Petrescu. April 2008. (Format: TXT=56094 bytes) (Updated by RFC6626) (Status: PROPOSED STANDARD) This document describes a protocol for supporting Mobile Networks between a Mobile Router and a Home Agent by extending the Mobile IPv4 protocol. A Mobile Router is responsible for the mobility of one or more network segments or subnets moving together. The Mobile Router hides its mobility from the nodes on the Mobile Network. The nodes on the Mobile Network may be fixed in relationship to the Mobile Router and may not have any mobility function. Extensions to Mobile IPv4 are introduced to support Mobile Networks. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Examples of Mobile Networks . . . . . . . . . . . . . . . 3 1.2. Overview of Protocol . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Mobile Network Extensions . . . . . . . . . . . . . . . . . . 8 4.1. Mobile Network Request Extension . . . . . . . . . . . . . 8 4.2. Mobile Network Acknowledgement Extension . . . . . . . . . 9 5. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 11 5.1. Error Processing . . . . . . . . . . . . . . . . . . . . . 12 5.2. Mobile Router Management . . . . . . . . . . . . . . . . . 12 6. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 13 6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 14 6.2.1. Registration Table . . . . . . . . . . . . . . . . . . 14 6.2.2. Prefix Table . . . . . . . . . . . . . . . . . . . . . 14 6.3. Mobile Network Prefix Registration . . . . . . . . . . . . 14 6.4. Advertising Mobile Network Reachability . . . . . . . . . 16 6.5. Establishment of Bi-directional Tunnel . . . . . . . . . . 16 6.6. Sending Registration Replies . . . . . . . . . . . . . . . 17 6.7. Mobile Network Prefix Deregistration . . . . . . . . . . . 17 7. Data Forwarding Operation . . . . . . . . . . . . . . . . . . 17 8. Nested Mobile Networks . . . . . . . . . . . . . . . . . . . . 18 9. Routing Protocol between Mobile Router and Home Agent . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10.1. Security when Dynamic Routing Protocol Is Used . . . . . . 20 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 13.1. Normative References . . . . . . . . . . . . . . . . . . . 23 13.2. Informative References . . . . . . . . . . . . . . . . . . 24 This document describes network mobility extensions to the Mobile IPv4 protocol. The goal of introducing these extensions is to accommodate mobility scenarios where groups of hosts and routers move homogeneously (as a whole). It is required that all hosts and routers in a Mobile Network be able to run applications connecting to the Internet, and be reachable from the Internet. 1.1. Examples of Mobile Networks A Mobile Network links together a set of hosts and routers. Connecting this Mobile Network to the Internet is ensured at two levels: first, a Mobile Router is connected on one side to the Mobile Network and on another side to a wireless access system; second, a Home Agent placed on the home link manages traffic between the Correspondent Node and a Local Fixed Node (LFN, a node in the Mobile Network) by means of encapsulating traffic. A scenario of applicability for this Mobile Network is described next. A Mobile Network is formed by a wireless-enabled Personal Digital Assistant (PDA) and a portable photographic camera, linked together by Bluetooth wireless link-layer technology. This is sometimes referred to as a Personal Area Network (PAN). In the illustration below, one can notice the PDA playing the role of a Mobile Router and the camera the role of Local Fixed Node. The camera (Local Fixed Node) uploads photographic content to a Correspondent Node (CN) server. When the Mobile Network moves away, the Mobile Router serving the Mobile Network changes its point of attachment from one cellular access (Access Router) to another, obtaining a new Care-of Address. The Home Agent (HA) encapsulates application traffic for the CN and LFN. Whereas the illustration above is a very simple instantiation of the applicability of Mobile IP-based Mobile Networks, more complex Mobile Networks are easily accommodated by the Mobile IPv4 extensions presented in this document (NEMOv4). For example, laptop computers used by passengers in a bus, train, ship, or plane should all be considered as forming Mobile Networks, as long as they move together (homogeneously). As introduced previously, this document presents extensions to the Mobile IPv4 protocol. The entities sending and receiving these extensions are the Mobile Router and the Home Agent. The Local Fixed Node is relieved from running Mobile IP software and, although it moves (together with the Mobile Network), its IP stack is not seeing any change in addressing. Mobility for the entire Mobile Network is supported by the Mobile Router registering its current point of attachment (Care-of Address) to its Home Agent: the Mobile Router sends an extended Registration Request to the Home Agent, which returns an extended Registration Reply. This signaling sets up the tunnel between the two entities, as illustrated in the following figure: The prefix(es) used within a Mobile Network (either implicitly configured on the Home Agent or explicitly identified by the Mobile Router in the Registration Request) is/are advertised by the Home Agent for route propagation in the home network. Traffic to and from nodes in the Mobile Network are tunneled by the Home Agent to the Mobile Router, and vice versa. Though packets from a Local Fixed Node placed in the Mobile Network can be forwarded by the Mobile Router directly without tunneling (if reverse tunneling were not used), these packets will be dropped if ingress filtering is turned on at the Access Router. Compared to Mobile IPv4, this document specifies an additional tunnel between a Mobile Router's Home Address and the Home Agent. This tunnel is encapsulated within the normal tunnel between the Care-of Address (CoA) and Home Agent. In Foreign Agent CoA mode, the tunnel between the Mobile Router and Home Agent is needed to allow the Foreign Agent to direct the decapsulated packet to the proper visiting Mobile Router. However, in co-located CoA mode, the additional tunnel is not essential and could be eliminated because the Mobile Router is the recipient of the encapsulated packets for the Mobile Network; a proposal for this feature is in the extending document mentioned above [NEMOv4-FA]. All traffic between the nodes in the Mobile Network and the Correspondent Nodes passes through the Home Agent. This document does not touch on aspects related to route optimization of this traffic. A similar protocol has been documented in RFC 3963 [RFC3963] for supporting IPv6 Mobile Networks with Mobile IPv6 extensions. Mobile Network Prefix The network prefix of the subnet delegated to a Mobile Router as the Mobile Network. A list of Mobile Network Prefixes indexed by the Home Address of a Mobile Router. The Home Agent manages and uses the Prefix Table to determine which Mobile Network Prefixes belong to a particular Mobile Router. RFC 4885 [RFC4885] defines a Local Fixed Node (LFN) to be a fixed node belonging to the Mobile Network and unable to change its point of attachment. This definition should not be confused with "Long, Fat Network, LFN" of RFC 1323 [RFC1323], at least because the latter is pronounced "elephan(t)" whereas a NEMO LFN is distinctively pronounced "elefen". Although the original Mobile IPv4 specifications stated that Mobile Networks can be supported by the Mobile Router and Home Agent using static configuration or running a routing protocol (see Section 4.5 of RFC 3344 [RFC3344]), there is no solution for explicit registration of the Mobile Networks served by the Mobile Router. A solution needs to provide the Home Agent a means to ensure that a Mobile Router claiming a certain Mobile Network Prefix is authorized to do so. A solution would also expose the Mobile Network Prefixes (and potentially other subnet-relevant information) in the exchanged messages, to aid in network debugging. The following requirements for Mobile Network support are enumerated: o A Mobile Router should be able to operate in explicit or implicit mode. A Mobile Router may explicitly inform the Home Agent which Mobile Network(s) need to be propagated via a routing protocol. A Mobile Router may also function in implicit mode, where the Home Agent may learn the Mobile Networks through other means, such as from the AAA server, via pre-configuration, or via a dynamic routing protocol. o The Mobile Network should be supported using Foreign Agents that are compliant to RFC 3344 [RFC3344] without any changes ('legacy' Foreign Agents). o The Mobile Network should allow Fixed Nodes, Mobile Nodes, or Mobile Routers to be on it. o The Local Fixed Nodes on a Mobile Network should be able to execute their sessions without running Mobile IP stacks. The Mobile Router managing the LFNs' Mobile Network is 'hiding' mobility events like the changes of the Care-of Address from the Local Fixed Nodes in that Mobile Network. 4. Mobile Network Extensions 4.1. Mobile Network Request Extension For Explicit Mode, the Mobile Router informs the Home Agent about the Mobile Network Prefixes during registration. The Registration Request contains zero, one, or several Mobile Network Request extensions in addition to any other extensions defined by or in the context of RFC 3344 [RFC3344]. When several Mobile Networks need to be registered, each is included in a separate Mobile Network Request extension, with its own Type, Length, Sub-Type, Prefix Length, and Prefix. A Mobile Network Request extension is encoded in Type- Length-Value (TLV) format and respects the following ordering: 148 Mobile Network Extension 0 (Mobile Network Request) 32-bit unsigned integer in network byte-order containing an IPv4 address whose leftmost Prefix Length bits make up the Mobile Network Prefix. 4.2. Mobile Network Acknowledgement Extension The Registration Reply contains zero, one or several Mobile Network Acknowledgement extensions in addition to any other extensions defined by or in the context of RFC 3344 [RFC3344]. For Implicit Mode, the Mobile Network Acknowledgement informs the Mobile Router the prefixes for which the Home Agent sets up forwarding with respect to this Mobile Router. Policies such as permitting only traffic from these Mobile Networks to be tunneled to the Home Agent may be applied by the Mobile Router. For Explicit Mode, when several Mobile Networks need to be acknowledged explicitly, each is included in a separate Mobile Network Acknowledgement extension, with its own Type, Sub-Type, Length, Prefix, and Prefix Length fields. At least one Mobile Network Acknowledgement extension MUST be in a successful Registration Reply to indicate to the Mobile Router that the Mobile Network Request extension was processed, and therefore was not skipped by the Home Agent. A Registration Reply may contain any non-zero number of Explicit Mode and Implicit Mode Acknowledgements sub-types. Both sub-types can be present in a single Registration Reply. A Mobile Network Acknowledgement extension is encoded in Type-Length-Value (TLV) format. When the registration is denied with Code HA_MOBNET_ERROR (Code field in the Registration Reply), the Code field in the included Mobile Network Extension provides the reason for the failure. 148 Mobile Network Extension 32-bit unsigned integer in network byte-order containing an IPv4 address whose leftmost Prefix Length bits make up the Mobile Network Prefix. A Mobile Router's operation is generally derived from the behavior of a Mobile Node, as set in RFC 3344 [RFC3344]. In addition to maintaining mobility bindings for its Home Address, the Mobile Router, together with the Home Agent, maintains forwarding information for the Mobile Network Prefix(es) assigned to the Mobile Router. A Mobile Router SHOULD set the 'T' bit to 1 in all Registration Request messages it sends to indicate the need for reverse tunnels for all traffic. Without reverse tunnels, all the traffic from the Mobile Network will be subject to ingress filtering in the visited networks. Upon reception of a successful Registration Reply, the Mobile Router processes the registration in accordance to RFC 3344 [RFC3344]. In addition, the following steps are taken: o Check for Mobile Network Acknowledgement extension(s) in Registration Reply. In accordance with this specification, a Mobile Router may operate in one of the following two modes: explicit and implicit. In explicit mode, the Mobile Router includes Mobile Network Prefix information in all Registration Requests (as Mobile Network Request extensions), while in implicit mode it does not include this information in any Registration Request. In the latter case, the Home Agent obtains the Mobile Network Prefixes by other means than Mobile IP. One example of obtaining the Mobile Network Prefix is through static configuration on the Home Agent. For deregistration, the Mobile Router sends a registration request with lifetime set to zero without any Mobile Network Request extensions. In a Mobile IP Registration Reply message, there may be two Code fields: one proper to the Registration Reply header (the 'proper' Code) and one within the Mobile Network Acknowledgement Extension (simply the 'Code'). A Mobile Router interprets the values of the Code field in the Mobile Network Acknowledgement Extension of the Registration Reply in order to identify any error related to managing the Mobile Network Prefixes by the Home Agent. It also interprets the values of the Code field in the Registration Reply header (the proper Code). If the value of the Code field in the Registration Reply (the proper) is set to HA_MOBNET_DISALLOWED, then the Mobile Router MUST stop sending Registration Requests with any Mobile Network Prefix extensions to that Home Agent. If the value of the Code field in the Registration Reply (the proper) is set to HA_MOBNET_ERROR, then the Mobile Router MUST stop sending Registration Requests that contain any of the Mobile Network Prefixes that are defined by the values of the fields Prefix and Prefix Length in the Mobile Network Acknowledgement extension. Note that the registration is denied in this case, and no forwarding for any Mobile Network Prefixes would be set up by the Home Agent for the Mobile Router. It is possible that the Mobile Router receives a Registration Reply with no Mobile Network extensions if the registration was processed by a Mobile IPv4 Home Agent that does not support this specification at all. In that case, the absence of Mobile Network extensions must be interpreted by the Mobile Router as the case where the Home Agent does not support Mobile Networks. The necessary initial configuration at a NEMOv4-enabled Home Agent includes, but is not limited to, the contents of the Prefix Table. The Mobile Router MAY need to store the Mobile Network Prefixes as the initial configuration. 1. Check that the Mobile Network Prefix information is valid. 2. Ensure the Mobile Network Prefix(es) is/are authorized to be on the Mobile Router. 4. Set up route for the Mobile Network Prefix via this tunnel. 5. Propagate Mobile Network Prefix routes via routing protocol if necessary. 6. Send the Registration Reply with the Mobile Network Acknowledgement extension(s). If there are any subnet routes via the tunnel to the Mobile Router that are not specified in the Mobile Network extensions, these routes are removed. For deregistration, the Home Agent removes the tunnel to the Mobile Router and all routes using this tunnel. The Mobile Network extensions are ignored. The Registration Table in the Home Agent, in accordance with RFC 3344 [RFC3344], contains binding information for every Mobile Node registered with it. RFC 3344 [RFC3344] defines the format of a Registration Table. In addition to all the parameters specified by RFC 3344 [RFC3344], the Home Agent MUST store the Mobile Network Prefixes associated with the Mobile Router in the corresponding registration entry, when the corresponding registration was performed in explicit mode. When the Home Agent is advertising reachability to Mobile Network Prefixes served by a Mobile Router, the information stored in the Registration Table can be used. The Home Agent must be able to authorize a Mobile Router for use of Mobile Network Prefixes when the Mobile Router is operating in explicit mode. Also, when the Mobile Router operates in implicit mode, the Home Agent must be able to locate the Mobile Network Prefixes associated with that Mobile Router. The Home Agent may store the Home Address of the Mobile Router along with the Mobile Network prefixes associated with that Mobile Router. If the Mobile Router does not have a Home Address assigned, this table may store the Network Access Identifier (NAI) [RFC2794] of the Mobile Router that will be used in dynamic Home Address assignment. 6.3. Mobile Network Prefix Registration If the Registration Request is valid, the Home Agent checks to see if there are any Mobile Network Prefix extensions included in the Registration Request. If so, the Mobile Network Prefix information is obtained from the included extensions, and the Home Address from the Home Address field of the Registration Request. For every Mobile Network Prefix extension included in the registration request, the Home Agent MUST perform a check against the Prefix Table. If the Prefix Table does not contain at least one entry pairing that Home Address to that Mobile Network Prefix, then the check fails; otherwise, it succeeds. Following this check against the Prefix Table, the Home Agent MUST construct a Registration Reply containing Mobile Network Acknowledgement extensions. For a Mobile Network Prefix for which the check was unsuccessful, the Code field in the corresponding Mobile Network Acknowledgement extension should be set to MOBNET_UNAUTHORIZED. For a Mobile Network Prefix for which the check was successful, the Code field in the respective Mobile Network Acknowledgement extensions should be set to 0. The Home Agent MUST attempt to set up forwarding for each Mobile Network Prefix extension for which the Prefix Table check was successful. If the forwarding setup fails for a particular Mobile Network Prefix (for reasons such as not enough memory available or not enough devices available), the Code field in the respective Mobile Network Acknowledgement extension should be set to MOBNET_FWDING_SETUP_FAILED. If forwarding and setup was successful for at least one Mobile Network Prefix, then the Code field (the proper) of the Registration Reply message should be set to 0. Otherwise, when forwarding and setup was unsuccessful for each and every Mobile Network Prefixes, that Code (the proper) should be HA_MOBNET_ERROR. If the Registration Request is sent in implicit mode, i.e., without any Mobile Network Request extension, the Home Agent may use pre- configured Mobile Network prefix information for the Mobile Router to set up forwarding. If the Home Agent is updating an existing binding entry for the Mobile Router, it MUST check all the prefixes in the Registration Table against the prefixes included in the Registration Request. If one or more Mobile Network prefixes are missing from the included If the 'T' bit is set, the Home Agent creates a bi-directional tunnel for the corresponding Mobile Network prefixes or updates the existing bi-directional tunnel. This tunnel is maintained independent of the reverse tunnel for the Mobile Router home address itself. 6.4. Advertising Mobile Network Reachability If the Mobile Network prefixes served by the Home Agent are aggregated with the home network prefix and if the Home Agent is the default router on the home network, the Home Agent does not have to advertise the Mobile Network Prefixes. The routes for the Mobile Network Prefix are automatically aggregated into the home network prefix (it is assumed that the Mobile Network Prefixes are automatically aggregated into the home network prefix). If the Mobile Router updates the Mobile Network prefix routes via a dynamic routing protocol, the Home Agent SHOULD propagate the routes on the appropriate networks. The Home Agent creates and maintains a bi-directional tunnel for the Mobile Network prefixes of a Mobile Router registered with it. A Home Agent supporting IPv4 Mobile Router operation MUST be able to forward packets destined to the Mobile Network prefixes served by the Mobile Router to its Care-of Address. Also, the Home Agent MUST be able to accept packets tunneled by the Mobile Router with the source address of the outer header set to the Care-of Address of the Mobile Router and that of the inner header set to the Mobile Router's Home Address or an address from one of the registered Mobile Network prefixes. The Home Agent MUST set the status code in the registration reply to 0 to indicate successful processing of the Registration Request and successful setup of forwarding for at least one Mobile Network prefix served by the Mobile Router. The Registration Reply MUST contain at least one Mobile Network Acknowledgement extension. If the Home Agent is unable to set up forwarding for one or more Mobile Network prefixes served by the Mobile Router, it MUST set the Mobile Network Acknowledgement Extension status Code in the Registration Reply to MOBNET_FWDING_SETUP_FAILED. When the prefix length is zero or greater than decimal 32, the status Code MUST be set to MOBNET_INVALID_PREFIX_LEN. If the Mobile Router is not authorized to forward packets to a Mobile Network prefix included in the request, the Home Agent MUST set the Code to MOBNET_UNAUTHORIZED. 6.7. Mobile Network Prefix Deregistration If the received Registration Request is for deregistration of the Care-of Address, the Home Agent, upon successful processing of it, MUST delete the entry (or entries) from its Registration Table. The Home Agent tears down the bi-directional tunnel and stops forwarding any packets to/from the Mobile Router. The Home Agent MUST ignore any included Mobile Network Request extension in a deregistration request. For traffic to the nodes in the Mobile Network, the Home Agent MUST perform double tunneling of the packet, if the Mobile Router had registered with a Foreign Agent Care-of Address. In this case, the Home Agent MUST encapsulate the packet with the tunnel header (source IP address set to Home Agent, and destination IP address set to Mobile Router's Home Address) and then encapsulate one more time with the tunnel header (source IP address set to Home Agent, and destination IP address set to CoA). When a Home Agent receives a packet from the Mobile Network prefix in the bi-directional tunnel, it MUST de-encapsulate the packet and route it as a normal IP packet. It MUST verify that the incoming For traffic from the nodes in the Mobile Network, the Mobile Router encapsulates the packet with a tunnel header (source IP address set to Mobile Router's Home Address, and destination IP address set to Home Agent) if reverse tunnel is enabled. Otherwise, the packet is routed directly to the Foreign Agent or access router. 8. Nested Mobile Networks Nested Network Mobility is a scenario where a Mobile Router allows another Mobile Router to attach to its Mobile Network. There could be arbitrary levels of nested mobility. The operation of each Mobile Router remains the same whether the Mobile Router attaches to another Mobile Router or to a fixed Access Router on the Internet. The solution described here does not place any restriction on the number of levels for nested mobility. Two issues should be noted though. First, whenever physical loops occur in a nested aggregation of Mobile Networks, this protocol neither detects nor solves them -- datagram forwarding may be blocked. Second, Mobile Routers in a deep nested aggregation of Mobile Networks might introduce significant overhead on the data packets as each level of nesting introduces another tunnel header encapsulation. Applications that do not support MTU discovery are adversely affected by the additional header encapsulations because the usable MTU is reduced with each level of nesting. There are several benefits of running a dynamic routing protocol between the Mobile Router and the Home Agent. If the Mobile Network is relatively large, including several wireless subnets, then the topology changes within the moving network can be exposed from the Mobile Router to the Home Agent by using a dynamic routing protocol. The purpose of the NEMOv4 protocol extensions to Mobile IPv4, as defined in previous sections, is not to inform the Home Agent about these topology changes, but to manage the mobility of the Mobile Router. The Mobile Network extension is protected by the same rules as for Mobile IP extensions in registration messages. See the Security Considerations section in RFC 3344 [RFC3344]. The Home Agent MUST be able to verify that the Mobile Router is authorized to provide mobility service for the Mobile Networks in the Registration Request, before anchoring these Mobile Network Prefixes on behalf of the Mobile Router. Forwarding for prefixes MUST NOT be set up without successful authorization of the Mobile Router for those prefixes. The Mobile Router MUST be notified when there is a registration failure because it cannot be successfully authorized for prefixes it requested. All Registration Requests and replies MUST be authenticated by the MN-HA Authentication Extension as specified in RFC 3344 [RFC3344]. When the registration request is sent in explicit mode, i.e., with one or more Mobile Network Prefix extensions, all the Mobile Network Prefix extensions MUST be included before the MN-HA Authentication extension. Also, these extensions MUST be included in the calculation of the MN-HA authenticator value. The Mobile Router should perform ingress filtering on all the packets received on the Mobile Network prior to reverse tunneling them to the Home Agent. The Mobile Router MUST drop any packets that do not have a source address belonging to the Mobile Network. The Mobile Router MUST also ensure that the source address of packets arriving on the Mobile Network is not the same as the Mobile Router's IP address on any interface. These checks will protect against nodes attempting to launch IP spoofing attacks through the bi-directional tunnel. The Home Agent, upon receiving packets through the bi-directional tunnel, MUST verify that the source addresses of the outer IP header of the packets are set to the Mobile Router's Care-of Address. Also, it MUST ensure that the source address of the inner IP header is a topologically correct address on the Mobile Network. This will prevent nodes from using the Home Agent to launch attacks inside the protected network. If a dynamic routing protocol is used between the Mobile Router and the Home Agent to propagate the Mobile Network information into the home network, the routing updates SHOULD be protected with IPsec ESP confidentiality between the Mobile Router and Home Agent, to prevent information about home network topology from being visible to eavesdroppers. +-------+--------------------------+ | Value | Name | +-------+--------------------------+ | 148 | Mobile Network Extension | +-------+--------------------------+ A new number space has been created for the Values and Names for the Sub-Type for Mobile Network Extensions. This number space is initially defined to hold the following entries, allocated by this document: +-------+-----------------------------------------+ | Value | Name | +-------+-----------------------------------------+ | 0 | Mobile Network Request Extension | | 1 | Explicit Mode Acknowledgement Extension | | 2 | Implicit Mode Acknowledgement Extension | +-------+-----------------------------------------+ Table 2: New Values and Names for the Sub-Type for Mobile Network Extensions +-------+-----------------------------------------------------------+ | Value | Name | +-------+-----------------------------------------------------------+ | 147 | Mobile Network Prefix operation error (HA_MOBNET_ERROR) | | 148 | Mobile Router operation is not permitted | | | (HA_MOBNET_DISALLOWED) | +-------+-----------------------------------------------------------+ A new number space has been created for the Code Values for the Mobile Network Acknowledgement Extension. This number space is initially defined to hold the following entries, allocated by this document (result of registration, as sent by the Home Agent): Table 4: New Code Values for Mobile Network Acknowledgement Extension Mobile IPv4 versions as early as 1996 (RFC 2002 by Charles Perkins) described Mobile Networks and Mobile Routers support. David Borman of TSV-DIR reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. The implications of the growth of usable MTU adversely affecting applications deep in a Mobile Network were suggested. http://www.ietf.org/rfc/rfc5181.txt 5181 IPv6 Deployment Scenarios in 802.16 Networks. M-K. Shin, Ed., Y-H. Han, S-E. Kim, D. Premec. May 2008. (Format: TXT=36671 bytes) (Status: INFORMATIONAL) There are two different deployment scenarios: fixed and mobile access deployment scenarios. A fixed access scenario substitutes for existing wired-based access technologies such as digital subscriber lines (xDSL) and cable networks. This fixed access scenario can provide nomadic access within the radio coverages, which is called the Hot-zone model. A mobile access scenario exists for the new paradigm of transmitting voice, data, and video over mobile networks. This scenario can provide high-speed data rates equivalent to the wire-based Internet as well as mobility functions equivalent to http://www.ietf.org/rfc/rfc5194.txt 5194 Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP). A. van Wijk, Ed., G. Gybels, Ed.. June 2008. (Format: TXT=68636 bytes) (Status: INFORMATIONAL) Store-and-forward systems like email or messaging on mobile networks, or non-streaming systems like instant messaging, are unable to provide that functionality. In particular, they do not allow for smooth communication through a Text Relay Service. Many mobile terminals allow the use of the circuit-switched data channel to transfer data in real time. Data rates of 9600 bit/s are usually supported on the 2G mobile network. Gateways provide interoperability with PSTN textphones. http://www.ietf.org/rfc/rfc5271.txt 5271 Mobile IPv6 Fast Handovers for 3G CDMA Networks. H. Yokota, G. Dommety. June 2008. (Format: TXT=49316 bytes) (Status: INFORMATIONAL) International Mobile Subscriber Identity (IMSI): The IMSI is a string of decimal digits, up to a maximum of 15 digits, that identifies a unique mobile terminal or mobile subscriber internationally. The IMSI consists of three fields: the Mobile Country Code (MCC), the Mobile Network Code (MNC), and the Mobile Subscriber Identification Number (MSIN). An example of the IMSI is "440701234567890", where "440" is the MCC, "70" is the MNC, and "1234567890" is the MSIN. The IMSI conforms to the ITU-T E.212 numbering standard [6]. In this specification, IMSI is an ASCII string that consists of not more than 15 decimal digits (ASCII values between 30 and 39 hexadecimal), one character per IMSI digit. The above example would therefore be encoded as "34 34 30 37 30 31 32 33 34 35 36 37 38 39 30" in hexadecimal notation. http://www.ietf.org/rfc/rfc5488.txt 5488 Network Mobility (NEMO) Management Information Base. S. Gundavelli, G. Keeni, K. Koide, K. Nagami. April 2009. (Format: TXT=87041 bytes) (Status: PROPOSED STANDARD) nemoHaMobileNetworkPrefixTable: contains the list of the mobile network prefixes that are maintained by the home agent. STATUS current DESCRIPTION "implicitMode(1): the Mobile Network Prefix Option is not included in the Binding Update by the mobile router. explicitMode(2): the mobile router included one or more Mobile Network Prefix Options in the Binding Update. " REFERENCE "RFC 3963: Section 5.2" ::= { nemoMrBLEntry 1 } nemoMrPrefixRegMode OBJECT-TYPE SYNTAX INTEGER { implicitMode (1), explicitMode (2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates the mode in which the mobile network prefixes will be registered with the home agent. implicitMode(1): the Mobile Network Prefix Option will not be included in the Binding Update by the mobile router. explicitMode(2): the mobile router will include one or more Mobile Network Prefix Options in the Binding Update. nemoHaMobileNetworkPrefixTable OBJECT-TYPE SYNTAX SEQUENCE OF NemoHaMobileNetworkPrefixEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the mobile network prefixes that the home agent maintains for the mobile router. The mobile network prefixes in this table are registered by Binding Updates or are manually pre-configured. " REFERENCE "RFC 3963: Section 6.1.2" ::= { nemoHaRegistration 1 } nemoHaMobileNetworkPrefixEntry OBJECT-TYPE SYNTAX NemoHaMobileNetworkPrefixEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry for a mobile network prefix. The nemoHaMobileNetworkPrefixSeqNo object is used to distinguish between multiple instances of the mobile network prefix in the same Binding Update for the same set of mip6BindingHomeAddressType and mip6BindingHomeAddress. There is no upper-bound on the maximum number of mobile network prefixes in a Binding Update but, for practical purposes, the upper bound of the value nemoHaMobileNetworkPrefixSeqNo OBJECT-TYPE SYNTAX Unsigned32 (1..1024) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A Binding Update may have multiple mobile network prefixes. This object, along with mip6BindingHomeAddressType and mip6BindingHomeAddress, uniquely identifies a row containing a single mobile network prefix for a mobile router in this table. " REFERENCE "RFC 3963: Sections 2, 6.1, 6.2" ::= { nemoHaMobileNetworkPrefixEntry 1 } nemoHaMobileNetworkPrefixType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The address type for the mobile network prefix that follows. " nemoHaMobileNetworkPrefix OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "A mobile network prefix related to the corresponding Binding Update. MAX-ACCESS read-only STATUS current DESCRIPTION "The information source of the mobile network prefix configured with the Binding Update. configured(1): indicates that the mobile network prefix has been manually pre-configured. bindingUpdate(2): indicates that the information is introduced to the home agent by the Mobile Network nemoBindingMrMode OBJECT-TYPE SYNTAX INTEGER { implicitMode(1), explicitMode(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "implicitMode(1): the Mobile Network Prefix Option is not included in the Binding Update by the mobile router. explicitMode(2): the mobile router included one or more Mobile Network Prefix Options in the Binding Update. " REFERENCE "RFC 3963: Sections 5.2, 6.1.1, 6.2" ::= { nemoBindingCacheEntry 2 } nemoMrPrefixRegMode: The value of this object is used to control the mode in which mobile network prefixes will be registered with the home agent. Access to this object may be abused to disrupt the setting up of mobile network prefixes. http://www.ietf.org/rfc/rfc5522.txt 5522 Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks. W. Eddy, W. Ivancic, T. Davis. October 2009. (Format: TXT=79570 bytes) (Status: INFORMATIONAL) Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks The base NEMO standard [1] extends Mobile IPv6 [2] for singular mobile hosts in order to be used by Mobile Routers (MRs) supporting entire mobile networks. NEMO allows mobile networks to efficiently remain reachable via fixed IP address prefixes no matter where they relocate within the network topology. This is accomplished through the maintenance of a bidirectional tunnel between a NEMO MR and a NEMO-supporting Home Agent (HA) placed at some relatively stable point in the network. NEMO does not provide Mobile IPv6's Route Optimization (RO) features to Mobile Network Nodes (MNNs) other than to the NEMO MR itself. Corresponding Nodes (CNs) that communicate For decades, mobile networks of some form have been used for communications with people and avionics equipment on board aircraft and spacecraft. These have not typically used IP, although architectures are being devised and deployed based on IP in both the aeronautics and space exploration communities (see Appendix A and Appendix B for more information). An aircraft or spacecraft generally contains many computing nodes, sensors, and other devices that are possible to address individually with IPv6. This is desirable to support network-centric operations concepts. Given that a craft has only a small number of access links, it is very natural to use NEMO MRs to localize the functions needed to manage the large onboard network's reachability over the few dynamic access links. On an aircraft, the nodes are arranged in multiple, independent networks, based on their functions. These multiple networks are required for regulatory reasons to have different treatments of their air-ground traffic and must often use distinct air-ground links and service providers. Some PIES nodes are currently using 2.5G/3G links for mobile data services, and these may be able to migrate to an IP-based onboard mobile network, when available. An underlying requirement that would be assumed by the use of Mobile IP technology for managing mobility (rather than a higher-layer approach) is that IP addresses used both within the mobile network and by CNs to start new sessions with nodes within the mobile network remain constant throughout the course of flights and operations. For ATS and AOS, this allows the Home Addresses (HoAs) to serve as node identifiers, rather than just locators, and for PIES it allows common persistent applications (e.g., Voice over IP (VoIP) clients, VPN clients, etc.) to remain connected throughout a flight. Prior aeronautical network systems like the prior OSI-based ATN and Connexion by Boeing set a precedent for keeping a fixed Mobile Network Prefix (MNP), though they relied on interdomain routing protocols (IDRP and BGP) to accomplish this, rather than NEMO technology. This requirement applies to the selection in general of a mobility management technology, and not specifically to an RO solution once NEMO has been decided on for mobility management. Even if RO is available to increase the performance of a mobile network's traffic, it may not be appropriate for all flows. be able to operate based on Binding Cache entries even after an HA failure. With RO, an HA failure primarily impacts the ability to connect new application flows to a mobile network. There is no intention to support "Internet-less" operation through this requirement. When an MR is completely disconnected from the majority of the network with which it is intended to communicate, including its HA, there is no requirement for it to be able to retain any communications involving parties outside the mobile networks managed by itself. purposes of RO. The previous OSI-based ATN system used IDRP and an "island" concept for maintaining connectivity to the mobile network but was not tested on a large scale deployment. The Connexion by Boeing system used BGP announces and withdrawals as a plane moved across the globe in order to maintain connectivity [10]. This was found to contribute to a significant amount of churn in the global Internet routing tables, which is undesirable for a number of reasons, and must be avoided in the future. [21] Ivancic, W., "Multi-Domained, Multi-Homed Mobile Networks", Work in Progress, September 2006. Supporting mobility in an IP-based network may be vastly different than it is in the OSI-based ATN, which uses the Inter-Domain Routing Protocol (IDRP) to recompute routing tables as mobile networks change topological points of attachment. ICAO recognizes this and has studied various mobility techniques based on link, network, transport, routing, and application protocols [14]. Work done within ICAO has identified the NEMO technology as a promising candidate for use in supporting global, IP-based mobile networking. The main concerns with NEMO have been with its current lack of route optimization support and its potentially complex configuration requirements in a large airport environment with multiple service providers and 25 or more airlines sharing the same infrastructure. http://www.ietf.org/rfc/rfc5550.txt 5550 The Internet Email to Support Diverse Service Environments (Lemonade) Profile. D. Cridland, Ed., A. Melnikov, Ed., S. Maes, Ed.. August 2009. (Format: TXT=84862 bytes) (Obsoletes RFC4550) (Updates RFC4469, RFC4467) (Status: PROPOSED STANDARD) Resynchronization is a costly part of an IMAP session, and mobile networks are generally more prone to unintended disconnection, which in turn makes this problem more acute. Therefore, Lemonade Message Stores provide a suite of extensions to reduce the synchronization cost. Lemonade and TCP provide for long-lived idle connections between the client and mail store, allowing the server to push notifications within IMAP. Some mobile networks support dormancy, which shuts down the radio traffic channel during idle periods to conserve handset and network resources, while maintaining IP and TCP state. (See the [LEMONADE-DEPLOYMENTS] document for more information.) o Measures to address a perceived need to traverse firewalls and mobile network intermediaries http://www.ietf.org/rfc/rfc5555.txt 5555 Mobile IPv6 Support for Dual Stack Hosts and Routers. H. Soliman, Ed.. June 2009. (Format: TXT=92387 bytes) (Status: PROPOSED STANDARD) A flag indicating, when set, that the mobile node requests a mobile network prefix. This flag is only relevant for new requests, and must be ignored for binding refreshes. http://www.ietf.org/rfc/rfc5568.txt 5568 Mobile IPv6 Fast Handovers. R. Koodli, Ed.. July 2009. (Format: TXT=121373 bytes) (Obsoletes RFC5268) (Status: PROPOSED STANDARD) o The Proxy Mobile IPv6 protocol [RFC5213] has been adopted for the deployment of fourth-generation mobile networks. This has established Mobility Header as the default type for critical IP mobility signaling. o The Mobile IPv6 protocol [RFC3775] (particularly, the Dual-stack MIP6 or DSMIP6 [RFC5555]) protocol, which is also expected to be deployed in the fourth-generation mobile networks, similarly relies on Mobility Header for critical IP mobility signaling. http://www.ietf.org/rfc/rfc5572.txt 5572 IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP). M. Blanchet, F. Parent. February 2010. (Format: TXT=60017 bytes) (Status: EXPERIMENTAL) 1. Introduction ....................................................4 2. Description of the TSP Framework ................................4 2.1. NAT Discovery ..............................................6 2.2. Any Encapsulation ..........................................6 2.3. Mobility ...................................................6 3. Advantages of TSP ...............................................7 4. Protocol Description ............................................7 4.1. Terminology ................................................7 4.2. Topology ...................................................8 4.3. Overview ...................................................8 4.4. TSP Signaling ..............................................9 4.4.1. Signaling Transport .................................9 4.4.2. Authentication Phase ...............................11 4.4.3. Command and Response Phase .........................14 4.5. Tunnel Establishment ......................................16 4.5.1. IPv6-over-IPv4 Tunnels .............................16 4.5.2. IPv6-over-UDP Tunnels ..............................16 4.6. Tunnel Keep-Alive .........................................16 4.7. XML Messaging .............................................17 4.7.1. Tunnel .............................................17 4.7.2. Client Element .....................................18 4.7.3. Server Element .....................................19 4.7.4. Broker Element .....................................19 5. Tunnel Request Examples ........................................19 5.1. Host Tunnel Request and Reply .............................19 5.2. Router Tunnel Request with a /48 Prefix Delegation and Reply .................................................20 5.3. IPv4 over IPv6 Tunnel Request .............................22 5.4. NAT Traversal Tunnel Request ..............................23 6. Applicability of TSP in Different Networks .....................24 6.1. Provider Networks with Enterprise Customers ...............24 6.2. Provider Networks with Home/Small Office Customers ........25 6.3. Enterprise Networks .......................................25 6.4. Wireless Networks .........................................25 6.5. Unmanaged Networks ........................................26 6.6. Mobile Hosts and Mobile Networks ..........................26 7. IANA Considerations ............................................26 8. Security Considerations ........................................27 9. Conclusion .....................................................27 10. Acknowledgements ..............................................27 11. References ....................................................28 11.1. Normative References .....................................28 11.2. Informative References ...................................28 Appendix A. The TSP DTD ..........................................30 Appendix B. Error Codes ..........................................31 6.6. Mobile Hosts and Mobile Networks Mobile networks share the applicability of the mobile hosts. Moreover, in the TSP framework, they also keep their prefix assignment and can control the routing. NAT discovery can also be used. http://www.ietf.org/rfc/rfc5580.txt 5580 Carrying Location Objects in RADIUS and Diameter. H. Tschofenig, Ed., F. Adrangi, M. Jones, A. Lior, B. Aboba. August 2009. (Format: TXT=119753 bytes) (Status: PROPOSED STANDARD) The E212 namespace can be used to indicate operator names based on the Mobile Country Code (MCC) and Mobile Network Code (MNC) defined in [ITU212]. The MCC/MNC values are assigned by the Telecommunications Standardization Bureau (TSB) within the ITU-T http://www.ietf.org/rfc/rfc5594.txt 5594 Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008. J. Peterson, A. Cooper. July 2009. (Format: TXT=61652 bytes) (Status: INFORMATIONAL) One simple way to potentially make peer selection more efficient would be for a peer to prefer peers within its own Autonomous System (AS). Transfers between peers within the same AS may be faster on some networks, although more data is needed to determine the extent of the potential improvement. On mobile networks, for example, the utility of AS numbers is limited since they do not correlate to geographic location. Peers may also see improvements by connecting to other peers within a specific set of ASes or IP prefixes provided by their ISPs. Some ISPs may have an incentive to expose this granularity of information because it will potentially reduce their transit costs. http://www.ietf.org/rfc/rfc5614.txt 5614 Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding. R. Ogier, P. Spagnolo. August 2009. (Format: TXT=170106 bytes) (Updated by RFC7038) (Status: EXPERIMENTAL) The appendices specify packet formats, detailed algorithms for the MDR selection algorithm, an algorithm for the selection of a subset of neighbors to advertise in the router-LSA to provide shortest-path routing, a proposed option that uses non-ackable LSAs to provide periodic flooding without the overhead of Link State Acknowledgments, and simulation results that predict the performance of OSPF-MDR in mobile networks with up to 200 nodes. Additional information and resources for OSPF-MDR can be found at http://www.manet-routing.org. Differential Hellos should be used to reduce the size of Hello packets when the average number of neighbors is large (e.g., greater than 50). Differential Hellos are obtained by setting the parameter 2HopRefresh to an integer greater than 1, with the recommended value being 3. Good performance in simulated mobile networks with up to 160 nodes has been obtained using the default configuration with differential Hellos. Good performance in simulated mobile networks with up to 200 nodes has been obtained using the same configuration except with minimal LSAs (LSAFullness = 0). Simulation results are presented in Appendix E. This requirement does not guarantee perfect synchronization, but simulations have shown that it performs well in mobile networks. This requirement avoids, for example, forwarding packets to a new neighbor that is poorly synchronized because it was not reachable before it became a neighbor. In a highly mobile network, it is possible that a router almost always originates a new router-LSA every MinLSInterval seconds. In this case, it should not be necessary to send Acks for such an LSA, or to retransmit such an LSA as a unicast, or to describe such an LSA in a DD packet. In this case, the originator of an LSA MAY indicate that the router-LSA is "non-ackable" by setting the L bit in the options field of the LSA (see Section A.1). For example, a router can originate non-ackable LSAs if it determines (e.g., based on an exponential moving average) that a new LSA is originated every MinLSInterval seconds at least 90 percent of the time. (Simulations can be used to determine the best threshold.) http://www.ietf.org/rfc/rfc5682.txt 5682 Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP. P. Sarolahti, M. Kojo, K. Yamamoto, M. Hata. September 2009. (Format: TXT=47337 bytes) (Updates RFC4138) (Status: PROPOSED STANDARD) There are a number of potential reasons for spurious retransmission timeouts. First, some mobile networking technologies involve sudden delay spikes on transmission because of actions taken during a hand- off. Second, a hand-off may take place from a low latency path to a high latency path, suddenly increasing the round-trip time beyond the current RTO value. Third, on a low-bandwidth link the arrival of competing traffic (possibly with higher priority), or some other change in available bandwidth, can cause a sudden increase of the round-trip time. This may trigger a spurious retransmission timeout. A persistently reliable link layer can also cause a sudden delay when a data frame and several retransmissions of it are lost for some reason. This document does not distinguish between the different causes of such a delay spike. Rather, it discusses the spurious retransmission timeouts caused by a delay spike in general. http://www.ietf.org/rfc/rfc5687.txt 5687 GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements. H. Tschofenig, H. Schulzrinne. March 2010. (Format: TXT=40880 bytes) (Status: INFORMATIONAL) 1. Introduction ....................................................3 2. Terminology .....................................................3 3. Scenarios .......................................................4 3.1. Fixed-Wired Environment ....................................4 3.2. Mobile Network .............................................7 3.3. Wireless Access ............................................8 4. Discovery of the Location Information Server ....................9 5. Identifier for Location Determination ..........................11 6. Requirements ...................................................14 7. Security Considerations ........................................16 8. Contributors ...................................................17 9. Acknowledgements ...............................................18 10. References ....................................................18 10.1. Normative References .....................................18 10.2. Informative References ...................................18 3.2. Mobile Network http://www.ietf.org/rfc/rfc5757.txt 5757 Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey. T. Schmidt, M. Waehlisch, G. Fairhurst. February 2010. (Format: TXT=92632 bytes) (Status: INFORMATIONAL) +------+ +------+ | MN | =====> | MN | +------+ +------+ | . | . | . +-------+ +-------+ | LAR 1 | | LAR 2 | +-------+ +-------+ \ / *** *** *** *** * ** ** ** * +------+ +------+ * * | MN | =====> | MN | * Mobile Network * +------+ +------+ * * | . * ** ** ** * | . *** *** *** *** | . | . +-------+ +-------+ +-------+ +-------+ | AR 1 | | AR 2 | | AR 1 | =====> | AR 2 | +-------+ +-------+ +-------+ +-------+ | | | | *** *** *** *** *** *** *** *** * ** ** ** * * ** ** ** * * * * * * Fixed Internet * * Fixed Internet * * * * * * ** ** ** * * ** ** ** * *** *** *** *** *** *** *** *** Mobility protocols need to consider the implications and requirements for Authentication, Authorization, and Accounting (AAA). An MN may have been authorized to receive a specific multicast group when using one mobile network, but this may not be valid when attaching to a different network. In general, the AAA association for an MN may change between attachments, or may be individually chosen prior to network (re-)association. The most appropriate network path may be [73] Lin, C.R. et al. "Scalable Multicast Protocol in IP-Based Mobile Networks", Wireless Networks, 8 (1), pp. 27-36, January, 2002. http://www.ietf.org/rfc/rfc5808.txt 5808 Requirements for a Location-by-Reference Mechanism. R. Marshall, Ed.. May 2010. (Format: TXT=32475 bytes) (Status: INFORMATIONAL) As justification for an LbyR model, consider the circumstance that in some mobile networks it is not efficient for the end host to periodically query the Location Information Server (LIS) for up-to- date location information. This is especially the case when power availability is a constraint or when a location update is not immediately needed. Furthermore, the end host might want to delegate the task of retrieving and publishing location information to a third party, such as to a presence server. Additionally, in some deployments, the network operator may not want to make location information widely available. These kinds of location scenarios form the basis of motivation for the LbyR model. http://www.ietf.org/rfc/rfc5944.txt 5944 IP Mobility Support for IPv4, Revised. C. Perkins, Ed.. November 2010. (Format: TXT=239935 bytes) (Obsoletes RFC3344) (Status: PROPOSED STANDARD) A mobile node can be a router that is responsible for the mobility of one or more entire networks moving together, perhaps on an airplane, a ship, a train, an automobile, a bicycle, or a kayak. The nodes connected to a network served by the mobile router may themselves be fixed nodes or mobile nodes or routers. In this document, such networks are called "mobile networks". A mobile router MAY act as a foreign agent and provide a foreign agent care-of address to mobile nodes connected to the mobile network. Typical routing to a mobile node via a mobile router in this case is illustrated by the following example: This example illustrates the case in which a mobile node is attached to a mobile network. That is, the mobile node is mobile with respect to the network, which itself is also mobile (here with respect to the ground). If, instead, the node is fixed with respect to the mobile network (the mobile network is the fixed node's home network), then either of two methods may be used to cause datagrams from correspondent nodes to be routed to the fixed node. Alternatively, the mobile router MAY advertise connectivity to the entire mobile network using normal IP routing protocols through a bidirectional tunnel to its own home agent. This method avoids the need for nested tunneling of datagrams. http://www.ietf.org/rfc/rfc6036.txt 6036 Emerging Service Provider Scenarios for IPv6 Deployment. B. Carpenter, S. Jiang. October 2010. (Format: TXT=45113 bytes) (Status: INFORMATIONAL) Asked about plans for Mobile IPv6 (or Nemo mobile networks), 19% said yes, and 71% said no, with the others uncertain. A detailed analysis shows that of the six ISPs who responded positively, three are large mobile operators (and a fourth mobile operator said no). The other three who responded positively were broadband ISPs ranging from small to very large. o Any plans for Mobile IPv6 (or Nemo mobile networks)? 6 yes, 2 uncertain, 22 no 34. Any plans for Mobile IPv6 (or Nemo mobile networks)? http://www.ietf.org/rfc/rfc6077.txt 6077 Open Research Issues in Internet Congestion Control. D. Papadimitriou, Ed., M. Welzl, M. Scharf, B. Briscoe. February 2011. (Format: TXT=130169 bytes) (Status: INFORMATIONAL) As outlined earlier in this document, the round-trip time is typically not a constant value. For a given path, there is a theoretical minimum value, which is given by the minimum transmission, processing, and propagation delay on that path. However, additional variable delays might be caused by congestion, cross-traffic, shared-media access control schemes, recovery procedures, or other sub-IP layer mechanisms. Furthermore, a change of the path (e.g., route flapping, hand-over in mobile networks) can result in completely different delay characteristics. http://www.ietf.org/rfc/rfc6089.txt 6089 Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support. G. Tsirtsis, H. Soliman, N. Montavont, G. Giaretta, K. Kuladinithi. January 2011. (Format: TXT=69353 bytes) (Updates RFC5648) (Status: PROPOSED STANDARD) Mobile IPv6 [RFC3775], Dual-Stack MIPv6 (DSMIPv6) [RFC5555], and Network Mobility (NEMO) Basic Support [RFC3963] allow a mobile node / mobile router to manage its mobility using the binding update message, which binds one care-of address to one home address and associated mobile networks. The binding update message can be sent to the home agent. In Mobile IPv6, the binding update can also be sent to a correspondent node or to a mobility anchor point (see [RFC5380]). The semantics of the binding update are limited to care-of address changes. That is, [RFC3775], [RFC5555], and [RFC3963] do not allow a mobile node / mobile router to bind more than one address to the home address. In [RFC5648], Mobile IPv6 and NEMO Basic Support are extended to allow the binding of more than one care-of address to a home address. This specification further extends Mobile IPv6, DSMIPv6, and NEMO Basic Support to allow them to specify policies associated with each binding. A policy can contain a request for special treatment of a particular IPv4 or IPv6 flow, which is viewed as a group of packets matching a traffic selector. Hence, this specification allows a mobile node / mobile router to bind a particular flow to a care-of address without affecting other flows using the same home address. In addition, this specification allows to bind a particular flow to a particular care-of address directly with correspondent node and mobility agents (i.e., home agents [RFC3775] and mobility anchor points [RFC5380]). http://www.ietf.org/rfc/rfc6115.txt 6115 Recommendation for a Routing Architecture. T. Li, Ed.. February 2011. (Format: TXT=178526 bytes) (Status: INFORMATIONAL) The advantage of LISP+ALT is that its ability to handle billions of EIDs is not constrained by the need to transmit or store the mapping to any one location. Such numbers, beyond a few tens of millions of EIDs, will only result if the system is used for mobility. Yet the concerns just mentioned about ALT's structure arise from the millions of ETRs that would be needed just for non-mobile networks. The maximum number of non-mobile networks requiring multihoming, etc., is likely to be ~10 million, so most of the 10 billion mappings would be for mobile devices. However, TTR mobility does not involve frequent mapping changes since most MNs only rarely move more than 1000 km. http://www.ietf.org/rfc/rfc6118.txt 6118 Update of Legacy IANA Registrations of Enumservices. B. Hoeneisen, A. Mayrhofer. March 2011. (Format: TXT=115372 bytes) (Updates RFC3762, RFC3764, RFC3953, RFC4143, RFC4002, RFC4238, RFC4355, RFC4415, RFC4769, RFC4969, RFC4979, RFC5028, RFC5278, RFC5333) (Status: PROPOSED STANDARD) Application-Based, Common voice tel tel The kind of communication indicated by this Enumservice is "Interactive Voice". From a protocol perspective, this communication is expected to involve bidirectional media streams carrying audio data. A client may imply that the person controlling population of a NAPTR holding this Enumservice indicates their capability to engage in an interactive voice session when contacted using the URI generated by this NAPTR. See , Section 5. COMMON (updated by RFC 6118) This Enumservice indicates that the person responsible for the NAPTR is accessible via the PSTN (Public Switched Telephone Network) or PLMN (Public Land Mobile Network) using the value of the generated URI. The kind of subsystem required to initiate a Voice Enumservice with this Subtype is a "Dialler". This is a subsystem that either provides a local Enumservice Name: "voice" Enumservice Type: "voice" Enumservice Subtype: "tel" URI Scheme: 'tel:' Functional Specification: The kind of communication indicated by this Enumservice is "Interactive Voice". From a protocol perspective, this communication is expected to involve bidirectional media streams carrying audio data. A client may imply that the person controlling population of a NAPTR holding this Enumservice indicates their capability to engage in an interactive voice session when contacted using the URI generated by this NAPTR. Security Considerations: See Section 5 of [RFC4415] Intended Usage: COMMON Authors: Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail see Authors' Addresses section) Any other information the author deems interesting: o This Enumservice indicates that the person responsible for the NAPTR is accessible via the PSTN (Public Switched Telephone Network) or PLMN (Public Land Mobile Network) using the value of the generated URI. o The kind of subsystem required to initiate a Voice Enumservice with this sub-type is a "Dialler". This is a subsystem that either provides a local connection to the PSTN or PLMN, or that provides an indirect connection to those networks. The http://www.ietf.org/rfc/rfc6126.txt 6126 The Babel Routing Protocol. J. Chroboczek. April 2011. (Format: TXT=99833 bytes) (Status: EXPERIMENTAL) Second, Babel does impose a hold time when a prefix is retracted (Section 3.5.5). While this hold time does not apply to the exact prefix being retracted, and hence does not prevent fast reconvergence should it become available again, it does apply to any shorter prefix that covers it. Hence, if a previously deaggregated prefix becomes aggregated, it will be unreachable for a few minutes. This makes Babel unsuitable for use in mobile networks that implement automatic prefix aggregation. http://www.ietf.org/rfc/rfc6139.txt 6139 Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) Scenarios. S. Russert, Ed., E. Fleischman, Ed., F. Templin, Ed.. February 2011. (Format: TXT=101101 bytes) (Status: INFORMATIONAL) Ubiquitous wireless access enables connection to network infrastructure nearly anywhere. Vehicles and even persons can host networks that move around with them. For example, commercial aircraft networks include requirements for nomadic networks, local mobility, and global mobility where the connection point between airplane and ground station can move from one continent to another. Mobile networks need to be able to use provider-independent (PI) as well as provider-aggregated (PA) address prefixes. Some applications such as voice require rapid or seamless connection handoffs -- also known as session survivability. Internet routing should not be unduly disrupted by mobility, so movement of mobile nodes or edge networks should not cause large ripples of routing protocol traffic, especially in the DFZ. http://www.ietf.org/rfc/rfc6155.txt 6155 Use of Device Identity in HTTP-Enabled Location Delivery (HELD). J. Winterbottom, M. Thomson, H. Tschofenig, R. Barnes. March 2011. (Format: TXT=58542 bytes) (Updated by RFC6915) (Status: PROPOSED STANDARD) [E.213] ITU-T, "E.213 : Telephone and ISDN numbering plan for land mobile stations in public land mobile networks (PLMN)", ITU-T Recommendation E.213, November 1988, . http://www.ietf.org/rfc/rfc6159.txt 6159 Session-Specific Explicit Diameter Request Routing. T. Tsou, G. Zorn, T. Taylor, Ed.. April 2011. (Format: TXT=45051 bytes) (Status: INFORMATIONAL) o a Diameter proxy in the visited mobile network (e.g., the 3GPP AAA proxy in the terminal visited network), and http://www.ietf.org/rfc/rfc6179.txt 6179 The Internet Routing Overlay Network (IRON). F. Templin, Ed.. March 2011. (Format: TXT=92638 bytes) (Status: EXPERIMENTAL) Route optimization considerations for mobile networks are found in [RFC5522]. [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks", RFC 5522, October 2009. http://www.ietf.org/rfc/rfc6180.txt 6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment. J. Arkko, F. Baker. May 2011. (Format: TXT=49679 bytes) (Status: INFORMATIONAL) This deployment model would fit well, for instance, a corporate or mobile network that offers IPv6-only networking but where users still wish to access content from the IPv4 Internet. The former service is used today in some university networks, and the latter in some corporate and mobile networks. The stateless service is naturally better suited for servers, and the stateful service for large numbers of client devices. The latter case occurs typically in a public network access setting. The two services can of course also be used together. In this scenario, network-layer translation provides for straightforward services for most applications crossing the IPv4-only/IPv6-only boundary. [v6-in-mobile] Koodli, R., "Mobile Networks Considerations for IPv6 Deployment", Work in Progress, May 2011. http://www.ietf.org/rfc/rfc6190.txt 6190 RTP Payload Format for Scalable Video Coding. S. Wenger, Y.-K. Wang, T. Schierl, A. Eleftheriadis. May 2011. (Format: TXT=250504 bytes) (Status: PROPOSED STANDARD) This situation can be handled best by introducing middleboxes close to the edge of the core network, which receive the layered multicast streams and compose the single SVC scalable bitstream according to the needs of the endpoint connected. These middleboxes are called MANEs throughout this specification. In practice, the authors envision the MANE to be part of (or at least physically and topologically close to) the base station of a mobile network, where all the signaling and media traffic necessarily are multiplexed on the same physical link. http://www.ietf.org/rfc/rfc6276.txt 6276 DHCPv6 Prefix Delegation for Network Mobility (NEMO). R. Droms, P. Thubert, F. Dupont, W. Haddad, C. Bernardos. July 2011. (Format: TXT=30430 bytes) (Status: PROPOSED STANDARD) One aspect of network mobility support is the assignment of a prefix or prefixes to a mobile router for use on the links in the mobile network. This document specifies how DHCPv6 prefix delegation can be used for this configuration task. The mobile router plays the role of requesting router, while the home agent assumes the role of delegating router. When the mobile router is outside its home network, the mobile router also assumes the role of DHCPv6 relay agent, co-located with the requesting router function. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. DHCPv6 Prefix Delegation of Mobile Network Prefixes . . . . . 4 3.1. Exchanging DHCPv6 Messages When the Mobile Router Is Not at Home . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.1. Relay Agent Configuration . . . . . . . . . . . . . . 7 3.1.2. Transmission of DHCPv6 Messages . . . . . . . . . . . 8 3.1.3. Receipt of DHCPv6 Messages . . . . . . . . . . . . . . 8 3.2. Exchanging DHCPv6 Messages When the Mobile Router Is at Home . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Selecting a Home Agent That Provides DHCPv6PD . . . . . . 9 3.4. Minimizing DHCPv6PD Messages . . . . . . . . . . . . . . . 10 3.5. Other DHCPv6 Functions . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . . 13 To use DHCPv6PD as a prefix assignment mechanism in mobile networks, when the mobile router is located at home, the home agent assumes the role of the delegating router and the mobile router assumes the role The following terms used in this document are defined in the Mobile Network terminology document [RFC4885]: Mobile Network (NEMO) Mobile Network Prefix (MNP) 3. DHCPv6 Prefix Delegation of Mobile Network Prefixes The NEMO Basic Support protocol [RFC3963] extends the Mobile IPv6 protocol [RFC6275] to enable network mobility. With the NEMO Basic Support protocol, a mobile router uses Mobile IPv6 to establish and maintain a session with its home agent and uses bidirectional tunneling between the mobile router and the home agent to provide a path through which nodes attached to links in the mobile network can maintain connectivity with nodes not in the NEMO. The requirements for Network Mobility [RFC4885] include the ability of the mobile router to receive delegated prefixes that can then be assigned to links in the mobile network. DHCPv6PD can be used to meet this requirement for prefix delegation. To use DHCPv6PD for mobile networks, when the mobile router is located at home, the home agent assumes the role of the delegating router and the mobile router assumes the role of the requesting router. However, when the mobile router is away from home, in addition to the roles when the mobile router is located at home, the mobile router also assumes the role of a DHCPv6 relay agent co-located with the requesting router function. Figure 1: Deployment topologies of the use of DHCPv6PD for delegation of Mobile Network Prefixes If the mobile router does not have any active delegated prefixes (with unexpired leases), the mobile router MUST initiate a DHCPv6 message exchange with a DHCPv6 Solicit message as described in Section 17 of [RFC3315] and Section 11.1 of [RFC3633]. The delegating router at the home agent responds with an Advertise message. Then, the mobile router MUST request a set of prefixes by sending a Request message. The delegating router includes the delegated prefixes in a Reply message. Note that in this case, the mobile router has previously sent a Binding Update to the home agent without knowing yet the set of prefixes that it can use as mobile network prefixes. The home agent, upon reception of the implicit Binding Update from the mobile router, MUST select (in case this was In case the mobile router has one or more active delegated prefixes -- for example, as if the mobile router reboots or the mobile network prefix(es) currently used by the mobile router is about to expire -- the mobile router MUST initiate a DHCPv6 message exchange with a DHCPv6 Rebind message as described in Section 18.1.2 of [RFC3315] and Section 12.1 of [RFC3633]. ----------------------------- -------- | MR | | HA | | (RR) (DRA) | | (DR) | ---------------------------- -------- | | Binding Update | | |------------------------>| | | (HoA, CoA) | | | | | | Binding Ack | | |<------------------------| | | | | DHCPv6 Solicit | DHCPv6 Solicit | |..................>|--=====================->| | | | | DHCPv6 Advertise | DHCPv6 Advertise | |<..................|<-=====================--| | | | | DHCPv6 Request | DHCPv6 Request | |..................>|--=====================->| | | | | DHCPv6 Reply | DHCPv6 Reply | |<..................|<-=====================--| | | (Mobile Network Prefix) | | | | Note that a mobile router using DHCPv6PD to obtain the set of prefixes to be used as mobile network prefixes cannot derive its home address from one of its mobile network prefix(es) (as the mobile router does not know them before registering to the home agent). Therefore, the mobile router MUST assign its home address from the prefix on its Home Link. -------- -------- | MR | | HA | | (RR) | | (DR) | -------- -------- | | | DHCPv6 Solicit | |------------------------>| | | | DHCPv6 Advertise | |<------------------------| | | | DHCPv6 Request | |------------------------>| | | | DHCPv6 Reply | |<------------------------| | (Mobile Network Prefix) | | | The use DHCPv6PD in a mobile network can be combined with the Rapid Commit option [RFC3315] to provide DHCPv6 prefix delegation with a two-message exchange between the mobile router and the DHCPv6PD delegating router. This document describes the use of DHCPv6 for prefix delegation in mobile networks. In addition to the security considerations for DHCPv6 described in the "Security Considerations" section of the DHCPv6 base specification [RFC3315] and the "Security Considerations" of the DHCPv6 Prefix Delegation specification [RFC3633], there are two aspects that need to be considered. First, the NEMO Basic Support specification requires the home agent to prevent a mobile router from claiming mobile network prefixes belonging to another mobile router. Upon reception of an implicit Binding Update from a mobile router, the home agent MUST only add prefixes into the mobile router's Binding Cache Entry if the mobile router has a valid DHCPv6 Prefix Delegation lease for said prefixes. If the mobile router does not have a valid DHCPv6 Prefix Delegation lease, the home agent MUST NOT add any prefixes into the mobile router's Binding Cache Entry. Upon the mobile router obtaining a http://www.ietf.org/rfc/rfc6301.txt 6301 A Survey of Mobility Support in the Internet. Z. Zhu, R. Wakikawa, L. Zhang. July 2011. (Format: TXT=84861 bytes) (Status: INFORMATIONAL) NEMO introduces a new entity called a Mobile Router (note that this is different from the "Mobile Router" in the LSR Protocol). Every mobile network has at least one Mobile Router. A Mobile Router is similar to a mobile node in Mobile IP, but instead of having a single HoA, it has one or more IP prefixes as the Identifier. After establishing a bidirectional tunnel with the Home Agent, the Mobile Router distributes its mobile network's prefixes (namely, Mobile Prefixes) through the tunnel to the Home Agent. The Mobile Prefix of a mobile network is not leaked to its access router (i.e., the access router never knows that it can reach the Mobile Prefixes via the Mobile Router). The Home Agent in turn announces the reachability to the Mobile Prefix. Packets to and from the mobile network flow through the bidirectional tunnel between the Mobile Router and the Home Agent to their destinations. Note that mobility is transparent to the nodes in the moving network. Connexion [Boeing] was a mobility support service provided by Boeing that uses BGP to support network mobility. Every mobile network is assigned a /24 IP address prefix (stable Identifier), and the CN uses this Identifier to reach the moving network, which means that the global routing system is responsible for finding a path to the mobile network. When an airplane moves between its access routers on the ground, it withdraws its prefix from the previous access router and announces the prefix via the new access point. As a result, the location change of the plane is effectively propagated to the rest of the world. However, if the number of moving networks becomes large, the amount of BGP updates will also increase proportionally, resulting in severe global routing dynamics. WINMO [WINMO] (which stands for Wide-Area IP Network Mobility) was introduced in 2008 to address the routing update overhead problem of Connexion. Like Connexion, WINMO also assigns each mobile network a stable prefix. However, through two new approaches, WINMO can reduce the BGP updates overhead for mobile networks by orders of magnitude lower than those of Connexion. First, WINMO uses various heuristics to reduce the propagation scope of routing updates caused by mobile movements. Consequently, not every router may know all the mobiles' current locations. Handling this issue led to the second and more fundamental approach taken by WINMO: it adopts the basic idea from Mobile IP by assigning each mobile network a "home" in the following way. WINMO assigns each mobile network a prefix out of a small set of well-defined Mobile Prefixes. These Mobile Prefixes are announced by a small set of Aggregation Routers, which also keep track of the mobile network's current locations. Therefore, these Aggregation Routers play a similar role to Home Agents in Mobile IP and can be counted on as a last resort to reach mobile networks globally. To prevent frequent Interior Border Gateway Protocol (iBGP) routing updates due to the movement of mobile networks within an Autonomous System (AS), WINMO also introduces a Home Agent for the Mobile Prefixes: only a Designated BGP-speaking Router (DBR) acts as the origin of Mobile Prefixes, and mobile networks always update the addresses of their access routers (intra-AS Locators) with DBR, which resembles the binding updates in Mobile IP. Thus, packets destined to mobile networks are forwarded to DBR after they enter the border of an AS, and DBR will tunnel them to the current locations of mobile networks. A new BGP community attribute, which includes the mobile network's intra-AS Locator in each packet, is also defined to eliminate the triangle-routing problem caused by DBR. The border routers of the AS can tunnel packets directly to the mobile network based on the new attribute. ILNPv6 [ILNP] stands for Identifier-Locator Network Protocol for IPv6. The ILNPv6 packet header was deliberately made similar to the IPv6 header. Essentially, it breaks an IPv6 address into two components: high-order 64 bits as a Locator and low-order 64 bits as an Identifier. The Identifier identifies a host, instead of an interface, and is used in upper-layer protocols (e.g., TCP, FTP); on the other hand, the Locator changes with the movement of the mobile node, and a set of Locators can be associated with a single Identifier. Several new DNS resource records (RRs) are required, among which I (Identifier Record) and L (Locator Record) are most important. As in current Internet, the CN will query the DNS about the mobile's domain name to determine where to send the packet. During the movement, the mobile node uses Secure Dynamic DNS update to ensure that the Locator values stored in DNS are up to date. It also sends Locator Update messages to the CNs that are currently communicating with it. As an optimization, ILNPv6 supports soft- handoff, which allows the use of multiple Locators simultaneously to achieve smooth transition. ILNPv6 also supports mobile networks. Proxy Mobile IP (PMIP) [RFC5213] was proposed in 2006 to meet the interest of mobile network operators who desire to support mobility in a network rather than on mobile devices and to have tighter control on mobility support. Mobility is completely transparent to the mobile devices and is provided to legacy IP devices. PMIP introduces two new types of network nodes, Local Mobility Anchor (LMA) and Mobile Access Gateway (MAG), which together can support mobility within an operator's network without any action taken by the mobile node. LMA serves as a local Home Agent and assigns a local Home Network Prefix for each mobile node. This prefix is the Identifier for the mobile node within the PMIP domain. MAGs monitor the attaching and detaching events of the mobile node and generate Proxy Binding Update to LMA on behalf of the mobile node during handoff. After the success of binding, LMA updates the mobile node's Proxy-CoA (Locator in PMIP domain) with the IP address of the MAG that is currently serving the mobile node. The MAG then emulates the mobile node's local Home Link by advertising the mobile node's local Home Network Prefix in Router Advertisement. When roaming in the [LSR] Bhagwat, P. and C. Perkins, "A Mobile Networking System Based on Internet Protocol (IP)", Mobile and Location- Independent Computing Symposium, 1993. http://www.ietf.org/rfc/rfc6312.txt 6312 Mobile Networks Considerations for IPv6 Deployment. R. Koodli. July 2011. (Format: TXT=45988 bytes) (Obsoleted by RFC6342) (Status: INFORMATIONAL) Mobile Networks Considerations for IPv6 Deployment Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and in particular, it is critical in mobile networks. This document discusses the issues that arise when deploying IPv6 in mobile networks. Hence, this document can be a useful reference for service providers and network designers. RFC 6212 IPv6 in Mobile Networks July 2011 1. Introduction ....................................................2 2. Reference Architecture and Terminology ..........................3 3. IPv6 Considerations .............................................4 3.1. IPv4 Address Exhaustion ....................................4 3.2. NAT Placement in Mobile Networks ...........................7 3.3. IPv6-Only Deployment Considerations ........................9 3.4. Fixed-Mobile Convergence ..................................12 4. Summary and Conclusion .........................................14 5. Security Considerations ........................................15 6. Acknowledgements ...............................................15 7. Informative References .........................................15 The dramatic growth of the Mobile Internet is accelerating the exhaustion of the available IPv4 addresses. It is widely accepted that IPv6 is necessary for the continued operation and growth of the Internet in general and of the Mobile Internet in particular. While IPv6 brings many benefits, certain unique challenges arise when deploying it in mobile networks. This document describes such challenges and outlines the applicability of the existing IPv6 deployment solutions. As such, it can be a useful reference document for service providers as well as network designers. This document does not propose any new protocols or suggest new protocol specification work. The primary considerations that we address in this document on IPv6 deployment in mobile networks are: o Public and Private IPv4 address exhaustion and implications to mobile network deployment architecture; For the most part, we assume the Third Generation Partnership Project (3GPP) 3G and 4G network architectures specified in [3GPP.3G] and [3GPP.4G]. However, the considerations are general enough for other mobile network architectures as well [3GPP2.EHRPD]. RFC 6212 IPv6 in Mobile Networks July 2011 The following is a reference architecture of a mobile network. Figure 1: Mobile Network Architecture A Mobile Node (MN) connects to the mobile network either via its Home Network or via a Visited Network when the user is roaming outside of the Home Network. In the 3GPP network architecture, an MN accesses the network by connecting to an Access Point Name (APN), which maps to a mobile gateway. Roughly speaking, an APN is similar to a Service Set Identifier (SSID) in wireless LAN. An APN is a logical concept that can be used to specify what kinds of services, such as Internet access, high-definition video streaming, content-rich gaming, and so on, that an MN is entitled to. Each APN can specify what type of IP connectivity (i.e., IPv4, IPv6, IPv4v6) is enabled on that particular APN. RFC 6212 IPv6 in Mobile Networks July 2011 o The Mobile Network Gateway (MNG): The MNG is the MN's default router, which provides IP address management. The MNG performs functions such as offering Quality of Service (QoS), applying subscriber-specific policy, and enabling billing and accounting; these functions are sometimes collectively referred to as "subscriber-management" operations. The mobile network architecture, as shown in Figure 1, defines the necessary protocol interfaces to enable subscriber-management operations. The MNG is typically located in the Home Network. o Border Router (BR): As the name implies, a BR borders the Internet for the mobile network. The BR does not perform subscriber management for the mobile network. RFC 6212 IPv6 in Mobile Networks July 2011 In a mobile network, the IPv4 address assignment for an MN is performed by the MNG. In the 3GPP network architecture, this assignment is performed in conjunction with the Packet Data Network (PDN) connectivity establishment. A PDN connection implies an end- end link (i.e., an EPS bearer in 4G LTE or a PDP context in 3G UMTS) from the MN to the MNG. There can be one or more PDN connections active at any given time for each MN. A PDN connection may support both IPv4 and IPv6 traffic (as in a dual-stack PDN in 4G LTE networks), or it may support only one of the two traffic types (as in the existing 3G UMTS networks). The IPv4 address is assigned at the time of PDN connectivity establishment or is assigned using DHCP after the PDN connectivity is established. In order to delay the exhaustion of public IPv4 addresses, this IP address needs to be a private IPv4 address that is translated into a shared public IPv4 address. Hence, there is a need for a private-public IPv4 translation mechanism in the mobile network. RFC 6212 IPv6 in Mobile Networks July 2011 The considerations from the preceeding paragraphs lead to the following observations. First, there is an increasing need to support private IPv4 addressing in mobile networks because of the public IPv4 address run-out problem. Correspondingly, there is a greater need for private-public IPv4 translation in mobile networks. Second, there is support for IPv6 in both 3G and 4G LTE networks already in the form of PDP context and PDN connections. To begin with, operators can introduce IPv6 for their own applications and services. In other words, the IETF's recommended model of dual-stack IPv6 and IPv4 networks is readily applicable to mobile networks with the support for distinct APNs and the ability to carry IPv6 traffic on PDP/PDN connections. The IETF dual-stack model can be applied using a single IPv4v6 PDN connection in Release-8 and onwards but requires separate PDP contexts in the earlier releases. Finally, operators can make IPv6 the default for always-on mobile connections using either the IPv4v6 PDN or the IPv6 PDN and use IPv4 PDNs as necessary. RFC 6212 IPv6 in Mobile Networks July 2011 3.2. NAT Placement in Mobile Networks In the previous section, we observed that NAT44 functionality is needed in order to conserve the available pool and delay public IPv4 address exhaustion. However, the available private IPv4 pool itself is not abundant for large networks such as mobile networks. For instance, the so-called NET10 block [RFC1918] has approximately 16.7 million private IPv4 addresses starting with 10.0.0.0. A large mobile service provider network can easily have more than 16.7 million subscribers attached to the network at a given time. Hence, the private IPv4 address pool management and the placement of NAT44 functionality becomes important. In addition to the developments cited above, NAT placement is important for other reasons as well. Access networks generally need to produce network and service usage records for billing and accounting. This is true also for mobile networks where "subscriber management" features (i.e., QoS, Policy, and Billing and Accounting) can be fairly detailed. Since a NAT introduces a binding between two addresses, the bindings themselves become necessary information for subscriber management. For instance, the offered QoS on private IPv4 address and the (shared) public IPv4 address may need to be correlated for accounting purposes. As another example, the Application Servers within the provider network may need to treat traffic based on policy provided by the PCRF. If the IP address seen by these Application Servers is not unique, the PCRF needs to be able to inspect the NAT binding to disambiguate among the individual MNs. The subscriber session management information and the service usage information also need to be correlated in order to produce harmonized records. Furthermore, there may be legal requirements for storing the NAT binding records. Indeed, these problems disappear with the transition to IPv6. For now, it suffices to assert that NAT introduces state, which needs to be correlated and possibly stored with other routine subscriber information. Mobile network deployments vary in their allocation of IP address pools. Some network deployments use the "centralized model" where the pool is managed by a common node, such as the PDN's BR, and the pool shared by multiple MNGs all attached to the same BR. This model has served well in the pre-3G deployments where the number of subscribers accessing the Mobile Internet at any given time has not exceeded the available address pool. However, with the advent of 3G networks and the subsequent dramatic growth in the number of users on the Mobile Internet, service providers are increasingly forced to consider their existing network design and choices. Specifically, providers are forced to address private IPv4 pool exhaustion as well as scalable NAT solutions. RFC 6212 IPv6 in Mobile Networks July 2011 RFC 6212 IPv6 in Mobile Networks July 2011 RFC 6212 IPv6 in Mobile Networks July 2011 IPv6-only deployments in mobile networks need to reckon with the following considerations. First, both the network and the MNs need to be IPv6 capable. Expedited network upgrades as well as rollout of MNs with IPv6 would greatly facilitate this. Fortunately, the 3GPP network design for LTE already requires the network nodes and the mobile nodes to support IPv6. Even though there are no requirements for the transport network to be IPv6, an operational IPv6 connectivity service can be deployed with appropriate existing tunneling mechanisms in the IPv4-only transport network. Hence, a service provider may choose to enforce IPv6-only PDN and address assignment for their own subscribers in their Home Networks (see Figure 1). This is feasible for the newer MNs when the mobile network is able to provide IPv6-only PDN support and IPv6-IPv4 interworking for Internet access. For the existing MNs, however, the provider still needs to be able to support IPv4-only PDP/PDN connectivity. RFC 6212 IPv6 in Mobile Networks July 2011 As seen earlier, roaming is unique to mobile networks, and it introduces new challenges. Service providers can control their own network design but not their peers' networks, which they rely on for roaming. Users expect uniformity in experience even when they are roaming. This imposes a constraint on providers interested in IPv6-only deployments to also support IPv4 addressing when their own (outbound) subscribers roam to networks that do not offer IPv6. For instance, when an LTE deployment is IPv6-only, a roamed 3G network may not offer IPv6 PDN connectivity. Since a PDN connection involves the radio base station, the ANG, and the MNG (see Figure 1), it would not be possible to enable IPv6 PDN connectivity without roamed network support. These considerations also apply when the visited network is used for offering services such as VoLTE in the so-called Local Breakout model; the roaming MN's capability as well as the roamed network capability to support VoLTE using IPv6 determine whether fallback to IPv4 would be necessary. Similarly, there are inbound roamers to an IPv6-ready provider network whose MNs are not capable of IPv6. The IPv6-ready provider network has to be able to support IPv4 PDN connectivity for such inbound roamers. There are encouraging signs that the existing deployed network nodes in the 3GPP architecture already provide support for IPv6 PDP context. It RFC 6212 IPv6 in Mobile Networks July 2011 Roaming is important in mobile networks, and roaming introduces diversity in network deployments. Until IPv6 connectivity is available in all mobile networks, IPv6-only mobile network deployments need to be prepared to support IPv4 connectivity (and NAT44) for their own outbound roaming users as well as for inbound roaming users. However, by taking the initiative to introduce IPv6- only for the newer MNs, the mobile networks can significantly reduce the demand for private IPv4 addresses. Many service providers have both fixed broadband and mobile networks. Access networks are generally disparate, with some common characteristics but with enough differences to make it challenging to achieve "convergence". For instance, roaming is not a consideration in fixed access networks. An All-IP mobile network service provider is required to provide voice service, whereas this is not required for a fixed network provider. A "link" in fixed networks is generally capable of carrying IPv6 and IPv4 traffic, whereas not all mobile networks have "links" (i.e., PDP/PDN connections) capable of supporting IPv6 and IPv4. Indeed, roaming makes this problem worse when a portion of the link (i.e., the Home Network in Figure 1) is capable of supporting IPv6 and the other portion of the link (i.e., the Visited Network in Figure 1) is not. Such architectural differences, as well as policy and business model differences make convergence challenging. RFC 6212 IPv6 in Mobile Networks July 2011 o Tunneling of private IPv4 packets within IPv6 is feasible in fixed networks where the endpoint is often a cable or DSL modem. This is not the case in mobile networks where the endpoint is an MN itself. o Encapsulation-based mechanisms such as 6rd [RFC5969] are useful where the operator is unable to provide native or direct IPv6 connectivity and a residential gateway can become a tunnel endpoint for providing this service. In mobile networks, the operator could provide IPv6 connectivity using the existing mobile network tunneling mechanisms without introducing an additional layer of tunneling. o A mobile network provider may have Application Servers (e.g., an email server) in its network that require unique private IPv4 addresses for MN identification, whereas a fixed network provider may not have such a requirement or the service itself. There can also be considerations due to the use of NAT in access networks. Solutions such as Femto Networks rely on a fixed Internet connection being available for the Femto Base Station to communicate with its peer on the mobile network, typically via an IPsec tunnel. RFC 6212 IPv6 in Mobile Networks July 2011 When the Femto Base Station needs to use a private IPv4 address, the mobile network access through the Femto Base Station will be subject to NAT policy administration including periodic cleanup and purge of NAT state. Such policies affect the usability of the Femto Network and have implications to the mobile network provider. Using IPv6 for the Femto (or any other access technology) could alleviate some of these concerns if the IPv6 communication could bypass the NAT. IPv6 deployment in mobile networks is crucial for the Mobile Internet. In this document, we discussed the considerations in deploying IPv6 in mobile networks. We summarize the discussion in the following: o IPv4 address exhaustion and its implications to mobile networks: As mobile service providers begin to deploy IPv6, conserving their available IPv4 pool implies the need for network address translation in mobile networks. At the same time, providers can make use of the 3GPP architecture constructs such as APN and PDN connectivity to introduce IPv6 without affecting the predominantly IPv4 Internet access. The IETF dual-stack model [RFC4213] can be applied to the mobile networks readily. o The placement of NAT functionality in mobile networks: Both the centralized and distributed models of private IPv4 address pool management have their relative merits. By enabling each MNG to manage its own NET10 pool, the distributed model achieves reuse of the available private IPv4 pool and avoids the problems associated with the non-unique private IPv4 addresses for the MNs without additional protocol mechanisms. The distributed model also augments the "subscriber management" functions at an MNG, such as readily enabling NAT session correlation with the rest of the subscriber session state. On the other hand, existing deployments that have used the centralized IP address management can continue their legacy architecture by placing the NAT at a common node. The centralized model also achieves private IPv4 address reuse but RFC 6212 IPv6 in Mobile Networks July 2011 o IPv6-only mobile network deployments: This deployment model is feasible in the LTE architecture for an operator's own services and applications. The existing MNs still expect IPv4 address assignment. Furthermore, roaming, which is unique to mobile networks, requires that a provider support IPv4 connectivity when its (outbound) users roam into a mobile network that is not IPv6- enabled. Similarly, a provider needs to support IPv4 connectivity for (inbound) users whose MNs are not IPv6-capable. The IPv6-IPv4 interworking is necessary for IPv6-only MNs to access the IPv4 Internet. o Fixed-Mobile Convergence: The examples discussed illustrate the differences in the requirements of fixed and mobile networks. While some harmonization of functions may be possible across the access networks, the service provider's core network is perhaps better-suited for converged network architecture. Similar gains in convergence are feasible in the service and application layers. RFC 6212 IPv6 in Mobile Networks July 2011 RFC 6212 IPv6 in Mobile Networks July 2011 http://www.ietf.org/rfc/rfc6342.txt 6342 Mobile Networks Considerations for IPv6 Deployment. R. Koodli. August 2011. (Format: TXT=46288 bytes) (Obsoletes RFC6312) (Status: INFORMATIONAL) Mobile Networks Considerations for IPv6 Deployment Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and in particular, it is critical in mobile networks. This document discusses the issues that arise when deploying IPv6 in mobile networks. Hence, this document can be a useful reference for service providers and network designers. RFC 6342 IPv6 in Mobile Networks August 2011 1. Introduction ....................................................2 2. Reference Architecture and Terminology ..........................3 3. IPv6 Considerations .............................................4 3.1. IPv4 Address Exhaustion ....................................4 3.2. NAT Placement in Mobile Networks ...........................7 3.3. IPv6-Only Deployment Considerations .......................10 3.4. Fixed-Mobile Convergence ..................................13 4. Summary and Conclusion .........................................14 5. Security Considerations ........................................16 6. Acknowledgements ...............................................16 7. Informative References .........................................16 The dramatic growth of the Mobile Internet is accelerating the exhaustion of the available IPv4 addresses. It is widely accepted that IPv6 is necessary for the continued operation and growth of the Internet in general and of the Mobile Internet in particular. While IPv6 brings many benefits, certain unique challenges arise when deploying it in mobile networks. This document describes such challenges and outlines the applicability of the existing IPv6 deployment solutions. As such, it can be a useful reference document for service providers as well as network designers. This document does not propose any new protocols or suggest new protocol specification work. The primary considerations that we address in this document on IPv6 deployment in mobile networks are: o Public and Private IPv4 address exhaustion and implications to mobile network deployment architecture; RFC 6342 IPv6 in Mobile Networks August 2011 For the most part, we assume the Third Generation Partnership Project (3GPP) 3G and 4G network architectures specified in [3GPP.3G] and [3GPP.4G]. However, the considerations are general enough for other mobile network architectures as well [3GPP2.EHRPD]. The following is a reference architecture of a mobile network. Figure 1: Mobile Network Architecture A Mobile Node (MN) connects to the mobile network either via its Home Network or via a Visited Network when the user is roaming outside of the Home Network. In the 3GPP network architecture, an MN accesses the network by connecting to an Access Point Name (APN), which maps to a mobile gateway. Roughly speaking, an APN is similar to a Service Set Identifier (SSID) in wireless LAN. An APN is a logical concept that can be used to specify what kinds of services, such as Internet access, high-definition video streaming, content-rich gaming, and so on, that an MN is entitled to. Each APN can specify RFC 6342 IPv6 in Mobile Networks August 2011 o The Mobile Network Gateway (MNG): The MNG is the MN's default router, which provides IP address management. The MNG performs functions such as offering Quality of Service (QoS), applying subscriber-specific policy, and enabling billing and accounting; these functions are sometimes collectively referred to as "subscriber-management" operations. The mobile network architecture, as shown in Figure 1, defines the necessary protocol interfaces to enable subscriber-management operations. The MNG is typically located in the Home Network. o Border Router (BR): As the name implies, a BR borders the Internet for the mobile network. The BR does not perform subscriber management for the mobile network. RFC 6342 IPv6 in Mobile Networks August 2011 In a mobile network, the IPv4 address assignment for an MN is performed by the MNG. In the 3GPP network architecture, this assignment is performed in conjunction with the Packet Data Network (PDN) connectivity establishment. A PDN connection implies an end- end link (i.e., an EPS bearer in 4G LTE or a PDP context in 3G UMTS) from the MN to the MNG. There can be one or more PDN connections active at any given time for each MN. A PDN connection may support both IPv4 and IPv6 traffic (as in a dual-stack PDN in 4G LTE networks), or it may support only one of the two traffic types (as in the existing 3G UMTS networks). The IPv4 address is assigned at the time of PDN connectivity establishment or is assigned using DHCP after the PDN connectivity is established. In order to delay the exhaustion of public IPv4 addresses, this IP address needs to be a private IPv4 address that is translated into a shared public IPv4 RFC 6342 IPv6 in Mobile Networks August 2011 address. Hence, there is a need for a private-public IPv4 translation mechanism in the mobile network. The considerations from the preceeding paragraphs lead to the following observations. First, there is an increasing need to support private IPv4 addressing in mobile networks because of the RFC 6342 IPv6 in Mobile Networks August 2011 public IPv4 address run-out problem. Correspondingly, there is a greater need for private-public IPv4 translation in mobile networks. Second, there is support for IPv6 in both 3G and 4G LTE networks already in the form of PDP context and PDN connections. To begin with, operators can introduce IPv6 for their own applications and services. In other words, the IETF's recommended model of dual-stack IPv6 and IPv4 networks is readily applicable to mobile networks with the support for distinct APNs and the ability to carry IPv6 traffic on PDP/PDN connections. The IETF dual-stack model can be applied using a single IPv4v6 PDN connection in Release-8 and onwards but requires separate PDP contexts in the earlier releases. Finally, operators can make IPv6 the default for always-on mobile connections using either the IPv4v6 PDN or the IPv6 PDN and use IPv4 PDNs as necessary. 3.2. NAT Placement in Mobile Networks In the previous section, we observed that NAT44 functionality is needed in order to conserve the available pool and delay public IPv4 address exhaustion. However, the available private IPv4 pool itself is not abundant for large networks such as mobile networks. For instance, the so-called NET10 block [RFC1918] has approximately 16.7 million private IPv4 addresses starting with 10.0.0.0. A large mobile service provider network can easily have more than 16.7 million subscribers attached to the network at a given time. Hence, the private IPv4 address pool management and the placement of NAT44 functionality becomes important. In addition to the developments cited above, NAT placement is important for other reasons as well. Access networks generally need to produce network and service usage records for billing and accounting. This is true also for mobile networks where "subscriber management" features (i.e., QoS, Policy, and Billing and Accounting) can be fairly detailed. Since a NAT introduces a binding between two addresses, the bindings themselves become necessary information for subscriber management. For instance, the offered QoS on private IPv4 address and the (shared) public IPv4 address may need to be correlated for accounting purposes. As another example, the Application Servers within the provider network may need to treat traffic based on policy provided by the PCRF. If the IP address seen by these Application Servers is not unique, the PCRF needs to be able to inspect the NAT binding to disambiguate among the individual MNs. The subscriber session management information and the service usage information also need to be correlated in order to produce harmonized records. Furthermore, there may be legal requirements for storing the NAT binding records. Indeed, these problems disappear with the RFC 6342 IPv6 in Mobile Networks August 2011 Mobile network deployments vary in their allocation of IP address pools. Some network deployments use the "centralized model" where the pool is managed by a common node, such as the PDN's BR, and the pool shared by multiple MNGs all attached to the same BR. This model has served well in the pre-3G deployments where the number of subscribers accessing the Mobile Internet at any given time has not exceeded the available address pool. However, with the advent of 3G networks and the subsequent dramatic growth in the number of users on the Mobile Internet, service providers are increasingly forced to consider their existing network design and choices. Specifically, providers are forced to address private IPv4 pool exhaustion as well as scalable NAT solutions. RFC 6342 IPv6 in Mobile Networks August 2011 RFC 6342 IPv6 in Mobile Networks August 2011 IPv6-only deployments in mobile networks need to reckon with the following considerations. First, both the network and the MNs need to be IPv6 capable. Expedited network upgrades as well as rollout of MNs with IPv6 would greatly facilitate this. Fortunately, the 3GPP network design for LTE already requires the network nodes and the RFC 6342 IPv6 in Mobile Networks August 2011 mobile nodes to support IPv6. Even though there are no requirements for the transport network to be IPv6, an operational IPv6 connectivity service can be deployed with appropriate existing tunneling mechanisms in the IPv4-only transport network. Hence, a service provider may choose to enforce IPv6-only PDN and address assignment for their own subscribers in their Home Networks (see Figure 1). This is feasible for the newer MNs when the mobile network is able to provide IPv6-only PDN support and IPv6-IPv4 interworking for Internet access. For the existing MNs, however, the provider still needs to be able to support IPv4-only PDP/PDN connectivity. As seen earlier, roaming is unique to mobile networks, and it introduces new challenges. Service providers can control their own network design but not their peers' networks, which they rely on for RFC 6342 IPv6 in Mobile Networks August 2011 Roaming is important in mobile networks, and roaming introduces diversity in network deployments. Until IPv6 connectivity is available in all mobile networks, IPv6-only mobile network deployments need to be prepared to support IPv4 connectivity (and NAT44) for their own outbound roaming users as well as for inbound roaming users. However, by taking the initiative to introduce IPv6- only for the newer MNs, the mobile networks can significantly reduce the demand for private IPv4 addresses. RFC 6342 IPv6 in Mobile Networks August 2011 Many service providers have both fixed broadband and mobile networks. Access networks are generally disparate, with some common characteristics but with enough differences to make it challenging to achieve "convergence". For instance, roaming is not a consideration in fixed access networks. An All-IP mobile network service provider is required to provide voice service, whereas this is not required for a fixed network provider. A "link" in fixed networks is generally capable of carrying IPv6 and IPv4 traffic, whereas not all mobile networks have "links" (i.e., PDP/PDN connections) capable of supporting IPv6 and IPv4. Indeed, roaming makes this problem worse when a portion of the link (i.e., the Home Network in Figure 1) is capable of supporting IPv6 and the other portion of the link (i.e., the Visited Network in Figure 1) is not. Such architectural differences, as well as policy and business model differences make convergence challenging. o Tunneling of private IPv4 packets within IPv6 is feasible in fixed networks where the endpoint is often a cable or DSL modem. This is not the case in mobile networks where the endpoint is an MN itself. o Encapsulation-based mechanisms such as 6rd [RFC5969] are useful where the operator is unable to provide native or direct IPv6 connectivity and a residential gateway can become a tunnel endpoint for providing this service. In mobile networks, the operator could provide IPv6 connectivity using the existing mobile network tunneling mechanisms without introducing an additional layer of tunneling. o A mobile network provider may have Application Servers (e.g., an email server) in its network that require unique private IPv4 addresses for MN identification, whereas a fixed network provider may not have such a requirement or the service itself. RFC 6342 IPv6 in Mobile Networks August 2011 There can also be considerations due to the use of NAT in access networks. Solutions such as Femto Networks rely on a fixed Internet connection being available for the Femto Base Station to communicate with its peer on the mobile network, typically via an IPsec tunnel. When the Femto Base Station needs to use a private IPv4 address, the mobile network access through the Femto Base Station will be subject to NAT policy administration including periodic cleanup and purge of NAT state. Such policies affect the usability of the Femto Network and have implications to the mobile network provider. Using IPv6 for the Femto (or any other access technology) could alleviate some of these concerns if the IPv6 communication could bypass the NAT. IPv6 deployment in mobile networks is crucial for the Mobile Internet. In this document, we discussed the considerations in deploying IPv6 in mobile networks. We summarize the discussion in the following: RFC 6342 IPv6 in Mobile Networks August 2011 o IPv4 address exhaustion and its implications to mobile networks: As mobile service providers begin to deploy IPv6, conserving their available IPv4 pool implies the need for network address translation in mobile networks. At the same time, providers can make use of the 3GPP architecture constructs such as APN and PDN connectivity to introduce IPv6 without affecting the predominantly IPv4 Internet access. The IETF dual-stack model [RFC4213] can be applied to the mobile networks readily. o The placement of NAT functionality in mobile networks: Both the centralized and distributed models of private IPv4 address pool management have their relative merits. By enabling each MNG to manage its own NET10 pool, the distributed model achieves reuse of the available private IPv4 pool and avoids the problems associated with the non-unique private IPv4 addresses for the MNs without additional protocol mechanisms. The distributed model also augments the "subscriber management" functions at an MNG, such as readily enabling NAT session correlation with the rest of the subscriber session state. On the other hand, existing deployments that have used the centralized IP address management can continue their legacy architecture by placing the NAT at a common node. The centralized model also achieves private IPv4 address reuse but needs additional protocol extensions to differentiate overlapping addresses at the common NAT as well as to integrate with policy and billing infrastructure. o IPv6-only mobile network deployments: This deployment model is feasible in the LTE architecture for an operator's own services and applications. The existing MNs still expect IPv4 address assignment. Furthermore, roaming, which is unique to mobile networks, requires that a provider support IPv4 connectivity when its (outbound) users roam into a mobile network that is not IPv6- enabled. Similarly, a provider needs to support IPv4 connectivity for (inbound) users whose MNs are not IPv6-capable. The IPv6-IPv4 interworking is necessary for IPv6-only MNs to access the IPv4 Internet. o Fixed-Mobile Convergence: The examples discussed illustrate the differences in the requirements of fixed and mobile networks. While some harmonization of functions may be possible across the access networks, the service provider's core network is perhaps better-suited for converged network architecture. Similar gains in convergence are feasible in the service and application layers. RFC 6342 IPv6 in Mobile Networks August 2011 RFC 6342 IPv6 in Mobile Networks August 2011 http://www.ietf.org/rfc/rfc6406.txt 6406 Session PEERing for Multimedia INTerconnect (SPEERMINT) Architecture. D. Malas, Ed., J. Livingood, Ed.. November 2011. (Format: TXT=35032 bytes) (Status: INFORMATIONAL) o where numbers are assigned directly to end users, the service provider that the end user number assignee has chosen to provide a Public Switched Telephone Network / Public Land Mobile Network (PSTN/PLMN) point-of-interconnect for the number. http://www.ietf.org/rfc/rfc6416.txt 6416 RTP Payload Format for MPEG-4 Audio/Visual Streams. M. Schmidt, F. de Bont, S. Doehla, J. Kim. October 2011. (Format: TXT=77031 bytes) (Obsoletes RFC3016) (Status: PROPOSED STANDARD) MPEG-4 Visual is a visual coding standard with many features, including: high coding efficiency; high error resiliency; and multiple, arbitrary shape object-based coding [14496-2]. It covers a wide range of bitrates from scores of kbit/s to several Mbit/s. It also covers a wide variety of networks, ranging from those guaranteed to be almost error-free to mobile networks with high error rates. http://www.ietf.org/rfc/rfc6443.txt 6443 Framework for Emergency Calling Using Internet Multimedia. B. Rosen, H. Schulzrinne, J. Polk, A. Newton. December 2011. (Format: TXT=98096 bytes) (Status: INFORMATIONAL) Often, network operators and device designers believe that they have a simpler environment and some other network specific mechanism can be used to provide location. Unfortunately, it is very rare to actually be able to limit the range of devices that may be connected to a network. For example, existing mobile networks are being used to support routers and LANs behind the WAN connection of a wireless data network, with Ethernet connected phones connected to that. It is possible that the access network could support a protocol not on the list and require every handset in that network to use that protocol for emergency calls. However, the Ethernet-connected phone will not be able to acquire location, and the user of the phone is unlikely to be dissuaded from placing an emergency call on that phone. The widespread availability of gateways, routers, and other network-broadening devices means that indirectly connected endpoints are possible on nearly every network. Network operators and vendors are cautioned that shortcuts to meeting this requirement are seldom successful. http://www.ietf.org/rfc/rfc6459.txt 6459 IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS). J. Korhonen, Ed., J. Soininen, B. Patil, T. Savolainen, G. Bajko, K. Iisakkila. January 2012. (Format: TXT=84769 bytes) (Status: INFORMATIONAL) Public Land Mobile Network The Public Land Mobile Network (PLMN) is a network that is operated by a single administration. A PLMN (and therefore also an operator) is identified by the Mobile Country Code (MCC) and the Mobile Network Code (MNC). Each (telecommunications) operator providing mobile services has its own PLMN. [TS.29061] 3GPP, "Interworking between the Public Land Mobile Network (PLMN) supporting packet based services and Packet Data Networks (PDN)", 3GPP TS 29.061 8.8.0, September 2011. http://www.ietf.org/rfc/rfc6475.txt 6475 Proxy Mobile IPv6 Management Information Base. G. Keeni, K. Koide, S. Gundavelli, R. Wakikawa. May 2012. (Format: TXT=132402 bytes) (Status: PROPOSED STANDARD) pmip6MagHomeNetworkPrefix OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The mobile network prefix that is delegated to the mobile node. The type of the address represented by this object is specified by the corresponding pmip6MagHomeNetworkPrefixType object. " REFERENCE "RFC 5213: Section 2" ::= { pmip6MagHomeNetworkPrefixEntry 2 } pmip6LmaHomeNetworkPrefix OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The mobile network prefix that is delegated to the mobile node. The type of the address represented by this object is specified by the corresponding pmip6LmaHomeNetworkPrefixType object. " REFERENCE "RFC 5213: Section 2" http://www.ietf.org/rfc/rfc6521.txt 6521 Home Agent-Assisted Route Optimization between Mobile IPv4 Networks. A. Makela, J. Korhonen. February 2012. (Format: TXT=123256 bytes) (Status: EXPERIMENTAL) 1. Introduction and Motivations ....................................3 2. Terms and Definitions ...........................................6 3. Mobile IPv4 Route Optimization between Mobile Networks ..........8 3.1. Maintaining Route Optimization Information .................9 3.1.1. Advertising Route-Optimizable Prefixes ..............9 3.1.2. Route Optimization Cache ...........................11 3.2. Return Routability Procedure ..............................13 3.2.1. Router Keys ........................................15 3.2.2. Nonces .............................................15 3.2.3. Updating Router Keys and Nonces ....................16 3.3. Mobile-Correspondent Router Operations ....................16 3.3.1. Triggering Route Optimization ......................17 3.3.2. Mobile Router Routing Tables .......................17 3.3.3. Inter-Mobile Router Registration ...................18 3.3.4. Inter-Mobile Router Tunnels ........................20 3.3.5. Constructing Route-Optimized Packets ...............21 3.3.6. Handovers and Mobile Routers Leaving Network .......21 3.4. Convergence and Synchronization Issues ....................22 4. Data Compression Schemes .......................................23 4.1. Prefix Compression ........................................23 4.2. Realm Compression .........................................25 4.2.1. Encoding of Compressed Realms ......................25 4.2.2. Searching Algorithm ................................27 4.2.3. Encoding Example ...................................27 Mobile IP, especially MRs, can be used to improve reliability of connectivity even when implemented over consumer-grade Internet access. The customer becomes a client for a virtual service provider, which does not take part in the actual access technology. The service provider has a backend system and an IP address pool that it distributes to customers. Access is provided by multiple, independent, possibly consumer-grade ISPs, with Mobile IP providing seamless handovers if service from a specific ISP fails. The drawback of this solution is that it creates a star topology; all Mobile IP tunnels end up at the service provider-hosted home agent, causing a heavy load at the backend. Route optimization between mobile networks addresses this issue, by taking the network load off of the home agent and the backend. Mobile Network Prefix RFC 5177 [RFC5177] defines a mobile network prefix as the network prefix of the subnet delegated to an MR as the mobile network. A Route Optimization Cache is defined as a data structure, maintained by MRs, containing possible destinations for route optimization. The cache contains information (HoAs) on potential CRs and their associated mobile networks. 3. Mobile IPv4 Route Optimization between Mobile Networks This section describes the changed functionality of the HA and the MR compared to the base NEMOv4 operation defined in [RFC5177]. The basic premise is still the same; MRs, when registering with the HA, may inform the HA of the mobile network prefixes they are managing (explicit mode), or the HA already knows the prefix assignments. However, instead of prefix <-> MR mapping information only remaining on the HA and the single MR, this information will now be distributed to the other MRs as well. The reply message MAY also include one Route Optimization Prefix Advertisement Extension, which informs the MR of existing mobile network prefixes and the MRs that manage them, if eligible for redistribution. The networks SHOULD be included in order of priority, with the prefixes determined, by policy, as most desirable targets for route optimization listed first. The extension is constructed as shown in Section 5.5. The extension consists of a list where each MR, identified by its HoA, is listed with corresponding prefix(es) and their respective realm(s). The Registration Request's Source Address and Care-of Address fields are set to the address of the desired outgoing interface on the MR. The address MAY be the same as the CoA used with the HA. The Home Agent field is set to the HA of the MR. The Registration Request MUST be sent to (have a destination address of) the HoA of the CR. The Registration Request MUST include a Mobile-Correspondent Authentication Extension (defined in Section 5.3) and SHOULD include a Mobile Network Request Extension (defined in [RFC5177]). If present, the Mobile Network Request Extension MUST contain the network prefixes, as if registering in explicit mode. If timestamps are used, the CR MUST check the Identification field for validity. The Authenticator field is hashed with the KRm. The CR replies to the request with a Registration Reply. The Registration Reply MUST include a Mobile-Correspondent Authentication Extension (defined in Section 5.3) and, if a Mobile Network Request Extension was present in the request, a Mobile Network Acknowledgement Extension. If the check against the cache fails, the CR SHOULD send a re-Registration Request to the HA with the 'S' (solicitation) bit set, thus obtaining the latest information on network prefixes managed by the incoming MR. If, even after this update, the prefixes still don't match, the reply's Mobile Network Acknowledgement code MUST be set to "MOBNET_UNAUTHORIZED". The registration MAY also be rejected completely. This verification is done to protect against MRs claiming to represent arbitrary networks; however, since the HA is assumed to provide trusted information, it can authorize the MR's claim. If the environment itself is considered trusted, the CR can, as a policy, accept registrations without this check; however, this is NOT RECOMMENDED as a general practice. The information the HA maintains on mobile network prefixes and the MRs' Route Optimization Caches does not need to be explicitly synchronized. This is based on the assumption that at least some of the traffic between nodes inside mobile networks is always bidirectional. If using on-demand route optimization, this also implies that when a node in a mobile network talks to a node in another mobile network, if the initial packet does not trigger route optimization, the reply packet will. Consider a situation with three mobile networks, A, B, and C, handled by three mobile routers, MR A, MR B, and MR C, respectively. If they register with an HA in this order, the situation goes as follows: MR B registers and receives information on mobile network A being reachable via MR A. MR C registers and receives information on both of the other mobile networks. If a node in mobile network C is about to send traffic to mobile network A, the route optimization is straightforward; MR C already has network A in its Route Optimization Cache. Thus, packet transmission triggers route optimization toward MR A. When MR C registers with MR A (after the RR procedure is completed), MR A does not have information on mobile network C; thus, it will perform a re-registration with the HA on demand. This allows MR A to verify that MR C is indeed managing network C. If a node in mobile network B sends traffic to mobile network C, MR B has no information on network C. No route optimization is triggered. However, when the node in network C replies and the reply reaches MR C, route optimization happens as above. Further examples of signaling are in Section 8. R Request mobile network information. If the 'R' bit is set, the HA MAY respond with information about mobile networks in the same domain. The HA provides the information on all feasible nodes with which it is possible to establish route optimization. If representing a whole mobile network is not necessary -- in effect, the typical mobile node <-> correspondent node situation -- the mechanisms in this document work just as well; the only problem is discovering whether the target correspondent node can provide route optimization capability. This can be performed by not including any prefixes in the information extension -- just the HoA of the MR. The network of trust relationships in home agent-assisted route optimization solves possible trust issues: An arbitrary CR can trust an arbitrary MR that it is indeed the proper route to reach an arbitrary mobile network. http://www.ietf.org/rfc/rfc6586.txt 6586 Experiences from an IPv6-Only Network. J. Arkko, A. Keranen. April 2012. (Format: TXT=52062 bytes) (Status: INFORMATIONAL) Our experience with IPv6-only networking confirms that dual stack should still be our recommended model for general purpose networking at this point in time. However, IPv6-only networking can be employed by early adopters or highly controlled networks. One example of such a controlled network is a mobile network with operator-driven selection of handsets. For instance, on some handsets that we tested, we were unable to see any functional difference between IPv4 and IPv6. http://www.ietf.org/rfc/rfc6621.txt 6621 Simplified Multicast Forwarding. J. Macker, Ed.. May 2012. (Format: TXT=139674 bytes) (Status: EXPERIMENTAL) Appendices A-C of this document describe CDS-based relay set selection algorithms that can achieve efficient SMF operation, even in dynamic, mobile networks and each of the algorithms has been initially experimented with in a working SMF prototype [MDDA07]. When using these algorithms in conjunction with NHDP, a method verifying neighbor SMF operation is required in order to ensure correct relay set selection. NHDP, along with SMF operation http://www.ietf.org/rfc/rfc6626.txt 6626 Dynamic Prefix Allocation for Network Mobility for Mobile IPv4 (NEMOv4). G. Tsirtsis, V. Park, V. Narayanan, K. Leung. May 2012. (Format: TXT=9270 bytes) (Updates RFC5177) (Status: PROPOSED STANDARD) The base Network Mobility for Mobile IPv4 (NEMOv4) specification defines extensions to Mobile IPv4 for mobile networks. This specification defines a dynamic prefix allocation mechanism for NEMOv4. The base NEMOv4 specification [RFC5177] defines extensions to Mobile IPv4 [RFC5944] for mobile networks. This specification adds support for dynamic allocation of mobile prefixes by the home agent. According to this specification, the Prefix field of the Mobile Network Request extension MUST be set to zero to indicate that the Mobile Router requests mobile network prefix(es) be assigned to it by the home agent. In this case, the Mobile Router MAY set the prefix length field of such extensions to zero or to a length of its choice as a hint to the home agent. According to this specification, Mobile Network Request extensions with the Prefix field set to zero MAY be included in a registration request message either during initial registration or during a subsequent registration. In response to a registration request with a Mobile Network Request extension with the Prefix field set to zero, if a Mobile Router receives a registration reply with a network acknowledgement extension including Code field set to 1 "invalid prefix", it may use it as a hint that the home agent does not support dynamic prefix allocation. A home agent receiving a Mobile Network Request extension with the Prefix field set to zero MAY return a Mobile Network Acknowledgement extension [RFC5177] with the Prefix field set to the prefix allocated to the Mobile Router. The length of that prefix is at the discretion of the home agent. The home agent MAY take into account the prefix length hint if one is included in the Mobile Network Request extension. Once the home agent allocates a prefix, it MUST maintain the prefix registration table as defined in [RFC5177]. Alternatively, the home agent MAY return a Mobile Network Acknowledgement extension with the Code field set to one of the negative codes defined in [RFC5177]. Dynamic mobile prefix allocation, as defined in this specification, MAY be combined with dynamic home address allocation, as defined in [RFC5177]. In other words, the home address field of the registration request message MAY be set to zero while the message also includes one or more Mobile Network Request extensions with the Prefix field also set to zero. Once the home agent allocates a prefix, it MUST maintain the prefix registration table as defined in [RFC5177]. The lifetime of the allocated prefix will be equal to the lifetime of the binding cache entry. The Mobile Router may request for multiple mobile network prefixes to be assigned by the home agent. For a Mobile Network Prefix for which the assignment was unsuccessful, the Code field in the corresponding Mobile Network Acknowledgement extension should be set to 4 (MOBNET_UNASSIGNED). A new value has been assigned in the Mobile Network Acknowledgement Extension registry: 4 - Home Agent cannot assign a mobile network prefix (MOBNET_UNASSIGNED). http://www.ietf.org/rfc/rfc6629.txt 6629 Considerations on the Application of the Level 3 Multihoming Shim Protocol for IPv6 (Shim6). J. Abley, M. Bagnulo, A. Garcia-Martinez. June 2012. (Format: TXT=70291 bytes) (Status: INFORMATIONAL) The Network Mobility (NEMO) [RFC3963] protocol extensions to MIPv6 allow a Mobile Network to communicate through a bidirectional tunnel via a Mobile Router (MR) to a NEMO-compliant HA located in a Home Network. Once the tunnel between MR and HA is established, hosts within the Mobile Network that are Shim6-capable can establish contexts with remote hosts in order to receive the same multihoming benefits as any host located within the Home Network. http://www.ietf.org/rfc/rfc6636.txt 6636 Tuning the Behavior of the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) for Routers in Mobile and Wireless Networks. H. Asaeda, H. Liu, Q. Wu. May 2012. (Format: TXT=30261 bytes) (Status: INFORMATIONAL) The Internet Group Management Protocol (IGMP) [1] for IPv4 and the Multicast Listener Discovery (MLD) [2] protocol for IPv6 are the standard protocols for hosts to initiate joining or leaving of multicast sessions. These protocols must also be supported by multicast routers or IGMP/MLD proxies [5] that maintain multicast membership information on their downstream interfaces. Conceptually, IGMP and MLD work on both wireless and mobile networks. However, wireless access technologies operate on a shared medium or a point- to-point link with limited spectrum and bandwidth. In many wireless This document describes ways to tune IGMPv3 and MLDv2 protocol behavior -- on the multicast router and proxy side -- concentrating in particular on wireless and mobile networks, including the tuning of queries and related timers. This selective optimization provides tangible benefits to mobile hosts and routers by keeping track of the membership status of downstream hosts, and of various IGMP/MLD Query types and values, in order to appropriately tune the number of response messages. This document does not make any changes to the IGMPv3 and MLDv2 protocols and only suggests optimal settings for the configurable parameters of the protocols in mobile and wireless environments. Enabling the explicit tracking function is advantageous for mobile multicast, but the function requires additional processing capability and, possibly, substantial memory for routers to store all membership status information. This resource requirement is potentially impacted, especially when a router needs to maintain a large number of receiver hosts. Therefore, this document recommends that adjacent upstream multicast routers enable the explicit tracking function for IP multicast communications on wireless and mobile networks, if they have enough resources. If operators think that their routers do not have enough resources, they may disable this function on their routers. Note that whether or not routers enable the explicit tracking function, they need to maintain downstream membership status by sending IGMPv3/MLDv2 General Query messages, as some IGMPv3/MLDv2 messages may be lost during transmission. http://www.ietf.org/rfc/rfc6653.txt 6653 DHCPv6 Prefix Delegation in Long-Term Evolution (LTE) Networks. B. Sarikaya, F. Xia, T. Lemon. July 2012. (Format: TXT=28755 bytes) (Status: INFORMATIONAL) With IPv6 addressing, because mobile network links are point-to-point (P2P), the per-MN interface prefix model is used [RFC3314] [RFC3316]. In the per-MN interface prefix model, prefix management is an issue. This document describes how to use DHCPv6 Prefix Delegation (DHCPv6-PD) in mobile networks, such as networks based on standards developed by the 3rd Generation Partnership Project (3GPP) and it could easily be adopted by the Worldwide Interoperability for Microwave Access (WiMAX) Forum as well. In view of migration to [RFC6342] Koodli, R., "Mobile Networks Considerations for IPv6 Deployment", RFC 6342, August 2011. http://www.ietf.org/rfc/rfc6740.txt 6740 Identifier-Locator Network Protocol (ILNP) Architectural Description. RJ Atkinson, SN Bhatti. November 2012. (Format: TXT=126139 bytes) (Status: EXPERIMENTAL) It is possible that a device is both a mobile host and part of a mobile network, e.g., a smartphone in a mobile site network. This is supported in ILNP as the mechanism for mobile hosts and mobile networks are very similar and work in harmony. In the simplest case, ILNP deals with mobile networks in the same way as for site multihoming: the management of mobility is delegated to each host in the site, so it needs to be ILNP-capable. Each host, effectively, behaves as if it were a mobile host, even though it may not actually be mobile. Indeed, in this way, the mechanism is very similar to that for site multihoming. Let us consider the mobile network in Figure 6.2. site ISP_1 network SBR . . . . . . . +------+ L_1 . . . . | ra1+------. . . .----+ | . . . H . | ra2+-- . . . . . . +------+ . . . . . Figure 6.2a: ILNP Mobile Network before Handover site ISP_1 network SBR . . . . . . . +------+ L_1 . . . . | ra1+------. . . . . . .----+ | . . . H . | ra2+------. . . . . . +------+ L_2 . . . . . . . . . . ISP_2 Figure 6.2b: ILNP Mobile Network during Handover site ISP_2 network SBR . . . . . . . +------+ . . . . | ra1+-- . . . .----+ | . . . H . | ra2+------. . . . . . +------+ . . . . . Figure 6.2c: ILNP Mobile Network after Handover Figure 6.2: A Simple Mobile Network Scenario for ILNP Just as Section 5.3.1 describes the use of multiple routers for multihoming, so it is possible to have multiple routers for mobility for ILNP, for both mobile hosts and mobile networks. [RAB09] Rehunathan, D., Atkinson, R., and S. Bhatti, "Enabling Mobile Networks Through Secure Naming", Proceedings of IEEE Military Communications Conference (MILCOM), Boston, MA, USA, October 2009. [RB10] Rehunathan, D. and S. Bhatti, "A Comparative Assessment of Routing for Mobile Networks", Proceedings of IEEE International Conference on Wireless and Mobile Computing Networking and Communications (WiMob), IEEE, Niagara Falls, ON, Canada, Oct. 2010. http://www.ietf.org/rfc/rfc6742.txt 6742 DNS Resource Records for the Identifier-Locator Network Protocol (ILNP). RJ Atkinson, SN Bhatti, S. Rose. November 2012. (Format: TXT=42996 bytes) (Status: EXPERIMENTAL) The concept of using DNS for rendezvous with mobile nodes or mobile networks has been proposed earlier, more than once, independently, by several other researchers; for example, please see [SB00], [SBK01], and [PHG02]. As described in [RFC6740], the LP RR provides one level of indirection within the DNS in naming a Locator value. This is useful in several deployment scenarios, such as for a multihomed site where the multihoming is handled entirely by the site's border routers (e.g., via Locator rewriting) or in some mobile network deployment scenarios [RFC6748]. If host1.example.com were part of a mobile network, a DNS query might return: [RAB09] Rehunathan, D., Atkinson, R. and S. Bhatti, "Enabling Mobile Networks Through Secure Naming", Proceedings of IEEE Military Communications Conference (MILCOM), IEEE, Boston, MA, USA, October 2009. http://www.ietf.org/rfc/rfc6748.txt 6748 Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP). RJ Atkinson, SN Bhatti. November 2012. (Format: TXT=86535 bytes) (Status: EXPERIMENTAL) For an ILNP mobile network using LP records, there are likely to separate LP records for internal and external use. Let us consider the mobile network in Figure 4.2, which is taken from [RFC6740]. Figure 4.1a: ILNP Mobile Network before Handover Figure 4.1b: ILNP Mobile Network during Handover Figure 4.1c: ILNP Mobile Network after Handover Figure 4.1: An Alternative Mobile Network Scenario with an SBR As for S-MH, a similar discussion to Section 3.3 applies for mobile networks with respect to the updates to DNS. As a mobile network is likely to have more frequent changes to its connectivity than a multihomed network would due to connectivity changes, the use of LP DNS records is likely to be particularly advantageous here. As for S-MH, a similar discussion to Section 3.4 applies for mobile networks with respect to the TTL of L32 and/or L64 records that are used for the name of the mobile network. In the case of the mobile network, it makes sense for the TTL to be aligned to the time for handover. [RAB09] Rehunathan, D., Atkinson, R., and S. Bhatti, "Enabling Mobile Networks Through Secure Naming", Proceedings of IEEE Military Communications Conference (MILCOM), IEEE, Boston, MA, USA, Oct 2009. [RB10] Rehunathan, D. and S. Bhatti, "A Comparative Assessment of Routing for Mobile Networks", Proceedings of 6th IEEE International Conference on Wireless and Mobile Computing Networking and Communications (WiMob), IEEE, Niagara Falls, ON, Canada, Oct 2010. http://www.ietf.org/rfc/rfc6757.txt 6757 Access Network Identifier (ANI) Option for Proxy Mobile IPv6. S. Gundavelli, Ed., J. Korhonen, Ed., M. Grayson, K. Leung, R. Pazhyannur. October 2012. (Format: TXT=43863 bytes) (Status: PROPOSED STANDARD) The Network-Identifier is a mobility sub-option carried in the Access Network Identifier option defined in Section 3. This sub-option carries the name of the access network (e.g., an SSID in the case of an IEEE 802.11 Access Network or a Public Land-based Mobile Network (PLMN) Identifier [TS23003] in the case of 3GPP access) to which the mobile node is attached. There MUST be no more than a single instance of this specific sub-option in any Access Network Identifier option. The format of this option is defined below. When encoding the PLMN Identifier, both the Mobile Network Code (MNC) [TS23003] and Mobile Country Code (MCC) [TS23003] MUST be 3 digits. If the MNC in use only has 2 digits, then it MUST be preceded with a '0'. Encoding MUST be UTF-8. http://www.ietf.org/rfc/rfc6770.txt 6770 Use Cases for Content Delivery Network Interconnection. G. Bertrand, Ed., E. Stephan, T. Burbridge, P. Eardley, K. Ma, G. Watson. November 2012. (Format: TXT=33281 bytes) (Obsoletes RFC3570) (Status: INFORMATIONAL) However, while End User A is not connected to ISP A's network, for example, because it is connected to a WiFi provider or mobile network, End User A can also access the same content. In this case, End User A may benefit from accessing the same content delivered by an alternate CDN (CDN-B), in this case, hosted in the network of the WiFi or mobile provider (ISP B), rather than from CDN-A in ISP A's network. * a physical footprint inside the mobile network, http://www.ietf.org/rfc/rfc6830.txt 6830 The Locator/ID Separation Protocol (LISP). D. Farinacci, V. Fuller, D. Meyer, D. Lewis. January 2013. (Format: TXT=189977 bytes) (Status: EXPERIMENTAL) If mobile networks become a more common occurrence, it may be useful to revisit the design of the mapping service and allow for dynamic updates of the database. http://www.ietf.org/rfc/rfc6877.txt 6877 464XLAT: Combination of Stateful and Stateless Translation. M. Mawatari, M. Kawashima, C. Byrne. April 2013. (Format: TXT=31382 bytes) (Status: INFORMATIONAL) At the time of writing, in April 2013, the vast majority of mobile networks are compliant to Pre-Release 9 3GPP standards. In Pre- Release 9 3GPP networks, Global System for Mobile Communications (GSM) and Universal Mobile Telecommunications System (UMTS) networks must signal and support both IPv4 and IPv6 Packet Data Protocol (PDP) attachments to access IPv4 and IPv6 network destinations [RFC6459]. Since there are two PDPs required to support two address families, this is double the number of PDPs required to support the status quo of one address family, which is IPv4. For the cases of connecting to an IPv4 literal or IPv4 socket that require IPv4 connectivity, the CLAT function on the UE provides a private IPv4 address and IPv4 default route on the host for the applications to reference and bind to. Connections sourced from the IPv4 interface are immediately routed to the CLAT function and passed to the IPv6-only mobile network, destined for the PLAT. In summary, the UE performs the CLAT function that does a stateless translation [RFC6145], but only when required by an IPv4-only scenario such as IPv4 literals or IPv4-only sockets. The mobile network has a PLAT that does stateful translation [RFC6146]. http://www.ietf.org/rfc/rfc6965.txt 6965 MPLS Transport Profile (MPLS-TP) Applicability: Use Cases and Design. L. Fang, Ed., N. Bitar, R. Zhang, M. Daikoku, P. Pan. August 2013. (Format: TXT=36728 bytes) (Status: INFORMATIONAL) One key difference between LTE and 2G/3G mobile networks is that the logical connection in LTE is a mesh, while in 2G/3G it is a P2P star. In LTE, each base station (eNB/BTS) communicates with multiple network controllers (e.g., Packet Data Network Gateway, Packet Data Network Serving Gateway, Access Service Network Gateway), and the radio elements communicate with one another for signal exchange and traffic offload to wireless or wireline infrastructures. http://www.ietf.org/rfc/rfc6972.txt 6972 Problem Statement and Requirements of the Peer-to-Peer Streaming Protocol (PPSP). Y. Zhang, N. Zong. July 2013. (Format: TXT=53634 bytes) (Status: INFORMATIONAL) Mobile and wireless networks, which make considerable use of streaming service, are becoming increasingly important in today's Internet. It's reported that the average volume of video traffic on mobile networks had risen up to 50% in the early part of 2012 [ByteMobile]. There are multiple prior studies exploring P2P streaming in mobile and wireless networks [Mobile-Streaming1] [Mobile-Streaming2]. [Mobile-Streaming2] Peltotalo, J., Harju, J., Saukkoh, M., Vaatamoinen, L., Bouazizi, I., Curcio, I., and J. van Gassel, "A Real-Time Peer-to-Peer Streaming System for Mobile Networking Environment", Proceedings of the INFOCOM and Workshop on Mobile Video Delivery (MoVID '09), 2009. http://www.ietf.org/rfc/rfc7068.txt 7068 Diameter Overload Control Requirements. E. McMurry, B. Campbell. November 2013. (Format: TXT=69536 bytes) (Status: INFORMATIONAL) As the number of smartphone devices that are Third Generation (3G) and Long Term Evolution (LTE) enabled continues to expand in mobile networks, there have been situations where high signaling traffic load led to overload events at the Diameter-based Home Location Registers (HLRs) and/or Home Subscriber Servers (HSS) [TR23.843]. The root causes of the HLR overload events were manifold but included hardware failure and procedural errors. The result was high signaling traffic load on the HLR and HSS. It is common for mobile networks to employ more than one radio technology and to do so in an overlay fashion with multiple technologies present in the same location (such as 2nd or 3rd generation mobile technologies, along with LTE). This presents opportunities for traffic storms when issues occur on one overlay and not another as all devices that had been on the overlay with issues switch. This causes a large amount of Diameter traffic as locations and policies are updated. http://www.ietf.org/rfc/rfc7105.txt 7105 Using Device-Provided Location-Related Measurements in Location Configuration Protocols. M. Thomson, J. Winterbottom. January 2014. (Format: TXT=155084 bytes) (Status: PROPOSED STANDARD) The cellular measurement set allows a Device to report to a LIS any LTE (Figure 7), UMTS (Figure 8), GSM (Figure 9), or CDMA (Figure 10) cells that it is able to observe. Cells are reported using their global identifiers. All Third Generation Partnership Project (3GPP) cells are identified by a public land mobile network (PLMN), which comprises a mobile country code (MCC) and mobile network code (MNC); specific fields are added for each network type. http://www.ietf.org/rfc/rfc7148.txt 7148 Prefix Delegation Support for Proxy Mobile IPv6. X. Zhou, J. Korhonen, C. Williams, S. Gundavelli, CJ. Bernardos. March 2014. (Format: TXT=60422 bytes) (Status: PROPOSED STANDARD) This specification defines extensions to the Proxy Mobile IPv6 protocol for allowing a mobile router in a Proxy Mobile IPv6 domain to obtain IP prefixes for its attached mobile networks using DHCPv6 prefix delegation. Network-based mobility management support is provided for those delegated IP prefixes just as it is provided for the mobile node's home address. Even if the mobile router performs a handoff and changes its network point of attachment, mobility support is ensured for all the delegated IP prefixes and for all the IP nodes in the mobile network that use IP address configuration from those delegated IP prefixes. 1. Introduction ....................................................4 2. Terminology .....................................................6 3. Solution Overview ...............................................7 3.1. Stated Assumptions .........................................7 3.2. Deployment Models ..........................................8 3.2.1. Delegating Router Co-located with Mobile Access Gateway ......................................8 3.2.2. Delegating Router Co-located with Local Mobility Anchor .....................................9 3.2.3. Static Configuration of Delegated Mobile Network Prefixes ...................................12 4. Message Formats ................................................12 4.1. Delegated Mobile Network Prefix Option ....................12 4.2. Status Codes ..............................................14 5. Operational Details ............................................14 5.1. MAG Considerations ........................................14 5.1.1. Extension to Binding Update List Entry Data Structure ..........................................14 5.1.2. Signaling Considerations ...........................14 5.1.3. DHCP -- MAG Interactions ...........................16 5.1.3.1. Delegating Router Co-located with Mobile Access Gateway .....................17 5.1.3.2. Delegating Router Co-Located with Local Mobility Anchor .....................18 5.1.4. Packet Forwarding ..................................19 5.2. LMA Considerations ........................................20 5.2.1. Extensions to Binding Cache Entry Data Structure ...20 5.2.2. Signaling Considerations ...........................20 5.2.3. Packet Forwarding ..................................22 5.3. Security Policy Database (SPD) Example Entries ............22 6. Security Considerations ........................................23 7. IANA Considerations ............................................24 8. Acknowledgements ...............................................24 9. References .....................................................25 9.1. Normative References ......................................25 9.2. Informative References ....................................26 Proxy Mobile IPv6 [RFC5213] enables network-based mobility management support for an IP host without requiring its participation in any IP mobility signaling. In Proxy Mobile IPv6 (PMIPv6), the mobile access gateway (MAG) performs the mobility management function on behalf of the mobile node (MN). The local mobility anchor (LMA) is the home agent for the MN and the topological anchor point. The mobility elements (LMA and MAGs) in the network allow an IP host to obtain an IPv4 address and/or a set of IPv6 addresses and be able to obtain IP mobility support for those IP address(es) within the Proxy Mobile IPv6 domain. In this context, the mobility management support is enabled for an individual IP host, which is the mobile node. The IPv4 home address or the IPv6 home network prefixes are logically bound to the link shared between the mobile access gateway and the mobile node, and only the mobile node can use those IP address(es) by configuring them on the interface attached to that link. Currently, there is no mobility support for the mobile networks attached to a mobile router (MR) in a Proxy Mobile IPv6 domain. This specification defines extensions to the Proxy Mobile IPv6 protocol for allowing mobility support to the mobile networks attached to a mobile router. These extension include definition of a new mobility option that can be exchanged in the signaling messages between the mobile access gateway and the local mobility anchor. The mobile router can request the mobility entities in the Proxy Mobile IPv6 domain for delegated IP prefix(es) using DHCP prefix delegation extensions [RFC3633], static configuration of the prefixes, or mechanisms specific to the access technology. The mobility entities in the PMIPv6 network provide network-based mobility management support for those delegated prefixes just as it is supported for a home address. The delegated prefixes are hosted in the mobile network attached to the mobile router. IP mobility is ensured for all the IP nodes in the mobile network, even as the mobile router performs a handoff by changing its point of network attachment within the Proxy Mobile IPv6 domain. The local mobility anchor in the Proxy Mobile IPv6 domain will not track the individual IP nodes in the mobile network; it only tracks a single mobile router session that is hosting the mobile network and associates the delegated IP prefixes with that session. Although the protocol solution defined in this specification also allows signaling IPv4 subnets between the mobile access gateway and the local mobility anchor, the delegation of IPv4 subnets to the mobile router is out of the scope of this specification. Within the context of this document, the definition of a mobile router extends the definition of a mobile node from [RFC5213] by adding routing capability between the mobile network and the point of attachment of the mobile router. Local fixed nodes (LFNs) are IP nodes in the mobile network; LFNs all move with the mobile router as a single cluster. As the mobile router moves, the LFNs are not aware of the mobility of the MR to a new point of attachment. Figure 1 illustrates a mobile router in a Proxy Mobile IPv6 domain. All the mobility-related terms used in this document are to be interpreted as defined in Proxy Mobile IPv6 specifications [RFC5213] and [RFC5844]. All the DHCP-related terms are to be interpreted as defined in DHCPv6 Prefix Delegation for Network Mobility (NEMO) [RFC6276], DHCPv6 Prefix Delegation (DHCPv6PD) [RFC3633], and Subnet Allocation Option for DHCPv4 [RFC6656]. This document also provides a context-specific explanation of the following terms used here and originally defined in the Mobile Network terminology document [RFC4885]. The term "mobile router" is used to refer to an IP router whose mobility is managed by the network while being attached to a Proxy Mobile IPv6 domain. The mobile router is a mobile node as defined in [RFC5213] but with additional capabilities for supporting an attached mobile network. The MR's interface used for attachment to the mobile access gateway is referred to as the "egress interface". Any MR's interface used for attachment to the mobile network is referred to as the "ingress interface". The mobility entities in the Proxy Mobile IPv6 domain provide mobility for the IPv4/IPv6 address(es) assigned to the mobile node's egress link and also mobility support to the network prefixes hosted in the network attached to the mobile router. Mobile Network A mobile network is an IP network attached to a mobile router. There can be many IP nodes in this IP network. The mobile router is a gateway for these IP nodes for reaching other IP networks or the Internet. The mobile router and the attached IP networks move as a single cluster. Delegated Mobile Network Prefix (DMNP) The Delegated Mobile Network Prefix is an IPv4/IPv6 prefix delegated to a mobile router and is hosted in the mobile network. The IP nodes in the mobile network will be able to obtain IP address configuration from the DMNP and will have IP mobility support for that address configuration. The DMNP is topologically anchored on the local mobility anchor, and the mobility elements in the Proxy Mobile IPv6 domain provide IP mobility support for the prefix by forwarding the mobile network traffic to the mobile router. A local fixed node is an IP node in the mobile network. As the mobile router performs a handoff and changes its network point of attachment, the local fixed node moves along with the mobile router. o The mobile router is a mobile node as defined in [RFC5213] but with additional capabilities for routing IP packets between its egress interface (interface used for attachment to the mobile access gateway) and any of its ingress interfaces (interfaces used for attachment to the mobile network). o The mobile router can obtain the delegated IP prefix(es) for its attached mobile networks using DHCPv6 prefix delegation, static configuration, or mechanisms specific to access technology. This document assumes DHCPv6 prefix delegation [RFC3633] in conjunction with the Prefix Exclude Option [RFC6603] as the default mechanism for prefix assignment to the mobile node. It defines an interworking between the mobility entities and the DHCPv6 functional elements in a non-normative way. The mechanism that delegates IPv4 subnets to a mobile router is out of the scope of this specification. o The mobile router obtains the IP address configuration for its egress roaming interface as specified in [RFC5213] and [RFC5844]. The mobile router, along with its mobile networks, will be able to perform handoff, change its point of attachment in the network, and retain IP mobility support. Figure 2 shows the high-level message call flow for this case. The mobile router attaches to the mobile access gateway, which triggers the Proxy Mobile IPv6 signaling between the mobile access gateway and the local mobility anchor, setting up the bidirectional tunnel between them (regular Proxy Mobile IPv6 registration). After that, the DHCPv6 requesting router function running on the mobile router sends a Solicit message requesting a prefix. This message is received by the DHCPv6 delegating router function running on the mobile access gateway. The mobile access gateway then sends a Proxy Binding Update message including a Delegated Mobile Network Prefix (DMNP) option carrying the ALL_ZERO value [RFC5213]. This serves as a request for the local mobility anchor to allocate a set of delegated prefixes, conveyed back in one or more DMNP options in a Proxy Binding Acknowledgement message. The DHCPv6-PD procedure is then completed as described in [RFC3633], ending with the delegating router sending a Reply message conveying the delegated prefixes. If the requesting router includes a Rapid Commit option in its Solicit message, it is preferable that the MAG respond directly with a Reply message rather than with an Advertise message, as described in [RFC3315], Section 17.2.3. 3.2.3. Static Configuration of Delegated Mobile Network Prefixes In this deployment scenario, the DMNPs of the mobile router are statically configured in the mobile node's policy profile [RFC5213]. The DMNPs are statically configured in the mobile network attached to the mobile router. The mobile router is the default-router for the mobile networks. Figure 4 shows a high-level message call flow for this example. The mobile access gateway obtains statically configured mobile network prefixes from the policy profile and registers them with the local mobility anchor using the extensions specified in this document, that is, the use of the Delegated Mobile Network Prefix (DMNP) option in the Proxy Mobile IPv6 signaling. There is no explicit trigger from the mobile router for registering or de-registering those prefixes. As long as there is a mobility session for the mobile router's home address, the local mobility anchor enables mobility support for the mobile network prefixes. Figure 4: Static Configuration of Delegated Mobile Network Prefixes 4.1. Delegated Mobile Network Prefix Option A new mobility header option, the Delegated Mobile Network Prefix option, is defined for use with Proxy Binding Update and Proxy Binding Acknowledgement messages exchanged between a local mobility anchor and a mobile access gateway. This option is used for exchanging the mobile router's IPv4/IPv6 DMNP. There can be multiple instances of the Delegated Mobile Network Prefix option present in a message. The Delegated Mobile Network Prefix option has an alignment requirement of 8n+2. Its format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |V| Reserved | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | . . + IPv4 or IPv6 Delegated Mobile Network Prefix + | (DMNP) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Delegated Mobile Network Prefix Contains a mobile router's 4-byte IPv4 or a 16-byte IPv6 Delegated Mobile Network Prefix. In order to support this specification, the conceptual Binding Update List Entry (BULE) data structure [RFC5213] needs to be extended to include a Delegated Mobile Network Prefix (DMNP) list. Each entry in the list is used for storing an IPv4/IPv6 mobile network prefix delegated to the mobile router. The mobile access gateway MUST include one or more Delegated Mobile Network Prefix (DMNP) options in the Proxy Binding Update message in order to request the local mobility anchor to allocate DMNP(s) for the mobile router. o There MUST be exactly one instance of the Delegated Mobile Network Prefix option with an ALL_ZERO value and with the (V) flag set to a value of (0). This serves as a request to the local mobility anchor to allocate a set of IPv6 DMNPs. o There MUST be exactly one instance of the Delegated Mobile Network Prefix option with an ALL_ZERO value and with the (V) flag set to a value of (1). This serves as a request to the local mobility anchor to allocate a set of IPv4 DMNP. o If the received Proxy Binding Acknowledgement message has the status field value set to NOT_AUTHORIZED_FOR_DELEGATED_MNP (not authorized for DMNP), the mobile access gateway MUST NOT enable mobility support for any of the prefixes in the mobile network, and prefix delegation support has to be disabled. o There MUST be exactly one instance of the Delegated Mobile Network Prefix option with NON_ZERO prefix value [RFC5213] for each of the mobile network prefixes that the mobile access gateway is requesting the local mobility anchor to allocate. The prefix value in the option is the prefix that is either statically configured for that mobile router in the mobile node's policy profile or obtained via interactions with the DHCP PD functions. This serves as a request to the local mobility anchor to allocate the requested IPv4/IPv6 prefix. o The Delegated Mobile Network Prefix (DMNP) list in the mobile router's Binding Update List entry has to be updated with the allocated prefix(es). However, if the received message was in response to a de-registration request with a lifetime value of (0), then the DMNP list has to be removed along with the Binding Update List entry. o The mobile access gateway has to set up a policy-based route for forwarding the IP packets received from the mobile network (with the source IP address from any of the IPv4/IPv6 DMNPs) through the bidirectional tunnel set up for that mobile router. However, if the received message was in response to a de-registration request with a lifetime value of (0), then the created forwarding state has to be removed. This specification assumes that all the mobile access gateways of a PMIPv6 domain support the same prefix delegation mechanism. Any differences will result in DMNPs getting de-registered and the mobile network losing the prefix(es). This would result in the attached local fixed nodes losing the assigned IP addresses. The mobile router MAY explicitly deprecate these prefixes. Alternatively, the lifetime of the addresses may expire. The mobile access gateway applies the considerations in Section 5.1.2 for requesting the local mobility anchor to enable delegated prefix support. For example, if the mobile router is soliciting an IPv4 prefix, the mobile access gateway includes in the Proxy Binding Update signaling a Delegated Mobile Network Prefix option with an ALL_ZERO value and with the (V) flag set to a value of (1). The standard DHCPv6 considerations will be applied with respect to the interactions between the delegating router and the requesting router. The requesting router is provided with the delegated prefix(es), which can then be then advertised in the mobile network and therefore used by the local fixed nodes to autoconfigure IP addresses, allowing them to gain access to the Internet. o The new mobile access gateway does not support the delegation of mobile network prefixes described in this specification. In this case, forwarding of the previously DMNPs is no longer performed. o The new mobile access gateway supports the delegation of mobile network prefixes described in this specification. There are two possible cases upon the reception of the Solicit message by the delegating router. If the MAG already knows the DMNPs, it conveys them in a DMNP option included in the Proxy Binding Update sent to the local mobility anchor, which then authorizes them based on: a) the content of the associated Binding Cache entry (if one exists), b) the user profile (if the allocation is static), or c) checking that the DMNPs are not already allocated. On the other hand, if the mobile access gateway is not aware of the DMNPs, it will include 0.0.0.0 / :: in a DMNP option included in the Proxy Binding Update sent to the LMA, which will provide the right prefixes back in the Proxy Binding Acknowledgement based on a) the content of the associated Binding Cache entry (if one exits), b) the profile (if static allocation is used), or c) dynamic assignment. The mobile access gateway will apply the considerations in Section 5.1.2 for requesting the local mobility anchor to enable delegated prefix support. The mobile access gateway will include exactly one instance of the Delegated Mobile Network Prefix option with NON_ZERO prefix value for each of the mobile network prefixes that the mobile access gateway is requesting the local mobility anchor to allocate. The prefix value(s) in the option will be the prefix(es) obtained via DHCP prefix delegation. can then be advertised in the mobile network and therefore used by the local fixed nodes to autoconfigure IP addresses, allowing them to gain access to the Internet. o The new mobile access gateway does not support the delegation of mobile network prefixes described in this specification. In this case, forwarding of the previously delegated mobile network prefixes is no longer performed. o The new mobile access gateway supports the delegation of mobile network prefixes described in this specification. There are two possible cases upon the reception of the Solicit message by the DHCPv6 relay agent. If the MAG already knows the DMNPs, it conveys them in a DMNP option included in the Proxy Binding Update sent to the local mobility anchor, which then authorizes them based on: a) the content of the associated Binding Cache entry (if one exists), b) the user profile (if the allocation is static), or c) checking that the DMNPs are not already allocated. On the other hand, if the mobile access gateway is not aware of the DMNPs, it will include 0.0.0.0 / :: in a DMNP option included in the Proxy Binding Update sent to the LMA, which will provide the right prefixes back in the Proxy Binding Acknowledgement based on a) the content of the associated Binding Cache entry (if one exits), b) the profile (if static allocation is used), or c) dynamic assignment. In order to support this specification, the conceptual Binding Cache entry (BCE) data structure [RFC5213] needs to be extended to include the Delegated Mobile Network Prefix (DMNP) list. Each entry in the list represents a DMNP. If the Proxy Binding Update message does not include any Delegated Mobile Network Prefix option(s) (Section 4.1), then the local mobility anchor MUST NOT enable Delegated Prefix support for the mobility session, and the Proxy Binding Acknowledgement message that is sent in response MUST NOT contain any Delegated Mobile Network Prefix option(s). If the Proxy Binding Update message includes one or more Delegated Mobile Network Prefix options, but the local mobility anchor is not configured with Delegated Prefix support, then the local mobility anchor will ignore the option(s) and process the rest of the option as specified in [RFC5213]. This would have no effect on the operation of the rest of the protocol. The Proxy Binding Acknowledgement message that is sent in response will not include any Delegated Mobile Network Prefix option(s). If the Proxy Binding Update message has the Delegated Mobile Network Prefix option(s) and if the local mobility anchor is configured for Delegated Prefix support, then the local mobility anchor MUST enable the Delegated Mobile Network Prefix option for that mobility session. The Proxy Binding Acknowledgement message that is sent in response MUST include the Delegated Mobile Network Prefix option(s). The following considerations apply. o If there is at least one instance of the Delegated Mobile Network Prefix option with an ALL_ZERO [RFC5213] prefix value, then this serves as a request for the local mobility anchor to perform the assignment of one or more DMNPs. * A Delegated Mobile Network option with an ALL_ZERO value and with the (V) flag set to a value of (0) is a request for the local mobility anchor to allocate one or more IPv6 prefixes. * A Delegated Mobile Network option with an ALL_ZERO value and with the (V) flag set to a value of (1) is a request for the local mobility anchor to allocate one or more IPv4 prefixes. * Inclusion of multiple instances of Delegated Mobile Network options with ALL_ZERO values, one with the (V) flag set to a value of (1) and another instance with the (V) flag set to a value of (0), is a request to allocate both IPv4 and IPv6 prefixes. o If there are no instances of the Delegated Mobile Network Prefix option present in the request with an ALL_ZERO value but a specific prefix value exists, then this serves as a request for the local mobility anchor to perform the allocation of the requested prefix(es). o The message MUST include one instance of the Delegated Mobile Network Prefix option for each of the allocated IPv4/IPv6 DMNPs. o The Delegated Mobile Network Prefix (DMNP) list in the mobile router's Binding Cache entry has to be updated with the allocated prefix(es). However, if the request is a de-registration request with a lifetime value of (0), the DMNP list has to be removed along with the Binding Cache entry. The local mobility anchor MUST advertise a connected route into the routing infrastructure for the IP prefixes delegated to all of the mobile routers that it is serving. This step essentially enables the local mobility anchor to be a routing anchor for those IP prefixes and be able to intercept IP packets sent to those mobile networks. The Delegated Mobile Network Prefix option defined in this specification is for use in Proxy Binding Update and Proxy Binding Acknowledgement messages. This option is carried like any other mobility header option as specified in [RFC5213]. Therefore, it inherits from [RFC5213] its security guidelines and does not require any additional security considerations. o This specification defines a new mobility header option, the Delegated Mobile Network Prefix option. This mobility option is described in Section 4.1. The type value 55 for this message has been allocated from the "Mobility Options" registry at http:// www.iana.org/assignments/mobility-parameters. http://www.ietf.org/rfc/rfc7161.txt 7161 Proxy Mobile IPv6 (PMIPv6) Multicast Handover Optimization by the Subscription Information Acquisition through the LMA (SIAL). LM. Contreras, CJ. Bernardos, I. Soto. March 2014. (Format: TXT=85916 bytes) (Status: EXPERIMENTAL) The backhaul delay characterization becomes problematic. In a real network, there are several solutions for the backhaul connection in terms of network topology (ring, star, point-to-point, etc.) and technology (optical fiber, microwave transmission, xDSL-based accesses, etc.), all of them having distinct properties in terms of performance, reliability, and delay. These solutions commonly coexist in a real mobile network, in such a way that an MN changing the point of attachment can pass smoothly from one solution to another. A value of D_bh = 5 ms can be established as the typical value for the backhaul latency in modern networks. --Apple-Mail=_BECAF02E-0E2E-46FC-85B4-D318E64B6E46 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-2 --Apple-Mail=_BECAF02E-0E2E-46FC-85B4-D318E64B6E46-- --Apple-Mail=_4B258988-A23B-4996-A35B-FC1E332A1AE2 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 iD8DBQFTPYQ5bjEdbHIsm0MRAmPCAKCGybxmsuzKzlkbnkqHI6gVPeCtwwCeInAN qgwjFrDo6T4dyhofs5Aw3rE= =iNVG -----END PGP SIGNATURE----- --Apple-Mail=_4B258988-A23B-4996-A35B-FC1E332A1AE2-- From nobody Thu Apr 3 13:09: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 C90ED1A012F; Thu, 3 Apr 2014 13:09:03 -0700 (PDT) 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 hG8IS1a511QX; Thu, 3 Apr 2014 13:08:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1484B1A017F; Thu, 3 Apr 2014 13:07:53 -0700 (PDT) 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: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140403200753.19889.62621.idtracker@ietfa.amsl.com> Date: Thu, 03 Apr 2014 13:07:53 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1FPXMG-EEwz5IbXgrSTUhdwFpUQ Cc: v6ops mailing list , v6ops chair , RFC Editor Subject: [v6ops] Document Action: 'Extending an IPv6 /64 Prefix from a 3GPP Mobile Interface to a LAN link' to Informational RFC (draft-ietf-v6ops-64share-10.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: Thu, 03 Apr 2014 20:09:04 -0000 The IESG has approved the following document: - 'Extending an IPv6 /64 Prefix from a 3GPP Mobile Interface to a LAN link' (draft-ietf-v6ops-64share-10.txt) as Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Joel Jaeggli and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-v6ops-64share/ Technical Summary This document summarizes the sharing of IPv6 connectivity for 3GPP devices or UEs in advance of implementations that fully support IPv6 prefix delegation. Specifically, this document outlines how a 3GPP device can facilitate connection sharing where only a single, globally routable /64 IPv6 prefix is available. Working Group Summary This draft was initiated in December 2012 draft-ietf-v6ops-64share-00.txt and has been actively updated since the initial draft was published. T-Mobile and DT have been actively working in this space advancing this work while mobile handsets evolve to support more advanced connectivity models including support for IPv6 prefix delegation. The overarching goal of the draft is to enable support for multiple devices through a connection that is enabled with globally routable IPv6 connectivity that is typically akin to that for a single device. This work does not employ the use of IPv6 address sharing or any form of translation related to IPv6. The working group has commented on at length and in turn the authors revised the draft to account for this feedback. Principally significant feedback was given around MTU handling and matters related to IPv6 neighbor discovery in where 64share has been deployed. More recently alignment with related work has been considered including RFC6204bis. Finally, Neighbor Discovery Proxy (ND Proxy) [RFC4389] functionality has been suggested as an option for extending the assigned /64 from the 3GPP radio interface to the LAN link, but ND Proxy is an experimental protocol and has some limitations with loop-avoidance. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? Personnel As specified in the abstract, the document is not a protocol or procedure; the document does outline implementation details and observations of the same to date in various modes of operation. From nobody Fri Apr 4 02:34: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 877BB1A0406 for ; Fri, 4 Apr 2014 02:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 57T63jKlOa7Q for ; Fri, 4 Apr 2014 02:34:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7801A0019 for ; Fri, 4 Apr 2014 02:34:51 -0700 (PDT) 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 BFG42016; Fri, 04 Apr 2014 09:34:46 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Apr 2014 10:33:31 +0100 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Apr 2014 10:34:30 +0100 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.77]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.03.0158.001; Fri, 4 Apr 2014 17:34:24 +0800 From: Tina TSOU To: Lorenzo Colitti , Nalini Elkins Thread-Topic: [v6ops] Comcast IPv6 Thread-Index: AQHPTSkQYUvfZUq1EU6gxsoZ3JzdKpr8WoWAgATbl7A= Date: Fri, 4 Apr 2014 09:34:24 +0000 Message-ID: References: <532C6E10.1040209@gmail.com> <20140331113541.GL43641@Space.Net> <1396274911.84934.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2A958356-CDB7-442F-8440-D775476A3909@lists.zabbadoz.net> <1396277061.74347.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1396277948.18387.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <4FC37E442D05A748896589E468752CAA0CB6B201@PWN401EA160.ent.corp.bcbsm.com> <4FC37E442D05A748896589E468752CAA0CB6B595@PWN401EA160.ent.corp.bcbsm.com> <1396301680.57607.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.87.91] Content-Type: multipart/alternative; boundary="_000_C0E0A32284495243BDE0AC8A066631A8181F173Cszxeml557mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Z5jSBahPMB9KKnTwUsz2u5R-iOg Cc: IPv6 Operations Subject: Re: [v6ops] Comcast IPv6 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, 04 Apr 2014 09:34:57 -0000 --_000_C0E0A32284495243BDE0AC8A066631A8181F173Cszxeml557mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCkpvaG4sIFlpdSwgSmFzb24gYW5kIG90aGVyIGNvbGxlYWd1ZXMgaGVscGVk IG91ciBvZmZpY2UgbmV0d29ya3MgKFNhbnRhIENsYXJhLCBDQSkgYW5kIG15IGhvbWUgbmV0d29y a3MgKEN1cGVydGlubyBhbmQgQ2FtcGJlbGwsIENBKSBnbyB0byBJUHY2IHRvbyBzaW5jZSAyMDEx Lg0KDQpUaGFuayB5b3UsIEpvaG4sIFlpdSwgSmFzb24gYW5kIENvbWNhc3QhDQoNCg0KVGhhbmsg eW91LA0KVGluYQ0KDQpGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBMb3JlbnpvIENvbGl0dGkNClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDAxLCAy MDE0IDExOjE3IFBNDQpUbzogTmFsaW5pIEVsa2lucw0KQ2M6IElQdjYgT3BlcmF0aW9ucw0KU3Vi amVjdDogUmU6IFt2Nm9wc10gQ29tY2FzdCBJUHY2DQoNCkdvb2Qgb24geWEgSm9obiENCg0KQ29u dmluY2luZyB0aGUgd29ybGQgdGhhdCBJUHY2IGV4aXN0cywgb25lIHNrZXB0aWMgYXQgYSB0aW1l LiA6LSkNCg0KT24gVHVlLCBBcHIgMSwgMjAxNCBhdCA2OjM0IEFNLCBOYWxpbmkgRWxraW5zIDxu YWxpbmkuZWxraW5zQGluc2lkZXRoZXN0YWNrLmNvbTxtYWlsdG86bmFsaW5pLmVsa2luc0BpbnNp ZGV0aGVzdGFjay5jb20+PiB3cm90ZToNCkd1eXMsDQoNCkpvaG4gQnJ6b3pvd3NraSBvZiBDb21j YXN0IGhhcyBiZWVuIEVYVFJFTUVMWSBoZWxwZnVsICYgZmVlbHMgdGhhdCBpbmRlZWQgbXkgYXJl YSBET0VTIGhhdmUgSVB2NiBzZXJ2aWNlLiAgIEkgd2lsbCBoYXZlIHRvIHBoeXNpY2FsbHkgZ28g dG8gbXkgbG9jYWwgb2ZmaWNlIHdpdGggdGhlIG1vZGVtICYgc2VlIHdoYXQgSSBoYXZlIHRvIGRv Lg0KTWF5IGhhdmUgdG8gc3dhcCBvdXQgdGhlIGVxdWlwbWVudC4NCg0KVW5mb3J0dW5hdGVseSwg aXQgd2lsbCB0YWtlIG1lIGEgZGF5IG9yIHR3byB0byBnZXQgdG8gdGhpcyBiZWNhdXNlIEkgaGF2 ZSB0byBhY3R1YWxseSBkbyBteSBkYXkgam9iIQ0KDQpUaGFua3MgdmVyeSBtdWNoLCBKb2huIQ0K DQpXaWxsIHJlcG9ydCBiYWNrIG9uIG15IHByb2dyZXNzLg0KDQpOYWxpbmkgRWxraW5zDQpJbnNp ZGUgUHJvZHVjdHMsIEluYy4NCig4MzEpIDY1OS04MzYwDQp3d3cuaW5zaWRldGhlc3RhY2suY29t PGh0dHA6Ly93d3cuaW5zaWRldGhlc3RhY2suY29tPg0KDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnY2b3BzIG1haWxpbmcgbGlzdA0KdjZvcHNA aWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby92Nm9wcw0KDQo= --_000_C0E0A32284495243BDE0AC8A066631A8181F173Cszxeml557mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkFyaWFsIFVuaWNvZGUgTVMiOw0KCXBhbm9z ZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2Fs aWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEg MSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQEFyaWFsIFVuaWNvZGUgTVMi Ow0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk65a6L5L2TO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u aG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQXJpYWwgVW5pY29k ZSBNUyIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVz dGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRlYXIgYWxsLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7 dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVz dGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Sm9obiwgWWl1LCBKYXNvbiBhbmQgb3RoZXIgY29sbGVhZ3Vl cyBoZWxwZWQgb3VyIG9mZmljZSBuZXR3b3JrcyAoU2FudGEgQ2xhcmEsIENBKSBhbmQNCiBteSBo b21lIG5ldHdvcmtzIChDdXBlcnRpbm8gYW5kIENhbXBiZWxsLCBDQSkgZ28gdG8gSVB2NiB0b28g c2luY2UgMjAxMS4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0 ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFuayB5b3Us IEpvaG4sIFlpdSwgSmFzb24gYW5kIENvbWNhc3QhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6 aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlk ZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRo YW5rIHlvdSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGluYTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCBVbmlj b2RlIE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5Mb3JlbnpvIENvbGl0dGk8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgQXByaWwgMDEs IDIwMTQgMTE6MTcgUE08YnI+DQo8Yj5Ubzo8L2I+IE5hbGluaSBFbGtpbnM8YnI+DQo8Yj5DYzo8 L2I+IElQdjYgT3BlcmF0aW9uczxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBDb21j YXN0IElQdjY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkdvb2Qgb24geWEgSm9o biE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Db252aW5jaW5nIHRo ZSB3b3JsZCB0aGF0IElQdjYgZXhpc3RzLCBvbmUgc2tlcHRpYyBhdCBhIHRpbWUuIDotKTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5PbiBUdWUsIEFwciAxLCAyMDE0IGF0IDY6MzQgQU0sIE5hbGluaSBF bGtpbnMgJmx0OzxhIGhyZWY9Im1haWx0bzpuYWxpbmkuZWxraW5zQGluc2lkZXRoZXN0YWNrLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPm5hbGluaS5lbGtpbnNAaW5zaWRldGhlc3RhY2suY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5HdXlzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Kb2huIEJyem96 b3dza2kgb2YgQ29tY2FzdCBoYXMgYmVlbiBFWFRSRU1FTFkgaGVscGZ1bCAmYW1wOyBmZWVscyB0 aGF0IGluZGVlZCBteSBhcmVhIERPRVMgaGF2ZSBJUHY2IHNlcnZpY2UuICZuYnNwOyBJIHdpbGwg aGF2ZSB0byBwaHlzaWNhbGx5IGdvIHRvIG15IGxvY2FsIG9mZmljZSB3aXRoIHRoZSBtb2RlbSAm YW1wOyBzZWUNCiB3aGF0IEkgaGF2ZSB0byBkby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk1h eSBoYXZlIHRvIHN3YXAgb3V0IHRoZSBlcXVpcG1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlVuZm9ydHVuYXRlbHksIGl0IHdpbGwg dGFrZSBtZSBhIGRheSBvciB0d28gdG8gZ2V0IHRvIHRoaXMgYmVjYXVzZSBJIGhhdmUgdG8gYWN0 dWFsbHkgZG8gbXkgZGF5IGpvYiE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhhbmtzIHZlcnkgbXVjaCwgSm9obiE8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+V2lsbCByZXBvcnQg YmFjayBvbiBteSBwcm9ncmVzcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Izg4ODg4 OCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM4ODg4ODgiPk5hbGluaSBF bGtpbnM8YnI+DQpJbnNpZGUgUHJvZHVjdHMsIEluYy48YnI+DQooODMxKSA2NTktODM2MDxicj4N CjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5zaWRldGhlc3RhY2suY29tIiB0YXJnZXQ9Il9ibGFuayI+ d3d3Lmluc2lkZXRoZXN0YWNrLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJob2VuemIiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6Izg4ODg4OCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3Bh biBsYW5nPSJFTi1VUyI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQp2Nm9wcyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_C0E0A32284495243BDE0AC8A066631A8181F173Cszxeml557mbschi_-- From nobody Fri Apr 4 03:01: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 127291A00C6 for ; Fri, 4 Apr 2014 03:01:23 -0700 (PDT) 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 oQIMY68QTrNK for ; Fri, 4 Apr 2014 03:01:18 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 717A11A004D for ; Fri, 4 Apr 2014 03:01:18 -0700 (PDT) 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 s34A1A5i022019; Fri, 4 Apr 2014 12:01:10 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1FE4F202145; Fri, 4 Apr 2014 12:03:01 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 13815200C28; Fri, 4 Apr 2014 12:03:01 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s34A16Jl005084; Fri, 4 Apr 2014 12:01:10 +0200 Message-ID: <533E82E2.8040902@gmail.com> Date: Fri, 04 Apr 2014 12:01:06 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <20140401231447.18485.85226.idtracker@ietfa.amsl.com> <1808340F7EC362469DDFFB112B37E2FCDA33129A67@SRVHKE02.rdm.cz> <533D45C5.6070005@gmail.com> <29E2A37D-7C52-4105-89FA-22F7F194A492@cisco.com> In-Reply-To: <29E2A37D-7C52-4105-89FA-22F7F194A492@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/n4yCS5azF76DydsVlE9xCroowV8 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-10.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: Fri, 04 Apr 2014 10:01:23 -0000 Le 03/04/2014 17:54, Fred Baker (fred) a ĂŠcrit : > > On Apr 3, 2014, at 4:28 AM, Alexandru Petrescu > wrote: > >> Thanks for the update. >> >> I am happy this document advances. >> >> I don't comment after a IESG review, just a few points for when >> time allows: > > It’s harder to change now. Time would have allowed at an earlier > date. Hi Fred, This is not a request for a change. >> - the term 'mobile network' is inconsistently used across this >> document and a published RFC. > > I’m not quite sure what you mean here. In this document, the term is > used twice, in the second and third paragraphs of the security > considerations section: > > Despite the use of temporary IPv6 addresses, the mobile network > provided /64 prefix is common to all the LAN attached devices > potentially concerning privacy. A nomadic device (e.g. a smartphone) > provided IPv6 prefix is not a long lived one due to re-attaches > caused by a device reload, traveling through loosely covered areas, > etc. The network will provide a new IPv6 prefix after a successful > re-attach. > > 3GPP mobile network capable CPEs (e.g. a router) are likely to keep > the mobile network data connection up for a longer time. Some mobile > networks may be re-setting the mobile network connection regularly > (e.g. every 24 hours) others may not. Privacy concerned users shall > take appropriate measures to not to keep their IPv6 prefixes long- > lived. > > In both cases, the term “mobile network” refers to the 3G/4G/LTE > network operated by the network provider. Yes, but a 'mobile network' as defined by the mobility terminology RFC has the mobile network be what this draft calls a 'LAN'. And I agree, this draft calls a 'mobile network' what the mobility terminology RFC calls a 'mobile access network'. This is even more complicated because we have here the cellular network facing a LAN, but otherwise a mobile network facing another mobile network? But yes - certainly, we are free to read this each in his/her own sense, and understand it ok. > The provider uses a common /64 across the devices connected to it in > a cell, and those devices, whether traditional handsets or things > more similar to traditional networking equipment but equipped with > 3G/4G/LTE interfaces, might keep those connections up for a period > of time. > > There are 121 RFCs that use the term “mobile network”. Thanks, didn't know that. > Some, such as RFC 898 (dated 1984), predate commercial use of the > term, and refer more to the packet radio experiments carried on by > SRI in that timeframe. This use of 'mobile network' in RFC898 is consistent with the definition of a mobile network in the mobility terminology RFC. > Per RFC 1726 (Requirements for IPng, 1994), > the term is used at least to include > > Reference [6] discusses possible future use of IP-based networks in > the US Navy's ships, planes, and shore installations. Their basic > model is that each ship, plane and shore installation represents at > least one IP network. The ship- and plane-based networks, > obviously, are mobile as these craft move around the world. > Furthermore, most, if not all, Naval surface combatants carry some > aircraft (at a minimum, a helicopter or two). So, not only must there > be mobile networks (the ships that move around), but there must be > mobile internetworks: the ships carrying the aircraft where each > aircraft has its own network, which is connected to the ship's > network and the whole thing is moving. This too, 'mobile network' consistent with the defitnition of mobile network in the mobilterminology RFC. > By the way, I’m not convinced that it is accurate to say that these > were “future” requirements; The use case existed in deployment at > the time. I agree. > RFC 2002 uses the term to refer to a subnet in motion within a > larger fixed network, or a network of individual devices in motion: > > A mobile node can be a router, which is responsible for the mobility > of one or more entire networks moving together, perhaps on an > airplane, a ship, a train, an automobile, a bicycle, or a kayak. The > nodes connected to a network served by the mobile router may > themselves be fixed nodes or mobile nodes or routers. In this > document, such networks are called "mobile networks”. > > If you’re referring to the now-common usage of commercial mobile > networks based on cellular radio technology, yes, those are also > referred to as “mobile networks”. But they are a relatively recent > group to choose the term. That is ok, but reflecting it in an RFC series exposes this duality in a different light, maybe contradictory in a sense. > I’m not sure I understand your point. That the term has been used > with multiple definitions in the RFC series? My point is that the term 'mobile network' used in this draft is used in such a way (it designates the 3GPP fixed network which supports movement of mobiles around it, it does not designate the network that moves) that is inconsistent with the other RFCs. > > See attached. > >> - the method works for _a_ SLAACed (W)LAN - it wouldnt scale >> beyond one such link. > > That comment came up in working group discussion, I believe. Since > that was the target use case, it was deemed an acceptable > limitation. To scale to multiple (W)LANs, the device and the network > would need to implement RFC 3633 or something equivalent to it. YEs, I agree to this point. The draft does not say it, but people should know. For example, in one particular case, just an example: trying to connect a vehicle to an IPv6-only cellular infrastructure may be tempted by 64share, or by NPT, but may realize that because there are typically several subnets in a vehicle, and because the cellular only gives a /64, neither 64share nor NPT may prove attractive candidates. Alex > >> Alex >> >> Le 02/04/2014 01:20, VĂ­zdal AleĹĄ a ĂŠcrit : >>> IESG review remarks have been incorporated. >>> >>> Ales >>> >>>> -----Original Message----- From: v6ops >>>> [mailto:v6ops-bounces@ietf.org] On Behalf Of >>>> internet-drafts@ietf.org Sent: Wednesday, April 02, 2014 1:15 >>>> AM To: i-d-announce@ietf.org Cc: v6ops@ietf.org Subject: >>>> [v6ops] I-D Action: draft-ietf-v6ops-64share-10.txt >>>> >>>> >>>> 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 : Extending an IPv6 /64 Prefix from a 3GPP >>>> Mobile Interface to a LAN link Authors : Cameron Byrne >>>> Dan Drown Ales Vizdal Filename : >>>> draft-ietf-v6ops-64share-10.txt Pages : 9 Date : >>>> 2014-04-01 >>>> >>>> Abstract: This document describes requirements for extending >>>> an IPv6 /64 prefix from a User Equipment 3GPP radio interface >>>> to a LAN link as well as two implementation examples. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-64share/ >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-v6ops-64share-10 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-64share-10 >>>> >>>> >>>> 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/ >>>> >>>> _______________________________________________ v6ops mailing >>>> list v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>> >>> ZĂĄsady komunikace, kterĂŠ společnost T-Mobile Czech Republic a.s. >>> uŞívĂĄ při sjednĂĄvĂĄnĂ­ smluv, jsou uvedeny zde >>> http://www.t-mobile.cz/zasady. NenĂ­-li v zĂĄsadĂĄch uvedeno jinak, >>> nepředstavuje tato zprĂĄva konečnĂ˝ nĂĄvrh na uzavřenĂ­ či změnu >>> smlouvy ani přijetĂ­ takovĂŠho nĂĄvrhu. The communication >>> principles which T-Mobile Czech Republic a.s. applies when >>> negotiating contracts are defined here >>> http://www.t-mobile.cz/principles. Unless otherwise stated in the >>> principles, this message does not constitute the final offer to >>> contract or an amendment of a contract or acceptance of such >>> offer. > > > > > From nobody Mon Apr 7 01:36: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 81E3F1A0343 for ; Mon, 7 Apr 2014 01:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 aabXWejll-IO for ; Mon, 7 Apr 2014 01:36:00 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 59DBA1A0344 for ; Mon, 7 Apr 2014 01:35:59 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 2C8096168 for ; Mon, 7 Apr 2014 01:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :content-type:message-id:mime-version:subject:date:references:to :in-reply-to; s=selector1; bh=TlxZtggayl8TC7wSR3mgWvE8NP8=; b=Tu iibf53rJFkF864ZgAk8LPecPRcpQVZL7wUkT7smqRWEEs0HcPlXVbGXdVeOJDnBi OqMpysO8tpssedDXJusfYhdAM4veNjDqb0w1iPlCnLHL9pecUM8q1MZ1yl6jYEwR I8oTIQqtPrtod6Sj3l+/ozthLTjRep92p9W1I6UQM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :content-type:message-id:mime-version:subject:date:references:to :in-reply-to; q=dns; s=selector1; b=Fr6pCTrk8GWb2njEhG6f4kh8IMX/ wU+8CQALwUskEl2bB/Y1OFNADDIzLjx2UrVvPNixuwtj+qII79MBttpES8HHGUQc XDFSzpfKwy3spvLG9/ycXWSz58RVdlBS/nHtdmlr36k3WtAPUZhu8Cl/N9Fhc+QS nLMU6WX9tji6hlE= Received: from dhcp-10-61-102-65.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 CEF66617C for ; Mon, 7 Apr 2014 01:35:47 -0700 (PDT) From: Ole Troan Content-Type: multipart/signed; boundary="Apple-Mail=_82298AA7-93BD-496B-AE24-20AE9294E633"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <7592BD2A-70A1-45F5-9566-4F76A76B5784@employees.org> Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Date: Mon, 7 Apr 2014 10:35:50 +0200 References: <20140401231447.18485.85226.idtracker@ietfa.amsl.com> To: "v6ops@ietf.org WG" In-Reply-To: <20140401231447.18485.85226.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/zvhVCxnVS8CxuMp2PVUkl70sB78 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-10.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, 07 Apr 2014 08:36:05 -0000 --Apple-Mail=_82298AA7-93BD-496B-AE24-20AE9294E633 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii shouldn't this document reference Appendix A of RFC4389 specifically? if not also RFC4903. cheers, Ole On 02 Apr 2014, at 1:14 , internet-drafts@ietf.org wrote: >=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 : Extending an IPv6 /64 Prefix from a 3GPP = Mobile Interface to a LAN link > Authors : Cameron Byrne > Dan Drown > Ales Vizdal > Filename : draft-ietf-v6ops-64share-10.txt > Pages : 9 > Date : 2014-04-01 >=20 > Abstract: > This document describes requirements for extending an IPv6 /64 = prefix > from a User Equipment 3GPP radio interface to a LAN link as well as > two implementation examples. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-64share/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-64share-10 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-64share-10 >=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 --Apple-Mail=_82298AA7-93BD-496B-AE24-20AE9294E633 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 iQEcBAEBCgAGBQJTQmNmAAoJEFuJXizso86gSJkH/jaNR0TXKLsPJUxAzUDkUJYN JwWNjM1kfVOiVjqMtQSlTRdW49Qj1t1KPJ8RKwgvHgEB2Dwpiuqzund83B+9G7u4 geMrnh1gvhFGs9Cdod+iUCtWWGx6aWoUjwqdWF4KAQmUBvQ5Is2swiWMyQQY0XAj NcG3IDI3neQRIQ0IfwVYYdU1tooElW6s4RuJd+SgnivdHTDIAhMqMwbM5ivTmOjt pK9MZgBF76lSQA9TJNjUJqJXCpzT6e6ZhMr/gHc2Ya57Ry6AaBfdjC/XuOP5R+K8 3B95ff0ObVsAl839tvCS2/Gg58ypGy8AcLLn6VPP4zNKCeGDuzlhlakUYy4OOaY= =HulW -----END PGP SIGNATURE----- --Apple-Mail=_82298AA7-93BD-496B-AE24-20AE9294E633-- From nobody Mon Apr 7 14: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 7C0ED1A07AE for ; Mon, 7 Apr 2014 14:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 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, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, 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 AnjY3oIgSYut for ; Mon, 7 Apr 2014 14:21:31 -0700 (PDT) Received: from nm35-vm5.bullet.mail.bf1.yahoo.com (nm35-vm5.bullet.mail.bf1.yahoo.com [72.30.238.77]) by ietfa.amsl.com (Postfix) with ESMTP id 98C251A01FC for ; Mon, 7 Apr 2014 14:21:16 -0700 (PDT) Received: from [98.139.215.140] by nm35.bullet.mail.bf1.yahoo.com with NNFMP; 07 Apr 2014 21:21:10 -0000 Received: from [98.139.212.220] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 07 Apr 2014 21:21:10 -0000 Received: from [127.0.0.1] by omp1029.mail.bf1.yahoo.com with NNFMP; 07 Apr 2014 21:21:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 672729.23962.bm@omp1029.mail.bf1.yahoo.com Received: (qmail 45998 invoked by uid 60001); 7 Apr 2014 21:21:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1396905670; bh=bHWSzIVRAXIpFihnQcuEh4+WN0Q6d8vqTo5Y7e5xwQM=; 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=TI5hZPdHy4AKhOep1CPdrhQCqsDdzKdX6iA6g8KvSiCKWriL2Y22rNhXAyS6FBqgGsLijEkM4oi3VO8XpJS750pO0Rejc3YGPyyankvY1s/iFA9ReC/1C/Y/LnbskrZeissp4NXBjoGtM2ajo0ceDk4XGTGpTHQ9GWVaQAA3OCg= 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=V/halDMive7ZwOF726ZQbo7JSRLuXgTYqRXJGqoIgZ1roCDWQ3NgwANCDRM8gc2El9KDziHtxTLRI0JlTlWfskKdS37vj2zVNbaI8EpzQOXq+a6XeaMN1ki3RiW3BBJsVwdcEJgscw3QJ/9jWCd5Hxzd+H5opZ7T7wy0N7Qg4KE=; X-YMail-OSG: LSaPeDIVM1lG2eOMZCRZ7IB6A5PbScGgPHI.hh0BIZILmf_ Srou1F6.IN_UZ5EvRTYBl6mIJFTRqNYEMfrKEW2anKUDTQGh0frKbAKdEbWC 21drAh_sb08Dc.sAshtroWDBN5ipK8P7GjJ5AK5C8O3CuyMBqeQ0lXIswVLi FSls7BA4TSy8txrqg5ZQUXLfH4RLKKcu1g6ctiBYF.bovKokdRnPxpr_nZ8E RpTvtazznkIPMOZ_IjJxVEBpESGqFatCh1NRkFQ.H.UMbNoS_4ckVBcNA4HY Dh0Q1zZ0PzIIDxxCPVKrtRqSYg5Ie0Mhix0gHzskYdWUPX9zp1MC6aQIDBNL LuWMGDVkB3BPFzCHmSJDHuZ9T86b.Di8kRlJMFSihKblpWKLbzIUG8_1Sfdp iiIPDi3_W4IWKzMA9kxPeZwKgGAXDXWJhJ.2mBLtZUH8yOQoB2Fk98dNuLuF uGf0Zye4QpixtgPLH45b0O5NDgI0wHTDM9b5v30w9EcGYGPBL9up1PWWWyKe BxZrkI_sc.SMLipJ7r6NDHiAaHN0kcRUWX6MYF.SulVswlmfJ0Nj7 Received: from [150.101.221.237] by web162205.mail.bf1.yahoo.com via HTTP; Mon, 07 Apr 2014 14:21:10 PDT X-Rocket-MIMEInfo: 002.001, SGksCgpJJ3ZlIGp1c3QgcG9zdGVkIHRoZSBmb2xsb3dpbmcgSUQsIGdyYXRlZnVsIGZvciBhbnkgZmVlZGJhY2suCgpSZWdhcmRzLApNYXJrLgoKCi0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tCj4gRnJvbTogImludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4KPiBUbzogTWFyayBTbWl0aCA8bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdT47IE1hcmsgU21pdGggPG1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU.Cj4gQ2M6IAo.IFNlbnQ6IFR1ZXNkYXksIDggQXABMAEBAQE- X-Mailer: YahooMailWebService/0.8.182.648 References: <20140407211920.26125.99768.idtracker@ietfa.amsl.com> Message-ID: <1396905670.42588.YahooMailNeo@web162205.mail.bf1.yahoo.com> Date: Mon, 7 Apr 2014 14:21:10 -0700 (PDT) From: Mark ZZZ Smith To: V6 Ops List In-Reply-To: <20140407211920.26125.99768.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ZCmIlNz-g2W7nqP6oGw3uQkpVdU Subject: [v6ops] Fw: New Version Notification for draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.txt 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, 07 Apr 2014 21:21:36 -0000 Hi,=0A=0AI've just posted the following ID, grateful for any feedback.=0A= =0ARegards,=0AMark.=0A=0A=0A----- Forwarded Message -----=0A> From: "intern= et-drafts@ietf.org" =0A> To: Mark Smith ; Mark Smith =0A> Cc: =0A> Sen= t: Tuesday, 8 April 2014 7:19 AM=0A> Subject: New Version Notification for = draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.txt=0A> =0A> =0A> A ne= w version of I-D, draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.txt= =0A> has been successfully submitted by Mark Smith and posted to the=0A> IE= TF repository.=0A> =0A> Name:=A0=A0=A0 =A0=A0=A0 draft-smith-v6ops-mitigate= -rtr-dos-mld-slctd-node=0A> Revision:=A0=A0=A0 00=0A> Title:=A0=A0=A0 =A0= =A0=A0 Further Mitigating Router ND Cache Exhaustion DoS Attacks Using =0A>= Solicited-Node Group Membership=0A> Document date:=A0=A0=A0 2014-04-07=0A>= Group:=A0=A0=A0 =A0=A0=A0 Individual Submission=0A> Pages:=A0=A0=A0 =A0=A0= =A0 6=0A> URL:=A0 =A0 =A0 =A0 =A0 =A0 =0A> http://www.ietf.org/internet-dra= fts/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.txt=0A> Status:=A0= =A0 =A0 =A0 =0A> https://datatracker.ietf.org/doc/draft-smith-v6ops-mitiga= te-rtr-dos-mld-slctd-node/=0A> Htmlized:=A0 =A0 =A0 =0A> http://tools.ietf.= org/html/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00=0A> =0A> =0A>= Abstract:=0A> =A0 For each of their IPv6 unicast or anycast addresses, no= des join a=0A> =A0 Solicited-Node multicast group, formed using the lower = 24 bits of the=0A> =A0 address.=A0 This group membership can be used by ro= uters to further=0A> =A0 mitigate the Neighbor Discovery cache Denial of S= ervice attack.=0A> =0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =0A> =A0 =0A> =0A> =0A> Please note tha= t it may take a couple of minutes from the time of submission=0A> until the= htmlized version and diff are available at tools.ietf.org.=0A> =0A> The IE= TF Secretariat=0A> From nobody Tue Apr 8 05:45: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 3ADB41A0386 for ; Tue, 8 Apr 2014 05:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.874 X-Spam-Level: X-Spam-Status: No, score=-107.874 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, 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 uvR78AMQJEmf for ; Tue, 8 Apr 2014 05:45:20 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id F41E01A0375 for ; Tue, 8 Apr 2014 05:45:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=151; q=dns/txt; s=iport; t=1396961120; x=1398170720; h=date:from:message-id:to:subject:cc; bh=2H1syy+0KIxTytXgJUDI4nC+xXuKW9JwDDXNCCSu+eY=; b=MRBeYjQmwylK7rBDlEAIcqZMIe/awrFfBOmdfZUoY++d/0NwbmRIiB1L kMNBrPYjHtN0k/mm85WLZ1AjtlVFxuznMqy3rWtzWq1mIHaxPdh0XYs3G zxR4d0rkdlvG0dDHsihZN+yi0t9n857zO4OO9AX65k5ObVEhJEA8qQcC6 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar4GAOPuQ1OrRDoG/2dsb2JhbABZgwY7rjEBlkyBHhZ0gyU8NIhcDsouF45sHYQiBIlbkDaRDINQ X-IronPort-AV: E=Sophos;i="4.97,818,1389744000"; d="scan'208";a="33952145" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by alln-iport-7.cisco.com with ESMTP; 08 Apr 2014 12:45:19 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s38CjJG8003997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Apr 2014 12:45:19 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id s38CjIP4008908; Tue, 8 Apr 2014 05:45:18 -0700 (PDT) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id s38CjHY2008892; Tue, 8 Apr 2014 05:45:17 -0700 (PDT) Date: Tue, 8 Apr 2014 05:45:17 -0700 (PDT) From: Fred Baker Message-Id: <201404081245.s38CjHY2008892@irp-view13.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/eiUOvgVZCr-dQNsVYRfEN2hVBzk Cc: draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node@tools.ietf.org Subject: [v6ops] new draft: draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node 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, 08 Apr 2014 12:45:22 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node. Please take a look at it and comment. From nobody Tue Apr 8 09:24: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 47C531A04AA for ; Tue, 8 Apr 2014 09:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.874 X-Spam-Level: X-Spam-Status: No, score=-107.874 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, 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 KYesjgwe1bEV for ; Tue, 8 Apr 2014 09:24:30 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8A71A0522 for ; Tue, 8 Apr 2014 09:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1992; q=dns/txt; s=iport; t=1396974270; x=1398183870; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WYiN5E5446FAiAxzLLQXRUu5EG76/fZTrKRLj0xWoro=; b=QCojkntkAZXlza2ht1ICmVFhppFqZF4zcFKNsTjQJ4fxjOqx5RggNPMy iW4HU29AKumLS84u0TyoVav3aESUOX0esaBqEdOSjeKeGNVuM0Jq2KOR9 7OBG1WZF932rwY27D5FouJGFRNkrL75LC/fxfjQjD1nP2GgigMj/KD07t k=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFALUhRFOtJV2Y/2dsb2JhbABZgwaBEsQpgR8WdIImAQEEcgcQAgFOMiUCBA4Th27KEBeObAeDJIEUBJBggTWGSJJAgzCCKw X-IronPort-AV: E=Sophos;i="4.97,818,1389744000"; d="asc'?scan'208";a="34011336" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP; 08 Apr 2014 16:24:30 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s38GOU5N005908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Apr 2014 16:24:30 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Tue, 8 Apr 2014 11:24:29 -0500 From: "Fred Baker (fred)" To: Mark ZZZ Smith Thread-Topic: draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.txt Thread-Index: AQHPU0cE96BZNuvLTk6vQVGdMoDT9A== Date: Tue, 8 Apr 2014 16:24:29 +0000 Message-ID: <7A01B3A7-84CB-42E3-BF78-90C0F24DE73A@cisco.com> References: <20140407211920.26125.99768.idtracker@ietfa.amsl.com> <1396905670.42588.YahooMailNeo@web162205.mail.bf1.yahoo.com> In-Reply-To: <1396905670.42588.YahooMailNeo@web162205.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.116] Content-Type: multipart/signed; boundary="Apple-Mail=_F1A1FB26-DD82-4272-9B43-8E580CA8B27F"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/IkqGo4xXmPrndv4Xn97BumG5qjo Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org>, V6 Ops List Subject: [v6ops] draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.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, 08 Apr 2014 16:24:35 -0000 --Apple-Mail=_F1A1FB26-DD82-4272-9B43-8E580CA8B27F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I have several different thoughts on this. First is to wonder whether it = fits this forum; it might fit better in 6man or savi. I have copied the = 6man chairs on this for their comment. As I understand it on a quick read, you talk about how a Solicited Node = Multicast works, and point out that there is no point sending out a = Solicited Node Multicast (the counterpart to an ARP Broadcast) at L2 if = nobody has joined the indicated group at L3. That=92s a very interesting = observation, and worth considering. A corollary to that might be related to draft-ietf-savi-dhcp and/or RFC = 6620; a SAVI switch configures filters to deny all traffic it doesn=92t = permit, and permits IPv6 traffic to be originated from a given port if = and only if it uses a source address that has been allocated to (DHCP) = or DAD verified by (SLAAC) a device on the port. One might similarly or = additionally observe that a host that doesn=92t join the relevant = multicast group cannot be reached by the network, and therefore should = not be injecting traffic into the network, making joining the SNM Group = a condition of authorization to use the network.=20 What is the relationship between this and Optimistic ND? RFC 4429.=20 What are the operational considerations appropriate to this? --Apple-Mail=_F1A1FB26-DD82-4272-9B43-8E580CA8B27F 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 iD8DBQFTRCK7bjEdbHIsm0MRAoKnAJ98Y7jC/TuTNEl/rkQJ+9JNHr+KwwCfYl/A e2A9B8WyugS42I4gusI5Jhc= =FTfR -----END PGP SIGNATURE----- --Apple-Mail=_F1A1FB26-DD82-4272-9B43-8E580CA8B27F-- From nobody Tue Apr 8 21:13: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 B98B81A008E for ; Tue, 8 Apr 2014 21:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.05 X-Spam-Level: * X-Spam-Status: No, score=1.05 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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.272, 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 pNm9cQtH8irf for ; Tue, 8 Apr 2014 21:13:41 -0700 (PDT) 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 78F2D1A008A for ; Tue, 8 Apr 2014 21:13:41 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id ur14so1950273igb.10 for ; Tue, 08 Apr 2014 21:13:41 -0700 (PDT) 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=BCnFCOiLS1X4qycQFE3nsyoQpV0xOJMHcCpf3Ia5/qI=; b=J/M9Gll9x12LUNmVO+k9e/UVfMpMN3R0umnwd7vudfW/KZkqmqnN8okoTl9mSnIzIv onkykBftHuE1FobaywLKof5hPn8Tv4iIN3wpR60O7x/b8Oulte5qEdAehvrPJiIEHOAq iARspExw59hj1KLjLGtdnwXYwwyCL0TcB/r7bxGbkT3dh6D+hgRJYLBY+MdLfnMXcNcB 11o0RGNcvObdvebye+IUP25p1hy5PzrZ16KYYDcxrfdvLEndgLpluOrEnlNNpATfQ0+1 ZtO2xN9Xf5QCSnfSromrj7PY4RgAEVfYEsZG84JdYMfQeGv1MY9xqjPdCWwVWo7k07ls MIjw== 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=BCnFCOiLS1X4qycQFE3nsyoQpV0xOJMHcCpf3Ia5/qI=; b=hJHRFn3iI7pdncXvlVNBs8YxRR3mEvM2FiahG4fFjKNhxI0lSmEfEVznUPq3PEKmtM YIUuhhFg3MlcFDyr1Dp9hvQOlsi+Y4oVBGW8DIGXmFLsgIEyQujXp2x+kBIGDwriSOQt Yu/qk97pFmQbJiqNNxKf4nKvhV0v8Fu1j0WzmjIie0lAz8vLASdkxStiFkxCNzCq0u5C 0H0oK8759rzmq4cEwxcbRZ8/SGplqYFcqzf6c45PFF4ja9BzgLXLXrux4uWN5uITPSYs Nx5ndYQIRb4RrniZN2wvYkEjIHta9ahvWj25xsDWzyrrTmNq1Fl1E0xQB0BCMwbD1gaF 5Nlw== X-Gm-Message-State: ALoCoQkpoFu0RtjiooKjbzACS7CwSI5vcOSNiiPQQHIcYcPxDfMWvYC483/p4CvBJDsyjAahZE7YgvevjTRl1DFo1g7jU/jA/tgZVta+CVuXj9D4W4Yo9d1GPL4GSB5gJVZKNi7dT1PCNBE+rA5uoOZtxA7rUy4Hd6S1g8Rbfm8hXgLSjOqpaRhjS4t++afmdD43FAlQD09y X-Received: by 10.42.67.130 with SMTP id t2mr6126499ici.17.1397016819923; Tue, 08 Apr 2014 21:13:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.136 with HTTP; Tue, 8 Apr 2014 21:13:19 -0700 (PDT) In-Reply-To: <7A01B3A7-84CB-42E3-BF78-90C0F24DE73A@cisco.com> References: <20140407211920.26125.99768.idtracker@ietfa.amsl.com> <1396905670.42588.YahooMailNeo@web162205.mail.bf1.yahoo.com> <7A01B3A7-84CB-42E3-BF78-90C0F24DE73A@cisco.com> From: Lorenzo Colitti Date: Wed, 9 Apr 2014 13:13:19 +0900 Message-ID: To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=20cf30334bfd4c1ca204f69453da Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ZDFfimCy1p4UoPLs6llRY0Ntn0c Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org>, V6 Ops List Subject: Re: [v6ops] draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.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: Wed, 09 Apr 2014 04:13:45 -0000 --20cf30334bfd4c1ca204f69453da Content-Type: text/plain; charset=UTF-8 On Wed, Apr 9, 2014 at 1:24 AM, Fred Baker (fred) wrote: > there is no point sending out a Solicited Node Multicast (the counterpart > to an ARP Broadcast) at L2 if nobody has joined the indicated group at L3. > I'd love for this to be usable, because it would also solve many of the debates regarding excessive multicast. Unfortunately, the usual counterarguments to this are: 1. MLDv2 state is not reliable. MLD messages are only sent out once and not acknowledged, and some implementations don't send them at all. Since failing to resolve a L3 address to a L2 address causes unrecoverable failure to communicate, basing ND on an unreliable protocol is a Bad Idea. Yes, you can always send out NSes as a fallback in case you have no MLD state for that address, but then you've just gone back to the DOS vulnerability you were trying to avoid. 2. If the router loses state, it won't know who is listening to what addresses. I suppose this could be solved by having the router send out an MLDv2 "general query" at boot, shortly after having sent its first periodic RA, but that has scaling limitations: if there are 5k hosts on-link, the router might well receive well over 10k packets (one for each autoconf address, and one for each stable-privacy or temporary address) will probably drop some of those packets, and then we're back to the reliability problem we had in #1. I don't know if these issues can be fixed. Cheers, Lorenzo --20cf30334bfd4c1ca204f69453da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 9, 2014 at 1:24 AM, Fred Baker (fred) <fred@cisco.com> = wrote:
there is no point sending out a Solicited No= de Multicast (the counterpart to an ARP Broadcast) at L2 if nobody has join= ed the indicated group at L3.

I'd love for this to be usable, becaus= e it would also solve many of the debates regarding excessive multicast. Un= fortunately, the usual counterarguments to this are:
  1. MLDv2 state is not reliable. MLD messages are only sent out once and not ac= knowledged, and some implementations don't send them at all. Since fail= ing to resolve a L3 address to a L2 address causes unrecoverable failure to= communicate, basing ND on an unreliable protocol is a Bad Idea. Yes, you c= an always send out NSes as a fallback in case you have no MLD state for tha= t address, but then you've just gone back to the DOS vulnerability you = were trying to avoid.
  2. If the router loses state, it won't know who is listening to w= hat addresses. I suppose this could be solved by having the router send out= an MLDv2 "general query" at boot, shortly after having sent its = first periodic RA, but that has scaling limitations: if there are 5k hosts = on-link, the router might well receive well over 10k packets (one for each = autoconf address, and one for each stable-privacy or temporary address) wil= l probably drop some of those packets, and then we're back to the relia= bility problem we had in #1.
I don't know if these issues can be fixed.
Cheers,
Lorenzo
--20cf30334bfd4c1ca204f69453da-- From nobody Tue Apr 8 23:31: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 E70721A0132 for ; Tue, 8 Apr 2014 23:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.772 X-Spam-Level: X-Spam-Status: No, score=-109.772 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.272, 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 xRc2oCta7y0N for ; Tue, 8 Apr 2014 23:30:57 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 960A71A0120 for ; Tue, 8 Apr 2014 23:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7264; q=dns/txt; s=iport; t=1397025056; x=1398234656; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5QEzsnLxbBqImu6RU2e9XYecraDhGnRj1XcYHiQJBNs=; b=PTnOSEVxvXACrzfFLZ1tr7mUBiSS6J0tw1rmt7PBa1t9ckqebBcHthBi xOt/o4sSi62w6oL/tqAA0vEDwxczfiNbRpCWfkNlXjQLsJdaSDOYzjPFk VhHf9ghneVPKWy2EQTdpQbaGUrdm+RDwoOAn3imFren8D3wt1G4RLokUy k=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFALroRFOtJA2E/2dsb2JhbABZgkJEO1fEOYEbFnSCJQEBAQMBRzIFCwIBCBguMiUCBA4FDodmCK0jnXgXjmwHgySBFASQYIE1hkiSQYMwgWkkHg X-IronPort-AV: E=Sophos;i="4.97,824,1389744000"; d="asc'?scan'208,217";a="34204548" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-7.cisco.com with ESMTP; 09 Apr 2014 06:30:53 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s396Usaf004682 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Apr 2014 06:30:54 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Wed, 9 Apr 2014 01:30:54 -0500 From: "Fred Baker (fred)" To: Lorenzo Colitti Thread-Topic: [v6ops] draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.txt Thread-Index: AQHPU71Bd6yqKpG8vkmkKqEPSYrOYw== Date: Wed, 9 Apr 2014 06:30:53 +0000 Message-ID: <9288C687-A64F-41FD-915D-8E2B6E176DCE@cisco.com> References: <20140407211920.26125.99768.idtracker@ietfa.amsl.com> <1396905670.42588.YahooMailNeo@web162205.mail.bf1.yahoo.com> <7A01B3A7-84CB-42E3-BF78-90C0F24DE73A@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.116] Content-Type: multipart/signed; boundary="Apple-Mail=_F82723AA-D49D-44E0-9F80-C9B3E0D82864"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mHdr8eYk-nC5LvjsYGcklUvIcQE Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org>, V6 Ops List Subject: Re: [v6ops] draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.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: Wed, 09 Apr 2014 06:31:00 -0000 --Apple-Mail=_F82723AA-D49D-44E0-9F80-C9B3E0D82864 Content-Type: multipart/alternative; boundary="Apple-Mail=_2A27F178-85F6-4766-9640-AA7F09F431F2" --Apple-Mail=_2A27F178-85F6-4766-9640-AA7F09F431F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 8, 2014, at 9:13 PM, Lorenzo Colitti wrote: > On Wed, Apr 9, 2014 at 1:24 AM, Fred Baker (fred) = wrote: > there is no point sending out a Solicited Node Multicast (the = counterpart to an ARP Broadcast) at L2 if nobody has joined the = indicated group at L3. >=20 > I'd love for this to be usable, because it would also solve many of = the debates regarding excessive multicast. Unfortunately, the usual = counterarguments to this are: > MLDv2 state is not reliable. MLD messages are only sent out once and = not acknowledged, and some implementations don't send them at all. Since = failing to resolve a L3 address to a L2 address causes unrecoverable = failure to communicate, basing ND on an unreliable protocol is a Bad = Idea. Yes, you can always send out NSes as a fallback in case you have = no MLD state for that address, but then you've just gone back to the DOS = vulnerability you were trying to avoid. > If the router loses state, it won't know who is listening to what = addresses. I suppose this could be solved by having the router send out = an MLDv2 "general query" at boot, shortly after having sent its first = periodic RA, but that has scaling limitations: if there are 5k hosts = on-link, the router might well receive well over 10k packets (one for = each autoconf address, and one for each stable-privacy or temporary = address) will probably drop some of those packets, and then we're back = to the reliability problem we had in #1. =46rom what I have been told internally, there are hosts that don=92t = make MLD =93Join=94 announcements, and those that do fire once and = forget. If the message doesn=92t get through, it doesn=92t get through. = One could send a request, but then every guy on the LAN responds, with = the exception o those that don=92t MLD. >=20 > I don't know if these issues can be fixed. >=20 > Cheers, > Lorenzo Make things as simple as possible, but not simpler. Albert Einstein --Apple-Mail=_2A27F178-85F6-4766-9640-AA7F09F431F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Apr 8, 2014, at 9:13 PM, Lorenzo = Colitti <lorenzo@google.com> = wrote:

On Wed, Apr 9, 2014 at 1:24 AM, Fred Baker (fred) = <fred@cisco.com> wrote:
there is no point = sending out a Solicited Node Multicast (the counterpart to an ARP = Broadcast) at L2 if nobody has joined the indicated group at L3.

I'd love for this to be usable, because = it would also solve many of the debates regarding excessive multicast. = Unfortunately, the usual counterarguments to this = are:
  1. MLDv2 state is not reliable. MLD messages are only sent out once and not = acknowledged, and some implementations don't send them at all. Since = failing to resolve a L3 address to a L2 address causes unrecoverable = failure to communicate, basing ND on an unreliable protocol is a Bad = Idea. Yes, you can always send out NSes as a fallback in case you have = no MLD state for that address, but then you've just gone back to the DOS = vulnerability you were trying to avoid.
  2. If the router loses state, it won't know who is listening to = what addresses. I suppose this could be solved by having the router send = out an MLDv2 "general query" at boot, shortly after having sent its = first periodic RA, but that has scaling limitations: if there are 5k = hosts on-link, the router might well receive well over 10k packets (one = for each autoconf address, and one for each stable-privacy or temporary = address) will probably drop some of those packets, and then we're back = to the reliability problem we had in = #1.

=46ro= m what I have been told internally, there are hosts that don=92t make = MLD =93Join=94 announcements, and those that do fire once and forget. If = the message doesn=92t get through, it doesn=92t get through. One could = send a request, but then every guy on the LAN responds, with the = exception o those that don=92t MLD.

I don't know if these issues can be = fixed.

Cheers,
Lorenzo

  • Make things as simple as possible, but = not simpler.
    • Albert Einstein

    = --Apple-Mail=_2A27F178-85F6-4766-9640-AA7F09F431F2-- --Apple-Mail=_F82723AA-D49D-44E0-9F80-C9B3E0D82864 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 iD8DBQFTROkcbjEdbHIsm0MRAmBXAKCAXH4nf9frsgmJMlnkkkwD9d7wGACgg4LZ lMJBYwixxGoOWu/ozUSxPKo= =BcFW -----END PGP SIGNATURE----- --Apple-Mail=_F82723AA-D49D-44E0-9F80-C9B3E0D82864-- From nobody Sun Apr 13 01:20: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 2C1481A0298 for ; Sun, 13 Apr 2014 01:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.312 X-Spam-Level: *** X-Spam-Status: No, score=3.312 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_REPLYTO=0.999, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 3mmLSUHlPZNi for ; Sun, 13 Apr 2014 01:20:06 -0700 (PDT) Received: from nm36.bullet.mail.ne1.yahoo.com (nm36.bullet.mail.ne1.yahoo.com [98.138.229.29]) by ietfa.amsl.com (Postfix) with ESMTP id 8056D1A0296 for ; Sun, 13 Apr 2014 01:20:04 -0700 (PDT) Received: from [127.0.0.1] by nm36.bullet.mail.ne1.yahoo.com with NNFMP; 13 Apr 2014 08:20:02 -0000 Received: from [98.138.226.178] by nm36.bullet.mail.ne1.yahoo.com with NNFMP; 13 Apr 2014 08:17:11 -0000 Received: from [98.139.215.141] by tm13.bullet.mail.ne1.yahoo.com with NNFMP; 13 Apr 2014 08:17:11 -0000 Received: from [98.139.212.204] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 13 Apr 2014 08:17:11 -0000 Received: from [127.0.0.1] by omp1013.mail.bf1.yahoo.com with NNFMP; 13 Apr 2014 08:17:11 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 690347.74085.bm@omp1013.mail.bf1.yahoo.com Received: (qmail 60152 invoked by uid 60001); 13 Apr 2014 08:17:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1397377031; bh=RDpeX1rVdZBvvLnDa2rX8JRDYT98isNJxyO2fyWtI/0=; 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=VwuW3oMgpKCPPzRNm+C1HXieQl54N8Lha9CYig6M6iT5T3iYKR3+31gWUFo85LI7BqpSq4uzqywfpCudQrxs7q0i5QG3WOuGcZuhNKE+m4CYtcTGJroGSM5Hw+w1TiOljY297qpX+Ab0hSW3gft+OsML8p5plgQUACLePbx8z6A= 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=tSXebQPPWfbO4qimMGPdsI2Ncpxxh4KPMEejLAvl+YKmfzSPpUW0WY9PYD0MUBppQPxgSLf/x9XVVduzolCBsWCMc/6RrycLcx65oC7GD7MixyK3sAh7jT01hP9tnd2G1cO/DYvXnqs3Phg4sw504Exab58YlMIr2N40zEJnvls=; X-YMail-OSG: dhSFImoVM1nBUS6Tc7uk_pxczgM.F9.2BcoHmFJjuJijd.P sAMCCyxz6Nm1k6MzeZ5KVDA.4rYej389XJ3LPHA1I57RbPXfomQxCCCzA.vg l14D50wDJKt1.iBQ_Btzj1ryPNLHHxlwzYmJ5S0ByF9MpwcdB1nxdZtaf8Mi EDdmvh.ix62RQtJfTOzt9RlOyVKJkGFhWTLxYtx27qHX5EWwGGpTiFkLHuV3 Y.luZ1LPXfY64DglTCypvG0PNpNZ8C1ioALq6RF7EHQeKQLnnGz68XoMtBc8 p1.g6zcKJ8HxY8nxynCU7krSktzyI_ZduzxGJ99OLPas6oLBmTkQy_h.qtY9 WlIBKuyWTGDuOmXvorKDw0Q9KsLYcgy3uWhmNJpFH.16oxces4OqUu2e8L6T ps837Sfcp19iH3u_F9wSC6QX1noNKieG4kdgIJardL_PGdOqbNkYWgcObV68 Y3O2uxxUQD01R764p6drJ4ol5C7qmtZmuhVD0KHUYzVVyhB9rTK4Bho0ZUi5 tB4tA4QCo_rkoiq4bnx5mLmakYjq_.TNPoPA9kbXDJjanda6Jw8kaT_zzKy_ qLHw- Received: from [150.101.221.237] by web162201.mail.bf1.yahoo.com via HTTP; Sun, 13 Apr 2014 01:17:11 PDT X-Rocket-MIMEInfo: 002.001, SGkgRnJlZCwKClRoYW5rcyBmb3IgeW91ciB0aW1lIGFuZCBjb21tZW50cy4KCgotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4gRnJvbTogRnJlZCBCYWtlciAoZnJlZCkgPGZyZWRAY2lzY28uY29tPgo.IFRvOiBNYXJrIFpaWiBTbWl0aCA8bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdT4KPiBDYzogVjYgT3BzIExpc3QgPHY2b3BzQGlldGYub3JnPjsgIjw2bWFuLWNoYWlyc0B0b29scy5pZXRmLm9yZz4iIDw2bWFuLWNoYWlyc0B0b29scy5pZXRmLm9yZz4KPiBTZW50OiBXZWRuZXNkYXksIDkgQXByaWwBMAEBAQE- X-Mailer: YahooMailWebService/0.8.182.648 References: <20140407211920.26125.99768.idtracker@ietfa.amsl.com> <1396905670.42588.YahooMailNeo@web162205.mail.bf1.yahoo.com> <7A01B3A7-84CB-42E3-BF78-90C0F24DE73A@cisco.com> Message-ID: <1397377031.23343.YahooMailNeo@web162201.mail.bf1.yahoo.com> Date: Sun, 13 Apr 2014 01:17:11 -0700 (PDT) From: Mark ZZZ Smith To: "Fred Baker \(fred\)" In-Reply-To: <7A01B3A7-84CB-42E3-BF78-90C0F24DE73A@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xfb4TfZPWS-lxNJJCR2nGXmJhFs Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org>, V6 Ops List Subject: Re: [v6ops] draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.txt 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, 13 Apr 2014 08:20:07 -0000 Hi Fred,=0A=0AThanks for your time and comments.=0A=0A=0A----- Original Mes= sage -----=0A> From: Fred Baker (fred) =0A> To: Mark ZZZ Sm= ith =0A> Cc: V6 Ops List ; "<6ma= n-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org>=0A> Sent: Wednesday,= 9 April 2014 2:24 AM=0A> Subject: draft-smith-v6ops-mitigate-rtr-dos-mld-s= lctd-node-00.txt=0A> =0A> I have several different thoughts on this. First = is to wonder whether it fits =0A> this forum; it might fit better in 6man o= r savi. I have copied the 6man chairs =0A> on this for their comment.=0A> = =0A> As I understand it on a quick read, you talk about how a Solicited Nod= e =0A> Multicast works, and point out that there is no point sending out a = Solicited =0A> Node Multicast (the counterpart to an ARP Broadcast) at L2 i= f nobody has joined =0A> the indicated group at L3. That=E2=80=99s a very i= nteresting observation, and worth =0A> considering.=0A>=C2=A0=0A=0AYes, tha= t is correct.=0A=0A> A corollary to that might be related to draft-ietf-sav= i-dhcp and/or RFC 6620; a =0A> SAVI switch configures filters to deny all t= raffic it doesn=E2=80=99t permit, and =0A> permits IPv6 traffic to be origi= nated from a given port if and only if it uses a =0A> source address that h= as been allocated to (DHCP) or DAD verified by (SLAAC) a =0A> device on the= port. One might similarly or additionally observe that a host that =0A> do= esn=E2=80=99t join the relevant multicast group cannot be reached by the ne= twork, and =0A> therefore should not be injecting traffic into the network,= making joining the =0A> SNM Group a condition of authorization to use the = network. =0A> =0A> What is the relationship between this and Optimistic ND?= RFC 4429. =0A>=C2=A0=0A=0AI haven't looked thoroughly at that yet, althoug= h there doesn't seem to be any mention of "MLD", "Solicited" or "Multicast"= , so I presume that it doesn't change any of the Solicited-Node multicast g= roup join/leave behaviour.=0A=0AOne thing to note is that this method would= not be using the Solicited-Node membership for tentative addresses, as tho= se MLD Reports are ignored by routers (identified by using the :: address a= s their source).=C2=A0=0A=0A> What are the operational considerations appro= priate to this?=0A> =0A=0ABroadly I don't think there really should be any,= as it is taking advantage of required behaviour of hosts when they have co= nfigured their address(es).=0A=0AThanks again,=0AMark.=0A From nobody Sun Apr 13 02:28: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 0F7ED1A02A9 for ; Sun, 13 Apr 2014 02:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.312 X-Spam-Level: *** X-Spam-Status: No, score=3.312 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_REPLYTO=0.999, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 YeQL1m_LfxRw for ; Sun, 13 Apr 2014 02:28:09 -0700 (PDT) Received: from nm45.bullet.mail.ne1.yahoo.com (nm45.bullet.mail.ne1.yahoo.com [98.138.120.52]) by ietfa.amsl.com (Postfix) with SMTP id 818011A02A8 for ; Sun, 13 Apr 2014 02:28:09 -0700 (PDT) Received: from [127.0.0.1] by nm45.bullet.mail.ne1.yahoo.com with NNFMP; 13 Apr 2014 09:28:07 -0000 Received: from [98.138.100.111] by nm45.bullet.mail.ne1.yahoo.com with NNFMP; 13 Apr 2014 09:25:21 -0000 Received: from [98.139.214.32] by tm100.bullet.mail.ne1.yahoo.com with NNFMP; 13 Apr 2014 09:25:21 -0000 Received: from [98.139.212.244] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 13 Apr 2014 09:25:21 -0000 Received: from [127.0.0.1] by omp1053.mail.bf1.yahoo.com with NNFMP; 13 Apr 2014 09:25:21 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 402957.32860.bm@omp1053.mail.bf1.yahoo.com Received: (qmail 92405 invoked by uid 60001); 13 Apr 2014 09:25:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1397381121; bh=jEaNTWJIu7cb8tlq4z4lKuQ61hTBCmIxaqu+jSHm/0E=; 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=eirvYa7FWU3Gdyv/qdAi9rqQJ64shVysQ6pnwUcDAQ4tOxs+twNwmzXbTtCno4IDwMLPOwBeXDJIblSRQltE79w2TKjIrADsa0BCoBtWx3Cr8Kp2t15FIjBTzg4A1MbgY+3fdsL+rzigWm472W0HDlSgCiT2NdB11ZUg2S9IM3M= 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=4MhWwm/TkN62vzxY6yo6WTCwmmruQTUIsRCVl+kuxRb8cD4480ldvYv71GeIVhdAtsuW2YM8+Wd4Q6zRDhgxFBEWlscyk8g4bJhTvSDGaE7D/e+h71IsTee4k0PtNnTQdzlZ6/+hGy3xC9dzKVH+xZxzR6SeDdqydAYifHwj7qw=; X-YMail-OSG: IDneeoQVM1mFHXAEspTL3YbDCurXys0dNIOp.mahU91NHT6 EBHGeT7TZVzBUJs7JF2kMkG3YAmExfRdLJHbz8NVAmk35U75qQJPqDcRWICQ S0QRKifGJI8U.VFXhkAQPv.pHgIVcm1pb4XV2DUD3lKdzalcoef7pSQtqVUB MqzifndTyD8kgRe8TvgA4Ip39o3WdQ437Z_s.wIi5FjluqUxz3bo2a_bZ9Y8 KwJHBAs8LTSiA5hS26eIAbZUVk_G24kQxLyZM76qx.HmGlTybDljRsFdubkU rMvIjQg7E4nKyBplTomU0ssCPRNBNGuoRdQBM.ccjMsR6rGQh4FqE2Na6yT. N3OyuxquvfCbTSRz3ZzSVNT_6u_VeQWsyjgI5t6Dtj3EoulnhcV5Mtb1O7h7 sO6SDhp6DL.UmCA4XRKF23gK.VL8s30Ans8OanwPC5DxeB3DkCLKRRZKaGEo oxIHufIgw9L38RjTRFhcQBekYVQfu64PtPie7c4_4.aKpBRCOtFpNo0QeZKs ZKgh3wK05dEM24SKzksiDvgEIBKU1wUvsnuCpOkM21zjC_oYGMCl020b0Abb oK2Uivw-- Received: from [150.101.221.237] by web162203.mail.bf1.yahoo.com via HTTP; Sun, 13 Apr 2014 02:25:21 PDT X-Rocket-MIMEInfo: 002.001, SGkgTG9yZW56bywKClRoYW5rcyBmb3IgeW91IHRpbWUgYW5kIGNvbW1lbnRzLgoKPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gRnJvbTogTG9yZW56byBDb2xpdHRpIDxsb3JlbnpvQGdvb2dsZS5jb20.Cj5UbzogRnJlZCBCYWtlciAoZnJlZCkgPGZyZWRAY2lzY28uY29tPiAKPkNjOiBNYXJrIFpaWiBTbWl0aCA8bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdT47ICI8Nm1hbi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc.IiA8Nm1hbi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc.OyBWNiBPcHMgTGlzdCABMAEBAQE- X-Mailer: YahooMailWebService/0.8.182.648 References: <20140407211920.26125.99768.idtracker@ietfa.amsl.com> <1396905670.42588.YahooMailNeo@web162205.mail.bf1.yahoo.com> <7A01B3A7-84CB-42E3-BF78-90C0F24DE73A@cisco.com> Message-ID: <1397381121.61502.YahooMailNeo@web162203.mail.bf1.yahoo.com> Date: Sun, 13 Apr 2014 02:25:21 -0700 (PDT) From: Mark ZZZ Smith To: Lorenzo Colitti , "Fred Baker \(fred\)" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/H3kmOsPXJvQ5R2hxrqeYNONrPNc Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org>, V6 Ops List Subject: Re: [v6ops] draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.txt 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, 13 Apr 2014 09:28:11 -0000 Hi Lorenzo,=0A=0AThanks for you time and comments.=0A=0A>__________________= ______________=0A> From: Lorenzo Colitti =0A>To: Fred B= aker (fred) =0A>Cc: Mark ZZZ Smith ; "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org>; V6 Ops L= ist =0A>Sent: Wednesday, 9 April 2014 2:13 PM=0A>Subject: = Re: [v6ops] draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.txt=0A> = =0A>=0A>=0A>On Wed, Apr 9, 2014 at 1:24 AM, Fred Baker (fred) wrote:=0A>=0A>there is no point sending out a Solicited Node Multicast = (the counterpart to an ARP Broadcast) at L2 if nobody has joined the indica= ted group at L3.=0A>>=0A>=0A>=0A>I'd love for this to be usable, because it= would also solve many of the debates regarding excessive multicast. Unfort= unately, the usual counterarguments to this are:=0A>=A0=A0=A0=A01. MLDv2 st= ate is not reliable. MLD messages are only sent out once and not acknowledg= ed,=0A=0AMy answer would be that if MLD isn't currently reliable enough for= this use, then it isn't currently reliable for any multicast application u= se, as the MLD procedures for Solicited-Node group membership are no differ= ent to those for any other multicast groups.=0A=0AI think that means work n= eeds to go into making MLD more reliable, or, alternatively, for those link= s for which it isn't reliable enough (I'm guessing people would be thinking= a busy wifi network), then treating the link as an RFC2491 IPv6 over NBMA = link would make the MLD procedures reliable.=0A=0A=0A> and some implementat= ions don't send them at all.=0A=0AI'd think they'd be classed as broken imp= lementations. I'm curious as to which implementations they are? I did some = rough testing before I wrote the I-D, and found that Linux/Android and IIRC= , Apple iOS devices do the right thing.=0A=0AIf those implementations don't= send MLD reports claim to implement MLDv1, then RFC2710 explicitly says th= at MLD messages are sent for Solicited-Node multicast addresses:=0A=0A"MLD = messages ARE sent for multicast addresses whose scope is 2 (link-local), in= cluding Solicited-Node multicast addresses [ADDR- ARCH], except for the lin= k-scope, all-nodes address (FF02::1)."=0A=0A=0AThat text was removed from M= LDv2 (RFC3810), however RFC4861 re-stated it:=0A=0A"The set of addresses as= signed to an interface may change over time. New addresses might be added a= nd old addresses might be removed [ADDRCONF].=A0 In such cases the node MUS= T join and leave the solicited-node multicast address corresponding to the = new and old addresses, respectively.=A0 Joining the solicited-node multicas= t address is done using a Multicast Listener Discovery such as [MLD] or [ML= Dv2] protocols.=A0 Note that multiple unicast addresses may map into the sa= me solicited-node multicast address; a node MUST NOT leave the solicited-no= de multicast group until all assigned addresses corresponding to that multi= cast address have been removed."=0A=0AI also looked at what RFC4890, "Recom= mendations for Filtering ICMPv6 Messages in Firewalls" said about filtering= of MLD messages, and it does not advise to filter them.=0A=0A=0AWith the a= ge of these requirements e.g. RFC2710 (1999), there has been plenty of time= for implementations to do the correct thing. I wonder how tolerant it is n= ecessary to be of implementations that don't follow requirements in specifi= cations?=0A=0AIn this case, I'd think the majority of implementations would= do the right thing, and for the implementations they don't, it would be be= tter to prevent them working at all than disable the protection this method= would provide to the correct implementations. IOW, reward and protect the = majority doing the right thing, penalise the minority that don't.=0A=0A(I t= hink it would be best that this measure is on by default, I could put some = text in the next revision to say that it must be possible to switch this mi= tigation method off if necessary to accommodate hosts that don't correctly = issue MLD join the Solicited-Node multicast group, if it isn't possible to = fix them.)=0A=0A=0A> Since failing to resolve a L3 address to a L2 address = causes unrecoverable failure to communicate, basing ND on an unreliable pro= tocol is a Bad Idea. Yes, you can always send out NSes as a fallback in cas= e you have no MLD state for that address, but then you've just gone back to= the DOS vulnerability you were trying to avoid.=0A>=0A=0AAgree.=0A=0A=0A>= =A0=A0=A0=A02. If the router loses state, it won't know who is listening to= what addresses. I suppose this could be solved by having the router send o= ut an MLDv2 "general query" at boot,=0A=0AMulticast routers should do exact= ly this when they bring up their interface, as part of the election of a Qu= erier, sending out multiple queries.=0A=0A> shortly after having sent its f= irst periodic RA, but that has scaling limitations: if there are 5k hosts o= n-link, the router might well receive well over 10k packets (one for each a= utoconf address, and one for each stable-privacy or temporary address) will= probably drop some of those packets, and then we're back to the reliabilit= y problem we had in #1.=0A>=0A=0AMLD has measures in it to spread responses= to Queries out over a time period specified in the query (Maximum Responde= Delay).=0A=0A=0AMore generally, I've noticed that these sorts of more extr= eme and corner cases are starting to be used to dismiss solutions that woul= d work for the common cases. That's not to say that some people aren't buil= ding them, but I wonder if that means that if people want to build them, th= ey need to stop expecting protocols and methods that work for common cases = (such as 100s of hosts, or perhaps low 1000) to scale up well beyond what w= as likely to be the original design requirement.=0A=0AI wonder if the large= IPv6 address space in a /64 subnet is inadvertently setting an incorrect e= xpectation that IPv6 subnets can have many orders of magnitude more hosts a= ttached than the equivalent IPv4 subnets, and that the protocols to support= link operation, such as RAs, ND and MLD have also been designed to scale t= hat large.=0A=0AActually, I understand the use of Solicited-Node multicast = groups and MLD messages for use by snooping switches, instead of link-layer= broadcasts i.e., IPv4 ARPs, is to allow the number of hosts on a link to b= e increased. So if MLD is failing to be reliable, and therefore IPv6 NSes a= re being flooded to all hosts, perhaps that is a or another sign that the l= ink-layer has too many hosts attached to it, and it needs to be partitioned= .=0A=0A=0AThanks very much,=0AMark.=0A=0A=0A=0A=0A>I don't know if these is= sues can be fixed.=0A>=0A=0A=0A=0A>=0A>Cheers,=0A>Lorenzo=0A>=0A> From nobody Sun Apr 13 20:37: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 770111A0325 for ; Sun, 13 Apr 2014 20:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.05 X-Spam-Level: * X-Spam-Status: No, score=1.05 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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.272, 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 edRHZ286NSCw for ; Sun, 13 Apr 2014 20:37:42 -0700 (PDT) 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 B53601A0324 for ; Sun, 13 Apr 2014 20:37:42 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id rp18so7654144iec.33 for ; Sun, 13 Apr 2014 20:37:40 -0700 (PDT) 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=lY4hahhoBkwnRMyDXpzTu6ylcY8h3bknnMCChshL4hk=; b=UX7nxcHMRf1T5mSjoIoYVz1AVmfuE83yvEc15y22sBmUvD5q5DsidRysQsbBJPhWox esc/nh9mUjIKC7B1U1Qw6NYDow4RUF4wjotPEqlaA6x3lX+BEGJVuSIbUd/5IxBZzv3T AvPcWXKOgEB7wW4G+PFeBbakR5TWo3No3r60kLHaX3ikxVIN1DCVFTIQZBCyYOrGxIh6 sj+2QE+Ue/QOXxpbWUa0woUa8ZzyZEaBYPbI2B17ryizYSGUwC3Ebo4CwlXxrokwaffn BM8WvE5IEQMlUB5RpxRZjX/kKCfGuW7eQCYP8bXdAhYRwgFHJ+00sxCMxq1z3b2anFT8 t9eA== 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=lY4hahhoBkwnRMyDXpzTu6ylcY8h3bknnMCChshL4hk=; b=WmFt05x7n4vRcPGaF45rz858Ta74hKTtoTiuGD05ucyuMuiq50TjjBHxK5NNGm+6W9 9AUTokui/64/3K8nUZquazdyfUgpZC9l0jd18H0i1KoV6vCHfwKi8ih6VO1L4TiVxjky v6+P2YI8NTaYmd01eCfTJqqtsL4OD2q41Xr9IeI8mSiTZP/WGqkp+8sxIaxq8anS755x 7bCzwLOEHp162xtz8ly8/EEi4izqSxKCUJEsOpF0GCKxyZ/SvwhcEGsjh+4IJf1S+UId SKnLYd3gFSRGSmhBdYO5s6GpkFYtUoio26UBUZl5unntVYmK5wnkNIbXwB7neWFJkOUh jq3Q== X-Gm-Message-State: ALoCoQnQhKaNl+tIp2KtNByWQ6llil51Deo1FPZhn6mbghU7Ubbk0IuCCm8gkS72degnhi6jphnjrmjve3sbcl1uAB4qMoONwbm9Wi1sIV5Sa+7GmO8YkR8JKMB9rC1e7xQCjmtyvS7bjiEEHvUreRxB1SHRYsr6DxAEN5Y6AhnuI4YvivmfA85mgVl4BIirXVM14pGYBXCT X-Received: by 10.50.22.69 with SMTP id b5mr13343240igf.45.1397446660178; Sun, 13 Apr 2014 20:37:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.136 with HTTP; Sun, 13 Apr 2014 20:37:20 -0700 (PDT) In-Reply-To: <1397381121.61502.YahooMailNeo@web162203.mail.bf1.yahoo.com> References: <20140407211920.26125.99768.idtracker@ietfa.amsl.com> <1396905670.42588.YahooMailNeo@web162205.mail.bf1.yahoo.com> <7A01B3A7-84CB-42E3-BF78-90C0F24DE73A@cisco.com> <1397381121.61502.YahooMailNeo@web162203.mail.bf1.yahoo.com> From: Lorenzo Colitti Date: Mon, 14 Apr 2014 12:37:20 +0900 Message-ID: To: Mark ZZZ Smith Content-Type: multipart/alternative; boundary=047d7b10ceddc5e55d04f6f867a3 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5CkYrJjtNuP2s9vW8CNg30rs-sU Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org>, V6 Ops List Subject: Re: [v6ops] draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.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, 14 Apr 2014 03:37:44 -0000 --047d7b10ceddc5e55d04f6f867a3 Content-Type: text/plain; charset=UTF-8 On Sun, Apr 13, 2014 at 6:25 PM, Mark ZZZ Smith wrote: > > 1. MLDv2 state is not reliable. MLD messages are only sent out once > and not acknowledged, > > My answer would be that if MLD isn't currently reliable enough for this > use, then it isn't currently reliable for any multicast application use, as > the MLD procedures for Solicited-Node group membership are no different to > those for any other multicast groups. > > I think that means work needs to go into making MLD more reliable, or, > alternatively, for those links for which it isn't reliable enough (I'm > guessing people would be thinking a busy wifi network), then treating the > link as an RFC2491 IPv6 over NBMA link would make the MLD procedures > reliable. > All I'm saying is that the document should determine and very clearly document the reliability of what it is proposing. Perhaps there's something I'm missing, but it seems to me that if for whatever reason the router misses the MLD join for an IP address, then no packets can be sent to that IP address, ever - or at least until the host leaves and joins again. It seems to me that regardless of whether the link-layer is a busy wifi network or a gold-plated fiber network, making usability of an IP address completely contingent on one unacknowledged packet sent at the beginning of its lifecycle won't work in many networks. Packets get lost. CPUs get overwhelmed. Cables blip when people touch them. "Make MLD more reliable" is a non-trivial exercise, and it won't help current implementations. "Treat the link as NBMA" might work (I don't know anything about it), but if so, then it needs to be clearly stated that this requires fundamentally changing the subnet model. > More generally, I've noticed that these sorts of more extreme and corner > cases are starting to be used to dismiss solutions that would work for the > common cases. That's not to say that some people aren't building them, but > I wonder if that means that if people want to build them, they need to stop > expecting protocols and methods that work for common cases (such as 100s of > hosts, or perhaps low 1000) to scale up well beyond what was likely to be > the original design requirement. > > I wonder if the large IPv6 address space in a /64 subnet is inadvertently > setting an incorrect expectation that IPv6 subnets can have many orders of > magnitude more hosts attached than the equivalent IPv4 subnets, and that > the protocols to support link operation, such as RAs, ND and MLD have also > been designed to scale that large. > Well, but to be fair, it would be nice to allow that sort of scalability. > Actually, I understand the use of Solicited-Node multicast groups and MLD > messages for use by snooping switches, instead of link-layer broadcasts > i.e., IPv4 ARPs, is to allow the number of hosts on a link to be increased. > So if MLD is failing to be reliable, and therefore IPv6 NSes are being > flooded to all hosts, perhaps that is a or another sign that the link-layer > has too many hosts attached to it, and it needs to be partitioned. > To some extent what you say is true - ND is much more efficient than broadcast ARP. The problem with comparing ND to ARP based on the protocols themselves is that today, at least in many networks, ARP is not a ARP any more. The packet format is the same, but it's not a broadcast. The host might send out a broadcast, but that's dropped and, depending on how many layering violations are being performed, the first-hop router or the AP reply unicast from their ARP cache, or, again depending on how many layering violations are being performed, from the DHCP lease database. So today people are building IPv4 wireless networks with 10k clients and /16 subnets of RFC1918 space. If plain ARP were in use such a network would melt down instantly, but since ARP requests are proxied by the AP, things "work" - sort of. --047d7b10ceddc5e55d04f6f867a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On S= un, Apr 13, 2014 at 6:25 PM, Mark ZZZ Smith <markzzzsmith@yahoo.= com.au> wrote:
    >=C2=A0=C2=A0=C2=A0=C2=A01. MLDv2 state is not rel= iable. MLD messages are only sent out once and not acknowledged,

    My answer would be that if MLD isn't currently reliable enough for this= use, then it isn't currently reliable for any multicast application us= e, as the MLD procedures for Solicited-Node group membership are no differe= nt to those for any other multicast groups.

    I think that means work needs to go into making MLD more reliable, or, alte= rnatively, for those links for which it isn't reliable enough (I'm = guessing people would be thinking a busy wifi network), then treating the l= ink as an RFC2491 IPv6 over NBMA link would make the MLD procedures reliabl= e.

    All I'm saying is that the document sh= ould determine and very clearly document the reliability of what it is prop= osing. Perhaps there's something I'm missing, but it seems to me th= at if for whatever reason the router misses the MLD join for an IP address,= then no packets can be sent to that IP address, ever - or at least until t= he host leaves and joins again.

    It seems to me that regardless of whether the link-laye= r is a busy wifi network or a gold-plated fiber network, making usability o= f an IP address completely contingent on one unacknowledged packet sent at = the beginning of its lifecycle won't work in many networks. Packets get= lost. CPUs get overwhelmed. Cables blip when people touch them.

    "Make MLD more reliable" is a non-trivial exe= rcise, and it won't help current implementations. "Treat the link = as NBMA" might work (I don't know anything about it), but if so, t= hen it needs to be clearly stated that this requires fundamentally changing= the subnet model.
    =C2=A0
    More generally, I've noticed that these sorts of more extreme and = corner cases are starting to be used to dismiss solutions that would work f= or the common cases. That's not to say that some people aren't buil= ding them, but I wonder if that means that if people want to build them, th= ey need to stop expecting protocols and methods that work for common cases = (such as 100s of hosts, or perhaps low 1000) to scale up well beyond what w= as likely to be the original design requirement.

    I wonder if the large IPv6 address space in a /64 subnet is inadvertently s= etting an incorrect expectation that IPv6 subnets can have many orders of m= agnitude more hosts attached than the equivalent IPv4 subnets, and that the= protocols to support link operation, such as RAs, ND and MLD have also bee= n designed to scale that large.

    Well, but to be fair, it would be nice to = allow that sort of scalability.
    =C2=A0
    Actually, I understand the use of Solicited-Node multicast groups and MLD m= essages for use by snooping switches, instead of link-layer broadcasts i.e.= , IPv4 ARPs, is to allow the number of hosts on a link to be increased. So = if MLD is failing to be reliable, and therefore IPv6 NSes are being flooded= to all hosts, perhaps that is a or another sign that the link-layer has to= o many hosts attached to it, and it needs to be partitioned.

    To some extent what you say is true - ND i= s much more efficient than broadcast ARP.

    The prob= lem with comparing ND to ARP based on the protocols themselves is that toda= y, at least in many networks, ARP is not a ARP any more. The packet format = is the same, but it's not a broadcast. The host might send out a broadc= ast, but that's dropped and, depending on how many layering violations = are being performed, the first-hop router or the AP reply unicast from thei= r ARP cache, or, again depending on how many layering violations are being = performed, from the DHCP lease database.

    So today people are building IPv4 wireless networks wit= h 10k clients and /16 subnets of RFC1918 space. If plain ARP were in use su= ch a network would melt down instantly, but since ARP requests are proxied = by the AP, things "work" - sort of.
    --047d7b10ceddc5e55d04f6f867a3-- From nobody Mon Apr 14 07:50: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 516061A04A6 for ; Mon, 14 Apr 2014 07:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 219XPFgKzrQl for ; Mon, 14 Apr 2014 07:50:21 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 61FA11A0476 for ; Mon, 14 Apr 2014 07:50:16 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D07F5403FF for ; Mon, 14 Apr 2014 10:50:13 -0400 (EDT) Message-ID: <534BF5A5.5010609@viagenie.ca> Date: Mon, 14 Apr 2014 10:50:13 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: v6ops@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ojTKUGbAqheD0XXCeOOMSaGzvsw Subject: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 14:50:27 -0000 Dearest V6OPS, We are soliciting reviews for this SUNSET4 draft: http://tools.ietf.org/html/draft-ietf-sunset4-noipv4-00 In a nutshell, it defines DHCPv6 and RA options indicating to the host that IPv4 is not available. Reviews from operations-minded people in V6OPS would be of tremendous help. Thanks, 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 nobody Mon Apr 14 08:08: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 5D8931A049D for ; Mon, 14 Apr 2014 08:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 gScpp1CPmW1E for ; Mon, 14 Apr 2014 08:08:46 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1E61A04B8 for ; Mon, 14 Apr 2014 08:08:46 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.dyn.netability.ie (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s3EF8gTL076871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 14 Apr 2014 16:08:42 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.dyn.netability.ie Message-ID: <534BFA08.3030404@foobar.org> Date: Mon, 14 Apr 2014 16:08:56 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Simon Perreault , v6ops@ietf.org References: <534BF5A5.5010609@viagenie.ca> In-Reply-To: <534BF5A5.5010609@viagenie.ca> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/tLNx0B9ELj-7b_hkkXV_1VT5MDY Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 15:08:49 -0000 On 14/04/2014 15:50, Simon Perreault wrote: > In a nutshell, it defines DHCPv6 and RA options indicating to the host > that IPv4 is not available. Reviews from operations-minded people in > V6OPS would be of tremendous help. I'm puzzled as to why these options should go into dhcpv6. Would dhcpv4 not be a much more sensible place to put them? Putting them into dhcpv6 is a very peculiar layering violation. Creating a "No Service" option in DHCPv4 would be a more natural solution to this problem which wouldn't involve layering violations or peculiar inter-DHCP protocol hacks, and would only require modifying a single daemon to implement it rather than creating a requirement for kernel level hacks on multiple daemons. Nick From nobody Mon Apr 14 08:12: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 81BD31A04E7 for ; Mon, 14 Apr 2014 08:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 lgOnwVPjxoKI for ; Mon, 14 Apr 2014 08:12:00 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0AA1A04B6 for ; Mon, 14 Apr 2014 08:12:00 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7A8BB403FF; Mon, 14 Apr 2014 11:11:57 -0400 (EDT) Message-ID: <534BFABD.500@viagenie.ca> Date: Mon, 14 Apr 2014 11:11:57 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Nick Hilliard , v6ops@ietf.org References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> In-Reply-To: <534BFA08.3030404@foobar.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/vcFjxt5k6FcR6L--LSZivS-kRzQ Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 15:12:01 -0000 Le 2014-04-14 11:08, Nick Hilliard a écrit : > On 14/04/2014 15:50, Simon Perreault wrote: >> In a nutshell, it defines DHCPv6 and RA options indicating to the host >> that IPv4 is not available. Reviews from operations-minded people in >> V6OPS would be of tremendous help. > > I'm puzzled as to why these options should go into dhcpv6. Would dhcpv4 > not be a much more sensible place to put them? Putting them into dhcpv6 is > a very peculiar layering violation. This is a comment that has already been made. It is addressed in section 4.1. Did you find the analysis unconvincing? Thanks, 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 nobody Mon Apr 14 08:44: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 0AA951A048A for ; Mon, 14 Apr 2014 08:44:34 -0700 (PDT) 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 COOyHlvXQ-Dv for ; Mon, 14 Apr 2014 08:44:32 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 568F01A049A for ; Mon, 14 Apr 2014 08:44:32 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.dyn.netability.ie (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s3EFiSdK077035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 14 Apr 2014 16:44:28 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.dyn.netability.ie Message-ID: <534C026A.4070105@foobar.org> Date: Mon, 14 Apr 2014 16:44:42 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Simon Perreault , v6ops@ietf.org References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <534BFABD.500@viagenie.ca> In-Reply-To: <534BFABD.500@viagenie.ca> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/zyIH7FZJTIF3-Rz3wm2AbZsx5TA Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 15:44:34 -0000 On 14/04/2014 16:11, Simon Perreault wrote: > This is a comment that has already been made. It is addressed in section > 4.1. Did you find the analysis unconvincing? unfortunately, yes. Taking the points in order: 4.1.1.1: "Devices that haven't been updated to speak IPv6 likely won't recognize a new DHCPv4 code telling them that IPv4 isn't supported." This is a circular argument which is a bit pointless. 4.1.2 "Devices that don't speak IPv6...": this is not relevant. 4.1.3: maintaining ipv4 infrastructure: this is reasonable, but there are relatively simple workarounds with not much overhead (dhcp relays). 4.1.4: no way back: a DHCPv4 option can be enabled with a timeout. Similarly, you could argue that there's no way back with any DHCP option because you can set an option timeout to be unfeasibly large for anything. But we regard this as an operational or configuration error, not a protocol problem. Anyway, most PE access device operators will have some back-door means of forcing a DHCP retry, e.g. forced line / carrier / tunnel drops, etc. Here are some reasons why No Service would be better served over DHCPv4: 0. this is a protocol layering violation, plain and simple. From an architectural point of view, a v6 service should not provide signalling for a v4 service or vice versa. 1. You need a protocol to allow the the DHCPv6 client to attempt to communicate with the DHCPv4 client on the end host. E.g. how do you get the dibbler v6 client to tell ISC ipv4 dhclient to stop issuing DHCP requests? Unless there's a standardised mechanism for doing this, the draft will not solve the problem you're trying to solve because the DHCPv4 and DHCPv6 clients may be different code trains from different vendors. 2. It would be necessary to implement this for both DHCPv4 and RA. If it's in the RA spec, then this will mean that some implementations will need to have more kernel code to handle a user-space problem. This is not sensible. 3. it would be trivially easy to implement a No Service option for dhcpv4. As a separate issue, you may want to put in a time-out field into the protocol with all-zeros or all-ones meaning infinite timeout. Nick From nobody Mon Apr 14 08:57: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 BB9ED1A04AE for ; Mon, 14 Apr 2014 08:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 RImUQY7J9w-Z for ; Mon, 14 Apr 2014 08:57:36 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 386D01A04A7 for ; Mon, 14 Apr 2014 08:57:36 -0700 (PDT) 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 0E6581B805A for ; Mon, 14 Apr 2014 08:57:34 -0700 (PDT) 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 07CAB19005C; Mon, 14 Apr 2014 08:57:34 -0700 (PDT) Received: from [192.168.146.119] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 14 Apr 2014 08:57:33 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <534BFA08.3030404@foobar.org> Date: Mon, 14 Apr 2014 10:57:34 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/GMGS1o7Qx__ogbaTcLkSTzmEK2c Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 15:57:37 -0000 On Apr 14, 2014, at 10:08 AM, Nick Hilliard wrote: > I'm puzzled as to why these options should go into dhcpv6. Would = dhcpv4 > not be a much more sensible place to put them? Putting them into = dhcpv6 is > a very peculiar layering violation. How is it a layering violation? And if you don't have IPv4, how do you = have DHCPv4? From nobody Mon Apr 14 09:08: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 661EE1A059F for ; Mon, 14 Apr 2014 09:08:35 -0700 (PDT) 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 IHii_14OMZNg for ; Mon, 14 Apr 2014 09:08:32 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id E7FEE1A05D3 for ; Mon, 14 Apr 2014 09:08:16 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.dyn.netability.ie (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s3EG8DfQ077358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 14 Apr 2014 17:08:13 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.dyn.netability.ie Message-ID: <534C07FC.8000907@foobar.org> Date: Mon, 14 Apr 2014 17:08:28 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ted Lemon References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> In-Reply-To: <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/gYgvXlqd6wwo_P_N-QrGa-h0yxs Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 16:08:35 -0000 On 14/04/2014 16:57, Ted Lemon wrote: > How is it a layering violation? because you're using one protocol stack to send signals about another protocol stack. "layering violation" is possibly the wrong term. Maybe "protocol bleed" or some > And if you don't have IPv4, how do you have DHCPv4? this is the thing: the whole proposal is a bit circular. If there's no DHCPv4 server, argument 3.1 is irrelevant and argument 3.2 is almost irrelevant because on any shared access medium, dhcp traffic which is ignored is not going to make up significant amounts of traffic. There's some justification for 3.3 but that can be dealt with on e.g. radio devices by coalescing requests so that control request like this / RA / etc are send alongside each other. 3.4 is an application level problem and it's not the job of the ietf to fix stupid / broken applications. If there is a dhcpv4 server in place (even a local stub server), then bingo: create a No Service option and the problem disappears. Nick From nobody Mon Apr 14 09:08: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 A2BD11A055D for ; Mon, 14 Apr 2014 09:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.263 X-Spam-Level: X-Spam-Status: No, score=-1.263 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.272, 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 MeHIq3vAnpVi for ; Mon, 14 Apr 2014 09:08:50 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 68B081A05C3 for ; Mon, 14 Apr 2014 09:08:50 -0700 (PDT) Received: from owens-mbp.meeting.arin.net (unknown.servercentral.net [50.31.214.180] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s3EG6HPl020519 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 09:06:18 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3EG6HPl020519 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1397491579; bh=oofiAeM8eUBGexR6kzDDWSEwaZg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=NtSes85EtlXblgun2cCzfMf7FoEzTSjyK3Tsu0n1ZyUJDcFuzfnJ0cpyNPXv0rNl1 747hXAARW6KqmDVQfCrtwPsmuMttjt13RRWRQ8yKBUfWZuTXMsKIYve4u2g+L8O+bh uhGwap4sezV0RcY1U9AjWodEAxImYTJZ7E72TiWg= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: <534C026A.4070105@foobar.org> Date: Mon, 14 Apr 2014 09:06:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <07CFFBBE-BF72-4098-B452-77492DFDF063@delong.com> References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <534BFABD.500@viagenie.ca> <534C026A.4070105@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 14 Apr 2014 09:06:19 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/14Ss6_RcO3nY_RcEQaP0qcjheiM Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 16:08:54 -0000 I agree with NIck=92s position. This should be addressed as a DHCPv4 = option rather than in DHCPv6. Owen On Apr 14, 2014, at 8:44 AM, Nick Hilliard wrote: > On 14/04/2014 16:11, Simon Perreault wrote: >> This is a comment that has already been made. It is addressed in = section >> 4.1. Did you find the analysis unconvincing? >=20 > unfortunately, yes. Taking the points in order: >=20 > 4.1.1.1: "Devices that haven't been updated to speak IPv6 likely won't > recognize a new DHCPv4 code telling them that IPv4 isn't supported." = This > is a circular argument which is a bit pointless. >=20 > 4.1.2 "Devices that don't speak IPv6...": this is not relevant. >=20 > 4.1.3: maintaining ipv4 infrastructure: this is reasonable, but there = are > relatively simple workarounds with not much overhead (dhcp relays). >=20 > 4.1.4: no way back: a DHCPv4 option can be enabled with a timeout. > Similarly, you could argue that there's no way back with any DHCP = option > because you can set an option timeout to be unfeasibly large for = anything. > But we regard this as an operational or configuration error, not a > protocol problem. Anyway, most PE access device operators will have = some > back-door means of forcing a DHCP retry, e.g. forced line / carrier / > tunnel drops, etc. >=20 > Here are some reasons why No Service would be better served over = DHCPv4: >=20 > 0. this is a protocol layering violation, plain and simple. =46rom = an > architectural point of view, a v6 service should not provide = signalling for > a v4 service or vice versa. >=20 > 1. You need a protocol to allow the the DHCPv6 client to attempt to > communicate with the DHCPv4 client on the end host. E.g. how do you = get > the dibbler v6 client to tell ISC ipv4 dhclient to stop issuing DHCP > requests? Unless there's a standardised mechanism for doing this, the > draft will not solve the problem you're trying to solve because the = DHCPv4 > and DHCPv6 clients may be different code trains from different = vendors. >=20 > 2. It would be necessary to implement this for both DHCPv4 and RA. If = it's > in the RA spec, then this will mean that some implementations will = need to > have more kernel code to handle a user-space problem. This is not = sensible. >=20 > 3. it would be trivially easy to implement a No Service option for = dhcpv4. >=20 > As a separate issue, you may want to put in a time-out field into the > protocol with all-zeros or all-ones meaning infinite timeout. >=20 > Nick >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Apr 14 09:36: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 6F4541A0681 for ; Mon, 14 Apr 2014 09:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 IeId8NdrKfHb for ; Mon, 14 Apr 2014 09:36:50 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 04A301A0688 for ; Mon, 14 Apr 2014 09:36:50 -0700 (PDT) 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 CE0381B805A for ; Mon, 14 Apr 2014 09:36:47 -0700 (PDT) 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 C759619005C; Mon, 14 Apr 2014 09:36:47 -0700 (PDT) Received: from [192.168.146.119] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 14 Apr 2014 09:36:47 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <534C07FC.8000907@foobar.org> Date: Mon, 14 Apr 2014 11:36:46 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/hIV-vhesAdFtXB-kMuyg46TaZqE Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 16:36:55 -0000 On Apr 14, 2014, at 11:08 AM, Nick Hilliard wrote: > because you're using one protocol stack to send signals about another > protocol stack. "layering violation" is possibly the wrong term. = Maybe > "protocol bleed" or some There is no such thing, and this isn't a valid distinction, at least = according to current practice. This is like saying that an HTTP server = that runs over IPv6 can't redirect to a URL that would be fetched over = IPv4, or that you can't do a DNS query for a AAAA record over IPv4, or = an A record over IPv6. >> And if you don't have IPv4, how do you have DHCPv4? >=20 > this is the thing: the whole proposal is a bit circular. If there's no > DHCPv4 server, argument 3.1 is irrelevant and argument 3.2 is almost > irrelevant because on any shared access medium, dhcp traffic which is > ignored is not going to make up significant amounts of traffic. = There's > some justification for 3.3 but that can be dealt with on e.g. radio = devices > by coalescing requests so that control request like this / RA / etc = are > send alongside each other. 3.4 is an application level problem and = it's > not the job of the ietf to fix stupid / broken applications. It's broadcast traffic, which is expensive for everyone sharing a Wifi = AP. If every host is doing it, that's a lot of traffic. Also, if I get a DHCPDISCOVER, and response with a DHCPOFFER with this = option, is the expectation that the client will shut down at that point? = That's a substantial protocol change, if so. If we're going all the = way to DHCPACK, now the client has an IP address. What if it tries to = use it? Only a client that's IPv6-capable is ever going to act on this option, = so doing it with DHCPv4 doesn't really make sense. From nobody Mon Apr 14 09:54: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 8F3A31A0656 for ; Mon, 14 Apr 2014 09:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.263 X-Spam-Level: X-Spam-Status: No, score=-1.263 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.272, 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 m06brWTstwAc for ; Mon, 14 Apr 2014 09:53:55 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id EFC151A01FA for ; Mon, 14 Apr 2014 09:53:54 -0700 (PDT) Received: from owens-mbp.meeting.arin.net (unknown.servercentral.net [50.31.214.180] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s3EGnFNf022371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 09:49:17 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3EGnFNf022371 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1397494158; bh=XjArKmVRYzS6ju8Lpk571MIpb4s=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=vlIjVK62heMT3Xvjl8ItNF3mbfoalOudv7Dg+J0vncBfXr08NsFK1f/czENF9Su16 u+QxNEMEApbhMOCLUsTKubExTJGvkEk5QJt0w8UN0ltArPDYsP9NZU9NpctQrtc6pc oABTW8rr2iiDDvUC4jKT0p557dUERM+gE/taHELA= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: Date: Mon, 14 Apr 2014 09:49:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> To: Ted Lemon X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 14 Apr 2014 09:49:18 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/si6tEPHiTUSr46aVl9HLSPXaUgw Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 16:53:59 -0000 On Apr 14, 2014, at 9:36 AM, Ted Lemon wrote: > On Apr 14, 2014, at 11:08 AM, Nick Hilliard wrote: >> because you're using one protocol stack to send signals about another >> protocol stack. "layering violation" is possibly the wrong term. = Maybe >> "protocol bleed" or some >=20 > There is no such thing, and this isn't a valid distinction, at least = according to current practice. This is like saying that an HTTP server = that runs over IPv6 can't redirect to a URL that would be fetched over = IPv4, or that you can't do a DNS query for a AAAA record over IPv4, or = an A record over IPv6. Not really=85 An HTTP server shouldn=92t be redirecting to an IP address at all. It = should be redirecting via name. Since the address family that the name = resolves to is opaque, a name is just a name. Similarly, DNS is a database query, not a protocol signaling for = configuration purposes. What is being proposed here would be more like responding to an IPv4 = packet with an ICMP6 unreachable, which I=92m pretty sure would be = considered problematic. >>> And if you don't have IPv4, how do you have DHCPv4? >>=20 >> this is the thing: the whole proposal is a bit circular. If there's = no >> DHCPv4 server, argument 3.1 is irrelevant and argument 3.2 is almost >> irrelevant because on any shared access medium, dhcp traffic which is >> ignored is not going to make up significant amounts of traffic. = There's >> some justification for 3.3 but that can be dealt with on e.g. radio = devices >> by coalescing requests so that control request like this / RA / etc = are >> send alongside each other. 3.4 is an application level problem and = it's >> not the job of the ietf to fix stupid / broken applications. >=20 > It's broadcast traffic, which is expensive for everyone sharing a Wifi = AP. If every host is doing it, that's a lot of traffic. Sure, so adding a form of NACK or DHCP-UNREACHABLE message to IPv4 makes = sense to me. > Also, if I get a DHCPDISCOVER, and response with a DHCPOFFER with this = option, is the expectation that the client will shut down at that point? = That's a substantial protocol change, if so. If we're going all the = way to DHCPACK, now the client has an IP address. What if it tries to = use it? Why not, instead of using a DCHCPOFFER, provide an ICMPv4 = DHCP-UNAVAILABLE message which can be sent in response to a DHCPREQUEST = message by any router which is configured to authoritatively deny DHCPv4 = on the link? A host receiving such a message should be expected to = behave in an identical manner to the behavior proposed in this draft. > Only a client that's IPv6-capable is ever going to act on this option, = so doing it with DHCPv4 doesn't really make sense. Only a client that=92s going to try DHCPv4 is ever going to act on this = option, so doing it in DHCPv6 doesn=92t really make sense. Owen From nobody Mon Apr 14 10:15: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 6CD0A1A068F for ; Mon, 14 Apr 2014 10:15:30 -0700 (PDT) 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 s_YY28B-99nE for ; Mon, 14 Apr 2014 10:15:28 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 766E71A068E for ; Mon, 14 Apr 2014 10:15:27 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.dyn.netability.ie (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s3EHFKO9077991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 14 Apr 2014 18:15:21 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.dyn.netability.ie Message-ID: <534C17B8.8030209@foobar.org> Date: Mon, 14 Apr 2014 18:15:36 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ted Lemon References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/rhHgrlNBjRgctUtc4-sa-zM8NJE Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 17:15:30 -0000 On 14/04/2014 17:36, Ted Lemon wrote: > Also, if I get a DHCPDISCOVER, and response with a DHCPOFFER with this > option, is the expectation that the client will shut down at that point? > That's a substantial protocol change, if so. Stepping back a moment, the alternatives are: 1. wiring both dhcpv6 and ra to include an ipv4 protocol option, and then designing and implementing a completely new protocol to get both client-side dhcpv6 and ra to be able to talk to to a dhcpv4 client in a standardised way so that either of them can pass a shutdown signal to the dhcpv4 client. 2. implement a shutdown signal directly in dhcpv4. The end result is the same: the draft requests a requirement for a DHCPv4 client to shut itself down on receiving a signal. > Only a client that's IPv6-capable is ever going to act on this option, > so doing it with DHCPv4 doesn't really make sense. Only a host which runs a dhcpv4 client is ever going to act on this option. From a strict point of view, it has nothing to do with ipv6. Nick From nobody Mon Apr 14 10:24: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 454361A06A4 for ; Mon, 14 Apr 2014 10:23:58 -0700 (PDT) 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 d3x-xBUVXMRG for ; Mon, 14 Apr 2014 10:23:53 -0700 (PDT) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4471A069E for ; Mon, 14 Apr 2014 10:23:53 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id jw12so8076300veb.27 for ; Mon, 14 Apr 2014 10:23:50 -0700 (PDT) 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=3P0xMj6n+SNp/WLUCFlJGWS8TZsyUdAOEvQHH2l/zyY=; b=DmKa9b8nU6B2kE+QoQqMpx9J4jAqHy/NrFexG/tOlhXkF81UYqM02TbFHvvDgWO3bQ P/5l+uNvBzujewPkcdLTSjQSNmma+CWgw2YQsjFni/KHj8nhEJRffmLysRo8RrdAQET8 I1tC5cPWIuEfDOK6WVQswx0e6npYD5qxdUOS4v22smOfDHzczVQz0FiT2Flx5ploHh4P ihmULuLSkaeG9yBmE11C8Db9lCVp52OrHoJmZ5ipHYDGO2Ri+r6WDJumjWTaiCZG4hKW Xntbs7aA725E6/Xvs4trflspLQZQF0rDp2tVZtnw4gu4EYamM4bDMwqQds89pmCd0EQm ULFw== MIME-Version: 1.0 X-Received: by 10.58.23.6 with SMTP id i6mr37143661vef.12.1397496230778; Mon, 14 Apr 2014 10:23:50 -0700 (PDT) Sender: mpetach@gmail.com Received: by 10.220.173.193 with HTTP; Mon, 14 Apr 2014 10:23:50 -0700 (PDT) In-Reply-To: References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> Date: Mon, 14 Apr 2014 10:23:50 -0700 X-Google-Sender-Auth: 9XOgiEVlgeLJBNy17tXCkWQGaiQ Message-ID: From: Matthew Petach To: Owen DeLong Content-Type: multipart/alternative; boundary=047d7b339db1691b5604f703f201 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/PGzUvbhuXoRv4-E2nGa3wrGB5y0 Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 17:23:58 -0000 --047d7b339db1691b5604f703f201 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 14, 2014 at 9:49 AM, Owen DeLong wrote: > > On Apr 14, 2014, at 9:36 AM, Ted Lemon wrote: > > > On Apr 14, 2014, at 11:08 AM, Nick Hilliard wrote: > >> because you're using one protocol stack to send signals about another > >> protocol stack. "layering violation" is possibly the wrong term. Maybe > >> "protocol bleed" or some > [...] > Why not, instead of using a DCHCPOFFER, provide an ICMPv4 DHCP-UNAVAILABLE > message which can be sent in response to a DHCPREQUEST message by any > router which is configured to authoritatively deny DHCPv4 on the link? A > host receiving such a message should be expected to behave in an identical > manner to the behavior proposed in this draft. > > Oooh, that could be fun at conferences...set my laptop up to respond to broadcast DHCP requests with DHCP-UNAVAILABLE responses, to keep all the bandwidth for myself. :) Matt (which is to say, the potential for abuse here seems kinda high; are we sure this a good road for us to be traveling down?) --047d7b339db1691b5604f703f201 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



    On Mon, Apr 14, 2014 at 9:49 AM, Owen DeLong <= owen@delong.com>= ; wrote:

    On Apr 14, 2014, at 9:36 AM, Ted Lemon <ted.lemon@nominum.com> wrote:

    > On Apr 14, 2014, at 11:08 AM, Nick Hilliard <nick@foobar.org> wrote:
    >> because you're using one protocol stack to send signals about = another
    >> protocol stack. =C2=A0"layering violation" is possibly t= he wrong term. =C2=A0Maybe
    >> "protocol bleed" or some
    [...]
    Why not,= instead of using a DCHCPOFFER, provide an ICMPv4 DHCP-UNAVAILABLE message = which can be sent in response to a DHCPREQUEST message by any router which = is configured to authoritatively deny DHCPv4 on the link? A host receiving = such a message should be expected to behave in an identical manner to the b= ehavior proposed in this draft.


    Oooh, that could be fun at = conferences...set my laptop up
    to respond to broadcast DHCP requests wit= h
    DHCP-UNAVAILABLE responses, to keep all
    the bandwidth fo= r myself.=C2=A0 :)

    Matt
    (which is to say, the potential for abuse= here seems
    kinda high; are we sure this a good road for us to be
    tra= veling down?)

    --047d7b339db1691b5604f703f201-- From nobody Mon Apr 14 10:26: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 3F0C81A06A9 for ; Mon, 14 Apr 2014 10:26:20 -0700 (PDT) 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 G1LODJWndJ7W for ; Mon, 14 Apr 2014 10:26:18 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 78A7D1A069E for ; Mon, 14 Apr 2014 10:26:18 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.dyn.netability.ie (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s3EHQ9M3078071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 14 Apr 2014 18:26:10 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.dyn.netability.ie Message-ID: <534C1A41.1050505@foobar.org> Date: Mon, 14 Apr 2014 18:26:25 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Matthew Petach , Owen DeLong References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/X_qGEA2Vk_JerLCNlVB09b1bl5s Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 17:26:20 -0000 On 14/04/2014 18:23, Matthew Petach wrote: > (which is to say, the potential for abuse here seems > kinda high; are we sure this a good road for us to be > traveling down?) This is no different to any other type of rogue dhcpv4 situation. Nick From nobody Mon Apr 14 10:33: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 CD8A81A06C1 for ; Mon, 14 Apr 2014 10:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] 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 DBenfOehqazw for ; Mon, 14 Apr 2014 10:33:31 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 28F451A069E for ; Mon, 14 Apr 2014 10:33:30 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1WZkky-0000BrC; Mon, 14 Apr 2014 19:33:20 +0200 Message-Id: To: Ted Lemon From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> In-reply-to: Your message of "Mon, 14 Apr 2014 11:36:46 -0500 ." Date: Mon, 14 Apr 2014 19:33:19 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mcg5ji176DOckQtkJm7R43Lc3J4 Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 17:33:34 -0000 In your letter dated Mon, 14 Apr 2014 11:36:46 -0500 you wrote: >It's broadcast traffic, which is expensive for everyone sharing a Wifi AP. I >f every host is doing it, that's a lot of traffic. > >Also, if I get a DHCPDISCOVER, and response with a DHCPOFFER with this option, > is the expectation that the client will shut down at that point? That's a s >ubstantial protocol change, if so. If we're going all the way to DHCPACK, no >w the client has an IP address. What if it tries to use it? I wonder if such an DHCPv4 option should be called 'no-service-at-the-moment'. This can then be returned in the DHCPOFFER. The option contains a timeout and clients should have a maximum what they are willing the accept. The client DHCP will stop sending DHCPDISCOVERs until the timeout has expired or until the user/admin manually requests a DHCP lease. This way the option becomes independent of IPv6 and can be use in any situation where there won't be any offers for a while. Note that if a client receives both an actual offer from one server and the new option from an attacker, then the client can still continue with a REQUEST, thus reducing the DoS potential. From nobody Mon Apr 14 10:45: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 564881A0666 for ; Mon, 14 Apr 2014 10:45:40 -0700 (PDT) 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 MIclIcRpAAMV for ; Mon, 14 Apr 2014 10:45:36 -0700 (PDT) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id CDEDB1A01FB for ; Mon, 14 Apr 2014 10:45:35 -0700 (PDT) Received: by mail-ve0-f174.google.com with SMTP id oz11so7709415veb.5 for ; Mon, 14 Apr 2014 10:45:33 -0700 (PDT) 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=pfLiUsyFwIylsgmgiGFFJKSuP6aO77pQkE3tSuBTNtE=; b=nwcjucsHZpRBSLruaO91KG09prQ+lz2YjgzagUqvr6J6WyEzl+Hg8YAAzc/RlpV+8j sMemab9ZIv3/wcm4MXvE2t8qJAu86oJeOwC7wIbvoxKw6zG8zBEQt1oK1UVS3bI7n8xJ o08cfSz05Qwp5reve1m+NhElGHgVQNgxPVrS2N/HBg6OfiWRBfkNZPbj/ANMdOHeOGlK fu52WALuF+4LFSC0OCtyHMvN62e05/tJAmMF/TgL64ebeIrREHbteejVJ/N2EYRZ55Ym apT097Qp5MKDq38jZjQdw3GJSGDj6QdsGrdkiEAEUCozpCsC/qQ/dtPGpIxagST9cqK2 eFQg== MIME-Version: 1.0 X-Received: by 10.221.4.66 with SMTP id ob2mr2254935vcb.28.1397497533142; Mon, 14 Apr 2014 10:45:33 -0700 (PDT) Sender: mpetach@gmail.com Received: by 10.220.173.193 with HTTP; Mon, 14 Apr 2014 10:45:33 -0700 (PDT) In-Reply-To: <534C1A41.1050505@foobar.org> References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <534C1A41.1050505@foobar.org> Date: Mon, 14 Apr 2014 10:45:33 -0700 X-Google-Sender-Auth: cwdT7MW0pyBekv5uWtuAZWinrBs Message-ID: From: Matthew Petach To: Nick Hilliard Content-Type: multipart/alternative; boundary=089e0122a924099cc004f7044026 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/6GGn8q3MyPyw0oSZF0BmDlUJrsc Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 17:45:40 -0000 --089e0122a924099cc004f7044026 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 14, 2014 at 10:26 AM, Nick Hilliard wrote: > On 14/04/2014 18:23, Matthew Petach wrote: > > (which is to say, the potential for abuse here seems > > kinda high; are we sure this a good road for us to be > > traveling down?) > > This is no different to any other type of rogue dhcpv4 situation. > > Nick > > Correct me if I'm wrong, though; being an ICMP response, rather than a DHCP response would mean DHCP snooping wouldn't be sufficient to stop me from engaging in mischief, where today settings like DHCP snooping and DHCP guard could prevent me from acting as a rogue DHCP server? I suppose if we extend the concept of DHCP snooping to also include ICMP snooping, that would work. Thanks! Matt --089e0122a924099cc004f7044026 Content-Type: text/html; charset=UTF-8

    On Mon, Apr 14, 2014 at 10:26 AM, Nick Hilliard <nick@foobar.org> wrote:
    On 14/04/2014 18:23, Matthew Petach wrote:
    > (which is to say, the potential for abuse here seems
    > kinda high; are we sure this a good road for us to be
    > traveling down?)

    This is no different to any other type of rogue dhcpv4 situation.

    Nick


    Correct me if I'm wrong, though; being an ICMP
    response, rather than a DHCP response would
    mean DHCP snooping wouldn't be sufficient to stop
    me from engaging in mischief, where today settings
    like DHCP snooping and DHCP guard could prevent
    me from acting as a rogue DHCP server?

    I suppose if we extend the concept of DHCP snooping
    to also include ICMP snooping, that would work.

    Thanks!

    Matt

    --089e0122a924099cc004f7044026-- From nobody Mon Apr 14 11: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 5D7C31A0262 for ; Mon, 14 Apr 2014 11:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 wxx0eZFIhZeu for ; Mon, 14 Apr 2014 11:13:54 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id CEBCC1A0203 for ; Mon, 14 Apr 2014 11:13:50 -0700 (PDT) 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 6A1691B805A for ; Mon, 14 Apr 2014 11:13:48 -0700 (PDT) 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 364F519005C; Mon, 14 Apr 2014 11:13:48 -0700 (PDT) Received: from [192.168.146.119] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 14 Apr 2014 11:13:47 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: Date: Mon, 14 Apr 2014 13:13:46 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <091F7BAB-2AAC-41B3-A67C-540482323E71@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> To: Owen DeLong X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/yV5EQ1LaGTTHS1mVwZXyHxEfHaw Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 18:13:59 -0000 On Apr 14, 2014, at 11:49 AM, Owen DeLong wrote: > What is being proposed here would be more like responding to an IPv4 = packet with an ICMP6 unreachable, which I=92m pretty sure would be = considered problematic. Okay, let's consider your example as it relates to the discussion. = Here we are talking about responding to an IPv6 packet with another IPv6 = packet, which contains information about the availability of IPv4 = service on the local wire. In your example you are talking about = responding to an IPv4 packet with an IPv6 packet. So the two = situations are not analogous. I agree that if we were doing what you = suggest in your example, that would be a bad idea, because the = association between an IPv4 and an IPv6 address is something that would = have to be inferred by the network, and that _would_ involve a layering = violation. But the actual use case we are talking about involves no such layering = violation. > Sure, so adding a form of NACK or DHCP-UNREACHABLE message to IPv4 = makes sense to me. So you are proposing a massive change to the DHCPv4 protocol in order to = arrange for it to be able to be turned off, rather than a minor change = to the DHCPv6 protocol to signal that there is no IPv4 available. How = does this make sense? > Why not, instead of using a DCHCPOFFER, provide an ICMPv4 = DHCP-UNAVAILABLE message which can be sent in response to a DHCPREQUEST = message by any router which is configured to authoritatively deny DHCPv4 = on the link? A host receiving such a message should be expected to = behave in an identical manner to the behavior proposed in this draft. ICMP !=3D DHCP. You just objected to the No IPv4 proposal (or Nick = did) on the basis that it's hard for a DHCPv6 client to pass information = to a DHCPv4 client (which, TBH, sounds like a bug to me). Why is it = easier for the ICMP implementation in the kernel to pass information to = the DHCPv4 client? I have personal experience with this: there's code = in the ISC DHCP server/client that has to catch bogus error messages = pushed up the stack by the kernel and ignore them in order to avoid = having its state machine broken, because the kernel has no way to = associate ICMP messages with particular datagram sources. My belief was = that the kernel should discard such messages, because it can't do = anything useful with them, but the linux guys decided to deliver them; = neither solution is really satisfactory. You are proposing to use this = as a solution in favor of something that would actually work reliably. = That doesn't make sense. The reality is that one of the biggest problems with the configuration = system on linux is that the various components don't communicate with = each other in a useful way. Other operating systems manage to do a = better job, and there's work ongoing in the linux community to fix this = problem (e.g., systemd is now pulling a lot of network stack = functionality into it specifically so that it can be part of the system = configuration state machine as a whole, and dnsmasq does something = similar). So in reality it makes a tremendous amount of sense to put this = information in DHCPv6, and the concern that it may be difficult to = communicate the information to the IPv4 stack is a temporary situation = that's easily addressed. Putting it in IPv4 means more useless network = traffic, more attack surfaces on IPv6-only routers, etc. From nobody Mon Apr 14 11: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 C801E1A0545 for ; Mon, 14 Apr 2014 11:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.573 X-Spam-Level: X-Spam-Status: No, score=-1.573 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, RP_MATCHES_RCVD=-0.272, 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 QTBr570Q45Zz for ; Mon, 14 Apr 2014 11:24:12 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9351A0319 for ; Mon, 14 Apr 2014 11:24:12 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8CBB8403EF; Mon, 14 Apr 2014 14:24:09 -0400 (EDT) Message-ID: <534C27C9.80701@viagenie.ca> Date: Mon, 14 Apr 2014 14:24:09 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Nick Hilliard , Ted Lemon References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <534C17B8.8030209@foobar.org> In-Reply-To: <534C17B8.8030209@foobar.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sl26y0RocPAc_XC0c0zgeq2gJAY Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 18:24:17 -0000 Le 2014-04-14 13:15, Nick Hilliard a écrit : > Stepping back a moment, the alternatives are: > > 1. wiring both dhcpv6 and ra to include an ipv4 protocol option, and then > designing and implementing a completely new protocol to get both > client-side dhcpv6 and ra to be able to talk to to a dhcpv4 client in a > standardised way so that either of them can pass a shutdown signal to the > dhcpv4 client. $ grep "option no-ipv4" /var/db/dhclient6.leases.eth0 && pkill dhclient - Is that too hard to implement? - Why does that need to be standardized? It would be part of an OS'es scripts and that usually doesn't get standardized. - Wouldn't POSIX be the applicable standard? (semi-joking here) > 2. implement a shutdown signal directly in dhcpv4. > > The end result is the same: the draft requests a requirement for a DHCPv4 > client to shut itself down on receiving a signal. > >> Only a client that's IPv6-capable is ever going to act on this option, >> so doing it with DHCPv4 doesn't really make sense. > > Only a host which runs a dhcpv4 client is ever going to act on this option. > From a strict point of view, it has nothing to do with ipv6. Only a network that does provide IPv6 would ever want to set that option. It has *everything* to do with IPv6. 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 nobody Mon Apr 14 12:34: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 604DD1A0666 for ; Mon, 14 Apr 2014 12:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.262 X-Spam-Level: X-Spam-Status: No, score=-1.262 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.272, 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 w5XnAzm-YjgS for ; Mon, 14 Apr 2014 12:33:55 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 830D71A0209 for ; Mon, 14 Apr 2014 12:33:54 -0700 (PDT) Received: from owens-mbp.meeting.arin.net (unknown.servercentral.net [50.31.214.180] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s3EJUT9u031885 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 12:30:32 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3EJUT9u031885 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1397503834; bh=5vF+w49FRvQfWCCPYxbg4XKMhH0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=SW09RuO7ZJgxphLSCaz20HklopoijyxDna5k3TUI0HSq98Skiral/xyreI6HqpvpK 5tQI2o0Ea9T2L8bzJCtdUCo4qFVozOO/mXa0mx0N9bMk764yINglhBRuyGOCMwBtmz uwXAp+USccpiDy0+tUulCYN0sR0e9Mw9M8fiT/vQ= Content-Type: multipart/alternative; boundary="Apple-Mail=_C84ECCD5-80BD-4BE0-BA92-26F629E0D1F2" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: Date: Mon, 14 Apr 2014 12:30:27 -0700 Message-Id: <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> To: Matthew Petach X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 14 Apr 2014 12:30:34 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ondZeTgXO0wbnvCtGbmRGwz-tWA Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 19:34:00 -0000 --Apple-Mail=_C84ECCD5-80BD-4BE0-BA92-26F629E0D1F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 14, 2014, at 10:23 AM, Matthew Petach = wrote: >=20 >=20 >=20 > On Mon, Apr 14, 2014 at 9:49 AM, Owen DeLong wrote: >=20 > On Apr 14, 2014, at 9:36 AM, Ted Lemon wrote: >=20 > > On Apr 14, 2014, at 11:08 AM, Nick Hilliard wrote: > >> because you're using one protocol stack to send signals about = another > >> protocol stack. "layering violation" is possibly the wrong term. = Maybe > >> "protocol bleed" or some > [...]=20 > Why not, instead of using a DCHCPOFFER, provide an ICMPv4 = DHCP-UNAVAILABLE message which can be sent in response to a DHCPREQUEST = message by any router which is configured to authoritatively deny DHCPv4 = on the link? A host receiving such a message should be expected to = behave in an identical manner to the behavior proposed in this draft. >=20 >=20 > Oooh, that could be fun at conferences...set my laptop up > to respond to broadcast DHCP requests with > DHCP-UNAVAILABLE responses, to keep all > the bandwidth for myself. :) And you can=92t do this with the proposed IPv6 response we are = discussing why? Seems to me that the same potential for abuse exists with either = situation. Owen --Apple-Mail=_C84ECCD5-80BD-4BE0-BA92-26F629E0D1F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
    On Apr 14, 2014, at 10:23 AM, Matthew = Petach <mpetach@netflight.com> = wrote:




    On Mon, Apr 14, 2014 at 9:49 AM, Owen DeLong = <owen@delong.com> wrote:

    On Apr 14, 2014, at 9:36 AM, Ted Lemon <ted.lemon@nominum.com> wrote:

    > On Apr 14, 2014, at 11:08 AM, Nick Hilliard <nick@foobar.org> = wrote:
    >> because you're using one protocol stack to send signals about = another
    >> protocol stack.  "layering violation" is possibly the = wrong term.  Maybe
    >> "protocol bleed" or some
    [...]
    Why not, instead of using a DCHCPOFFER, provide = an ICMPv4 DHCP-UNAVAILABLE message which can be sent in response to a = DHCPREQUEST message by any router which is configured to authoritatively = deny DHCPv4 on the link? A host receiving such a message should be = expected to behave in an identical manner to the behavior proposed in = this draft.


    Oooh, that could be fun = at conferences...set my laptop up
    to respond to broadcast DHCP = requests with
    DHCP-UNAVAILABLE responses, to keep = all
    the bandwidth for myself.  = :)

    And you can=92t = do this with the proposed IPv6 response we are discussing = why?

    Seems to me that the same potential for = abuse exists with either = situation.

    Owen

    = --Apple-Mail=_C84ECCD5-80BD-4BE0-BA92-26F629E0D1F2-- From nobody Mon Apr 14 12:39: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 810971A0706 for ; Mon, 14 Apr 2014 12:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.262 X-Spam-Level: X-Spam-Status: No, score=-1.262 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.272, 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 ua0pMcfk0h2K for ; Mon, 14 Apr 2014 12:39:16 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 359DB1A0705 for ; Mon, 14 Apr 2014 12:39:16 -0700 (PDT) Received: from owens-mbp.meeting.arin.net (unknown.servercentral.net [50.31.214.180] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s3EJWpTn031991 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 12:33:08 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3EJWpTn031991 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1397503991; bh=Brk0CkyZBeWqBpHh4By+W5ncIc4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=aaV1XoYabwziSr3u41V0BXW5ChFM7jW5Qsdwfwcna2gAhC6AacRxjbH4B/Mzq7qYn ni+pnpRAh7svz4TK+by1X2JUP9MwqySIf7wQtsQWrN5wX3KXa+QPRM/rFqxfQQpOM9 MZEt04fPL44GSRXVoJ/sDoeSPcwBdmZMYxPfPV7E= Content-Type: multipart/alternative; boundary="Apple-Mail=_D8F15737-430C-4B6C-AB60-EDE9775DC2F9" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: Date: Mon, 14 Apr 2014 12:32:49 -0700 Message-Id: References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <534C1A41.1050505@foobar.org> To: Matthew Petach X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 14 Apr 2014 12:33:11 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sBOdcixc3ojvB1vZr39EPqP8GNw Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 19:39:20 -0000 --Apple-Mail=_D8F15737-430C-4B6C-AB60-EDE9775DC2F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 14, 2014, at 10:45 AM, Matthew Petach = wrote: >=20 > On Mon, Apr 14, 2014 at 10:26 AM, Nick Hilliard = wrote: > On 14/04/2014 18:23, Matthew Petach wrote: > > (which is to say, the potential for abuse here seems > > kinda high; are we sure this a good road for us to be > > traveling down?) >=20 > This is no different to any other type of rogue dhcpv4 situation. >=20 > Nick >=20 >=20 > Correct me if I'm wrong, though; being an ICMP > response, rather than a DHCP response would > mean DHCP snooping wouldn't be sufficient to stop > me from engaging in mischief, where today settings > like DHCP snooping and DHCP guard could prevent > me from acting as a rogue DHCP server? >=20 > I suppose if we extend the concept of DHCP snooping > to also include ICMP snooping, that would work. >=20 > Thanks! >=20 > Matt >=20 ICMP was just a suggestion. If you want to put it in DHCP/UDP to dodge = abuse potential, I have no problem with that. The point is that this has = no business being encoded in DHCPv6 or RA, it belongs in IPv4 somewhere. Owen --Apple-Mail=_D8F15737-430C-4B6C-AB60-EDE9775DC2F9 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
    On Apr 14, 2014, at 10:45 AM, Matthew Petach <mpetach@netflight.com> wrote:


    On Mon, Apr 14, 2014 at 10:26 AM, Nick Hilliard <nick@foobar.org> wrote:
    On 14/04/2014 18:23, Matthew Petach wrote:
    > (which is to say, the potential for abuse here seems
    > kinda high; are we sure this a good road for us to be
    > traveling down?)

    This is no different to any other type of rogue dhcpv4 situation.

    Nick


    Correct me if I'm wrong, though; being an ICMP
    response, rather than a DHCP response would
    mean DHCP snooping wouldn't be sufficient to stop
    me from engaging in mischief, where today settings
    like DHCP snooping and DHCP guard could prevent
    me from acting as a rogue DHCP server?

    I suppose if we extend the concept of DHCP snooping
    to also include ICMP snooping, that would work.

    Thanks!

    Matt


    ICMP was just a suggestion. If you want to put it in DHCP/UDP to dodge abuse potential, I have no problem with that. The point is that this has no business being encoded in DHCPv6 or RA, it belongs in IPv4 somewhere.

    Owen

    --Apple-Mail=_D8F15737-430C-4B6C-AB60-EDE9775DC2F9-- From nobody Mon Apr 14 12:42: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 A95F31A0711 for ; Mon, 14 Apr 2014 12:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 enjKy2bbFJ1o for ; Mon, 14 Apr 2014 12:42:19 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 6C03F1A0213 for ; Mon, 14 Apr 2014 12:42:19 -0700 (PDT) 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 079CD1B8062 for ; Mon, 14 Apr 2014 12:42:17 -0700 (PDT) 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 D1AE519005C; Mon, 14 Apr 2014 12:42:16 -0700 (PDT) Received: from [192.168.146.119] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 14 Apr 2014 12:42:16 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> Date: Mon, 14 Apr 2014 14:42:14 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> To: Owen DeLong X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/L1EXYuTuG1UKVLauJajGg1mRNEw Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 19:42:20 -0000 On Apr 14, 2014, at 2:30 PM, Owen DeLong wrote: > Seems to me that the same potential for abuse exists with either = situation. This is true, and the remedy exists as well. It's worth pointing out = that "please review" doesn't mean "please redesign this." It means = "please point out technical flaws that you see." None of what you or = Nick has said sound like technical flaws to me=97they sound like "I = would prefer to do it this other way." The working group considered doing it that other way and decided that on = the balance, the way it's written now is better. So unless there is = some strong technical reason why it _shouldn't_ be done the way the = working group has proposed, there's no basis for making a change. It's = issues like that that we are looking for in a v6ops review. From nobody Mon Apr 14 12:48: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 24B6E1A071A for ; Mon, 14 Apr 2014 12:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.327 X-Spam-Level: X-Spam-Status: No, score=0.327 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_22=0.6, RP_MATCHES_RCVD=-0.272] 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 JBPm_I2NI_YR for ; Mon, 14 Apr 2014 12:48:28 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFAD1A02AC for ; Mon, 14 Apr 2014 12:48:27 -0700 (PDT) Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 995AC629B9 for ; Mon, 14 Apr 2014 21:48:24 +0200 (CEST) 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 6BE6E629A1 for ; Mon, 14 Apr 2014 21:48:24 +0200 (CEST) Received: (qmail 54271 invoked by uid 1007); 14 Apr 2014 21:48:24 +0200 Date: Mon, 14 Apr 2014 21:48:24 +0200 From: Gert Doering To: Simon Perreault Message-ID: <20140414194824.GY43641@Space.Net> References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <534C17B8.8030209@foobar.org> <534C27C9.80701@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <534C27C9.80701@viagenie.ca> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/vRkWjmtECswn63P64hK5y0X-WRc Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 19:48:30 -0000 Hi, On Mon, Apr 14, 2014 at 02:24:09PM -0400, Simon Perreault wrote: > Le 2014-04-14 13:15, Nick Hilliard a écrit : > > Stepping back a moment, the alternatives are: > > > > 1. wiring both dhcpv6 and ra to include an ipv4 protocol option, and then > > designing and implementing a completely new protocol to get both > > client-side dhcpv6 and ra to be able to talk to to a dhcpv4 client in a > > standardised way so that either of them can pass a shutdown signal to the > > dhcpv4 client. > > $ grep "option no-ipv4" /var/db/dhclient6.leases.eth0 && pkill dhclient > > - Is that too hard to implement? Yes. My DHCP client is called "dhcpcd". Nick's might be "pump". > - Why does that need to be standardized? It would be part of an OS'es > scripts and that usually doesn't get standardized. Who do you expect to maintain that on the DHCPv6 client side, for all possible combinations with DHCPv4 clients? > > Only a host which runs a dhcpv4 client is ever going to act on this option. > > From a strict point of view, it has nothing to do with ipv6. > > Only a network that does provide IPv6 would ever want to set that > option. It has *everything* to do with IPv6. To the contrary. A network that does not provide IPv4 would want to set that option. You might just not have public IPv4 here, because it's a zeroconfo network with only IPv4 link-local (169.254) addresses. 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 nobody Mon Apr 14 12:54: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 1BA621A06AC for ; Mon, 14 Apr 2014 12:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.636 X-Spam-Level: X-Spam-Status: No, score=0.636 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.272, 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 VmUhI-Jx_NHb for ; Mon, 14 Apr 2014 12:53:55 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id B01211A0648 for ; Mon, 14 Apr 2014 12:53:55 -0700 (PDT) Received: from owens-mbp.meeting.arin.net (unknown.servercentral.net [50.31.214.180] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s3EJnjKQ032702 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 12:49:47 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3EJnjKQ032702 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1397504990; bh=/9NhLlZhaWWp2cxNxc4+K23SBDg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=KyaAiuMNAX9mqKXBA5GD5DkfS9Y+g6todWzpgmeIiyY7zJfmzeYs3ZS1jPZGiN/aR YMHCW6jcSf6WZ64tGM0abOap7SQzd7N53KMCtMBIXd1w2G04h9CWuyy9pN28ii7CVN rhnOwsia24x/j/DjzphcTSLoqCgCFOm0TMRViE2c= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: <091F7BAB-2AAC-41B3-A67C-540482323E71@nominum.com> Date: Mon, 14 Apr 2014 12:49:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3AAA3A70-1513-4163-A841-45FEFC95004C@delong.com> References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <091F7BAB-2AAC-41B3-A67C-540482323E71@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 14 Apr 2014 12:49:50 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/MAsV6BCehovG9QuCxqBd-flP_JM Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 19:54:00 -0000 On Apr 14, 2014, at 11:13 AM, Ted Lemon wrote: > On Apr 14, 2014, at 11:49 AM, Owen DeLong wrote: >> What is being proposed here would be more like responding to an IPv4 = packet with an ICMP6 unreachable, which I=92m pretty sure would be = considered problematic. >=20 > Okay, let's consider your example as it relates to the discussion. = Here we are talking about responding to an IPv6 packet with another IPv6 = packet, which contains information about the availability of IPv4 = service on the local wire. In your example you are talking about = responding to an IPv4 packet with an IPv6 packet. So the two = situations are not analogous. I agree that if we were doing what you = suggest in your example, that would be a bad idea, because the = association between an IPv4 and an IPv6 address is something that would = have to be inferred by the network, and that _would_ involve a layering = violation. >=20 > But the actual use case we are talking about involves no such layering = violation. >=20 >> Sure, so adding a form of NACK or DHCP-UNREACHABLE message to IPv4 = makes sense to me. >=20 > So you are proposing a massive change to the DHCPv4 protocol in order = to arrange for it to be able to be turned off, rather than a minor = change to the DHCPv6 protocol to signal that there is no IPv4 available. = How does this make sense? Please explain to me why this is any more massive of a change to DHCPv4 = than it would be to DHCPv6. >> Why not, instead of using a DCHCPOFFER, provide an ICMPv4 = DHCP-UNAVAILABLE message which can be sent in response to a DHCPREQUEST = message by any router which is configured to authoritatively deny DHCPv4 = on the link? A host receiving such a message should be expected to = behave in an identical manner to the behavior proposed in this draft. >=20 > ICMP !=3D DHCP. You just objected to the No IPv4 proposal (or Nick = did) on the basis that it's hard for a DHCPv6 client to pass information = to a DHCPv4 client (which, TBH, sounds like a bug to me). Why is it = easier for the ICMP implementation in the kernel to pass information to = the DHCPv4 client? I have personal experience with this: there's code = in the ISC DHCP server/client that has to catch bogus error messages = pushed up the stack by the kernel and ignore them in order to avoid = having its state machine broken, because the kernel has no way to = associate ICMP messages with particular datagram sources. My belief was = that the kernel should discard such messages, because it can't do = anything useful with them, but the linux guys decided to deliver them; = neither solution is really satisfactory. You are proposing to use this = as a solution in favor of something that would actually work reliably. = That doesn't make sense. ICMP is the protocol generally intended to communicate that a service is = unavailable.=20 Using DHCPv6 to tell a client that DHCPv4 is not available seems a = rather odd choice in my mind and I still have yet to see any clear = indication why that=92s preferable to using either DHCPv4 or some other = IPv4 protocol such as ICMP to do so. > The reality is that one of the biggest problems with the configuration = system on linux is that the various components don't communicate with = each other in a useful way. Other operating systems manage to do a = better job, and there's work ongoing in the linux community to fix this = problem (e.g., systemd is now pulling a lot of network stack = functionality into it specifically so that it can be part of the system = configuration state machine as a whole, and dnsmasq does something = similar). I haven=92t seen anything to indicate to me that the IPv6 configuration = mechanisms in MacOS X, Solaris, BSD, or any other operating system are = sufficiently coupled to the IPv4 configuration mechanisms (nor, arguably = should they be) as to address this issue without substantial = modification. > So in reality it makes a tremendous amount of sense to put this = information in DHCPv6, and the concern that it may be difficult to = communicate the information to the IPv4 stack is a temporary situation = that's easily addressed. Putting it in IPv4 means more useless network = traffic, more attack surfaces on IPv6-only routers, etc. You=92re going to have to provide some clarification or documentation to = back this claim up. I don=92t see how responding to an IPv4 packet with = an IPv4 packet indicating that the requested IPv4 service is unavailable = means more useless network traffic or increases the attack surface on an = IPv6-only router. I=92ll buy the argument that a simple ICMP response introduces new DOS = vectors (though arguably if the RFC were written such that a client that = receives both an ICMP and a DHCPOFFER would ignore the ICMP, I think = that is largely mitigated), but I don=92t buy that it increases the = attack surface of the router or that it increases the useless network = traffic. In reality, most dual-stack clients are going to send out their DHCPv4 = request either at the same time or earlier than their DHCPv6 request, so = you=92re going to see that first request either way. If the router = immediately responds with a single packet saying =93NO=94, then that=92s = it. Otherwise, you wait until the DHCPv6 response comes back (mandating = the additional overhead of DHCPv6 in networks that may well operate on = SLAAC currently, thus introducing several additional unnecessary = packets) and at most you=92ve added one packet per client reboot, = roughly. I have a hard time calling that =93more useless network = traffic=94. Owen From nobody Mon Apr 14 12:58: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 0DA4B1A0447 for ; Mon, 14 Apr 2014 12:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.263 X-Spam-Level: X-Spam-Status: No, score=-1.263 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.272, 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 5L_8CsP5VhXr for ; Mon, 14 Apr 2014 12:58:30 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFBD1A039D for ; Mon, 14 Apr 2014 12:58:30 -0700 (PDT) Received: from [IPv6:2001:1838:1003::a036:4bd9:bfc6:a04c] (unknown.ipv6.scnet.net [IPv6:2001:1838:1003:0:a036:4bd9:bfc6:a04c] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s3EJqbac032763 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 12:53:26 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3EJqbac032763 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1397505229; bh=lMBwzcAwsdB1/GDogJUHupvKjyc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=mBD3leBl/0XJC2KTRbhSvpvPX55UV4AFEmU6T6O+4BC3LsQHx20Mlxco3pq7+wiQK jt51PquE7vLcMX5mfPGtezKJgvAC3gAABTeo83OR9CWmC+VeQH2xBUGWEmkDdBOL1d xJjjcfllkQkMXMpIWEHPGP6eVOOr8Sh3BKAqJdNo= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: <534C27C9.80701@viagenie.ca> Date: Mon, 14 Apr 2014 12:52:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3DFC20FF-E866-4E1C-B720-D7C91CBB925B@delong.com> References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <534C17B8.8030209@foobar.org> <534C27C9.80701@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 14 Apr 2014 12:53:49 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/AQrdzuL0J2Fp4DKUt2SSrVkuQlg Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 19:58:31 -0000 >> Only a host which runs a dhcpv4 client is ever going to act on this = option. >> =46rom a strict point of view, it has nothing to do with ipv6. >=20 > Only a network that does provide IPv6 would ever want to set that > option. It has *everything* to do with IPv6. Nope=85 Why wouldn=92t a network that does not offer IPv4 autoconfigration not = want to implement that option whether or not they do DHCPv6? This is all about the unavailability of IPv4 auto configuration on the = network. It has nothing inherently to do with IPv6 except that IPv6 is = the most likely alternative to IPv4 that would be used. However, that=92s = just a likely majority use case, not the sole use case. Owen From nobody Mon Apr 14 13:01: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 30FB81A039D for ; Mon, 14 Apr 2014 13:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 qJ5vFr43PM0T for ; Mon, 14 Apr 2014 13:01:02 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 990061A0213 for ; Mon, 14 Apr 2014 13:01:02 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id F113C403EF for ; Mon, 14 Apr 2014 16:00:59 -0400 (EDT) Message-ID: <534C3E7B.9070705@viagenie.ca> Date: Mon, 14 Apr 2014 16:00:59 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/cp3OAXCCcf2JARcbH0BjcOWVj_w Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 20:01:07 -0000 Le 2014-04-14 15:42, Ted Lemon a écrit : > The working group considered doing it that other way and decided that > on the balance, the way it's written now is better. So unless there > is some strong technical reason why it _shouldn't_ be done the way > the working group has proposed, there's no basis for making a change. > It's issues like that that we are looking for in a v6ops review. This is entirely correct. For the sake of history, we had in sunset4 a presentation of draft-yang-dhc-ipv4-dis which is a DHCPv4-based solution. That was many IETFs ago. We eventually merged with that draft. Since the goal is going IPv6-only, a DHCPv4-based solution was considered a deal-breaker. 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 nobody Mon Apr 14 13:03: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 039601A02AC for ; Mon, 14 Apr 2014 13:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.263 X-Spam-Level: X-Spam-Status: No, score=-1.263 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.272, 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 yLnsRMA0cLtx for ; Mon, 14 Apr 2014 13:03:45 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 420201A0213 for ; Mon, 14 Apr 2014 13:03:45 -0700 (PDT) Received: from [IPv6:2001:1838:1003::a036:4bd9:bfc6:a04c] (unknown.ipv6.scnet.net [IPv6:2001:1838:1003:0:a036:4bd9:bfc6:a04c] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s3EK1uJf000678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 13:02:03 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3EK1uJf000678 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1397505732; bh=ZUeH0JWqryBlfpFJL7hra+dz39c=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=W4V40I4nrHwAYAiPVECjswt84ZxS5TKaQKw9rKFj/hcrI1BV6n/LWMrTB+uyeAXst ftsOd/KQgD4J4ysM+l48XFXgHrX44JWymRdjAFJULPYbeLnJ9tzfuSKfs6AplhZ/rQ u8r3ewnfojX1gK+ekQAg5k4V3vzZ10mN0B9G8ezE= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: Date: Mon, 14 Apr 2014 13:01:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> To: Ted Lemon X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 14 Apr 2014 13:02:12 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/u_CrLjcfXboR0RnFg0gBGuWd6KE Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 20:03:46 -0000 On Apr 14, 2014, at 12:42 PM, Ted Lemon wrote: > On Apr 14, 2014, at 2:30 PM, Owen DeLong wrote: >> Seems to me that the same potential for abuse exists with either = situation. >=20 > This is true, and the remedy exists as well. It's worth pointing out = that "please review" doesn't mean "please redesign this." It means = "please point out technical flaws that you see." None of what you or = Nick has said sound like technical flaws to me=97they sound like "I = would prefer to do it this other way." >=20 > The working group considered doing it that other way and decided that = on the balance, the way it's written now is better. So unless there is = some strong technical reason why it _shouldn't_ be done the way the = working group has proposed, there's no basis for making a change. It's = issues like that that we are looking for in a v6ops review. We can agree to disagree, but I feel that informing a host about the = availability of IPv4 configuration services through an IPv6 = configuration service is, in fact, a technically flawed concept. Owen From nobody Mon Apr 14 13:05: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 339561A066F for ; Mon, 14 Apr 2014 13:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.573 X-Spam-Level: X-Spam-Status: No, score=-1.573 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, RP_MATCHES_RCVD=-0.272, 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 b0lxTnicOWtT for ; Mon, 14 Apr 2014 13:05:21 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E40BD1A064F for ; Mon, 14 Apr 2014 13:05:20 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 13C39403EF; Mon, 14 Apr 2014 16:05:18 -0400 (EDT) Message-ID: <534C3F7D.3040406@viagenie.ca> Date: Mon, 14 Apr 2014 16:05:17 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Gert Doering References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <534C17B8.8030209@foobar.org> <534C27C9.80701@viagenie.ca> <20140414194824.GY43641@Space.Net> In-Reply-To: <20140414194824.GY43641@Space.Net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/7pd8tc2_DjbynDSe9lWAywjAGRU Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 20:05:23 -0000 Le 2014-04-14 15:48, Gert Doering a écrit : >> $ grep "option no-ipv4" /var/db/dhclient6.leases.eth0 && pkill dhclient >> >> - Is that too hard to implement? > > Yes. My DHCP client is called "dhcpcd". Nick's might be "pump". I'm sorry, I don't see your point. >> - Why does that need to be standardized? It would be part of an OS'es >> scripts and that usually doesn't get standardized. > > Who do you expect to maintain that on the DHCPv6 client side, for all > possible combinations with DHCPv4 clients? Why would anyone want to maintain that for all combinations of implementations? Take NetworkManager for example. It uses ISC DHCPv4+v6. So it implements the above. That's all it needs to do. Other network daemons or sets of init scripts would do similarly however they want. It's something that gets implemented a level above the DHCP client, in the "glue" code. >>> Only a host which runs a dhcpv4 client is ever going to act on this option. >>> From a strict point of view, it has nothing to do with ipv6. >> >> Only a network that does provide IPv6 would ever want to set that >> option. It has *everything* to do with IPv6. > > To the contrary. A network that does not provide IPv4 would want to set > that option. You might just not have public IPv4 here, because it's > a zeroconfo network with only IPv4 link-local (169.254) addresses. I'm not following your reasoning, sorry. 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 nobody Mon Apr 14 13:10: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 28CBB1A039D for ; Mon, 14 Apr 2014 13:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 Kjh8tVCgw7ds for ; Mon, 14 Apr 2014 13:10:17 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4BA1A0319 for ; Mon, 14 Apr 2014 13:10:16 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9ADA6403EF; Mon, 14 Apr 2014 16:10:13 -0400 (EDT) Message-ID: <534C40A5.9050302@viagenie.ca> Date: Mon, 14 Apr 2014 16:10:13 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Owen DeLong References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <534C17B8.8030209@foobar.org> <534C27C9.80701@viagenie.ca> <3DFC20FF-E866-4E1C-B720-D7C91CBB925B@delong.com> In-Reply-To: <3DFC20FF-E866-4E1C-B720-D7C91CBB925B@delong.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Yw-CqH7tc-UwUQ1BN4-SnIonjFY Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 20:10:19 -0000 Le 2014-04-14 15:52, Owen DeLong a écrit : > Why wouldn’t a network that does not offer IPv4 autoconfigration not want to implement that option whether or not they do DHCPv6? Not sure what you mean. Our draft does specify RA and DHCPv6 versions of the No-IPv4 option. > This is all about the unavailability of IPv4 auto configuration on the network. It has nothing inherently to do with IPv6 except that IPv6 is the most likely alternative to IPv4 that would be used. However, that’s just a likely majority use case, not the sole use case. Look, if IPv7 was a thing I would totally agree with you. It's not, so what you're saying sounds like theoretical orthodoxy. We're trying to fix real problems with moving to IPv6-only. I totally don't care about non-IPv6 and non-IPv4 networks. And I don't see why anyone should. 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 nobody Mon Apr 14 13:12: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 94B281A039D for ; Mon, 14 Apr 2014 13:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.572 X-Spam-Level: X-Spam-Status: No, score=-1.572 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, RP_MATCHES_RCVD=-0.272] 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 qk0cj89wivNG for ; Mon, 14 Apr 2014 13:12:39 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id E41F21A02AC for ; Mon, 14 Apr 2014 13:12:35 -0700 (PDT) Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id BEE13629C5 for ; Mon, 14 Apr 2014 22:12:31 +0200 (CEST) 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 92EA962994 for ; Mon, 14 Apr 2014 22:12:31 +0200 (CEST) Received: (qmail 80702 invoked by uid 1007); 14 Apr 2014 22:12:31 +0200 Date: Mon, 14 Apr 2014 22:12:31 +0200 From: Gert Doering To: Simon Perreault Message-ID: <20140414201231.GZ43641@Space.Net> References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <534C17B8.8030209@foobar.org> <534C27C9.80701@viagenie.ca> <20140414194824.GY43641@Space.Net> <534C3F7D.3040406@viagenie.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="av70RPuHaysFRWqx" Content-Disposition: inline In-Reply-To: <534C3F7D.3040406@viagenie.ca> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/GWrh6tfo1z8D3TyrebBobO7hsM4 Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 20:12:41 -0000 --av70RPuHaysFRWqx Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Apr 14, 2014 at 04:05:17PM -0400, Simon Perreault wrote: > Le 2014-04-14 15:48, Gert Doering a =E9crit : > >> $ grep "option no-ipv4" /var/db/dhclient6.leases.eth0 && pkill dhclient > >> > >> - Is that too hard to implement? > >=20 > > Yes. My DHCP client is called "dhcpcd". Nick's might be "pump". >=20 > I'm sorry, I don't see your point. There are at least 3 different IPv4 DHCP clients on "Unix", and the author and maintainer of the IPv6 DHCP client that is installed might not know which IPv4 DHCP client you're using. So either there is a standard way to communicate this across, as in "all *IPv4* DHCP clients need to learn that", or it will fail in some scenarios, no matter what the IPv6 DHCP client maintainers do. (Also, I'd consider "just kill a foreign process" to be very rude - and depending on the environment you're doing this in, it will be futile as well, because a "service manager" of some sort could just report an error, and restart the "failing" dhclient process). > >> - Why does that need to be standardized? It would be part of an OS'es > >> scripts and that usually doesn't get standardized. > >=20 > > Who do you expect to maintain that on the DHCPv6 client side, for all > > possible combinations with DHCPv4 clients? >=20 > Why would anyone want to maintain that for all combinations of > implementations? "To make it work"? [..] > > To the contrary. A network that does not provide IPv4 would want to set > > that option. You might just not have public IPv4 here, because it's > > a zeroconfo network with only IPv4 link-local (169.254) addresses. >=20 > I'm not following your reasoning, sorry. More bluntly: what makes you think that a network that has no IPv4 has IPv6? 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 --av70RPuHaysFRWqx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBU0xBL99WwGXkzn/FAQLxHg//WOuo4Yr/q6ADfvn1yc52f8CU0Zi/0ViU KsOtFZIIrol5QyFtiBL5rGdVKGqPxOnNe9ovdLwK4TvorrGLP6l4MtrvugDUiaWG xKAVSurZ22drqsjcdLv7G5jtN1Mf/eaSI47/oL7BpDGnrbbyG8qkLwBKd9rDKQzY R9aV8OsLH0zWDfXX0u4LNrl1474qPQ0Xs87RkdXeR9Wj4O5AsyousjWN3fljSNxn bAOtiXLuBrEx4Zv/o/0ipuVkmrmJEG2AkxAj0wUdHbgmMxs61ptP+aqGun1kaf8y Pb9/58U9W5jQJo809PWzWGCzzsf/71BN6pjv3Z558gkQe3EVvnfNCF0YKiCAhKPd 6rV2nQuyTroA/I++3pq1NamGZ9Lj11fuRR2rC4KKWkaiKjfbd13EZL3Gl76rW/lI Vn2Ius5w8fnn4QAxZuKwpgAogPxBhlekh0gYSO/bxd7mEhYd8CtK/9+G/r1NsBEA plYXf7DNpxjqXnNoBt1KALddUMQJvnPrs6ox6oe1oZN1ylisryO5ViI453yduflc PmbKf4Hc/YI2Mz6nEIUHlQg8x7//YrzHx8b63NILMF5MPw0Vz7jJ0zE5oUs1OQGf exxfAvvTu9gXAgmm7xHXXA7KRx0MzhifihzIagWeNwDWp3lQL6G45thN833fvPZA erBZBmRwEsk= =jxiA -----END PGP SIGNATURE----- --av70RPuHaysFRWqx-- From nobody Mon Apr 14 13:19: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 8FC6C1A0213 for ; Mon, 14 Apr 2014 13:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 GnjWwUVflBMu for ; Mon, 14 Apr 2014 13:19:42 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 02D4B1A049A for ; Mon, 14 Apr 2014 13:18:54 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 30ED4403EF; Mon, 14 Apr 2014 16:18:51 -0400 (EDT) Message-ID: <534C42AA.1000102@viagenie.ca> Date: Mon, 14 Apr 2014 16:18:50 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Gert Doering References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <534C17B8.8030209@foobar.org> <534C27C9.80701@viagenie.ca> <20140414194824.GY43641@Space.Net> <534C3F7D.3040406@viagenie.ca> <20140414201231.GZ43641@Space.Net> In-Reply-To: <20140414201231.GZ43641@Space.Net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2N4ndb6LCQ1nEI6mx0VPjcrYiTs Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 20:19:47 -0000 Le 2014-04-14 16:12, Gert Doering a écrit : >>>> $ grep "option no-ipv4" /var/db/dhclient6.leases.eth0 && pkill dhclient >>>> >>>> - Is that too hard to implement? >>> >>> Yes. My DHCP client is called "dhcpcd". Nick's might be "pump". >> >> I'm sorry, I don't see your point. > > There are at least 3 different IPv4 DHCP clients on "Unix", and the > author and maintainer of the IPv6 DHCP client that is installed might > not know which IPv4 DHCP client you're using. > > So either there is a standard way to communicate this across, as in > "all *IPv4* DHCP clients need to learn that", or it will fail in some > scenarios, no matter what the IPv6 DHCP client maintainers do. Ah I see what you mean. I would not expect the DHCPv6 client to have any code added. It would be the controlling "glue code" (e.g., NetworkManager, init scripts, whatever) that would be modified. > (Also, I'd consider "just kill a foreign process" to be very rude - and > depending on the environment you're doing this in, it will be futile > as well, because a "service manager" of some sort could just report an > error, and restart the "failing" dhclient process). Of course. The glue code would terminate the DHCPv4 client process in the appropriate manner. >>> To the contrary. A network that does not provide IPv4 would want to set >>> that option. You might just not have public IPv4 here, because it's >>> a zeroconfo network with only IPv4 link-local (169.254) addresses. >> >> I'm not following your reasoning, sorry. > > More bluntly: what makes you think that a network that has no IPv4 has IPv6? Because we absolutely don't care about other kinds of networks. We're doing this so that IPv6 works better. We don't care about making IPv4 work better. 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 nobody Mon Apr 14 13:20: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 BDE9B1A0447 for ; Mon, 14 Apr 2014 13:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.037 X-Spam-Level: X-Spam-Status: No, score=-0.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.272, 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 vFYR9BYGAy0u for ; Mon, 14 Apr 2014 13:20:42 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id DF4D01A039D for ; Mon, 14 Apr 2014 13:20:41 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.97,859,1389762000"; d="scan'208";a="260437938" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 14 Apr 2014 16:20:13 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Mon, 14 Apr 2014 16:20:28 -0400 From: "George, Wes" To: Owen DeLong , Ted Lemon Date: Mon, 14 Apr 2014 16:20:26 -0400 Thread-Topic: [v6ops] Please review the No IPv4 draft Thread-Index: Ac9YHvmQys992smRSDCieXrXiAkDMA== Message-ID: References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/bU3aV9AVQAwH4y65xIvYjT-RoXU Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 20:20:46 -0000 T24gNC8xNC8xNCwgNDowMSBQTSwgIk93ZW4gRGVMb25nIiA8b3dlbkBkZWxvbmcuY29tPiB3cm90 ZToNCg0KDQo+V2UgY2FuIGFncmVlIHRvIGRpc2FncmVlLCBidXQgSSBmZWVsIHRoYXQgaW5mb3Jt aW5nIGEgaG9zdCBhYm91dCB0aGUNCj5hdmFpbGFiaWxpdHkgb2YgSVB2NCBjb25maWd1cmF0aW9u IHNlcnZpY2VzIHRocm91Z2ggYW4gSVB2NiBjb25maWd1cmF0aW9uDQo+c2VydmljZSBpcywgaW4g ZmFjdCwgYSB0ZWNobmljYWxseSBmbGF3ZWQgY29uY2VwdC4NCg0KSSBiZWxpZXZlIERIQyB3b3Vs ZCBiZWcgdG8gZGlmZmVyIHdpdGggeW91ciBvcGluaW9uOg0KaHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWRoYy1kaGNwdjQtb3Zlci1kaGNwdjYNCg0KaHR0cDovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRoYy1kaGNwdjQtb3Zlci1pcHY2DQoN Cg0KV2UgaGFkIGEgam9pbnQgbWVldGluZyB3aXRoIERIQyBpbiBCZXJsaW4gd2hlcmUgd2UgZGlz Y3Vzc2VkIHRoaXMsIGJlY2F1c2UNCndlIHdhbnRlZCB0byBlbnN1cmUgY29vcmRpbmF0aW9uIGJl dHdlZW4gdGhlIHR3byBncm91cHMgb24gbWF0dGVycyB3aGVyZQ0KdGhlcmUgaXMgaW50ZXJhY3Rp b24gYmV0d2VlbiBJUHY0IGFuZCBJUHY2IERIQ1AuDQpodHRwOi8vd3d3LmlldGYub3JnL3Byb2Nl ZWRpbmdzLzg3L3N1bnNldDQuaHRtbA0KDQpXZXMgR2VvcmdlDQoNCg0KVGhpcyBFLW1haWwgYW5k IGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJv cHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwg b3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBU aGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1 YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZp ZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rp b24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0 byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwu IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2lu YWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo= From nobody Mon Apr 14 13:21: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 13AC71A0213 for ; Mon, 14 Apr 2014 13:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.773 X-Spam-Level: X-Spam-Status: No, score=-0.773 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.272, 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 QFCSZrn-oIQc for ; Mon, 14 Apr 2014 13:21:25 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 66A001A0447 for ; Mon, 14 Apr 2014 13:21:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id E1595870074; Mon, 14 Apr 2014 22:21:19 +0200 (CEST) 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 q-lmumqgV4uP; Mon, 14 Apr 2014 22:21:19 +0200 (CEST) Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:7451:d3b8:2988:ba7f]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id AD1D787006F; Mon, 14 Apr 2014 22:21:19 +0200 (CEST) Message-ID: <534C432D.3060700@globis.net> Date: Mon, 14 Apr 2014 22:21:01 +0200 From: Ray Hunter User-Agent: Postbox 3.0.9 (Macintosh/20140129) MIME-Version: 1.0 To: Ted Lemon References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/VeFidQS5zZ7U2k8EpFiX7Vajpj0 Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 20:21:30 -0000 Ted Lemon wrote: > On Apr 14, 2014, at 2:30 PM, Owen DeLong wrote: >> Seems to me that the same potential for abuse exists with either situation. > > This is true, and the remedy exists as well. It's worth pointing out that "please review" doesn't mean "please redesign this." It means "please point out technical flaws that you see." None of what you or Nick has said sound like technical flaws to me—they sound like "I would prefer to do it this other way." > > The working group considered doing it that other way and decided that on the balance, the way it's written now is better. So unless there is some strong technical reason why it _shouldn't_ be done the way the working group has proposed, there's no basis for making a change. It's issues like that that we are looking for in a v6ops review. > > That we are discussing turning off IPv4 in both RA and DHCPv6 just highlights to me how ridiculous host configuration has become. To me this proposal just introduces all sorts of horrible race conditions and inconsistencies, and I'm not convinced it's any better than just configuring up IPv4 via DHCPv4 with either a self assigned address or an RFC 1918 address and saying nothing about remote connectivity (given that most OSes already have IPv4 detection mechanisms in place to work out whether they are on a corporate network with proxies or the Internet or on an isolated island or whatever.) e.g. what does a host do if RA says turn off IPv4, but DHCPv4 replies either before or after a host receives that RA advertisement? Does the host have to then disable IPv4 once it is already up? For how long? What if DHCPv6 and RA are not consistent (given they may not even be the same router or device responding)? What if one router is IPv4 only and the other IPv6 only? And they're from 2 different ISP providers connected to a common L2 LAN? That's a perfectly valid configuration in my opinion. Can an absence of "turn off IPv4" message be taken as a "turn on IPv4"? How would this be implemented consistently given RA is generally ICMP (kernel space) and DHCPv6 user space (daemon)? Given the O and M bit saga, what makes anyone think that this additional signalling will be any better? Why would any end host trust this message? IMHO the place to turn off or signal limited IPv4 connectivity is in DHCPv4 (if we ever even attempt to do that). -- Regards, RayH From nobody Mon Apr 14 13:34: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 D01241A06F4 for ; Mon, 14 Apr 2014 13:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 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.272, 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 TELRCty5CQIK for ; Mon, 14 Apr 2014 13:34:12 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id F244E1A021F for ; Mon, 14 Apr 2014 13:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5735; q=dns/txt; s=iport; t=1397507650; x=1398717250; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Tsti3MsOMD/kiCDbKbFhNwryorWPyYWAWJcGa8mUUtc=; b=b6MqhqspYN5m2FFrxGCdQcZn2gpR8ltTh6Mj2hmKpCfKFe1vi0iiS3U7 7dOKOQMRbi1Ee+xvWoNTAXcjV4bHq8Niv3v8DKcHPlM3GXmwgaJ4WmahR 9fNhnhCxBOnDDxYyGbEMfZFtd2h8cpNXJ7hdM7ULIPqLLUg4zNV5gHdsv g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAH9FTFOtJA2H/2dsb2JhbABZgwY7V7t5hzWBJxZ0giUBAQEDAQEBATc0CwUHBAIBCBEEAQEBChQJBycLFAkIAgQBDQUIDAeHWQgNy3oTBI49MQcGgx6BFASUdJYwgzGBaSQe X-IronPort-AV: E=Sophos;i="4.97,859,1389744000"; d="scan'208";a="317635626" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-2.cisco.com with ESMTP; 14 Apr 2014 20:34:09 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3EKY9CO025842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Apr 2014 20:34:09 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.212]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Mon, 14 Apr 2014 15:34:08 -0500 From: "Bernie Volz (volz)" To: Ted Lemon , Owen DeLong Thread-Topic: [v6ops] Please review the No IPv4 draft Thread-Index: AQHPV/Dx0jm4+vJrr02ADXU7FejXCZsRRQJ8gABWeACAAAfpAIAAA3kAgAAXoQD//8+J4A== Date: Mon, 14 Apr 2014 20:34:08 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AFE30A4@xmb-rcd-x04.cisco.com> References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <091F7BAB-2AAC-41B3-A67C-540482323E71@nominum.com> In-Reply-To: <091F7BAB-2AAC-41B3-A67C-540482323E71@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.242.239] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/QD9FYciDlInBfpzoT1IB2mcq-b4 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 20:34:14 -0000 >So you are proposing a massive change to the DHCPv4 protocol in order to a= rrange for it to be able to be turned off, rather than a minor change to th= e DHCPv6 protocol to signal that there is no IPv4 available. How does thi= s make sense? Are the changes really so massive? (In total, yes there probably is a lot o= f code to tweak, but that will happen if it is done on the IPv6 or IPv4 sid= e.) To add this to DHCPv4, we would need a new option code that a client that s= upports the new "DHCPTURNOFF" message (or whatever it is called) includes i= n the PRL. The server would then know it can send it (if applicable). For c= lients that don't support this feature, the server would likely just ignore= the packets (as if there was no server). I think the main reasons for considering using IPv6 were: 1. IPv6 components are more likely to be updated (many people would probabl= y prefer not to touch the v4 code if they don't have to anymore). Thus, thi= s change can be rolled out with other changes. 2. For v6 only deployments (where there is no v4), this does require SOME v= 4 (i.e., to deploy the server - though "link-local" v4 addresses would be p= erfectly usable). There may also be relays to configure (which involves yet= more v4) -- or new small server to implement to eliminate the relay. (If r= elays are used there might be some issues with whether all relays will rela= y the packet back to the client with the 'unknown' message type.) If you have v4 and v6 available on your network, there's no clear winner. I= f you have only v6 on your network, using v6 to signal this has advantages. There's one other minor consideration ... if v6 is used to signal this, it = can also be used for manually configured IPv4 hosts (though of course you c= ould just manually reconfigure those). - Bernie -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Monday, April 14, 2014 2:14 PM To: Owen DeLong Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft On Apr 14, 2014, at 11:49 AM, Owen DeLong wrote: > What is being proposed here would be more like responding to an IPv4 pack= et with an ICMP6 unreachable, which I'm pretty sure would be considered pro= blematic. Okay, let's consider your example as it relates to the discussion. Here w= e are talking about responding to an IPv6 packet with another IPv6 packet, = which contains information about the availability of IPv4 service on the lo= cal wire. In your example you are talking about responding to an IPv4 pac= ket with an IPv6 packet. So the two situations are not analogous. I agr= ee that if we were doing what you suggest in your example, that would be a = bad idea, because the association between an IPv4 and an IPv6 address is so= mething that would have to be inferred by the network, and that _would_ inv= olve a layering violation. But the actual use case we are talking about involves no such layering viol= ation. > Sure, so adding a form of NACK or DHCP-UNREACHABLE message to IPv4 makes = sense to me. So you are proposing a massive change to the DHCPv4 protocol in order to ar= range for it to be able to be turned off, rather than a minor change to the= DHCPv6 protocol to signal that there is no IPv4 available. How does this= make sense? > Why not, instead of using a DCHCPOFFER, provide an ICMPv4 DHCP-UNAVAILABL= E message which can be sent in response to a DHCPREQUEST message by any rou= ter which is configured to authoritatively deny DHCPv4 on the link? A host = receiving such a message should be expected to behave in an identical manne= r to the behavior proposed in this draft. ICMP !=3D DHCP. You just objected to the No IPv4 proposal (or Nick did) o= n the basis that it's hard for a DHCPv6 client to pass information to a DHC= Pv4 client (which, TBH, sounds like a bug to me). Why is it easier for th= e ICMP implementation in the kernel to pass information to the DHCPv4 clien= t? I have personal experience with this: there's code in the ISC DHCP ser= ver/client that has to catch bogus error messages pushed up the stack by th= e kernel and ignore them in order to avoid having its state machine broken,= because the kernel has no way to associate ICMP messages with particular d= atagram sources. My belief was that the kernel should discard such message= s, because it can't do anything useful with them, but the linux guys decide= d to deliver them; neither solution is really satisfactory. You are propos= ing to use this as a solution in favor of something that would actually wor= k reliably. That doesn't make sense. The reality is that one of the biggest problems with the configuration syst= em on linux is that the various components don't communicate with each othe= r in a useful way. Other operating systems manage to do a better job, and= there's work ongoing in the linux community to fix this problem (e.g., sys= temd is now pulling a lot of network stack functionality into it specifical= ly so that it can be part of the system configuration state machine as a wh= ole, and dnsmasq does something similar). So in reality it makes a tremendous amount of sense to put this information= in DHCPv6, and the concern that it may be difficult to communicate the inf= ormation to the IPv4 stack is a temporary situation that's easily addressed= . Putting it in IPv4 means more useless network traffic, more attack surf= aces on IPv6-only routers, etc. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Apr 14 13:43: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 644791A021F for ; Mon, 14 Apr 2014 13:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.263 X-Spam-Level: X-Spam-Status: No, score=-1.263 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.272, 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 7lynpvHbE4XG for ; Mon, 14 Apr 2014 13:43:50 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 90A421A0208 for ; Mon, 14 Apr 2014 13:43:49 -0700 (PDT) Received: from owens-mbp.meeting.arin.net (unknown.servercentral.net [50.31.214.180] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s3EKdwKW002211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 13:40:00 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3EKdwKW002211 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1397508001; bh=uC5ecC2bY3ZanKBk+RQ6UMlLWyA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=48VQRaQ/TZHNSNE1pbeBWR4wm2zg0EoKq9ZSjPTx2RtcoWeN46twsiReFeij30+IC QRagsa6mlejxVfq8rwhjb4L6r0+ZRXVBmtegFRvuqKsACJ1BAU/JeDITTXQh7AkjoK vfF2j3xxf5PoujUZ9A3LasD7kBJhYfXJxLVsjuq0= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: <534C40A5.9050302@viagenie.ca> Date: Mon, 14 Apr 2014 13:39:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1DA9DEFD-8BD8-45C2-AD82-339EF2A289B8@delong.com> References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <534C17B8.8030209@foobar.org> <534C27C9.80701@viagenie.ca> <3DFC20FF-E866-4E1C-B720-D7C91CBB925B@delong.com> <534C40A5.9050302@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 14 Apr 2014 13:40:01 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/0ctg_5DuRCtkMEuopIJijuoga7g Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 20:43:55 -0000 On Apr 14, 2014, at 1:10 PM, Simon Perreault = wrote: > Le 2014-04-14 15:52, Owen DeLong a =E9crit : >> Why wouldn=92t a network that does not offer IPv4 autoconfigration = not want to implement that option whether or not they do DHCPv6? >=20 > Not sure what you mean. Our draft does specify RA and DHCPv6 versions = of > the No-IPv4 option. Not responsive to the above statement. It is possible that there are = networks which do not implement IPv4 auto configuration that would want = to use this option that also do not do IPv6. For example, a statically = addressed IPv4 Wireless network may want to turn off clients sending = DHCP discovers. >> This is all about the unavailability of IPv4 auto configuration on = the network. It has nothing inherently to do with IPv6 except that IPv6 = is the most likely alternative to IPv4 that would be used. However, = that=92s just a likely majority use case, not the sole use case. >=20 > Look, if IPv7 was a thing I would totally agree with you. It's not, so > what you're saying sounds like theoretical orthodoxy. We're trying to > fix real problems with moving to IPv6-only. I totally don't care about > non-IPv6 and non-IPv4 networks. And I don't see why anyone should. I am not sure how IPv7 got inserted into this, but whatever=85 I=92m = talking about the fact that this option could, in fact, be useful for = some IPv4-only networks as well. Non-IPv4 is not the same as IPv4 with = no auto configuration. This isn=92t about turning off IPv4, this is = about turning off IPv4 auto configuration unless I completely = misunderstand the draft in question. Owen From nobody Mon Apr 14 13:44: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 A48881A0717 for ; Mon, 14 Apr 2014 13:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 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.272, 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 oIVOb5HV4RDf for ; Mon, 14 Apr 2014 13:44:51 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id BF3241A0694 for ; Mon, 14 Apr 2014 13:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6614; q=dns/txt; s=iport; t=1397508288; x=1398717888; h=from:to:cc:subject:date:message-id:references: content-transfer-encoding:mime-version; bh=QLWtBaUVcUen54U71PDgCk98Yapy8JTkuhjoTXlsttc=; b=LNlv3f88Xe0kWw75wWZYi8eD9wamJgiVI828O01Hs7aodb+H7RKhTlYx 8jpj9VRuVxqe1Rgn3MNwnc66HkvXCPff9ZKeykCL19knJPxzJH5nFtsc5 HKfqyoxlato4v/eFeRrEiYbSXb5Yaf3H+mCKHmbRD825GvOXcCbtjtnwJ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFACRITFOtJA2M/2dsb2JhbABZgwY7V7t7hzWBJxZ0giUBAQEDAQEBATc0CwUHBAIBCBEEAQEBChQJBycLFAkIAgQBDQUIDAeHWQgNzAUTBI49MQ2DHoEUBJR0ljCDMYFpJB4 X-IronPort-AV: E=Sophos;i="4.97,859,1389744000"; d="scan'208";a="35728746" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP; 14 Apr 2014 20:44:47 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s3EKil8q013186 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Apr 2014 20:44:47 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.212]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Mon, 14 Apr 2014 15:44:47 -0500 From: "Bernie Volz (volz)" To: Ted Lemon , Owen DeLong Thread-Topic: [v6ops] Please review the No IPv4 draft Thread-Index: AQHPV/Dx0jm4+vJrr02ADXU7FejXCZsRRQJ8gABWeACAAAfpAIAAA3kAgAAXoQD//8+J4IAABSXg Date: Mon, 14 Apr 2014 20:44:47 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AFE3163@xmb-rcd-x04.cisco.com> References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <091F7BAB-2AAC-41B3-A67C-540482323E71@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.242.239] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/C5NB_R-t3sfsmD5QjDFPPBH71JE Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 20:44:55 -0000 BTW: How significant is the problem anyway? Has this been analyzed by anyon= e? Sure, the clients broadcast these packets but this is the "good" direction = in Wifi - the Wifi 'switch' can be told to drop them. Other switches can to= ? Seems to me that this would be far better to leave to the networking infras= tructure to just 'block' the DHCPv4 packets if IPv4 isn't enabled? Or are there networks where the periodic DHCPv4 DHCPDISCOVERs will end up c= osting significant overhead? I suspect many access networks (i.e. DOCSIS - the IP Provisioning Mode TLV)= already provide some information about whether v4, v6, or both are availab= le? - Bernie -----Original Message----- From: Bernie Volz (volz)=20 Sent: Monday, April 14, 2014 4:34 PM To: 'Ted Lemon'; Owen DeLong Cc: v6ops@ietf.org Subject: RE: [v6ops] Please review the No IPv4 draft >So you are proposing a massive change to the DHCPv4 protocol in order to a= rrange for it to be able to be turned off, rather than a minor change to th= e DHCPv6 protocol to signal that there is no IPv4 available. How does thi= s make sense? Are the changes really so massive? (In total, yes there probably is a lot o= f code to tweak, but that will happen if it is done on the IPv6 or IPv4 sid= e.) To add this to DHCPv4, we would need a new option code that a client that s= upports the new "DHCPTURNOFF" message (or whatever it is called) includes i= n the PRL. The server would then know it can send it (if applicable). For c= lients that don't support this feature, the server would likely just ignore= the packets (as if there was no server). I think the main reasons for considering using IPv6 were: 1. IPv6 components are more likely to be updated (many people would probabl= y prefer not to touch the v4 code if they don't have to anymore). Thus, thi= s change can be rolled out with other changes. 2. For v6 only deployments (where there is no v4), this does require SOME v= 4 (i.e., to deploy the server - though "link-local" v4 addresses would be p= erfectly usable). There may also be relays to configure (which involves yet= more v4) -- or new small server to implement to eliminate the relay. (If r= elays are used there might be some issues with whether all relays will rela= y the packet back to the client with the 'unknown' message type.) If you have v4 and v6 available on your network, there's no clear winner. I= f you have only v6 on your network, using v6 to signal this has advantages. There's one other minor consideration ... if v6 is used to signal this, it = can also be used for manually configured IPv4 hosts (though of course you c= ould just manually reconfigure those). - Bernie -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Monday, April 14, 2014 2:14 PM To: Owen DeLong Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft On Apr 14, 2014, at 11:49 AM, Owen DeLong wrote: > What is being proposed here would be more like responding to an IPv4 pack= et with an ICMP6 unreachable, which I'm pretty sure would be considered pro= blematic. Okay, let's consider your example as it relates to the discussion. Here w= e are talking about responding to an IPv6 packet with another IPv6 packet, = which contains information about the availability of IPv4 service on the lo= cal wire. In your example you are talking about responding to an IPv4 pac= ket with an IPv6 packet. So the two situations are not analogous. I agr= ee that if we were doing what you suggest in your example, that would be a = bad idea, because the association between an IPv4 and an IPv6 address is so= mething that would have to be inferred by the network, and that _would_ inv= olve a layering violation. But the actual use case we are talking about involves no such layering viol= ation. > Sure, so adding a form of NACK or DHCP-UNREACHABLE message to IPv4 makes = sense to me. So you are proposing a massive change to the DHCPv4 protocol in order to ar= range for it to be able to be turned off, rather than a minor change to the= DHCPv6 protocol to signal that there is no IPv4 available. How does this= make sense? > Why not, instead of using a DCHCPOFFER, provide an ICMPv4 DHCP-UNAVAILABL= E message which can be sent in response to a DHCPREQUEST message by any rou= ter which is configured to authoritatively deny DHCPv4 on the link? A host = receiving such a message should be expected to behave in an identical manne= r to the behavior proposed in this draft. ICMP !=3D DHCP. You just objected to the No IPv4 proposal (or Nick did) o= n the basis that it's hard for a DHCPv6 client to pass information to a DHC= Pv4 client (which, TBH, sounds like a bug to me). Why is it easier for th= e ICMP implementation in the kernel to pass information to the DHCPv4 clien= t? I have personal experience with this: there's code in the ISC DHCP ser= ver/client that has to catch bogus error messages pushed up the stack by th= e kernel and ignore them in order to avoid having its state machine broken,= because the kernel has no way to associate ICMP messages with particular d= atagram sources. My belief was that the kernel should discard such message= s, because it can't do anything useful with them, but the linux guys decide= d to deliver them; neither solution is really satisfactory. You are propos= ing to use this as a solution in favor of something that would actually wor= k reliably. That doesn't make sense. The reality is that one of the biggest problems with the configuration syst= em on linux is that the various components don't communicate with each othe= r in a useful way. Other operating systems manage to do a better job, and= there's work ongoing in the linux community to fix this problem (e.g., sys= temd is now pulling a lot of network stack functionality into it specifical= ly so that it can be part of the system configuration state machine as a wh= ole, and dnsmasq does something similar). So in reality it makes a tremendous amount of sense to put this information= in DHCPv6, and the concern that it may be difficult to communicate the inf= ormation to the IPv4 stack is a temporary situation that's easily addressed= . Putting it in IPv4 means more useless network traffic, more attack surf= aces on IPv6-only routers, etc. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Apr 14 14:07: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 76A841A022D for ; Mon, 14 Apr 2014 14:07:14 -0700 (PDT) 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 APGUr34ECSZf for ; Mon, 14 Apr 2014 14:07:12 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id C53111A0224 for ; Mon, 14 Apr 2014 14:07:11 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s3EL73vo079794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 14 Apr 2014 22:07:04 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <534C4DF7.4070407@foobar.org> Date: Mon, 14 Apr 2014 22:07:03 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ted Lemon References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/EjnEckv_EsRvSKlWtdsBXuSbXpk Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 14 Apr 2014 21:07:14 -0000 On 14/04/2014 20:42, Ted Lemon wrote: > The working group considered doing it that other way and decided that on > the balance, the way it's written now is better. Ted, there seems to have been relatively little discussion about this point. There's nothing in any of the sunset4 mailing lists, and the only reference I can find to not using dhcpv4 for this purpose were the presentation and minutes at ietf84, neither of which devoted much attention to the problem, as far as I can see. > https://tools.ietf.org/agenda/84/slides/slides-84-sunset4-9.pdf > https://tools.ietf.org/wg/sunset4/minutes?item=minutes-84-sunset4.html I may be missing something though. Nick From nobody Mon Apr 14 20:12: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 D12B41A0643 for ; Mon, 14 Apr 2014 20:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 r2EfeStFEYp0 for ; Mon, 14 Apr 2014 20:12:36 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 96CB61A02FC for ; Mon, 14 Apr 2014 20:12:36 -0700 (PDT) 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 30F661B805A for ; Mon, 14 Apr 2014 20:12:34 -0700 (PDT) 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 00A7919005C; Mon, 14 Apr 2014 20:12:34 -0700 (PDT) Received: from [192.168.146.119] (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, 14 Apr 2014 20:12:34 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <3AAA3A70-1513-4163-A841-45FEFC95004C@delong.com> Date: Mon, 14 Apr 2014 22:12:30 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <230F179C-D5F3-4FB5-B068-C06549631BA7@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <091F7BAB-2AAC-41B3-A67C-540482323E71@nominum.com> <3AAA3A70-1513-4163-A841-45FEFC95004C@delong.com> To: Owen DeLong X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/i-L_vZuY65q-OWD8i77DFeXsqWw Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 03:12:41 -0000 On Apr 14, 2014, at 2:49 PM, Owen DeLong wrote: > Please explain to me why this is any more massive of a change to = DHCPv4 than it would be to DHCPv6. Because you are changing the protocol state machine. From nobody Mon Apr 14 20:15: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 5E1751A02FC for ; Mon, 14 Apr 2014 20:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 GPzBFpBjTufG for ; Mon, 14 Apr 2014 20:15:29 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 30D8D1A02F6 for ; Mon, 14 Apr 2014 20:15:29 -0700 (PDT) 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 CE9001B805A for ; Mon, 14 Apr 2014 20:15:26 -0700 (PDT) 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 C365B19005C; Mon, 14 Apr 2014 20:15:26 -0700 (PDT) Received: from [192.168.146.119] (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, 14 Apr 2014 20:15:26 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <20140414201231.GZ43641@Space.Net> Date: Mon, 14 Apr 2014 22:15:23 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <23F575A3-E00D-410E-9929-7377B7CAA623@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <534C17B8.8030209@foobar.org> <534C27C9.80701@viagenie.ca> <20140414194824.GY43641@Space.Net> <534C3F7D.3040406@viagenie.ca> <20140414201231.GZ43641@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/k9m54nMg7GKtwekotfDJM5h3JpI Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 03:15:33 -0000 On Apr 14, 2014, at 3:12 PM, Gert Doering wrote: > There are at least 3 different IPv4 DHCP clients on "Unix", and the > author and maintainer of the IPv6 DHCP client that is installed might > not know which IPv4 DHCP client you're using. This is not something to brag about. Network configuration works badly = on machines that operate this way. I say this as the author of one of = those DHCP clients. This problem needs to be fixed, not papered over, = and using it as an excuse to do the wrong thing in a protocol spec is = absurd. From nobody Mon Apr 14 20:17: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 B71071A02FC for ; Mon, 14 Apr 2014 20:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 6TqduUnG8zU4 for ; Mon, 14 Apr 2014 20:17:27 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id ED1C81A02F6 for ; Mon, 14 Apr 2014 20:17:26 -0700 (PDT) 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 98D201B803E for ; Mon, 14 Apr 2014 20:17:24 -0700 (PDT) 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 8A6E719005C; Mon, 14 Apr 2014 20:17:24 -0700 (PDT) Received: from [192.168.146.119] (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, 14 Apr 2014 20:17:18 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <534C432D.3060700@globis.net> Date: Mon, 14 Apr 2014 22:17:15 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <51F06435-CA02-4B65-8484-51687A35CB29@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> <534C432D.3060700@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/aGVCkTw05DIE-cCb3XwnfsQUBWA Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 03:17:29 -0000 On Apr 14, 2014, at 3:21 PM, Ray Hunter wrote: > e.g. what does a host do if RA says turn off IPv4, but DHCPv4 replies = either before or after a host receives that RA advertisement? > Does the host have to then disable IPv4 once it is already up? For how = long? The network is mismanaged or under attack. Fix it. From nobody Mon Apr 14 20:23:18 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 0D48B1A0515 for ; Mon, 14 Apr 2014 20:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 TNz-VJi6ggke for ; Mon, 14 Apr 2014 20:23:16 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 13FD91A02FC for ; Mon, 14 Apr 2014 20:23:16 -0700 (PDT) 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 A7DB01B803E for ; Mon, 14 Apr 2014 20:23:13 -0700 (PDT) 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 9DDB919005C; Mon, 14 Apr 2014 20:23:13 -0700 (PDT) Received: from [192.168.146.119] (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, 14 Apr 2014 20:23:13 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <534C4DF7.4070407@foobar.org> Date: Mon, 14 Apr 2014 22:23:11 -0500 Content-Transfer-Encoding: 7bit Message-ID: <40E2438A-C43F-4E41-8778-511E53EF7009@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> <534C4DF7.4070407@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/uhgbmE1TfY0JqLKzPaE64n_MavU Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 03:23:17 -0000 On Apr 14, 2014, at 4:07 PM, Nick Hilliard wrote: > I may be missing something though. You are, and I believe Simon already mentioned what it was. From nobody Mon Apr 14 21:21: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 E47D51A02FF for ; Mon, 14 Apr 2014 21:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 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.272, 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 Jtc-G283KwWB for ; Mon, 14 Apr 2014 21:20:59 -0700 (PDT) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 7507A1A02F0 for ; Mon, 14 Apr 2014 21:20:59 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n16so10284092oag.31 for ; Mon, 14 Apr 2014 21:20:56 -0700 (PDT) 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=6lpxkSG5zBPtOrcUKz0jnaEHyS6fJQKUdQ6l15VQbH8=; b=fHieUjP7VLbv3PKhPYecN5CCVjd4p8ufoEDkIzyZe6cLGuHGzY3pFZesT0msDvlr0Y mJrKKWoQg9eAVC4VeLK2d6vYancZVXwdEcQyqUTKENX0PYAgjzk2xSIVcgDAmu4RaXdS d06vt3Tm3mPr1gm28PWfArSMS8tGXknEhHaPILUzk6hO6iRPZAZ0NiRImieTLvveETZN L3+HMXHh+5YhIB96W1JAmYBoAa1hnGAaPnns+YtDftk8ma+P71zFXBkZY3nA9qyVD7fA jqSyUM13AjvYiqRoHJPSDZHlm4J4BVBr6c0Ny6bdHnKX9K8zw28Wnpc090ob6JIQxqzg tfFg== 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=6lpxkSG5zBPtOrcUKz0jnaEHyS6fJQKUdQ6l15VQbH8=; b=itIjAgTqGDUebFhP3JDRoZUX+K0xce+HjtQc3gGhHwLZtVcyUr61xHlu8b3qu3wRxf Dqo2dq17xPIOjw7D7u01bMNCsyw6jYPPgCkgIiWGy5zfdX7RZanEt3Aji3K2SI43gcNT P96L4sY2BZTbGAS0AK3wJHBkBXmS/lGrYNmhsAyFon2FNAeUhrW3s0It/SYoNwC96sMD u7/Hx1rf/dnc4kubKunJMIWbLOves4FRvwyWTE4sDn4Y3L+l8A0tcLoVU9QiDLnjMoNc AfsPe1x3QKXDZIJVhiZHuhOXghFpONJUDbkAtrjfjdHLHroFbWiaHI+mxkSvBM5i5YVS v+Cw== X-Gm-Message-State: ALoCoQn4GADf26UmeVfoYqjJhCtIAG3tkiYQjTWowe5KgmlgO3Dv/WKs5zTJmB8fPBR6R0nzBWJcOGqQW5GldP4b+p9JCk9s5/M3eELtH1hEAsVn9UFUdBOHanR1nECtnrIZawlsP51tTRFkJ/ZK2s34EXXaSGFLNlmn+9Gz2qMirbBCbuZu59qnU0QD+90usX4m2AAGaXOD X-Received: by 10.182.142.229 with SMTP id rz5mr38294940obb.12.1397535656487; Mon, 14 Apr 2014 21:20:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.89.229 with HTTP; Mon, 14 Apr 2014 21:20:36 -0700 (PDT) In-Reply-To: <534BF5A5.5010609@viagenie.ca> References: <534BF5A5.5010609@viagenie.ca> From: Lorenzo Colitti Date: Tue, 15 Apr 2014 13:20:36 +0900 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=001a11c362e65ddd3c04f70d205e Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/udSvGPETo9pyIN6c2zYqSsGFxcw Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 04:21:04 -0000 --001a11c362e65ddd3c04f70d205e Content-Type: text/plain; charset=UTF-8 On Mon, Apr 14, 2014 at 11:50 PM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > In a nutshell, it defines DHCPv6 and RA options indicating to the host > that IPv4 is not available. Reviews from operations-minded people in > V6OPS would be of tremendous help. > I don't see a strong use case for this. It seems to me that the two scenarios in the introduction can be solved by simply configuring the DHCPv4 relay (or the server, if on-link) to drop all DHCPv4 requests. Am I missing something? --001a11c362e65ddd3c04f70d205e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On M= on, Apr 14, 2014 at 11:50 PM, Simon Perreault <simon.perreault@v= iagenie.ca> wrote:
    In a nutshell, it defines DHCPv6 and RA opti= ons indicating to the host
    that IPv4 is not available. Reviews from operations-minded people in
    V6OPS would be of tremendous help.

    I do= n't see a strong use case for this. It seems to me that the two scenari= os in the introduction can be solved by simply configuring the DHCPv4 relay= (or the server, if on-link) to drop all DHCPv4 requests.

    Am I missing something?
    --001a11c362e65ddd3c04f70d205e-- From nobody Mon Apr 14 21:53: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 4E5701A06B1 for ; Mon, 14 Apr 2014 21:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.263 X-Spam-Level: X-Spam-Status: No, score=-1.263 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.272, 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 TQuu5W5jy5KY for ; Mon, 14 Apr 2014 21:53:42 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 994161A06A3 for ; Mon, 14 Apr 2014 21:53:41 -0700 (PDT) Received: from [192.168.2.102] (ip-64-134-38-51.public.wayport.net [64.134.38.51]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s3F4oBnF031599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 21:50:13 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3F4oBnF031599 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1397537415; bh=6qgU205E6wt3M0ODheyqo7kU9iU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=lLBZ+1xUpH+bQvLX1oFFb1Ket4odgJNd5h9M2Dtpk7S0bITNAQBSThONFEJ36/13L 7PID/t84H0UtIeHo9/khE3ZWAIaT+sGqp4VNkBhOLF+734sZLp7hmOqw92Sr/3O6Hk d+TlBcJ6QMCnn83k0HvSUO61x0utkB7O9y+mJ/xI= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: <230F179C-D5F3-4FB5-B068-C06549631BA7@nominum.com> Date: Mon, 14 Apr 2014 21:50:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <091F7BAB-2AAC-41B3-A67C-540482323E71@nominum.com> <3AAA3A70-1513-4163-A841-45FEFC95004C@delong.com> <230F179C-D5F3-4FB5-B068-C06549631BA7@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 14 Apr 2014 21:50:15 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/pP4HNKJVlyrfus9UOUqr2SUuBSY Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 04:53:43 -0000 On Apr 14, 2014, at 8:12 PM, Ted Lemon wrote: > On Apr 14, 2014, at 2:49 PM, Owen DeLong wrote: >> Please explain to me why this is any more massive of a change to = DHCPv4 than it would be to DHCPv6. >=20 > Because you are changing the protocol state machine. So, you=92re saying having some external process kill the DHCP4 client = in response to a message received via DHCPv6 is less of a change to the = protocol state machine than having DHCPv4 client die in response to a = similar message=85 Right. Owen From nobody Mon Apr 14 21:53: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 564ED1A06D0 for ; Mon, 14 Apr 2014 21:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.263 X-Spam-Level: X-Spam-Status: No, score=-1.263 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.272, 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 nPANgPriOGn4 for ; Mon, 14 Apr 2014 21:53:43 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id B164D1A06A3 for ; Mon, 14 Apr 2014 21:53:43 -0700 (PDT) Received: from [192.168.2.102] (ip-64-134-38-51.public.wayport.net [64.134.38.51]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s3F4oBnG031599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 21:51:08 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3F4oBnG031599 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1397537470; bh=qupH10jybexjZGYFL7stt1fEo8g=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=FpN5vDV5uArLQZ5tH54EnFPpPpKueoOHWYp7rmTfVLG/aSIFz9SARDqc81iar2Fzk dpcb1VnE4QIQsCmFqN//PEs4dkkNYY3jBsOeShD3WXobhD3pSgfyUvdX9TD/bqHuw7 mMITaXiObQ0VGEkoLJ4GWAzaFettNi+g3/+Tn7Do= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: <23F575A3-E00D-410E-9929-7377B7CAA623@nominum.com> Date: Mon, 14 Apr 2014 21:51:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <82E804C3-725D-415A-87C3-512073774C6F@delong.com> References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <534C17B8.8030209@foobar.org> <534C27C9.80701@viagenie.ca> <20140414194824.GY43641@Space.Net> <534C3F7D.3040406@viagenie.ca> <20140414201231.GZ43641@Space.Net> <23F575A3-E00D-410E-9929-7377B7CAA623@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 14 Apr 2014 21:51:09 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/D_AZUL3HaZt1bi3lEHJ316Yl1Ic Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 04:53:47 -0000 On Apr 14, 2014, at 8:15 PM, Ted Lemon wrote: > On Apr 14, 2014, at 3:12 PM, Gert Doering wrote: >> There are at least 3 different IPv4 DHCP clients on "Unix", and the >> author and maintainer of the IPv6 DHCP client that is installed might >> not know which IPv4 DHCP client you're using. >=20 > This is not something to brag about. Network configuration works = badly on machines that operate this way. I say this as the author of = one of those DHCP clients. This problem needs to be fixed, not papered = over, and using it as an excuse to do the wrong thing in a protocol spec = is absurd. Calling it the wrong thing while advocating an even more wrong thing is = equally absurd. Owen From nobody Mon Apr 14 23:08: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 07B7B1A0743 for ; Mon, 14 Apr 2014 23:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 LyDnxOpuicZ9 for ; Mon, 14 Apr 2014 23:08:21 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id D7BD41A06C9 for ; Mon, 14 Apr 2014 23:08:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id B5890870074; Tue, 15 Apr 2014 08:08:17 +0200 (CEST) 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 m04tDYRGRn4S; Tue, 15 Apr 2014 08:08:17 +0200 (CEST) Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:7daa:d497:b80b:8b11]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 7901187006F; Tue, 15 Apr 2014 08:08:17 +0200 (CEST) Message-ID: <534CCCCF.9040000@globis.net> Date: Tue, 15 Apr 2014 08:08:15 +0200 From: Ray Hunter User-Agent: Postbox 3.0.9 (Macintosh/20140129) MIME-Version: 1.0 To: Ted Lemon References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> <534C432D.3060700@globis.net> <51F06435-CA02-4B65-8484-51687A35CB29@nominum.com> In-Reply-To: <51F06435-CA02-4B65-8484-51687A35CB29@nominum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/HrsWdTDTMyC1UTLT4THkpcDg8sM Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 06:08:26 -0000 > Ted Lemon > 15 April 2014 05:17 > > The network is mismanaged or under attack. Fix it. > See Homenet Architecture 3.2.2.2. B: Two ISPs, Two CERs, Shared subnet. http://tools.ietf.org/html/draft-ietf-homenet-arch-13#page-18 What when one ISP says "No IPv4 Service" whilst the other ISP says "Yes IPv4, and here's your address"? This is NOT a misconfiguration IMHO, but a weakness in the assumptions lying behind this draft i.e. that all routers on a link are managed by one self-consistent management entity for both IPv6 and IPv4. > Ray Hunter > 14 April 2014 22:21 > > > > > That we are discussing turning off IPv4 in both RA and DHCPv6 just > highlights to me how ridiculous host configuration has become. > > To me this proposal just introduces all sorts of horrible race > conditions and inconsistencies, and I'm not convinced it's any better > than just configuring up IPv4 via DHCPv4 with either a self assigned > address or an RFC 1918 address and saying nothing about remote > connectivity (given that most OSes already have IPv4 detection > mechanisms in place to work out whether they are on a corporate > network with proxies or the Internet or on an isolated island or > whatever.) > > e.g. what does a host do if RA says turn off IPv4, but DHCPv4 replies > either before or after a host receives that RA advertisement? > Does the host have to then disable IPv4 once it is already up? For how > long? > > What if DHCPv6 and RA are not consistent (given they may not even be > the same router or device responding)? > > What if one router is IPv4 only and the other IPv6 only? And they're > from 2 different ISP providers connected to a common L2 LAN? That's a > perfectly valid configuration in my opinion. > > Can an absence of "turn off IPv4" message be taken as a "turn on IPv4"? > > How would this be implemented consistently given RA is generally ICMP > (kernel space) and DHCPv6 user space (daemon)? > > Given the O and M bit saga, what makes anyone think that this > additional signalling will be any better? > > Why would any end host trust this message? > > IMHO the place to turn off or signal limited IPv4 connectivity is in > DHCPv4 (if we ever even attempt to do that). > > ------------------------------------------------------------------------ -- Regards, RayH From nobody Tue Apr 15 01: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 C4B6C1A031D for ; Tue, 15 Apr 2014 01:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.272, 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 fpRW8hK5gaUj for ; Tue, 15 Apr 2014 01:01:32 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 16B6C1A028F for ; Tue, 15 Apr 2014 01:01:31 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 74946A3; Tue, 15 Apr 2014 10:01:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 6A20CA2; Tue, 15 Apr 2014 10:01:27 +0200 (CEST) Date: Tue, 15 Apr 2014 10:01:27 +0200 (CEST) From: Mikael Abrahamsson To: Ray Hunter In-Reply-To: <534CCCCF.9040000@globis.net> Message-ID: References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> <534C432D.3060700@globis.net> <51F06435-CA02-4B65-8484-51687A35CB29@nominum.com> <534CCCCF.9040000@globis.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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/k1iykYpSRoeMNShRf6mm0_isaPw Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 08:01:37 -0000 On Tue, 15 Apr 2014, Ray Hunter wrote: > See Homenet Architecture 3.2.2.2. B: Two ISPs, Two CERs, Shared subnet. > http://tools.ietf.org/html/draft-ietf-homenet-arch-13#page-18 > > What when one ISP says "No IPv4 Service" whilst the other ISP says "Yes IPv4, > and here's your address"? Then you will still have IPv4 within the home, but just a single subnet. Perhaps the flag should be "IPv4 service available from me", and should be thought of as per-router based in the context of MIF. If all RAs seen has "0" on the IPv4 available option, then don't ask for IPv4. Yes, this is a problem if "ships-in-the-night" approach is done, and IPv4 and IPv6 is done by different routers. Perhaps the flag should be seen as a hint, approximately the same as the M flag, and if it's set to 0 then stop doing DHCPv4 after 1 minute if you don't get an answer? > This is NOT a misconfiguration IMHO, but a weakness in the assumptions lying > behind this draft i.e. that all routers on a link are managed by one > self-consistent management entity for both IPv6 and IPv4. As far as I can see, there is no good solution to the goal of indicating that IPv4 is available or not. There are just subjective opinion what is least bad. I think it's good we're discussing it. >From what I can tell, explicitly telling DHCPv4 that there isn't IPv4 available has a use-case, but also a way to turn DHCPv4 back on at a later date, and unless we come up with a new mechanism, this isn't available unless we do it with the existing IPv6 mechanisms. So, what's the least evil here? Updating IPv4 software functionality or extend existing IPv6 ones? I think the draft is a good summary of the options we have. Clarification what should be done when there is non-congruent information sent by different routers in their RAs is needed, however. I actually don't have a strong opinion either way, both solutions on their own have drawbacks. Only way to really solve this would be to have DHCPv4 gain "no IPv4 address available here" and also IPv6 gain hint flag as to if IPv4 is available or not, and this wouldn't be 100% deterministic. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Apr 15 01:25: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 2B4461A03F1 for ; Tue, 15 Apr 2014 01:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 bDjYWiFEuc6c for ; Tue, 15 Apr 2014 01:25:12 -0700 (PDT) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id BEEDF1A06E0 for ; Tue, 15 Apr 2014 01:25:11 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id b13so9065869wgh.17 for ; Tue, 15 Apr 2014 01:25:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:message-id:from:to:cc:subject:in-reply-to :references:user-agent:mime-version:content-type; bh=DZBPYHaIWVqh2U26bCDqi963iL3IkNEKhZkVoI2+R4k=; b=OdjeYJCih2myBx5KlrN7caT9eedrAJMip0vQHbI8J3TteFFlQgT8wnEnFehc6OqqqG TcuCVG0IawCCeC0tv94FBf2ad67rSPEf9x1B0Ls4Pa1gxHqEUaZxS2D5jB97jcPb3wTd BCADv+xiZw4oX62damNXZbax8suPt27fnqPUA/YMIq51zVVWnEAByJ4/wVn9kZEqtiyZ Am23zGNO3HvQavoaW7mraooNJRucjCaGyUfxcLj+01px9YGtQicAmH/NIxGPsendpLzQ eWSI3Un4wo/szvHHiRu0cqEocFQ7HPIpqcWFDs8d8qG4wENtvLRLoki05W4GSHMLACuU o04Q== X-Gm-Message-State: ALoCoQmxMZXGclj8lCm+Bv4T8k6aA/prLWyZ+PflYKLfGVz8a2mqvyeOMqMyEM+r7v7PRPRj+RW6 X-Received: by 10.180.38.107 with SMTP id f11mr1310584wik.31.1397550308633; Tue, 15 Apr 2014 01:25:08 -0700 (PDT) Received: from dhcp-179.wlan.no8.be.ucd.ie ([2001:770:13f:1:f11a:6e23:68dd:5756]) by mx.google.com with ESMTPSA id km2sm28688920wjb.13.2014.04.15.01.25.07 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Apr 2014 01:25:08 -0700 (PDT) Date: Tue, 15 Apr 2014 09:25:02 +0100 Message-ID: From: "Niall O'Reilly" To: Lorenzo Colitti In-Reply-To: References: <534BF5A5.5010609@viagenie.ca> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/WXyEVqwzdL_vCjF_mzjIdOSHDuw Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 08:25:13 -0000 At Tue, 15 Apr 2014 13:20:36 +0900, Lorenzo Colitti wrote: > > I don't see a strong use case for this. You are not alone! > It seems to me that the two > scenarios in the introduction can be solved by simply configuring the > DHCPv4 relay (or the server, if on-link) to drop all DHCPv4 requests. Why go even that far? What's wrong with the minimalist solution of just not providing any DHCPv4 service, and leaving the client to pick a link-local IPv4 address? Is the noise/signal (stet!) ratio in client-generated traffic already so low that a few DHCPDISCOVERs per client would be noticeable? > Am I missing something? Or I? ATB Niall O'Reilly From nobody Tue Apr 15 01:27: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 44B381A031D for ; Tue, 15 Apr 2014 01:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.123 X-Spam-Level: X-Spam-Status: No, score=-4.123 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.272, 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 QSzYtJSsJkLt for ; Tue, 15 Apr 2014 01:27:45 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id E98151A02FD for ; Tue, 15 Apr 2014 01:27:44 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 66D8BA3; Tue, 15 Apr 2014 10:27:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5F0F6A2; Tue, 15 Apr 2014 10:27:41 +0200 (CEST) Date: Tue, 15 Apr 2014 10:27:41 +0200 (CEST) From: Mikael Abrahamsson To: Niall O'Reilly In-Reply-To: Message-ID: References: <534BF5A5.5010609@viagenie.ca> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KeBlKubuif3d_pIYrwZVh6oYZFk Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 08:27:49 -0000 On Tue, 15 Apr 2014, Niall O'Reilly wrote: > Is the noise/signal (stet!) ratio in client-generated traffic already > so low that a few DHCPDISCOVERs per client would be noticeable? If you have thousands of devices in the same domain, so yes. Also, you have to remember that some devices will try to ARP for "everything" when IPv4 is still turned on (using its IPv4 LL address). Having IPv4 be completely turned off on a LAN actually makes quite a lot of sense. So yes, there is a use-case. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Apr 15 01:31: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 5FC4E1A05E5 for ; Tue, 15 Apr 2014 01:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 aVxkt1Wt3F-I for ; Tue, 15 Apr 2014 01:30:58 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 863671A06E0 for ; Tue, 15 Apr 2014 01:30:57 -0700 (PDT) Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id B4274629D9 for ; Tue, 15 Apr 2014 10:30:54 +0200 (CEST) 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 7731B62991 for ; Tue, 15 Apr 2014 10:30:54 +0200 (CEST) Received: (qmail 10428 invoked by uid 1007); 15 Apr 2014 10:30:54 +0200 Date: Tue, 15 Apr 2014 10:30:54 +0200 From: Gert Doering To: Ted Lemon Message-ID: <20140415083054.GA43641@Space.Net> References: <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <534C17B8.8030209@foobar.org> <534C27C9.80701@viagenie.ca> <20140414194824.GY43641@Space.Net> <534C3F7D.3040406@viagenie.ca> <20140414201231.GZ43641@Space.Net> <23F575A3-E00D-410E-9929-7377B7CAA623@nominum.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VYtpT0p4un6JI1+2" Content-Disposition: inline In-Reply-To: <23F575A3-E00D-410E-9929-7377B7CAA623@nominum.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/UoQOshRTbG0NCz_R3VulOfWyuaY Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 08:31:03 -0000 --VYtpT0p4un6JI1+2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Apr 14, 2014 at 10:15:23PM -0500, Ted Lemon wrote: > On Apr 14, 2014, at 3:12 PM, Gert Doering wrote: > > There are at least 3 different IPv4 DHCP clients on "Unix", and the > > author and maintainer of the IPv6 DHCP client that is installed might > > not know which IPv4 DHCP client you're using. >=20 > This is not something to brag about. Network configuration works > badly on machines that operate this way. I say this as the author > of one of those DHCP clients. This problem needs to be fixed, not > papered over, and using it as an excuse to do the wrong thing in a > protocol spec is absurd. It's called "multiple independent implementations of the same spec", and I'm not sure what's wrong about it. Actually it's pretty good to have alternatives and competition there, if one of the implementations is buggy or lacking behind. Yes, it would be even nicer if all these implementations would use a common API so you could really just plug-replace them, and remote-control them, all in the same way - but *that* is not "part of the spec". 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 --VYtpT0p4un6JI1+2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBU0zuPt9WwGXkzn/FAQKQXRAAmpASMWwWA5lJIt0X8VPAR2gq1JPYUFxl IUlMZPR9Ew8fbWkvptV4q/RZTKs4eFIzruTyq8ZpzVEoVUbxCpseUT/qE0zffUlX ffRvyjM+b3OoQdYq0kxZo52EKYOjRIp5BwZ8Kcu1m1AvIAXppvQQdSdMZdYAR0fn NYFQ8WtMnz4udPK9zSt6sI6231BxUqDyEAOxtNGsOcvHfn6XHQzO1KR9svygSgAK YhhOgqWASQuRVbhV118plwvy0NAYLXLlTtChARbt/kb3hwr9bxgfblH4hGFVC8WI Fy2GAfJBe+87ZzIrg6j4dd29RSgzNS/jtm7GzXmAB88sfUHL2KW2/Di8LuQVv0+A 116bNFF/bJnQiPVmjyG/KY9hhbtuujc1be0TURHPnXB+4h+pzxa+xcS89BLMkhic YgzVNM334h50iq4LOwqPuEkL/PfdtT3RYRUiRZyqTeBa/iGvvMy5MXQ/59uCDlZM br4ibdI1b6A1uICSGfGsY9Mzu8/Jq5FrNvE0vCAqsuOT4eqD7wddHSg6oQ0WBvIB ES37ahL5Ybz2Li30t6cWdBVSUB3swhmcisBbM20vfH7Cagtss8/UIfBRX3M/jahu r6cMx2LoxW1O4SWGujOaaphBGOvj5p4I03GIx4HY5slKTUVggK+6G2zD/UjB9G0X eGytEAfqMIs= =gEtS -----END PGP SIGNATURE----- --VYtpT0p4un6JI1+2-- From nobody Tue Apr 15 01:36: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 8FA3B1A0745 for ; Tue, 15 Apr 2014 01:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 vOrgXiG-rcQy for ; Tue, 15 Apr 2014 01:36:19 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 772A81A0396 for ; Tue, 15 Apr 2014 01:36:19 -0700 (PDT) Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 257F2629C8 for ; Tue, 15 Apr 2014 10:36:16 +0200 (CEST) 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 E3F2D6297D for ; Tue, 15 Apr 2014 10:36:15 +0200 (CEST) Received: (qmail 11724 invoked by uid 1007); 15 Apr 2014 10:36:15 +0200 Date: Tue, 15 Apr 2014 10:36:15 +0200 From: Gert Doering To: Mikael Abrahamsson Message-ID: <20140415083615.GB43641@Space.Net> References: <534BF5A5.5010609@viagenie.ca> 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) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Y9r0GTQnvaJGIctFjMD8uPHyu40 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 08:36:20 -0000 Hi, On Tue, Apr 15, 2014 at 10:27:41AM +0200, Mikael Abrahamsson wrote: > On Tue, 15 Apr 2014, Niall O'Reilly wrote: > > > Is the noise/signal (stet!) ratio in client-generated traffic already > > so low that a few DHCPDISCOVERs per client would be noticeable? > > If you have thousands of devices in the same domain, so yes. > > Also, you have to remember that some devices will try to ARP for > "everything" when IPv4 is still turned on (using its IPv4 LL address). > Having IPv4 be completely turned off on a LAN actually makes quite a lot > of sense. > > So yes, there is a use-case. I agree to this. Interestingly, this is something else than "just shutdown the dhcpv4 client if this option is detected" - it is "shutdown IPv4", which many OSes can't do today at all (and yes, that needs fixing). 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 nobody Tue Apr 15 01:54: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 8D53A1A03D4 for ; Tue, 15 Apr 2014 01:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.272, 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 D-lZ0x956zVk for ; Tue, 15 Apr 2014 01:54:00 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id E1CCC1A03F1 for ; Tue, 15 Apr 2014 01:53:59 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 20F8FA3; Tue, 15 Apr 2014 10:53:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1CE89A2; Tue, 15 Apr 2014 10:53:56 +0200 (CEST) Date: Tue, 15 Apr 2014 10:53:56 +0200 (CEST) From: Mikael Abrahamsson To: Gert Doering In-Reply-To: <20140415083615.GB43641@Space.Net> Message-ID: References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Clodr-JAh3KiF7jVgxD0zUgfg04 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 08:54:02 -0000 On Tue, 15 Apr 2014, Gert Doering wrote: > I agree to this. Interestingly, this is something else than "just > shutdown the dhcpv4 client if this option is detected" - it is "shutdown > IPv4", which many OSes can't do today at all (and yes, that needs > fixing). You're right. I just realised I implicitly thought that "shutdown DHCPv4" and "shutdown IPv4" is the same thing, but it isn't. So the flag should really be "of IPv4 and IPv6, use only IPv6" and I actually think this is ok to put in IPv6. I would prefer to see this information in RAs after thinking a bit more of this.. And I think it should be hints in the style of M and O flags, meaning the client can still try DHCPv4 for a short while if it really wants to, but it should listen to the hint if it doesn't see significant IPv4 traffic. Would it make sense to have a "deactivate IPv6 stack for the lifetime of this RA"-message as well? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Apr 15 02:01: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 113FD1A06AD for ; Tue, 15 Apr 2014 02:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 AbA-vRfhbYQr for ; Tue, 15 Apr 2014 02:01:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4103E1A0290 for ; Tue, 15 Apr 2014 02:01:31 -0700 (PDT) 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 BDC73544; Tue, 15 Apr 2014 09:01:27 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Apr 2014 10:00:05 +0100 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Apr 2014 10:01:24 +0100 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.77]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.03.0158.001; Tue, 15 Apr 2014 17:01:17 +0800 From: Tina TSOU To: Gert Doering , Mikael Abrahamsson Thread-Topic: [v6ops] Please review the No IPv4 draft Thread-Index: AQHPV/E98rBUqLIzeEOmeeRw+/Z2cJsRjhoAgABESwCAAAC+gIAAAmWAgACM3PA= Date: Tue, 15 Apr 2014 09:01:17 +0000 Message-ID: References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> In-Reply-To: <20140415083615.GB43641@Space.Net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.87.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Tg2NdiVjUwZP2bfZryPeHNq8B_A Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 09:01:40 -0000 Dear Gert et al, Should it be addressed in sunset4 WG? =20 Thank you, Tina -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Gert Doering Sent: Tuesday, April 15, 2014 4:36 PM To: Mikael Abrahamsson Cc: v6ops@ietf.org WG Subject: Re: [v6ops] Please review the No IPv4 draft Hi, On Tue, Apr 15, 2014 at 10:27:41AM +0200, Mikael Abrahamsson wrote: > On Tue, 15 Apr 2014, Niall O'Reilly wrote: >=20 > > Is the noise/signal (stet!) ratio in client-generated traffic=20 > > already so low that a few DHCPDISCOVERs per client would be noticeable= ? >=20 > If you have thousands of devices in the same domain, so yes. >=20 > Also, you have to remember that some devices will try to ARP for=20 > "everything" when IPv4 is still turned on (using its IPv4 LL address). > Having IPv4 be completely turned off on a LAN actually makes quite a=20 > lot of sense. >=20 > So yes, there is a use-case. I agree to this. Interestingly, this is something else than "just shutdown= the dhcpv4 client if this option is detected" - it is "shutdown IPv4", whi= ch many OSes can't do today at all (and yes, that needs fixing). 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 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Apr 15 02:02: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 581881A071D for ; Tue, 15 Apr 2014 02:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.272, 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 4JUew7Z-9BQU for ; Tue, 15 Apr 2014 02:02:51 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB1E1A0292 for ; Tue, 15 Apr 2014 02:02:51 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id DEECDA1; Tue, 15 Apr 2014 11:02:47 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D6FE79A; Tue, 15 Apr 2014 11:02:47 +0200 (CEST) Date: Tue, 15 Apr 2014 11:02:47 +0200 (CEST) From: Mikael Abrahamsson To: Tina TSOU In-Reply-To: Message-ID: References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8dopQYQle8TgmlTpoMED2TT6Tww Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 09:02:53 -0000 On Tue, 15 Apr 2014, Tina TSOU wrote: > Dear Gert et al, > > Should it be addressed in sunset4 WG? Sounds appropriate, yes. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Apr 15 04: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 8A3D41A0798 for ; Tue, 15 Apr 2014 04:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 0v8G4iB2PjG4 for ; Tue, 15 Apr 2014 04:25:00 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 7790D1A03C4 for ; Tue, 15 Apr 2014 04:24:59 -0700 (PDT) Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 2A7D4629DC for ; Tue, 15 Apr 2014 13:24:56 +0200 (CEST) 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 029C8629C5 for ; Tue, 15 Apr 2014 13:24:56 +0200 (CEST) Received: (qmail 41215 invoked by uid 1007); 15 Apr 2014 13:24:55 +0200 Date: Tue, 15 Apr 2014 13:24:55 +0200 From: Gert Doering To: Tina TSOU Message-ID: <20140415112455.GC43641@Space.Net> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wHN/osVXRAXX1q4W" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/W8EECM3NPod37wDciRv8YgGU4YY Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 11:25:01 -0000 --wHN/osVXRAXX1q4W Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Apr 15, 2014 at 09:01:17AM +0000, Tina TSOU wrote: > Should it be addressed in sunset4 WG? We're discussing a draft that came over from sunset4 for feedback. 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 --wHN/osVXRAXX1q4W Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBU00XB99WwGXkzn/FAQK1yBAAnz6MRL4nOUzSXrOU+jxNhxYooP0frG0E i5TePxDApdq1+WdDYxAbFQJmc3NqvzX4mykhurYOA18XkYeYLRrhVPuDkHfSZRiO Q9FPJK/DuR6A/s76cYz/iwcR3VFdujQCygCZidwt+iT42P8d3MmKff8w+DKqwEpK tsIZ+Rrf9DakXJQWxoIfkxXsthKhsLcyppDFantHI3pDVni5D5xCw6jrscZqQOsN ptI3/HDKEBSMQRJLIP+wPXFRJ7gFvwBOmZiaGCGUjaF1OoMnzAhXTg9bxtnuE3pc 8nSoFMuYYfoGbiQHsSG7Rdr7NStAv4NWxm3LxIjwFUKdV28r/saz6YDHGwR9g012 d/2tMtxwmtpei42tX970N68mEKjU/AOLICTW9digPfqMHSux8HKT6z7sZbNmPRco K9hK58heeXcZJhFJc+v1AmUQN80YvLt7G31/Uvqc8PBKBXKncb5HzmFlYPFxVWj9 ubZXTxSEo8h5GPNNL1XF32WLFATHEUnYKo9yQoKSe/L9OoYil8AqzYpWZgJD27/w qKd7n3WAdNJbrPVgPugjDRJkTJ1jlOBoTDbDZaxDRsFBPYfNKS8np4AKf/85fZXb NhdWGUr29v7OoDR6HwWFG/djFHowq2w31k0WVRrsZ5GUn/27seTAtaNqTAgFPIet gGtTfxA1LvI= =RvF/ -----END PGP SIGNATURE----- --wHN/osVXRAXX1q4W-- From nobody Tue Apr 15 04:34: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 CFE751A03CA for ; Tue, 15 Apr 2014 04:34:41 -0700 (PDT) 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 qpUGakiADF3w for ; Tue, 15 Apr 2014 04:34:40 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id ABB521A03C4 for ; Tue, 15 Apr 2014 04:34:39 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.dyn.netability.ie (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s3FBYZfw088226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 15 Apr 2014 12:34:35 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.dyn.netability.ie Message-ID: <534D1966.5090301@foobar.org> Date: Tue, 15 Apr 2014 12:35:02 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ted Lemon References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> <534C4DF7.4070407@foobar.org> <40E2438A-C43F-4E41-8778-511E53EF7009@nominum.com> In-Reply-To: <40E2438A-C43F-4E41-8778-511E53EF7009@nominum.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/O1Ik4qzch_c7qLo7kG_zlYczezQ Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 11:34:42 -0000 On 15/04/2014 04:23, Ted Lemon wrote: > You are, and I believe Simon already mentioned what it was. Email is proving a bad medium for communication here. Let me guess that you're referring to Simon's comment in his email of 2014-04-14 16:00:59 -0400, which was stated on page 4 of slides-84-sunset4-9.pdf: > Since the goal is going IPv6-only, a DHCPv4-based solution was > considered a deal-breaker and: > Must be transported over IPv6 > – > ...since the goal is eliminating IPv4 This is not an especially relevant argument because if there were a dhcpv4 option to handle this, all you would need to provide the service would be a local stub dhcpv4 mechanism to reply with a DHCPOFFER with a No Service option. There would be no requirement to back-haul the initial DHCPREQUEST to a centralised provisioning system. IOW, from an operational point of view, this can be provided simply and easily using dhcpv4 at the local level, and this mechanism would spectacularly avoid the deployment problems that Ray outlined. Handling this over DHCPv6 involves a level of string, gum and duck tape that makes me want to cringe. As a separate issue, if the operator really wants to disable all ipv4, why not disable ethertypes 0x0800 and 0x0806 at the mac forwarding layer? Nick From nobody Tue Apr 15 04:55: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 640891A07AF for ; Tue, 15 Apr 2014 04:55:04 -0700 (PDT) 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=unavailable 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 35YJuCuYnjmn for ; Tue, 15 Apr 2014 04:54:53 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id F28FF1A07B6 for ; Tue, 15 Apr 2014 04:54:32 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.dyn.netability.ie (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s3FBsSav088350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 15 Apr 2014 12:54:29 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.dyn.netability.ie Message-ID: <534D1E10.40809@foobar.org> Date: Tue, 15 Apr 2014 12:54:56 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ted Lemon References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <091F7BAB-2AAC-41B3-A67C-540482323E71@nominum.com> <3AAA3A70-1513-4163-A841-45FEFC95004C@delong.com> <230F179C-D5F3-4FB5-B068-C06549631BA7@nominum.com> In-Reply-To: <230F179C-D5F3-4FB5-B068-C06549631BA7@nominum.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/w6KTgdZyhJHjaQzW7HTwITi9GCI Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 11:55:04 -0000 On 15/04/2014 04:12, Ted Lemon wrote: > Because you are changing the protocol state machine. it's a single new state with a single transition point, and it would need to added to the state machine regardless of whether the signal comes directly through dhcpv4 or indirectly through dhcpv6 or ra. The difference between the two is that dhcpv6/ra would need an asynchronous transition which significantly complicates the dhcpv4 FSM because you would now have the possibility of a transition from any dhcpv4 state to the No IPv4 state. IOW, you're creating a longjmp style exception mechanism in the FSM. This is not a sensible thing to aim for. Nick From nobody Tue Apr 15 06:14: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 29A221A0258 for ; Tue, 15 Apr 2014 06:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 82TKZmTwtDyY for ; Tue, 15 Apr 2014 06:14:02 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 27DA41A0114 for ; Tue, 15 Apr 2014 06:14:02 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 05A63403E0; Tue, 15 Apr 2014 09:13:58 -0400 (EDT) Message-ID: <534D3096.8090202@viagenie.ca> Date: Tue, 15 Apr 2014 09:13:58 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Owen DeLong References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <534C17B8.8030209@foobar.org> <534C27C9.80701@viagenie.ca> <3DFC20FF-E866-4E1C-B720-D7C91CBB925B@delong.com> <534C40A5.9050302@viagenie.ca> <1DA9DEFD-8BD8-45C2-AD82-339EF2A289B8@delong.com> In-Reply-To: <1DA9DEFD-8BD8-45C2-AD82-339EF2A289B8@delong.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/FK9EyLl1sS_233C1tWdUh-XNAyY Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 13:14:07 -0000 Le 2014-04-14 16:39, Owen DeLong a écrit : >>> Why wouldn’t a network that does not offer IPv4 autoconfigration >>> not want to implement that option whether or not they do DHCPv6? >> >> Not sure what you mean. Our draft does specify RA and DHCPv6 >> versions of the No-IPv4 option. > > Not responsive to the above statement. It is possible that there are > networks which do not implement IPv4 auto configuration that would > want to use this option that also do not do IPv6. For example, a > statically addressed IPv4 Wireless network may want to turn off > clients sending DHCP discovers. Are you saying we should be trying to make non-IPv6 networks work better? Because we totally don't care about those. > I’m talking about the fact that this option could, in fact, be useful > for some IPv4-only networks as well. We don't care about IPv4-only networks. 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 nobody Tue Apr 15 06:18: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 B17811A0430 for ; Tue, 15 Apr 2014 06:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 VLbIB-cWxfW7 for ; Tue, 15 Apr 2014 06:18:23 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id C54F11A0499 for ; Tue, 15 Apr 2014 06:18:23 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id CEE51403E0; Tue, 15 Apr 2014 09:18:20 -0400 (EDT) Message-ID: <534D319C.3030800@viagenie.ca> Date: Tue, 15 Apr 2014 09:18:20 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <534BF5A5.5010609@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wHa1TbYXrTc4_oVRUD4B7X9gIFE Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 13:18:29 -0000 Le 2014-04-15 00:20, Lorenzo Colitti a ĂŠcrit : > In a nutshell, it defines DHCPv6 and RA options indicating to the host > that IPv4 is not available. Reviews from operations-minded people in > V6OPS would be of tremendous help. > > I don't see a strong use case for this. It seems to me that the two > scenarios in the introduction can be solved by simply configuring the > DHCPv4 relay (or the server, if on-link) to drop all DHCPv4 requests. DHCP clients do not interpret the absence of response as absence of IPv4 service. They will endlessly retry. It is this endless, periodic retrying that causes the problems we list in section 3. As an example, ISC dhclient retries every ~2 minutes or so by default. (From my memory.) > Am I missing something? Basically we're trying to make DHCPv4 clients shut up. 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 nobody Tue Apr 15 06:20: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 826A61A0499 for ; Tue, 15 Apr 2014 06:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 0qj0cHjz-NFW for ; Tue, 15 Apr 2014 06:19:55 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 860651A01F1 for ; Tue, 15 Apr 2014 06:19:55 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8AF0F403E0; Tue, 15 Apr 2014 09:19:52 -0400 (EDT) Message-ID: <534D31F8.6060902@viagenie.ca> Date: Tue, 15 Apr 2014 09:19:52 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Niall O'Reilly , Lorenzo Colitti References: <534BF5A5.5010609@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xNfLwYWGHa-rLa_frdGe64oGBC8 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 13:20:00 -0000 Le 2014-04-15 04:25, Niall O'Reilly a écrit : >> It seems to me that the two >> scenarios in the introduction can be solved by simply configuring the >> DHCPv4 relay (or the server, if on-link) to drop all DHCPv4 requests. > > Why go even that far? What's wrong with the minimalist solution of > just not providing any DHCPv4 service, ...which, from the point of view of the client, is exactly the same as Lorenzo's suggestion of dropping requests. > and leaving the client to > pick a link-local IPv4 address? The host will do that in some cases, but in general DHCPv4 clients will not simply shut up. They will retry endlessly. > Is the noise/signal (stet!) ratio in client-generated traffic already > so low that a few DHCPDISCOVERs per client would be noticeable? Yes. Please see the issues this creates that are listed in section 3 of our draft. 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 nobody Tue Apr 15 06:29: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 575071A0446 for ; Tue, 15 Apr 2014 06:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 5Vi9G03wmx5T for ; Tue, 15 Apr 2014 06:29:34 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 322FB1A0430 for ; Tue, 15 Apr 2014 06:29:34 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3B87D403E0 for ; Tue, 15 Apr 2014 09:29:31 -0400 (EDT) Message-ID: <534D343A.5000403@viagenie.ca> Date: Tue, 15 Apr 2014 09:29:30 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> <534C432D.3060700@globis.net> In-Reply-To: <534C432D.3060700@globis.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/PHAdcEz9v9wxlH1p6ZNOj6Hd688 Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 13:29:39 -0000 Le 2014-04-14 16:21, Ray Hunter a écrit : > That we are discussing turning off IPv4 in both RA and DHCPv6 just > highlights to me how ridiculous host configuration has become. > > To me this proposal just introduces all sorts of horrible race > conditions and inconsistencies, and I'm not convinced it's any better > than just configuring up IPv4 via DHCPv4 with either a self assigned > address or an RFC 1918 address and saying nothing about remote > connectivity (given that most OSes already have IPv4 detection > mechanisms in place to work out whether they are on a corporate network > with proxies or the Internet or on an isolated island or whatever.) > > e.g. what does a host do if RA says turn off IPv4, but DHCPv4 replies > either before or after a host receives that RA advertisement? > Does the host have to then disable IPv4 once it is already up? For how > long? Yes. Forever. This is in our draft. If IPv4 is already up, then there is a problem with your network's configuration. If you're saying over IPv4 that there is no IPv4 service, but on the other hand you *are* in fact providing IPv4 service, there's a contradiction somewhere. So in fact what would happen is the host would abort an unresponsive IPv4 provisioning process. > What if DHCPv6 and RA are not consistent (given they may not even be the > same router or device responding)? Then you have a network configuration consistency problem. We have the same issue whenever we define similar options in DHCPv6 and RA. Take for example DNS resolver provisioning, which is IMHO worse because we're not even talking about conflicting binary options, but list-values options that need to be merged somehow. This is not germane to the No-IPv4 problem. I wouldn't mind removing either the DHCPv6 or RA option if provisioning consistency proves to be an issue that people care about. > What if one router is IPv4 only and the other IPv6 only? And they're > from 2 different ISP providers connected to a common L2 LAN? That's a > perfectly valid configuration in my opinion. Absolutely. This is why we define how this option works in multiple-interfaces scenarios. This is all in the draft. > Can an absence of "turn off IPv4" message be taken as a "turn on IPv4"? No. It's an absence of information, period. > How would this be implemented consistently given RA is generally ICMP > (kernel space) and DHCPv6 user space (daemon)? I would make it all percolate all the way up to the controlling glue code (e.g., NetworkManager or init scripts). > Given the O and M bit saga, what makes anyone think that this additional > signalling will be any better? Because it helps fix real problems we're having today, and it helps people move to IPv6-only networks. > Why would any end host trust this message? Why would any end host trust anything received over DHCP or RA? This issue is not germane to the No IPv4 problem. > IMHO the place to turn off or signal limited IPv4 connectivity is in > DHCPv4 (if we ever even attempt to do that). Why? 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 nobody Tue Apr 15 06:32: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 A91161A046C for ; Tue, 15 Apr 2014 06:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 nvEf3AYXBtrD for ; Tue, 15 Apr 2014 06:32:00 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E67041A04B8 for ; Tue, 15 Apr 2014 06:31:59 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 07A4A403E0 for ; Tue, 15 Apr 2014 09:31:56 -0400 (EDT) Message-ID: <534D34CC.3030004@viagenie.ca> Date: Tue, 15 Apr 2014 09:31:56 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> <534C4DF7.4070407@foobar.org> <40E2438A-C43F-4E41-8778-511E53EF7009@nominum.com> <534D1966.5090301@foobar.org> In-Reply-To: <534D1966.5090301@foobar.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/A2NvEpYxMYkFz99gVRC4CfHNVXg Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 13:32:05 -0000 Le 2014-04-15 07:35, Nick Hilliard a ĂŠcrit : > This is not an especially relevant argument because if there were a dhcpv4 > option to handle this, all you would need to provide the service would be a > local stub dhcpv4 mechanism to reply with a DHCPOFFER with a No Service > option. There would be no requirement to back-haul the initial DHCPREQUEST > to a centralised provisioning system. IOW, from an operational point of > view, this can be provided simply and easily using dhcpv4 at the local > level, and this mechanism would spectacularly avoid the deployment problems > that Ray outlined. Handling this over DHCPv6 involves a level of string, > gum and duck tape that makes me want to cringe. This doesn't work when the L2 link is shared with clients to which you do want to provide IPv4 service. > As a separate issue, if the operator really wants to disable all ipv4, why > not disable ethertypes 0x0800 and 0x0806 at the mac forwarding layer? This doesn't work when the L2 link is shared with clients to which you do want to provide IPv4 service. 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 nobody Tue Apr 15 06:36: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 51DCE1A046C for ; Tue, 15 Apr 2014 06:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 LDOGv6IoMPPL for ; Tue, 15 Apr 2014 06:36:50 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 316031A0430 for ; Tue, 15 Apr 2014 06:36:50 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 44431403E0 for ; Tue, 15 Apr 2014 09:36:47 -0400 (EDT) Message-ID: <534D35EE.3060705@viagenie.ca> Date: Tue, 15 Apr 2014 09:36:46 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <091F7BAB-2AAC-41B3-A67C-540482323E71@nominum.com> <489D13FBFA9B3E41812EA89F188F018E1AFE3163@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AFE3163@xmb-rcd-x04.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/pecXU2H5ZwXolCWQCztG2dkh7LQ Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 13:36:55 -0000 Le 2014-04-14 16:44, Bernie Volz (volz) a écrit : > BTW: How significant is the problem anyway? Has this been analyzed by anyone? > > Sure, the clients broadcast these packets but this is the "good" direction in Wifi - the Wifi 'switch' can be told to drop them. Other switches can to? > > Seems to me that this would be far better to leave to the networking infrastructure to just 'block' the DHCPv4 packets if IPv4 isn't enabled? This doesn't work when the L2 link is shared with clients to which you do want to provide IPv4 service. > I suspect many access networks (i.e. DOCSIS - the IP Provisioning Mode TLV) already provide some information about whether v4, v6, or both are available? That is true, but there's no way to propagate this information to more hosts in the home. So you end up with DHCP requests eating battery life in the home. Our draft describes how to propagate the No-IPv4 knowledge inside the home. 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 nobody Tue Apr 15 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 EA70E1A02F8 for ; Tue, 15 Apr 2014 06:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 KD7PZ02KkFZ5 for ; Tue, 15 Apr 2014 06:39:02 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 241701A01F4 for ; Tue, 15 Apr 2014 06:39:02 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 35AA5403E0 for ; Tue, 15 Apr 2014 09:38:59 -0400 (EDT) Message-ID: <534D3672.3060702@viagenie.ca> Date: Tue, 15 Apr 2014 09:38:58 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> In-Reply-To: <20140415083615.GB43641@Space.Net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/vEp2A2ZxNRrayMMZwcwxHW9uBog Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 13:39:04 -0000 Le 2014-04-15 04:36, Gert Doering a écrit : > I agree to this. Interestingly, this is something else than "just shutdown > the dhcpv4 client if this option is detected" - it is "shutdown IPv4", which > many OSes can't do today at all (and yes, that needs fixing). Correct, it means "shutdown IPv4". Our draft lists precisely what needs to be shut down. And you're correct in that implementing this could mean more than just "pkill dhclient" on some OSes. But that work needs to happen anyway. 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 nobody Tue Apr 15 06:41: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 58B091A04C5 for ; Tue, 15 Apr 2014 06:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 W_BWuqZ4Whpt for ; Tue, 15 Apr 2014 06:41:33 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E34651A0495 for ; Tue, 15 Apr 2014 06:41:32 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DDE99403E0 for ; Tue, 15 Apr 2014 09:41:29 -0400 (EDT) Message-ID: <534D3709.2040609@viagenie.ca> Date: Tue, 15 Apr 2014 09:41:29 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sfLWos-orvkeUeqXkCqYGDfaQ_c Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 13:41:34 -0000 Le 2014-04-15 04:53, Mikael Abrahamsson a écrit : > So the flag should really be "of IPv4 and IPv6, use only IPv6" and I > actually think this is ok to put in IPv6. That's a nice way to put it! > I would prefer to see this information in RAs after thinking a bit more > of this.. And I think it should be hints in the style of M and O flags, > meaning the client can still try DHCPv4 for a short while if it really > wants to, but it should listen to the hint if it doesn't see significant > IPv4 traffic. Sure, we can add some leeway to the text. As long as it makes hosts eventually shut up, we're good. > Would it make sense to have a "deactivate IPv6 stack for the lifetime of > this RA"-message as well? I personally don't see a need. 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 nobody Tue Apr 15 06:54: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 7D67B1A0318 for ; Tue, 15 Apr 2014 06:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 L8SWCTn1V69U for ; Tue, 15 Apr 2014 06:54:45 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2241A0312 for ; Tue, 15 Apr 2014 06:54:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id AAE36870074; Tue, 15 Apr 2014 15:54:41 +0200 (CEST) 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 rAStxsTninbK; Tue, 15 Apr 2014 15:54:41 +0200 (CEST) Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 7E80A87006F; Tue, 15 Apr 2014 15:54:41 +0200 (CEST) Message-ID: <534D3A1F.9070307@globis.net> Date: Tue, 15 Apr 2014 15:54:39 +0200 From: Ray Hunter User-Agent: Postbox 3.0.9 (Macintosh/20140129) MIME-Version: 1.0 To: Simon Perreault References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> <534C4DF7.4070407@foobar.org> <40E2438A-C43F-4E41-8778-511E53EF7009@nominum.com> <534D1966.5090301@foobar.org> <534D34CC.3030004@viagenie.ca> In-Reply-To: <534D34CC.3030004@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/nMQKvg2l8aBUixCNZYwCbX-gUAA Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 13:54:48 -0000 Simon Perreault wrote: > Le 2014-04-15 07:35, Nick Hilliard a écrit : >> This is not an especially relevant argument because if there were a dhcpv4 >> option to handle this, all you would need to provide the service would be a >> local stub dhcpv4 mechanism to reply with a DHCPOFFER with a No Service >> option. There would be no requirement to back-haul the initial DHCPREQUEST >> to a centralised provisioning system. IOW, from an operational point of >> view, this can be provided simply and easily using dhcpv4 at the local >> level, and this mechanism would spectacularly avoid the deployment problems >> that Ray outlined. Handling this over DHCPv6 involves a level of string, >> gum and duck tape that makes me want to cringe. > > This doesn't work when the L2 link is shared with clients to which you > do want to provide IPv4 service. Wait a minute. If there's routers there that need to provide IPv4 selectively to some client nodes on the same L2 link then you almost certainly have an on link DHCPv4 server already. Or at least an IPv4 speaking router that can support one. And that is most likely already hooked in to a centralised provisioning system via DHCPv4 relays. And you anyway have to track L2 addresses to know which nodes on the link DO need a proper IPv4 service and which DON'T. In that case, just assigning all clients that do not enjoy an IPv4 service an address from a network 10.X.X.X/8 (the range can can be re-used on every end router) and filtering at L3 with an access list has exactly the same effect. Better still: assign those hosts that should not be using IPv4 an address with a very long lease via DHCPv4 from one of your RTBH black hole ranges. http://tools.ietf.org/html/rfc5635. They'll never send packets off link and they'll not retransmit DHCPv4 requests for a very long time. It's re-using an existing mechanism that is operationally proven, is unlikely to cause surprises, and has the advantage of not requiring any new code on either the end nodes nor the last-hop routers. > >> As a separate issue, if the operator really wants to disable all ipv4, why >> not disable ethertypes 0x0800 and 0x0806 at the mac forwarding layer? > > This doesn't work when the L2 link is shared with clients to which you > do want to provide IPv4 service. > > Simon We should fix this in IPv4. Polluting IPv6 with IPv4 switches is a bad move. Why does anyone think that badly behaved DHCPv4 clients will be any better behaved because there's a (new) DHCPv6 or RA option being advertised? If they're broken for IPv4 and haven't been patched for a long time, they're even more likely to be broken for IPv6, and just as likely not to be patched IMHO. -- Regards, RayH From nobody Tue Apr 15 07:06: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 CEB871A07C5 for ; Tue, 15 Apr 2014 07:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 s9jGObfrkOYA for ; Tue, 15 Apr 2014 07:06:27 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id F2CEF1A07BD for ; Tue, 15 Apr 2014 07:06:26 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 01F29403E0; Tue, 15 Apr 2014 10:06:23 -0400 (EDT) Message-ID: <534D3CDF.5050804@viagenie.ca> Date: Tue, 15 Apr 2014 10:06:23 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ray Hunter References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> <534C4DF7.4070407@foobar.org> <40E2438A-C43F-4E41-8778-511E53EF7009@nominum.com> <534D1966.5090301@foobar.org> <534D34CC.3030004@viagenie.ca> <534D3A1F.9070307@globis.net> In-Reply-To: <534D3A1F.9070307@globis.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ffFwsVxUYO-3DxkxKyYoV3ePy0A Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 14:06:29 -0000 Le 2014-04-15 09:54, Ray Hunter a écrit : >>> This is not an especially relevant argument because if there were a >>> dhcpv4 >>> option to handle this, all you would need to provide the service >>> would be a >>> local stub dhcpv4 mechanism to reply with a DHCPOFFER with a No Service >>> option. There would be no requirement to back-haul the initial >>> DHCPREQUEST >>> to a centralised provisioning system. IOW, from an operational point of >>> view, this can be provided simply and easily using dhcpv4 at the local >>> level, and this mechanism would spectacularly avoid the deployment >>> problems >>> that Ray outlined. Handling this over DHCPv6 involves a level of >>> string, >>> gum and duck tape that makes me want to cringe. >> >> This doesn't work when the L2 link is shared with clients to which you >> do want to provide IPv4 service. > Wait a minute. If there's routers there that need to provide IPv4 > selectively to some client nodes on the same L2 link then you almost > certainly have an on link DHCPv4 server already. Or at least an IPv4 > speaking router that can support one. And that is most likely already > hooked in to a centralised provisioning system via DHCPv4 relays. > > And you anyway have to track L2 addresses to know which nodes on the > link DO need a proper IPv4 service and which DON'T. > > In that case, just assigning all clients that do not enjoy an IPv4 > service an address from a network 10.X.X.X/8 (the range can can be > re-used on every end router) and filtering at L3 with an access list has > exactly the same effect. > Better still: assign those hosts that should not be using IPv4 an > address with a very long lease via DHCPv4 from one of your RTBH black > hole ranges. http://tools.ietf.org/html/rfc5635. > > They'll never send packets off link and they'll not retransmit DHCPv4 > requests for a very long time. > > It's re-using an existing mechanism that is operationally proven, is > unlikely to cause surprises, and has the advantage of not requiring any > new code on either the end nodes nor the last-hop routers. Can this be propagated inside a home? > Why does anyone think that badly behaved DHCPv4 clients will be any > better behaved because there's a (new) DHCPv6 or RA option being > advertised? Badly behaved? Who said anything about badly behaved clients? We're assuming correct implementations here. 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 nobody Tue Apr 15 07:21: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 23EEB1A01D4 for ; Tue, 15 Apr 2014 07:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 kxqpyv1F9vu1 for ; Tue, 15 Apr 2014 07:21:08 -0700 (PDT) Received: from smtpauth4.wiscmail.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) by ietfa.amsl.com (Postfix) with ESMTP id CD8341A00CF for ; Tue, 15 Apr 2014 07:21:08 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth4.wiscmail.wisc.edu by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0N4200H00SZZX300@smtpauth4.wiscmail.wisc.edu> for v6ops@ietf.org; Tue, 15 Apr 2014 09:21:05 -0500 (CDT) X-Spam-PmxInfo: Server=avs-4, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.15.141221, SenderIP=0.0.0.0 Received: from ricotta.doit.wisc.edu (ricotta.doit.wisc.edu [144.92.67.161]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0N42003O6T732S20@smtpauth4.wiscmail.wisc.edu>; Tue, 15 Apr 2014 09:21:04 -0500 (CDT) Date: Tue, 15 Apr 2014 09:21:03 -0500 From: "Dale W. Carder" To: Simon Perreault Message-id: <20140415142103.GA50776@ricotta.doit.wisc.edu> References: <534BF5A5.5010609@viagenie.ca> In-reply-to: <534BF5A5.5010609@viagenie.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Iwflwa9hu9xF880GeQxyvosS5Vg Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 14:21:13 -0000 Thus spake Simon Perreault (simon.perreault@viagenie.ca) on Mon, Apr 14, 2014 at 10:50:13AM -0400: > Dearest V6OPS, > > We are soliciting reviews for this SUNSET4 draft: > > http://tools.ietf.org/html/draft-ietf-sunset4-noipv4-00 > > In a nutshell, it defines DHCPv6 and RA options indicating to the host > that IPv4 is not available. Reviews from operations-minded people in > V6OPS would be of tremendous help. I guess I am still confused by your use cases. In looking at our dhcpv4 servers, I don't have No-IPX nor No-AppleTalk options sent to clients, so I am confused why this is needed for IPv4. 3.1: Turn off the dhcpv4 relay feature per router (sub)interface. No more load on the dhcpv4 server. 3.2: At the edge of your network, filter packets containing ethertypes you do not support. 3.3: Mobile device vendors have an incentive in fixing their code so they do not chew up their battery more than their competitors. 3.4: At the edge of your network, filter packets containing ethertypes you do not support. I think I understand 5.3 however I think you made a much better argument for turning off dhcp relay and ethertype filtering. The v4-level just says where the filter would best be configured. Since not every host would understand the No_IPv4 option, you are probably just going to have to filter in your network anyway if Section 3 is truly a problem. Dale From nobody Tue Apr 15 08:14: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 745E21A0484 for ; Tue, 15 Apr 2014 08:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.263 X-Spam-Level: X-Spam-Status: No, score=-1.263 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.272, 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 61TmXFdLPgy4 for ; Tue, 15 Apr 2014 08:14:17 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDAC1A0476 for ; Tue, 15 Apr 2014 08:14:16 -0700 (PDT) Received: from [IPv6:2001:1838:1003::1826:c02d:dc29:1365] (unknown.ipv6.scnet.net [IPv6:2001:1838:1003:0:1826:c02d:dc29:1365] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s3FF9Sg0029791 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Apr 2014 08:09:30 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3FF9Sg0029791 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1397574571; bh=I5/Z6hgueP+Jm10BNlZF2YKoRoA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ZbiYR6u+6SvB22Q3yxcOgoGmOjo4kfjVSzp3BbYAFf+oEEaoIKbLn7EtkdG0obPZA nvosczsfOjj52RaHbvZRkQBwjbXfrM7rk+J3IOhMnvHSQFh+62Fxbu8ixKo6PMX4yG HUvhbdlK4cSlcbnn/BHjdj4c8BHrQ8627K7MLfQQ= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: Date: Tue, 15 Apr 2014 08:09:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4E64CF95-F984-48F2-AEFA-A3E9FF9D38A3@delong.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 15 Apr 2014 08:09:31 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/vKnqw1ce7HzFj4WX3GRSHe8cYp4 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 15:14:21 -0000 I would support an RA flag that says =93If you=92re reading this = message, don=92t do IPv4 on this network=94. That=92s not even close to what is proposed here. What is proposed here is a variety of IPv6 methods for telling a client = to turn off it=92s IPv4 dynamic configuration requests and there=92s no = reason to put that into IPv6 at all. Owen On Apr 15, 2014, at 1:53 AM, Mikael Abrahamsson = wrote: > On Tue, 15 Apr 2014, Gert Doering wrote: >=20 >> I agree to this. Interestingly, this is something else than "just = shutdown the dhcpv4 client if this option is detected" - it is "shutdown = IPv4", which many OSes can't do today at all (and yes, that needs = fixing). >=20 > You're right. I just realised I implicitly thought that "shutdown = DHCPv4" and "shutdown IPv4" is the same thing, but it isn't. >=20 > So the flag should really be "of IPv4 and IPv6, use only IPv6" and I = actually think this is ok to put in IPv6. >=20 > I would prefer to see this information in RAs after thinking a bit = more of this.. And I think it should be hints in the style of M and O = flags, meaning the client can still try DHCPv4 for a short while if it = really wants to, but it should listen to the hint if it doesn't see = significant IPv4 traffic. >=20 > Would it make sense to have a "deactivate IPv6 stack for the lifetime = of this RA"-message as well? >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Apr 15 08:16: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 302231A043E for ; Tue, 15 Apr 2014 08:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 yK4QbDgrVmL4 for ; Tue, 15 Apr 2014 08:16:06 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id DCB1F1A02F5 for ; Tue, 15 Apr 2014 08:16:05 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B59624043F; Tue, 15 Apr 2014 11:16:02 -0400 (EDT) Message-ID: <534D4D32.7080001@viagenie.ca> Date: Tue, 15 Apr 2014 11:16:02 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Dale W. Carder" References: <534BF5A5.5010609@viagenie.ca> <20140415142103.GA50776@ricotta.doit.wisc.edu> In-Reply-To: <20140415142103.GA50776@ricotta.doit.wisc.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mBzqZK7RHWsDvB9EDJN_Y18km10 Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 15:16:11 -0000 Le 2014-04-15 10:21, Dale W. Carder a écrit : > I guess I am still confused by your use cases. In looking at our dhcpv4 > servers, I don't have No-IPX nor No-AppleTalk options sent to clients, > so I am confused why this is needed for IPv4. IPv4 has billions of deployed devices. IPX and AppleTalk, not so much. > 3.1: Turn off the dhcpv4 relay feature per router (sub)interface. No more > load on the dhcpv4 server. Not possible if the L2 link is shared with devices to which you do want to provide IPv4 service. > 3.2: At the edge of your network, filter packets containing ethertypes you > do not support. Not possible if the L2 link is shared with devices to which you do want to provide IPv4 service. > 3.3: Mobile device vendors have an incentive in fixing their code so > they do not chew up their battery more than their competitors. Yet the problem has not been fixed. > 3.4: At the edge of your network, filter packets containing ethertypes you > do not support. Not possible if the L2 link is shared with devices to which you do want to provide IPv4 service. Plus, that only works for ISPs. We need a way to propagate this inside the home. 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 nobody Tue Apr 15 08:19: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 6C12E1A0492 for ; Tue, 15 Apr 2014 08:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 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.272, 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 o4eaMMHkpUKY for ; Tue, 15 Apr 2014 08:19:27 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 0531D1A056D for ; Tue, 15 Apr 2014 08:19:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2078; q=dns/txt; s=iport; t=1397575164; x=1398784764; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=19/DD+Q1L+DcpHVGLaahzXZv0UdiK6oqhsHfMpo7nvU=; b=bHIDK7naRSE6+vebwvNjyrteZt9t7fJi7SW/NNQMyL6hFGjDUQXm9dbW am9u8DeLg72ekdmsi0vgPExVRrufmwrmRKTkcgGkGdOW0QkYVi4l6Kquj xVC46HFOyN4BOFKFeu431d8Z9JQUNFp4GJlkVbc3OV+9XAbsK/iBg5StP U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAHlNTVOtJV2d/2dsb2JhbABYgwY7V7t0hzWBIhZ0giUBAQEDAQEBASRHEAcEAgEIEQQBAQsdBycLFAkIAgQBEggRh1sIDcwNF417ESY4BoMegRQEiSSQdJEPgzGBakE X-IronPort-AV: E=Sophos;i="4.97,864,1389744000"; d="scan'208";a="35991345" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP; 15 Apr 2014 15:19:23 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s3FFJNlR012791 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Apr 2014 15:19:23 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.212]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Tue, 15 Apr 2014 10:19:23 -0500 From: "Bernie Volz (volz)" To: Simon Perreault , "v6ops@ietf.org" Thread-Topic: [v6ops] Please review the No IPv4 draft Thread-Index: AQHPV/Dx0jm4+vJrr02ADXU7FejXCZsRRQJ8gABWeACAAAfpAIAAA3kAgAAXoQD//8+J4IAABSXggAFwQgD//8f98A== Date: Tue, 15 Apr 2014 15:19:23 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AFE5A9D@xmb-rcd-x04.cisco.com> References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <091F7BAB-2AAC-41B3-A67C-540482323E71@nominum.com> <489D13FBFA9B3E41812EA89F188F018E1AFE3163@xmb-rcd-x04.cisco.com> <534D35EE.3060705@viagenie.ca> In-Reply-To: <534D35EE.3060705@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.70.121] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/aINdPoYXAdntzJ3xxEkll0lldsc Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 15:19:31 -0000 > This doesn't work when the L2 link is shared with clients to which you do= want to provide IPv4 service. So, why can't other devices use IPv4 then? > That is true, but there's no way to propagate this information to more ho= sts in the home. So you end up with DHCP requests eating battery life in th= e home. That might require some tweaks in those devices (they probably already limi= t what discovery they do if they aren't getting DHCPv4 service to start wit= h -- and that would benefit the device everywhere). - Bernie -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Simon Perreault Sent: Tuesday, April 15, 2014 9:37 AM To: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft Le 2014-04-14 16:44, Bernie Volz (volz) a =E9crit : > BTW: How significant is the problem anyway? Has this been analyzed by any= one? >=20 > Sure, the clients broadcast these packets but this is the "good" directio= n in Wifi - the Wifi 'switch' can be told to drop them. Other switches can = to? >=20 > Seems to me that this would be far better to leave to the networking infr= astructure to just 'block' the DHCPv4 packets if IPv4 isn't enabled? This doesn't work when the L2 link is shared with clients to which you do w= ant to provide IPv4 service. > I suspect many access networks (i.e. DOCSIS - the IP Provisioning Mode TL= V) already provide some information about whether v4, v6, or both are avail= able? That is true, but there's no way to propagate this information to more host= s in the home. So you end up with DHCP requests eating battery life in the = home. Our draft describes how to propagate the No-IPv4 knowledge inside the= home. 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 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Apr 15 08:20: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 8A3671A0652 for ; Tue, 15 Apr 2014 08:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 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.272, 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 W9e-C2-zQM1F for ; Tue, 15 Apr 2014 08:20:53 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id A1C8C1A014B for ; Tue, 15 Apr 2014 08:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1999; q=dns/txt; s=iport; t=1397575244; x=1398784844; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qk6NAZ0sizAHlWfi2EZtRkNj5zY5iNmvfRq5xaElLME=; b=cvhbiYbXmUlFJBMnMJoeliBDNkHnbzwsksbL1OVk2f1GPEu++X8JOQwC YnYaogTzMAwcupQOtChL3bc9VCDNd2PZsxVg7oHlBWRJfAlNeLffAH1KU 9Ri2okt9zOILQQyPAyy0FKNkJ1IPF8sOPoLxkbMjXmYCiPhjh44gnVjqo 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAHlNTVOtJV2a/2dsb2JhbABYDoJ4O1e7dIc1gSIWdIIlAQEBAwEBAQEkRwsFBwQCAQgRBAEBCx0HJwsUCQgCBAENBQiHbAgNzA0XjXs3MQcGgx6BFASJJJB0kQ+CcUCCKw X-IronPort-AV: E=Sophos;i="4.97,864,1389744000"; d="scan'208";a="317904603" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 15 Apr 2014 15:20:43 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3FFKg6v008007 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Apr 2014 15:20:42 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.212]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Tue, 15 Apr 2014 10:20:42 -0500 From: "Bernie Volz (volz)" To: Simon Perreault , "Dale W. Carder" Thread-Topic: [v6ops] Please review the No IPv4 draft Thread-Index: AQHPWL2c0jm4+vJrr02ADXU7FejXCZsSyt0Q Date: Tue, 15 Apr 2014 15:20:42 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AFE5ACB@xmb-rcd-x04.cisco.com> References: <534BF5A5.5010609@viagenie.ca> <20140415142103.GA50776@ricotta.doit.wisc.edu> <534D4D32.7080001@viagenie.ca> In-Reply-To: <534D4D32.7080001@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.70.121] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1RnC3fPgWTqTxa-xclSWiM-KLW8 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 15:20:57 -0000 Yeah, but we survived the transition away from these older networks without= significant issues and special messages on IPv4 to tell clients "don't try= IPX or AppleTalk or ...". - Bernie -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Simon Perreault Sent: Tuesday, April 15, 2014 11:16 AM To: Dale W. Carder Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft Le 2014-04-15 10:21, Dale W. Carder a =E9crit : > I guess I am still confused by your use cases. In looking at our=20 > dhcpv4 servers, I don't have No-IPX nor No-AppleTalk options sent to=20 > clients, so I am confused why this is needed for IPv4. IPv4 has billions of deployed devices. IPX and AppleTalk, not so much. > 3.1: Turn off the dhcpv4 relay feature per router (sub)interface. No=20 > more load on the dhcpv4 server. Not possible if the L2 link is shared with devices to which you do want to = provide IPv4 service. > 3.2: At the edge of your network, filter packets containing=20 > ethertypes you do not support. Not possible if the L2 link is shared with devices to which you do want to = provide IPv4 service. > 3.3: Mobile device vendors have an incentive in fixing their code so=20 > they do not chew up their battery more than their competitors. Yet the problem has not been fixed. > 3.4: At the edge of your network, filter packets containing=20 > ethertypes you do not support. Not possible if the L2 link is shared with devices to which you do want to = provide IPv4 service. Plus, that only works for ISPs. We need a way to propagate this inside the = home. 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 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Apr 15 08:21: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 73E801A06B5 for ; Tue, 15 Apr 2014 08:21:20 -0700 (PDT) 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 bRjjBGS28Bs6 for ; Tue, 15 Apr 2014 08:21:17 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED021A06BC for ; Tue, 15 Apr 2014 08:21:15 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.dyn.netability.ie (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s3FFLBp1090035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 15 Apr 2014 16:21:11 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.dyn.netability.ie Message-ID: <534D4E85.5040104@foobar.org> Date: Tue, 15 Apr 2014 16:21:41 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Simon Perreault References: <534BF5A5.5010609@viagenie.ca> <534D319C.3030800@viagenie.ca> In-Reply-To: <534D319C.3030800@viagenie.ca> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/IIDCZeWvP7BKtD9ptVBjmCDI76I Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 15:21:20 -0000 On 15/04/2014 14:18, Simon Perreault wrote: > Basically we're trying to make DHCPv4 clients shut up. then there's confusion about the draft's aims. A good deal of the draft goes into detail about completely stopping all ipv4 services on the client system (which is something that is not going to be simple to achieve in practice), whereas your stated aims and justification in the draft are all about getting dhcpv4 clients to stop making noise. Getting DHCPv4 clients to shut up is an admirable goal and I think it's worth pursuing this by using the front-door method of creating a dhcpv4 no-service option (suggestion: use dhcpv4, implement a timeout, make it interface specific, i.e. don't attempt to apply the configuration to multiple interfaces, and don't attempt to complicate things by creating a requirement to completely disable ipv4). This would not be difficult to achieve either operationally or from a protocol point of view; it would be both clear and unambiguous, and it would not suffer from the technical / implementation problems that either Ray or I brought up. As a side issue you may want to consider renaming the draft -nodhcpv4- instead of -noipv4-. Getting hosts to stop talking ipv4 completely is a much more difficult problem. If you want to write a draft about this, then you need to start from the beginning explaining the problem you're trying to solve, why you're trying to solve it and then provide guidance on how it should be handled. This analysis is not present in your current draft. At the very least I would be curious to know how and why a DHCP or RA request coming in on any random interface should have the authority to completely disable an entire communications protocol, O/S wide. As a client, I might well have multiple interfaces configured, only one of which has ipv6 disabled, and it would be difficult to understand how e.g. my 3g provider should have the right to tell me that my operating system should completely shut down ipv4 while my computer was connected to my home wifi. Nick From nobody Tue Apr 15 08:29: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 9C9F31A01A8 for ; Tue, 15 Apr 2014 08:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 TTu-jD865fjb for ; Tue, 15 Apr 2014 08:29:50 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id B85661A0176 for ; Tue, 15 Apr 2014 08:29:50 -0700 (PDT) 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 B68331B8055 for ; Tue, 15 Apr 2014 08:29:46 -0700 (PDT) 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 B02CB19005C; Tue, 15 Apr 2014 08:29:46 -0700 (PDT) Received: from [172.16.0.175] (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, 15 Apr 2014 08:29:46 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: Date: Tue, 15 Apr 2014 10:29:44 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <534BF5A5.5010609@viagenie.ca> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xZQTZZeWlvgCNcexcAZcw0GgWgg Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 15:29:51 -0000 On Apr 14, 2014, at 11:20 PM, Lorenzo Colitti = wrote: > I don't see a strong use case for this. It seems to me that the two = scenarios in the introduction can be solved by simply configuring the = DHCPv4 relay (or the server, if on-link) to drop all DHCPv4 requests. In a v6-only network, there would be no relay, so you'd get this effect = for free. > Am I missing something? Broadcast traffic on Wifi. Vulnerability to on-link IPv4 attacks. = Otherwise, probably no. From nobody Tue Apr 15 08:31: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 32F471A0677 for ; Tue, 15 Apr 2014 08:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 LMdC6-JF9_ZD for ; Tue, 15 Apr 2014 08:31:44 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 4348F1A065E for ; Tue, 15 Apr 2014 08:31:44 -0700 (PDT) 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 9CC4D1B8055 for ; Tue, 15 Apr 2014 08:31:41 -0700 (PDT) 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 9612E19005C; Tue, 15 Apr 2014 08:31:41 -0700 (PDT) Received: from [172.16.0.175] (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, 15 Apr 2014 08:31:41 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: Date: Tue, 15 Apr 2014 10:31:25 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <182F7B02-7D62-4477-8A74-F641A0C366C4@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <091F7BAB-2AAC-41B3-A67C-540482323E71@nominum.com> <3AAA3A70-1513-4163-A841-45FEFC95004C@delong.com> <230F179C-D5F3-4FB5-B068-C06549631BA7@nominum.com> To: Owen DeLong X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/9h18lDE0H6T8-oSr1exvQta7MGg Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 15:31:45 -0000 On Apr 14, 2014, at 11:50 PM, Owen DeLong wrote: > So, you=92re saying having some external process kill the DHCP4 client = in response to a message received via DHCPv6 is less of a change to the = protocol state machine than having DHCPv4 client die in response to a = similar message=85 Right. Yes. Not running a protocol is not a change to the protocol's state = machine. We don't need to write an RFC explaining how to not enable = DHCPv4. Changes to the state machine for the benefit of this use case = would have to be considered in the larger context of intended uses of = DHCPv4; turning off DHCPv4 requires no such consideration. From nobody Tue Apr 15 08:37: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 3A2541A0476 for ; Tue, 15 Apr 2014 08:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.272] 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 jqCA1xGI1_4j for ; Tue, 15 Apr 2014 08:37:29 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id A47AE1A01E2 for ; Tue, 15 Apr 2014 08:37:23 -0700 (PDT) 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 228C21B8055 for ; Tue, 15 Apr 2014 08:37:21 -0700 (PDT) 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 1BF7519005C; Tue, 15 Apr 2014 08:37:21 -0700 (PDT) Received: from [172.16.0.175] (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, 15 Apr 2014 08:37:20 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <82E804C3-725D-415A-87C3-512073774C6F@delong.com> Date: Tue, 15 Apr 2014 10:37:19 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <534C17B8.8030209@foobar.org> <534C27C9.80701@viagenie.ca> <20140414194824.GY43641@Space.Net> <534C3F7D.3040406@viagenie.ca> <20140414201231.GZ43641@Space.Net> <23F575A3-E00D-410E-9929-7377B7CAA623@nominum.com> <82E804C3-725D-415A-87C3-512073774C6F@delong.com> To: Owen DeLong X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/N63sXAZHk2wIrE9euGGkrWn4VaA Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 15:37:34 -0000 On Apr 14, 2014, at 11:51 PM, Owen DeLong wrote: > Calling it the wrong thing while advocating an even more wrong thing = is equally absurd. When I call it the wrong thing, I mean that it doesn't work well (and I = explained that). In practice, not in theory. You are claiming that = adding the capability to shut off DHCPv4 is even more wrong, but you = haven't explained why. So when we weigh the two considerations next to = each other, one of which is substantiated by everybody's daily = experience of Linux networking, and the other of which is purely = speculative and not substantiated by any reasoning that would lead us to = think it is true, then despite the fact that, if it were true, it would = be worse, we should, logically, weigh the other consideration more = heavily. For comparison, suppose you were to assert that there's a significant = risk of giant bunnies leaping out into the road when driving on any = interstate highway in the U.S. We could definitely say that if such a = statement were true, it would require us to change our driving habits. = And yet we likely would not change our driving habits, because you have = given us no reason to think it's true. (Happy Easter!) From nobody Tue Apr 15 08:38: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 063C91A02CB for ; Tue, 15 Apr 2014 08:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.263 X-Spam-Level: X-Spam-Status: No, score=-1.263 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.272, 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 nEaC_CMFVupW for ; Tue, 15 Apr 2014 08:38:37 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 520131A043C for ; Tue, 15 Apr 2014 08:38:37 -0700 (PDT) Received: from [IPv6:2001:1838:1003::1826:c02d:dc29:1365] (unknown.ipv6.scnet.net [IPv6:2001:1838:1003:0:1826:c02d:dc29:1365] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s3FFZGo8000778 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Apr 2014 08:35:17 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3FFZGo8000778 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1397576118; bh=26VK2HtaI5xSMUzN0CB74nG22u0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=eVBJtK/JAiab9UqgocSz/Kc7+69H7Z8ta/sTRMMj3PK0XkTn9FcHmug+9EcANtCHl HwgvIxbUw48SBlBA/v+/AZJXfr86qoCBH3vxQTXyHej+58xZl9YsD7SENuKIlJtDgJ Z59JnqqEfWXHsudro/RFbb48rV1oT1WVZ9sq2RFk= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: <534D4D32.7080001@viagenie.ca> Date: Tue, 15 Apr 2014 08:35:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <438CE365-71E8-4ED0-BDD6-2367C0CD2CEB@delong.com> References: <534BF5A5.5010609@viagenie.ca> <20140415142103.GA50776@ricotta.doit.wisc.edu> <534D4D32.7080001@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 15 Apr 2014 08:35:18 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/TjMbFJUbS7icqL3jcf187TC-LIk Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 15:38:38 -0000 >=20 >> 3.3: Mobile device vendors have an incentive in fixing their code so >> they do not chew up their battery more than their competitors. >=20 > Yet the problem has not been fixed. =85 YET Reality, however, is that encouraging them to fix that could be = accomplished just as easily as getting them to implement this new = IPv6-based modification to their DHCPv4 client behavior. In fact, it = could even be done without necessarily waiting for them to implement = IPv6 in said client. Owen From nobody Tue Apr 15 08:40: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 BFC7A1A0304 for ; Tue, 15 Apr 2014 08:40:02 -0700 (PDT) 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 bd3taN_aQYun for ; Tue, 15 Apr 2014 08:39:59 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) by ietfa.amsl.com (Postfix) with ESMTP id D09491A02CB for ; Tue, 15 Apr 2014 08:39:58 -0700 (PDT) Received: by mail-yk0-f179.google.com with SMTP id 9so8942793ykp.38 for ; Tue, 15 Apr 2014 08:39:56 -0700 (PDT) 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=S9g05Kt/w/YvF1i//Lvdr5rVcrQmrZ9Z2XmSxGNO1tc=; b=Rx7qVspPkhK/+p3cMpPS5C5GiQNR9ZOIOCLZ8HzHKGlkdK6nH2jxrriHsOAtHbubfH 7e6eNZZQb1ayhBRpXX4b6SBBWjJcnNt4j1CX+mWayoYcaI97hk86AgGF/OBCCrGcb7d0 5/ZhfRetYoA1tiXkIyNyK17DkVhtFFN8MScDbQq1bY2fS8YBCe+piqk63yAVtYhuguRf ovN4uU+nCeC5xyxfJZ18xd+vmvCCK2debj6K8dFUlEdDR5UMFI/dKMBeSr+EaPch4PBS 7ydnt0vpP/i6W8EVQ+s9Qk41Yoj7Ylk/rI8h6COl66grUFIBNGGczj2aSJYfXZWoI+U+ qILA== MIME-Version: 1.0 X-Received: by 10.236.99.99 with SMTP id w63mr3482367yhf.52.1397576395920; Tue, 15 Apr 2014 08:39:55 -0700 (PDT) Sender: mpetach@gmail.com Received: by 10.170.135.80 with HTTP; Tue, 15 Apr 2014 08:39:55 -0700 (PDT) In-Reply-To: References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> Date: Tue, 15 Apr 2014 08:39:55 -0700 X-Google-Sender-Auth: 51sEwlwAY_cYICuqVuvFWHf6wbo Message-ID: From: Matthew Petach To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=20cf300e4cd9a01aa204f7169cee Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/eMkT41duHj-BAaAA1AqYfR49H8g Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 15:40:02 -0000 --20cf300e4cd9a01aa204f7169cee Content-Type: text/plain; charset=UTF-8 On Tue, Apr 15, 2014 at 1:53 AM, Mikael Abrahamsson wrote: > Would it make sense to have a "deactivate IPv6 stack for the lifetime of > this RA"-message as well? > > That would be an excellent feature to support, yes; I have IPv4-only connectivity in some places, and having hosts send out RS messages for connectivity that will never happen is a waste of network resources; it would be good for the local router to be able to say "there is no v6 here, stop trying and deactivate your IPv6 stack completely". Thank you for that recommendation! Matt > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --20cf300e4cd9a01aa204f7169cee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



    On Tue, Apr 15, 2014 at 1:53 AM, Mikael Abrahamsson <swmike@swm.pp.= se> wrote:
    Would it make sense to have a "deactiva= te IPv6 stack for the lifetime of this RA"-message as well?


    That would be an excellent featu= re to support, yes;
    I have IPv4-only connectivity in some pla= ces, and
    having hosts send out RS messages for connectivity
    that wil= l never happen is a waste of network resources;
    it would be good for the local router to be able to say
    "there is n= o v6 here, stop trying and deactivate your
    IPv6 stack completely".<= br>
    Thank you for that recommendation!

    Matt
    =C2=A0<= /div>

    --
    Mikael Abrahamsson =C2=A0 =C2=A0email: swmike@swm.pp.se

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


    --20cf300e4cd9a01aa204f7169cee-- From nobody Tue Apr 15 08:44: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 8BBD11A04A9 for ; Tue, 15 Apr 2014 08:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.263 X-Spam-Level: X-Spam-Status: No, score=-1.263 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.272, 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 Zb7brsPPtMGN for ; Tue, 15 Apr 2014 08:44:42 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id C3D671A0176 for ; Tue, 15 Apr 2014 08:44:41 -0700 (PDT) Received: from [IPv6:2001:1838:1003::1826:c02d:dc29:1365] (unknown.ipv6.scnet.net [IPv6:2001:1838:1003:0:1826:c02d:dc29:1365] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s3FFem2Y001292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Apr 2014 08:40:49 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3FFem2Y001292 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1397576450; bh=M57LbIcsYjTK7q5CGUkN/p8JXA0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=e2gSOkJy81s+f2hfYYv2DFc89MEiZ5+lmZXsAYtgp5HXB+IsxKlfJe+sqELDPGCWp socBfylDzJAWpIJHallo+ZKNVABvMobPZtR/QeuQ6ltE1g43hmSh1ulvaQu1aOIjTO lEGHtevi5nWiVf9sHv9o85uarWhVlk8VsQz6yVRY= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: <182F7B02-7D62-4477-8A74-F641A0C366C4@nominum.com> Date: Tue, 15 Apr 2014 08:40:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4C6C2577-0AB3-49B2-8C19-51CCE95A6448@delong.com> References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <091F7BAB-2AAC-41B3-A67C-540482323E71@nominum.com> <3AAA3A70-1513-4163-A841-45FEFC95004C@delong.com> <230F179C-D5F3-4FB5-B068-C06549631BA7@nominum.com> <182F7B02-7D62-4477-8A74-F641A0C366C4@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 15 Apr 2014 08:40:50 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/v0PUZpz9hzzWvS856-bAI1L48gg Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 15:44:44 -0000 On Apr 15, 2014, at 8:31 AM, Ted Lemon wrote: > On Apr 14, 2014, at 11:50 PM, Owen DeLong wrote: >> So, you=92re saying having some external process kill the DHCP4 = client in response to a message received via DHCPv6 is less of a change = to the protocol state machine than having DHCPv4 client die in response = to a similar message=85 Right. >=20 > Yes. Not running a protocol is not a change to the protocol's state = machine. We don't need to write an RFC explaining how to not enable = DHCPv4. Changes to the state machine for the benefit of this use case = would have to be considered in the larger context of intended uses of = DHCPv4; turning off DHCPv4 requires no such consideration. Turning off DHCPv4 through an IPv6 dynamic configuration mechanism = absolutely requires those considerations. This argument has become a reductio ad absurdum, IMHO. If you want to provide an automated way to shut down DHCPv4, it should = be done in IPv4. An ICMPv4 message saying =93Don=92t keep trying to use = DHCPv4=94 sent in response to a DHCPv4 request would be fine. Requiring = clients that receive both an DHCPOFFER and the message to act on the = DHCPOFFER and ignore the ICMP message would mitigate the DoS and other = concerns and wouldn=92t involve a significant change to the DHCPv4 state = machine. Owen From nobody Tue Apr 15 08:46: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 BBDC81A075F for ; Tue, 15 Apr 2014 08:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 XxLvC7gQjtM4 for ; Tue, 15 Apr 2014 08:46:30 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2603E1A06F7 for ; Tue, 15 Apr 2014 08:46:30 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 20758403C1; Tue, 15 Apr 2014 11:46:27 -0400 (EDT) Message-ID: <534D5452.4080300@viagenie.ca> Date: Tue, 15 Apr 2014 11:46:26 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Nick Hilliard References: <534BF5A5.5010609@viagenie.ca> <534D319C.3030800@viagenie.ca> <534D4E85.5040104@foobar.org> In-Reply-To: <534D4E85.5040104@foobar.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/uvsJuV2TdTXvDPeMFBOZURQGlBI Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 15:46:39 -0000 Le 2014-04-15 11:21, Nick Hilliard a ĂŠcrit : > On 15/04/2014 14:18, Simon Perreault wrote: >> Basically we're trying to make DHCPv4 clients shut up. This was a mistake on my part. We're trying to do much more. We're trying to create an IPv4 kill switch. > then there's confusion about the draft's aims. A good deal of the draft > goes into detail about completely stopping all ipv4 services on the client > system (which is something that is not going to be simple to achieve in > practice), whereas your stated aims and justification in the draft are all > about getting dhcpv4 clients to stop making noise. > > Getting DHCPv4 clients to shut up is an admirable goal and I think it's > worth pursuing this by using the front-door method of creating a dhcpv4 > no-service option (suggestion: use dhcpv4, implement a timeout, make it > interface specific, i.e. don't attempt to apply the configuration to > multiple interfaces, and don't attempt to complicate things by creating a > requirement to completely disable ipv4). This would not be difficult to > achieve either operationally or from a protocol point of view; it would be > both clear and unambiguous, and it would not suffer from the technical / > implementation problems that either Ray or I brought up. As a side issue > you may want to consider renaming the draft -nodhcpv4- instead of -noipv4-. > > Getting hosts to stop talking ipv4 completely is a much more difficult > problem. If you want to write a draft about this, then you need to start > from the beginning explaining the problem you're trying to solve, We do have a section titled "The Problems we're Trying to Solve". > why you're trying to solve it Because problems are problematic. > and then provide guidance on how it should be > handled. This analysis is not present in your current draft. You might be interested in this analysis of problems preventing the migration to IPv6-only: http://tools.ietf.org/html/draft-ietf-sunset4-gapanalysis-04 > At the very least I would be curious to know how and why a DHCP or RA > request coming in on any random interface should have the authority to > completely disable an entire communications protocol, O/S wide. It does *not* have any authority. It is signalling. A host is free to ignore the signalling. > As a > client, I might well have multiple interfaces configured, only one of which > has ipv6 disabled, and it would be difficult to understand how e.g. my 3g > provider should have the right to tell me that my operating system should > completely shut down ipv4 while my computer was connected to my home wifi. It does not. Did you read our draft? We specify how the No-IPv4 option is to be processed in multiple interfaces settings. 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 nobody Tue Apr 15 08:51: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 3BFB21A02D6 for ; Tue, 15 Apr 2014 08:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 DmMahsR4wNG7 for ; Tue, 15 Apr 2014 08:51:08 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id B706B1A049A for ; Tue, 15 Apr 2014 08:51:08 -0700 (PDT) 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 353CC1B8055 for ; Tue, 15 Apr 2014 08:51:06 -0700 (PDT) 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 2EB7319005C; Tue, 15 Apr 2014 08:51:06 -0700 (PDT) Received: from [172.16.0.175] (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, 15 Apr 2014 08:51:05 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <20140415083054.GA43641@Space.Net> Date: Tue, 15 Apr 2014 10:50:30 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <12834618-FF47-47C8-A7CE-7752B7A5641D@nominum.com> References: <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <534C17B8.8030209@foobar.org> <534C27C9.80701@viagenie.ca> <20140414194824.GY43641@Space.Net> <534C3F7D.3040406@viagenie.ca> <20140414201231.GZ43641@Space.Net> <23F575A3-E00D-410E-9929-7377B7CAA623@nominum.com> <20140415083054.GA43641@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/nekhQddlE2UsQTA6rvCBsO0Zv6o Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 15:51:10 -0000 On Apr 15, 2014, at 3:30 AM, Gert Doering wrote: > It's called "multiple independent implementations of the same spec", = and > I'm not sure what's wrong about it. There's nothing wrong with multiple implementations. What's wrong is = that there is no tight integration between the various configuration = agents on Linux, and this breaks badly as soon as your network gets = interesting. It's better now than it use to be, but it's still all = held together with bubble gum and bailing wire, and it falls apart at = the slightest excuse. From nobody Tue Apr 15 08:52: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 74AAA1A0781 for ; Tue, 15 Apr 2014 08:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 ATRDzilhAx7n for ; Tue, 15 Apr 2014 08:52:00 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 826071A077A for ; Tue, 15 Apr 2014 08:52:00 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 85FBB41172; Tue, 15 Apr 2014 11:51:57 -0400 (EDT) Message-ID: <534D559D.9080309@viagenie.ca> Date: Tue, 15 Apr 2014 11:51:57 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Bernie Volz (volz)" , "Dale W. Carder" References: <534BF5A5.5010609@viagenie.ca> <20140415142103.GA50776@ricotta.doit.wisc.edu> <534D4D32.7080001@viagenie.ca> <489D13FBFA9B3E41812EA89F188F018E1AFE5ACB@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AFE5ACB@xmb-rcd-x04.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/3Pcrdu--JyGCjS3xddAhQSdFGi4 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 15:52:03 -0000 Le 2014-04-15 11:20, Bernie Volz (volz) a écrit : > Yeah, but we survived the transition away from these older networks without significant issues and special messages on IPv4 to tell clients "don't try IPX or AppleTalk or ...". Of course. And this argument has first been made by Stuart Cheshire. To me, the operational situation with IPv4 and its billions of deployed devices is light-years away from AppleTalk/IPX. People are experiencing real problems with moving to IPv6-only. I don't think our answer should be "just do it the way it was done with AppleTalk and IPX". Simon > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Simon Perreault > Sent: Tuesday, April 15, 2014 11:16 AM > To: Dale W. Carder > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Please review the No IPv4 draft > > Le 2014-04-15 10:21, Dale W. Carder a écrit : >> I guess I am still confused by your use cases. In looking at our >> dhcpv4 servers, I don't have No-IPX nor No-AppleTalk options sent to >> clients, so I am confused why this is needed for IPv4. > > IPv4 has billions of deployed devices. IPX and AppleTalk, not so much. > >> 3.1: Turn off the dhcpv4 relay feature per router (sub)interface. No >> more load on the dhcpv4 server. > > Not possible if the L2 link is shared with devices to which you do want to provide IPv4 service. > >> 3.2: At the edge of your network, filter packets containing >> ethertypes you do not support. > > Not possible if the L2 link is shared with devices to which you do want to provide IPv4 service. > >> 3.3: Mobile device vendors have an incentive in fixing their code so >> they do not chew up their battery more than their competitors. > > Yet the problem has not been fixed. > >> 3.4: At the edge of your network, filter packets containing >> ethertypes you do not support. > > Not possible if the L2 link is shared with devices to which you do want to provide IPv4 service. > > Plus, that only works for ISPs. We need a way to propagate this inside the home. > > 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 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- 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 nobody Tue Apr 15 08: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 EC6991A03A6 for ; Tue, 15 Apr 2014 08:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 BZ5aBy0AFTcW for ; Tue, 15 Apr 2014 08:57:42 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id C33011A02C7 for ; Tue, 15 Apr 2014 08:57:42 -0700 (PDT) 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 409451B8055 for ; Tue, 15 Apr 2014 08:57:40 -0700 (PDT) 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 2D70519005C; Tue, 15 Apr 2014 08:57:40 -0700 (PDT) Received: from [172.16.0.175] (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, 15 Apr 2014 08:57:39 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <534D1966.5090301@foobar.org> Date: Tue, 15 Apr 2014 10:57:38 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <6D57B3D8-DAF4-4792-BDF5-B0489A283F6B@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> <534C4DF7.4070407@foobar.org> <40E2438A-C43F-4E41-8778-511E53EF7009@nominum.com> <534D1966.5090301@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/FtcIcUC0Q8XckByshn2zySGbqSE Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 15:57:47 -0000 On Apr 15, 2014, at 6:35 AM, Nick Hilliard wrote: > This is not an especially relevant argument because if there were a = dhcpv4 > option to handle this, all you would need to provide the service would = be a > local stub dhcpv4 mechanism to reply with a DHCPOFFER with a No = Service > option. There would be no requirement to back-haul the initial = DHCPREQUEST > to a centralised provisioning system. So now every v6-only CPE router has to have a DHCPv4 implementation and = an IPv4 stack. > As a separate issue, if the operator really wants to disable all ipv4, = why > not disable ethertypes 0x0800 and 0x0806 at the mac forwarding layer? The draft speaks to this point. BTW, the draft also speaks to the point of why you don't want to use = DHCPv4 for this: once you've turned off IPv4, DHCPv4 can't be used to = turn it back on again. And the message from Simon that I was referring to was the one that = discussed the draft that was proposed in sunset4 for solving this = problem using DHCPv4, which was _not adopted by the working group_. = Draft adoption is part of the working group process; the fact that the = working group decided to merge the DHCPv4 draft into this one, and not = the other way around, is precisely what it means for a working group to = have consensus to push this solution and not the other one. From nobody Tue Apr 15 09:06: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 4096B1A07C0 for ; Tue, 15 Apr 2014 09:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 NLcwUJ9r7JaR for ; Tue, 15 Apr 2014 09:06:23 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 090D21A07C4 for ; Tue, 15 Apr 2014 09:06:23 -0700 (PDT) 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 4B9D41B8055 for ; Tue, 15 Apr 2014 09:06:20 -0700 (PDT) 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 4556619005C; Tue, 15 Apr 2014 09:06:20 -0700 (PDT) Received: from [172.16.0.175] (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, 15 Apr 2014 09:06:20 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <4C6C2577-0AB3-49B2-8C19-51CCE95A6448@delong.com> Date: Tue, 15 Apr 2014 11:06:04 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <0F8232C6-0B82-4A6F-9F66-A6A78DC19DEF@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <091F7BAB-2AAC-41B3-A67C-540482323E71@nominum.com> <3AAA3A70-1513-4163-A841-45FEFC95004C@delong.com> <230F179C-D5F3-4FB5-B068-C06549631BA7@nominum.com> <182F7B02-7D62-4477-8A74-F641A0C366C4@nominum.com> <4C6C2577-0AB3-49B2-8C19-51CCE95A6448@delong.com> To: Owen DeLong X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/uQ6s8LolsLy7MfsuSrn0U0r28FY Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 16:06:24 -0000 Owen, you are just repeating the same point over and over again, and you = still haven't given any reason why we should consider it to be true. = Please either give a reason, or stop repeating yourself. From nobody Tue Apr 15 09:18: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 634691A04A9 for ; Tue, 15 Apr 2014 09:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 FoSod7UPzEZP for ; Tue, 15 Apr 2014 09:18:28 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id CD03A1A048A for ; Tue, 15 Apr 2014 09:18:28 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id CA4574038F for ; Tue, 15 Apr 2014 12:18:25 -0400 (EDT) Message-ID: <534D5BD1.5020406@viagenie.ca> Date: Tue, 15 Apr 2014 12:18:25 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <4E64CF95-F984-48F2-AEFA-A3E9FF9D38A3@delong.com> In-Reply-To: <4E64CF95-F984-48F2-AEFA-A3E9FF9D38A3@delong.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/9PeUrM72p9lvnGY6ln3ryGGumic Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 16:18:30 -0000 Le 2014-04-15 11:09, Owen DeLong a écrit : > I would support an RA flag that says “If you’re reading this message, don’t do IPv4 on this network”. > > That’s not even close to what is proposed here. Uh? At the very least, it was our intent to propose that very thing. An IPv4 kill switch. > What is proposed here is a variety of IPv6 methods for telling a client to turn off it’s IPv4 dynamic configuration requests and there’s no reason to put that into IPv6 at all. I'm sorry, I'm not following. If your problem is with "variety of methods", then I can understand. We started with DHCPv6 only, then we added RA because people were asking for it. We expect one could be removed if it poses a problem. 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 nobody Tue Apr 15 09:38:18 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 7C4771A07D3 for ; Tue, 15 Apr 2014 09:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.037 X-Spam-Level: ** X-Spam-Status: No, score=2.037 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, J_CHICKENPOX_57=0.6, RP_MATCHES_RCVD=-0.272, 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 XG1TiHaFCUGJ for ; Tue, 15 Apr 2014 09:38:12 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 174F81A079F for ; Tue, 15 Apr 2014 09:38:12 -0700 (PDT) Received: from owens-mbp.meeting.arin.net (unknown.servercentral.net [50.31.214.180] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s3FGXugk006472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Apr 2014 09:33:57 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3FGXugk006472 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1397579638; bh=cOvb789JdCte908FF4ckb1HK5Dc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=kltFWNTJV6vYeDv1GuI41ZT9GWzsmQ6r3+TgE2/hXDPUp67jVqK0f/aAmp+qXirDh YN5aD4lViKZbLBey13VaPRXnru1BiQnE3W8OLOCKtlcHlHqSgsWhZdMh/hHWwfcGO+ i9F9S7Xc46O712tUPE2q49iH3pIt3B8o3cyWpmMg= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: Date: Tue, 15 Apr 2014 09:33:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <534C17B8.8030209@foobar.org> <534C27C9.80701@viagenie.ca> <20140414194824.GY43641@Space.Net> <534C3F7D.3040406@viagenie.ca> <20140414201231.GZ43641@Space.Net> <23F575A3-E00D-410E-9929-7377B7CAA623@nominum.com> <82E804C3-725D-415A-87C3-512073774C6F@delong.com> To: Ted Lemon X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 15 Apr 2014 09:33:58 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/MTe9QMamhWCjDtJz5X-YbM3-KOo Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 16:38:17 -0000 On Apr 15, 2014, at 8:37 AM, Ted Lemon wrote: > On Apr 14, 2014, at 11:51 PM, Owen DeLong wrote: >> Calling it the wrong thing while advocating an even more wrong thing = is equally absurd. >=20 > When I call it the wrong thing, I mean that it doesn't work well (and = I explained that). In practice, not in theory. You are claiming that = adding the capability to shut off DHCPv4 is even more wrong, but you = haven't explained why. So when we weigh the two considerations next to = each other, one of which is substantiated by everybody's daily = experience of Linux networking, and the other of which is purely = speculative and not substantiated by any reasoning that would lead us to = think it is true, then despite the fact that, if it were true, it would = be worse, we should, logically, weigh the other consideration more = heavily. No, I am not. I am claiming that putting DHCPv4 instructions into DHCPv6 = (and/or RA) is even more wrong. I=92m all for adding an ICMP4 or DHCPv4 message to execute that task. I have, in fact explained why and so has Gert and so have several other = people. You are choosing to ignore us while simultaneously disagreeing = with us, but that doesn=92t change the fact that we have, in fact, done = so. However, to summarize: 1. It makes little sense to me to try and turn off DHCPv4 using an = IPv6 message when it can much more cleanly be done with a very simple IPv4 message. 2. A client which is a =93problem=94 as you describe the problem = statement is a client which is sending DHCPv4REQUEST messages. Therefore, an appropriate way to identify and rectify = such a problem is to send an IPv4 packet in response to the DHCPv4REQUEST message which says =93STOP THAT=94. = Such a message could either be a new DHCP response type or an ICMP message indicating that the = DHCPv4 service is unavailable. 3. Others have raised a concern that forged ICMP based =93STOP = THAT=94 messages in IPv4 could: 1. Bypass DHCP Snooping safeguards 2. Serve as a DoS vector 4. The concerns expressed in 3 received the following response: 1. The IPv6 based message would also bypass IPv4 DHCP = snooping 2. Require clients which receive both a =93STOP THAT=94 = message and a DHCPOFFER to act on the Offer and ignore the =93STOP THAT=94 message for some time. 5. You argued that it is more difficult to implement changes to the = DHCPv4 state machine than to implement something where the IPv6 DHCP or RA client would somehow pass a message to = the upstream =93glue code=94 whatever that may be on any given platform which would then cause it to kill off the = DHCPv4 process on the client (and possibly shut down other aspects of the IPv4 stack on the client as well). I don=92t buy that argument as I believe it would be pretty = simple to add code to DHCPv4 clients that essentially does the = following: ... if (DHCP_SHUTDOWN_RECEIVED) { /* code here to listen for other DHCP responses = over the next n seconds (probably n<30) */ if (DHCP_OFFER_RECEIVED) break; /* If needed, any clean-up code before = terminating the DHCPv4 process and/or to shutdown the IPv4 stack */ exit(0); } =85 On the other hand, what you propose requires: 1. Add options to RA 2. Add options to DHCPv6 3. Update every RA implementation to somehow pass = receipt of this option up to =93glue code=94 4. Update every DHCPv6 implementation to somehow = pass receipt of this option up to =93glue code=94 5. Update glue code to deal with all possible = variants of how the RA/DHCPv6 information may be passed up to that glue = code. 6. Update glue code to properly terminate all = possible variants of DHCPv4 client which may be running on the host. 7. Update glue code to do any other tasks required = to shutdown IPv4 on the applicable interface on the host. I=92ll note that in many cases, the DHCPv4, DHCPv6, RA, and = =93glue code=94 come in multiple variants and even in one set of = variants, each of those 4 items may have different maintainers and/or = different organizations/persons responsible for said maintenance. As near as I can tell the draft does not standardize any of the = APIs necessary for the communications in the above 7 steps. > For comparison, suppose you were to assert that there's a significant = risk of giant bunnies leaping out into the road when driving on any = interstate highway in the U.S. We could definitely say that if such a = statement were true, it would require us to change our driving habits. = And yet we likely would not change our driving habits, because you have = given us no reason to think it's true. If you simply want to bloviate while misrepresenting what has been said, = then I see little point in the discussion. Owen From nobody Tue Apr 15 09:43: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 878381A01CB; Tue, 15 Apr 2014 09:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 Dp2ANTac83mC; Tue, 15 Apr 2014 09:43:15 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id BE6741A01BE; Tue, 15 Apr 2014 09:43:14 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id D245620030; Tue, 15 Apr 2014 12:43:27 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 59F8763ABA; Tue, 15 Apr 2014 12:43:06 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 472BB63AA2; Tue, 15 Apr 2014 12:43:06 -0400 (EDT) From: Michael Richardson To: v6ops@ietf.org, Ted Lemon , homenet@ietf.org, sunset4@ietf.org In-Reply-To: <3F8F807A-AE0E-428A-A915-9D5CE8127F1A@fugue.com> References: <534BF803.3090600@viagenie.ca> <87wqes3pms.fsf@toke.dk> <534C214F.6010603@viagenie.ca> <878ur67rx2.fsf@toke.dk> <3F8F807A-AE0E-428A-A915-9D5CE8127F1A@fugue.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/9mR2f1cj2IeshnvRyNHiqYsaSAc Subject: Re: [v6ops] [homenet] Please review the No IPv4 draft 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, 15 Apr 2014 16:43:19 -0000 I think it's important to read the draft, and understand section 5.3, about the "v4-level". I think that the security implications in the document are understood by the authors, but simply not spelled out yet. I think that some additional text in 5.3 might help make it clearer that there might be competing v4-labels coming from different routers/DHCPv6 servers, and that really the one with the lowest value wins. Hosts that don't understand this option will continue to behave as if the option did not occur, and any device for which this option is implemented needs to think about how much credence they will put into it. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Tue Apr 15 09:49: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 55BBB1A0450 for ; Tue, 15 Apr 2014 09:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.262 X-Spam-Level: X-Spam-Status: No, score=-1.262 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.272, 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 yzE5qNY8_CFN for ; Tue, 15 Apr 2014 09:49:01 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id A069B1A01CB for ; Tue, 15 Apr 2014 09:49:00 -0700 (PDT) Received: from owens-mbp.meeting.arin.net (unknown.servercentral.net [50.31.214.180] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s3FGkBsu006866 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Apr 2014 09:46:13 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3FGkBsu006866 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1397580374; bh=VXUmY68+xLOOitXkZc9eNGtpjME=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=Tx02x51uPDHmYdvY/h+m5SV1trDeJBsZyHrx6UR0tUyWOkS0nRB5NwzJdPERfuVcK lvdGokwOA+B3WC6eSbC7fWqhdl75AhDdrD0ax8ziXx6CiYfi4sLMsDBDN4RwIBkNDI adWNVjE9i9CU9yZgEaJS82mQEoSkJQWjPzL8QQnc= Content-Type: multipart/alternative; boundary="Apple-Mail=_67513A67-959A-4F9C-8949-52577739EC36" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: <6D57B3D8-DAF4-4792-BDF5-B0489A283F6B@nominum.com> Date: Tue, 15 Apr 2014 09:46:09 -0700 Message-Id: <0FD7945D-10DF-460C-9773-9C1C90C8CEFB@delong.com> References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> <534C4DF7.4070407@foobar.org> <40E2438A-C43F-4E41-8778-511E53EF7009@nominum.com> <534D1966.5090301@foobar.org> <6D57B3D8-DAF4-4792-BDF5-B0489A283F6B@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 15 Apr 2014 09:46:14 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/A68Tt0CESi6yBwPmR-1t5Xx6-IM Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 16:49:05 -0000 --Apple-Mail=_67513A67-959A-4F9C-8949-52577739EC36 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 15, 2014, at 8:57 AM, Ted Lemon wrote: > On Apr 15, 2014, at 6:35 AM, Nick Hilliard wrote: >> This is not an especially relevant argument because if there were a = dhcpv4 >> option to handle this, all you would need to provide the service = would be a >> local stub dhcpv4 mechanism to reply with a DHCPOFFER with a No = Service >> option. There would be no requirement to back-haul the initial = DHCPREQUEST >> to a centralised provisioning system. >=20 > So now every v6-only CPE router has to have a DHCPv4 implementation = and an IPv4 stack. No, but the ones that want to be able to signal IPv4 operational = behaviors would need to have a minimal IPv4 stack and the ability to do = the following: 1. Detect an IPv4 DHCPREQUEST packet. 2. Respond with an ICMP DHCPv4 unavailable packet 3. A way to turn off this behavior In reality, there=92s not going to be any such thing as a v6-only CPE = router implementation for many years to come, so this argument is rather = specious to begin with. However, in that distant future, the above could = be supported with a pretty small code-base. > BTW, the draft also speaks to the point of why you don't want to use = DHCPv4 for this: once you've turned off IPv4, DHCPv4 can't be used to = turn it back on again. As a general rule, once you turn off a network protocol, turning it back = on requires intervention. I see no reason that we need to contemplate = providing an IPv6 signaling mechanism to turn IPv4 on. > And the message from Simon that I was referring to was the one that = discussed the draft that was proposed in sunset4 for solving this = problem using DHCPv4, which was _not adopted by the working group_. = Draft adoption is part of the working group process; the fact that the = working group decided to merge the DHCPv4 draft into this one, and not = the other way around, is precisely what it means for a working group to = have consensus to push this solution and not the other one. I=92m happy for the working group, but there is very little operator = participation in the sunset4 working group at this time and I suspect = that is one of the reasons said group decided to ask v6ops to review the = draft. You are now hearing from people who are network operators that = they feel this was the wrong approach to adopt and that we do not concur = with the consensus of the sunset4 working group. While I understand you may have expected us to just nod in agreement and = say =93looks good=94, that=92s not the outcome that is actually = happening and continuing to tell us that we should merely nod in = agreement or that our arguments against the choices sunset4 now = considers to be fait accompli are not valid is not a productive approach = to said review. Owen --Apple-Mail=_67513A67-959A-4F9C-8949-52577739EC36 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
    On Apr 15, 2014, at 8:57 AM, Ted Lemon = <ted.lemon@nominum.com>= wrote:

    On Apr 15, 2014, at 6:35 AM, Nick Hilliard <nick@foobar.org> = wrote:
    This is not an especially relevant = argument because if there were a dhcpv4
    option to handle this, all = you would need to provide the service would be a
    local stub dhcpv4 = mechanism to reply with a DHCPOFFER with a No Service
    option. There = would be no requirement to back-haul the initial DHCPREQUEST
    to a = centralised provisioning system.

    So now every = v6-only CPE router has to have a DHCPv4 implementation and an IPv4 = stack.

    No, but the ones that want to be = able to signal IPv4 operational behaviors would need to have a minimal = IPv4 stack and the ability to do the = following:

    1. Detect an IPv4 DHCPREQUEST = packet.
    2. Respond with an ICMP DHCPv4 = unavailable packet
    3. A way to turn off this = behavior

    In reality, there=92s not going to be = any such thing as a v6-only CPE router implementation for many years to = come, so this argument is rather specious to begin with. However, in = that distant future, the above could be supported with a pretty small = code-base.

    BTW, the = draft also speaks to the point of why you don't want to use DHCPv4 for = this: once you've turned off IPv4, DHCPv4 can't be used to turn it back = on again.

    As a general rule, once you = turn off a network protocol, turning it back on requires intervention. I = see no reason that we need to contemplate providing an IPv6 signaling = mechanism to turn IPv4 on.

    And = the message from Simon that I was referring to was the one that = discussed the draft that was proposed in sunset4 for solving this = problem using DHCPv4, which was _not adopted by the working group_. =   Draft adoption is part of the working group process; the = fact that the working group decided to merge the DHCPv4 draft into this = one, and not the other way around, is precisely what it means for a = working group to have consensus to push this solution and not the other = one.

    I=92m happy for the working group, = but there is very little operator participation in the sunset4 working = group at this time and I suspect that is one of the reasons said group = decided to ask v6ops to review the draft. You are now hearing from = people who are network operators that they feel this was the wrong = approach to adopt and that we do not concur with the consensus of the = sunset4 working group.

    While I understand you = may have expected us to just nod in agreement and say =93looks good=94, = that=92s not the outcome that is actually happening and continuing to = tell us that we should merely nod in agreement or that our arguments = against the choices sunset4 now considers to be fait accompli are = not valid is not a productive approach to said = review.

    Owen

    = --Apple-Mail=_67513A67-959A-4F9C-8949-52577739EC36-- From nobody Tue Apr 15 09:53: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 0D9FA1A0499 for ; Tue, 15 Apr 2014 09:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 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.272, 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 IUadZlrScdZx for ; Tue, 15 Apr 2014 09:53:34 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 887B81A02E0 for ; Tue, 15 Apr 2014 09:53:34 -0700 (PDT) Received: from owens-mbp.meeting.arin.net (unknown.servercentral.net [50.31.214.180] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s3FGlewD006926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Apr 2014 09:47:41 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3FGlewD006926 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1397580461; bh=E3qBxCtlp2wdwfRxXtgZiPlJqd4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=QNy8BJvH2zVJYs9sJIZztfRxCwMQmAwTtiTU9jE1vOQPmATUOvrl4q83XIElrgZ+8 570cDiM7Cvv5+M9wrGj8RBvi5bes4k35gOPnxKI9sNW0P+mMtFFCxLE9CILvDw0KyM O2bfqMS//KmPWZIf75HqV+GDWwjK0mUAzzr5bNBE= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: <534D5BD1.5020406@viagenie.ca> Date: Tue, 15 Apr 2014 09:47:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <71F7DEDD-FF39-4D16-8C62-23ABC9CA4734@delong.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <4E64CF95-F984-48F2-AEFA-A3E9FF9D38A3@delong.com> <534D5BD1.5020406@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 15 Apr 2014 09:47:41 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_aaWAy25utkX1l8bv3jhjlmCpZE Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 16:53:42 -0000 On Apr 15, 2014, at 9:18 AM, Simon Perreault = wrote: > Le 2014-04-15 11:09, Owen DeLong a =E9crit : >> I would support an RA flag that says =93If you=92re reading this = message, don=92t do IPv4 on this network=94. >>=20 >> That=92s not even close to what is proposed here. >=20 > Uh? >=20 > At the very least, it was our intent to propose that very thing. An = IPv4 > kill switch. >=20 >> What is proposed here is a variety of IPv6 methods for telling a = client to turn off it=92s IPv4 dynamic configuration requests and = there=92s no reason to put that into IPv6 at all. >=20 > I'm sorry, I'm not following. >=20 > If your problem is with "variety of methods", then I can understand. = We > started with DHCPv6 only, then we added RA because people were asking > for it. We expect one could be removed if it poses a problem. IMHO, this should be reduced to a single bit in an RA if it is = implemented in IPv6 at all. Owen From nobody Tue Apr 15 09:55: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 77FFC1A02E0 for ; Tue, 15 Apr 2014 09:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 26lpbFgXer-8 for ; Tue, 15 Apr 2014 09:55:44 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id C335A1A011A for ; Tue, 15 Apr 2014 09:55:44 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C0C8B4038F; Tue, 15 Apr 2014 12:55:41 -0400 (EDT) Message-ID: <534D648D.8010002@viagenie.ca> Date: Tue, 15 Apr 2014 12:55:41 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Owen DeLong References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <4E64CF95-F984-48F2-AEFA-A3E9FF9D38A3@delong.com> <534D5BD1.5020406@viagenie.ca> <71F7DEDD-FF39-4D16-8C62-23ABC9CA4734@delong.com> In-Reply-To: <71F7DEDD-FF39-4D16-8C62-23ABC9CA4734@delong.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/UVlpsKiWZcWbgKIyTZJIpiK65II Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 16:55:48 -0000 Le 2014-04-15 12:47, Owen DeLong a écrit : > IMHO, this should be reduced to a single bit in an RA if it is implemented in IPv6 at all. Understood. Thanks, 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 nobody Tue Apr 15 09:56: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 8EA551A07B6 for ; Tue, 15 Apr 2014 09:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 PIE5YvyJkezi for ; Tue, 15 Apr 2014 09:56:44 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 89D201A07CB for ; Tue, 15 Apr 2014 09:56:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 7658E8714F8; Tue, 15 Apr 2014 18:56:40 +0200 (CEST) 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 LR9u9Il5c2dU; Tue, 15 Apr 2014 18:56:40 +0200 (CEST) Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 5ACA8870073; Tue, 15 Apr 2014 18:56:40 +0200 (CEST) Message-ID: <534D64C6.5090407@globis.net> Date: Tue, 15 Apr 2014 18:56:38 +0200 From: Ray Hunter User-Agent: Postbox 3.0.9 (Macintosh/20140129) MIME-Version: 1.0 To: Simon Perreault References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> <534C4DF7.4070407@foobar.org> <40E2438A-C43F-4E41-8778-511E53EF7009@nominum.com> <534D1966.5090301@foobar.org> <534D34CC.3030004@viagenie.ca> <534D3A1F.9070307@globis.net> <534D3CDF.5050804@viagenie.ca> In-Reply-To: <534D3CDF.5050804@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xGq59mYLGJZG73jrIrI7U9g7wGU Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 16:56:47 -0000 > Simon Perreault > 15 April 2014 16:06 > Le 2014-04-15 09:54, Ray Hunter a écrit : >>>> This is not an especially relevant argument because if there were a >>>> dhcpv4 >>>> option to handle this, all you would need to provide the service >>>> would be a >>>> local stub dhcpv4 mechanism to reply with a DHCPOFFER with a No Service >>>> option. There would be no requirement to back-haul the initial >>>> DHCPREQUEST >>>> to a centralised provisioning system. IOW, from an operational point of >>>> view, this can be provided simply and easily using dhcpv4 at the local >>>> level, and this mechanism would spectacularly avoid the deployment >>>> problems >>>> that Ray outlined. Handling this over DHCPv6 involves a level of >>>> string, >>>> gum and duck tape that makes me want to cringe. >>> This doesn't work when the L2 link is shared with clients to which you >>> do want to provide IPv4 service. >> Wait a minute. If there's routers there that need to provide IPv4 >> selectively to some client nodes on the same L2 link then you almost >> certainly have an on link DHCPv4 server already. Or at least an IPv4 >> speaking router that can support one. And that is most likely already >> hooked in to a centralised provisioning system via DHCPv4 relays. >> >> And you anyway have to track L2 addresses to know which nodes on the >> link DO need a proper IPv4 service and which DON'T. >> >> In that case, just assigning all clients that do not enjoy an IPv4 >> service an address from a network 10.X.X.X/8 (the range can can be >> re-used on every end router) and filtering at L3 with an access list has >> exactly the same effect. >> Better still: assign those hosts that should not be using IPv4 an >> address with a very long lease via DHCPv4 from one of your RTBH black >> hole ranges. http://tools.ietf.org/html/rfc5635. >> >> They'll never send packets off link and they'll not retransmit DHCPv4 >> requests for a very long time. >> >> It's re-using an existing mechanism that is operationally proven, is >> unlikely to cause surprises, and has the advantage of not requiring any >> new code on either the end nodes nor the last-hop routers. > Can this be propagated inside a home? Of course. Assuming a CPE router allows the admin to configure an arbitrary ACL e.g. access restrictions/outbound/time of day access list to the Internet (which is a very common feature), plus the range of the addresses to be allocated via DHCP (another common feature) you can blanket ban all IPv4 nodes from going off link, whilst shutting up chatty DHCP4 clients by giving them an address blocked by the ACL. Or if you have a mixed scenario, you split your DHCP range into 2 halves. Top half has an ACL preventing Internet access. Bottom half has no ACL preventing Internet access, and you use "Pre-assigned DHCP addresses" in the DHCP server to assign "static" addresses in the appropriate range based on the client's MAC address. That's also already a really common feature in IPv4 CPEs today. >> Why does anyone think that badly behaved DHCPv4 clients will be any >> better behaved because there's a (new) DHCPv6 or RA option being >> advertised? > Badly behaved? Who said anything about badly behaved clients? We're > assuming correct implementations here. -- Regards, RayH From nobody Tue Apr 15 10:15: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 9CE301A01F8 for ; Tue, 15 Apr 2014 10:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 KJjeZN6yuigY for ; Tue, 15 Apr 2014 10:15:45 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1541A04E9 for ; Tue, 15 Apr 2014 10:15:41 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.dyn.netability.ie (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s3FHFb16090999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 15 Apr 2014 18:15:37 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.dyn.netability.ie Message-ID: <534D6957.5000900@foobar.org> Date: Tue, 15 Apr 2014 18:16:07 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Simon Perreault References: <534BF5A5.5010609@viagenie.ca> <534D319C.3030800@viagenie.ca> <534D4E85.5040104@foobar.org> <534D5452.4080300@viagenie.ca> In-Reply-To: <534D5452.4080300@viagenie.ca> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2Pse0rQEigay6cWak1X_dO9SjwM Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 17:15:47 -0000 On 15/04/2014 16:46, Simon Perreault wrote: > This was a mistake on my part. We're trying to do much more. We're > trying to create an IPv4 kill switch. then you need to rewrite sections 1 and 3 from scratch before any other comments from v6ops would be of any relevance. As it stands, you have provided justification for a dhcpv4 client kill switch, but no more. Killing ipv4 on an interface - particularly given the semantics defined in e.g. 5.3.3.h - is a substantial undertaking which will require substantial justification. Killing ipv4 system-wide, as suggested at the end of section 5.3, is something which will be extraordinarily difficult to envisage. > It does not. Did you read our draft? We specify how the No-IPv4 option > is to be processed in multiple interfaces settings. I did read the draft and it does talk about killing ipv4 system-wide, and across all interfaces: > The intent is to remove all traces of IPv4 activity. Once the No- > IPv4 option with value 3 is activated, the network stack should > behave as if IPv4 functionality had never been present. For > example, a modular kernel implementation could accomplish the > above by unloading the IPv4 kernel module at run time. No way, Jose. Simon, I think you need to go back to the drawing board on this draft. As I said before, stopping v4 DHCPREQUEST packets is a good idea and it would be feasible to design a mechanism to implement it. Beyond that, you're on shaky ground. Nick From nobody Tue Apr 15 10:40: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 A95321A0394 for ; Tue, 15 Apr 2014 10:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.128 X-Spam-Level: * X-Spam-Status: No, score=1.128 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_57=0.6, RP_MATCHES_RCVD=-0.272] 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 mT9faONDx-iD for ; Tue, 15 Apr 2014 10:40:02 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6AB1A01E7 for ; Tue, 15 Apr 2014 10:40:02 -0700 (PDT) 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 DECD61B8017 for ; Tue, 15 Apr 2014 10:39:59 -0700 (PDT) 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 D3DDF19005C; Tue, 15 Apr 2014 10:39:59 -0700 (PDT) Received: from [192.168.146.119] (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, 15 Apr 2014 10:39:59 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: Date: Tue, 15 Apr 2014 12:39:57 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <534C17B8.8030209@foobar.org> <534C27C9.80701@viagenie.ca> <20140414194824.GY43641@Space.Net> <534C3F7D.3040406@viagenie.ca> <20140414201231.GZ43641@Space.Net> <23F575A3-E00D-410E-9929-7377B7CAA623@nominum.com> <82E804C3-725D-415A-87C3-512073774C6F@delong.com> To: Owen DeLong X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/eDgb3Zqodt9DE9izAYIy6doF2Js Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 17:40:04 -0000 On Apr 15, 2014, at 11:33 AM, Owen DeLong wrote: > 1. It makes little sense to me to try and turn off DHCPv4 using an = IPv6 message when it can much more cleanly be > done with a very simple IPv4 message. An opinion, which is addressed and refuted in the draft. > 2. A client which is a =93problem=94 as you describe the problem = statement is a client which is sending DHCPv4REQUEST > messages. Therefore, an appropriate way to identify and rectify = such a problem is to send an IPv4 packet in > response to the DHCPv4REQUEST message which says =93STOP THAT=94. = Such a message could either be a > new DHCP response type or an ICMP message indicating that the = DHCPv4 service is unavailable. An opinion, not a technical objection to the current proposal. > 3. Others have raised a concern that forged ICMP based =93STOP = THAT=94 messages in IPv4 could: > 1. Bypass DHCP Snooping safeguards > 2. Serve as a DoS vector True, but since this draft doesn't propose such a mechanism, not a = technical objection to the current proposal. > 4. The concerns expressed in 3 received the following response: > 1. The IPv6 based message would also bypass IPv4 DHCP = snooping > 2. Require clients which receive both a =93STOP THAT=94 = message and a DHCPOFFER to act on the Offer > and ignore the =93STOP THAT=94 message for some time. There's been some discussion of this specifically on the homenet mailing = list which I think didn't get Cc'd here, unfortunately, and it looks = like there will be a new draft out that addresses this issue. > 5. You argued that it is more difficult to implement changes to the = DHCPv4 state machine than to implement something > where the IPv6 DHCP or RA client would somehow pass a message to = the upstream =93glue code=94 whatever that may be > on any given platform which would then cause it to kill off the = DHCPv4 process on the client (and possibly shut down > other aspects of the IPv4 stack on the client as well). No, I said we'd have to update the DHCP protocol specification to add = another state to the state machine, and we'd have to think through all = the implications of that. Whereas simply shutting off the DHCP client = while the network says "suppress IPv4" is quite easy, and we already = know how to do it. >=20 > I don=92t buy that argument as I believe it would be pretty = simple to add code to DHCPv4 clients that essentially does the = following: >=20 > ... > if (DHCP_SHUTDOWN_RECEIVED) > { > /* code here to listen for other DHCP responses = over the next n seconds (probably n<30) */ > if (DHCP_OFFER_RECEIVED) break; > /* If needed, any clean-up code before = terminating the DHCPv4 process and/or to shutdown the IPv4 stack */ > exit(0); > } > =85 Great, so what happens when I switch networks to an IPv4-only network? = My DHCP client is down, and you haven't implemented a mechanism for = bringing it back up. No offense, but I've had my hands deep and dirty = in this code=97I'm not just talking through my hat. >=20 > On the other hand, what you propose requires: >=20 > 1. Add options to RA > 2. Add options to DHCPv6 > 3. Update every RA implementation to somehow pass = receipt of this option up to =93glue code=94 > 4. Update every DHCPv6 implementation to somehow = pass receipt of this option up to =93glue code=94 > 5. Update glue code to deal with all possible = variants of how the RA/DHCPv6 information may be passed up to that glue = code. > 6. Update glue code to properly terminate all = possible variants of DHCPv4 client which may be running on the host. > 7. Update glue code to do any other tasks required = to shutdown IPv4 on the applicable interface on the host. >=20 > I=92ll note that in many cases, the DHCPv4, DHCPv6, RA, and = =93glue code=94 come in multiple variants and even in one set of = variants, > each of those 4 items may have different maintainers and/or = different organizations/persons responsible for said maintenance. >=20 > As near as I can tell the draft does not standardize any of the = APIs necessary for the communications in the above 7 steps. We've never written a standard API for DHCP because nobody's been = interested. Microsoft has their way, Apple has their way, Linux hasn't = really figured out a way yet. When I wrote the ISC client, I made the = action part of the client a shell script so that it would be easy to = script, but that turned out to be a mistake because the DHCP client = state machine interacts with so many other state machines. Right now the state of the art on this is a homogenous configuration = architecture. I share your desire for the architecture to be general = enough that parts can be plugged in and out, but that doesn't mean we = can just punt on making it actually _work_. And if we make it actually = work, the points you raise above, while valid, are not a show stopper. = If we don't care about making it work, then we might as well punt on the = turn-off-DHCPv4 thing entirely on that platform, because I don't think = it can be made to work satisfactorily anyway. If you are interested in what's going on in terms of advancing the state = of the art on Linux, I encourage you to look at what the systemd team is = doing, and also at what Simon Kelley has been doing in dnsmasq. = NetworkManager is not something I'd suggest wasting any time on, and the = other configuration infrastructures on Linux are too half-baked to even = seriously consider when we're talking about touchless configuration. From nobody Tue Apr 15 10:47: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 0C1761A022D for ; Tue, 15 Apr 2014 10:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 kNpqIjKGbV_P for ; Tue, 15 Apr 2014 10:47:20 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id BCD441A026F for ; Tue, 15 Apr 2014 10:47:20 -0700 (PDT) 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 27ED91B8017 for ; Tue, 15 Apr 2014 10:47:18 -0700 (PDT) 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 1DEDC19005C; Tue, 15 Apr 2014 10:47:18 -0700 (PDT) Received: from [192.168.146.119] (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, 15 Apr 2014 10:47:17 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <534D6957.5000900@foobar.org> Date: Tue, 15 Apr 2014 12:47:15 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <6773DA12-104D-4E28-BEE5-807834EF8F2D@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <534D319C.3030800@viagenie.ca> <534D4E85.5040104@foobar.org> <534D5452.4080300@viagenie.ca> <534D6957.5000900@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/vsDOlZjbXgWwVEfuWsC-i8v3nAc Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 17:47:25 -0000 On Apr 15, 2014, at 12:16 PM, Nick Hilliard wrote: > I think you need to go back to the drawing board on this draft. As > I said before, stopping v4 DHCPREQUEST packets is a good idea and it = would > be feasible to design a mechanism to implement it. Beyond that, = you're on > shaky ground. Nick, if you want something like what you just said to actually be the = outcome of the process, you need to give a clear technical objection = that motivates that outcome. From nobody Tue Apr 15 10:58: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 A8DB31A036F for ; Tue, 15 Apr 2014 10:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, 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 FdUbCDpw4i3b for ; Tue, 15 Apr 2014 10:58:34 -0700 (PDT) Received: from linfre.de (linfre.de [83.151.26.85]) by ietfa.amsl.com (Postfix) with ESMTP id 05ED81A0368 for ; Tue, 15 Apr 2014 10:58:34 -0700 (PDT) Received: from linne.localnet (31.150.15.45) by linfreserv.linfre (Axigen) with (AES256-SHA encrypted) ESMTPSA id 2FA59E; Tue, 15 Apr 2014 19:58:18 +0200 From: Karsten Thomann To: v6ops@ietf.org Date: Tue, 15 Apr 2014 19:58:46 +0200 Message-ID: <3446106.k0lm12lQ8b@linne> User-Agent: KMail/4.10.4 (Windows/6.1; KDE/4.10.4; i686; ; ) In-Reply-To: <534D3672.3060702@viagenie.ca> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="nextPart14871702.ghmRgCEENZ" Content-Transfer-Encoding: 7Bit X-AXIGEN-DK-Result: No records DomainKey-Status: no signature X-AxigenSpam-Level: 7 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/if3pf5vwn_CY-6vI8L-BhiCNhBc Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 17:58:36 -0000 This is a multi-part message in MIME format. --nextPart14871702.ghmRgCEENZ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" I have still problems to understand why a message on one link/interface= should be able to=20 shutdown the whole IPv4 stack or the dhcpv4 client, the scope of the me= ssage should be limited=20 to the link/interface on which the message was received and not further= ...=20 In my opinion the system should remove the v4 address, and the dhcpv4 c= lient should stop=20 sending discover messages on that specific interface, and the easiest w= ay to tell dhcpv4 to do=20 that is a dhcpv4 message. Karsten Am Dienstag, 15. April 2014, 09:38:58 schrieb Simon Perreault: > Le 2014-04-15 04:36, Gert Doering a =E9crit : > > I agree to this. Interestingly, this is something else than "just > > shutdown > > the dhcpv4 client if this option is detected" - it is "shutdown IPv= 4", > > which many OSes can't do today at all (and yes, that needs fixing).= >=20 > Correct, it means "shutdown IPv4". Our draft lists precisely what nee= ds > to be shut down. And you're correct in that implementing this could m= ean > more than just "pkill dhclient" on some OSes. But that work needs to > happen anyway. >=20 > Simon --nextPart14871702.ghmRgCEENZ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1"

    I h= ave still problems to understand why a message on one link/interface sh= ould be able to shutdown the whole IPv4 stack or the dhcpv4 client, the= scope of the message should be limited to the link/interface on which = the message was received and not further...

     

    In = my opinion the system should remove the v4 address, and the dhcpv4 clie= nt should stop sending discover messages on that specific interface, an= d the easiest way to tell dhcpv4 to do that is a dhcpv4 message.

     

    Kar= sten

     

    Am = Dienstag, 15. April 2014, 09:38:58 schrieb Simon Perreault:

    >= ; Le 2014-04-15 04:36, Gert Doering a =E9crit :

    >= ; > I agree to this. Interestingly, this is something else than &qu= ot;just

    >= ; > shutdown

    >= ; > the dhcpv4 client if this option is detected" - it is "= ;shutdown IPv4",

    >= ; > which many OSes can't do today at all (and yes, that needs fixin= g).

    >= ;

    >= ; Correct, it means "shutdown IPv4". Our draft lists precisel= y what needs

    >= ; to be shut down. And you're correct in that implementing this could m= ean

    >= ; more than just "pkill dhclient" on some OSes. But that work= needs to

    >= ; happen anyway.

    >= ;

    >= ; Simon

    --nextPart14871702.ghmRgCEENZ-- From nobody Tue Apr 15 11:55: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 CDFE11A02E3 for ; Tue, 15 Apr 2014 11:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.664 X-Spam-Level: ** X-Spam-Status: No, score=2.664 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, 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 Cyy4LnOxZ6j0 for ; Tue, 15 Apr 2014 11:55:09 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBAD1A02D0 for ; Tue, 15 Apr 2014 11:55:09 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.97,865,1389762000"; d="scan'208,217";a="262321333" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 15 Apr 2014 14:54:45 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Tue, 15 Apr 2014 14:55:06 -0400 From: "George, Wes" To: Karsten Thomann , "v6ops@ietf.org" Date: Tue, 15 Apr 2014 14:55:05 -0400 Thread-Topic: [v6ops] Please review the No IPv4 draft Thread-Index: Ac9Y3Dc8f0jahVP2RqqS4GO/4IB2Wg== Message-ID: References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> In-Reply-To: <3446106.k0lm12lQ8b@linne> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CF72F7D418416wesleygeorgetwcablecom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/o7ymImx4R4dzA2PNzLXZew8AXgs Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 18:55:14 -0000 --_000_CF72F7D418416wesleygeorgetwcablecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpGcm9tOiBLYXJzdGVuIFRob21hbm4gPGthcnN0ZW5fdGhvbWFubkBsaW5mcmUuZGU8bWFpbHRv OmthcnN0ZW5fdGhvbWFubkBsaW5mcmUuZGU+Pg0KDQpJIGhhdmUgc3RpbGwgcHJvYmxlbXMgdG8g dW5kZXJzdGFuZCB3aHkgYSBtZXNzYWdlIG9uIG9uZSBsaW5rL2ludGVyZmFjZSBzaG91bGQgYmUg YWJsZSB0byBzaHV0ZG93biB0aGUgd2hvbGUgSVB2NCBzdGFjayBvciB0aGUgZGhjcHY0IGNsaWVu dCwgdGhlIHNjb3BlIG9mIHRoZSBtZXNzYWdlIHNob3VsZCBiZSBsaW1pdGVkIHRvIHRoZSBsaW5r L2ludGVyZmFjZSBvbiB3aGljaCB0aGUgbWVzc2FnZSB3YXMgcmVjZWl2ZWQgYW5kIG5vdCBmdXJ0 aGVyLi4uDQoNCkluIG15IG9waW5pb24gdGhlIHN5c3RlbSBzaG91bGQgcmVtb3ZlIHRoZSB2NCBh ZGRyZXNzLCBhbmQgdGhlIGRoY3B2NCBjbGllbnQgc2hvdWxkIHN0b3Agc2VuZGluZyBkaXNjb3Zl ciBtZXNzYWdlcyBvbiB0aGF0IHNwZWNpZmljIGludGVyZmFjZSwgYW5kIHRoZSBlYXNpZXN0IHdh eSB0byB0ZWxsIGRoY3B2NCB0byBkbyB0aGF0IGlzIGEgZGhjcHY0IG1lc3NhZ2UuDQoNCg0KV0dd IEnigJl2ZSBub3RlZCBwcml2YXRlbHkgdG8gU2ltb24gdGhhdCBJIHRoaW5rIHdlIG5lZWQgbXVj aCBiZXR0ZXIgdGV4dCBpbiB0aGUgZHJhZnQgZGlzY3Vzc2luZyB3aGF0IHRvIGRvIHdoZW4gdGhl cmUgYXJlIG11bHRpcGxlIGludGVyZmFjZXM6DQotIHdoZW4gb25lIGludGVyZmFjZSBoYXMgYmVl biBnaXZlbiBhIGNvZGUgdG8gaW5kaWNhdGUgb25lIG9mIHRoZSAzIHN0YXR1c2VzIGRvY3VtZW50 ZWQgaW4gdGhlIGRyYWZ0LCB3aGF0IGlmIGFueXRoaW5nIGRvIHlvdSBkbyBvbiB0aGUgb3RoZXJz Pw0KLSBXaGVuIHNldmVyYWwgaW50ZXJmYWNlcyByZWNlaXZlIHRoZSBzYW1lIG9yIGNvbmZsaWN0 aW5nIGNvZGVzLCB3aGF0IGRvIHlvdSBkbywgd2hpY2ggaGFzIHByaW9yaXR5LCBvciBkbyB5b3Ug ZGVmYXVsdCB0byB0aGUgbGVhc3QgcmVzdHJpY3RpdmU/DQotIHdoZW4gYSBsb2NhbCBjb25maWd1 cmF0aW9uIGlzIHByZXNlbnQgdG8gb3ZlcnJpZGUgdGhlIG5ldHdvcmstc2VudCBjb2RlLCB3aGF0 IGhhcHBlbnM/DQotIGV0Yy4NCg0KVGhhbmtzLA0KDQpXZXMNCg0KQW55dGhpbmcgYmVsb3cgdGhp cyBsaW5lIGhhcyBiZWVuIGFkZGVkIGJ5IG15IGNvbXBhbnnigJlzIG1haWwgc2VydmVyLCBJIGhh dmUgbm8gY29udHJvbCBvdmVyIGl0Lg0KLS0tLS0tLS0tLS0NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NClRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1h eSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGlj aCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJl bG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29s ZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBp cyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhp cyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24s IGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRo ZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkg cHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFu ZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUt bWFpbCBhbmQgYW55IHByaW50b3V0Lg0K --_000_CF72F7D418416wesleygeorgetwcablecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjps ZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZU OiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBB RERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1S SUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5LYXJzdGVuIFRob21hbm4gJmx0OzxhIGhyZWY9Im1h aWx0bzprYXJzdGVuX3Rob21hbm5AbGluZnJlLmRlIj5rYXJzdGVuX3Rob21hbm5AbGluZnJlLmRl PC9hPiZndDs8YnI+DQo8L2Rpdj4NCjxkaXY+DQo8bWV0YSBuYW1lPSJxcmljaHRleHQiIGNvbnRl bnQ9IjEiPg0KPHN0eWxlIHR5cGU9InRleHQvY3NzIj4NCnAsIGxpIHsgd2hpdGUtc3BhY2U6IHBy ZS13cmFwOyB9DQo8L3N0eWxlPg0KPGRpdiBzdHlsZT0iIGZvbnQtZmFtaWx5OidUYWhvbWEnOyBm b250LXNpemU6OC4yNXB0OyBmb250LXdlaWdodDo0MDA7IGZvbnQtc3R5bGU6bm9ybWFsOyI+DQo8 cCBzdHlsZT0iIG1hcmdpbi10b3A6MHB4OyBtYXJnaW4tYm90dG9tOjBweDsgbWFyZ2luLWxlZnQ6 MHB4OyBtYXJnaW4tcmlnaHQ6MHB4OyAtcXQtYmxvY2staW5kZW50OjA7IHRleHQtaW5kZW50OjBw eDsgLXF0LXVzZXItc3RhdGU6MDsiPg0KSSBoYXZlIHN0aWxsIHByb2JsZW1zIHRvIHVuZGVyc3Rh bmQgd2h5IGEgbWVzc2FnZSBvbiBvbmUgbGluay9pbnRlcmZhY2Ugc2hvdWxkIGJlIGFibGUgdG8g c2h1dGRvd24gdGhlIHdob2xlIElQdjQgc3RhY2sgb3IgdGhlIGRoY3B2NCBjbGllbnQsIHRoZSBz Y29wZSBvZiB0aGUgbWVzc2FnZSBzaG91bGQgYmUgbGltaXRlZCB0byB0aGUgbGluay9pbnRlcmZh Y2Ugb24gd2hpY2ggdGhlIG1lc3NhZ2Ugd2FzIHJlY2VpdmVkIGFuZCBub3QgZnVydGhlci4uLjwv cD4NCjxwIHN0eWxlPSIgbWFyZ2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4t bGVmdDowcHg7IG1hcmdpbi1yaWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRl bnQ6MHB4OyAtcXQtdXNlci1zdGF0ZTowOyI+DQpJbiBteSBvcGluaW9uIHRoZSBzeXN0ZW0gc2hv dWxkIHJlbW92ZSB0aGUgdjQgYWRkcmVzcywgYW5kIHRoZSBkaGNwdjQgY2xpZW50IHNob3VsZCBz dG9wIHNlbmRpbmcgZGlzY292ZXIgbWVzc2FnZXMgb24gdGhhdCBzcGVjaWZpYyBpbnRlcmZhY2Us IGFuZCB0aGUgZWFzaWVzdCB3YXkgdG8gdGVsbCBkaGNwdjQgdG8gZG8gdGhhdCBpcyBhIGRoY3B2 NCBtZXNzYWdlLjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V0ddIEnigJl2ZSBub3RlZCBwcml2YXRlbHkgdG8g U2ltb24gdGhhdCBJIHRoaW5rIHdlIG5lZWQgbXVjaCBiZXR0ZXIgdGV4dCBpbiB0aGUgZHJhZnQg ZGlzY3Vzc2luZyB3aGF0IHRvIGRvIHdoZW4gdGhlcmUgYXJlIG11bHRpcGxlIGludGVyZmFjZXM6 PC9kaXY+DQo8ZGl2Pi0gd2hlbiBvbmUgaW50ZXJmYWNlIGhhcyBiZWVuIGdpdmVuIGEgY29kZSB0 byBpbmRpY2F0ZSBvbmUgb2YgdGhlIDMgc3RhdHVzZXMgZG9jdW1lbnRlZCBpbiB0aGUgZHJhZnQs IHdoYXQgaWYgYW55dGhpbmcgZG8geW91IGRvIG9uIHRoZSBvdGhlcnM/PC9kaXY+DQo8ZGl2Pi0g V2hlbiBzZXZlcmFsIGludGVyZmFjZXMgcmVjZWl2ZSB0aGUgc2FtZSBvciBjb25mbGljdGluZyBj b2Rlcywgd2hhdCBkbyB5b3UgZG8sIHdoaWNoIGhhcyBwcmlvcml0eSwgb3IgZG8geW91IGRlZmF1 bHQgdG8gdGhlIGxlYXN0IHJlc3RyaWN0aXZlPzwvZGl2Pg0KPGRpdj4tIHdoZW4gYSBsb2NhbCBj b25maWd1cmF0aW9uIGlzIHByZXNlbnQgdG8gb3ZlcnJpZGUgdGhlIG5ldHdvcmstc2VudCBjb2Rl LCB3aGF0IGhhcHBlbnM/PC9kaXY+DQo8ZGl2Pi0gZXRjLjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19T UkNfQk9EWV9TRUNUSU9OIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSIgZm9udC1mYW1pbHk6J1RhaG9t YSc7IGZvbnQtc2l6ZTo4LjI1cHQ7IGZvbnQtd2VpZ2h0OjQwMDsgZm9udC1zdHlsZTpub3JtYWw7 Ij4NCjxwIHN0eWxlPSItcXQtcGFyYWdyYXBoLXR5cGU6ZW1wdHk7IG1hcmdpbi10b3A6MHB4OyBt YXJnaW4tYm90dG9tOjBweDsgbWFyZ2luLWxlZnQ6MHB4OyBtYXJnaW4tcmlnaHQ6MHB4OyAtcXQt YmxvY2staW5kZW50OjA7IHRleHQtaW5kZW50OjBweDsgIj4NCjxicj4NCjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L3NwYW4+PHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSIgZm9udC1mYW1pbHk6J1RhaG9tYSc7IGZvbnQtc2l6ZTo4LjI1cHQ7IGZvbnQt d2VpZ2h0OjQwMDsgZm9udC1zdHlsZTpub3JtYWw7Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgbWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDExcHQ7Ij4NClRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7Ij4NCjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFw dDsiPg0KV2VzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IG1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMXB0OyI+DQo8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgbWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjog cmdiKDEyNywgMTI3LCAxMjcpOyBmb250LXNpemU6IDExcHQ7Ij5Bbnl0aGluZyBiZWxvdyB0aGlz IGxpbmUgaGFzIGJlZW4gYWRkZWQgYnkgbXkgY29tcGFueeKAmXMgbWFpbCBzZXJ2ZXIsIEkgaGF2 ZSBubyBjb250cm9sIG92ZXIgaXQuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgbWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDExcHQ7Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDEyNywg MTI3LCAxMjcpOyI+LS0tLS0tLS0tLS08L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bh bj48YnI+DQo8aHI+DQo8Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9IkdyYXkiIHNpemU9IjEiPlRo aXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2Fy bmVyIENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBj b25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdh cm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5DQogZm9yIHRoZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFy ZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBj b3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFu ZCBhdHRhY2htZW50cyB0bw0KIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5k IG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkg ZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBw cmludG91dC48YnI+DQo8L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CF72F7D418416wesleygeorgetwcablecom_-- From nobody Tue Apr 15 12:14: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 018E61A07F2 for ; Tue, 15 Apr 2014 12:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.037 X-Spam-Level: ** X-Spam-Status: No, score=2.037 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, J_CHICKENPOX_57=0.6, RP_MATCHES_RCVD=-0.272, 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 8DmUoIceEaCQ for ; Tue, 15 Apr 2014 12:14:36 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 927611A07DC for ; Tue, 15 Apr 2014 12:14:36 -0700 (PDT) Received: from owens-mbp.meeting.arin.net (unknown.servercentral.net [50.31.214.180] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s3FJ9gJs014271 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Apr 2014 12:09:43 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3FJ9gJs014271 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1397588984; bh=bUXxf1PU+io4mHtvAbhZDQTC/0s=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=up07U6/ufqP+aJItJYRdDialhKxmhLsN5hAVNC3VL7V4wG1OKYe0ZPqVQdpwY3Wh0 j1uBSNn8jacFpRNzK8Bcg20eFGUE4LqRKHdBxqYN3EeyTc93jx6QZ5mLA0pSBZI/Of UhDwzHqZ25vQ9I7uze6jXt0WvYgLT2kvSVs71T/Y= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: Date: Tue, 15 Apr 2014 12:09:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5D2D8B98-FC97-4227-84B1-BCC70FF997F9@delong.com> References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <534C17B8.8030209@foobar.org> <534C27C9.80701@viagenie.ca> <20140414194824.GY43641@Space.Net> <534C3F7D.3040406@viagenie.ca> <20140414201231.GZ43641@Space.Net> <23F575A3-E00D-410E-9929-7377B7CAA623@nominum.com> <82E804C3-725D-415A-87C3-512073774C6F@delong.com> To: Ted Lemon X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 15 Apr 2014 12:09:44 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wP161HfOfg3uOIEk5MGmXMfF17M Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 19:14:41 -0000 On Apr 15, 2014, at 10:39 AM, Ted Lemon wrote: > On Apr 15, 2014, at 11:33 AM, Owen DeLong wrote: >> 1. It makes little sense to me to try and turn off DHCPv4 using an = IPv6 message when it can much more cleanly be >> done with a very simple IPv4 message. >=20 > An opinion, which is addressed and refuted in the draft. Not adequately refuted to change my opinion. >=20 >> 2. A client which is a =93problem=94 as you describe the problem = statement is a client which is sending DHCPv4REQUEST >> messages. Therefore, an appropriate way to identify and rectify = such a problem is to send an IPv4 packet in >> response to the DHCPv4REQUEST message which says =93STOP THAT=94. = Such a message could either be a >> new DHCP response type or an ICMP message indicating that the = DHCPv4 service is unavailable. >=20 > An opinion, not a technical objection to the current proposal. The current proposal states that the problem is clients sending = DHCPv4REQUESTS. >> 3. Others have raised a concern that forged ICMP based =93STOP = THAT=94 messages in IPv4 could: >> 1. Bypass DHCP Snooping safeguards >> 2. Serve as a DoS vector >=20 > True, but since this draft doesn't propose such a mechanism, not a = technical objection to the current proposal. No, a technical solution to the proposed problem. >> 4. The concerns expressed in 3 received the following response: >> 1. The IPv6 based message would also bypass IPv4 DHCP = snooping >> 2. Require clients which receive both a =93STOP THAT=94 = message and a DHCPOFFER to act on the Offer >> and ignore the =93STOP THAT=94 message for some time. >=20 > There's been some discussion of this specifically on the homenet = mailing list which I think didn't get Cc'd here, unfortunately, and it = looks like there will be a new draft out that addresses this issue. OK, but this is a technical problem with the current draft as written. >> 5. You argued that it is more difficult to implement changes to the = DHCPv4 state machine than to implement something >> where the IPv6 DHCP or RA client would somehow pass a message to = the upstream =93glue code=94 whatever that may be >> on any given platform which would then cause it to kill off the = DHCPv4 process on the client (and possibly shut down >> other aspects of the IPv4 stack on the client as well). >=20 > No, I said we'd have to update the DHCP protocol specification to add = another state to the state machine, and we'd have to think through all = the implications of that. Whereas simply shutting off the DHCP client = while the network says "suppress IPv4" is quite easy, and we already = know how to do it. And I=92m saying you don=92t need to add another state to the state = machine, you simply provide a way to tell a DHCPv4 client to turn itself = off. This does not have to be stateful or added to the state machine as = shown below. >=20 >>=20 >> I don=92t buy that argument as I believe it would be pretty = simple to add code to DHCPv4 clients that essentially does the = following: >>=20 >> ... >> if (DHCP_SHUTDOWN_RECEIVED) >> { >> /* code here to listen for other DHCP responses = over the next n seconds (probably n<30) */ >> if (DHCP_OFFER_RECEIVED) break; >> /* If needed, any clean-up code before = terminating the DHCPv4 process and/or to shutdown the IPv4 stack */ >> exit(0); >> } >> =85 >=20 > Great, so what happens when I switch networks to an IPv4-only network? = My DHCP client is down, and you haven't implemented a mechanism for = bringing it back up. No offense, but I've had my hands deep and dirty = in this code=97I'm not just talking through my hat. Neither am I. In my experience on most hosts (and I admit I am not an = expert on all operating systems, but this seems easy enough to change = where a change would be required), the DHCP client gets relaunched on a = link state transition from no-link to link, including sleep/wake events. = Unless you believe such a transition would occur without a link-state or = sleep/wake transition occurring, I don=92t see this as a serious = problem. >> On the other hand, what you propose requires: >>=20 >> 1. Add options to RA >> 2. Add options to DHCPv6 >> 3. Update every RA implementation to somehow pass = receipt of this option up to =93glue code=94 >> 4. Update every DHCPv6 implementation to somehow = pass receipt of this option up to =93glue code=94 >> 5. Update glue code to deal with all possible = variants of how the RA/DHCPv6 information may be passed up to that glue = code. >> 6. Update glue code to properly terminate all = possible variants of DHCPv4 client which may be running on the host. >> 7. Update glue code to do any other tasks required = to shutdown IPv4 on the applicable interface on the host. >>=20 >> I=92ll note that in many cases, the DHCPv4, DHCPv6, RA, and = =93glue code=94 come in multiple variants and even in one set of = variants, >> each of those 4 items may have different maintainers and/or = different organizations/persons responsible for said maintenance. >>=20 >> As near as I can tell the draft does not standardize any of the = APIs necessary for the communications in the above 7 steps. >=20 > We've never written a standard API for DHCP because nobody's been = interested. Microsoft has their way, Apple has their way, Linux hasn't = really figured out a way yet. When I wrote the ISC client, I made the = action part of the client a shell script so that it would be easy to = script, but that turned out to be a mistake because the DHCP client = state machine interacts with so many other state machines. Right=85 But we=92ve also never required interaction between DHCPv6 and = the behavior of the DHCPv4 client before, either, whether directly or = through =93glue code=94. > Right now the state of the art on this is a homogenous configuration = architecture. I share your desire for the architecture to be general = enough that parts can be plugged in and out, but that doesn't mean we = can just punt on making it actually _work_. And if we make it actually = work, the points you raise above, while valid, are not a show stopper. = If we don't care about making it work, then we might as well punt on the = turn-off-DHCPv4 thing entirely on that platform, because I don't think = it can be made to work satisfactorily anyway. No, the state of the art is all over the map. There is absolutely no = homogenous configuration architecture. One may be getting developed here = and there on some platform(s) and some platforms may actually already = have one, but it is by no means the ubiquitous state of the art. I=92m not proposing punting on making it work. In fact, I proposed what = I believe to be a superior solution which keeps things properly modular, = but you want to decry my concerns as invalid simply because I=92m not = paying attention to sunset4, but as an operator I am here in v6ops, = which in my mind is one of the main reasons for bringing this draft to = v6ops. I care about making it work, but as you have just admitted, it can be = made to work in a way which doesn=92t break modularity. > If you are interested in what's going on in terms of advancing the = state of the art on Linux, I encourage you to look at what the systemd = team is doing, and also at what Simon Kelley has been doing in dnsmasq. = NetworkManager is not something I'd suggest wasting any time on, and = the other configuration infrastructures on Linux are too half-baked to = even seriously consider when we're talking about touchless = configuration. Unfortunately, while I might personally find that entertaining, I = actually have other more pressing things that I must do for $DAYJOB. I think you will find that this is one of the primary reasons that = operator participation in the IETF and other such working groups and = development efforts. The biggest other one would be the tendency to tell us that we=92re not = complaining in the correct way or that our concerns are invalid when we = do speak up. Owen From nobody Tue Apr 15 12:24: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 5DD1A1A0471 for ; Tue, 15 Apr 2014 12:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.663 X-Spam-Level: ** X-Spam-Status: No, score=2.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.272, 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 0hWWIqmlZVFu for ; Tue, 15 Apr 2014 12:24:18 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 24CC21A011A for ; Tue, 15 Apr 2014 12:24:18 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.97,865,1389762000"; d="scan'208";a="262381148" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 15 Apr 2014 15:23:54 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Tue, 15 Apr 2014 15:24:15 -0400 From: "George, Wes" To: "Bernie Volz (volz)" , Simon Perreault , "Dale W. Carder" Date: Tue, 15 Apr 2014 15:24:13 -0400 Thread-Topic: [v6ops] Please review the No IPv4 draft Thread-Index: Ac9Y4Ekwz2ZoJDUtQhqIwZlylZxXnQ== Message-ID: References: <534BF5A5.5010609@viagenie.ca> <20140415142103.GA50776@ricotta.doit.wisc.edu> <534D4D32.7080001@viagenie.ca> <489D13FBFA9B3E41812EA89F188F018E1AFE5ACB@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AFE5ACB@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jWSewvvETBvIFioVOl448ofW22Y Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 19:24:22 -0000 T24gNC8xNS8xNCwgMTE6MjAgQU0sICJCZXJuaWUgVm9seiAodm9seikiIDx2b2x6QGNpc2NvLmNv bT4gd3JvdGU6DQoNCg0KPlllYWgsIGJ1dCB3ZSBzdXJ2aXZlZCB0aGUgdHJhbnNpdGlvbiBhd2F5 IGZyb20gdGhlc2Ugb2xkZXIgbmV0d29ya3MNCj53aXRob3V0IHNpZ25pZmljYW50IGlzc3VlcyBh bmQgc3BlY2lhbCBtZXNzYWdlcyBvbiBJUHY0IHRvIHRlbGwgY2xpZW50cw0KPiJkb24ndCB0cnkg SVBYIG9yIEFwcGxlVGFsayBvciAuLi4iLg0KPg0KPi0gQmVybmllDQoNCk9rLiBZb3VuZ2lu4oCZ IChhbmQgY29jaGFpciBvZiBTdW5zZXQ0KSBzcGVha2luZy4gTXkgZXhwZXJpZW5jZSB3aXRoDQpu ZXR3b3JraW5nIGJlZ2lucyBhZnRlciB0aGVzZSB0cmFuc2l0aW9ucyB3ZXJlIGxhcmdlbHkgY29t cGxldGUsIHNvIEkNCmdlbnVpbmVseSBkb27igJl0IGhhdmUgYSBnb29kIHNlbnNlIGZvciB3aGF0 IHdhcyBkb25lIHRvIOKAnHN1cnZpdmUiIHRoaXMNCnRyYW5zaXRpb24sIGFuZCBJ4oCZZCBiZXQg U2ltb24gZG9lc27igJl0IGVpdGhlci4gSWYgdGhhdOKAmXMgcmVhbGx5IHRoZSByaWdodA0KbW9k ZWwsIHBsZWFzZSBleHBsYWluIHdoYXQgdGhhdCBhY3R1YWxseSBtZWFucywgc2luY2UgaW4gU3Vu c2V0NCB3ZeKAmXJlDQpzdXBwb3NlZCB0byBiZSBmaWd1cmluZyBvdXQgd2hhdCB0aGlzIHRyYW5z aXRpb24gbG9va3MgbGlrZSwgaG93IHRvIHR1cm4NCm9mZiBJUHY0LCBldGMuIElmIGl04oCZcyBy ZWFsbHkgYmVlbiBkb25lLCBJIGRvbuKAmXQgd2FudCB0byByZWludmVudCB0aGUNCndoZWVsLCBi dXQgSSBuZWVkIG1vcmUgdG8gZ28gb24gdGhhbiB0aGUgaGFuZHdhdmluZyB0aGF0IGhhcyBzbyBm YXINCmFjY29tcGFuaWVkIHRoaXMgYXNzZXJ0aW9uLiBBbnN3ZXIgc3BlY2lmaWNhbGx5IGlmIHlv dSBhcmUgdGhpbmtpbmcgb2YgYQ0Kc3BlY2lmaWMgbmV0d29yaywgb3IgZ2VuZXJpY2FsbHkgaWYg dGhhdOKAmXMgbW9yZSBhcHByb3ByaWF0ZS4NCg0KRGlkIHRoZXkgZGllIG9mIG5hdHVyYWwgY2F1 c2VzIEkuZS4gbW9zdCBjbGllbnRzIHNpbXBseSBzdG9wcGVkIGhhdmluZw0KdGhlbSBlbmFibGVk IGJ5IGRlZmF1bHQ/IElmIHllcywgb3ZlciB3aGF0IHRpbWVmcmFtZT8NCldlcmUgc29tZSBuZXR3 b3JrcyBmb3JjaW5nIHRob3NlIHByb3RvY29scyB0byBiZSBkaXNhYmxlZCB2aWEgZ29pbmcgdG8N CmVhY2ggaG9zdCBhbmQgbWFudWFsbHkgY29uZmlndXJpbmc/IE9yIHdhcyB0aGUgYmFja2dyb3Vu ZCB0cmFmZmljIHNvDQpuZWdsaWdpYmxlIHRoYXQgaXQgd2FzIHNpbXBseSBpZ25vcmVkPw0KV2hh dCB3YXMgdGhlIG9yZGVyIG9mIG1hZ25pdHVkZSBvZiBzaXplIG9mIHRoZSBicm9hZGNhc3QgZG9t YWluPyBOdW1iZXIgb2YNCmhvc3RzIHRoYXQgbWlnaHQgaGF2ZSB0byBiZSB0b3VjaGVkIG9uIGFu IGF2ZXJhZ2UgbmV0d29yaz8gSG93IG1hbnkgaG9zdHMNCndlcmUgZHluYW1pY2FsbHkgY29uZmln dXJlZCB2cyBzdGF0aWM/IERIQ1Agd2FzIHByZXR0eSBuZXcgdGhlbiwgd2FzbuKAmXQgaXQ/DQpT aW5jZSB3ZeKAmXZlIGJyb3VnaHQgdXAgcmVkdWNpbmcganVuayBjbGllbnQtc291cmNlZCB0cmFm ZmljIG9uIHdpcmVsZXNzDQpuZXR3b3JrcyBhcyBvbmUgb2YgdGhlIGdvYWxzIG9mIGJlaW5nIGFi bGUgdG8gdGVsbCBjbGllbnRzIHRvIHN0b3ANCnNwZWFraW5nIERIQ1B2NCwgb3IgSVB2NC9hcnAg aW4gZ2VuZXJhbCwgaG93IG1hbnkgd2lyZWxlc3MgSVBYIGFuZA0KQXBwbGV0YWxrIG5ldHdvcmtz IHdlcmUgdGhlcmU/IChhbmQgeWVzIHRoYXQgbGFzdCBxdWVzdGlvbiBpcyBtb3N0bHkNCnRvbmd1 ZS1pbi1jaGVlaykNCg0KVGhhbmtzLA0KDQpXZXMNCg0KDQpBbnl0aGluZyBiZWxvdyB0aGlzIGxp bmUgaGFzIGJlZW4gYWRkZWQgYnkgbXkgY29tcGFueeKAmXMgbWFpbCBzZXJ2ZXIsIEkNCmhhdmUg bm8gY29udHJvbCBvdmVyIGl0Lg0KLS0tLS0tLS0tLS0NCg0KDQoNClRoaXMgRS1tYWlsIGFuZCBh bnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3By aWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9y IHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhp cyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFs IG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVk IHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9u IHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8g dGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFs IGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0K From nobody Tue Apr 15 12:26: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 04EE01A06CB for ; Tue, 15 Apr 2014 12:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, 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 WGp7mC-t7DBY for ; Tue, 15 Apr 2014 12:25:54 -0700 (PDT) Received: from linfre.de (linfre.de [83.151.26.85]) by ietfa.amsl.com (Postfix) with ESMTP id 350D61A06C1 for ; Tue, 15 Apr 2014 12:25:54 -0700 (PDT) Received: from linne.localnet (31.150.15.45) by linfreserv.linfre (Axigen) with (AES256-SHA encrypted) ESMTPSA id 3AB522; Tue, 15 Apr 2014 21:25:39 +0200 From: Karsten Thomann To: "George, Wes" Date: Tue, 15 Apr 2014 21:26:06 +0200 Message-ID: <6788197.iuYbI3p2ZC@linne> User-Agent: KMail/4.10.4 (Windows/6.1; KDE/4.10.4; i686; ; ) In-Reply-To: References: <534BF5A5.5010609@viagenie.ca> <3446106.k0lm12lQ8b@linne> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="nextPart34091340.cT32MB59DP" Content-Transfer-Encoding: 7Bit X-AXIGEN-DK-Result: No records DomainKey-Status: no signature X-AxigenSpam-Level: 7 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ozsKMAu-RjbTIRnHyKFhpJEYj_A Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 19:25:59 -0000 This is a multi-part message in MIME format. --nextPart34091340.cT32MB59DP Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="cp 1252" - when one interface has been given a code to indicate one of the 3 sta= tuses documented in the=20 draft, what if anything do you do on the others? [KT] In my opinion such messages must be kept interface specific in all= cases, for example you=20 want to use a vpn connection to a IPv4 network behind the vpn gateway o= ver an IPv6 network,=20 how that should be possible when the ipv4 stack is disabled globally by= one option on the=20 interface? - When several interfaces receive the same or conflicting codes, what d= o you do, which has=20 priority, or do you default to the least restrictive? [KT] as already written it must be kept interface specific, and with co= nflicting codes use the least=20 restrictive, as the other router may still offer ipv4 connectivity, eve= n only local or to other=20 networks at the site - when a local configuration is present to override the network-sent co= de, what happens? [KT] Use the more specific approach, as host configuration is more spec= ific than link specific the=20 host configuration should take precedence over the network-sent code Am Dienstag, 15. April 2014, 14:55:05 schrieb George, Wes: *From: *Karsten Thomann I have still problems to understand why a message on one link/interface= should be able to=20 shutdown the whole IPv4 stack or the dhcpv4 client, the scope of the me= ssage should be limited=20 to the link/interface on which the message was received and not further= ... In my opinion the system should remove the v4 address, and the dhcpv4 c= lient should stop=20 sending discover messages on that specific interface, and the easiest w= ay to tell dhcpv4 to do=20 that is a dhcpv4 message. WG] I=92ve noted privately to Simon that I think we need much better te= xt in the draft discussing=20 what to do when there are multiple interfaces: - when one interface has been given a code to indicate one of the 3 sta= tuses documented in the=20 draft, what if anything do you do on the others? - When several interfaces receive the same or conflicting codes, what d= o you do, which has=20 priority, or do you default to the least restrictive? - when a local configuration is present to override the network-sent co= de, what happens? - etc. Thanks, =20 Wes =20 Anything below this line has been added by my company=92s mail server, = I have no control over it. ----------- -------------------- This E-mail and any of its attachments may contain Time Warner Cable pr= oprietary information,=20 which is privileged, confidential, or subject to copyright belonging to= Time Warner Cable. This E- mail is intended solely for the use of the individual or entity to whic= h it is addressed. If you are not=20 the intended recipient of this E-mail, you are hereby notified that any= dissemination, distribution,=20 copying, or action taken in relation to the contents of and attachments= to this E-mail is strictly=20 prohibited and may be unlawful. If you have received this E-mail in err= or, please notify the sender=20 immediately and permanently delete the original and any copy of this E-= mail and any printout. -------- [1] mailto:karsten_thomann@linfre.de --nextPart34091340.cT32MB59DP Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="cp 1252"

    - w= hen one interface has been given a code to indicate one of the 3 status= es documented in the draft, what if anything do you do on the others?

    [KT= ] In my opinion such messages must be kept interface specific in all ca= ses, for example you want to use a vpn connection to a IPv4 network beh= ind the vpn gateway over an IPv6 network, how that should be possible w= hen the ipv4 stack is disabled globally by one option on the interface?=

     

    - W= hen several interfaces receive the same or conflicting codes, what do y= ou do, which has priority, or do you default to the least restrictive?<= /p>

    [KT= ] as already written it must be kept interface specific, and with confl= icting codes use the least restrictive, as the other router may still o= ffer ipv4 connectivity, even only local or to other networks at the sit= e

     

    - w= hen a local configuration is present to override the network-sent code,= what happens?

    [KT= ] Use the more specific approach, as host configuration is more specifi= c than link specific the host configuration should take precedence over= the network-sent code

     

     

     

    Am = Dienstag, 15. April 2014, 14:55:05 schrieb George, Wes:

    From: Karsten Thomann <karsten_thomann= @linfre.de>

    I have still problems to understand why a = message on one link/interface should be able to shutdown the whole IPv4= stack or the dhcpv4 client, the scope of the message should be limited= to the link/interface on which the message was received and not furthe= r...

    In my opinion the system should remove the= v4 address, and the dhcpv4 client should stop sending discover message= s on that specific interface, and the easiest way to tell dhcpv4 to do = that is a dhcpv4 message.

    <= br />

    <= br />

    W= G] I=92ve noted privately to Simon that I think we need much better tex= t in the draft discussing what to do when there are multiple interfaces= :

    -= when one interface has been given a code to indicate one of the 3 stat= uses documented in the draft, what if anything do you do on the others?=

    -= When several interfaces receive the same or conflicting codes, what do= you do, which has priority, or do you default to the least restrictive= ?

    -= when a local configuration is present to override the network-sent cod= e, what happens?

    -= etc.

     

     

    Thanks,=

    =A0

    Wes

    =A0

    Anything below this line has been added by my company=92s mail = server, I have no control over it.

    -----------

    This E-mail and any o= f its attachments may contain Time Warner Cable proprietary information= , which is privileged, confidential, or subject to copyright belonging = to Time Warner Cable. This E-mail is intended solely for the use of the= individual or entity to which it is addressed. If you are not the inte= nded recipient of this E-mail, you are hereby notified that any dissemi= nation, distribution, copying, or action taken in relation to the conte= nts of and attachments to this E-mail is strictly prohibited and may be= unlawful. If you have received this E-mail in error, please notify the= sender immediately and permanently delete the original and any copy of= this E-mail and any printout.



    --nextPart34091340.cT32MB59DP-- From nobody Tue Apr 15 13:03: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 5C5361A0322 for ; Tue, 15 Apr 2014 13:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.163 X-Spam-Level: * X-Spam-Status: No, score=1.163 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272, 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 g1E2Pg4h2s33 for ; Tue, 15 Apr 2014 13:02:34 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id D4DAA1A01FB for ; Tue, 15 Apr 2014 13:02:28 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.97,866,1389762000"; d="scan'208,217";a="270120439" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 15 Apr 2014 16:02:05 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Tue, 15 Apr 2014 16:02:25 -0400 From: "George, Wes" To: Owen DeLong , Ted Lemon Date: Tue, 15 Apr 2014 16:02:24 -0400 Thread-Topic: [v6ops] Please review the No IPv4 draft Thread-Index: Ac9Y5Z6LG/OMhHGUSLmMFR+E9KQd+g== Message-ID: References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> <534C4DF7.4070407@foobar.org> <40E2438A-C43F-4E41-8778-511E53EF7009@nominum.com> <534D1966.5090301@foobar.org> <6D57B3D8-DAF4-4792-BDF5-B0489A283F6B@nominum.com> <0FD7945D-10DF-460C-9773-9C1C90C8CEFB@delong.com> In-Reply-To: <0FD7945D-10DF-460C-9773-9C1C90C8CEFB@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CF7300251845Fwesleygeorgetwcablecom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/LPIKq3egQGsGloRSC1vYinhpcDE Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 20:02:39 -0000 --_000_CF7300251845Fwesleygeorgetwcablecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IE93ZW4gRGVMb25nIDxvd2VuQGRlbG9uZy5jb208bWFpbHRvOm93ZW5AZGVsb25n LmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBBcHJpbCAxNSwgMjAxNCBhdCAxMjo0NiBQTQ0KVG86IFRl ZCBMZW1vbiA8dGVkLmxlbW9uQG5vbWludW0uY29tPG1haWx0bzp0ZWQubGVtb25Abm9taW51bS5j b20+Pg0KQ2M6ICJ2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+IiA8djZvcHNA aWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbdjZvcHNdIFBs ZWFzZSByZXZpZXcgdGhlIE5vIElQdjQgZHJhZnQNCg0KDQpJbiByZWFsaXR5LCB0aGVyZeKAmXMg bm90IGdvaW5nIHRvIGJlIGFueSBzdWNoIHRoaW5nIGFzIGEgdjYtb25seSBDUEUgcm91dGVyIGlt cGxlbWVudGF0aW9uIGZvciBtYW55IHllYXJzIHRvIGNvbWUsIHNvIHRoaXMgYXJndW1lbnQgaXMg cmF0aGVyIHNwZWNpb3VzIHRvIGJlZ2luIHdpdGguIEhvd2V2ZXIsIGluIHRoYXQgZGlzdGFudCBm dXR1cmUsIHRoZSBhYm92ZSBjb3VsZCBiZSBzdXBwb3J0ZWQgd2l0aCBhIHByZXR0eSBzbWFsbCBj b2RlLWJhc2UuDQoNCldHXSB5ZWFo4oCmIGhhdmUgeW91IHNlZW4gaG93IGxvbmcgaXQgdGFrZXMg SUVURiB3b3JrIHRvIHByb2dyZXNzIGZyb20gZHJhZnQgdG8gYWN0dWFsIGRlcGxveWVkIGltcGxl bWVudGF0aW9uPyBFc3BlY2lhbGx5IGlmIHlvdeKAmXJlIGZhY3RvcmluZyBpbiB0aGUgYXZlcmFn ZSBoYWxmLWxpZmUgb2YgYSBjb25zdW1lciBDUEUgcm91dGVyPyBUaGF04oCZcyB3aHkgd2UgYXJl IHN0YXJ0aW5nIG5vdy4gIEl04oCZcyBub3QgYSBzcGVjaW91cyBhcmd1bWVudCwganVzdCB2ZXJ5 IGZvcndhcmQgbG9va2luZy4NCg0KQW5kIHRoZSBtZXNzYWdlIGZyb20gU2ltb24gdGhhdCBJIHdh cyByZWZlcnJpbmcgdG8gd2FzIHRoZSBvbmUgdGhhdCBkaXNjdXNzZWQgdGhlIGRyYWZ0IHRoYXQg d2FzIHByb3Bvc2VkIGluIHN1bnNldDQgZm9yIHNvbHZpbmcgdGhpcyBwcm9ibGVtIHVzaW5nIERI Q1B2NCwgd2hpY2ggd2FzIF9ub3QgYWRvcHRlZCBieSB0aGUgd29ya2luZyBncm91cF8uICAgRHJh ZnQgYWRvcHRpb24gaXMgcGFydCBvZiB0aGUgd29ya2luZyBncm91cCBwcm9jZXNzOyB0aGUgZmFj dCB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIGRlY2lkZWQgdG8gbWVyZ2UgdGhlIERIQ1B2NCBkcmFm dCBpbnRvIHRoaXMgb25lLCBhbmQgbm90IHRoZSBvdGhlciB3YXkgYXJvdW5kLCBpcyBwcmVjaXNl bHkgd2hhdCBpdCBtZWFucyBmb3IgYSB3b3JraW5nIGdyb3VwIHRvIGhhdmUgY29uc2Vuc3VzIHRv IHB1c2ggdGhpcyBzb2x1dGlvbiBhbmQgbm90IHRoZSBvdGhlciBvbmUuDQpJ4oCZbSBoYXBweSBm b3IgdGhlIHdvcmtpbmcgZ3JvdXAsIGJ1dCB0aGVyZSBpcyB2ZXJ5IGxpdHRsZSBvcGVyYXRvciBw YXJ0aWNpcGF0aW9uIGluIHRoZSBzdW5zZXQ0IHdvcmtpbmcgZ3JvdXAgYXQgdGhpcyB0aW1lIGFu ZCBJIHN1c3BlY3QgdGhhdCBpcyBvbmUgb2YgdGhlIHJlYXNvbnMgc2FpZCBncm91cCBkZWNpZGVk IHRvIGFzayB2Nm9wcyB0byByZXZpZXcgdGhlIGRyYWZ0Lg0KV0ddIFdvcmtpbmcgZ3JvdXAgY2hh aXIgaGF0IG9uOiBBY3R1YWxseSwgdGhlcmXigJlzIGRlY2VudCBvcGVyYXRvciBwYXJ0aWNpcGF0 aW9uIGFzIGEgcGVyY2VudGFnZSBvZiBvdmVyYWxsLCBidXQgdW5mb3J0dW5hdGVseSB0aGVyZSBp cyB2ZXJ5IGxpdHRsZSBwYXJ0aWNpcGF0aW9uIGluIHRoZSBXRyBwZXJpb2QsIHNvIHdlIHdlcmVu 4oCZdCBjb21mb3J0YWJsZSB3aXRoIHRoZSBsZXZlbCBvZiBmZWVkYmFjayB0aGUgZHJhZnQgaGFk IHJlY2VpdmVkIHRodXMgZmFyIGFuZCBhc2tlZCBmb3IgYWRkaXRpb25hbCByZXZpZXcuDQoNCllv dSBhcmUgbm93IGhlYXJpbmcgZnJvbSBwZW9wbGUgd2hvIGFyZSBuZXR3b3JrIG9wZXJhdG9ycyB0 aGF0IHRoZXkgZmVlbCB0aGlzIHdhcyB0aGUgd3JvbmcgYXBwcm9hY2ggdG8gYWRvcHQgYW5kIHRo YXQgd2UgZG8gbm90IGNvbmN1ciB3aXRoIHRoZSBjb25zZW5zdXMgb2YgdGhlIHN1bnNldDQgd29y a2luZyBncm91cC4NCg0KV0ddIFllcywgYnV0IGJhc2VkIG9uIHlvdXIgcHJldmlvdXMgbWVzc2Fn ZXMsIHlvdSBzZWVtIHRvIGhhdmUgYSBmdW5kYW1lbnRhbCBpc3N1ZSB3aXRoIGFueSBJUHY0L0RD SFB2NCBjb25maWd1cmF0aW9uIGJlaW5nIHNlbnQgb3ZlciBJUHY2LCBhbmQgYXMgSSBub3RlZCBp biBteSBwcmV2aW91cyByZXNwb25zZSB0byB5b3UsIERIQyBpcyBhbHNvIG1vdmluZyB0b3dhcmQg dGhlIHBhdGggb2YgZG9pbmcgdGhpcywganVzdCBub3Qgd2l0aCBhIGtpbGwgc3dpdGNoLCBhbmQg d2l0aCBkaWZmZXJlbnQgdGVjaG5pY2FsIGp1c3RpZmljYXRpb24uIE5vdCBzYXlpbmcgdGhhdCBt YWtlcyBpdCByaWdodCwgYnV0IGlmIGl04oCZcyBub3QsIHRoZXJl4oCZcyBhIG11Y2ggbGFyZ2Vy IGRpc2N1c3Npb24gdG8gYmUgaGFkLCBhbmQgdGhlIGZvbGtzIGluIERIQyB0aGF0IGFyZSB3b3Jr aW5nIG9uIHRob3NlIGRyYWZ0cyBwcm9iYWJseSBuZWVkIHNpbWlsYXIgZmVlZGJhY2sgaWYgdGhl cmXigJlzIHRydWx5IGEgdGVjaG5pY2FsIHByb2JsZW0gd2l0aCBpdCBhbmQgbm90IHRoYXQgaXQg c2ltcGx5IGlzbuKAmXQgYXJjaGl0ZWN0dXJhbGx5IHB1cmUgZW5vdWdoIGZvciB5b3UuIEluIG90 aGVyIHdvcmRzLCBTdW5zZXQ0IGlzIG1vdmluZyB0aGlzIGRpcmVjdGlvbiBiZWNhdXNlIGl0IGVu YWJsZXMgdXMgdG8gbGV2ZXJhZ2Ugd29yayB0aGF0IGlzIGFscmVhZHkgaGFwcGVuaW5nIGluIERI QywgYW5kIHdlIGFyZSB0cnlpbmcgdG8gY29vcmRpbmF0ZSB0aG9zZSBlZmZvcnRzIHdpdGggdGhl bS4gIFNvIEnigJlkIHJlY29tbWVuZCBnb2luZyB0byByZWFkIHRoZSBkcmFmdHMgSSBwb2ludGVk IHlvdSB0byB5ZXN0ZXJkYXksIGFuZCBkZXRlcm1pbmluZyB3aGV0aGVyIHlvdSBoYXZlIGEgcHJv YmxlbSB3aXRoIHRoZSB3aG9sZSBjb25jZXB0IG9yIGp1c3Qgc3Vuc2V0NOKAmXMgcGFydGljdWxh ciBwaWVjZSBvZiBpdCwgYW5kIHByb2NlZWRpbmcgYWNjb3JkaW5nbHkuDQoNClRoYW5rcywNCg0K V2VzDQoNCkFueXRoaW5nIGJlbG93IHRoaXMgbGluZSBoYXMgYmVlbiBhZGRlZCBieSBteSBjb21w YW554oCZcyBtYWlsIHNlcnZlciwgSSBoYXZlIG5vIGNvbnRyb2wgb3ZlciBpdC4NCi0tLS0tLS0t LS0tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUaGlzIEUtbWFpbCBhbmQg YW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9w cmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBv ciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRo aXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVh bCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmll ZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlv biB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRv IHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4g SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5h bCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCg== --_000_CF7300251845Fwesleygeorgetwcablecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19C T0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXpl OjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1 bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBB RERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYg MXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+T3dlbiBEZUxvbmcg Jmx0OzxhIGhyZWY9Im1haWx0bzpvd2VuQGRlbG9uZy5jb20iPm93ZW5AZGVsb25nLmNvbTwvYT4m Z3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UdWVz ZGF5LCBBcHJpbCAxNSwgMjAxNCBhdCAxMjo0NiBQTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5UbzogPC9zcGFuPlRlZCBMZW1vbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRlZC5s ZW1vbkBub21pbnVtLmNvbSI+dGVkLmxlbW9uQG5vbWludW0uY29tPC9hPiZndDs8YnI+DQo8c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWls dG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW3Y2b3BzXSBQbGVh c2UgcmV2aWV3IHRoZSBObyBJUHY0IGRyYWZ0PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNw LW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyI+DQo8 YnI+DQo8ZGl2Pg0KPGRpdj5JbiByZWFsaXR5LCB0aGVyZeKAmXMgbm90IGdvaW5nIHRvIGJlIGFu eSBzdWNoIHRoaW5nIGFzIGEgdjYtb25seSBDUEUgcm91dGVyIGltcGxlbWVudGF0aW9uIGZvciBt YW55IHllYXJzIHRvIGNvbWUsIHNvIHRoaXMgYXJndW1lbnQgaXMgcmF0aGVyIHNwZWNpb3VzIHRv IGJlZ2luIHdpdGguIEhvd2V2ZXIsIGluIHRoYXQgZGlzdGFudCBmdXR1cmUsIHRoZSBhYm92ZSBj b3VsZCBiZSBzdXBwb3J0ZWQgd2l0aCBhIHByZXR0eSBzbWFsbCBjb2RlLWJhc2UuPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5X R10geWVhaOKApiBoYXZlIHlvdSBzZWVuIGhvdyBsb25nIGl0IHRha2VzIElFVEYgd29yayB0byBw cm9ncmVzcyBmcm9tIGRyYWZ0IHRvIGFjdHVhbCBkZXBsb3llZCBpbXBsZW1lbnRhdGlvbj8gRXNw ZWNpYWxseSBpZiB5b3XigJlyZSBmYWN0b3JpbmcgaW4gdGhlIGF2ZXJhZ2UgaGFsZi1saWZlIG9m IGEgY29uc3VtZXIgQ1BFIHJvdXRlcj8gVGhhdOKAmXMgd2h5IHdlIGFyZSBzdGFydGluZyBub3cu ICZuYnNwO0l04oCZcyBub3QgYSBzcGVjaW91cyBhcmd1bWVudCwNCiBqdXN0IHZlcnkgZm9yd2Fy ZCBsb29raW5nLjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBz cGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5BbmQgdGhlIG1lc3NhZ2Ug ZnJvbSBTaW1vbiB0aGF0IEkgd2FzIHJlZmVycmluZyB0byB3YXMgdGhlIG9uZSB0aGF0IGRpc2N1 c3NlZCB0aGUgZHJhZnQgdGhhdCB3YXMgcHJvcG9zZWQgaW4gc3Vuc2V0NCBmb3Igc29sdmluZyB0 aGlzIHByb2JsZW0gdXNpbmcgREhDUHY0LCB3aGljaCB3YXMgX25vdCBhZG9wdGVkIGJ5IHRoZSB3 b3JraW5nIGdyb3VwXy4gJm5ic3A7Jm5ic3A7RHJhZnQgYWRvcHRpb24gaXMgcGFydCBvZiB0aGUN CiB3b3JraW5nIGdyb3VwIHByb2Nlc3M7IHRoZSBmYWN0IHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAg ZGVjaWRlZCB0byBtZXJnZSB0aGUgREhDUHY0IGRyYWZ0IGludG8gdGhpcyBvbmUsIGFuZCBub3Qg dGhlIG90aGVyIHdheSBhcm91bmQsIGlzIHByZWNpc2VseSB3aGF0IGl0IG1lYW5zIGZvciBhIHdv cmtpbmcgZ3JvdXAgdG8gaGF2ZSBjb25zZW5zdXMgdG8gcHVzaCB0aGlzIHNvbHV0aW9uIGFuZCBu b3QgdGhlIG90aGVyIG9uZS48L2Jsb2NrcXVvdGU+DQpJ4oCZbSBoYXBweSBmb3IgdGhlIHdvcmtp bmcgZ3JvdXAsIGJ1dCB0aGVyZSBpcyB2ZXJ5IGxpdHRsZSBvcGVyYXRvciBwYXJ0aWNpcGF0aW9u IGluIHRoZSBzdW5zZXQ0IHdvcmtpbmcgZ3JvdXAgYXQgdGhpcyB0aW1lIGFuZCBJIHN1c3BlY3Qg dGhhdCBpcyBvbmUgb2YgdGhlIHJlYXNvbnMgc2FpZCBncm91cCBkZWNpZGVkIHRvIGFzayB2Nm9w cyB0byByZXZpZXcgdGhlIGRyYWZ0Lg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0K PGRpdj5XR10gV29ya2luZyBncm91cCBjaGFpciBoYXQgb246IEFjdHVhbGx5LCB0aGVyZeKAmXMg ZGVjZW50IG9wZXJhdG9yIHBhcnRpY2lwYXRpb24gYXMgYSBwZXJjZW50YWdlIG9mIG92ZXJhbGws IGJ1dCB1bmZvcnR1bmF0ZWx5IHRoZXJlIGlzIHZlcnkgbGl0dGxlIHBhcnRpY2lwYXRpb24gaW4g dGhlIFdHIHBlcmlvZCwgc28gd2Ugd2VyZW7igJl0IGNvbWZvcnRhYmxlIHdpdGggdGhlIGxldmVs IG9mIGZlZWRiYWNrIHRoZSBkcmFmdCBoYWQgcmVjZWl2ZWQNCiB0aHVzIGZhciBhbmQgYXNrZWQg Zm9yIGFkZGl0aW9uYWwgcmV2aWV3LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlk PSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBi cmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazog YWZ0ZXItd2hpdGUtc3BhY2U7Ij4NCjxkaXY+WW91IGFyZSBub3cgaGVhcmluZyBmcm9tIHBlb3Bs ZSB3aG8gYXJlIG5ldHdvcmsgb3BlcmF0b3JzIHRoYXQgdGhleSBmZWVsIHRoaXMgd2FzIHRoZSB3 cm9uZyBhcHByb2FjaCB0byBhZG9wdCBhbmQgdGhhdCB3ZSBkbyBub3QgY29uY3VyIHdpdGggdGhl IGNvbnNlbnN1cyBvZiB0aGUgc3Vuc2V0NCB3b3JraW5nIGdyb3VwLjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+V0ddIFllcywgYnV0IGJhc2VkIG9uIHlvdXIgcHJldmlvdXMgbWVzc2Fn ZXMsIHlvdSBzZWVtIHRvIGhhdmUgYSBmdW5kYW1lbnRhbCBpc3N1ZSB3aXRoDQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6IGJvbGQ7Ij5hbnk8L3NwYW4+Jm5ic3A7SVB2NC9EQ0hQdjQgY29uZmln dXJhdGlvbiBiZWluZyBzZW50IG92ZXIgSVB2NiwgYW5kIGFzIEkgbm90ZWQgaW4gbXkgcHJldmlv dXMgcmVzcG9uc2UgdG8geW91LCBESEMgaXMgYWxzbyBtb3ZpbmcgdG93YXJkIHRoZSBwYXRoIG9m IGRvaW5nIHRoaXMsIGp1c3Qgbm90IHdpdGggYSBraWxsIHN3aXRjaCwgYW5kIHdpdGggZGlmZmVy ZW50IHRlY2huaWNhbCBqdXN0aWZpY2F0aW9uLg0KIE5vdCBzYXlpbmcgdGhhdCBtYWtlcyBpdCBy aWdodCwgYnV0IGlmIGl04oCZcyBub3QsIHRoZXJl4oCZcyBhIG11Y2ggbGFyZ2VyIGRpc2N1c3Np b24gdG8gYmUgaGFkLCBhbmQgdGhlIGZvbGtzIGluIERIQyB0aGF0IGFyZSB3b3JraW5nIG9uIHRo b3NlIGRyYWZ0cyBwcm9iYWJseSBuZWVkIHNpbWlsYXIgZmVlZGJhY2sgaWYgdGhlcmXigJlzIHRy dWx5IGEgdGVjaG5pY2FsIHByb2JsZW0gd2l0aCBpdCBhbmQgbm90IHRoYXQgaXQgc2ltcGx5IGlz buKAmXQgYXJjaGl0ZWN0dXJhbGx5DQogcHVyZSBlbm91Z2ggZm9yIHlvdS4gSW4gb3RoZXIgd29y ZHMsIFN1bnNldDQgaXMgbW92aW5nIHRoaXMgZGlyZWN0aW9uIGJlY2F1c2UgaXQgZW5hYmxlcyB1 cyB0byBsZXZlcmFnZSB3b3JrIHRoYXQgaXMgYWxyZWFkeSBoYXBwZW5pbmcgaW4gREhDLCBhbmQg d2UgYXJlIHRyeWluZyB0byBjb29yZGluYXRlIHRob3NlIGVmZm9ydHMgd2l0aCB0aGVtLiAmbmJz cDtTbyBJ4oCZZCByZWNvbW1lbmQgZ29pbmcgdG8gcmVhZCB0aGUgZHJhZnRzIEkgcG9pbnRlZCB5 b3UNCiB0byB5ZXN0ZXJkYXksIGFuZCBkZXRlcm1pbmluZyB3aGV0aGVyIHlvdSBoYXZlIGEgcHJv YmxlbSB3aXRoIHRoZSB3aG9sZSBjb25jZXB0IG9yIGp1c3Qgc3Vuc2V0NOKAmXMgcGFydGljdWxh ciBwaWVjZSBvZiBpdCwgYW5kIHByb2NlZWRpbmcgYWNjb3JkaW5nbHkuJm5ic3A7PC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6 IDExcHQ7Ij5UaGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPldlczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MXB0OyI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7Ij48c3BhbiBzdHlsZT0i Y29sb3I6IHJnYigxMjcsIDEyNywgMTI3KTsgZm9udC1zaXplOiAxMXB0OyI+QW55dGhpbmcgYmVs b3cgdGhpcyBsaW5lIGhhcyBiZWVuIGFkZGVkIGJ5IG15IGNvbXBhbnnigJlzIG1haWwgc2VydmVy LCBJIGhhdmUgbm8gY29udHJvbCBvdmVyIGl0Ljwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7Ij48 c3BhbiBzdHlsZT0iY29sb3I6IHJnYigxMjcsIDEyNywgMTI3KTsiPi0tLS0tLS0tLS0tPC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGJyPg0KPGhyPg0KPGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJHcmF5 IiBzaXplPSIxIj5UaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29u dGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMg cHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdp bmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseQ0K IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBh ZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBF LW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRp c3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBj b250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8NCiB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBw cm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg RS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5k IHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1t YWlsIGFuZCBhbnkgcHJpbnRvdXQuPGJyPg0KPC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CF7300251845Fwesleygeorgetwcablecom_-- From nobody Tue Apr 15 13:24: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 5455D1A03C7 for ; Tue, 15 Apr 2014 13:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 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.272, 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 pqdm4xBJoRc1 for ; Tue, 15 Apr 2014 13:24:32 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id B3CE11A01FB for ; Tue, 15 Apr 2014 13:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5818; q=dns/txt; s=iport; t=1397593469; x=1398803069; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/I3y9Pb623MLN1dOoKDJ4hkJ4DY+CqFvQ5wCDCzIdlA=; b=YMqicAY1TclZcr3aSrehV+rjNumYng95YLv3qdazAvJSr+1+mAcN9aY+ O71p5TrOFO1BpqTorCtqbovSItOtEZQe2/MDmr5tUmPonvFpS3k9x3LCg tcNlCXTtWaUNmp7AqQJ2Xs9JmkLUH0oA93inbJPt2uM4CTIfoIIxsUhif c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFALOUTVOtJA2I/2dsb2JhbABaDoJ4gRKDEcAdGYEQFnSCJQEBAQQjET4HDAQCAQgRBAEBAwIGHQMCAgIwFAEICAIEAQ0FCId0qXSiaBeBKYxpAQEeMQcGgmk1gRQBA5R1ljKCcUCBcjk X-IronPort-AV: E=Sophos;i="4.97,866,1389744000"; d="scan'208";a="36075308" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-3.cisco.com with ESMTP; 15 Apr 2014 20:24:28 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3FKOS3H016596 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Apr 2014 20:24:28 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.212]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Tue, 15 Apr 2014 15:24:28 -0500 From: "Bernie Volz (volz)" To: "George, Wes" , Simon Perreault , "Dale W. Carder" Thread-Topic: [v6ops] Please review the No IPv4 draft Thread-Index: AQHPWL2c0jm4+vJrr02ADXU7FejXCZsSyt0QgACYCoD//7hxIA== Date: Tue, 15 Apr 2014 20:24:28 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AFE68BC@xmb-rcd-x04.cisco.com> References: <534BF5A5.5010609@viagenie.ca> <20140415142103.GA50776@ricotta.doit.wisc.edu> <534D4D32.7080001@viagenie.ca> <489D13FBFA9B3E41812EA89F188F018E1AFE5ACB@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.70.121] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Pb5HbBANfjWEt8TZJWCsRc-yBZ0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 20:24:36 -0000 SSBkb24ndCBoYXZlIGdvb2QgYW5zd2VycyBmb3IgeW91IG9uIHRoZSBwcmV2aW91cyB0cmFuc2l0 aW9ucyAtIHBlcmhhcHMgb3RoZXJzIGRvLg0KDQo+U2luY2Ugd2XigJl2ZSBicm91Z2h0IHVwIHJl ZHVjaW5nIGp1bmsgY2xpZW50LXNvdXJjZWQgdHJhZmZpYyBvbiB3aXJlbGVzcw0KPiBuZXR3b3Jr cyBhcyBvbmUgb2YgdGhlIGdvYWxzIG9mIGJlaW5nIGFibGUgdG8gdGVsbCBjbGllbnRzIHRvIHN0 b3Agc3BlYWtpbmcNCj4gREhDUHY0LCBvciBJUHY0L2FycCBpbiBnZW5lcmFsLCBob3cgbWFueSB3 aXJlbGVzcyBJUFggYW5kIEFwcGxldGFsayANCj4gbmV0d29ya3Mgd2VyZSB0aGVyZT8gKGFuZCB5 ZXMgdGhhdCBsYXN0IHF1ZXN0aW9uIGlzIG1vc3RseSB0b25ndWUtaW4tY2hlZWspDQoNCklmIGl0 IGlzIHdpcmVsZXNzIHRoYXQgaXMgYSBzaWduaWZpY2FudCBjb25jZXJuLCB3b3VsZG4ndCBpdCBi ZSBiZXR0ZXIgdG8gaGF2ZSB0aGUgd2lyZWxlc3MgbGF5ZXIgY29tbXVuaWNhdGUgd2hhdCBuZXR3 b3JraW5nIHByb3RvY29scyBzaG91bGQgW25vdF0gYmUgcnVuICh0aGF0J3MgYSBkaWZmZXJlbnQg c3RhbmRhcmRzIG9yZ2FuaXphdGlvbiB0aG91Z2gpPw0KDQpCVFc6IEluIGluIHRoZSBvbGQgZGF5 cywgIndpcmVkIiBicm9hZGNhc3QgZG9tYWlucyB3ZXJlIGxhcmdlIGJlY2F1c2Ugc3dpdGNoZXMg d2VyZW4ndCB1c2VkIGV2ZXJ5d2hlcmUgLSB0aG91Z2ggdGhleSB3ZXJlbid0IGFzIGxhcmdlIGFz IHNvbWUgb2YgdGhlIHdpcmVsZXNzIG9uZXMgYXJlIHRvZGF5Lg0KDQpTaW1pbGFyIHRvIHRoZSB3 b3JrIGRvbmUgb24gUkZDIDcwODMgZm9yIHJlZHVjaW5nIHRoZSByYXRlIGF0IHdoaWNoIERIQ1B2 NiBjbGllbnRzIHNlbmQgU29saWNpdHMsIHBlcmhhcHMgd2Ugc2hvdWxkIGxvb2sgYXQgYWx0ZXJp bmcgdGhlIERIQ1B2NCBESENQRElTQ09WRVIgcmF0ZXM/IFJGQyAyMTMxIGhhcyAiVGhlIHJldHJh bnNtaXNzaW9uIGRlbGF5IFNIT1VMRCBiZSBkb3VibGVkIHdpdGggc3Vic2VxdWVudCByZXRyYW5z bWlzc2lvbnMgdXAgdG8gYSBtYXhpbXVtIG9mIDY0IHNlY29uZHMuIiBSRkMgNzA4MyBjaGFuZ2Vk IERIQ1B2NidzIHZhbHVlIGZyb20gMTIwIHRvIDM2MDAgc2Vjb25kcy4gQnV0IHRoaXMgb25seSBo ZWxwcyB0aGUgREhDUHY0IERIQ1BESVNDT1ZFUiBpc3N1ZSAobm90IHRoZSByZXN0IG9mIHRoZSBJ UHY0IGlzc3Vlcywgc3VjaCBhcyB1c2luZyBhIGxpbmsgbG9jYWwgYWRkcmVzcykuIEJ1dCBJIHN1 c3BlY3QgdGhhdCB0aGlzIHdvdWxkIGdvIGEgbG9uZyB3YXkgdG8gcmVkdWNlIHRoZSBpc3N1ZXMg d2l0aCBXaXJlbGVzcy4NCg0KLSBCZXJuaWUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IEdlb3JnZSwgV2VzIFttYWlsdG86d2VzbGV5Lmdlb3JnZUB0d2NhYmxlLmNvbV0gDQpT ZW50OiBUdWVzZGF5LCBBcHJpbCAxNSwgMjAxNCAzOjI0IFBNDQpUbzogQmVybmllIFZvbHogKHZv bHopOyBTaW1vbiBQZXJyZWF1bHQ7IERhbGUgVy4gQ2FyZGVyDQpDYzogdjZvcHNAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbdjZvcHNdIFBsZWFzZSByZXZpZXcgdGhlIE5vIElQdjQgZHJhZnQNCg0K T24gNC8xNS8xNCwgMTE6MjAgQU0sICJCZXJuaWUgVm9seiAodm9seikiIDx2b2x6QGNpc2NvLmNv bT4gd3JvdGU6DQoNCg0KPlllYWgsIGJ1dCB3ZSBzdXJ2aXZlZCB0aGUgdHJhbnNpdGlvbiBhd2F5 IGZyb20gdGhlc2Ugb2xkZXIgbmV0d29ya3MgDQo+d2l0aG91dCBzaWduaWZpY2FudCBpc3N1ZXMg YW5kIHNwZWNpYWwgbWVzc2FnZXMgb24gSVB2NCB0byB0ZWxsIGNsaWVudHMgDQo+ImRvbid0IHRy eSBJUFggb3IgQXBwbGVUYWxrIG9yIC4uLiIuDQo+DQo+LSBCZXJuaWUNCg0KT2suIFlvdW5naW7i gJkgKGFuZCBjb2NoYWlyIG9mIFN1bnNldDQpIHNwZWFraW5nLiBNeSBleHBlcmllbmNlIHdpdGgg bmV0d29ya2luZyBiZWdpbnMgYWZ0ZXIgdGhlc2UgdHJhbnNpdGlvbnMgd2VyZSBsYXJnZWx5IGNv bXBsZXRlLCBzbyBJIGdlbnVpbmVseSBkb27igJl0IGhhdmUgYSBnb29kIHNlbnNlIGZvciB3aGF0 IHdhcyBkb25lIHRvIOKAnHN1cnZpdmUiIHRoaXMgdHJhbnNpdGlvbiwgYW5kIEnigJlkIGJldCBT aW1vbiBkb2VzbuKAmXQgZWl0aGVyLiBJZiB0aGF04oCZcyByZWFsbHkgdGhlIHJpZ2h0IG1vZGVs LCBwbGVhc2UgZXhwbGFpbiB3aGF0IHRoYXQgYWN0dWFsbHkgbWVhbnMsIHNpbmNlIGluIFN1bnNl dDQgd2XigJlyZSBzdXBwb3NlZCB0byBiZSBmaWd1cmluZyBvdXQgd2hhdCB0aGlzIHRyYW5zaXRp b24gbG9va3MgbGlrZSwgaG93IHRvIHR1cm4gb2ZmIElQdjQsIGV0Yy4gSWYgaXTigJlzIHJlYWxs eSBiZWVuIGRvbmUsIEkgZG9u4oCZdCB3YW50IHRvIHJlaW52ZW50IHRoZSB3aGVlbCwgYnV0IEkg bmVlZCBtb3JlIHRvIGdvIG9uIHRoYW4gdGhlIGhhbmR3YXZpbmcgdGhhdCBoYXMgc28gZmFyIGFj Y29tcGFuaWVkIHRoaXMgYXNzZXJ0aW9uLiBBbnN3ZXIgc3BlY2lmaWNhbGx5IGlmIHlvdSBhcmUg dGhpbmtpbmcgb2YgYSBzcGVjaWZpYyBuZXR3b3JrLCBvciBnZW5lcmljYWxseSBpZiB0aGF04oCZ cyBtb3JlIGFwcHJvcHJpYXRlLg0KDQpEaWQgdGhleSBkaWUgb2YgbmF0dXJhbCBjYXVzZXMgSS5l LiBtb3N0IGNsaWVudHMgc2ltcGx5IHN0b3BwZWQgaGF2aW5nIHRoZW0gZW5hYmxlZCBieSBkZWZh dWx0PyBJZiB5ZXMsIG92ZXIgd2hhdCB0aW1lZnJhbWU/DQpXZXJlIHNvbWUgbmV0d29ya3MgZm9y Y2luZyB0aG9zZSBwcm90b2NvbHMgdG8gYmUgZGlzYWJsZWQgdmlhIGdvaW5nIHRvIGVhY2ggaG9z dCBhbmQgbWFudWFsbHkgY29uZmlndXJpbmc/IE9yIHdhcyB0aGUgYmFja2dyb3VuZCB0cmFmZmlj IHNvIG5lZ2xpZ2libGUgdGhhdCBpdCB3YXMgc2ltcGx5IGlnbm9yZWQ/DQpXaGF0IHdhcyB0aGUg b3JkZXIgb2YgbWFnbml0dWRlIG9mIHNpemUgb2YgdGhlIGJyb2FkY2FzdCBkb21haW4/IE51bWJl ciBvZiBob3N0cyB0aGF0IG1pZ2h0IGhhdmUgdG8gYmUgdG91Y2hlZCBvbiBhbiBhdmVyYWdlIG5l dHdvcms/IEhvdyBtYW55IGhvc3RzIHdlcmUgZHluYW1pY2FsbHkgY29uZmlndXJlZCB2cyBzdGF0 aWM/IERIQ1Agd2FzIHByZXR0eSBuZXcgdGhlbiwgd2FzbuKAmXQgaXQ/DQpTaW5jZSB3ZeKAmXZl IGJyb3VnaHQgdXAgcmVkdWNpbmcganVuayBjbGllbnQtc291cmNlZCB0cmFmZmljIG9uIHdpcmVs ZXNzIG5ldHdvcmtzIGFzIG9uZSBvZiB0aGUgZ29hbHMgb2YgYmVpbmcgYWJsZSB0byB0ZWxsIGNs aWVudHMgdG8gc3RvcCBzcGVha2luZyBESENQdjQsIG9yIElQdjQvYXJwIGluIGdlbmVyYWwsIGhv dyBtYW55IHdpcmVsZXNzIElQWCBhbmQgQXBwbGV0YWxrIG5ldHdvcmtzIHdlcmUgdGhlcmU/IChh bmQgeWVzIHRoYXQgbGFzdCBxdWVzdGlvbiBpcyBtb3N0bHkNCnRvbmd1ZS1pbi1jaGVlaykNCg0K VGhhbmtzLA0KDQpXZXMNCg0KDQpBbnl0aGluZyBiZWxvdyB0aGlzIGxpbmUgaGFzIGJlZW4gYWRk ZWQgYnkgbXkgY29tcGFueeKAmXMgbWFpbCBzZXJ2ZXIsIEkgaGF2ZSBubyBjb250cm9sIG92ZXIg aXQuDQotLS0tLS0tLS0tLQ0KDQoNCg0KVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRp b24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5 cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRl bmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdo aWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2Vt aW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRp b24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBz dHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9m IHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo= From nobody Tue Apr 15 13:39: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 8061F1A0781 for ; Tue, 15 Apr 2014 13:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.437 X-Spam-Level: * X-Spam-Status: No, score=1.437 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.272, 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 VQRaFhdiWB3h for ; Tue, 15 Apr 2014 13:39:02 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id A331C1A0786 for ; Tue, 15 Apr 2014 13:39:00 -0700 (PDT) Received: from owens-mbp.meeting.arin.net (unknown.ipv6.scnet.net [IPv6:2001:1838:1003:0:c419:9f0a:8d6:6970] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s3FKZi6K023844 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Apr 2014 13:35:45 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3FKZi6K023844 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1397594147; bh=bAoUNw2gQzziisowhGxCFxNkKxs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=KHNoXvbbqfzv8l/CsGmppFZrtrt9ZAUiUGqxlfW5fkmi5/ysp2aUeQ02FrOZBTxuf GqCWDsQ4Vb2wFc4ooTXOWT5i6/a4jO8V33i0b68WwEDCdj759T5L0CLGh4AGcfv7uA zrOwhckYwl50y/cFpuCgm5PWF8qgahJRgLZ10kSs= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: Date: Tue, 15 Apr 2014 13:35:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <49C1D0B8-4B70-4FBC-B635-0B65D11C8AA4@delong.com> References: <534BF5A5.5010609@viagenie.ca> <20140415142103.GA50776@ricotta.doit.wisc.edu> <534D4D32.7080001@viagenie.ca> <489D13FBFA9B3E41812EA89F188F018E1AFE5ACB@xmb-rcd-x04.cisco.com> To: "George, Wes" X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 15 Apr 2014 13:35:47 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/i1kHXO1Bav28cxk_KDeF4Bdmh9s Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 20:39:06 -0000 On Apr 15, 2014, at 12:24 PM, George, Wes = wrote: > On 4/15/14, 11:20 AM, "Bernie Volz (volz)" wrote: >=20 >=20 >> Yeah, but we survived the transition away from these older networks >> without significant issues and special messages on IPv4 to tell = clients >> "don't try IPX or AppleTalk or ...". >>=20 >> - Bernie >=20 > Ok. Youngin=92 (and cochair of Sunset4) speaking. My experience with > networking begins after these transitions were largely complete, so I > genuinely don=92t have a good sense for what was done to =93survive" = this > transition, and I=92d bet Simon doesn=92t either. If that=92s really = the right Well, I was around for these transitions, so let me shed some limited = light=85 > model, please explain what that actually means, since in Sunset4 we=92re= > supposed to be figuring out what this transition looks like, how to = turn > off IPv4, etc. If it=92s really been done, I don=92t want to reinvent = the > wheel, but I need more to go on than the handwaving that has so far > accompanied this assertion. Answer specifically if you are thinking of = a > specific network, or generically if that=92s more appropriate. I had experience with sunsetting appletalk, IPX, netBEUI, DECNET, and = ARCNET. While I didn=92t have direct experience sunsetting Vines or other XNS = variants, I think that=92s enough of a sampling to speak relatively = generically. > Did they die of natural causes I.e. most clients simply stopped having > them enabled by default? If yes, over what timeframe? Yes, they died of natural causes over the course of about 2-5 years and = in some cases, as much as 10-15 years, depending on the organization. However, =93clients stopped having them enabled by default=94 doesn=92t = really apply because to my knowledge, other than Appletalk, IPv4 is the = first protocol to have really been =93enabled by default=94. In the = other cases, you generally had to take substantial effort to install = each and every protocol you wanted to run on any given host. Every thing = was much harder than what we take for granted now. Even in the case of appletalk, mostly what happened is Apple moved to = TCP/IP with OS X and as a result Appletalk simply evaporated. Further, none of the things that are being considered a problem in this = draft were considered problematic in those days. Low power applications = simply didn=92t exist. If it had a NIC back then, it probably involved a = relatively thick piece of Co-Ax (or at least a thin one). In the (very = rare) case there was a wireless network, it involved a PCMCIA card that = was larger than many modern cellphones. Mobile connectivity was a pipe = dream. > Were some networks forcing those protocols to be disabled via going to > each host and manually configuring? Or was the background traffic so > negligible that it was simply ignored? Some of the former, mostly the latter.=20 > What was the order of magnitude of size of the broadcast domain? = Number of > hosts that might have to be touched on an average network? How many = hosts > were dynamically configured vs static? DHCP was pretty new then, = wasn=92t it? DHCP might even have been nonexistent on most networks when much of this = occurred. > Since we=92ve brought up reducing junk client-sourced traffic on = wireless > networks as one of the goals of being able to tell clients to stop > speaking DHCPv4, or IPv4/arp in general, how many wireless IPX and > Appletalk networks were there? (and yes that last question is mostly > tongue-in-cheek) Very nearly zero. Owen From nobody Tue Apr 15 13:58: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 C4E811A06F6 for ; Tue, 15 Apr 2014 13:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.262 X-Spam-Level: X-Spam-Status: No, score=-1.262 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.272, 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 sBwi4DWzElbs for ; Tue, 15 Apr 2014 13:58:22 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id B47EE1A06E7 for ; Tue, 15 Apr 2014 13:58:22 -0700 (PDT) Received: from owens-mbp.meeting.arin.net (unknown.servercentral.net [50.31.214.180] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s3FKrhi0026267 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Apr 2014 13:53:45 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3FKrhi0026267 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1397595226; bh=DFQdfyJSPouIVKl4lYXYNd/hm6Y=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=G+C9Ssy9KOpZKneKpFaeJWae6GLblKxhbns/yJRKYlVXRz9t31CMyfSPfGyLGfpu3 yKUQksucoBRBXOJcK+HHCdi3R/r04YsVWdKzd6XS2dPNVBoaTb39WTJYWPxD2kDp0l s0za3XA+/tn5EeZHh3w6KkdxOItEP4WhosZuQvZA= Content-Type: multipart/alternative; boundary="Apple-Mail=_9BCB2E59-045C-4BEF-B91C-BE713EEC500B" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: Date: Tue, 15 Apr 2014 13:53:40 -0700 Message-Id: References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> <534C4DF7.4070407@foobar.org> <40E2438A-C43F-4E41-8778-511E53EF7009@nominum.com> <534D1966.5090301@foobar.org> <6D57B3D8-DAF4-4792-BDF5-B0489A283F6B@nominum.com> <0FD7945D-10DF-460C-9773-9C1C90C8CEFB@delong.com> To: "George, Wes" X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 15 Apr 2014 13:53:46 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/cD2ATGV6Zl-KaP4N2K3kpywziCc Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 20:58:27 -0000 --Apple-Mail=_9BCB2E59-045C-4BEF-B91C-BE713EEC500B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 15, 2014, at 1:02 PM, George, Wes = wrote: >=20 >=20 > From: Owen DeLong > Date: Tuesday, April 15, 2014 at 12:46 PM > To: Ted Lemon > Cc: "v6ops@ietf.org" > Subject: Re: [v6ops] Please review the No IPv4 draft >=20 >=20 > In reality, there=92s not going to be any such thing as a v6-only CPE = router implementation for many years to come, so this argument is rather = specious to begin with. However, in that distant future, the above could = be supported with a pretty small code-base. >=20 > WG] yeah=85 have you seen how long it takes IETF work to progress from = draft to actual deployed implementation? Especially if you=92re = factoring in the average half-life of a consumer CPE router? That=92s = why we are starting now. It=92s not a specious argument, just very = forward looking. >=20 >> And the message from Simon that I was referring to was the one that = discussed the draft that was proposed in sunset4 for solving this = problem using DHCPv4, which was _not adopted by the working group_. = Draft adoption is part of the working group process; the fact that the = working group decided to merge the DHCPv4 draft into this one, and not = the other way around, is precisely what it means for a working group to = have consensus to push this solution and not the other one. > I=92m happy for the working group, but there is very little operator = participation in the sunset4 working group at this time and I suspect = that is one of the reasons said group decided to ask v6ops to review the = draft. > WG] Working group chair hat on: Actually, there=92s decent operator = participation as a percentage of overall, but unfortunately there is = very little participation in the WG period, so we weren=92t comfortable = with the level of feedback the draft had received thus far and asked for = additional review. >=20 > You are now hearing from people who are network operators that they = feel this was the wrong approach to adopt and that we do not concur with = the consensus of the sunset4 working group. >=20 > WG] Yes, but based on your previous messages, you seem to have a = fundamental issue with any IPv4/DCHPv4 configuration being sent over = IPv6, and as I noted in my previous response to you, DHC is also moving = toward the path of doing this, just not with a kill switch, and with = different technical justification. Not saying that makes it right, but = if it=92s not, there=92s a much larger discussion to be had, and the = folks in DHC that are working on those drafts probably need similar = feedback if there=92s truly a technical problem with it and not that it = simply isn=92t architecturally pure enough for you. In other words, = Sunset4 is moving this direction because it enables us to leverage work = that is already happening in DHC, and we are trying to coordinate those = efforts with them. So I=92d recommend going to read the drafts I = pointed you to yesterday, and determining whether you have a problem = with the whole concept or just sunset4=92s particular piece of it, and = proceeding accordingly.=20 Conceptually, I think it is generally ill-advised, just as I wouldn=92t = advocate putting IPv6 name server options in DHCPv4 (though there are = others who would support doing so). I agree that the DHC working group may well need more feedback than they = are getting. Unfortunately, I don=92t have the bandwidth to keep up with = DHC, sunset4, etc. and I do my best to keep up with v6ops as that is the = one that seems most relevant to my immediate circumstances. This draft happened to hit v6ops, so I commented on it as requested. In an ideal world, I=92d be able to do just as you suggest and push on = all the right places. In the real world, I=92ve probably already spent = more time on this issue than I really should. Owen --Apple-Mail=_9BCB2E59-045C-4BEF-B91C-BE713EEC500B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
    On Apr 15, 2014, at 1:02 PM, George, = Wes <wesley.george@twcable.com>= ; wrote:



    From: Owen DeLong <owen@delong.com>
    Date: Tuesday, April 15, 2014 at = 12:46 PM
    To: Ted Lemon <ted.lemon@nominum.com>
    Cc: "v6ops@ietf.org" <v6ops@ietf.org>
    Subject: Re: [v6ops] Please = review the No IPv4 draft


    In reality, there=92s not going to be any such thing as a v6-only = CPE router implementation for many years to come, so this argument is = rather specious to begin with. However, in that distant future, the = above could be supported with a pretty small code-base.

    WG] yeah=85 have you seen how long it takes IETF work to progress = from draft to actual deployed implementation? Especially if you=92re = factoring in the average half-life of a consumer CPE router? That=92s = why we are starting now.  It=92s not a specious argument, just very forward looking.

    And the message from Simon that I was = referring to was the one that discussed the draft that was proposed in = sunset4 for solving this problem using DHCPv4, which was _not adopted by = the working group_.   Draft adoption is part of the working group process; the fact that the working group decided to merge = the DHCPv4 draft into this one, and not the other way around, is = precisely what it means for a working group to have consensus to push = this solution and not the other one.
    I=92m happy for the working group, but there is very little operator = participation in the sunset4 working group at this time and I suspect = that is one of the reasons said group decided to ask v6ops to review the = draft.
    WG] Working group chair hat on: Actually, there=92s decent operator = participation as a percentage of overall, but unfortunately there is = very little participation in the WG period, so we weren=92t comfortable = with the level of feedback the draft had received thus far and asked for additional review.

    You are now hearing from people who are network operators that they = feel this was the wrong approach to adopt and that we do not concur with = the consensus of the sunset4 working group.

    WG] Yes, but based on your previous messages, you seem to have a = fundamental issue with any IPv4/DCHPv4 = configuration being sent over IPv6, and as I noted in my previous = response to you, DHC is also moving toward the path of doing this, just = not with a kill switch, and with different technical justification. Not saying that makes it right, but if it=92s not, there=92s a much = larger discussion to be had, and the folks in DHC that are working on = those drafts probably need similar feedback if there=92s truly a = technical problem with it and not that it simply isn=92t architecturally pure enough for you. In other words, Sunset4 is moving this direction = because it enables us to leverage work that is already happening in DHC, = and we are trying to coordinate those efforts with them.  So I=92d = recommend going to read the drafts I pointed you to yesterday, and determining whether you have a problem with the whole = concept or just sunset4=92s particular piece of it, and proceeding = accordingly. 

    Conceptually, I think it is generally ill-advised, just as I wouldn=92t= advocate putting IPv6 name server options in DHCPv4 (though there are = others who would support doing so).

    I agree = that the DHC working group may well need more feedback than they are = getting. Unfortunately, I don=92t have the bandwidth to keep up with = DHC, sunset4, etc. and I do my best to keep up with v6ops as that is the = one that seems most relevant to my immediate = circumstances.

    This draft happened to hit = v6ops, so I commented on it as requested.

    In an = ideal world, I=92d be able to do just as you suggest and push on all the = right places. In the real world, I=92ve probably already spent more time = on this issue than I really = should.

    Owen

    = --Apple-Mail=_9BCB2E59-045C-4BEF-B91C-BE713EEC500B-- From nobody Tue Apr 15 14:47: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 D54121A0235 for ; Tue, 15 Apr 2014 14:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.527 X-Spam-Level: X-Spam-Status: No, score=0.527 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272, 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 eu7REKrwb8Ys for ; Tue, 15 Apr 2014 14:47:53 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id CB3E01A0210 for ; Tue, 15 Apr 2014 14:47:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 46BF6870074; Tue, 15 Apr 2014 23:47:49 +0200 (CEST) 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 yag5qsn+qliq; Tue, 15 Apr 2014 23:47:49 +0200 (CEST) Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 12B50870073; Tue, 15 Apr 2014 23:47:49 +0200 (CEST) Message-ID: <534DA903.6090203@globis.net> Date: Tue, 15 Apr 2014 23:47:47 +0200 From: Ray Hunter User-Agent: Postbox 3.0.9 (Macintosh/20140129) MIME-Version: 1.0 To: "George, Wes" References: <534BF5A5.5010609@viagenie.ca> <20140415142103.GA50776@ricotta.doit.wisc.edu> <534D4D32.7080001@viagenie.ca> <489D13FBFA9B3E41812EA89F188F018E1AFE5ACB@xmb-rcd-x04.cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/x3daMtNbR8PAZQ_dfa0PFVRTpTg Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 21:47:55 -0000 George, Wes wrote: > Ok. Youngin’ (and cochair of Sunset4) speaking. My experience with > networking begins after these transitions were largely complete, so I > genuinely don’t have a good sense for what was done to “survive" this > transition, and I’d bet Simon doesn’t either. If that’s really the right > model, please explain what that actually means, since in Sunset4 we’re > supposed to be figuring out what this transition looks like, how to turn > off IPv4, etc. If it’s really been done, I don’t want to reinvent the > wheel, but I need more to go on than the handwaving that has so far > accompanied this assertion. Answer specifically if you are thinking of a > specific network, or generically if that’s more appropriate. I've personally been around for the sunset of Appletalk, IPX, LAT, DECnet IV, SNA, SNA tunneling, X25, WAN bridging, NetBIOS, Apollo/Domain in various organisations. > > Did they die of natural causes I.e. most clients simply stopped having > them enabled by default? Clients stopped enabling them. In many cases it was a commercial decision to remove support for the relevant code/ drivers. Mostly it was natural end of life renewal. > If yes, over what timeframe? Some were very quick: wiped out within 6 months. Some took a very long time to die. Some became islands connected via tunnels. Some became islands without external connectivity. I suspect IPv4 will be around for at least 20 years (e.g. factory automation). As soon as people started having to pay extra to maintain this service i.e. providing the old protocol demanded a premium, the death accelerated very quickly. I think sunset IPv4 has to be very clear what problem it is trying to tackle. Thinking that IPv4 can be turned off per ISP or per site in one big switch off is not going to fly IMHO. > Were some networks forcing those protocols to be disabled via going to > each host and manually configuring? Removing the network statements on the router was generally the way it was triggered. The equivalent would be disabling the DHCPv4 server, or serving up junk IPv4 network addresses +ACL. But on some systems there was significant manual intervention per host required e.g. changing batch files to prevent loading a specific driver, reconfiguring or even recompiling the OS, or removing a specialised card like a broadband-LAN adapter. > Or was the background traffic so > negligible that it was simply ignored? Certainly not. Processors were much slower then. L2 Broadcasts could have significant impact on machine productivity e.g. mixing Novell Netware clients on a LAN carrying LAT/MOP which was broadcast heavy could impact those users. Remember there weren't any switches on 10Base5 or cable LAN systems (Sytek et al). A site was generally one big flat L2 LAN. From fading memory I remember 20Kbps of broadcasts (50 pps) on a 10Mb LAN was pretty significant. So we'd make a legacy LAN to connect up the poorly behaving systems (or more likely create a new LAN to accommodate the new well-behaved systems, and leave the old ones to die a natural death). A modern equivalent would be to create a new VLAN or separate SSID for IPv6 only hosts. > What was the order of magnitude of size of the broadcast domain? 1000 hosts or more (WAN bridging) > Number of > hosts that might have to be touched on an average network? 1000-100000? > How many hosts > were dynamically configured vs static? Mostly statically configured for DECnet, but dynamic for LAT, IPX, Appletalk. Centrally configured for SNA. > DHCP was pretty new then, wasn’t it? I don't see how this is relevant. There are still many systems running with statically assigned IPv4 addresses. > Since we’ve brought up reducing junk client-sourced traffic on wireless > networks as one of the goals of being able to tell clients to stop > speaking DHCPv4, or IPv4/arp in general, how many wireless IPX and > Appletalk networks were there? (and yes that last question is mostly > tongue-in-cheek) None. But there weren't many routers either (just the odd DEMSA, Proteon and those new fangled Cisco AGS thingies). So excessive broadcasts were an issue back then too. Just try opening the finder on an original Macintosh when you had 100+ Appletalk zones and network IDs and watch your 64K WAN links fill up. I personally get the feeling that this issue of background noise is being overblown. I haven't seen any evidence yet of why it isn't possible just to create a new VLAN/SSID/light up a new DWDM color/new bearer for the IPv6 only systems that are supposedly sensitive to broadcasts. Router ports cost way less than 1/100th of what they used to cost. And it's not like anyone is going to renumber their IPv4 subnets to create the super large prefixes that native IPv6 can theoretically support. So what's the real problem here? And why can't this be solved with existing techniques? > Thanks, > > Wes -- Regards, RayH From nobody Tue Apr 15 15:17: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 2E6B31A06ED for ; Tue, 15 Apr 2014 15:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 Rss1tFHcVNUh for ; Tue, 15 Apr 2014 15:16:57 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 6E30A1A04A1 for ; Tue, 15 Apr 2014 15:16:56 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s3FMGqEd093021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 15 Apr 2014 23:16:52 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <534DAFD4.6000207@foobar.org> Date: Tue, 15 Apr 2014 23:16:52 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ted Lemon References: <534BF5A5.5010609@viagenie.ca> <534D319C.3030800@viagenie.ca> <534D4E85.5040104@foobar.org> <534D5452.4080300@viagenie.ca> <534D6957.5000900@foobar.org> <6773DA12-104D-4E28-BEE5-807834EF8F2D@nominum.com> In-Reply-To: <6773DA12-104D-4E28-BEE5-807834EF8F2D@nominum.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/FlNqd1fmsd9_U9nDWcvP-2QFNAo Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 15 Apr 2014 22:17:04 -0000 On 15/04/2014 18:47, Ted Lemon wrote: > On Apr 15, 2014, at 12:16 PM, Nick Hilliard wrote: >> I think you need to go back to the drawing board on this draft. As >> I said before, stopping v4 DHCPREQUEST packets is a good idea and it would >> be feasible to design a mechanism to implement it. Beyond that, you're on >> shaky ground. > > Nick, if you want something like what you just said to actually be the > outcome of the process, you need to give a clear technical objection > that motivates that outcome. I've written 10 emails on the topic in the last 24h, which is at least 9 too many, and probably 10. These contain details on a wide variety of issues, but they can be broadly summarised as: helicopter view of draft issues: the draft is poorly structured; the problem statement does not match the solution which is presented; the justification for the overall aims of the draft is weak; the consequences of the draft as defined in S5.3.1 through S5.3.3 are ill thought out and have far-reaching consequences which look extremely difficult to implement as well as being contentious from an operational point of view; there is no proposed "v4-level" option which matches the problem statement; the draft proposes that a remote signalling mechanism should be allowed to completely shut down ipv4 services right across an entire client machine - an issue which is well beyond the remit of the ietf standards process; there is no security analysis of anything. technical implementation issues: the justification for the proposed technical solution (as distinct from the overall aims) is almost non-existent; the proposal suggests a back-door mechanism to implement a protocol shutdown when a front-door mechanism would be technically much simpler to implement; the draft does not provide any protocol to implement this inter-process communication mechanism while all parties agree that there is a serious back-end problem here; the draft does not detail how or why it is appropriate for a kernel level protocol (RA) to signal a widescale kernel/userland behavioural change for an O/S; any real-world implementation of this draft will require changes to both dhcpv6 and RA rather than a single protocol, which will result in serious implementation problems; there has been no discussion alternative approaches to handle the problem (e.g. mac layer filters); there is no option for a timeout in the protocol proposal; the proposal as it stands will open implementers up to a wide variety of race conditions and inconsistent states; the implementation will cause the interpretation of RA and its interaction with DHCPv6 to become further complicated (sufficient ill-defined / complicated at the moment that it needs an entire rfc to describe it). There's discussion of most of these points on the v6ops mailing list. If there are any you want clarification on, please let me know and I'll do my best to elaborate. Overall, I view the proposal as being a bizarre approach to handling far too large a problem space. However, small bits of it may worth salvaging and re-working from the ground up, hence the suggestion for the authors to go back to the drawing board and re-think the problem set and potential solution space from scratch. As it stands, I do not believe that further work on this draft would be productive. Nick From nobody Tue Apr 15 21:18: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 4F90F1A0022 for ; Tue, 15 Apr 2014 21:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 SNN9ejpp5VgE for ; Tue, 15 Apr 2014 21:18:43 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 2F45D1A0012 for ; Tue, 15 Apr 2014 21:18:43 -0700 (PDT) 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 14D1C1B8050 for ; Tue, 15 Apr 2014 21:18:40 -0700 (PDT) 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 E8FAC19005C; Tue, 15 Apr 2014 21:18:39 -0700 (PDT) Received: from [192.168.146.119] (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, 15 Apr 2014 21:18:39 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AFE68BC@xmb-rcd-x04.cisco.com> Date: Tue, 15 Apr 2014 23:18:37 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <534BF5A5.5010609@viagenie.ca> <20140415142103.GA50776@ricotta.doit.wisc.edu> <534D4D32.7080001@viagenie.ca> <489D13FBFA9B3E41812EA89F188F018E1AFE5ACB@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AFE68BC@xmb-rcd-x04.cisco.com> To: Bernie Volz X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/HzHogntJJUkZ-BYk15IGRPbo4dg Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 04:18:47 -0000 On Apr 15, 2014, at 3:24 PM, Bernie Volz (volz) wrote: > I don't have good answers for you on the previous transitions - = perhaps others do. Apple stopped shipping Appletalk, and Apple has a pretty good upgrade = rate. And it had been off by default for a while. And it was never = widespread outside of the Apple ecosystem. I really think comparing = IPv4 to Appletalk is apples and oranges. IPX was also Windows-only, and was pretty much dead when Windows 95 = shipped because at that point its only use was for file sharing and = other services on the LAN. It had never had much use outside of that = space. IPv4 is general-purpose, not application-specific. I think we can = expect to see it shipping enabled for quite some time yet. Whether = there's any utility in having a way to shut it off, I don't know. One = way to find out is to release a specification for how to do it and see = if anybody implements it. From nobody Wed Apr 16 01:23: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 2ACEE1A0027 for ; Wed, 16 Apr 2014 01:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 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.272, 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 c-qxBF4Q1XIf for ; Wed, 16 Apr 2014 01:23:20 -0700 (PDT) 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 616081A0087 for ; Wed, 16 Apr 2014 01:23:20 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id lx4so10202350iec.38 for ; Wed, 16 Apr 2014 01:23:17 -0700 (PDT) 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=vAXdlvcfxZkL+XTKnLOEF/cHEJSOpAPnVcCFyweyU9Q=; b=Kp1y7YFbXWOllK5M5bgHkpyPq8QCB//8VAz0+9mDwX22nSQlX4kfkI5EgNPRJ9SxNX ats+DouM+n38dBlaHt7+U7+3qbq9bqxZN+BgVJ6YjG45gtam40IbGc1gA0zJh95EKu+0 u+sbCuO8z/q987EE8lM0lqj0WeO0J+KJXtMn8SAwr5fdndcp8psTJqOyU4HvxwbSzxBz 7TQBxtbSbfQKrHUq37DzbY1BFTqebBMKSBz6RyJ8wsKgpUeNvGNVgEvxofM2dLEaWsGw qK7CouFymKhpNpzvJd5KLO897M77rYd3tKqQA1ZojA/iSvKHcrYI/JzG+azHFmh4vVQv mi0Q== 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=vAXdlvcfxZkL+XTKnLOEF/cHEJSOpAPnVcCFyweyU9Q=; b=l90JGFkvSfYMf2Wf9yv4dkIeEL6tI4YNOY/z4yt0KHGnwZ2AGtPrGgNI+UwekdNXCh 8Wu8bSwXxRgm1apdMdDnTKmlT0EdbI4AdSfiPUTW9v8viU0rK5wQ0U1bGx3fNvD7dObZ ZHyib8lqjLIwx/85yahi9gD7I/MxSwW3MBHJG9bK/yTpaSd+76qTMK5UHkD89wvapeHl K4AQ2ClTNRfKL4f8aXCx7anan7SSL9aa2LY10ghw+JXSAlIDdzhta0lwv+ufwTR/K3YD ax4BCC0Rr12TDyfRewVVupxcndX8OOcP+8RhETloKM+GP40aHgiinqba9XDC5wBq6zc5 sCFA== X-Gm-Message-State: ALoCoQkBCXmoys0z++lsQVc3KwGNcu4b6J1AQhGM+1Fg85ShPeawPAoSJS4xPCEqs0GYLN7CDJfsom4Gn+fPwroA5d6dkx7f9raGr5I+N18ZuRJCcDBupUAoy0uH4dXizC2/R4FARZnfqC450TnjIMaXocCdJiM/ZUG48U8k8jHR2jURqMWHzr/spGrd9sJe6mPFPcoOR+2r X-Received: by 10.42.226.8 with SMTP id iu8mr2827695icb.7.1397636596820; Wed, 16 Apr 2014 01:23:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.136 with HTTP; Wed, 16 Apr 2014 01:22:55 -0700 (PDT) In-Reply-To: <145CDCFA-8442-4949-8025-0D6CAE5027C2@delong.com> References: <534BF5A5.5010609@viagenie.ca> <145CDCFA-8442-4949-8025-0D6CAE5027C2@delong.com> From: Lorenzo Colitti Date: Wed, 16 Apr 2014 17:22:55 +0900 Message-ID: To: Owen DeLong Content-Type: multipart/alternative; boundary=001a11c30f9ee1117204f724a091 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/RQqYYeP_J-YqruzEXOsUeXmrLd4 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 08:23:25 -0000 --001a11c30f9ee1117204f724a091 Content-Type: text/plain; charset=UTF-8 Ok. So: 1. As regards impact to the client - "don't waste your resources sending DHCPv4 requests, there's never going to be a DHCPv4 server here", then: what's the advantage to the client above doing exponential backoff with one packet every 2 minutes / half hour / 2 hours? True, clients don't do exponential backoff today, but they will have to be modified anyway for this option to work. 2. As regards impact to the infrastructure: on wifi, infrastructure-to-client broadcasts are expensive, but client-to-infrastructure broadcasts are effectively unicast. So just configuring the AP to drop the packets will do what you want. As regards to low-power clients, see #1. Don't get me wrong - I don't think this is harmful (modulo security considerations, of course). I just don't think it's a particularly good use of our time. If we do do this, on the face of it it would seem that from the host's perspective it would be better to have this information in DHCPv4 than in DHCPv6. Cheers, Lorenzo On Tue, Apr 15, 2014 at 1:57 PM, Owen DeLong wrote: > > On Apr 14, 2014, at 9:20 PM, Lorenzo Colitti wrote: > > On Mon, Apr 14, 2014 at 11:50 PM, Simon Perreault < > simon.perreault@viagenie.ca> wrote: > >> In a nutshell, it defines DHCPv6 and RA options indicating to the host >> that IPv4 is not available. Reviews from operations-minded people in >> V6OPS would be of tremendous help. >> > > I don't see a strong use case for this. It seems to me that the two > scenarios in the introduction can be solved by simply configuring the > DHCPv4 relay (or the server, if on-link) to drop all DHCPv4 requests. > > Am I missing something? > > > I believe the purpose is to get the DHC4 client to stop asking (broadcast > DHCP4 requests) on networks where repeated garbage packets are less than > desirable (low power applications, wifi, etc.) > > Owen > > --001a11c30f9ee1117204f724a091 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Ok. So:
  • As regards impact to the client - "do= n't waste your resources sending DHCPv4 requests, there's never goi= ng to be a DHCPv4 server here", then: what's the advantage to the = client above doing exponential backoff with one packet every 2 minutes / ha= lf hour / 2 hours? True, clients don't do exponential backoff today, bu= t they will have to be modified anyway for this option to work.
  • As regards impact to the infrastructure: on = wifi, infrastructure-to-client broadcasts are expensive, but client-to-infr= astructure broadcasts are effectively unicast. So just configuring the AP t= o drop the packets will do what you want. As regards to low-power clients, = see #1.
    • Don't get me wrong - I don't think this is harmful (modul= o security considerations, of course). I just don't think it's a pa= rticularly good use of our time.

    If we = do do this, on the face of it it would seem that from the host's perspe= ctive it would be better to have this information in DHCPv4 than in DHCPv6.=

    Cheers,
    Lorenzo


    On Tue, Apr 15, 2014 at 1:57 PM, Owen De= Long <owen@delong.com> wrote:

    On= Apr 14, 2014, at 9:20 PM, Lorenzo Colitti <lorenzo@google.com> wrote:

    On M= on, Apr 14, 2014 at 11:50 PM, Simon Perreault <simon.perreault@v= iagenie.ca> wrote:
    In a nutshell, it defines DHCPv6 and RA opti= ons indicating to the host
    that IPv4 is not available. Reviews from operations-minded people in
    V6OPS would be of tremendous help.

    I do= n't see a strong use case for this. It seems to me that the two scenari= os in the introduction can be solved by simply configuring the DHCPv4 relay= (or the server, if on-link) to drop all DHCPv4 requests.

    Am I missing something?

    I believe the purpose is to get the DHC4 cl= ient to stop asking (broadcast DHCP4 requests) on networks where repeated g= arbage packets are less than desirable (low power applications, wifi, etc.)=

    Owen


    --001a11c30f9ee1117204f724a091-- From nobody Wed Apr 16 01:37: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 3DD2D1A00E6 for ; Wed, 16 Apr 2014 01:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.272, 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 rCmRnqPg4B3v for ; Wed, 16 Apr 2014 01:37:04 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8A41A0087 for ; Wed, 16 Apr 2014 01:37:04 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 77C44A1; Wed, 16 Apr 2014 10:37:00 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 713F29A; Wed, 16 Apr 2014 10:37:00 +0200 (CEST) Date: Wed, 16 Apr 2014 10:37:00 +0200 (CEST) From: Mikael Abrahamsson To: Karsten Thomann In-Reply-To: <3446106.k0lm12lQ8b@linne> Message-ID: References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/RPhfIxAR68rI6OB7JTxfFeAklec Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 08:37:09 -0000 On Tue, 15 Apr 2014, Karsten Thomann wrote: > I have still problems to understand why a message on one link/interface should be able to > shutdown the whole IPv4 stack or the dhcpv4 client, the scope of the message should be limited > to the link/interface on which the message was received and not further... I can see the use-case for both. Let's say you have a mobile phone connecting to an IPv6 only wifi, and it has ipv4 on the mobile Internet side, and it's now connecting to dual stacked resources within the enterprise. So regarding shutting down IPv4 completely on the device, that should be a policy decision. There are use cases for both behaviour, ie allowing a single interface to shutdown the complete IPv4 stack on the device, and the case where you *don't* want this to happen. This should be a policy decision on the device. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Apr 16 01:51: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 D87B61A0087 for ; Wed, 16 Apr 2014 01:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 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.272, 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 1QUMUHL8ccJB for ; Wed, 16 Apr 2014 01:51:07 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id B81B21A0109 for ; Wed, 16 Apr 2014 01:51:07 -0700 (PDT) Received: by mail-ig0-f179.google.com with SMTP id hl10so785351igb.12 for ; Wed, 16 Apr 2014 01:51:04 -0700 (PDT) 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=HgE71zBlL2M7ElI6p4JljRWtdJhyKIWPb4kn8F26R3s=; b=ivcVqEPgXf5uJQHZkXH/yEV5JYXqfRBqZ4ijZSdWn7OtctqMCqCrWvKBxbawDnWysL aNQHnrTldNFeKYl3iL8+qbVJ7Yw6wr8dxE9hv7GCyDj80FS5er2qJqYFfwm8ZoTmYf0t Evc7uLSHhMGr5XrPTnkjdBJD6duNmnPiInyp+LO+rH1tJrH/H8OZcRpRIPx6udpZauQN Fefa54H4UKbt+YPzX6tA7xHqTS3WQSp1APZnj3JeTKBVMjfr1idJdyHjaVl+T3F7Zwit lyDlVVxeQ4AZysFB+hVdyCzdie+xPKOHDXcAMHD7llsTBon5neHryZRi+7VlzL0MBrRr lorA== 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=HgE71zBlL2M7ElI6p4JljRWtdJhyKIWPb4kn8F26R3s=; b=QHAopL9+dLHO1vG6naV3g6ARdMV9bbm4FLpBJzGztp6WSrRVMpGnUpu3KrHGtXeEYm 1S0/oOlVJY4sjv7s3yasZoOdoPF+5WM4PHquIXfYhMPa+MubkKxsNNECRYoSlsmfTlYo YMqNHFp4vswuWQfMeaQAKZdenFma1LJHQ0TongwHIopXx46x+mYBDNAXmEyYwOdA0H0s iEdAolIlv/LZ6Nf/VxUxAj9Uc7lCyCHf+YY1h44CtBzbkJlcM82zcivwfrXEFLTxQWYI TLt//W6u2m0b8O1G31rQ+oyTiroN6JOlGBqaOaNZsVJpis2yAMBbbO+I4gtBAodcT782 4MGg== X-Gm-Message-State: ALoCoQnb58khO9etay8ddCNugfo/a4u1hbQZL6kiTZvCb2TKL4JKo64g/7lzHXtHOIAFBL7pr198Ere6mjqj9CRYjziJJhDDdCWBxRSivQWDdb+OG3/I8kNuoRc+hRW7dG/e7rGTmHzSlyKNf+Ms6NFb6tYObJSS3vIxy+AkuDlpSu/6cEzw4oec3kxf8c10aaEcjV/ERuhd X-Received: by 10.42.21.133 with SMTP id k5mr2769245icb.1.1397638264238; Wed, 16 Apr 2014 01:51:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.136 with HTTP; Wed, 16 Apr 2014 01:50:44 -0700 (PDT) In-Reply-To: References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> From: Lorenzo Colitti Date: Wed, 16 Apr 2014 17:50:44 +0900 Message-ID: To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=20cf301cc54a43d85104f725049a Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4Q8kqqRCRCRXJuA-sWYPQQkEhZg Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 08:51:12 -0000 --20cf301cc54a43d85104f725049a Content-Type: text/plain; charset=UTF-8 On Wed, Apr 16, 2014 at 5:37 PM, Mikael Abrahamsson wrote: > So regarding shutting down IPv4 completely on the device, that should be a > policy decision. There are use cases for both behaviour, ie allowing a > single interface to shutdown the complete IPv4 stack on the device, and the > case where you *don't* want this to happen. This should be a policy > decision on the device. > The device will do what it wants with the information you give it, and I think it's unlikely to shut down all IPv4 on all interfaces just because your network asks it to. :-) --20cf301cc54a43d85104f725049a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On W= ed, Apr 16, 2014 at 5:37 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
    So regarding shutting down I= Pv4 completely on the device, that should be a policy decision. There are u= se cases for both behaviour, ie allowing a single interface to shutdown the= complete IPv4 stack on the device, and the case where you *don't* want= this to happen. This should be a policy decision on the device.

    The device will do what it wants wit= h the information you give it, and I think it's unlikely to shut down a= ll IPv4 on all interfaces just because your network asks it to. :-)
    --20cf301cc54a43d85104f725049a-- From nobody Wed Apr 16 01: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 C44741A0022 for ; Wed, 16 Apr 2014 01:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.272, 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 L23Zl0niQvD9 for ; Wed, 16 Apr 2014 01:54:44 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id CDC591A00A2 for ; Wed, 16 Apr 2014 01:54:43 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D6DFDA1; Wed, 16 Apr 2014 10:54:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CFE349A; Wed, 16 Apr 2014 10:54:39 +0200 (CEST) Date: Wed, 16 Apr 2014 10:54:39 +0200 (CEST) From: Mikael Abrahamsson To: Lorenzo Colitti In-Reply-To: Message-ID: References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/RwZQAUhvfstyemEa6fPOWMPQp-M Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 08:54:45 -0000 On Wed, 16 Apr 2014, Lorenzo Colitti wrote: > The device will do what it wants with the information you give it, and I > think it's unlikely to shut down all IPv4 on all interfaces just because > your network asks it to. :-) If it's an enterprise device then the enterprise probably want to follow what the network says. But as I said before, there are use-cases for both and this is why I feel the flags announced should be hints. Also again, I support this being put into RA. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Apr 16 02:40: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 287501A0013 for ; Wed, 16 Apr 2014 02:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 CAhodfE2p5DN for ; Wed, 16 Apr 2014 02:40:03 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 118401A00E6 for ; Wed, 16 Apr 2014 02:40:02 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1WaMBx-0000BSC; Wed, 16 Apr 2014 11:31:41 +0200 Message-Id: To: Mikael Abrahamsson From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> In-reply-to: Your message of "Wed, 16 Apr 2014 10:54:39 +0200 (CEST) ." Date: Wed, 16 Apr 2014 11:31:27 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/XPkeX8veXrMXlQFDK2i-csB7nos Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 09:40:05 -0000 In your letter dated Wed, 16 Apr 2014 10:54:39 +0200 (CEST) you wrote: >If it's an enterprise device then the enterprise probably want to follow >what the network says. But as I said before, there are use-cases for both >and this is why I feel the flags announced should be hints. > >Also again, I support this being put into RA. Unfortunately, the discussion is now split over v6ops and homenet. I think an option to shutdown IPv4 belongs in DHCPv4. Not in RA. Having an RA shutdown a DHCPv4 client just creates all kinds of complexity I can do without. >From a host OS point of view, acting on a DHCPv4 extension would be almost trivial, whereas putting an option in RA creates all kinds of complexity nobody can predict at the moment. From nobody Wed Apr 16 04:55: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 913D01A0156 for ; Wed, 16 Apr 2014 04:55:49 -0700 (PDT) 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 7rWSoMbhi6ua for ; Wed, 16 Apr 2014 04:55:44 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0121A014D for ; Wed, 16 Apr 2014 04:55:44 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 7241B88118 for ; Wed, 16 Apr 2014 04:55:41 -0700 (PDT) Received: from 102521117.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 3389C71B0001 for ; Wed, 16 Apr 2014 04:55:41 -0700 (PDT) Message-ID: <534E6FAF.5080503@innovationslab.net> Date: Wed, 16 Apr 2014 07:55:27 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <534C1A41.1050505@foobar.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="eWF759gmNIb5e4XaImAtMJNHkF4QjDfJJ" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Gggr6p5o6OjVegC3kxRwooj7Wlw Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 11:55:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eWF759gmNIb5e4XaImAtMJNHkF4QjDfJJ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I purposely picked Owen's message since it is a perfect entry point... On 4/14/14 3:32 PM, Owen DeLong wrote: >=20 > On Apr 14, 2014, at 10:45 AM, Matthew Petach > wrote: >=20 >>=20 >> On Mon, Apr 14, 2014 at 10:26 AM, Nick Hilliard >> wrote: On 14/04/2014 18:23, Matthew Petach wrote: >>> (which is to say, the potential for abuse here seems kinda high; >>> are we sure this a good road for us to be traveling down?) >>=20 >> This is no different to any other type of rogue dhcpv4 situation. >>=20 >> Nick >>=20 >>=20 >> Correct me if I'm wrong, though; being an ICMP response, rather >> than a DHCP response would mean DHCP snooping wouldn't be >> sufficient to stop me from engaging in mischief, where today >> settings like DHCP snooping and DHCP guard could prevent me from >> acting as a rogue DHCP server? >>=20 >> I suppose if we extend the concept of DHCP snooping to also include >> ICMP snooping, that would work. >>=20 >> Thanks! >>=20 >> Matt >>=20 >=20 > ICMP was just a suggestion. If you want to put it in DHCP/UDP to > dodge abuse potential, I have no problem with that. The point is that > this has no business being encoded in DHCPv6 or RA, it belongs in > IPv4 somewhere. Further down the thread, there have been arguments about IPv6 being the only transport available, hence the need to put this option in DHCPv6/RAs. Seems to me the way you keep this option in its own address family (i.e., carry it in DHCPv4) is to leverage a draft now going through IETF Last Call (draft-ietf-dhc-dhcpv4-over-dhcpv6). That draft specifies how to carry DHCPv4 options in DHCPv6 (due to lack of IPV4 transport). Regards, Brian --eWF759gmNIb5e4XaImAtMJNHkF4QjDfJJ 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.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTTm+2AAoJEBOZRqCi7goqcd8H/1yKlGLxHDf0AvwHN9B2Bqad sKuSIFlPZgEnCcvhpdozO88+u+4qud/klMCjEILDxxNvHliNgF/mR/ka9zSFJzVS 9Ejmn8RRM4APlUiwzeeFDjGr5jcVRWyVhvZS56Zf7//SQhdVmOaHaX/ypGFzAA96 RvIZDj+bf/xM7ZBVMgsqfQSD150lVyz70S84XSbjfm25LihASIth86pGhfs4DBY8 mIyeW3/CnDPNIoMO1ShqkgKOZH+XrTHWlefdvfHPyhcIC2dt2ZuVdbAwuFg2IDlC LKQHWkijf6fyqw+6KbmBakk5PsRFDsQuf2O5N2zYLrVzyO3P+p44uN+PQoObpTg= =X/m7 -----END PGP SIGNATURE----- --eWF759gmNIb5e4XaImAtMJNHkF4QjDfJJ-- From nobody Wed Apr 16 05:53: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 8889F1A016A for ; Wed, 16 Apr 2014 05:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 hDfzpOqugSlC for ; Wed, 16 Apr 2014 05:53:44 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 946C51A0166 for ; Wed, 16 Apr 2014 05:53:27 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2520:ef8a:477:622f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4EFB240063 for ; Wed, 16 Apr 2014 08:53:24 -0400 (EDT) Message-ID: <534E7D44.5080409@viagenie.ca> Date: Wed, 16 Apr 2014 08:53:24 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/DKLdc7UfKIqGYsnQJBxWv5IxE7U Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 12:53:48 -0000 Le 2014-04-16 04:37, Mikael Abrahamsson a écrit : > So regarding shutting down IPv4 completely on the device, that should be > a policy decision. There are use cases for both behaviour, ie allowing a > single interface to shutdown the complete IPv4 stack on the device, and > the case where you *don't* want this to happen. This should be a policy > decision on the device. Absolutely. That was the intent. I see now that such language is absent from the draft. We will add it in the next revision. Thanks, 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 nobody Wed Apr 16 05:58: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 760221A0171 for ; Wed, 16 Apr 2014 05:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 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.272, 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 G95TymcDFOYd for ; Wed, 16 Apr 2014 05:58:19 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id D595E1A0166 for ; Wed, 16 Apr 2014 05:58:18 -0700 (PDT) Received: from [192.168.2.100] (ip-64-134-38-51.public.wayport.net [64.134.38.51]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s3GCtmla000627 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 16 Apr 2014 05:55:50 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3GCtmla000627 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1397652950; bh=TPinu0Uk+ZaGFODSFL6fr455iHM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=HUBU73Sht/R84DVVupYOn9EDyr65+zcWWy/5D5v2FQjVUNyqa4AG3icnlzD+15Al4 fD51YZ3ApjtblSykP1JfOQWbsdhF2jbsaikd4L1U4ONVvmhBEcmUb2uLBDBUtmbsBB E06SNVUX4F1uyj9akpLyRn7t+Rjp2TGpKDa2D8wE= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: <534E6FAF.5080503@innovationslab.net> Date: Wed, 16 Apr 2014 05:55:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <60828264-A034-46D2-AFE6-05C984C172E7@delong.com> References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <534C1A41.1050505@foobar.org> <534E6FAF.5080503@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 16 Apr 2014 05:55:50 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/NOBSuaJHruk94Vg5qu95FuUIy9Q Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 12:58:23 -0000 > Further down the thread, there have been arguments about IPv6 being = the > only transport available, hence the need to put this option in > DHCPv6/RAs. Seems to me the way you keep this option in its own = address > family (i.e., carry it in DHCPv4) is to leverage a draft now going > through IETF Last Call (draft-ietf-dhc-dhcpv4-over-dhcpv6). That = draft > specifies how to carry DHCPv4 options in DHCPv6 (due to lack of IPV4 > transport). I=92m still trying to fathom what you would need DHCPv4 information for = at all in an environment lacking IPv4 transport. If you don=92t have DHCPv4 transport, how are you going to get the = client=92s DHCPv4 request in the first place? Why would you try to configure DHCPv4 information on a client that has = no IPv4 transport? I can see IPv6 transport for DHCPv4 relay information, but using DHCPv6 = as a transport to talk to the DHCPv4 client directly seems patently = absurd to me. Owen From nobody Wed Apr 16 06:52: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 05DCC1A01A7 for ; Wed, 16 Apr 2014 06:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 rF_dZxW3z9X8 for ; Wed, 16 Apr 2014 06:52:49 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id EF2111A01AA for ; Wed, 16 Apr 2014 06:52:47 -0700 (PDT) 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 F0AB11B8055 for ; Wed, 16 Apr 2014 06:52:44 -0700 (PDT) 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 D2BF619005C; Wed, 16 Apr 2014 06:52:44 -0700 (PDT) Received: from [192.168.146.119] (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, 16 Apr 2014 06:52:44 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <60828264-A034-46D2-AFE6-05C984C172E7@delong.com> Date: Wed, 16 Apr 2014 08:52:42 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <534C1A41.1050505@foobar.org> <534E6FAF.5080503@innovationslab.net> <60828264-A034-46D2-AFE6-05C984C172E7@delong.com> To: Owen DeLong X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/YPUeAh3pFWal5xy6lqvvHWp-SsA Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 13:52:53 -0000 On Apr 16, 2014, at 7:55 AM, Owen DeLong wrote: > I can see IPv6 transport for DHCPv4 relay information, but using = DHCPv6 as a transport to talk to the DHCPv4 client directly seems = patently absurd to me. It gets you the IPv6 relay path information, which you would not get if = you sent the request directly. Doing a v4 shim relay doesn't really = get you what you want since you don't want to configure the interface = that's connected to the link the relay is connected to. There's a = draft, http://tools.ietf.org/html/draft-ietf-dhc-v4configuration-05, = that talks about the why of this, but it needs a bit of work, so the = dhcpv4-over-dhcpv6 draft made it into the last call queue first. From nobody Wed Apr 16 06:57: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 A58B41A01B3 for ; Wed, 16 Apr 2014 06:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 7ynDTuXRaiiv for ; Wed, 16 Apr 2014 06:57:47 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id C50BD1A019B for ; Wed, 16 Apr 2014 06:57:47 -0700 (PDT) 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 D6B5A1B8034 for ; Wed, 16 Apr 2014 06:57:44 -0700 (PDT) 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 CFA5F19005C; Wed, 16 Apr 2014 06:57:44 -0700 (PDT) Received: from [192.168.146.119] (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, 16 Apr 2014 06:57:39 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: Date: Wed, 16 Apr 2014 08:57:36 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> To: Philip Homburg X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/iOXAiUW64mVNwuxwL2bTfbRQPXw Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 13:57:53 -0000 On Apr 16, 2014, at 4:31 AM, Philip Homburg = wrote: > Unfortunately, the discussion is now split over v6ops and homenet. The request was for feedback. If you want to discuss what's in the = document in the sense of participating in the working group effort, the = place to do that is the sunset4 mailing list. So the situation is = working out just fine, actually, despite my remark yesterday: homenet is = giving feedback, and v6ops is giving feedback. You are not going to change the outcome by soliciting support for your = position on other mailing lists. The way to change the outcome is by = raising technical issues that haven't already been addressed by the = working group. This is what the request for feedback was about. It's = not useful to rehash discussions about matters of preference that have = already been settled. From nobody Wed Apr 16 07:45: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 1A9601A01E4 for ; Wed, 16 Apr 2014 07:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.527 X-Spam-Level: X-Spam-Status: No, score=0.527 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272, 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 SWGfRJMKVZSL for ; Wed, 16 Apr 2014 07:45:38 -0700 (PDT) Received: from smtpauth4.wiscmail.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) by ietfa.amsl.com (Postfix) with ESMTP id 321591A01E3 for ; Wed, 16 Apr 2014 07:45:34 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-disposition: inline Content-type: text/plain; charset=utf-8 Received: from avs-daemon.smtpauth4.wiscmail.wisc.edu by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0N4400700OUF1Z00@smtpauth4.wiscmail.wisc.edu> for v6ops@ietf.org; Wed, 16 Apr 2014 09:45:31 -0500 (CDT) X-Spam-PmxInfo: Server=avs-4, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.16.143920, SenderIP=0.0.0.0 Received: from ricotta.doit.wisc.edu (ricotta.doit.wisc.edu [144.92.67.161]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0N44003KFOZTYG00@smtpauth4.wiscmail.wisc.edu>; Wed, 16 Apr 2014 09:45:31 -0500 (CDT) Date: Wed, 16 Apr 2014 09:45:29 -0500 From: "Dale W. Carder" To: "George, Wes" Message-id: <20140416144528.GA62773@ricotta.doit.wisc.edu> References: <534BF5A5.5010609@viagenie.ca> <20140415142103.GA50776@ricotta.doit.wisc.edu> <534D4D32.7080001@viagenie.ca> <489D13FBFA9B3E41812EA89F188F018E1AFE5ACB@xmb-rcd-x04.cisco.com> In-reply-to: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/DRWqInvrNz0OfffcWaQqpX4Oows Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 14:45:42 -0000 Thus spake George, Wes (wesley.george@twcable.com) on Tue, Apr 15, 2014 at 03:24:13PM -0400: > On 4/15/14, 11:20 AM, "Bernie Volz (volz)" wrote: > > >Yeah, but we survived the transition away from these older networks > >without significant issues and special messages on IPv4 to tell clients > >"don't try IPX or AppleTalk or ...". > > > >- Bernie > > Ok. Youngin’ (and cochair of Sunset4) speaking. My experience with > networking begins after these transitions were largely complete, so I > genuinely don’t have a good sense for what was done to “survive" this > transition, and I’d bet Simon doesn’t either. If that’s really the right > model, I'm not sure it was the "right" model, but we learned a lot. Everything in that timeframe was manually configured, although host numbering was automatic in IPX, plus we enforced bootp/dhcp use for v4. There were a number of factors that came into play in our migration off IPX. Every PC was dual-stack in effect. All major applications (really netware, and printing) were on IPX and used SAP for discovery. When these applications made it to ipv4 they also used ipv4 SLP for discovery. However, there was no RFC 3484 for IPX/IPv4. This meant that every PC (thousands) had to be visited manually and reconfigured to prefer ipv4 over ipx. Only then could we start the migration off of IPX. Today we do have 3484 (or better), plus happy eyeball variants. If we had either then, I think the transition would have been cake, and the migration would have been through atrophy. These were good sized broadcast (and collision) domains. Each was typically a big hub with a /22 that fed branches on thinnet. Our final push was for getting rid of SAP broadcasts. We had them at peak probably around 10 or 20 kpps, which was a disaster for the shared L2 segments and slow clients. We got lucky on appletalk because we forced most of the issues when we went from localtalk to ethernet. However, we kept gator boxes running as protocol translators, primarily for printing from apple OS 7 - 9 clients. We had hundreds of zones though, which was still horrible. I disabled appletalk on each router subint one at a time over the course of a year (this was 2006!). > Since we’ve brought up reducing junk client-sourced traffic on wireless > networks as one of the goals of being able to tell clients to stop > speaking DHCPv4, or IPv4/arp in general, how many wireless IPX and > Appletalk networks were there? (and yes that last question is mostly > tongue-in-cheek) These days we have thousands of AP's, with an ipv4 /17 for clients. However clients sending unnecessary dhcp probes is in the OK direction because this can be filtered on ingress at the AP, and it won't be broadcast back out to others. In fact we suppress ARP and other multicast in a similar manner. Modern enterprise wireless controller networks are way, way more sophisticated than their wired counterparts due to the management of scarce RF time. So, I don't buy any argument in this draft that there is a problem in this direction. If anything, modify dhcpv4 to do exponential backoff, but I doubt this would work either since the clients sleep and wake up too often. Dale From nobody Wed Apr 16 07:54: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 2602E1A021C for ; Wed, 16 Apr 2014 07:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 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.272, 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 kAXcEm6Fr5a2 for ; Wed, 16 Apr 2014 07:54:39 -0700 (PDT) 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 C7C001A021B for ; Wed, 16 Apr 2014 07:54:38 -0700 (PDT) Received: by mail-ig0-f172.google.com with SMTP id hn18so1119008igb.5 for ; Wed, 16 Apr 2014 07:54:35 -0700 (PDT) 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=o9uPKtSKqKDvf/vYeqC6gRRySyUJtr21F+5CHb20hpQ=; b=ddC1YT+FW3quFoC1o8bn8JDtJPFHrsMwuLSWQl3P4OaDz5e/VayA7Dy+7FGi8Mz3NQ YAQUoW4eslhoK3URzYFNWWGVzQIfzY+eKfX7KPKcpHCLQwcvKeHBmLYJKFd1m7Cje9Lc ln7RvGfyVBkm/WzFk31V6TXb4tbdTef8tArp2rU5h7bjQVCc3AodnjQS4tKq1EEEXWQg U7gAO+zi1mxMo4EHo9zROQ107AfFTSyXEOSz+QxVVzQznDJrujAFVseONWVDyRfkbY6C 9jjYq6YDb/xKLXQ98B5VC9KyrQsaw8EMt5BPV3afnvn8GdVXKUKqBhnOj5cczH0dOCg2 acoA== 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=o9uPKtSKqKDvf/vYeqC6gRRySyUJtr21F+5CHb20hpQ=; b=eEiBoy/qNLHO7mI98I7fpSWZS/zh0pusSdrO0eNsbT4LrsobfzkF5VDWWRhSRHe49e ZWM9XjKU9wiEwwSwo/45/LcJxNBX8+keA8K5KgVxSlpBjRK7GMY8DXyT0Q4gP6tzK8d8 SC/zrWfHW/WUsnzltbB3zDLiJK9GKVrVPRE5WtIC+EosTm+8Pv4DC1O8PUOQjKEzElR8 tvnKXigh6vW5yQn/NR9+kWUibzMX7DQkKDJhFy2/yXmGm7LdMos7PzSWnKR0rzxVVhW2 ruEEYG4pUwj9zeSsowzVE/Tfs7CD7sIpgf97MpZpGxXOI7zknamKmqhzQJku1rNSbFzC 8f4g== X-Gm-Message-State: ALoCoQl25PxE8e2pGiwR92UNvicZOFD9PwHvHkwUP1CDWtUBcGYhCAFTNCfVnYHKJi0try1UuD8BmIVeOvTL/1RPO3GjB4UeH8qoSUBy/FAaPp1vL1I5seJsTnu6I6TwILjMHjMyVXT0n7JfBFUom1QKRADxGaacCNONzSkVjkFzvsYikicYFlnCXDZKkhLgP3hlWN0j3pZH X-Received: by 10.42.20.6 with SMTP id e6mr4307137icb.29.1397660075511; Wed, 16 Apr 2014 07:54:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.136 with HTTP; Wed, 16 Apr 2014 07:54:14 -0700 (PDT) In-Reply-To: References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> From: Lorenzo Colitti Date: Wed, 16 Apr 2014 23:54:14 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=f46d04190e62516a7a04f72a1837 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/cJfLyBzl6PzchdaxxFbZrD2eZNg Cc: Philip Homburg , "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 14:54:43 -0000 --f46d04190e62516a7a04f72a1837 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 16, 2014 at 10:57 PM, Ted Lemon wrote: > The way to change the outcome is by raising technical issues that haven't > already been addressed by the working group. > I think that doesn't work, actually. What happens instead is that someone raises an issue, and you say that they're wrong. :-) --f46d04190e62516a7a04f72a1837 Content-Type: text/html; charset=UTF-8
    On Wed, Apr 16, 2014 at 10:57 PM, Ted Lemon <ted.lemon@nominum.com> wrote:
    The way to change the outcome is by raising technical issues that haven't already been addressed by the working group.

    I think that doesn't work, actually. What happens instead is that someone raises an issue, and you say that they're wrong. :-)
    --f46d04190e62516a7a04f72a1837-- From nobody Wed Apr 16 08:24: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 5E01C1A019B for ; Wed, 16 Apr 2014 08:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 DThXnybyZQLj for ; Wed, 16 Apr 2014 08:24:46 -0700 (PDT) Received: from smtpauth2.wiscmail.wisc.edu (wmauth2.doit.wisc.edu [144.92.197.222]) by ietfa.amsl.com (Postfix) with ESMTP id 00EBF1A0196 for ; Wed, 16 Apr 2014 08:24:45 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0N4400L00QNHRA00@smtpauth2.wiscmail.wisc.edu> for v6ops@ietf.org; Wed, 16 Apr 2014 10:24:42 -0500 (CDT) X-Spam-PmxInfo: Server=avs-2, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.16.151819, SenderIP=0.0.0.0 Received: from ricotta.doit.wisc.edu (ricotta.doit.wisc.edu [144.92.67.161]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0N4400LA4QT5HQ00@smtpauth2.wiscmail.wisc.edu>; Wed, 16 Apr 2014 10:24:42 -0500 (CDT) Date: Wed, 16 Apr 2014 10:24:40 -0500 From: "Dale W. Carder" To: Lorenzo Colitti Message-id: <20140416152440.GA64039@ricotta.doit.wisc.edu> References: <534BF5A5.5010609@viagenie.ca> <145CDCFA-8442-4949-8025-0D6CAE5027C2@delong.com> In-reply-to: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/J2nTCqFy6LrAZAH02fb6z6zjGHU Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 15:24:47 -0000 Thus spake Lorenzo Colitti (lorenzo@google.com) on Wed, Apr 16, 2014 at 05:22:55PM +0900: > > 1. As regards impact to the client - "don't waste your resources sending > DHCPv4 requests, there's never going to be a DHCPv4 server here", then: > what's the advantage to the client above doing exponential backoff with one > packet every 2 minutes / half hour / 2 hours? True, clients don't do > exponential backoff today, but they will have to be modified anyway for > this option to work. I would worry that mobile clients may not be online continously long enough for the backoff timer to get very high, unless there would be some way to tie the backoff timer into rfc4436 or something if you reattach to the same L2 domain. Dale From nobody Wed Apr 16 08:25: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 AABA21A01D4 for ; Wed, 16 Apr 2014 08:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 SVk-eDEeC5xw for ; Wed, 16 Apr 2014 08:25:12 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 508141A01E6 for ; Wed, 16 Apr 2014 08:25:10 -0700 (PDT) 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 68EDA1B803B for ; Wed, 16 Apr 2014 08:25:07 -0700 (PDT) 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 624CC19005C; Wed, 16 Apr 2014 08:25:07 -0700 (PDT) Received: from [192.168.146.119] (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, 16 Apr 2014 08:25:07 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: Date: Wed, 16 Apr 2014 10:25:05 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/eZbT9M2FaT9yMOx9QZrUxmROjsc Cc: Philip Homburg , "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 15:25:14 -0000 On Apr 16, 2014, at 9:54 AM, Lorenzo Colitti wrote: > I think that doesn't work, actually. What happens instead is that = someone raises an issue, and you say that they're wrong. :-) Hm. Well, I think the objection that's been raised that's most = compelling is "why bother?" Philip's issues are technical, but they = aren't objections, in the sense that he hasn't pointed out an oversight = in the spec that means it can't be implemented or won't work. We've gotten some good feedback that the document isn't clear enough, = particularly with respect to how multiple interfaces are handled, and = we've gotten some good feedback about how to handle validity of the = assertion that IPv4 shouldn't be used, and about how to deal with = various attacks that could be launched by shutting down IPv4. The = authors have agreed that there is work to do, and it sounds like they're = going to do it. I felt like that part of the conversation was = productive and beneficial. However, there's also been a lot of discussion about whether to use = DHCPv4 or IPv6 configuration protocols for signaling, and that hasn't = been so useful, because it's recapitulating discussions that have = occurred previously, and revisiting a decision the working group already = made, for reasons that are explained in the draft. I never know how to deal with discussions like this. I personally = favor an open communications model where I actually say why I don't = think the objections are useful, over a model where I just ignore them. = However, as we've seen, when people repeatedly re-assert the same = point, it tends to drown out the useful part of the conversation, and = when I say "no, that point isn't useful in this part of the discussion = because FOO," people re-assert the point with slightly different wording = rather than saying "oh, Ted might have a point, let me think about it." = So in that sense, me saying "that's not a valid point" isn't = constructive. This type of interaction, where we wind up endlessly re-stating the same = point, is one of the failure modes of the IETF. To the extent that = I've been a part of it, I apologize, but I still don't know how to = address the tradeoff between open communications and ignoring redundant = comments. From nobody Wed Apr 16 08:57: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 DD82E1A0206 for ; Wed, 16 Apr 2014 08:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 8_DZB6zxtvcu for ; Wed, 16 Apr 2014 08:57:20 -0700 (PDT) Received: from smtpauth3.wiscmail.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3281A0135 for ; Wed, 16 Apr 2014 08:57:20 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0N4400M00RMM6K00@smtpauth3.wiscmail.wisc.edu> for v6ops@ietf.org; Wed, 16 Apr 2014 10:57:17 -0500 (CDT) X-Spam-PmxInfo: Server=avs-3, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.16.154819, SenderIP=0.0.0.0 Received: from ricotta.doit.wisc.edu (ricotta.doit.wisc.edu [144.92.67.161]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0N4400MG6SBFIT00@smtpauth3.wiscmail.wisc.edu>; Wed, 16 Apr 2014 10:57:16 -0500 (CDT) Date: Wed, 16 Apr 2014 10:57:14 -0500 From: "Dale W. Carder" To: Mikael Abrahamsson Message-id: <20140416155714.GB64039@ricotta.doit.wisc.edu> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> In-reply-to: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5QYjAH-CGqPF6KsoR82dekrXLwE Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 15:57:25 -0000 Thus spake Mikael Abrahamsson (swmike@swm.pp.se) on Wed, Apr 16, 2014 at 10:54:39AM +0200: > On Wed, 16 Apr 2014, Lorenzo Colitti wrote: > > >The device will do what it wants with the information you give it, > >and I think it's unlikely to shut down all IPv4 on all interfaces > >just because your network asks it to. :-) > > If it's an enterprise device then the enterprise probably want to > follow what the network says. But as I said before, there are > use-cases for both and this is why I feel the flags announced should > be hints. We have probably tens of thousands of devices at any given time that are attached to our enterprise and have the ability to be on a cellular network. While we can send as many "hints" as we want, the devices in practice are tuned to operate in the best interest of it's owner or perhaps the cellular provider subsidizing its cost. So, I am not in favor of adding more hints that may or may not observed that result in additional complexity and create an even more diverse set of behavior that has to be managed. This is why I think the only real solution that would work in practice is ethertype filtering. Dale From nobody Wed Apr 16 09:10: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 DB2291A0135 for ; Wed, 16 Apr 2014 09:10:06 -0700 (PDT) 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 LRwMuPXDnG64 for ; Wed, 16 Apr 2014 09:10:03 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 401201A01F2 for ; Wed, 16 Apr 2014 09:10:02 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.dyn.netability.ie (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s3GG9v3A003240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 16 Apr 2014 17:09:58 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.dyn.netability.ie Message-ID: <534EAB83.1070906@foobar.org> Date: Wed, 16 Apr 2014 17:10:43 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ted Lemon References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1-tzF5E-RYIVIgSFXKpD16C36xU Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 16:10:07 -0000 On 16/04/2014 16:25, Ted Lemon wrote: > because it's recapitulating discussions that have occurred previously, > and revisiting a decision the working group already made, for reasons > that are explained in the draft. well no, not really. I can find no discussion at all about this on the sunset4 mailing lists - where there was only a single email about the entire draft from non-authors in the last couple of years, unrelated to this issue. From what I can tell from the sunset4 meeting minutes, there was only minimal discussion about the choice of using dhcpv6/ra at ietf meetings. If we are missing something here, can you please point to some URL or other resource where we can examine the justification for this decision, because so far there is a not insignificant level of disquiet about this choice on v6ops, and from what I can see, this body of opinion is being ignored. This concerns me because I see no clear evidence that due consideration was given to the issue in the first place. Nick From nobody Wed Apr 16 09: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 52A911A019B for ; Wed, 16 Apr 2014 09:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 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.272, 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 DmDfyTjmMxRU for ; Wed, 16 Apr 2014 09:24:56 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 31B191A0235 for ; Wed, 16 Apr 2014 09:24:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4055; q=dns/txt; s=iport; t=1397665493; x=1398875093; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=1CIcUzF4W5uRPqMYVERO/grbxS5XQyyWj/SOccuKqe8=; b=WgSBYPlk4lyQJbEbYUO47lk5eUdHXNUmJonsDrMnrJptKTsWl93OECRs zkkIEEho17UF1WogoVW7udNCJP7lrysMcdGJKhyIYjLhJ/qPyYZMUK46c ccDOVlLnUEW1zmgG8Ti7pA9WDAmONdncWxieoy4a6nlfgv6mSBTdfBAgJ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAHeuTlOtJA2N/2dsb2JhbABZgwY7V7t9hziBIhZ0giUBAQEEAQEBNzQJFAEIEQQBAR8FMgsdCAIEARIJEodNAxENyQEXjEmCIAaEMgSWfoFogTeLQoVQgXKBP4Ir X-IronPort-AV: E=Sophos;i="4.97,872,1389744000"; d="scan'208";a="318303388" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-4.cisco.com with ESMTP; 16 Apr 2014 16:24:46 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s3GGOkPT007265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Apr 2014 16:24:46 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.41]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Wed, 16 Apr 2014 11:24:45 -0500 From: "Eric Levy- Abegnoli (elevyabe)" To: Mark ZZZ Smith , V6 Ops List Thread-Topic: [v6ops] Fw: New Version Notification for draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.txt Thread-Index: AQHPWZBglp1mYi5zZkqc1Z0wcii+pA== Date: Wed, 16 Apr 2014 16:24:45 +0000 Message-ID: In-Reply-To: <1396905670.42588.YahooMailNeo@web162205.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.49.80.39] Content-Type: text/plain; charset="us-ascii" Content-ID: <9017149C23C86B4FA5B1BAB676B236D6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1BAENRJEiQOr5xnW-CDr7j7zFJo Subject: Re: [v6ops] Fw: New Version Notification for draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.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: Wed, 16 Apr 2014 16:25:01 -0000 Hi,=20 I took a look at the draft, and found it "protocolly" interesting but "operationally" flawed. - some host stacks (last time I checked was a few years ago, so hopefully that has changed) don't bother sending the MLD join for solicited-node groups, mainly because it's not very relevant. Currently, stacks don't bother storing mld state received in join, for any link-local scope mc, and simply forward multicast regardless (I understand that the draft is suggesting to make them relevant, but the amount of router-to-network interactions is not worth the value in my opinion). And the fact that so far, these states were useless make me think there are not generally available. - When the MLD join is sent, it is sent once, when link goes up. It's easy to miss it for the router, for many reasons (split network, no retry, reboot, etc.). The router could send a periodic MLD query, but that would generate quite a bit of overhead, and I suspect that while some host stacks still bother sending the mld report on link-up, they might not bother sending then on mld-query (I don't know that for a fact). Bottom line, the router is not likely to have an accurate table at any given time of all listeners (even if it polls, can't do it too often for obvious scalability reasons). So we can't really base a resolution decision on this table (unless the router is under attack and has no other choice). - In addition, to come back to the purpose (mitigate resolution DoS), it would "only: divide by 2**24 the address space. So a DoS attack would still have plenty of addresses to use for his attack (2**40 per known address, which is way enough to fill a cache). If this is "just" to mitigate a DoS resolution attack, it would be more efficient to store the (savi) binding table on the router, so that it knows the address, not the the slctd (I think someone proposed a solution like that at last ietf). Eric On 07/04/14 23:21, "Mark ZZZ Smith" wrote: >Hi, > >I've just posted the following ID, grateful for any feedback. > >Regards, >Mark. > > >----- Forwarded Message ----- >> From: "internet-drafts@ietf.org" >> To: Mark Smith ; Mark Smith >> >> Cc:=20 >> Sent: Tuesday, 8 April 2014 7:19 AM >> Subject: New Version Notification for >>draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.txt >>=20 >>=20 >> A new version of I-D, >>draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.txt >> has been successfully submitted by Mark Smith and posted to the >> IETF repository. >>=20 >> Name: draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node >> Revision: 00 >> Title: Further Mitigating Router ND Cache Exhaustion DoS Attacks >>Using=20 >> Solicited-Node Group Membership >> Document date: 2014-04-07 >> Group: Individual Submission >> Pages: 6 >> URL: =20 >>=20 >>http://www.ietf.org/internet-drafts/draft-smith-v6ops-mitigate-rtr-dos-ml >>d-slctd-node-00.txt >> Status: =20 >>=20 >>https://datatracker.ietf.org/doc/draft-smith-v6ops-mitigate-rtr-dos-mld-s >>lctd-node/ >> Htmlized: =20 >>=20 >>http://tools.ietf.org/html/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-n >>ode-00 >>=20 >>=20 >> Abstract: >> For each of their IPv6 unicast or anycast addresses, nodes join a >> Solicited-Node multicast group, formed using the lower 24 bits of the >> address. This group membership can be used by routers to further >> mitigate the Neighbor Discovery cache Denial of Service attack. >>=20 >> =20 >> =20 >> =20 >>=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 >> The IETF Secretariat >>=20 > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Apr 16 09: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 D4D5A1A01C8 for ; Wed, 16 Apr 2014 09:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 X7O8CNTgXbtV for ; Wed, 16 Apr 2014 09:42:23 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5DA1A025D for ; Wed, 16 Apr 2014 09:42:23 -0700 (PDT) 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 6DB7B1B803F for ; Wed, 16 Apr 2014 09:42:20 -0700 (PDT) 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 4F16C19005C; Wed, 16 Apr 2014 09:42:20 -0700 (PDT) Received: from [192.168.146.119] (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, 16 Apr 2014 09:42:20 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <534EAB83.1070906@foobar.org> Date: Wed, 16 Apr 2014 11:42:18 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <70739713-281A-41E6-93ED-5EE1BC4B7FAB@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <534EAB83.1070906@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/gKtyJV0bMZL_HhOAFPzb-TcgjN4 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 16:42:28 -0000 On Apr 16, 2014, at 11:10 AM, Nick Hilliard wrote: > well no, not really. I can find no discussion at all about this on = the > sunset4 mailing lists There are actually two other drafts related to this topic: http://tools.ietf.org/html/draft-yang-sunset4-weaken-dhcp-00 http://tools.ietf.org/html/draft-yang-dhc-ipv4-dis-01 The authors of draft-yang-sunset4-weaken-dhcp-00 decided to combine = their work with the current working group draft. This was discussed in = the meeting at IETF 87, and there were no objections (although there was = substantial comment on the draft). The draft was adopted by the = working group in September 2013; no objections were raised. So unless you are saying that there was a process failure here, the = issue is effectively settled. From nobody Wed Apr 16 09:51: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 A9C3D1A01AC for ; Wed, 16 Apr 2014 09:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 SuS6Klk3Kex6 for ; Wed, 16 Apr 2014 09:51:24 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id AD9D71A019B for ; Wed, 16 Apr 2014 09:51:24 -0700 (PDT) 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 AA6811B803F for ; Wed, 16 Apr 2014 09:51:21 -0700 (PDT) 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 A37E619005C; Wed, 16 Apr 2014 09:51:21 -0700 (PDT) Received: from [192.168.146.119] (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, 16 Apr 2014 09:51:21 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <70739713-281A-41E6-93ED-5EE1BC4B7FAB@nominum.com> Date: Wed, 16 Apr 2014 11:51:19 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <534EAB83.1070906@foobar.org> <70739713-281A-41E6-93ED-5EE1BC4B7FAB@nominum.com> To: Nick Hilliard X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/9fGyagGdUqkPER3ovkZDrOXQgAI Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 16:51:25 -0000 On Apr 16, 2014, at 11:42 AM, Ted Lemon wrote: > So unless you are saying that there was a process failure here, the = issue is effectively settled. BTW, this does _not_ mean that it can't be reopened. It just means = that the presumption is that it won't be. There is actually a precedent for something like this in IETF history: = https://tools.ietf.org/html/rfc2563 RFC 2563 is not widely implemented (not at all implemented, actually, as = far as I know). I think this is actually the strongest argument = against the current effort: if nobody implements it in any shipping = stacks, what's the point? From nobody Wed Apr 16 09:58: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 D522B1A01F2 for ; Wed, 16 Apr 2014 09:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] 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 r2hx5mcOCZ2v for ; Wed, 16 Apr 2014 09:58:50 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 42FB91A022A for ; Wed, 16 Apr 2014 09:58:50 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1WaTAV-0000BxC; Wed, 16 Apr 2014 18:58:39 +0200 Message-Id: To: Ted Lemon From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <534EAB83.1070906@foobar.org> <70739713-281A-41E6-93ED-5EE1BC4B7FAB@nominum.com> In-reply-to: Your message of "Wed, 16 Apr 2014 11:42:18 -0500 ." <70739713-281A-41E6-93ED-5EE1BC4B7FAB@nominum.com> Date: Wed, 16 Apr 2014 18:58:33 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/CsuFVYmIOZBJ5vLxO-seZgIVpzg Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 16:58:54 -0000 In your letter dated Wed, 16 Apr 2014 11:42:18 -0500 you wrote: >So unless you are saying that there was a process failure here, the issue is eff >ectively settled. I really love the false modesty in Section 4.1: "The authors conclude that a DHCPv6 option is clearly necessary, whereas it is not as clear for a DHCPv4 option. More feedback on this topic would be appreciated." Well, we can safely assume that the authors (at least some of them) got their feedback. It's up to them to decide what to do. From nobody Wed Apr 16 10:45: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 90A8D1A01AC for ; Wed, 16 Apr 2014 10:45:33 -0700 (PDT) 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 M5_QUEPM2gJE for ; Wed, 16 Apr 2014 10:45:29 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 480B21A01FD for ; Wed, 16 Apr 2014 10:45:23 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.dyn.netability.ie (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s3GHjH2w004029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 16 Apr 2014 18:45:17 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.dyn.netability.ie Message-ID: <534EC1DB.4010902@foobar.org> Date: Wed, 16 Apr 2014 18:46:03 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ted Lemon References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <534EAB83.1070906@foobar.org> <70739713-281A-41E6-93ED-5EE1BC4B7FAB@nominum.com> In-Reply-To: <70739713-281A-41E6-93ED-5EE1BC4B7FAB@nominum.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/DENne2Ub6DXyuTLrTl1_dOD-uIw Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 17:45:33 -0000 On 16/04/2014 17:42, Ted Lemon wrote: > On Apr 16, 2014, at 11:10 AM, Nick Hilliard wrote: >> well no, not really. I can find no discussion at all about this on the >> sunset4 mailing lists > > There are actually two other drafts related to this topic: ok, thanks for the refs. I was aware of draft-yang-sunset4-weaken-dhcp (and had already looked that up), but not of draft-yang-dhc-ipv4-dis. > http://tools.ietf.org/html/draft-yang-sunset4-weaken-dhcp-00 > http://tools.ietf.org/html/draft-yang-dhc-ipv4-dis-01 there is no record of any discussion about draft-yang-sunset4-weaken-dhcp on the sunset4 mailing list; just some notifications that the draft had been published. There were several emails on dhcwg@ about draft-yang-dhc-ipv4-dis, only one of which provided any comments, and another (from you) which contained a single question which was never answered. > The authors of draft-yang-sunset4-weaken-dhcp-00 decided to combine > their work with the current working group draft. This was discussed in > the meeting at IETF 87, and there were no objections (although there was > substantial comment on the draft). The draft was adopted by the > working group in September 2013; no objections were raised. The sunset4 minutes from IETF87 are here: https://tools.ietf.org/wg/sunset4/minutes?item=minutes-87-sunset4.html There's no mention of the DHCPv4 issue here either. There was discussion about this draft in sunset4 at ietf84 through ietf86, but all the discussion was entitled "Disabling IPv4 with DHCPv6", which rather put the cart before the horse, so to speak. Nothing in the minutes indicated any discussion as to why DHCPv4 was discarded as an option. This doesn't mean that there wasn't a discussion, of course. It just means that if there was, it wasn't minuted and now we have no way of reviewing the rationale for the decision. > So unless you are saying that there was a process failure here, the > issue is effectively settled. Process exists to serve the ietf, not the other way around. Several people in both v6ops and homenet have expressed serious concern about the choice to use dhcpv6 and ra instead of dhcpv4. If you want to invoke process to close the discussion on this topic, then that's your prerogative, but given the previous lack of discussion about it, I would view this as a very poor idea. Nick From nobody Wed Apr 16 10:55: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 AAA7D1A0165 for ; Wed, 16 Apr 2014 10:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 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.272, 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 lkUWKEZm0c3c for ; Wed, 16 Apr 2014 10:55:11 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 283D71A024F for ; Wed, 16 Apr 2014 10:55:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1394; q=dns/txt; s=iport; t=1397670908; x=1398880508; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1/o53UzR9XzC0TIL73dqlkV4w/2Sx3XbzF+fvgGchdk=; b=QbhYfDY+bk4gAtwS+6Zl9m8k6qSg0wmnryIi7fcCgvtxpm6ooxv4WGT/ RXGq01PL+9G6RYKKSHf80Q+CXeNaiziZKGYy78E8TlCYb7lkiFZ5rWbJ+ 5qBqY3P3x6kMIz3CwL6XMhbV1NK5qz7HRr6wiUcXRelxr2z8hnJw89ZI9 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4FAHrDTlOtJV2c/2dsb2JhbABZgwY7V7t9hziBIhZ0giUBAQEEAQEBNzQLDAQCAQgRBAEBAQoUCQcnCxQJCAIEAQ0FCId0Dck5EwSOMQYrBwaDHoEUAQOrL4Mxgis X-IronPort-AV: E=Sophos;i="4.97,873,1389744000"; d="scan'208";a="36366427" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP; 16 Apr 2014 17:55:07 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3GHt7ft018809 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Apr 2014 17:55:07 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.212]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Wed, 16 Apr 2014 12:55:07 -0500 From: "Bernie Volz (volz)" To: Ted Lemon , Nick Hilliard Thread-Topic: [v6ops] Please review the No IPv4 draft Thread-Index: AQHPWY5q0jm4+vJrr02ADXU7FejXCZsUxl0AgAAChYD//70OQA== Date: Wed, 16 Apr 2014 17:55:07 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AFE95F4@xmb-rcd-x04.cisco.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <534EAB83.1070906@foobar.org> <70739713-281A-41E6-93ED-5EE1BC4B7FAB@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.70.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/GKBI6njQcuUBu3mCOPm9b6uUI7M Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 17:55:14 -0000 Maybe for those that want this done via DHCPv4, RFC 2563's time is finally = here? Maybe it needs additional tweaks to have the DHCPv4 client extend the= times between retransmission of the DHCPDISCOVERs (as RFC 2563 does not ap= pear to mean stop sending those or send them less frequently). But as you say, it may be that this effort isn't necessary. - Bernie -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Wednesday, April 16, 2014 12:51 PM To: Nick Hilliard Cc: v6ops@ietf.org WG Subject: Re: [v6ops] Please review the No IPv4 draft On Apr 16, 2014, at 11:42 AM, Ted Lemon wrote: > So unless you are saying that there was a process failure here, the issue= is effectively settled. BTW, this does _not_ mean that it can't be reopened. It just means that t= he presumption is that it won't be. There is actually a precedent for something like this in IETF history: http= s://tools.ietf.org/html/rfc2563 RFC 2563 is not widely implemented (not at all implemented, actually, as fa= r as I know). I think this is actually the strongest argument against the= current effort: if nobody implements it in any shipping stacks, what's the= point? _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Apr 16 12:05:18 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 A24EA1A02ED for ; Wed, 16 Apr 2014 12:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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-DMCGBQET_g for ; Wed, 16 Apr 2014 12:05:13 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDBE1A0291 for ; Wed, 16 Apr 2014 12:05:13 -0700 (PDT) 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 1CF8D1B803F for ; Wed, 16 Apr 2014 12:05:10 -0700 (PDT) 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 DF06519005C; Wed, 16 Apr 2014 12:05:09 -0700 (PDT) Received: from [192.168.146.119] (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, 16 Apr 2014 12:05:09 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <534EC1DB.4010902@foobar.org> Date: Wed, 16 Apr 2014 14:05:07 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <575F73AC-8DA5-4E04-B2CF-4875B729C7D3@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <534EAB83.1070906@foobar.org> <70739713-281A-41E6-93ED-5EE1BC4B7FAB@nominum.com> <534EC1DB.4010902@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/3CRuhgjVXDKZwODDl2C_HUTWTe4 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 19:05:17 -0000 On Apr 16, 2014, at 12:46 PM, Nick Hilliard wrote: > Process exists to serve the ietf, not the other way around. Several = people > in both v6ops and homenet have expressed serious concern about the = choice > to use dhcpv6 and ra instead of dhcpv4. If you want to invoke process = to > close the discussion on this topic, then that's your prerogative, but = given > the previous lack of discussion about it, I would view this as a very = poor > idea. That's fine. The working group is amenable to useful discussion, as = far as I know. What concerns me is that a lot of objections have been = raised that are simply opinions, and that are addressed in the current = document. And motivations have been stated that do not match my = personal experience of the state of the art in host configuration = stacks. So I raise process not because I think process should trump technical = contribution, but because process is the only way to deal with disputes = over matters of opinion. There's no way everyone can win on a matter = of opinion, and while there's clearly some support for a DHCPv4 = solution, there's substantially more support for a DHCPv6/RA solution. = That's also why I asked people who object whether they had objections = which were of the form "this won't actually work because FOO." Nobody = provided any values of FOO with respect to the current proposal. You may get the impression that I feel strongly about this proposal and = think it's a good idea. I do support the work, and I think the choice = that's been made is a good one, but I really don't feel strongly about = it=97I'd be just as happy if the conclusion of the process was "just = filter IPv4 at the access points if you want it to go away," and I'd = like to see more discussion on that topic. But what I really do feel = strongly about is that discussions should be productive, and that's why = you see me participating in this discussion in the way that I have been = doing. From nobody Wed Apr 16 12:06: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 A7BCD1A02F8 for ; Wed, 16 Apr 2014 12:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 wUe_myDamjzS for ; Wed, 16 Apr 2014 12:06:46 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id B6A431A02F7 for ; Wed, 16 Apr 2014 12:06:46 -0700 (PDT) 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 C323B1B8055 for ; Wed, 16 Apr 2014 12:06:43 -0700 (PDT) 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 B85E219005C; Wed, 16 Apr 2014 12:06:43 -0700 (PDT) Received: from [192.168.146.119] (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, 16 Apr 2014 12:06:43 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AFE95F4@xmb-rcd-x04.cisco.com> Date: Wed, 16 Apr 2014 14:06:41 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <9BE7B619-D224-42E7-93ED-3C542E1AC0AF@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <534EAB83.1070906@foobar.org> <70739713-281A-41E6-93ED-5EE1BC4B7FAB@nominum.com> <489D13FBFA9B3E41812EA89F188F018E1AFE95F4@xmb-rcd-x04.cisco.com> To: Bernie Volz X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/DncASxVwbXjx98HP7c5KpdSpgl0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 19:06:47 -0000 On Apr 16, 2014, at 12:55 PM, Bernie Volz (volz) wrote: > Maybe for those that want this done via DHCPv4, RFC 2563's time is = finally here? Maybe it needs additional tweaks to have the DHCPv4 client = extend the times between retransmission of the DHCPDISCOVERs (as RFC = 2563 does not appear to mean stop sending those or send them less = frequently). 2563 doesn't shut down IPv4 altogether. It just kills IPv4 stateless = autoconfiguration (the 169.254.x.x addresses you see if you don't have = DHCPv4 service). From nobody Wed Apr 16 12:43: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 853161A030E for ; Wed, 16 Apr 2014 12:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.263 X-Spam-Level: X-Spam-Status: No, score=-1.263 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.272, 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 lA4eZGNCwxwH for ; Wed, 16 Apr 2014 12:43:45 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id D31041A021D for ; Wed, 16 Apr 2014 12:43:45 -0700 (PDT) Received: from owens-mbp.meeting.arin.net (unknown.servercentral.net [50.31.214.180] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s3GJg9qI032181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 16 Apr 2014 12:42:11 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3GJg9qI032181 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1397677333; bh=IxJJOAlYBaoKfrwkMTGQuRKiXbg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=xgCRFWh60fEWThFsoDFmvpru9OStFaosP8GZqrk0tjz4yYuqej7PxFDxsF4/IA7Cz zEMVhSymSJYVApkZlZnDgKrX3pPHx5KXRNW1M4GKblCvjIA5524VEsLH6QILHmRJde Uc3HILLr5cMMIVK1qtznKGWmmMxn7LwJ/ujG6InI= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: <575F73AC-8DA5-4E04-B2CF-4875B729C7D3@nominum.com> Date: Wed, 16 Apr 2014 12:42:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <534EAB83.1070906@foobar.org> <70739713-281A-41E6-93ED-5EE1BC4B7FAB@nominum.com> <534EC1DB.4010902@foobar.org> <575F73AC-8DA5-4E04-B2CF-4875B729C7D3@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 16 Apr 2014 12:42:13 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/tZi9vqFJOXCDTlRLKuCIruJqNtg Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 19:43:50 -0000 On Apr 16, 2014, at 12:05 PM, Ted Lemon wrote: > On Apr 16, 2014, at 12:46 PM, Nick Hilliard wrote: >> Process exists to serve the ietf, not the other way around. Several = people >> in both v6ops and homenet have expressed serious concern about the = choice >> to use dhcpv6 and ra instead of dhcpv4. If you want to invoke = process to >> close the discussion on this topic, then that's your prerogative, but = given >> the previous lack of discussion about it, I would view this as a very = poor >> idea. >=20 > That's fine. The working group is amenable to useful discussion, as = far as I know. What concerns me is that a lot of objections have been = raised that are simply opinions, and that are addressed in the current = document. And motivations have been stated that do not match my = personal experience of the state of the art in host configuration = stacks. >=20 > So I raise process not because I think process should trump technical = contribution, but because process is the only way to deal with disputes = over matters of opinion. There's no way everyone can win on a matter = of opinion, and while there's clearly some support for a DHCPv4 = solution, there's substantially more support for a DHCPv6/RA solution. = That's also why I asked people who object whether they had objections = which were of the form "this won't actually work because FOO." Nobody = provided any values of FOO with respect to the current proposal. Please explain how =93substantially more support=94 was established in = this context. It sounds like there was very limited discussion mostly in relation to = other drafts in working groups outside of v6ops. There=92s definitely been substantial objection to doing it in DHCPv6/RA = and significant support for doing it either in DHCPv4 or ICMPv4. > You may get the impression that I feel strongly about this proposal = and think it's a good idea. I do support the work, and I think the = choice that's been made is a good one, but I really don't feel strongly = about it=97I'd be just as happy if the conclusion of the process was = "just filter IPv4 at the access points if you want it to go away," and = I'd like to see more discussion on that topic. But what I really do = feel strongly about is that discussions should be productive, and that's = why you see me participating in this discussion in the way that I have = been doing. In which case, I would suggest it would be more productive to look for = ways to take the feedback received and apply it in a useful way rather = than simply attempt to unilaterally declare it out of scope for the = review and that the issues raised are =93settled=94 and immutable by = this process. Owen From nobody Wed Apr 16 13: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 995361A02DA for ; Wed, 16 Apr 2014 13:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 Ii1Rz5PH3dps for ; Wed, 16 Apr 2014 13:04:33 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 3F84D1A02CA for ; Wed, 16 Apr 2014 13:04:33 -0700 (PDT) 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 1A55A1B8050 for ; Wed, 16 Apr 2014 13:04:30 -0700 (PDT) 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 E8BC619005C; Wed, 16 Apr 2014 13:04:29 -0700 (PDT) Received: from [192.168.146.119] (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, 16 Apr 2014 13:04:29 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: Date: Wed, 16 Apr 2014 15:04:27 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <534EAB83.1070906@foobar.org> <70739713-281A-41E6-93ED-5EE1BC4B7FAB@nominum.com> <534EC1DB.4010902@foobar.org> <575F73AC-8DA5-4E04-B2CF-4875B729C7D3@nominum.com> To: Owen DeLong X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Tb7D9_HFEEZ_H9NpzMBMidmHi78 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 20:04:35 -0000 On Apr 16, 2014, at 2:42 PM, Owen DeLong wrote: > Please explain how =93substantially more support=94 was established in = this context. Well, let's see. The working group produced the document, so you've = got that support for DHCPv6/RA. And I count four people so far who = have stated strong opinions in favor of DHCPv4, none of whom participate = in the working group, and none of whom participated in developing the = specification. I've counted at least four people with the same level = of participation in sunset4 (none) who disagree with you. =20 I will admit that there has been a _lot_ more email in favor of DHCPv4, = but that's a bug, not a feature, because most of it has been repeats or = questions about the fairness of the process. None of this matters, = since we don't vote, either by head count or email volume count; I = mention it simply to point out that if we did vote, the outcome would = not be any more satisfying for you. > In which case, I would suggest it would be more productive to look for = ways to take the feedback received and apply it in a useful way rather = than simply attempt to unilaterally declare it out of scope for the = review and that the issues raised are =93settled=94 and immutable by = this process. I haven't said that the outcome is immutable; indeed I've explicitly = said that it's mutable, and explained how to mutate it. A question is = never so settled that a lone cry in the wilderness of "that won't work = because FOO" can't unsettle it. From nobody Wed Apr 16 13:23: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 928551A02E4 for ; Wed, 16 Apr 2014 13:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 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.272, 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 37Yzdesdf8zH for ; Wed, 16 Apr 2014 13:23:21 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id BD7891A02E7 for ; Wed, 16 Apr 2014 13:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1930; q=dns/txt; s=iport; t=1397679798; x=1398889398; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=nha8GIgMQwnC5E8iyRDKgFtBhmeia9nFEOWsfwLX100=; b=KGBauAF4CD29MjdnJcoeee7CICUzMCYKOc9EWUmWKDfymJsBfJHoTGXS oO4SW9HexuR90+d4bcwiQGDoWkN1BvOUpIzxVlFzmkr/Qt2s1ePyUHuOE IcHIvCs8n4+xPJKFgsPWvnC5FZ/v5iyle1SipRBHA5I1JbcyA7UON0cbL A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAAHmTlOtJV2Z/2dsb2JhbABZgwaBEsM1gSYWdIIlAQEBBDo/DAQCAQgRBAEBAQoUCQcyFAkIAgQOBQiHdMlzF44KJzEHBoMegRQBA6svgzGBaUI X-IronPort-AV: E=Sophos;i="4.97,874,1389744000"; d="scan'208";a="36403244" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-2.cisco.com with ESMTP; 16 Apr 2014 20:23:17 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3GKNGm4024129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Apr 2014 20:23:16 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.212]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Wed, 16 Apr 2014 15:23:16 -0500 From: "Bernie Volz (volz)" To: Ted Lemon Thread-Topic: [v6ops] Please review the No IPv4 draft Thread-Index: AQHPWY5q0jm4+vJrr02ADXU7FejXCZsUxl0AgAAChYD//70OQIAAaMSA//+90uA= Date: Wed, 16 Apr 2014 20:23:16 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AFE99EB@xmb-rcd-x04.cisco.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <534EAB83.1070906@foobar.org> <70739713-281A-41E6-93ED-5EE1BC4B7FAB@nominum.com> <489D13FBFA9B3E41812EA89F188F018E1AFE95F4@xmb-rcd-x04.cisco.com> <9BE7B619-D224-42E7-93ED-3C542E1AC0AF@nominum.com> In-Reply-To: <9BE7B619-D224-42E7-93ED-3C542E1AC0AF@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.70.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/tviS_r0ASj8VIAZSkWxkRNS64io Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 20:23:23 -0000 I understand that. Hence why I said we need the additional tweak (and I'm s= uggesting to slow the retransmission rate, not eliminate it completely ). For those that were willing to continue to run a DHCPv4 server of some limi= ted capabilities (as well as enough IPv4), this would: 1. Cause the clients not to autoconfigure (this is provided by RFC 2563). T= his means they have no address. 2. Cause the clients to reduce the rate at which they send DHCPDISCOVERs (t= his is a new option or change to DHCPv4 clients - like DHCPv6 SOLMAX). Cont= inuing to send these at a reduced rate is good in that someone might have e= rred and thus the client will eventually get back IPv4 service. This would then be a tool in the toolbox that people can use on networks wh= ere they want to avoid (reduce) IPv4 traffic. (Other tools include blocking= it where possible (switches, Wifi routers), just ignoring it, ...). And it= keeps the tools in the IPv4 / DHCPv4 part of the network and doesn't pollu= te IPv6 RAs and DHCPv6. There's little we can do to cause people to implement these if they don't f= eel the need.=20 - Bernie -----Original Message----- From: Ted Lemon [mailto:ted.lemon@nominum.com]=20 Sent: Wednesday, April 16, 2014 3:07 PM To: Bernie Volz (volz) Cc: Nick Hilliard; v6ops@ietf.org WG Subject: Re: [v6ops] Please review the No IPv4 draft On Apr 16, 2014, at 12:55 PM, Bernie Volz (volz) wrote: > Maybe for those that want this done via DHCPv4, RFC 2563's time is finall= y here? Maybe it needs additional tweaks to have the DHCPv4 client extend t= he times between retransmission of the DHCPDISCOVERs (as RFC 2563 does not = appear to mean stop sending those or send them less frequently). 2563 doesn't shut down IPv4 altogether. It just kills IPv4 stateless auto= configuration (the 169.254.x.x addresses you see if you don't have DHCPv4 s= ervice). From nobody Wed Apr 16 13: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 298D01A030F for ; Wed, 16 Apr 2014 13:30:14 -0700 (PDT) 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 hGWOK7EAyYs2 for ; Wed, 16 Apr 2014 13:30:09 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id CFB261A030B for ; Wed, 16 Apr 2014 13:29:47 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id vb8so4472943obc.8 for ; Wed, 16 Apr 2014 13:29:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=nYPQNJhUrcXrA+DlRPpF0DIwDIxHH+pmzp1AN9yAS98=; b=QlKcjQRBB/GlWsTLZyUvY9CCEGkdZlSvhAghz5Jy8Vj3nClo40VUxODCEKVbCK2HWg WhpMK0sbHPNS3Vx8fF+V9VHph6P2HA35gItPudnerdmmUj8J1TiqJQKG3+NPmMTAbs9h A/fDA8y6yZ8h//uqLeexv74pC9JpZiOWl5UH1WHC2nxtAEj+BM7WhK2RdQ5O4Xk4HA4Y hwA0eKZr5Bu36Awg/h8aWRZbeLCRSPIaqrMu2zHulgn38b23um/NWr7orx5x6R4h6lkH AqzLENJItk4y4EPSm8DHcAJ8G4VfMye1ihUJWfZQxbOdVlvw8VexRUpjYmQC30dn1a5D wbgA== X-Received: by 10.60.131.40 with SMTP id oj8mr8262776oeb.14.1397680184522; Wed, 16 Apr 2014 13:29:44 -0700 (PDT) Received: from [192.168.0.102] ([207.112.100.22]) by mx.google.com with ESMTPSA id dg2sm41845678obb.17.2014.04.16.13.29.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Apr 2014 13:29:43 -0700 (PDT) Message-ID: <534EE834.5040801@gmail.com> Date: Wed, 16 Apr 2014 16:29:40 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Nick Hilliard , Ted Lemon References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <534EAB83.1070906@foobar.org> <70739713-281A-41E6-93ED-5EE1BC4B7FAB@nominum.com> <534EC1DB.4010902@foobar.org> In-Reply-To: <534EC1DB.4010902@foobar.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Lfw037R-s3iv5tLmzTVtZ_2nU7Q Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 20:30:14 -0000 The real debate over the issue of IPv4 configuration over IPv6 occurred jointly between DHC and Softwires. It got quite heated. Jabber logs at http://www.ietf.org/jabber/logs/dhc/2013-11-05.html. On 16/04/2014 1:46 PM, Nick Hilliard wrote: > On 16/04/2014 17:42, Ted Lemon wrote: >> On Apr 16, 2014, at 11:10 AM, Nick Hilliard wrote: >>> well no, not really. I can find no discussion at all about this on the >>> sunset4 mailing lists >> >> There are actually two other drafts related to this topic: > > ok, thanks for the refs. I was aware of draft-yang-sunset4-weaken-dhcp > (and had already looked that up), but not of draft-yang-dhc-ipv4-dis. > >> http://tools.ietf.org/html/draft-yang-sunset4-weaken-dhcp-00 >> http://tools.ietf.org/html/draft-yang-dhc-ipv4-dis-01 > > there is no record of any discussion about draft-yang-sunset4-weaken-dhcp > on the sunset4 mailing list; just some notifications that the draft had > been published. > > There were several emails on dhcwg@ about draft-yang-dhc-ipv4-dis, only one > of which provided any comments, and another (from you) which contained a > single question which was never answered. > >> The authors of draft-yang-sunset4-weaken-dhcp-00 decided to combine >> their work with the current working group draft. This was discussed in >> the meeting at IETF 87, and there were no objections (although there was >> substantial comment on the draft). The draft was adopted by the >> working group in September 2013; no objections were raised. > > The sunset4 minutes from IETF87 are here: > > https://tools.ietf.org/wg/sunset4/minutes?item=minutes-87-sunset4.html > > There's no mention of the DHCPv4 issue here either. > > There was discussion about this draft in sunset4 at ietf84 through ietf86, > but all the discussion was entitled "Disabling IPv4 with DHCPv6", which > rather put the cart before the horse, so to speak. Nothing in the minutes > indicated any discussion as to why DHCPv4 was discarded as an option. This > doesn't mean that there wasn't a discussion, of course. It just means that > if there was, it wasn't minuted and now we have no way of reviewing the > rationale for the decision. > >> So unless you are saying that there was a process failure here, the >> issue is effectively settled. > > Process exists to serve the ietf, not the other way around. Several people > in both v6ops and homenet have expressed serious concern about the choice > to use dhcpv6 and ra instead of dhcpv4. If you want to invoke process to > close the discussion on this topic, then that's your prerogative, but given > the previous lack of discussion about it, I would view this as a very poor > idea. > > Nick > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Apr 16 14:12: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 6E4C71A0320 for ; Wed, 16 Apr 2014 14:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.123 X-Spam-Level: X-Spam-Status: No, score=-4.123 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.272, 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 BbdjwWA8d4Tz for ; Wed, 16 Apr 2014 14:11:56 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id C08CE1A02CE for ; Wed, 16 Apr 2014 14:11:34 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B9779A1; Wed, 16 Apr 2014 23:11:29 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B2DC19A; Wed, 16 Apr 2014 23:11:29 +0200 (CEST) Date: Wed, 16 Apr 2014 23:11:29 +0200 (CEST) From: Mikael Abrahamsson To: "Dale W. Carder" In-Reply-To: <20140416155714.GB64039@ricotta.doit.wisc.edu> Message-ID: References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xQFTWKcQaCJc8uAmV5w9gamtL5I Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 21:11:59 -0000 On Wed, 16 Apr 2014, Dale W. Carder wrote: > So, I am not in favor of adding more hints that may or may not observed > that result in additional complexity and create an even more diverse set > of behavior that has to be managed. This is why I think the only real > solution that would work in practice is ethertype filtering. That still doesn't solve the problem of the enterprise network being IPv6 only but publishes A and AAAA entries for internal resources on the internal DNS zone, because other networks they have are dual stack. Otoh I think this would be better solved by implementing MIF functionality in the device but... oh well. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Apr 16 14: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 5483D1A02CE for ; Wed, 16 Apr 2014 14:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.263 X-Spam-Level: X-Spam-Status: No, score=-1.263 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.272, 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 e8csyx8O-1i6 for ; Wed, 16 Apr 2014 14:18:46 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA371A01C1 for ; Wed, 16 Apr 2014 14:18:46 -0700 (PDT) Received: from owens-mbp.meeting.arin.net (unknown.servercentral.net [50.31.214.180] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s3GLGiRx005791 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 16 Apr 2014 14:16:55 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3GLGiRx005791 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1397683015; bh=rEXGyZJ8BOuQMgEjpmCBZ7Bb0Ds=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=fOokorkwmfV+suazIj9YI3Elr3sobupfP/qiGQDMTEROH5exy2e+dawudVUW9ilxp PmPJf83q+tvsXcFF09fJ1bZ2ty7XTPl3b/eoSiIRoXibFSKebAYJE+LBt5UL7si+Q+ Sl0KmfFHE28fjgqW3R5aiacd79Ny8BYuNvasw28w= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: Date: Wed, 16 Apr 2014 14:16:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 16 Apr 2014 14:16:55 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Fx4JIIe1IdSkF2stcGtUOkDfW-U Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 21:18:50 -0000 On Apr 16, 2014, at 2:11 PM, Mikael Abrahamsson = wrote: > On Wed, 16 Apr 2014, Dale W. Carder wrote: >=20 >> So, I am not in favor of adding more hints that may or may not = observed that result in additional complexity and create an even more = diverse set of behavior that has to be managed. This is why I think the = only real solution that would work in practice is ethertype filtering. >=20 > That still doesn't solve the problem of the enterprise network being = IPv6 only but publishes A and AAAA entries for internal resources on the = internal DNS zone, because other networks they have are dual stack. A host which doesn=92t have a v4 route to reach a given A record should = ignore said A record pretty harmlessly in favor of the AAAA record. A = host that does otherwise is a broken host. Owen From nobody Wed Apr 16 16:12: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 BF0931A01A9 for ; Wed, 16 Apr 2014 16:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 F860fFaJ3GGH for ; Wed, 16 Apr 2014 16:12:51 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA1D1A0005 for ; Wed, 16 Apr 2014 16:12:51 -0700 (PDT) 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 39AE81B81EA for ; Wed, 16 Apr 2014 16:12:48 -0700 (PDT) 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 1DC9C19005C; Wed, 16 Apr 2014 16:12:48 -0700 (PDT) Received: from [192.168.146.119] (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, 16 Apr 2014 16:12:47 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <534EE834.5040801@gmail.com> Date: Wed, 16 Apr 2014 18:12:45 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <3DF45562-0FC9-4596-91C0-E95FF218F02F@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <534EAB83.1070906@foobar.org> <70739713-281A-41E6-93ED-5EE1BC4B7FAB@nominum.com> <534EC1DB.4010902@foobar.org> <534EE834.5040801@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/EUcKQl6_IxlEG1-xvidc25dYfD4 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 23:12:53 -0000 On Apr 16, 2014, at 3:29 PM, Tom Taylor = wrote: > The real debate over the issue of IPv4 configuration over IPv6 = occurred jointly between DHC and Softwires. It got quite heated. Jabber = logs at http://www.ietf.org/jabber/logs/dhc/2013-11-05.html. That was a bit of debate between me and Ole, but to characterize it as = "the real debate" kind of misses what consensus is about. This is = something that's been discussed at great length over the past six years, = and the working group has at various times had consensus about it. Ole = and my discussion is one brief vignette within that multi-year saga. But again, it's orthogonal to what we are talking about here=97the draft = we were talking about is how to configure IPv4 addresses and service = information when you don't have a local wire with IPv4 running on it, = not how you turn off IPv4 when you don't want it. From nobody Wed Apr 16 16:43: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 A0F691A0424 for ; Wed, 16 Apr 2014 16:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.263 X-Spam-Level: X-Spam-Status: No, score=-1.263 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.272, 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 1FNerVp9d4St for ; Wed, 16 Apr 2014 16:43:10 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 303B01A0420 for ; Wed, 16 Apr 2014 16:43:09 -0700 (PDT) Received: from [192.168.2.100] (ip-64-134-38-51.public.wayport.net [64.134.38.51]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s3GNeOY1018541 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 16 Apr 2014 16:40:36 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3GNeOY1018541 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1397691637; bh=BdvYVbYY9srupm+0/Ow1Cxex1Bo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nFBjyU16BVp1K6W8qr2WqCLRMCJEYILs8sWgKpcPz4TUbLKbeiCa9+C+212ytKswU NX4OZ813etfoxuJWgIN1gMqiu413tLpGjPTf/gsoc9+KEYhKwtfNkxK3+zL70u5bTP tjo8OUyoqB3n6STeYXVtlKzcKjZJXU2SIf5hNb0Q= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: <3DF45562-0FC9-4596-91C0-E95FF218F02F@nominum.com> Date: Wed, 16 Apr 2014 16:40:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <696FEE01-88E1-482B-9128-05C415B37481@delong.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <534EAB83.1070906@foobar.org> <70739713-281A-41E6-93ED-5EE1BC4B7FAB@nominum.com> <534EC1DB.4010902@foobar.org> <534EE834.5040801@gmail.com> <3DF45562-0FC9-4596-91C0-E95FF218F02F@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 16 Apr 2014 16:40:37 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mJrIHIS3ltFnXEDTpBur5jwBN5s Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 16 Apr 2014 23:43:14 -0000 On Apr 16, 2014, at 4:12 PM, Ted Lemon wrote: > On Apr 16, 2014, at 3:29 PM, Tom Taylor = wrote: >> The real debate over the issue of IPv4 configuration over IPv6 = occurred jointly between DHC and Softwires. It got quite heated. Jabber = logs at http://www.ietf.org/jabber/logs/dhc/2013-11-05.html. >=20 > That was a bit of debate between me and Ole, but to characterize it as = "the real debate" kind of misses what consensus is about. This is = something that's been discussed at great length over the past six years, = and the working group has at various times had consensus about it. Ole = and my discussion is one brief vignette within that multi-year saga. >=20 > But again, it's orthogonal to what we are talking about here=97the = draft we were talking about is how to configure IPv4 addresses and = service information when you don't have a local wire with IPv4 running = on it, not how you turn off IPv4 when you don't want it. Huh??? The discussion we are talking about has nothing to do with that. = It=92s about how to turn off IPv4 services on a LAN where it is desired = to get an IPv4 DHCP client to STFU (or we=92re talking about two = different drafts, one of which is IPv4 configuration over an IPv6 tunnel = and the other of which is the DHCP STFU). Owen From nobody Wed Apr 16 18:40: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 5F39B1A03AC for ; Wed, 16 Apr 2014 18:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 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.272, 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 u5XKO6btJYGR for ; Wed, 16 Apr 2014 18:40:51 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5601A03A8 for ; Wed, 16 Apr 2014 18:40:51 -0700 (PDT) Received: by mail-ig0-f170.google.com with SMTP id uq10so1688412igb.5 for ; Wed, 16 Apr 2014 18:40:47 -0700 (PDT) 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=zv+HdJIsAvOwiGOeY2Fn1Bgn6kD3/t3F79dUgOsNgHI=; b=U18q8td1wpVtiQikp3BS23WGRZucX9fav0LeMfXOFBIteoKkhzEMkm5JQco4wgeKyp YjLULhaf+37ZI/B19ZikMv74tyUJpb4e024CNOM6zGqqDwrBiOfcl68KVagsmE76dYLt lNOSaNoEbzfVKJDGZ4ufdxdLfo2k0GYqmk+psT/iAHr3ACCqeonv+WB4dhHdwegS7GPn uAJIMSa0nOCwbL3ehH82d14eG9XKg1dwvCrB4gMcVWbH+hHVlWDqJkXsdIB/dfA4jpi7 3RqnVsEbboDWpBvBmbBVaRIdLooXDjZ57TwohqXkGgOotDj2D/1UvyuRym5qbRfoz5Zc gs3Q== 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=zv+HdJIsAvOwiGOeY2Fn1Bgn6kD3/t3F79dUgOsNgHI=; b=T4SZd8Pe6TSUYq1aXelGvEnsDhsyJhyoyJ1QrhMWPTJ3eNvWcjGIxcdl/eZnxOHhyi hupGsh52Dm5E1NOQEqg6C5GO9gl9m8lrvkC9QoN8swaQ4yIAPkckZuYfZOpTCr2vqwDu GuflEMvme77v2K5tw4UgNm7p37bi29rXxbGWFFx71yJfJ1MdGEMIdlo7C5Zg0GG536eL woNRWWaMaIJSEkXbAzO4RHdRbcS49wfuKiOxAi0uFuXNZjoh6QAgxTmAcUTDJSF/875f Vad7hQivd9ulON4kx6T2SGpSRhxZeNeNyZdH2iGmTPT8zyF2ClqEzhAs23sBzBA1flqE guWQ== X-Gm-Message-State: ALoCoQmE6nTnYyQk9nNxC1zkGgDtqQEVhehTq7v9sKFttiz7ghWV/TmkIvByhsG3eKbbAG5Q0m/jqlNO8px+wDC5k6Oj8OZuiluFk+usaVJxW7GPQXyyECOVESIaZ9H7+ZGqTUeRAlaSqCQH2ZnC08EsqVEMFRpXfXg6JdS1zPDdpUC9L+TFFIVPVPHCAUxjQY7oefFAN26q X-Received: by 10.50.79.161 with SMTP id k1mr13647701igx.31.1397698847775; Wed, 16 Apr 2014 18:40:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.136 with HTTP; Wed, 16 Apr 2014 18:40:27 -0700 (PDT) In-Reply-To: <575F73AC-8DA5-4E04-B2CF-4875B729C7D3@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <534EAB83.1070906@foobar.org> <70739713-281A-41E6-93ED-5EE1BC4B7FAB@nominum.com> <534EC1DB.4010902@foobar.org> <575F73AC-8DA5-4E04-B2CF-4875B729C7D3@nominum.com> From: Lorenzo Colitti Date: Thu, 17 Apr 2014 10:40:27 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=089e01183c36534f6504f7331fbc Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/PCxfAwfJ81xKpb24_4Otapsq3L8 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 17 Apr 2014 01:40:55 -0000 --089e01183c36534f6504f7331fbc Content-Type: text/plain; charset=UTF-8 On Thu, Apr 17, 2014 at 4:05 AM, Ted Lemon wrote: > What concerns me is that a lot of objections have been raised that are > simply opinions, and that are addressed in the current document. > I think the problem is that while they are, as you say, addressed in the current document, there are a number of people on this thread who find the arguments incomplete and insatisfactory. In other words, a lot of objections are opinions, but some of the arguments in the current document are simply opinions, too. Example: one thing that argues in favour of a DHCPv4 option is that on current IPv4-only networks, it can be very easy to send out a rogue RA or install a rogue DHCPv6 server, because IPv6 security features like RA guard or DHCPv6 filtering are likely not in place. The impact of such an attack on current hosts is severe, because it allows attackers to blackhole packets, but at least hosts that implement happy eyeballs can defend against that sort of attack. This option makes it much worse: if a rogue RA sender or rogue DHCPv6 server sends out a "kill IPv4" option, then the hosts are dead in the water. There is no mention of this in the document. --089e01183c36534f6504f7331fbc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On T= hu, Apr 17, 2014 at 4:05 AM, Ted Lemon <ted.lemon@nominum.com><= /span> wrote:
    What concerns me is that a l= ot of objections have been raised that are simply opinions, and that are ad= dressed in the current document.

    I think the problem is that while they are= , as you say, addressed in the current document, there are a number of peop= le on this thread who find the arguments incomplete and insatisfactory. In = other words, a lot of objections are opinions, but some of the arguments in= the current document are simply opinions, too.

    Example: one thing that argues in favour of a DHCPv4 op= tion is that on current IPv4-only networks, it can be very easy to send out= a rogue RA or install a rogue DHCPv6 server, because IPv6 security feature= s like RA guard or DHCPv6 filtering are likely not in place. The impact of = such an attack on current hosts is severe, because it allows attackers to b= lackhole packets, but at least hosts that implement happy eyeballs can defe= nd against that sort of attack. This option makes it much worse: if a rogue= RA sender or rogue DHCPv6 server sends out a "kill IPv4" option,= then the hosts are dead in the water.

    There is no mention of this in the document.
    --089e01183c36534f6504f7331fbc-- From nobody Wed Apr 16 18:44: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 B11931A001A for ; Wed, 16 Apr 2014 18:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 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.272, 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 aYvCK5-KT6tk for ; Wed, 16 Apr 2014 18:44:32 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id D6DF41A000E for ; Wed, 16 Apr 2014 18:44:31 -0700 (PDT) Received: by mail-ig0-f179.google.com with SMTP id hl10so152874igb.6 for ; Wed, 16 Apr 2014 18:44:28 -0700 (PDT) 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=tiM4ALjXgz2/a7dmvNbsXbPcvMcRRJKNSxCxz5mIUIg=; b=RM4hikdt3ZOsjnnHT4KQz4RZO34yrGmj9g/LjZP9xIOv5CMZek/iPp9l70OEQe44mJ 5pALy8BmwuhxVm2sZlyH9lWGXcPngOGqVV0QwoinkgBRCtUxypxZT+Dq7tM0WARJFTou UKEEvZsDYlv5/TMDVnubHsqM9RrJ9nZjvQQFggInUsrTqj1fzxismtH5gMVp3CXDuVqs vVceTzSJ08N30cEPig/i/S9rY2EzeDj5aiVQ4HcpDM57EV1cHKhoUBEwiL80Yk3RaJkH lQPbH4fEnM12/llMaFy8C6BfieNiuv9K7ZL8ufELuzFaCOyAJ+voWSNZ+fHedUtiv15k 48qw== 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=tiM4ALjXgz2/a7dmvNbsXbPcvMcRRJKNSxCxz5mIUIg=; b=XRVWY4Zcoco9uoA7eZMTSJ/7ExiAyNuiJYOGqlnXr11A+iAhgrMIB8+HZwVkb3pjmn niJWPgiQRw+TFtg7w7UBjwY7JhMLa8nbWCPwy/5yjfLX/hl02jqhSav0ump3KCDJunRn wvWtBBNGp7bAQZ0gdnuAhEIfDBr+RmhKpzcC7xvD+pJR0o/spSndNz+1EaGYwb8x+5N2 8lyXFPxjU2gGqS97+Bz+ruZpSdif1bV8w+tHb66wjp0nGynBWSDwe8ha1rAbH1M2OhLs RMR7QPD8UBFUFsElpcWYVdlpRlxR9IdrT8wDdtKQ2Zm7KSAws9tQVdjCFNfSmA1vqUfu k3tA== X-Gm-Message-State: ALoCoQnwkqKM4bjM//E9EIQ04ujaGpnRZRsmUNwKv27eIBdB3/6wwOkHvkPwfcyxGA8ml/UC3RoObC4GenOqGkXL1l4KGDrivR4s2zHModrctsQAIyoiF3QtTRmXKnGLsQTe3PJDroerROz3xXKxwH/8P4TW3w2F2g6kK/LjOR8/hdQLQswP9mereb+iPLqM/m/BogC2hBmv X-Received: by 10.50.114.99 with SMTP id jf3mr13627556igb.45.1397699068418; Wed, 16 Apr 2014 18:44:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.136 with HTTP; Wed, 16 Apr 2014 18:44:08 -0700 (PDT) In-Reply-To: References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <534EAB83.1070906@foobar.org> <70739713-281A-41E6-93ED-5EE1BC4B7FAB@nominum.com> <534EC1DB.4010902@foobar.org> <575F73AC-8DA5-4E04-B2CF-4875B729C7D3@nominum.com> From: Lorenzo Colitti Date: Thu, 17 Apr 2014 10:44:08 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7b4146e07a04db04f7332c97 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1a9bp3CHT9Eix5hE_TKVctAODmA Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 17 Apr 2014 01:44:32 -0000 --047d7b4146e07a04db04f7332c97 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 17, 2014 at 10:40 AM, Lorenzo Colitti wrote: > This option makes it much worse: if a rogue RA sender or rogue DHCPv6 > server sends out a "kill IPv4" option, then the hosts are dead in the water. > Ted - for the avoidance of doubt, I assert that this is a "this won't work because FOO" objection. :-) --047d7b4146e07a04db04f7332c97 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On T= hu, Apr 17, 2014 at 10:40 AM, Lorenzo Colitti <lorenzo@google.com>= wrote:
    =
    This option makes it much worse:= if a rogue RA sender or rogue DHCPv6 server sends out a "kill IPv4&qu= ot; option, then the hosts are dead in the water.

    Ted - for the avoidance = of doubt, I assert that this is a "this won't work because FOO&quo= t; objection. :-)
    --047d7b4146e07a04db04f7332c97-- From nobody Wed Apr 16 19:04: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 9D8871A0031 for ; Wed, 16 Apr 2014 19:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 kov-mqduBvm3 for ; Wed, 16 Apr 2014 19:04:27 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id D6BC21A0016 for ; Wed, 16 Apr 2014 19:04:27 -0700 (PDT) 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 886AC1B81EB for ; Wed, 16 Apr 2014 19:04:24 -0700 (PDT) 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 54EF019005C; Wed, 16 Apr 2014 19:04:24 -0700 (PDT) Received: from [192.168.146.119] (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, 16 Apr 2014 19:04:24 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: Date: Wed, 16 Apr 2014 21:04:21 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <2E8100D0-A238-4E03-84EF-4645385FB298@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <534EAB83.1070906@foobar.org> <70739713-281A-41E6-93ED-5EE1BC4B7FAB@nominum.com> <534EC1DB.4010902@foobar.org> <575F73AC-8DA5-4E04-B2CF-4875B729C7D3@nominum.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/3-ilmFzSRaoRchpmHnuYakhMbNU Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 17 Apr 2014 02:04:30 -0000 On Apr 16, 2014, at 8:40 PM, Lorenzo Colitti wrote: > Example: one thing that argues in favour of a DHCPv4 option is that on = current IPv4-only networks, it can be very easy to send out a rogue RA = or install a rogue DHCPv6 server, because IPv6 security features like RA = guard or DHCPv6 filtering are likely not in place. The impact of such an = attack on current hosts is severe, because it allows attackers to = blackhole packets, but at least hosts that implement happy eyeballs can = defend against that sort of attack. This option makes it much worse: if = a rogue RA sender or rogue DHCPv6 server sends out a "kill IPv4" option, = then the hosts are dead in the water. >=20 > There is no mention of this in the document. Yes, but Lorenzo, if you followed the conversation, you might recall = that this very issue came up, and the authors agree that it's an issue, = and will be updating the draft to address the issue. After they've = addressed it according to what we talked about, a host that implements = the proposal will no longer be affected by rogue RAs in the way that you = describe. And, by the way, since rogue RAs are a problem regardless, they need to = be mitigated regardless. From nobody Wed Apr 16 21:02: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 336301A043E for ; Wed, 16 Apr 2014 21:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.262 X-Spam-Level: X-Spam-Status: No, score=-1.262 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.272, 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 bP-PMcJUY-24 for ; Wed, 16 Apr 2014 21:02:49 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6DD1A043C for ; Wed, 16 Apr 2014 21:02:48 -0700 (PDT) Received: from [192.168.2.100] (ip-64-134-38-51.public.wayport.net [64.134.38.51]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s3H429O5003151 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 16 Apr 2014 21:02:11 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3H429O5003151 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1397707333; bh=t/3WOLU0fne4nMOI5xQycXJRBzo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=BiV/9HT+rsrYOwVdUlRSSGuTKM6OgEMSCVZnntXd9k1zg/d8Ohmd/4Fd2Y00tGqQA y2gF4cyARC9u0Ujh9TegrS0onlinuIuwZbhPi8wyj9iTHnypoMcW2yR+WqRj/mMqY6 VB+ZRMZV4zv5friF6NTD7brhFgQBoo2/UfDP/jSQ= Content-Type: multipart/alternative; boundary="Apple-Mail=_161F03C2-22F2-4616-9C00-9C0BE07BFDE5" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: Date: Wed, 16 Apr 2014 21:02:07 -0700 Message-Id: <264E5E20-1891-4218-913F-8C8D80414E1B@delong.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <534EAB83.1070906@foobar.org> <70739713-281A-41E6-93ED-5EE1BC4B7FAB@nominum.com> <534EC1DB.4010902@foobar.org> <575F73AC-8DA5-4E04-B2CF-4875B729C7D3@nominum.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 16 Apr 2014 21:02:13 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/pb1vywWt29Di1hUicijEfjtCZP0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 17 Apr 2014 04:02:50 -0000 --Apple-Mail=_161F03C2-22F2-4616-9C00-9C0BE07BFDE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 16, 2014, at 6:44 PM, Lorenzo Colitti wrote: > On Thu, Apr 17, 2014 at 10:40 AM, Lorenzo Colitti = wrote: > This option makes it much worse: if a rogue RA sender or rogue DHCPv6 = server sends out a "kill IPv4" option, then the hosts are dead in the = water. >=20 > Ted - for the avoidance of doubt, I assert that this is a "this won't = work because FOO" objection. :-) +1 Owen --Apple-Mail=_161F03C2-22F2-4616-9C00-9C0BE07BFDE5 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
    On Apr 16, 2014, at 6:44 PM, Lorenzo Colitti <lorenzo@google.com> wrote:

    On Thu, Apr 17, 2014 at 10:40 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
    This option makes it much worse: if a rogue RA sender or rogue DHCPv6 server sends out a "kill IPv4" option, then the hosts are dead in the water.

    Ted - for the avoidance of doubt, I assert that this is a "this won't work because FOO" objection. :-)

    +1

    Owen

    --Apple-Mail=_161F03C2-22F2-4616-9C00-9C0BE07BFDE5-- From nobody Wed Apr 16 21:59: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 A3B5E1A0461 for ; Wed, 16 Apr 2014 21:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.123 X-Spam-Level: X-Spam-Status: No, score=-4.123 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.272, 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 mZj6uSaL8HCO for ; Wed, 16 Apr 2014 21:59:11 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 12E6B1A045E for ; Wed, 16 Apr 2014 21:59:10 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C0D43A1; Thu, 17 Apr 2014 06:59:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id BBDB69A; Thu, 17 Apr 2014 06:59:06 +0200 (CEST) Date: Thu, 17 Apr 2014 06:59:06 +0200 (CEST) From: Mikael Abrahamsson To: Owen DeLong In-Reply-To: Message-ID: References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> 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-647455301-1397710746=:10236" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/rIb7l-I7itFCWeMI8A86Ps4yfn8 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 17 Apr 2014 04:59:15 -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-647455301-1397710746=:10236 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 16 Apr 2014, Owen DeLong wrote: > > On Apr 16, 2014, at 2:11 PM, Mikael Abrahamsson wrote: > >> On Wed, 16 Apr 2014, Dale W. Carder wrote: >> >>> So, I am not in favor of adding more hints that may or may not observed that result in additional complexity and create an even more diverse set of behavior that has to be managed. This is why I think the only real solution that would work in practice is ethertype filtering. >> >> That still doesn't solve the problem of the enterprise network being IPv6 only but publishes A and AAAA entries for internal resources on the internal DNS zone, because other networks they have are dual stack. > > A host which doesn’t have a v4 route to reach a given A record should ignore said A record pretty harmlessly in favor of the AAAA record. A host that does otherwise is a broken host. It has a default IPv4 route out to the mobile network. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-647455301-1397710746=:10236-- From nobody Thu Apr 17 01:55: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 490231A00FE for ; Thu, 17 Apr 2014 01:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 Rwd-ieHTf6oS for ; Thu, 17 Apr 2014 01:55:26 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id AE4911A0027 for ; Thu, 17 Apr 2014 01:55:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 9AA6E870073; Thu, 17 Apr 2014 10:55:22 +0200 (CEST) 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 hwURrh2KG8lz; Thu, 17 Apr 2014 10:55:22 +0200 (CEST) Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:a5d1:d231:56c8:a9ec]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 5AFAB87006F; Thu, 17 Apr 2014 10:55:22 +0200 (CEST) Message-ID: <534F96F7.3030806@globis.net> Date: Thu, 17 Apr 2014 10:55:19 +0200 From: Ray Hunter User-Agent: Postbox 3.0.9 (Macintosh/20140129) MIME-Version: 1.0 To: Mikael Abrahamsson References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wWvex5vx9IGB3mTmSgfwhVqBbBc Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 17 Apr 2014 08:55:28 -0000 Mikael Abrahamsson wrote: > On Wed, 16 Apr 2014, Dale W. Carder wrote: > >> So, I am not in favor of adding more hints that may or may not >> observed that result in additional complexity and create an even more >> diverse set of behavior that has to be managed. This is why I think >> the only real solution that would work in practice is ethertype >> filtering. +1 > > That still doesn't solve the problem of the enterprise network being > IPv6 only but publishes A and AAAA entries for internal resources on > the internal DNS zone, because other networks they have are dual stack. > > Otoh I think this would be better solved by implementing MIF > functionality in the device but... oh well. > Enterprise networks will use alternative protocols/methods to configure their end nodes IMHO e.g. Active Directory And we have https://tools.ietf.org/html/rfc7078 for cases where some LANs are IPv4 only, some are dual stack, and others are IPv6 only (assuming anyone implements it) I'm hoping that a node connected to an authenticated AD server will by default ignore any unauthenticated configuration hints purportedly sent via a DHCPv6 server. Although as I've pointed out earlier, there could be serious race conditions here (RA/DHCPv6 IPv4 shutdown packet of death arrives before AD authentication). -- Regards, RayH From nobody Thu Apr 17 04:02: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 B113A1A004A for ; Thu, 17 Apr 2014 04:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 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.272, 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 jcb1Lgg91bGG for ; Thu, 17 Apr 2014 04:02:47 -0700 (PDT) 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 0BB301A0090 for ; Thu, 17 Apr 2014 04:02:44 -0700 (PDT) Received: by mail-ig0-f175.google.com with SMTP id ur14so2122327igb.8 for ; Thu, 17 Apr 2014 04:02:41 -0700 (PDT) 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=Uae3nAXLnziaLPnVPpCQ3I4CNKQH5dlzBEpVITJxCyg=; b=WQupBrq3J2SKhXLsj8M3/Sn7DLgAFlVqQF7O/1WRTSH9ykVVVRujBlCjjR7HZxPJ+i O2KnXhQECGlpZLJP6pTgMqKmpszDwLesBbUKJy3YqTPPQMWtJZ6HpSGtv8vUs3P8TGYJ tAfr2ggWKcVCvpu+EddOYEkShSiyds+GoxZeRIPnBZB1Il5x9xN+1GGG0FYAgBiaME5g aixsdSsKAeWkq5OjdVpXwmqhlF9YdJbxxNDQeZIxln9sMjmZQmNjvk+VkGfzNVmH8Vg3 sf+O3mV1rsXVTmTWF9uFuDsa0wjJITaky/OBkYtat2N3+Qtqb9YHfEQSpGNn1cBXaI+5 f14A== 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=Uae3nAXLnziaLPnVPpCQ3I4CNKQH5dlzBEpVITJxCyg=; b=l2ynXHEkxiYklE6rmg2uZK4DtD11iNiabQP+dknqaNt1dDD7SxpqRAlK2AfXAYFa5z /8S/bX7nZgKhvD7w2PS6bUi4adQiZJBodkMlU+GPzni9bttiAc1vDGELHIbnSZ52oM1n 8X5V3BggZyb4qVgEZiz/0Ok9YuoqmYx8J0GXX+DbXxGXw/+1ZG7uSr9nx9HoaSfjxstK vKWFwRETzxjjOrsXDwdWFgG2fx60zCIrbnZP1NDRB4da1hqKT33ukpKUtNsr8a1abPTR RufBvrKWJpcS3DO+umtZrMfZmKaCaeaipBGYxxlvdQaTeblmzchwW0NUcZzcCt4uuGS3 WqbA== X-Gm-Message-State: ALoCoQmwapNmoM4ALwDwrMLnpwl1Ayin0V74EvdUMJfW9ETMTOZ0N5CQrXqhwK8tgljxY0gf9i2qSFAMaD7E2U2SSIOERPfR1uhgwEGKJ1FWu48UVFkmADz6Ef5kSvmjKUsLax+QJ76hMQafkMcJR/gGr8rnc6oVI5thbLS+zJhC0wrkgiS3vHTs9uv5HfDikV9GZVUJAIL+ X-Received: by 10.43.138.8 with SMTP id iq8mr8600415icc.37.1397732561277; Thu, 17 Apr 2014 04:02:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.136 with HTTP; Thu, 17 Apr 2014 04:02:21 -0700 (PDT) In-Reply-To: <534F96F7.3030806@globis.net> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> <534F96F7.3030806@globis.net> From: Lorenzo Colitti Date: Thu, 17 Apr 2014 20:02:21 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=001a11c20364ce79ad04f73af88e Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/K_WAIh4RnuqcBSq2_hM29DCFGCM Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 17 Apr 2014 11:02:52 -0000 --001a11c20364ce79ad04f73af88e Content-Type: text/plain; charset=UTF-8 On Thu, Apr 17, 2014 at 11:04 AM, Ted Lemon wrote: > Yes, but Lorenzo, if you followed the conversation, you might recall that > this very issue came up, and the authors agree that it's an issue, and will > be updating the draft to address the issue. After they've addressed it > according to what we talked about, a host that implements the proposal will > no longer be affected by rogue RAs in the way that you describe. > Hard to tell since we're well past 200 messages at this point, but I think the solutions to this scenario that are being proposed are "put a legitimate IPv6 router to your network" (i.e., enable IPv6 on it) and "enable IPv6 RA guard + DHCPv6 guard on your network or block ethertype 0x86dd". All of those will require hardware upgrades in some networks. And, by the way, since rogue RAs are a problem regardless, they need to be > mitigated regardless. > That's a great statement in theory. However, bear in mind that on a lot of currently-installed equipment with no RA guard / DHCPv6 guard support, that means "block ethertype 0x86dd in the switches". As you say, if you can't or don't do this, you already have a problem today. However, the impact (or should I say, the "enormity" :-)) of the problem is different: - Today, the situation is "block ethertype 0x86dd in the switches, and if you don't or can't, your hosts won't be able to reach dual-stack websites unless they implement happy eyeballs". A nuisance, yes, but survivable, since most OSes implement happy eyeballs these days. - If this draft is published and implemented, that will turn into "block ethertype 0x86dd in the switches, and if you don't or can't, kiss your network goodbye". It's not OK to blind-side network operators like this. I repeat: FOO. --001a11c20364ce79ad04f73af88e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On T= hu, Apr 17, 2014 at 11:04 AM, Ted Lemon <ted.lemon@nominum.com>= wrote:
    Yes, but Lorenzo, if you followed the conversation, y= ou might recall that this very issue came up, and the authors agree that it= 's an issue, and will be updating the draft to address the issue. =C2= =A0 After they've addressed it according to what we talked about, a hos= t that implements the proposal will no longer be affected by rogue RAs in t= he way that you describe.

    Hard to tell since we're well pa= st 200 messages at this point, but I think the solutions to this scenario t= hat are being proposed are "put a legitimate IPv6 router to your netwo= rk" (i.e., enable IPv6 on it) and "enable IPv6 RA guard + DHCPv6 = guard on your network or block ethertype 0x86dd". All of those will re= quire hardware upgrades in some networks.

    And, by the way, since rogue RAs are a problem regardless, they need to be = mitigated regardless.

    That's a grea= t statement in theory. However, bear in mind that on a lot of currently-ins= talled equipment with no RA guard / DHCPv6 guard support, that means "= block ethertype 0x86dd in the switches". As you say, if you can't = or don't do this, you already have a problem today.

    However, the impact (or should I say, the "e= normity" :-)) of the problem is different:
    • Today, th= e situation is "block ethertype 0x86dd in the switches, and if you don= 't or can't, your hosts won't be able to reach dual-stack websi= tes unless they implement happy eyeballs". A nuisance, yes, but surviv= able, since most OSes implement happy eyeballs these days.
    • If this draft is published and implemented, that will turn into &q= uot;block ethertype 0x86dd in the switches, and if you don't or can'= ;t, kiss your network goodbye".
    It's not OK to= blind-side network operators like this.

    I repeat: FOO.
    --001a11c20364ce79ad04f73af88e-- From nobody Thu Apr 17 04:59: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 58B711A0119 for ; Thu, 17 Apr 2014 04:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.263 X-Spam-Level: X-Spam-Status: No, score=-1.263 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.272, 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 k4REwnrC6AoX for ; Thu, 17 Apr 2014 04:58:55 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 856CD1A0118 for ; Thu, 17 Apr 2014 04:58:54 -0700 (PDT) Received: from [192.168.2.100] (ip-64-134-38-51.public.wayport.net [64.134.38.51]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s3HBuiv9000419 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 17 Apr 2014 04:56:46 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3HBuiv9000419 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1397735808; bh=QomKBKhZaIXWJfkcmFkbGN/1CW4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=38RKvQXJ0wD7ja26rh8FJ8K+nJwXIXZ3Qq1N7atNm7rmuKwS0LfEQ9bO4wiLKz4c4 4CzKcs6t++MGsdtk1KZd5rMa+pUmt9p9h+h7SGqRNgW6qzDR1OsqZJG2WNFINaYr6d HvI+bOkjDRLd9GWXqcYb95IsbwEe0WzRsNKYG1Tc= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: Date: Thu, 17 Apr 2014 04:56:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4EABCE38-7CBA-4C95-84EE-686A2300F26E@delong.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 17 Apr 2014 04:56:48 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ovhuZ7MmgxhWCsYXLRAA4lESsV8 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 17 Apr 2014 11:58:59 -0000 On Apr 16, 2014, at 9:59 PM, Mikael Abrahamsson = wrote: > On Wed, 16 Apr 2014, Owen DeLong wrote: >=20 >>=20 >> On Apr 16, 2014, at 2:11 PM, Mikael Abrahamsson = wrote: >>=20 >>> On Wed, 16 Apr 2014, Dale W. Carder wrote: >>>=20 >>>> So, I am not in favor of adding more hints that may or may not = observed that result in additional complexity and create an even more = diverse set of behavior that has to be managed. This is why I think the = only real solution that would work in practice is ethertype filtering. >>>=20 >>> That still doesn't solve the problem of the enterprise network being = IPv6 only but publishes A and AAAA entries for internal resources on the = internal DNS zone, because other networks they have are dual stack. >>=20 >> A host which doesn=92t have a v4 route to reach a given A record = should ignore said A record pretty harmlessly in favor of the AAAA = record. A host that does otherwise is a broken host. >=20 > It has a default IPv4 route out to the mobile network. Providing a mechanism for an IPv6 LAN to shut down the IPv4 mobile = network on a device which is unlikely to be enterprise controlled is not = a solution in the real world, but only an attack vector. Sure, 5 years ago, you could make the case that corporate mobile devices = might be under sufficient control that this could be an effective = solution in many cases. Today, BYOD is becoming more and more the trend = and the percentage of mobile devices under sufficient corporate control = to make this feasible is small and shrinking rapidly. Instead, it simply introduces a DoS vector for additional attacks on = mobile devices in the wile, which is pretty much the last thing we need = at this point. So, to make Ted happy=85 I=92ll put this into terms he will hopefully = consider appropriate: This won=92t work because it introduces a significant new denial of = service path to a fairly large fraction of non-afflicted hosts until = such time as they turn off the solution leading to... This won=92t work because the solution will work on such a small = fraction of the afflicted hosts as to be ineffective at best. Owen From nobody Thu Apr 17 05:13: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 E7DB11A011E for ; Thu, 17 Apr 2014 05:13:29 -0700 (PDT) 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 nfZcjj_m4YYj for ; Thu, 17 Apr 2014 05:13:27 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 820811A010F for ; Thu, 17 Apr 2014 05:13:27 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.dyn.netability.ie (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s3HCDLAN019685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 17 Apr 2014 13:13:21 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.dyn.netability.ie Message-ID: <534FC59B.201@foobar.org> Date: Thu, 17 Apr 2014 13:14:19 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ted Lemon References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <534EAB83.1070906@foobar.org> <70739713-281A-41E6-93ED-5EE1BC4B7FAB@nominum.com> <534EC1DB.4010902@foobar.org> <575F73AC-8DA5-4E04-B2CF-4875B729C7D3@nominum.com> In-Reply-To: <575F73AC-8DA5-4E04-B2CF-4875B729C7D3@nominum.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/VzvKvEUfYXUBr3Me3OXOgYQr7fA Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 17 Apr 2014 12:13:30 -0000 On 16/04/2014 20:05, Ted Lemon wrote: > What concerns me is that a lot of objections have been > raised that are simply opinions, and that are addressed in the current > document. >From what I can see, there was no initial justification to use v6 transport other than a declarative "it shall be so!" pronouncement, and in this situation it is reasonable to question this decision in v6ops, particularly as it will cause operational problems as outlined by a bunch of people. Several of the issues raised about this on v6ops were not opinions, e.g. Ray Hunter's list of concerns in his email of 2014-04-14 22:21:01 +0200, most of which were based on the technical reality that implementing this option in dhcpv6/ra instead of dhcpv4 will create interpretation+state problems and unavoidable race conditions. Disappointingly, there was no follow-up on that email. Similarly the comments in my email of april 15, 23:16:52 +0100 were ignored. I fully understand your position on handling opinion A vs opinion B by using process, but we're not in this situation. Legitimate technical objections have been raised about a variety of fundamental issues in this ID and have either been addressed inadequately or in many cases not at all, and you are incorrectly writing several of these objections off as opinion. > I'd be just as happy if the conclusion of the process was "just > filter IPv4 at the access points if you want it to go away," and I'd > like to see more discussion on that topic. this is also a valid concern. I can see no reason why anyone would heed an unauthenticated signal to entirely shut down all ipv4 services o/s wide on their ipv4-enabled client (or even no-ipv4 options 1-2 for that matter), when we already have the existing option for operators to fully satisfy all aims of this draft by declining to forward ethertypes 0x0800 and 0x0806. Simple and enforceable are both good engineering principals to aspire to. Complex+advisory+piles of failure modes+controversial need a much greater level of justification, which is notably absent from this draft. Nick From nobody Thu Apr 17 05:42: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 614DD1A012B for ; Thu, 17 Apr 2014 05:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.737 X-Spam-Level: X-Spam-Status: No, score=-0.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272, 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 Y34k_RqkpS2Q for ; Thu, 17 Apr 2014 05:41:58 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA831A0118 for ; Thu, 17 Apr 2014 05:41:58 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.97,879,1389762000"; d="scan'208";a="273220079" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 17 Apr 2014 08:41:27 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Thu, 17 Apr 2014 08:41:53 -0400 From: "George, Wes" To: "Dale W. Carder" Date: Thu, 17 Apr 2014 08:41:52 -0400 Thread-Topic: [v6ops] Please review the No IPv4 draft Thread-Index: Ac9aOmkp2jmHcRmOTfGlMJ2uzfaBiA== Message-ID: References: <534BF5A5.5010609@viagenie.ca> <20140415142103.GA50776@ricotta.doit.wisc.edu> <534D4D32.7080001@viagenie.ca> <489D13FBFA9B3E41812EA89F188F018E1AFE5ACB@xmb-rcd-x04.cisco.com> <20140416144528.GA62773@ricotta.doit.wisc.edu> In-Reply-To: <20140416144528.GA62773@ricotta.doit.wisc.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ruPgqgLphGoYAOl1wd7s9adeu08 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 17 Apr 2014 12:41:59 -0000 T24gNC8xNi8xNCwgMTA6NDUgQU0sICJEYWxlIFcuIENhcmRlciIgPGR3Y2FyZGVyQHdpc2MuZWR1 PiB3cm90ZToNCg0KDQo+TW9kZXJuIGVudGVycHJpc2Ugd2lyZWxlc3MgY29udHJvbGxlcg0KPm5l dHdvcmtzIGFyZSB3YXksIHdheSBtb3JlIHNvcGhpc3RpY2F0ZWQgdGhhbiB0aGVpciB3aXJlZCBj b3VudGVycGFydHMNCj5kdWUgdG8gdGhlIG1hbmFnZW1lbnQgb2Ygc2NhcmNlIFJGIHRpbWUuICBT bywgSSBkb24ndCBidXkgYW55IGFyZ3VtZW50DQo+aW4gdGhpcyBkcmFmdCB0aGF0IHRoZXJlIGlz IGEgcHJvYmxlbSBpbiB0aGlzIGRpcmVjdGlvbi4NCg0KQSBmYWlyIHBvaW50LCBidXQgdGhpcyBl eHRlbmRzIGJleW9uZCBzaW1wbHkgZW50ZXJwcmlzZSBuZXR3b3JrcywgYW5kIEnigJltDQpub3Qg d2lsbGluZyB0byBhc3N1bWUgdGhhdCBhbGwgd2lyZWxlc3MgbmV0d29ya3Mgd2lsbCBoYXZlIGEg Y29udHJvbGxlciwNCm1vZGVybiBvciBvdGhlcndpc2UuIFRoZXJlIGFyZSBwbGVudHkgb2Ygc21h bGwgYW5kIG1pZHNpemUgbmV0d29ya3MgdGhhdA0KYXJlIHNpbXBseSBvbmUgb3IgbW9yZSBBUHMg YWxsIHN0cnVuZyB0b2dldGhlciBvbiB0aGUgc2FtZSBMQU4uIEFuZCBnaXZlbg0KaG93IHVuaXZl cnNhbGx5IGJhZCBob3RlbCBhbmQgY29uZmVyZW5jZSBjZW50ZXIgbmV0d29ya3MgdXN1YWxseSBh cmUsIEnigJltDQpza2VwdGljYWwgdGhhdCBldmVuIHRob3NlIG5ldHdvcmtzIGFyZSBjb25zaXN0 ZW50bHkgdXNpbmcgYSBtb2Rlcm4NCmNvbnRyb2xsZXIsIG9yIGlmIHRoZXkgYXJlLCBpdOKAmXMg bm90IHNldCB1cCBwYXJ0aWN1bGFybHkgd2VsbC4gSSBkb27igJl0DQprbm93IGZvciBzdXJlIHdo ZXRoZXIgREhDUHY0IGFuZCByZWxhdGVkIElQdjQganVuayB0cmFmZmljIGNvbnN0aXR1dGVzDQph bnl0aGluZyBtb3JlIHRoYW4gYSB0cml2aWFsIGFtb3VudCBvZiBhZGRpdGlvbmFsIGxvYWQgb24g dGhlIFJGIGlmIHdlDQphc3N1bWUgdGhhdCB0aGUgbmV0d29yayBpcyBsZXNzIHRoYW4gYSBjZXJ0 YWluIHNpemUsIGJ1dCBteSB0aG91Z2h0IHdhcw0KdGhhdCBhbnl0aGluZyB0aGF0IGNvbnRyaWJ1 dGVzIGV4dHJhIHRyYWZmaWMgb24gYSBuZXR3b3JrIHRoYXQgaXMgYWxyZWFkeQ0Kb3ZlcmxvYWRl ZCBhbmQgcGVyZm9ybWluZyBwb29ybHkgaXMgc29tZXRoaW5nIHRoYXQgc2hvdWxkIGJlIHJlbW92 ZWQgaWYNCnJlYXNvbmFibHkgcG9zc2libGUuIFNvIEkgbG9vayBhdCBpdCBhcyBhbiBvcHBvcnR1 bml0eSBmb3Igb3B0aW1pemF0aW9uIGlmDQp3ZSBjYW4gY29tZSB1cCB3aXRoIGEgd2F5IHRvIGRv IGl0IHRoYXQgaXMgd29ydGggdGhlIHRyYWRlb2ZmcyBhbmQNCnJlbGF0aXZlbHkgdHJhbnNwYXJl bnQgdG8gbmV0d29yayBvcGVyYXRvcnMgYW5kIHVzZXJzLg0KDQpUaGFua3MsDQoNCldlcyBHZW9y Z2UNCg0KQW55dGhpbmcgYmVsb3cgdGhpcyBsaW5lIGhhcyBiZWVuIGFkZGVkIGJ5IG15IGNvbXBh bnnigJlzIG1haWwgc2VydmVyLCBJDQpoYXZlIG5vIGNvbnRyb2wgb3ZlciBpdC4NCi0tLS0tLS0t LS0tDQoNCg0KDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29u dGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMg cHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdp bmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseSBm b3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRk cmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1t YWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0 cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29u dGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hp Yml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1h aWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVy bWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwg YW5kIGFueSBwcmludG91dC4NCg== From nobody Thu Apr 17 06:10: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 106B11A0168 for ; Thu, 17 Apr 2014 06:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.123 X-Spam-Level: X-Spam-Status: No, score=-4.123 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.272, 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 P0YISD5g2jE4 for ; Thu, 17 Apr 2014 06:09:45 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 910791A0166 for ; Thu, 17 Apr 2014 06:09:45 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CD783A1; Thu, 17 Apr 2014 15:09:40 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id C4B779A; Thu, 17 Apr 2014 15:09:40 +0200 (CEST) Date: Thu, 17 Apr 2014 15:09:40 +0200 (CEST) From: Mikael Abrahamsson To: Owen DeLong In-Reply-To: <4EABCE38-7CBA-4C95-84EE-686A2300F26E@delong.com> Message-ID: References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> <4EABCE38-7CBA-4C95-84EE-686A2300F26E@delong.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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/PQRmOQcQWWK9J8MTtHRJTN16NB0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 17 Apr 2014 13:09:51 -0000 On Thu, 17 Apr 2014, Owen DeLong wrote: > Providing a mechanism for an IPv6 LAN to shut down the IPv4 mobile > network on a device which is unlikely to be enterprise controlled is not > a solution in the real world, but only an attack vector. One could imagine that the signal is authenticated, for instance by SEND. The user can choose to trust these kinds of signals the same way they enter SSIDs to connect to automatically. As I said before, this is all about policy. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Apr 17 06: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 36B721A0192 for ; Thu, 17 Apr 2014 06:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 N_SlMdTgduON for ; Thu, 17 Apr 2014 06:51:20 -0700 (PDT) Received: from smtpauth2.wiscmail.wisc.edu (wmauth2.doit.wisc.edu [144.92.197.222]) by ietfa.amsl.com (Postfix) with ESMTP id 765561A018F for ; Thu, 17 Apr 2014 06:51:20 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-disposition: inline Content-type: text/plain; charset=utf-8 Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0N4600B00H4G3H00@smtpauth2.wiscmail.wisc.edu> for v6ops@ietf.org; Thu, 17 Apr 2014 08:51:16 -0500 (CDT) X-Spam-PmxInfo: Server=avs-2, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.17.134220, SenderIP=0.0.0.0 Received: from ricotta.doit.wisc.edu (ricotta.doit.wisc.edu [144.92.67.161]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0N4600KRKH5EQX10@smtpauth2.wiscmail.wisc.edu>; Thu, 17 Apr 2014 08:51:16 -0500 (CDT) Date: Thu, 17 Apr 2014 08:51:14 -0500 From: "Dale W. Carder" To: "George, Wes" Message-id: <20140417135113.GD66237@ricotta.doit.wisc.edu> References: <534BF5A5.5010609@viagenie.ca> <20140415142103.GA50776@ricotta.doit.wisc.edu> <534D4D32.7080001@viagenie.ca> <489D13FBFA9B3E41812EA89F188F018E1AFE5ACB@xmb-rcd-x04.cisco.com> <20140416144528.GA62773@ricotta.doit.wisc.edu> In-reply-to: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ziuUZE1MeMDEDGSXtwkxD6tFX0k Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 17 Apr 2014 13:51:25 -0000 Thus spake George, Wes (wesley.george@twcable.com) on Thu, Apr 17, 2014 at 08:41:52AM -0400: > On 4/16/14, 10:45 AM, "Dale W. Carder" wrote: > > >Modern enterprise wireless controller > >networks are way, way more sophisticated than their wired counterparts > >due to the management of scarce RF time. So, I don't buy any argument > >in this draft that there is a problem in this direction. > > A fair point, but this extends beyond simply enterprise networks, and I’m > not willing to assume that all wireless networks will have a controller, > modern or otherwise. True enough. Maybe this could also be clarified in the problem scope of the draft. > There are plenty of small and midsize networks that > are simply one or more APs all strung together on the same LAN. > And given > how universally bad hotel and conference center networks usually are, Is this the Godwin's law's for networking? ;-) While dhcpv4 behavior could contribute to the chaos and potentially could be cleaned up, there's obviously a lot more going on that makes these networks perform poorly. Included in this is that there are also many more multicast protocols running for service discovery and sharing that are far more chatty and probably present a far larger problem in rf airtime. > So I look at it as an opportunity for optimization if > we can come up with a way to do it that is worth the tradeoffs and > relatively transparent to network operators and users. What if rfc2131's transmission delay was changed from SHOULD to MUST? (Section 4.1 par. 7). What if the maximum was set higher than 64 seconds? Would that alleviate the concerns? This is where the problem scope in the draft certainly could be clearer, as to whether we are talking about making dhcp more friendly in the absence of v4 connectivity (which may certainly be a good idea), or if we are talking about the kill switch (which has a lot of problems still). Dale From nobody Thu Apr 17 07:01: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 E77E31A02E7 for ; Thu, 17 Apr 2014 07:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 gPZlXj6Z_HFs for ; Thu, 17 Apr 2014 07:01:52 -0700 (PDT) Received: from smtpauth2.wiscmail.wisc.edu (wmauth2.doit.wisc.edu [144.92.197.222]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4751A0171 for ; Thu, 17 Apr 2014 07:01:51 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-disposition: inline Content-type: text/plain; charset=utf-8 Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0N4600B00H4G3H00@smtpauth2.wiscmail.wisc.edu> for v6ops@ietf.org; Thu, 17 Apr 2014 09:01:48 -0500 (CDT) X-Spam-PmxInfo: Server=avs-2, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.17.135119, SenderIP=0.0.0.0 Received: from ricotta.doit.wisc.edu (ricotta.doit.wisc.edu [144.92.67.161]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0N4600K6GHMYQX20@smtpauth2.wiscmail.wisc.edu>; Thu, 17 Apr 2014 09:01:48 -0500 (CDT) Date: Thu, 17 Apr 2014 09:01:46 -0500 From: "Dale W. Carder" To: "George, Wes" Message-id: <20140417140145.GF66237@ricotta.doit.wisc.edu> References: <534BF5A5.5010609@viagenie.ca> <20140415142103.GA50776@ricotta.doit.wisc.edu> <534D4D32.7080001@viagenie.ca> <489D13FBFA9B3E41812EA89F188F018E1AFE5ACB@xmb-rcd-x04.cisco.com> <20140416144528.GA62773@ricotta.doit.wisc.edu> In-reply-to: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/vSml6svTzllZnIh1l0GaA7SRnVI Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 17 Apr 2014 14:01:57 -0000 Thus spake George, Wes (wesley.george@twcable.com) on Thu, Apr 17, 2014 at 08:41:52AM -0400: > On 4/16/14, 10:45 AM, "Dale W. Carder" wrote: > > >Modern enterprise wireless controller > >networks are way, way more sophisticated than their wired counterparts > >due to the management of scarce RF time. So, I don't buy any argument > >in this draft that there is a problem in this direction. > > A fair point, but this extends beyond simply enterprise networks, and I’m > not willing to assume that all wireless networks will have a controller, > modern or otherwise. There are plenty of small and midsize networks that > are simply one or more APs all strung together on the same LAN. It's also worth pointing out that these will be the same networks that will be significantly vulnerable to the attack vector opened up by this draft. If they are not filtering packets for RF performance, I would fear that they are not filtering for rogue dhcp packets either. Dale From nobody Thu Apr 17 07:43: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 7376C1A01CB for ; Thu, 17 Apr 2014 07:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 btU1K6QuX_aw for ; Thu, 17 Apr 2014 07:43:34 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 42E321A01C7 for ; Thu, 17 Apr 2014 07:43:34 -0700 (PDT) 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 BDBD61B81D7 for ; Thu, 17 Apr 2014 07:43:30 -0700 (PDT) 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 A383119005C; Thu, 17 Apr 2014 07:43:30 -0700 (PDT) Received: from [192.168.146.119] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 17 Apr 2014 07:43:30 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <534F96F7.3030806@globis.net> Date: Thu, 17 Apr 2014 09:43:28 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <4F57E302-AC0B-49AB-BBA5-8E1F3DD831F4@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> <534F96F7.3030806@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/au7QtwPllahyTB99xPnhPoY-Hts Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 17 Apr 2014 14:43:38 -0000 On Apr 17, 2014, at 3:55 AM, Ray Hunter wrote: > Although as I've pointed out earlier, there could be serious race = conditions here (RA/DHCPv6 IPv4 shutdown packet of death arrives before = AD authentication). In an enterprise network, if you aren't filtering rogue RAs, you = probably need to hire a new network administrator. But yeah, that's = definitely an issue that should be covered in the security = considerations section. From nobody Thu Apr 17 07:46: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 DD22A1A01E3 for ; Thu, 17 Apr 2014 07:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 1Sn4MF6hx06G for ; Thu, 17 Apr 2014 07:46:05 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 7584B1A01E1 for ; Thu, 17 Apr 2014 07:46:05 -0700 (PDT) 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 31B941B8034 for ; Thu, 17 Apr 2014 07:46:02 -0700 (PDT) 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 20B4B19005C; Thu, 17 Apr 2014 07:46:02 -0700 (PDT) Received: from [192.168.146.119] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 17 Apr 2014 07:46:01 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: Date: Thu, 17 Apr 2014 09:46:00 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <8D4A6D5D-10FF-43BE-82C2-23E8D72BA3A2@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> <534F96F7.3030806@globis.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1XJs-rFJR_Wbthyw6M6q0rP7Sdc Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 17 Apr 2014 14:46:07 -0000 On Apr 17, 2014, at 6:02 AM, Lorenzo Colitti wrote: > Hard to tell since we're well past 200 messages at this point, but I = think the solutions to this scenario that are being proposed are "put a = legitimate IPv6 router to your network" (i.e., enable IPv6 on it) and = "enable IPv6 RA guard + DHCPv6 guard on your network or block ethertype = 0x86dd". All of those will require hardware upgrades in some networks. No, the solution was a bit more detailed than that, and did not involve = RA guard. You should probably wait for the next version of the draft = and re-evaluate. From nobody Thu Apr 17 07: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 0278B1A01EA for ; Thu, 17 Apr 2014 07:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 XpNs_tTBHMn7 for ; Thu, 17 Apr 2014 07:48:29 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id BE3DE1A00D1 for ; Thu, 17 Apr 2014 07:48:29 -0700 (PDT) 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 6954A1B807A for ; Thu, 17 Apr 2014 07:48:26 -0700 (PDT) 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 5F29319005C; Thu, 17 Apr 2014 07:48:26 -0700 (PDT) Received: from [192.168.146.119] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 17 Apr 2014 07:48:26 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <4EABCE38-7CBA-4C95-84EE-686A2300F26E@delong.com> Date: Thu, 17 Apr 2014 09:48:24 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <8E450CDC-FFC5-4649-89FE-387836C8E40B@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> <4EABCE38-7CBA-4C95-84EE-686A2300F26E@delong.com> To: Owen DeLong X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1nuvZ27Qg-yytdFbYN8hSbih18k Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 17 Apr 2014 14:48:34 -0000 On Apr 17, 2014, at 6:56 AM, Owen DeLong wrote: > Providing a mechanism for an IPv6 LAN to shut down the IPv4 mobile = network on a device which is unlikely to be enterprise controlled is not = a solution in the real world, but only an attack vector. We are in full agreement on this point. It has to be up to the device = what it does with whatever configuration information the network = supplies, and I would not expect a device to take advice from one = network about how to operate on another. You could imagine exceptions = to this, but I think all of them would be equally well addressed by = individually updating each device, so there's no reason to have a = protocol for doing it. From nobody Thu Apr 17 07:57: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 8197E1A013A for ; Thu, 17 Apr 2014 07:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 qfoZ-9SIHEoR for ; Thu, 17 Apr 2014 07:57:39 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 326341A00C2 for ; Thu, 17 Apr 2014 07:57:39 -0700 (PDT) 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 D32811B807A for ; Thu, 17 Apr 2014 07:57:35 -0700 (PDT) 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 C824319005C; Thu, 17 Apr 2014 07:57:35 -0700 (PDT) Received: from [192.168.146.119] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 17 Apr 2014 07:57:35 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <534FC59B.201@foobar.org> Date: Thu, 17 Apr 2014 09:57:34 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <1BE293BD-3191-4622-AACA-E9E3689400EB@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <534EAB83.1070906@foobar.org> <70739713-281A-41E6-93ED-5EE1BC4B7FAB@nominum.com> <534EC1DB.4010902@foobar.org> <575F73AC-8DA5-4E04-B2CF-4875B729C7D3@nominum.com> <534FC59B.201@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/knh2xHrEgn6IUoOH7hjhm67fOXE Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 17 Apr 2014 14:57:43 -0000 On Apr 17, 2014, at 7:14 AM, Nick Hilliard wrote: > =46rom what I can see, there was no initial justification to use v6 = transport > other than a declarative "it shall be so!" pronouncement, and in this > situation it is reasonable to question this decision in v6ops, = particularly > as it will cause operational problems as outlined by a bunch of = people. Sure, it's reasonable to question the decision, and the working group = did ask for feedback, so there's nothing wrong with providing feedback. = However, my point is that v6ops doesn't get any special veto power over = this if you don't raise substantive objections. > Several of the issues raised about this on v6ops were not opinions, = e.g. > Ray Hunter's list of concerns in his email of 2014-04-14 22:21:01 = +0200, > most of which were based on the technical reality that implementing = this > option in dhcpv6/ra instead of dhcpv4 will create interpretation+state > problems and unavoidable race conditions. Disappointingly, there was = no > follow-up on that email. Similarly the comments in my email of april = 15, > 23:16:52 +0100 were ignored. It's not an opinion that implementing the current proposal using the = current network configuration framework on a typical Linux box is = difficult and potentially brittle. I agree that this is the case. I = also agree that it's easier to implement this as a DHCPv4 option. But = the question is not "is it easier to implement" but "is it better." = The authors of the draft thought about it, wrote drafts documenting = various solutions, and came up with "no, it's better to do it over = IPv6." What I am characterizing as opinion is "this is hard to do on Linux, = therefore we should do it this other way." It's true that it's hard to = do on Linux, for certain values of Linux, but the connection between = that and "we should do it this other way" is opinion. This is = compounded by the fact that there are already other configuration = interdependencies that are handled poorly by the same Linux = configuration framework we are talking about, and consequently work is = being done to come up with a more robust framework. I've mentioned = this, but the response was to ignore that point and continue to assert = "this is hard on Linux." Which is why I tend to see this as "opinion" = rather than "technical objection." >> I'd be just as happy if the conclusion of the process was "just >> filter IPv4 at the access points if you want it to go away," and I'd >> like to see more discussion on that topic. >=20 > this is also a valid concern. I can see no reason why anyone would = heed an > unauthenticated signal to entirely shut down all ipv4 services o/s = wide on > their ipv4-enabled client (or even no-ipv4 options 1-2 for that = matter), > when we already have the existing option for operators to fully = satisfy all > aims of this draft by declining to forward ethertypes 0x0800 and = 0x0806. > Simple and enforceable are both good engineering principals to aspire = to. > Complex+advisory+piles of failure modes+controversial need a much = greater > level of justification, which is notably absent from this draft. Noted. I think it would be good to have text in the document that = explains why this isn't the proposed solution, so that it can be = evaluated on the merits and we don't have to speculate. From nobody Thu Apr 17 09:30: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 EF9C71A021A for ; Thu, 17 Apr 2014 09:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 z_0Wtpz1MIfR for ; Thu, 17 Apr 2014 09:30:36 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 523DB1A01FE for ; Thu, 17 Apr 2014 09:30:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id A33D5870074; Thu, 17 Apr 2014 18:30:31 +0200 (CEST) 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 7SEkbcBTczHk; Thu, 17 Apr 2014 18:30:31 +0200 (CEST) Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:5de4:4a3d:6627:bbc9]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 57CD587006F; Thu, 17 Apr 2014 18:30:31 +0200 (CEST) Message-ID: <535001A5.1000409@globis.net> Date: Thu, 17 Apr 2014 18:30:29 +0200 From: Ray Hunter User-Agent: Postbox 3.0.9 (Macintosh/20140129) MIME-Version: 1.0 To: Ted Lemon References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> <534F96F7.3030806@globis.net> <4F57E302-AC0B-49AB-BBA5-8E1F3DD831F4@nominum.com> In-Reply-To: <4F57E302-AC0B-49AB-BBA5-8E1F3DD831F4@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/80rbQEWkKlF7oaJjA9iG4zbai3Y Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 17 Apr 2014 16:30:38 -0000 > Ted Lemon > 17 April 2014 16:43 > > In an enterprise network, if you aren't filtering rogue RAs, you > probably need to hire a new network administrator. But yeah, that's > definitely an issue that should be covered in the security > considerations section. > Lorenzo said it already: the impact is potentially much more serious. If you've left IPv6 enabled on end nodes, but given IPv4 absolute priority in the permanent copy of the RFC6724 address selection rules table, any IPv6 addressing and routing would only become active when connected to an IPv6 only environment. If you've not (correctly) taken heed of RFC6104 (and a lot of people haven't), any rogue RA would probably only be a temporary annoyance to IPv4 which anyway goes away automatically with the rogue RA. Same is true for nodes implementing Happy Eyeballs RFC6555. If you had a complete protocol shutdown due to draft-ietf-sunset4-noipv4-00 (assuming the proposed flag is carried in a rogue RA) you may need a helpdesk call, a site visit, or access to an out of band console to be able to restart your machines. How would most mere mortals find a rogue RA (process) that only sends a handful of packets per week/month and where the purpose of the packet is obfuscated with headers? RFC7113 was only published in February 2014. Potential Ping of Death all over again. > Ray Hunter > 17 April 2014 10:55 > > > Mikael Abrahamsson wrote: >> On Wed, 16 Apr 2014, Dale W. Carder wrote: >> >>> So, I am not in favor of adding more hints that may or may not >>> observed that result in additional complexity and create an even >>> more diverse set of behavior that has to be managed. This is why I >>> think the only real solution that would work in practice is >>> ethertype filtering. > +1 >> >> That still doesn't solve the problem of the enterprise network being >> IPv6 only but publishes A and AAAA entries for internal resources on >> the internal DNS zone, because other networks they have are dual stack. >> >> Otoh I think this would be better solved by implementing MIF >> functionality in the device but... oh well. >> > Enterprise networks will use alternative protocols/methods to > configure their end nodes IMHO e.g. Active Directory > > And we have https://tools.ietf.org/html/rfc7078 for cases where some > LANs are IPv4 only, some are dual stack, and others are IPv6 only > (assuming anyone implements it) > > I'm hoping that a node connected to an authenticated AD server will by > default ignore any unauthenticated configuration hints purportedly > sent via a DHCPv6 server. > > Although as I've pointed out earlier, there could be serious race > conditions here (RA/DHCPv6 IPv4 shutdown packet of death arrives > before AD authentication). > > ------------------------------------------------------------------------ -- Regards, RayH From nobody Thu Apr 17 09:54: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 1EBD61A01D3 for ; Thu, 17 Apr 2014 09:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 C8V7mJq-XOxF for ; Thu, 17 Apr 2014 09:54:52 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 386431A0194 for ; Thu, 17 Apr 2014 09:54:51 -0700 (PDT) Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 96752629CD for ; Thu, 17 Apr 2014 18:54:47 +0200 (CEST) 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 5814F629C2 for ; Thu, 17 Apr 2014 18:54:47 +0200 (CEST) Received: (qmail 14108 invoked by uid 1007); 17 Apr 2014 18:54:47 +0200 Date: Thu, 17 Apr 2014 18:54:47 +0200 From: Gert Doering To: Ted Lemon Message-ID: <20140417165447.GA43641@Space.Net> References: <534EAB83.1070906@foobar.org> <70739713-281A-41E6-93ED-5EE1BC4B7FAB@nominum.com> <534EC1DB.4010902@foobar.org> <575F73AC-8DA5-4E04-B2CF-4875B729C7D3@nominum.com> <534FC59B.201@foobar.org> <1BE293BD-3191-4622-AACA-E9E3689400EB@nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1BE293BD-3191-4622-AACA-E9E3689400EB@nominum.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/USC2f5QSPeYvv0hh54QeDO5bmFA Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 17 Apr 2014 16:54:54 -0000 Hi, On Thu, Apr 17, 2014 at 09:57:34AM -0500, Ted Lemon wrote: > However, my point is that v6ops doesn't get any special veto power over this if you don't raise substantive objections. It will be interesting to see IETF last call on this, if there is significant objection being ignored "because it's from the wrong WG". (Besides this, I've long stopped caring about this thread. There's way too much religion in here) 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 nobody Thu Apr 17 09:55: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 70E1E1A02C4 for ; Thu, 17 Apr 2014 09:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 WzzcDeG6ZiMi for ; Thu, 17 Apr 2014 09:55:42 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id CF0C91A0180 for ; Thu, 17 Apr 2014 09:55:42 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:349d:fe5f:bc57:89]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 170D44039D for ; Thu, 17 Apr 2014 12:55:39 -0400 (EDT) Message-ID: <5350078A.2080002@viagenie.ca> Date: Thu, 17 Apr 2014 12:55:38 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <534EAB83.1070906@foobar.org> <70739713-281A-41E6-93ED-5EE1BC4B7FAB@nominum.com> <534EC1DB.4010902@foobar.org> <575F73AC-8DA5-4E04-B2CF-4875B729C7D3@nominum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/EyvNt2sCRuOJOKGqd96W3ETUVEU Subject: Re: [v6ops] Please review the No IPv4 draft 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, 17 Apr 2014 16:55:47 -0000 Le 2014-04-16 21:40, Lorenzo Colitti a écrit : > Example: one thing that argues in favour of a DHCPv4 option is that on > current IPv4-only networks, it can be very easy to send out a rogue RA > or install a rogue DHCPv6 server, because IPv6 security features like RA > guard or DHCPv6 filtering are likely not in place. The impact of such an > attack on current hosts is severe, because it allows attackers to > blackhole packets, but at least hosts that implement happy eyeballs can > defend against that sort of attack. This option makes it much worse: if > a rogue RA sender or rogue DHCPv6 server sends out a "kill IPv4" option, > then the hosts are dead in the water. > > There is no mention of this in the document. Because nobody mentioned it before. :) Will be added to section "4.1. DHCPv6 vs DHCPv4" in the next revision. Thanks, 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 nobody Thu Apr 17 09:57: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 117A61A0180 for ; Thu, 17 Apr 2014 09:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 qha6aTFTisbf for ; Thu, 17 Apr 2014 09:57:45 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id C74BC1A01A0 for ; Thu, 17 Apr 2014 09:57:45 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:349d:fe5f:bc57:89]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1BF624039D for ; Thu, 17 Apr 2014 12:57:42 -0400 (EDT) Message-ID: <53500805.3000308@viagenie.ca> Date: Thu, 17 Apr 2014 12:57:41 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/c8OdSB1SpyjfRCD6CvQ7G5O5-Oo Subject: Re: [v6ops] Please review the No IPv4 draft 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, 17 Apr 2014 16:57:51 -0000 Le 2014-04-16 17:16, Owen DeLong a écrit : > A host which doesn’t have a v4 route to reach a given A record should ignore said A record pretty harmlessly in favor of the AAAA record. A host that does otherwise is a broken host. Welcome to the real world, where hosts are broken and routes don't matter. 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 nobody Thu Apr 17 10:05: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 9E2521A0322 for ; Thu, 17 Apr 2014 10:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 EdiTMY5VNfaw for ; Thu, 17 Apr 2014 10:04:58 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D6BF31A0313 for ; Thu, 17 Apr 2014 10:04:57 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:349d:fe5f:bc57:89]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 28F0F4039D for ; Thu, 17 Apr 2014 13:04:54 -0400 (EDT) Message-ID: <535009B5.3000200@viagenie.ca> Date: Thu, 17 Apr 2014 13:04:53 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> <4EABCE38-7CBA-4C95-84EE-686A2300F26E@delong.com> In-Reply-To: <4EABCE38-7CBA-4C95-84EE-686A2300F26E@delong.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jChHU7nwoK6tm2ZPzMahxUQg1Co Subject: Re: [v6ops] Please review the No IPv4 draft 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, 17 Apr 2014 17:04:59 -0000 Le 2014-04-17 07:56, Owen DeLong a écrit : > Providing a mechanism for an IPv6 LAN to shut down the IPv4 mobile > network on a device which is unlikely to be enterprise controlled is > not a solution in the real world, but only an attack vector. The current draft doesn't allow this. Let me know if you find the text unclear on this point. 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 nobody Thu Apr 17 17:31: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 4532C1A011D for ; Thu, 17 Apr 2014 17:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 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.272, 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 GKgWZZLDwFOf for ; Thu, 17 Apr 2014 17:31:39 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 22BCA1A018F for ; Thu, 17 Apr 2014 17:31:39 -0700 (PDT) Received: by mail-ig0-f176.google.com with SMTP id uy17so192984igb.3 for ; Thu, 17 Apr 2014 17:31:35 -0700 (PDT) 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=ba6U/AFLyV8CaeL3pRDyvwg8fOWz/gmP3EJyN8823B4=; b=frRzZdR+2fuq8aWEydrjKVW1k4ceYDqdyUztVd52z7lGBW6Si4hKmBmo+P4EhgLf2t h3U7OSxr0e41JjAfI6PEgFTRF+2mBtyOAjvWAwNWug1E1MaTX/zM4r9PFgaaiJXkGWb5 nWAcNlClHKW/39iye06ULUAH0DmJhbbOp1vIeOCyexHdFbRaEVk6iyORqWG/9OGBtgOh KK2vJMRccYmpK1RrErZUz6/7q/RxpbH28a1GLsnEzLC6QsOcNJrwKzmAf34JpbHCn8KX LKFBkylBVDQ3XPnxGxSO2Ek8T6ToWif4PTS9lS9rSAYb4qLuA5oBwdvrL6XYLk/2BS/7 4lsg== 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=ba6U/AFLyV8CaeL3pRDyvwg8fOWz/gmP3EJyN8823B4=; b=kMiG05sOkDLTE2UajChRJ6nU5R5Mx3tugLA6vfAdaIEtDbBLN2z3QXH6d9OPLbk4ii RUy8zdObqPs/4CGWBqWKkAVqDBu6f1VQvnnIgsOndkBocJH/57KKcOb7qf7pvVo2HlrY 28XWVGboVWH1kTABANlhpZacMs40n0/07PrU4E/7UFtR7M+b2JuM3I1xMoEj2YlJW57t 4N9dygFChvkAD7o3DqY15m7sc/XAntzZNqumx11bJyOFs82HAcnu+DzqaI+Pi7Yio/fx 9ZYCKq9AoHtO3MmfPWJgfOfdtoJDBfxa7OtkULtFZUswZBvpTdeKBkW/q1mtbNj77gOO RbyA== X-Gm-Message-State: ALoCoQlSAJ0m3Rn6h+1RM9yQE5qIv/2AoEGTm4vKBOV5optoUNLHAvxKxEB+uO/xcyFDGzFngU4mb7iAzr+FBMLq7Ror0k3fOA9ucOMOuBSOU9+ob/ADajgPuA5/MGpAABD3MbtC1PNSdfoEpNPmPm08G95TbpQh9xRbpnEZ1f4fqDlRLErkxY0bFvM2FzawhZQqDlBe6lWr X-Received: by 10.42.23.82 with SMTP id r18mr12486120icb.43.1397781095263; Thu, 17 Apr 2014 17:31:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.136 with HTTP; Thu, 17 Apr 2014 17:31:15 -0700 (PDT) In-Reply-To: <8D4A6D5D-10FF-43BE-82C2-23E8D72BA3A2@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> <534F96F7.3030806@globis.net> <8D4A6D5D-10FF-43BE-82C2-23E8D72BA3A2@nominum.com> From: Lorenzo Colitti Date: Fri, 18 Apr 2014 09:31:15 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=20cf301d3edca8a38904f746459b Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/9cn0sXB250vlXxN5wO8FBocC0UM Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 18 Apr 2014 00:31:43 -0000 --20cf301d3edca8a38904f746459b Content-Type: text/plain; charset=UTF-8 On Thu, Apr 17, 2014 at 11:46 PM, Ted Lemon wrote: > > Hard to tell since we're well past 200 messages at this point, but I > think the solutions to this scenario that are being proposed are "put a > legitimate IPv6 router to your network" (i.e., enable IPv6 on it) and > "enable IPv6 RA guard + DHCPv6 guard on your network or block ethertype > 0x86dd". All of those will require hardware upgrades in some networks. > > No, the solution was a bit more detailed than that, and did not involve RA > guard. You should probably wait for the next version of the draft and > re-evaluate. > But will the solution address this issue? If not, then there's no point waiting for a new version of the draft, right? You agree that if this is not addressed, it's a substantial reason not to put this option in IPv6 provisioning protocols? --20cf301d3edca8a38904f746459b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On T= hu, Apr 17, 2014 at 11:46 PM, Ted Lemon <ted.lemon@nominum.com>= wrote:
    > Hard to tell since we're well = past 200 messages at this point, but I think the solutions to this scenario= that are being proposed are "put a legitimate IPv6 router to your net= work" (i.e., enable IPv6 on it) and "enable IPv6 RA guard + DHCPv= 6 guard on your network or block ethertype 0x86dd". All of those will = require hardware upgrades in some networks.

    No, the solution was a bit more detailed than that, and did not invol= ve RA guard. =C2=A0 You should probably wait for the next version of the dr= aft and re-evaluate.

    But will the solut= ion address this issue? If not, then there's no point waiting for a new= version of the draft, right? You agree that if this is not addressed, it&#= 39;s a substantial reason not to put this option in IPv6 provisioning proto= cols?
    --20cf301d3edca8a38904f746459b-- From nobody Fri Apr 18 13:58: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 41DB01A01D3 for ; Fri, 18 Apr 2014 13:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.137 X-Spam-Level: X-Spam-Status: No, score=0.137 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.272, 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 47oOXRvqk2O5 for ; Fri, 18 Apr 2014 13:58:44 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id EBCBB1A02D8 for ; Fri, 18 Apr 2014 13:58:43 -0700 (PDT) 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 s3IKuQsO003722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 18 Apr 2014 13:56:26 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3IKuQsO003722 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1397854587; bh=29/QtnGkpipC4ZyCMCe1d157EEc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=D3C6yWHSUPlDKqm6enK8UWbymkmk7BJNY/Fb8mf78tmZaMTk5Jb+Y0w2ALMGjRG43 4ZCwP6J7qbYBQ9r2ueTh7j/TwsR2oCRZHGa19ctZWtaGryE83E4hEyrThjLNLYDYfF DoMu9gAuPLpktTEviNOiI3F0sv7oUODA9PAEMPZs= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Owen DeLong In-Reply-To: <1BE293BD-3191-4622-AACA-E9E3689400EB@nominum.com> Date: Fri, 18 Apr 2014 13:56:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <65F84234-90E7-47E2-A67C-B3DD38681830@delong.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <534EAB83.1070906@foobar.org> <70739713-281A-41E6-93ED-5EE1BC4B7FAB@nominum.com> <534EC1DB.4010902@foobar.org> <575F73AC-8DA5-4E04-B2CF-4875B729C7D3@nominum.com> <534FC59B.201@foobar.org> <1BE293BD-3191-4622-AACA-E9E3689400EB@nominum.com> To: Ted Lemon 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]); Fri, 18 Apr 2014 13:56:27 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qF8ST_TZrG2an6P5PCip2Iwx63k Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 18 Apr 2014 20:58:48 -0000 > The authors of the draft thought about it, wrote drafts documenting = various solutions, and came up with "no, it's better to do it over = IPv6." Which is strictly THEIR OPINION. An opinion which is apparently NOT = shared by many people on this list. > What I am characterizing as opinion is "this is hard to do on Linux, = therefore we should do it this other way." It's true that it's hard to = do on Linux, for certain values of Linux, but the connection between = that and "we should do it this other way" is opinion. This is = compounded by the fact that there are already other configuration = interdependencies that are handled poorly by the same Linux = configuration framework we are talking about, and consequently work is = being done to come up with a more robust framework. I've mentioned = this, but the response was to ignore that point and continue to assert = "this is hard on Linux." Which is why I tend to see this as "opinion" = rather than "technical objection." I don't believe that is a valid characterization of what was said. What was said was "This is a bad way to do it for a number of = reasons..." Beyond that, there was an "oh, by the way, it's also hard and brittle on = Linux". IMHO, this should be done in DHCPv4 or ICMPv4 (and the more I think = about it, the more I think ICMPv4) and NOT IPv6 because: 1. Principle of least surprise. IPv4 developers do not = expect to have to anticipate that things happening over IPv6 will affect the behavior of core IPv4 = services, nor should they. Most systems and network administrator have the same expectation. Configuring an IPv4 address over an IPv6 tunnel might be = an exception, but at least in that case, the operator is aware of the fact that they are trying to = tunnel IPv4 through IPv6 and that is likely to modify their general expectation. Shutting down IPv4 on command = issued over IPv6, OTOH, violates all kinds of expectations and is likely to result in significant = surprise in the operator community. 2. This feature could be implemented in IPv4 with little or = no IPv4 stack running on the implementing device in question (AP, Router, etc.), so the argument that it = requires an IPv4 stack to be preserved is somewhat specious. All that is needed is enough to detect an IPv4 = DHCPREQUEST (and/or BOOTPREQUEST) and respond with a preformed ICMP DHCP4UNAVAILABLE message. 3. A host could receive conflicting IPv6 and IPv4 messages = about what it is supposed to do about IPv4 configuration. You can argue that such behavior is a = broken network configuration, but the reality is that failing to consider this in real world scenarios has = undesirable operational effects and security implications. At the very least, behavior in the face of such an event = on the client side should be specified and deterministic. 4. The number of clients likely to be affected by this = change is much greater than the target space. Moving this to IPv4 would reduce the impact space to match the = target space. And Oh, by the way: While Linux is an example of a well modularized = operating system where IPv4 configuration is handled by completely separate mechanisms than IPv6 = configuration, it is likely not the only one. Implementation of this on any such modularized system is likely to = result in brittleness and unexpected consequences. >=20 >>> I'd be just as happy if the conclusion of the process was "just >>> filter IPv4 at the access points if you want it to go away," and I'd >>> like to see more discussion on that topic. >>=20 >> this is also a valid concern. I can see no reason why anyone would = heed an >> unauthenticated signal to entirely shut down all ipv4 services o/s = wide on >> their ipv4-enabled client (or even no-ipv4 options 1-2 for that = matter), >> when we already have the existing option for operators to fully = satisfy all >> aims of this draft by declining to forward ethertypes 0x0800 and = 0x0806. >> Simple and enforceable are both good engineering principals to aspire = to. >> Complex+advisory+piles of failure modes+controversial need a much = greater >> level of justification, which is notably absent from this draft. >=20 > Noted. I think it would be good to have text in the document that = explains why this isn't the proposed solution, so that it can be = evaluated on the merits and we don't have to speculate. I'd agree with that at the very least, though modifying the draft to = propose an ICMP4 DHCPUNAVAILABLE message and client behavior in the face = of receiving both that and a DHCPOFFER would be preferable IMHO. Owen From nobody Sat Apr 19 15:31: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 3C5681A00CF for ; Sat, 19 Apr 2014 15:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 Y4CzCwkHCM75 for ; Sat, 19 Apr 2014 15:30:57 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 18DD71A00C3 for ; Sat, 19 Apr 2014 15:30:56 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s3JMUnju049502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 19 Apr 2014 23:30:49 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <5352F918.4090908@foobar.org> Date: Sat, 19 Apr 2014 23:30:48 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ted Lemon References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <534EAB83.1070906@foobar.org> <70739713-281A-41E6-93ED-5EE1BC4B7FAB@nominum.com> <534EC1DB.4010902@foobar.org> <575F73AC-8DA5-4E04-B2CF-4875B729C7D3@nominum.com> <534FC59B.201@foobar.org> <1BE293BD-3191-4622-AACA-E9E3689400EB@nominum.com> In-Reply-To: <1BE293BD-3191-4622-AACA-E9E3689400EB@nominum.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mNKKzT3J2JW66G2HZF1531nEsTo Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 19 Apr 2014 22:30:59 -0000 On 17/04/2014 15:57, Ted Lemon wrote: > On Apr 17, 2014, at 7:14 AM, Nick Hilliard wrote: >> From what I can see, there was no initial justification to use v6 transport >> other than a declarative "it shall be so!" pronouncement, and in this >> situation it is reasonable to question this decision in v6ops, particularly >> as it will cause operational problems as outlined by a bunch of people. > > Sure, it's reasonable to question the decision, and the working group > did ask for feedback, so there's nothing wrong with providing feedback. > However, my point is that v6ops doesn't get any special veto power over > this if you don't raise substantive objections. the point people are raising is that there appears to be a considerable gap between your understanding of "substantive objections" and theirs. >> this is also a valid concern. I can see no reason why anyone would heed an >> unauthenticated signal to entirely shut down all ipv4 services o/s wide on >> their ipv4-enabled client (or even no-ipv4 options 1-2 for that matter), >> when we already have the existing option for operators to fully satisfy all >> aims of this draft by declining to forward ethertypes 0x0800 and 0x0806. >> Simple and enforceable are both good engineering principals to aspire to. >> Complex+advisory+piles of failure modes+controversial need a much greater >> level of justification, which is notably absent from this draft. > > Noted. I think it would be good to have text in the document that > explains why this isn't the proposed solution, so that it can be > evaluated on the merits and we don't have to speculate. As the draft demands that a single unauthenticated packet can shut down ipv4 services on a client device either completely (as specified in 5.3.3) or almost completely (5.3.2), both options will need a detailed security analysis to describe how packets of this form cannot be abused by either an malicious operator or by rogue packets caused by access domain misconfiguration. Also, given the extraordinary nature of these requirements, the justification for including them in an internet standards track document will need to be similarly extraordinary. Nick From nobody Sat Apr 19 21:38: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 E32AC1A0126 for ; Sat, 19 Apr 2014 21:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.312 X-Spam-Level: *** X-Spam-Status: No, score=3.312 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_REPLYTO=0.999, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 FJspLJrGKvYU for ; Sat, 19 Apr 2014 21:38:07 -0700 (PDT) Received: from nm41.bullet.mail.ne1.yahoo.com (nm41.bullet.mail.ne1.yahoo.com [98.138.120.48]) by ietfa.amsl.com (Postfix) with SMTP id B9F9F1A00FF for ; Sat, 19 Apr 2014 21:38:06 -0700 (PDT) Received: from [127.0.0.1] by nm41.bullet.mail.ne1.yahoo.com with NNFMP; 20 Apr 2014 04:38:02 -0000 Received: from [98.138.100.102] by nm41.bullet.mail.ne1.yahoo.com with NNFMP; 20 Apr 2014 04:35:03 -0000 Received: from [98.139.212.152] by tm101.bullet.mail.ne1.yahoo.com with NNFMP; 20 Apr 2014 04:35:03 -0000 Received: from [98.139.212.203] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 20 Apr 2014 04:35:03 -0000 Received: from [127.0.0.1] by omp1012.mail.bf1.yahoo.com with NNFMP; 20 Apr 2014 04:35:03 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 269357.85071.bm@omp1012.mail.bf1.yahoo.com Received: (qmail 25343 invoked by uid 60001); 20 Apr 2014 04:35:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1397968503; bh=hffOXDudBswcghXjcuLnZqYBSS10rHOMGh5nLpOurVE=; 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=FeHj133qzU3mSxnop9XrJ+oeqBROKJwX8dD/WhLiHyXtwXhoAtlDOXNUKPt0B/B+GFcTZGdOC4h8DSGkozTMoF6gYyKAoe6LEGsT+wvvy2wQtHusyU+bd91VyNQAFSSZ25+9mcP7v414OsV/s1DIrdMKIXZMvtxYAYDaweGt8bM= 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=yRJMT9JCd+6wnXbWj9nKtNBqOaWq5wWU9OAH/9u9OkoCW37Hrio6u7G24QBCSIqypHNmE8pltOLZi6Dh1x/nxJv95pdpjue7k/eKrGUoWDq1Udiv8b7S/IDPSfjnNNW5J5e7grasNWRb0Go8aRSqm3DChKhyy6fdNbfkkxqymQI=; X-YMail-OSG: Kd99jcMVM1lFrqFTPdQYxpsKJKF7MJMPDBeGo0Il7mfWKQ2 7GspKhjk4Id0jeykpUfhEOjaJLOtn0vMzvj4Pb.RSMDb330eXl9vTN15RhWf HjW8uqU4TOabSbpVSXyOTv1yfC775ZBdEofqI8FrIUzJ4lVWPGbE3U5XxuRJ Kqc7I9i4xpcHJUPzA.ZzOJeNiTg3vgOtmq9MQLk1VjR.xnZP1PYc2JOOMzuf HAXkXuRFAc8BZKtvy9JLigc91rhnmlzI6L3KZezBBaZ8jsjn13saoIL.zkT6 5SzXkXvH2ZooHSPrRfantwzuzcQipcq8m6jZ.Jgc0f_vnMYbWKWs2hh27GcY mjyeynLfTEIG5Lv_QkJMDhG.Mg5bqiLFH7m5K7EgUW.paR1pJ6n77NjJUBOt BXiX7kBsKuLWpNpvgg_P1xCorGbCgKC0XxvBEO2PBY666.U49MrpM6TkVbX7 rT25wJhARbBw67feYda_vvtkQZTJbNP3WuHTA3JAAIDDL4hNzghi0lW9KU9u 2iTQ2_5ggp0oqnI_l48sVIijQsSSpZW203ucziELU41OSboIkT.6wnqE9oN9 2p.NQPgXuevW6Sc82Ycwkwgo_mTbS1Mi36ep3iDiGKDEPYcvbNhXI4ciNHA- - Received: from [150.101.221.237] by web162203.mail.bf1.yahoo.com via HTTP; Sat, 19 Apr 2014 21:35:03 PDT X-Rocket-MIMEInfo: 002.001, SGkgRXJpYywKClRoYW5rcyBmb3IgeW91ciB0aW1lIGFuZCBjb21tZW50cy4KClNvIEkndmUgYmVlbiBkb2luZyBzb21lIGZ1cnRoZXIgaW52ZXN0aWdhdGlvbiBpbiB0byBob3N0IHN0YWNrIE1MRCBiZWhhdmlvdXIuIEkgaGF2ZW4ndCBmaW5pc2hlZCB0aGF0LCBob3dldmVyIEkgY2FuIGFkZHJlc3Mgc29tZSBwb2ludHMgYmVsb3csIHdoaWNoIGhhdmUgYWxzbyBiZWVuIHJhaXNlZCBieSBMb3JlbnpvLgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBFcmljIExldnktIEFiZWdub2xpICgBMAEBAQE- X-Mailer: YahooMailWebService/0.8.185.657 References: <1396905670.42588.YahooMailNeo@web162205.mail.bf1.yahoo.com> Message-ID: <1397968503.65061.YahooMailNeo@web162203.mail.bf1.yahoo.com> Date: Sat, 19 Apr 2014 21:35:03 -0700 (PDT) From: Mark ZZZ Smith To: "Eric Levy- Abegnoli \(elevyabe\)" , V6 Ops List In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/EeMgOLYLL880Vg_-3FlWGfMUslg Subject: Re: [v6ops] Fw: New Version Notification for draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.txt 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, 20 Apr 2014 04:38:11 -0000 Hi Eric,=0A=0AThanks for your time and comments.=0A=0ASo I've been doing so= me further investigation in to host stack MLD behaviour. I haven't finished= that, however I can address some points below, which have also been raised= by Lorenzo.=0A=0A=0A----- Original Message -----=0A> From: Eric Levy- Abeg= noli (elevyabe) =0A> To: Mark ZZZ Smith ; V6 Ops List =0A> Cc: =0A> Sent: Thursday, 17 = April 2014 2:24 AM=0A> Subject: Re: [v6ops] Fw: New Version Notification fo= r draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.txt=0A> =0A> Hi, =0A= > I took a look at the draft, and found it "protocolly" interesting but=0A>= "operationally" flawed.=0A> - some host stacks (last time I checked was a = few years ago, so hopefully=0A> that has changed) don't bother sending the = MLD join for solicited-node=0A> groups, mainly because it's not very releva= nt.=0A=0ALinux (Fedora 20) does and probably that means Android does. I'm r= unning up some Windows VMs to see what that does (http://www.modern.ie/ for= a legal variety of them).=0A=0AApart from being required by RFC2710 and RF= C4862, hosts have an interest in sending these so that MLD snooping layer 2= devices can suppress unwanted multicasts to them.=0A=0AIf it was quite a w= hile ago, then perhaps these hosts were IPv6 implementations that existed b= efore MLDv1/RFC2710, as RFC2710 introduced the requirement to join the Soli= cited-Node multicast groups.=0A=0A=0AOne broader question I have is how muc= h tolerance for lack of features in implementations is necessary? RFC2710 w= as published in 1999, and the IPv6 Node Requirements RFC from 2006 made MLD= a requirement. Implementations before RFC2710 aren't going to support off-= link sourced multicast applications, because they can't tell a router they = want to join multicast groups.=0A=0A> Currently, stacks don't=0A=0A> bother= storing mld state received in join, for any link-local scope mc,=0A> and s= imply forward multicast regardless (I understand that the draft is=0A> sugg= esting to make them relevant, but the amount of router-to-network=0A> inter= actions is not worth the value in my opinion).=A0 And the fact that so=0A> = far, these states were useless make me think there are not generally=0A> av= ailable.=0A> =0A> - When the MLD join is sent, it is sent once, when link g= oes up.=0A=0A=0AFirstly, note that from the perspective of MLDv1/MLDv2, the= re is nothing special about Solicited-Node multicast groups. So the standar= d MLDv1/MLDv2 join etc. procedures apply.=0A=0AIn the case of RFC2710/MLDv1= it is recommended to send more than one:=0A=0A" =A0When a node starts list= ening to a multicast address on an interface,=0A=A0 =A0it should immediatel= y transmit an unsolicited Report for that address=0A=A0 =A0on that interfac= e, in case it is the first listener on the link. To=0A=A0 =A0cover the pos= sibility of the initial Report being lost or damaged, it=0A=A0 =A0is recomm= ended that it be repeated once or twice after short delays=0A=A0 =A0[Unsoli= cited Report Interval]. (A simple way to accomplish this is=0A=A0 =A0to se= nd the initial Report and then act as if a Multicast-Address-=0A=A0 =A0Spec= ific Query was received for that address, and set a timer=0A=A0 =A0appropri= ately)."=0A=0AIn the case of MLDv2, they explicitly made sending at least t= wo MLD state change reports a requirement:=0A=0A" =A0As opposed to Current = State Reports, State Change Reports are=0A=A0 =A0retransmitted several time= s, in order to avoid them being missed by=0A=A0 =A0one or more multicast ro= uters. The number of retransmissions depends=0A=A0 =A0on the so-called Rob= ustness Variable. This variable allows tuning=0A=A0 =A0the protocol accord= ing to the expected packet loss on a link. If a=0A=A0 =A0link is expected = to be lossy (e.g., a wireless connection), the value=0A=A0 =A0of the Robust= ness Variable may be increased. MLD is robust to=0A=A0 =A0[Robustness Vari= able]-1 packet losses. This document recommends a=0A=A0 =A0default value o= f 2 for the Robustness Variable (see section 9.1)."=0A=0A=0A> It's easy=0A>= to miss it for the router, for many reasons (split network, no retry,=0A> = reboot, etc.). The router could send a periodic MLD query,=0A=0AThat is wha= t the designated querier multicast router does to track the continued exist= ence of multicast group presence on a link. Solicited-Node multicast group = membership is reported in response to these queries.=0A=0AThese queries are= sent approximately once every 2 minutes respectively by MLD or MLDv2. That= would too long to wait to discover Solicited-Node membership for a new dev= ice if the initial reports had been lost. It's tempting to suggest setting = this interval to something much lower e.g. 3 to 5 seconds, however that is = really trying to make up for the lack of reliability of implementations tha= t haven't either followed the recommendations in MLDv1 or the requirements = in MLDv2 for group joins. While I think tolerating faulty or unreliable imp= lementations is generally a good thing, I always wonder how far to go befor= e saying, "the implementation is too broken, can't be supported."=0A=0A=0A>= but that would=0A> generate quite a bit of overhead, and I suspect that wh= ile some host=0A> stacks still bother sending the mld report on link-up, th= ey might not=0A> bother sending then on mld-query (I don't know that for a = fact).=0A> Bottom line, the router is not likely to have an accurate table = at any=0A> given time of all listeners (even if it polls, can't do it too o= ften for=0A> obvious scalability reasons).=0A=0AIf it doesn't, the MLD/MLDv= 2 has failed to successfully discover multicast listeners. That means the a= ll of the following won't work reliably:=0A=0A- the method proposed in this= memo=0A=0A- MLD snooping by layer 2 devices=0A=0A- all multicast applicati= ons where the multicast sources are off-link=0A=0AWhile I accept that the c= onsequences of this DoS mitigation method failing are the most severe (all = off-link unicast fails), end-users will probably consider the failure of of= f-link multicast applications to be nearly as severe - they just expect thi= ngs to work, and don't really care why they don't.=0A=0ASo if MLD is failin= g, something needs to be done to make it more reliable, either tuning, or f= ixing of the MLD/MLDv2 protocol.=0A=0AI accept that this method could uncov= er the lack of MLD reliability on a link, that hasn't previously been disco= vered because off-link source multicast applications haven't been used. I'l= l have a think about that case further.=0A=0A> So we can't really base a re= solution decision on this table (unless the=0A> router is under attack and = has no other choice).=0A> =0A> - In addition, to come back to the purpose (= mitigate resolution DoS), it=0A> would "only: divide by 2**24 the address s= pace. So a DoS attack would=0A> still have plenty of addresses to use for h= is attack (2**40 per known=0A> address, which is way enough to fill a cache= ).=0A>=A0=0A=0ATrue, as I've described in the Security Considerations secti= on. This is not a stand alone method, I think it is a further compliment to= other methods to protect the ND cache.=0A=0AUltimately the only way to abs= olutely solve this problem is to have a node registration protocol, so that= routers have absolute knowledge of all hosts. However, in the interim, I t= hink methods such as this one can be useful mitigations.=0A=0A>=A0=0A=0A> I= f this is "just" to mitigate a DoS resolution attack, it would be =0A> more= =0A> efficient to store the (savi) binding table on the router, so that it= =0A> knows the address, not the the slctd (I think someone proposed a solut= ion=0A> like that at last ietf).=0A=0AI think one of the advantages of this= method is that it is likely to require very minimal changes to routers' im= plementations of features they probably already have - enabling MLDv1/MLDv2= capability all of the time rather than just when it is a multicast (forwar= ding) router, and a slight change to their neighbor discovery procedure.=0A= =0AThanks,=0AMark.=0A=0A=0A> Eric=0A> =0A> =0A> =0A> On 07/04/14 23:21, "Ma= rk ZZZ Smith" =0A> wrote:=0A> =0A>> Hi,=0A>> = =0A>> I've just posted the following ID, grateful for any feedback.=0A>> = =0A>> Regards,=0A>> Mark.=0A>> =0A>> =0A>> ----- Forwarded Message -----=0A= >>> From: "internet-drafts@ietf.org" =0A> =0A>>>= To: Mark Smith ; Mark Smith=0A>>> =0A>>> Cc: =0A>>> Sent: Tuesday, 8 April 2014 7:19 AM=0A>>= > Subject: New Version Notification for=0A>>> draft-smith-v6ops-mitigate-r= tr-dos-mld-slctd-node-00.txt=0A>>> =0A>>> =0A>>> A new version of I-D,=0A>= >> draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.txt=0A>>> has been= successfully submitted by Mark Smith and posted to the=0A>>> IETF reposit= ory.=0A>>> =0A>>> Name:=A0 =A0 =A0 =A0 draft-smith-v6ops-mitigate-rtr-dos-= mld-slctd-node=0A>>> Revision:=A0 =A0 00=0A>>> Title:=A0 =A0 =A0 =A0 Furt= her Mitigating Router ND Cache Exhaustion DoS Attacks=0A>>> Using =0A>>> S= olicited-Node Group Membership=0A>>> Document date:=A0 =A0 2014-04-07=0A>>= > Group:=A0 =A0 =A0 =A0 Individual Submission=0A>>> Pages:=A0 =A0 =A0 =A0= 6=0A>>> URL:=A0 =A0 =A0 =A0 =A0 =A0 =0A>>> =0A>>> http://www.ietf.org/int= ernet-drafts/draft-smith-v6ops-mitigate-rtr-dos-ml=0A>>> d-slctd-node-00.tx= t=0A>>> Status:=A0 =A0 =A0 =A0 =0A>>> =0A>>> https://datatracker.ietf.org/= doc/draft-smith-v6ops-mitigate-rtr-dos-mld-s=0A>>> lctd-node/=0A>>> Htmliz= ed:=A0 =A0 =A0 =0A>>> =0A>>> http://tools.ietf.org/html/draft-smith-v6ops-m= itigate-rtr-dos-mld-slctd-n=0A>>> ode-00=0A>>> =0A>>> =0A>>> Abstract:=0A>= >> =A0 =A0 For each of their IPv6 unicast or anycast addresses, nodes join = a=0A>>> =A0 =A0 Solicited-Node multicast group, formed using the lower 24 b= its of =0A> the=0A>>> =A0 =A0 address.=A0 This group membership can be used= by routers to further=0A>>> =A0 =A0 mitigate the Neighbor Discovery cache = Denial of Service attack.=0A>>> =0A>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =0A>= >> =A0 =A0 =A0 =A0 =0A>>> =A0 =0A>>> =0A>>> =0A>>> Please note that it may= take a couple of minutes from the time of=0A>>> submission=0A>>> until th= e htmlized version and diff are available at tools.ietf.org.=0A>>> =0A>>> = The IETF Secretariat=0A>>> =0A>> =0A>> ____________________________________= ___________=0A>> v6ops mailing list=0A>> v6ops@ietf.org=0A>> https://www.ie= tf.org/mailman/listinfo/v6ops=0A> From nobody Sun Apr 20 12:56: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 95E8E1A001B for ; Sun, 20 Apr 2014 12:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 3CCgmQe7ueEy for ; Sun, 20 Apr 2014 12:56:03 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id D58C61A0007 for ; Sun, 20 Apr 2014 12:56:03 -0700 (PDT) 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 4B8E01B801C for ; Sun, 20 Apr 2014 12:55:59 -0700 (PDT) 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 1814019005C; Sun, 20 Apr 2014 12:55:59 -0700 (PDT) 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; Sun, 20 Apr 2014 12:55:59 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <5352F918.4090908@foobar.org> Date: Sun, 20 Apr 2014 15:55:56 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <7E89E226-BD57-435D-B898-8AA26718806E@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <534EAB83.1070906@foobar.org> <70739713-281A-41E6-93ED-5EE1BC4B7FAB@nominum.com> <534EC1DB.4010902@foobar.org> <575F73AC-8DA5-4E04-B2CF-4875B729C7D3@nominum.com> <534FC59B.201@foobar.org> <1BE293BD-3191-4622-AACA-E9E3689400EB@nominum.com> <5352F918.4090908@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wqehLphfINefLZwzxIXN-kCgJ00 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 20 Apr 2014 19:56:08 -0000 On Apr 19, 2014, at 6:30 PM, Nick Hilliard wrote: > As the draft demands that a single unauthenticated packet can shut = down > ipv4 services on a client device either completely (as specified in = 5.3.3) > or almost completely (5.3.2), both options will need a detailed = security > analysis to describe how packets of this form cannot be abused by = either an > malicious operator or by rogue packets caused by access domain > misconfiguration. Also, given the extraordinary nature of these > requirements, the justification for including them in an internet = standards > track document will need to be similarly extraordinary. There was discussion on this question, updates were proposed, and I = expect to see them in the next draft. From nobody Mon Apr 21 09:16: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 09DDB1A0198 for ; Mon, 21 Apr 2014 09:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.773 X-Spam-Level: X-Spam-Status: No, score=-109.773 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.272, 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 0fpRD7vlAQQY for ; Mon, 21 Apr 2014 09:16:24 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id A14401A0010 for ; Mon, 21 Apr 2014 09:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7312; q=dns/txt; s=iport; t=1398096980; x=1399306580; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=e118Z2JkJCkBLs6WLB6dRQyBzbzFmSJrryzWhExZs0Q=; b=kVKvrSuzMqA6d7NRzO+b5BJmOdvSniYKPHtQsLzKkmomv3jBpro14VUS hZiPrs2EGcXwZ01ojiOrkXJPQJrkcAHCBRCIYZT/SzQ3Yt/1R+R8k9Rpc 7iuVBv1wc9NH99WDxhDt2aeno+jm+o7PW8B6eJdg9wHmivPwSQD3z/cDb M=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am8FAFVDVVOtJA2K/2dsb2JhbABZgwZPV4MPwH+BIBZ0giUBAQEDASNbBwQCAQYTBAEBAScDAgIhERQJCAIEEw6IHwMJCA2OM5wbnCINhmsXjEmBNxEBVwaCaTWBFASFOIs1gTeEXIFugTeLR4VRgzGBcjk X-IronPort-AV: E=Sophos;i="4.97,896,1389744000"; d="asc'?scan'208";a="37476075" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-1.cisco.com with ESMTP; 21 Apr 2014 16:16:19 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3LGGJcP027874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Apr 2014 16:16:19 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.100]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Mon, 21 Apr 2014 11:16:18 -0500 From: "Fred Baker (fred)" To: V6 Ops List Thread-Topic: draft-byrne-v6ops-clatip-01 Thread-Index: AQHPXX0GoCnfuCMMckahK1B0I3gQqQ== Date: Mon, 21 Apr 2014 16:16:18 +0000 Message-ID: <9B724115-1AA3-423C-A0F2-658285D5F43D@cisco.com> References: <852615d6f8d742a095d2701496c62275@BY2PR03MB412.namprd03.prod.outlook.com> <37C0752F-8766-43BF-AD3E-29EBB64FED96@tsinghua.edu.cn> In-Reply-To: <37C0752F-8766-43BF-AD3E-29EBB64FED96@tsinghua.edu.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.155.64.140] Content-Type: multipart/signed; boundary="Apple-Mail=_471CA75E-257E-4D05-9D9D-1E3D60742A83"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/lyAwLGnr2nuILnKmFEBK9VCvRCM Subject: [v6ops] 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: Mon, 21 Apr 2014 16:16:29 -0000 --Apple-Mail=_471CA75E-257E-4D05-9D9D-1E3D60742A83 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Following up from the recent meeting. We discussed clatip. The outcome was that we wanted to know what = softwire wanted done with it, and I took the action to ask.=20 The response from the softwire chairs was that they wanted to consider = the draft there, and advance it from there. However, it appears to be = bottlenecked. So, the softwire chairs have stepped back. I want the opinion of v6ops. Do we need this, or not? If we need this, = we should adopt it, and then (I think) go to an immediate WGLC and = potentially advance it. If it=E2=80=99s not needed, we should say it is = not needed. Please reply in this thread. On Apr 21, 2014, at 5:55 AM, Yong Cui wrote: > Hi Fred, >=20 > Thanks for your email and reminding. >=20 > You are right that we are glad to take this work in Softwire as we = discussed in March. However, for some reasons we need to focus on MAP = package right now. There is the consensus that Softwire will NOT take = any new work before we submit the MAP package to IESG. There are even = some other wg items blocked in Softwire at this moment. We are trying to = solve the MAP issues asap and accelerate the process. But I'm afraid we = still need some time. >=20 > So if you'd like to take this work in v6ops, please do so. Otherwise, = we still need to wait for some time before taking it in Softwire. >=20 > Thanks for understanding and let us know your decision. >=20 > Yong=20 >=20 > On 2014-4-19, at =E4=B8=8A=E5=8D=8812:23, Fred Baker (fred) = wrote: >=20 >> Softwire chairs: >>=20 >> In March, you indicated that you wanted to progress this in softwire. = The authors haven=E2=80=99t heard from you and are looking for guidance. = Pick one: do you want it, or do you want it done for you? >>=20 >> Fred >>=20 >>=20 >> On Apr 18, 2014, at 4:55 AM, TheIpv6guy . wrote: >>=20 >>> *fixing the softwire chair email address since it bounced. >>>=20 >>> On Fri, Apr 4, 2014 at 5:44 PM, Fred Baker (fred) = wrote: >>>>=20 >>>> On Apr 4, 2014, at 6:34 AM, Cb B wrote: >>>>=20 >>>> Hello folks, >>>>=20 >>>> No follow-up in a week. I assume the below explanation and = exisiting text >>>> are ok. >>>>=20 >>>> To restate, this I-D simply generalizes the scope of 192.0.0.0/29. = There is >>>> no guidance on how specific addresses may be used. It is assumed = the >>>> deploying party will not cause a conflict on the host by assiging = the same >>>> address to the host multipls times.... as that is a general ip = configuration >>>> rule. >>>>=20 >>>> I will ask v6ops to accept this i-d and direct them to this thread = to see >>>> the softwire view. >>>>=20 >>>>=20 >>>> My understanding is that softwires wants to progress this one. I = guess I=E2=80=99d >>>> like to hear from the softwires chairs before bringing it back. >>>>=20 >>>=20 >>>=20 >>> Fred, >>>=20 >>> It has been 14 days since your email. I am not sure if you sent = the >>> email to the wrong address of fixed it. Either way, i would like to >>> make progress on this I-D in v6ops since this I-D is about a >>> generalized approach that exceeds the bounds of softwires. This has >>> also been presented twice in person to v6ops. >>>=20 >>> Cameron >>>=20 >>>> CB >>>>=20 >>>> On Mar 29, 2014 4:59 AM, "Cb B" wrote: >>>>>=20 >>>>> On Thu, Mar 27, 2014 at 3:38 PM, Dave Thaler = >>>>> wrote: >>>>>>> -----Original Message----- >>>>>>> From: Softwires [mailto:softwires-bounces@ietf.org] On Behalf Of = Cb B >>>>>>> Sent: Thursday, March 27, 2014 10:58 AM >>>>>>> To: softwires@ietf.org >>>>>>> Subject: [Softwires] draft-byrne-v6ops-clatip-01 >>>>>>>=20 >>>>>>> Hi Softwires, >>>>>>>=20 >>>>>>> Ales presented draft-byrne-v6ops-clatip-01 in softwires at the = last >>>>>>> IETF >>>>>>> meeting. >>>>>>>=20 >>>>>>> I am attempting to have this I-D adopted by v6ops, but v6ops = requested >>>>>>> feedback from softwires first. >>>>>>>=20 >>>>>>> Pertaining to the minutes, i would like to address some topics = to make >>>>>>> sure it >>>>>>> is ok for v6ops to move forward with adoption >>>>>>>=20 >>>>>>>=20 >>>>>>> = https://tools.ietf.org/wg/softwire/minutes?item=3Dminutes-89-softwire.html= >>>>>>>=20 >>>>>>> The addresses, both in DS-lite and 464xlat, never appears on the = wire >>>>>>> so >>>>>>> there is no chance of overlap or collision. >>>>>>=20 >>>>>> Disagree, that conclusion doesn't follow (and in my experience = it's >>>>>> wrong). >>>>>> Overlap/collision happens when there are two interfaces on the = same host >>>>>> (even if they're not in use simultaneously). The collisions can = affect >>>>>> the routing table (if the host implements in such a way), ACLs = like in >>>>>> host firewall policies and such, and various application-layer = uses. >>>>>>=20 >>>>>=20 >>>>> Ah, i see your point. If the host is itself both a B4 and a CLAT = at >>>>> the same time, then this collision may occur within the host, not = on >>>>> the wire. >>>>>=20 >>>>>> It's fine to specify use as the default range (e.g. for 464xlat = or >>>>>> DS-lite) but >>>>>> important to never constrain it to only that range, assuming the = range >>>>>> is made >>>>>> non-DS-lite specific. >>>>>>=20 >>>>>> -Dave >>>>>=20 >>>>> Is there such a constraint that would cause a problem? >>>>>=20 >>>>> Looking at RFC6333 and draft-byrne-v6ops-clatip, i see that = RFC6333 >>>>> says the B4 SHOULD use 192.0.0.2. To a rational person, a good = reason >>>>> to not use 192.0.0.2 is that it is in use for a CLAT interface on = the >>>>> same host, which fits with the SHOULD wording. >>>>>=20 >>>>> Is there some text that you could suggest that may clarify this >>>>> situation in draft-byrne-v6ops-clatip or is it ok for v6ops to = adopt >>>>> as-is? As it stands, the I-D simply says that 192.0.0.0/29 will = be >>>>> generalized without making any further statements how addresses = may be >>>>> used within that range. >>>>>=20 >>>>> CB >>>>=20 >>>>=20 >>>> ------------------------------------------------------ >>>> 8 issues in virtual infrastructure >>>> http://dcrocker.net/#fallacies >>>>=20 >>=20 >> ------------------------------------------------------ >> 8 issues in virtual infrastructure >> http://dcrocker.net/#fallacies >>=20 >=20 >=20 ------------------------------------------------------ 8 issues in virtual infrastructure http://dcrocker.net/#fallacies --Apple-Mail=_471CA75E-257E-4D05-9D9D-1E3D60742A83 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 iD8DBQFTVURQbjEdbHIsm0MRArytAKC/sIKxQKePY03ScJy4zP01aw561ACg2mpE ZLJlCDljId9clvAvmUYA7/c= =Vady -----END PGP SIGNATURE----- --Apple-Mail=_471CA75E-257E-4D05-9D9D-1E3D60742A83-- From nobody Mon Apr 21 09:43: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 A9C961A0223 for ; Mon, 21 Apr 2014 09:43:47 -0700 (PDT) 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 Y1RHsrc2R7wI for ; Mon, 21 Apr 2014 09:43:43 -0700 (PDT) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 174AE1A0181 for ; Mon, 21 Apr 2014 09:43:30 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id lh14so1226260vcb.20 for ; Mon, 21 Apr 2014 09:43:24 -0700 (PDT) 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=GAd3yK9acjIRxpIZg8EwP0BJcaoSWa7CzWZlQlOMVxQ=; b=O6hlm6SljM2EZ3zlUZezUm3GLL+QJ+SMRaAbv5xJLkj7myarLFVEf6of1Jq1iae9p4 loFygbs/x+lA/Z5QlHxMEsokAujYnLmYAlgPW+z01i4PO7xTxyVNrsXHx6Vw9VFo2yhG E1X+qpYDFNu8UGOzuE2oMhsMenzFZ1CfOxGKNULZdX/Ge6TYgZvaDnZOhY0VgdG7Ieg8 U0k8AQw4B6BEyYL1Czlsr1/w1ZK7h/nSe3u16XuwPd3L+W1C34RbR1c33oX3oNVP7Yi0 FfMug0vEi3bIkO9tOa2wASIYbLDqzq+msBRko/uEFdcAX6GJW0F4sMRADqNBYZHeoxLr cqpA== MIME-Version: 1.0 X-Received: by 10.52.6.162 with SMTP id c2mr26938972vda.6.1398098604841; Mon, 21 Apr 2014 09:43:24 -0700 (PDT) Sender: mpetach@gmail.com Received: by 10.220.173.193 with HTTP; Mon, 21 Apr 2014 09:43:24 -0700 (PDT) In-Reply-To: <8E450CDC-FFC5-4649-89FE-387836C8E40B@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> <4EABCE38-7CBA-4C95-84EE-686A2300F26E@delong.com> <8E450CDC-FFC5-4649-89FE-387836C8E40B@nominum.com> Date: Mon, 21 Apr 2014 09:43:24 -0700 X-Google-Sender-Auth: jOK2P5lgoFLbeP7imP6M9pgUvXw Message-ID: From: Matthew Petach To: Ted Lemon Content-Type: multipart/alternative; boundary=20cf30334739b3e1dd04f790328e Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/p6tTw_T7G59GXdqvLDZLxOw42EY Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 21 Apr 2014 16:43:48 -0000 --20cf30334739b3e1dd04f790328e Content-Type: text/plain; charset=UTF-8 On Thu, Apr 17, 2014 at 7:48 AM, Ted Lemon wrote: > On Apr 17, 2014, at 6:56 AM, Owen DeLong wrote: > > Providing a mechanism for an IPv6 LAN to shut down the IPv4 mobile > network on a device which is unlikely to be enterprise controlled is not a > solution in the real world, but only an attack vector. > > We are in full agreement on this point. It has to be up to the device > what it does with whatever configuration information the network supplies, > and *I would not expect a device to take advice from one network about how > to operate on another.* You could imagine exceptions to this, but I think > all of them would be equally well addressed by individually updating each > device, so there's no reason to have a protocol for doing it. > Ted, I just want to repeat your statement once more: "I would not expect a device to take advice from one network about how to operate on another." I don't think I could sum up my objections to this draft any more clearly than you just did. I would not expect any device of mine to take advice from an IPv6 network about how to operate on an IPv4 network. Even if those networks happen to be sharing the same physical piece of wire, or same range of RF spectrum, they are independent and orthogonal networks. Now, one can take steps to bring those networks together, such as creating tunnels, encapsulating one network within the other; but under those circumstances, one should realize the now-shared-fate scenario one has delved into. But by default, the two protocols were designed to be ships in the night, and what is being proposed here clearly violates that. (looking at this from the other side, it would have been an interesting proposal a few years back to have a DHCPv4 option to tell hosts to shut down all those pesky teredo, 6in4, and other pesky IPv6 tunnelling, translation, and encapsulation technologies that the hosts might have tried to use that caused extra unnecessary packets to clog the networks. I'd like to imagine the outcry against such a "packet of IPv6 death" would have been equally as loud as what you're seeing now.) Matt --20cf30334739b3e1dd04f790328e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



    On Thu, Apr 17, 2014 at 7:48 AM, Ted Lemon <ted.lemon@nominum.= com> wrote:
    On Apr 17= , 2014, at 6:56 AM, Owen DeLong <owen= @delong.com> wrote:
    > Providing a mechanism for an IPv6 LAN to shut down the IPv4 mobile net= work on a device which is unlikely to be enterprise controlled is not a sol= ution in the real world, but only an attack vector.

    We are in full agreement on this point. =C2=A0 It has to be up to the= device what it does with whatever configuration information the network su= pplies, and *I would not expect a device to take advice from one network ab= out how to operate on another.* =C2=A0 You could imagine exceptions to this= , but I think all of them would be equally well addressed by individually u= pdating each device, so there's no reason to have a protocol for doing = it.

    Ted, I just want to repeat your statement = once more:

    "I would not expect a device to take advice from one= network about how to operate on another."

    I don'= ;t think I could sum up my objections to this draft any
    more clearly than you just did.=C2=A0 I would not expect any device
    of m= ine to take advice from an IPv6 network about how to
    operate on an IPv4 = network.=C2=A0 Even if those networks happen
    to be sharing the same phys= ical piece of wire, or same range of
    RF spectrum, they are independent and orthogonal networks.

    Now, one can take steps to bring those networks together,
    such as crea= ting tunnels, encapsulating one network within
    the other; but under thos= e circumstances, one should realize
    the now-shared-fate scenario one has delved into.=C2=A0 But bydefault, the two protocols were designed to be ships in the
    night, and what is being proposed here clearly violates
    that= .

    (looking at this from the other side, it would ha= ve been an
    interesting proposal a few years back to have a DHCPv4
    opt= ion to tell hosts to shut down all those pesky teredo,
    6in4, = and other pesky IPv6 tunnelling, translation, and
    encapsulation technologies that the hosts might have
    tried to use that = caused extra unnecessary packets
    to clog the networks.=C2=A0 = I'd like to imagine the outcry
    against such a "packe= t of IPv6 death" would have
    been equally as loud as what you're seeing now.)

    Matt
    --20cf30334739b3e1dd04f790328e-- From nobody Mon Apr 21 09:52: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 0B1971A0022 for ; Mon, 21 Apr 2014 09:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 IkRXrRryderZ for ; Mon, 21 Apr 2014 09:52:03 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACC91A0252 for ; Mon, 21 Apr 2014 09:52:00 -0700 (PDT) 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 5E3EC1B81EE for ; Mon, 21 Apr 2014 09:51:55 -0700 (PDT) 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 5229419005C; Mon, 21 Apr 2014 09:51:55 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 21 Apr 2014 09:51:55 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: Date: Mon, 21 Apr 2014 12:51:52 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <8D5B69E2-9327-4A37-95D6-EA9DAA92003F@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> <4EABCE38-7CBA-4C95-84EE-686A2300F26E@delong.com> <8E450CDC-FFC5-4649-89FE-387836C8E40B@nominum.com> To: Matthew Petach X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wGRJQ_YVeSaiiooBW0xn6cnKqn8 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 21 Apr 2014 16:52:05 -0000 On Apr 21, 2014, at 12:43 PM, Matthew Petach = wrote: > I would not expect any device > of mine to take advice from an IPv6 network about how to > operate on an IPv4 network. I think you're abusing the term "network" here to make a point that's = only tangentially related. If you have a point to make, you should = make it without torturing definitions like this to do it. A physical = wire (or SSID) is obviously owned by some one entity, and that entity is = the network operator for that wire. If conflicting information appears = on that wire, it is either an attack or a misconfiguration; in either = case, the network operator has to fix it. We should try to be robust = in the face of such attacks, but the distinction you are drawing gives = us no help in doing so. From nobody Mon Apr 21 14: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 78B621A028A; Mon, 21 Apr 2014 14:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -79.474 X-Spam-Level: X-Spam-Status: No, score=-79.474 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_SBL=20, USER_IN_WHITELIST=-100] 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 tUd9S2erygY9; Mon, 21 Apr 2014 14:46:20 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id ABE411A02A9; Mon, 21 Apr 2014 14:46:20 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 6000) id B6E5E1801B0; Mon, 21 Apr 2014 14:45:33 -0700 (PDT) Date: Mon, 21 Apr 2014 14:45:33 -0700 From: RFC Editor To: ietf-announce@ietf.org Message-ID: <20140421214533.GD15803@rfc-editor.org> References: <20140409194156.GA984@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140409194156.GA984@rfc-editor.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/c09k4EpzkoAnd10YlYh3HER76kg Cc: v6ops@ietf.org, RFC Editor Subject: [v6ops] Resend: RFC 7157 on IPv6 Multihoming without Network Address Translation 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, 21 Apr 2014 21:46:25 -0000 Below is the original publication announcement for RFC 7157. It is being resent because the original announcement does not seem to have made it through to the ietf-announce list. Please note that the date of publication is 31 March 2014, as indicated in the message below. ----- Forwarded message from rfc-editor@rfc-editor.org ----- Date: Mon, 31 Mar 2014 17:36:01 -0700 (PDT) From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, v6ops@ietf.org Subject: RFC 7157 on IPv6 Multihoming without Network Address Translation A new Request for Comments is now available in online RFC libraries. RFC 7157 Title: IPv6 Multihoming without Network Address Translation Author: O. Troan, Ed., D. Miles, S. Matsushima, T. Okimoto, D. Wing Status: Informational Stream: IETF Date: March 2014 Mailbox: ot@cisco.com, davidmiles@google.com, satoru.matsushima@g.softbank.co.jp, t.okimoto@west.ntt.co.jp, dwing@cisco.com Pages: 22 Characters: 49038 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-06.txt URL: http://www.rfc-editor.org/rfc/rfc7157.txt Network Address and Port Translation (NAPT) works well for conserving global addresses and addressing multihoming requirements because an IPv4 NAPT router implements three functions: source address selection, next-hop resolution, and (optionally) DNS resolution. For IPv6 hosts, one approach could be the use of IPv6-to-IPv6 Network Prefix Translation (NPTv6). However, NAT and NPTv6 should be avoided, if at all possible, to permit transparent end-to-end connectivity. In this document, we analyze the use cases of multihoming. We also describe functional requirements and possible solutions for multihoming without the use of NAT in IPv6 for hosts and small IPv6 networks that would otherwise be unable to meet minimum IPv6-allocation criteria. We conclude that DHCPv6-based solutions are suitable to solve the multihoming issues described in this document, but NPTv6 may be required as an intermediate solution. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ----- End forwarded message ----- From nobody Mon Apr 21 22:29: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 DE7941A0077 for ; Mon, 21 Apr 2014 22:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 0EAqwAeWjbg4 for ; Mon, 21 Apr 2014 22:29:44 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6AF1A006E for ; Mon, 21 Apr 2014 22:29:44 -0700 (PDT) Received: from [2a02:c0:2:4:6666:17:0:1000] (port=56810 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1WcTGy-0004ta-H5; Tue, 22 Apr 2014 07:29:36 +0200 Message-ID: <5355FE26.5020105@fud.no> Date: Tue, 22 Apr 2014 07:29:10 +0200 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Fred Baker (fred)" , V6 Ops List References: <852615d6f8d742a095d2701496c62275@BY2PR03MB412.namprd03.prod.outlook.com> <37C0752F-8766-43BF-AD3E-29EBB64FED96@tsinghua.edu.cn> <9B724115-1AA3-423C-A0F2-658285D5F43D@cisco.com> In-Reply-To: <9B724115-1AA3-423C-A0F2-658285D5F43D@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4f9xDspA6iod8Yh5ryX3PUf7ox4 Subject: Re: [v6ops] 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: Tue, 22 Apr 2014 05:29:46 -0000 * Fred Baker (fred) > Do we need this, or not? I think this is useful, yes. Tore From nobody Tue Apr 22 06: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 152E11A03EF for ; Tue, 22 Apr 2014 06:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.964 X-Spam-Level: * X-Spam-Status: No, score=1.964 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272, 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 K5B0cCdwKncH for ; Tue, 22 Apr 2014 06:01:49 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id E00351A042E for ; Tue, 22 Apr 2014 06:01:36 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.97,904,1389762000"; d="scan'208,217";a="281699363" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 22 Apr 2014 08:59:44 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Tue, 22 Apr 2014 09:00:33 -0400 From: "George, Wes" To: Matthew Petach , Ted Lemon Date: Tue, 22 Apr 2014 09:00:32 -0400 Thread-Topic: [v6ops] Please review the No IPv4 draft Thread-Index: Ac9eKthk5xQQU4EwRAWQzVfljoIXTA== Message-ID: References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> <4EABCE38-7CBA-4C95-84EE-686A2300F26E@delong.com> <8E450CDC-FFC5-4649-89FE-387836C8E40B@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CF7BDD911911Dwesleygeorgetwcablecom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Wst5HCoXn_R_Oqg5LkS_D1POo7k Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 22 Apr 2014 13:01:53 -0000 --_000_CF7BDD911911Dwesleygeorgetwcablecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpGcm9tOiBNYXR0aGV3IFBldGFjaCA8bXBldGFjaEBuZXRmbGlnaHQuY29tPG1haWx0bzptcGV0 YWNoQG5ldGZsaWdodC5jb20+Pg0KRGF0ZTogTW9uZGF5LCBBcHJpbCAyMSwgMjAxNCBhdCAxMjo0 MyBQTQ0KVG86IFRlZCBMZW1vbiA8dGVkLmxlbW9uQG5vbWludW0uY29tPG1haWx0bzp0ZWQubGVt b25Abm9taW51bS5jb20+Pg0KQ2M6ICJ2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5v cmc+IFdHIiA8djZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPj4NClN1YmplY3Q6 IFJlOiBbdjZvcHNdIFBsZWFzZSByZXZpZXcgdGhlIE5vIElQdjQgZHJhZnQNCg0KSSB3b3VsZCBu b3QgZXhwZWN0IGFueSBkZXZpY2UNCm9mIG1pbmUgdG8gdGFrZSBhZHZpY2UgZnJvbSBhbiBJUHY2 IG5ldHdvcmsgYWJvdXQgaG93IHRvDQpvcGVyYXRlIG9uIGFuIElQdjQgbmV0d29yay4gIEV2ZW4g aWYgdGhvc2UgbmV0d29ya3MgaGFwcGVuDQp0byBiZSBzaGFyaW5nIHRoZSBzYW1lIHBoeXNpY2Fs IHBpZWNlIG9mIHdpcmUsIG9yIHNhbWUgcmFuZ2Ugb2YNClJGIHNwZWN0cnVtLCB0aGV5IGFyZSBp bmRlcGVuZGVudCBhbmQgb3J0aG9nb25hbCBuZXR3b3Jrcy4NCg0KV0ddIEkgdGhpbmsgdGhhdCB0 aGVyZeKAmXMgYSBuZWVkIGZvciBjbGFyaWZpY2F0aW9uIGhlcmUuIEEgbG90IG9mIHRoaXMgZGlz Y3Vzc2lvbiBoYXMgZm9jdXNlZCBhbG1vc3QgZXhjbHVzaXZlbHkgb24gdGhlIGZ1bGwtb24gZGlz YWJsaW5nIG9mIElQdjQuIFBhcnQgb2Ygd2hhdCB0aGUgZHJhZnQgZGlzY3Vzc2VzIGlzIHRoYXQg dGhlcmUgYXJlIGRpZmZlcmluZyB0aGluZ3MgdGhhdCBjYW4gYmUgc2lnbmFsZWQgdG8gdGhlIGxv Y2FsIGRldmljZXMgZnJvbSB0aGUgbmV0d29yayBiYXNlZCBvbiB0aGUgYml0IHNldCBpbiB0aGUg cHJvcG9zZWQgb3B0aW9uLiBUaGVyZSBpcyBhbiBvcHRpb24gdGhhdCBzaW1wbHkgc2lnbmFscyDi gJx0aGVyZSBpcyBubyBJUHY0IHN1cHBvcnQgb24gdGhpcyBuZXR3b3Jr4oCdIGFuZCBtYWtlcyBh dHRlbmRhbnQgcmVjb21tZW5kYXRpb25zIHRoYXQgdGhlIGRldmljZSBkZWNpZGUgb24gaXRzIG93 biB3aGF0IHRvIGRvIGZvciBhbnkgbG9jYWwgSVB2NCB0cmFmZmljIG9uIHRoZSBMQU4sIGluY2x1 ZGluZyBkb2luZyBub3RoaW5nLCBjb25maWd1cmluZyAxNjkgYWRkcmVzc2VzLCBldGMuIGJ1dCB0 aGF0IGl0IHNob3VsZCBkaXNhYmxlIElQdjQgb24gdGhlIHVwc3RyZWFtIGludGVyZmFjZSBmYWNp bmcgdGhlIG5ldHdvcmsgdGhhdCBwcm92aWRlZCB0aGUgc2lnbmFsIChJLmUuIFN0b3AgZm9yd2Fy ZGluZyBJUHY0IHRyYWZmaWMgYW5kIHN0b3Agc2VuZGluZyBESENQdjQpLg0KSeKAmW0gd2lsbGlu ZyB0byBnbyB3aXRoIGNvbnNlbnN1cyAoaWYgZXhpc3QpIHRoYXQgdGhlIG1vcmUgYWdncmVzc2l2 ZSBvcHRpb24gb2Ygc29tZXRoaW5nIGxpa2UgYSBmdWxsLW9uIElQdjQga2lsbHN3aXRjaCB0aGF0 IGFmZmVjdHMgbW9yZSB0aGFuIG9uZSBpbnRlcmZhY2UgYW5kIGFmZmVjdHMgdGhlIGxvY2FsIG5l dHdvcmsgaXMgYSBicmlkZ2UgdG9vIGZhciwgYm90aCBmb3Igc2VjdXJpdHkgcmVhc29ucyAoSXTi gJlsbCBiZSBoYXJkIHRvIHNlY3VyZSB0byBhIGxldmVsIHRoYXQgZXhwbG9pdHMgYXJlbuKAmXQg bGlrZWx5KSBhbmQgYmVjYXVzZSBpdCBnZXRzIGludG8gYSBxdWVzdGlvbiBhYm91dCBhdXRvbm9t eSBhbmQgc3BhbiBvZiBjb250cm9sLiBCdXQgSSB0aGluayBpdOKAmXMgd29ydGggaGlnaGxpZ2h0 aW5nIHRoYXQgdGhlcmUgYXJlIGFsc28gbGVzcyBhZ2dyZXNzaXZlIG9wdGlvbnMgZGlzY3Vzc2Vk IGluIHRoZSBkcmFmdCwgYW5kIEnigJlkIGxpa2UgdG8gaGF2ZSBzb21lIHNlbnNlIHRoYXQgdGhv c2UgYXJlIG1vc3RseSBvbiB0aGUgcmlnaHQgdHJhY2ssIGFuZCB5b3VyIHN0YXRlbWVudCBpcyBz byBicm9hZCB0aGF0IEkgd2FudGVkIHRvIGdldCBjbGFyaWZpY2F0aW9uIG9uIHdoYXQgeW91IHRo aW5rIG9mIHRoaXMuDQoNClRoYW5rcywNCg0KV2VzIEdlb3JnZQ0KDQpBbnl0aGluZyBiZWxvdyB0 aGlzIGxpbmUgaGFzIGJlZW4gYWRkZWQgYnkgbXkgY29tcGFueeKAmXMgbWFpbCBzZXJ2ZXIsIEkg aGF2ZSBubyBjb250cm9sIG92ZXIgaXQuDQotLS0tLS0tLS0tLQ0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdo aWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQg YmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBz b2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0 IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0 aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlv biwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8g dGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMg RS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo= --_000_CF7BDD911911Dwesleygeorgetwcablecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjps ZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZU OiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBB RERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1S SUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5NYXR0aGV3IFBldGFjaCAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1wZXRhY2hAbmV0ZmxpZ2h0LmNvbSI+bXBldGFjaEBuZXRmbGlnaHQuY29tPC9hPiZndDs8 YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPk1vbmRheSwg QXByaWwgMjEsIDIwMTQgYXQgMTI6NDMgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 Ym9sZCI+VG86IDwvc3Bhbj5UZWQgTGVtb24gJmx0OzxhIGhyZWY9Im1haWx0bzp0ZWQubGVtb25A bm9taW51bS5jb20iPnRlZC5sZW1vbkBub21pbnVtLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnY2 b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT4gV0cmcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFt2Nm9wc10gUGxlYXNl IHJldmlldyB0aGUgTm8gSVB2NCBkcmFmdDxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KPGRpdiBjbGFzcz0i Z21haWxfcXVvdGUiPg0KPGRpdj5JIHdvdWxkIG5vdCBleHBlY3QgYW55IGRldmljZTxicj4NCm9m IG1pbmUgdG8gdGFrZSBhZHZpY2UgZnJvbSBhbiBJUHY2IG5ldHdvcmsgYWJvdXQgaG93IHRvPGJy Pg0Kb3BlcmF0ZSBvbiBhbiBJUHY0IG5ldHdvcmsuJm5ic3A7IEV2ZW4gaWYgdGhvc2UgbmV0d29y a3MgaGFwcGVuPGJyPg0KdG8gYmUgc2hhcmluZyB0aGUgc2FtZSBwaHlzaWNhbCBwaWVjZSBvZiB3 aXJlLCBvciBzYW1lIHJhbmdlIG9mPGJyPg0KUkYgc3BlY3RydW0sIHRoZXkgYXJlIGluZGVwZW5k ZW50IGFuZCBvcnRob2dvbmFsIG5ldHdvcmtzLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V0ddIEkgdGhpbmsgdGhhdCB0aGVy ZeKAmXMgYSBuZWVkIGZvciBjbGFyaWZpY2F0aW9uIGhlcmUuIEEgbG90IG9mIHRoaXMgZGlzY3Vz c2lvbiBoYXMgZm9jdXNlZCBhbG1vc3QgZXhjbHVzaXZlbHkgb24gdGhlIGZ1bGwtb24gZGlzYWJs aW5nIG9mIElQdjQuIFBhcnQgb2Ygd2hhdCB0aGUgZHJhZnQgZGlzY3Vzc2VzIGlzIHRoYXQgdGhl cmUgYXJlIGRpZmZlcmluZyB0aGluZ3MgdGhhdCBjYW4gYmUgc2lnbmFsZWQgdG8gdGhlIGxvY2Fs IGRldmljZXMNCiBmcm9tIHRoZSBuZXR3b3JrIGJhc2VkIG9uIHRoZSBiaXQgc2V0IGluIHRoZSBw cm9wb3NlZCBvcHRpb24uIFRoZXJlIGlzIGFuIG9wdGlvbiB0aGF0IHNpbXBseSBzaWduYWxzIOKA nHRoZXJlIGlzIG5vIElQdjQgc3VwcG9ydCBvbiB0aGlzIG5ldHdvcmvigJ0gYW5kIG1ha2VzIGF0 dGVuZGFudCByZWNvbW1lbmRhdGlvbnMgdGhhdCB0aGUgZGV2aWNlIGRlY2lkZSBvbiBpdHMgb3du IHdoYXQgdG8gZG8gZm9yIGFueSBsb2NhbCBJUHY0IHRyYWZmaWMgb24gdGhlDQogTEFOLCBpbmNs dWRpbmcgZG9pbmcgbm90aGluZywgY29uZmlndXJpbmcgMTY5IGFkZHJlc3NlcywgZXRjLiBidXQg dGhhdCBpdCBzaG91bGQgZGlzYWJsZSBJUHY0IG9uIHRoZSB1cHN0cmVhbSBpbnRlcmZhY2UgZmFj aW5nIHRoZSBuZXR3b3JrIHRoYXQgcHJvdmlkZWQgdGhlIHNpZ25hbCAoSS5lLiBTdG9wIGZvcndh cmRpbmcgSVB2NCB0cmFmZmljIGFuZCBzdG9wIHNlbmRpbmcgREhDUHY0KS4mbmJzcDs8L2Rpdj4N CjxkaXY+SeKAmW0gd2lsbGluZyB0byBnbyB3aXRoIGNvbnNlbnN1cyAoaWYgZXhpc3QpIHRoYXQg dGhlIG1vcmUgYWdncmVzc2l2ZSBvcHRpb24gb2Ygc29tZXRoaW5nIGxpa2UgYSBmdWxsLW9uIElQ djQga2lsbHN3aXRjaCB0aGF0IGFmZmVjdHMgbW9yZSB0aGFuIG9uZSBpbnRlcmZhY2UgYW5kIGFm ZmVjdHMgdGhlIGxvY2FsIG5ldHdvcmsgaXMgYSBicmlkZ2UgdG9vIGZhciwgYm90aCBmb3Igc2Vj dXJpdHkgcmVhc29ucyAoSXTigJlsbCBiZSBoYXJkIHRvDQogc2VjdXJlIHRvIGEgbGV2ZWwgdGhh dCBleHBsb2l0cyBhcmVu4oCZdCBsaWtlbHkpIGFuZCBiZWNhdXNlIGl0IGdldHMgaW50byBhIHF1 ZXN0aW9uIGFib3V0IGF1dG9ub215IGFuZCBzcGFuIG9mIGNvbnRyb2wuIEJ1dCBJIHRoaW5rIGl0 4oCZcyB3b3J0aCBoaWdobGlnaHRpbmcgdGhhdCB0aGVyZSBhcmUgYWxzbyBsZXNzIGFnZ3Jlc3Np dmUgb3B0aW9ucyBkaXNjdXNzZWQgaW4gdGhlIGRyYWZ0LCBhbmQgSeKAmWQgbGlrZSB0byBoYXZl IHNvbWUgc2Vuc2UgdGhhdA0KIHRob3NlIGFyZSBtb3N0bHkgb24gdGhlIHJpZ2h0IHRyYWNrLCBh bmQgeW91ciBzdGF0ZW1lbnQgaXMgc28gYnJvYWQgdGhhdCBJIHdhbnRlZCB0byBnZXQgY2xhcmlm aWNhdGlvbiBvbiB3aGF0IHlvdSB0aGluayBvZiB0aGlzLiZuYnNwOzwvZGl2Pg0KPHNwYW4gaWQ9 Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBjbGFzcz0iZ21h aWxfZXh0cmEiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjxicj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsi PlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMXB0OyI+V2VzPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsiPiZu YnNwO0dlb3JnZTwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7Ij48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBp ZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJn bWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7Ij48 c3BhbiBzdHlsZT0iY29sb3I6IHJnYigxMjcsIDEyNywgMTI3KTsgZm9udC1zaXplOiAxMXB0OyI+ QW55dGhpbmcgYmVsb3cgdGhpcyBsaW5lIGhhcyBiZWVuIGFkZGVkIGJ5IG15IGNvbXBhbnnigJlz IG1haWwgc2VydmVyLCBJIGhhdmUgbm8gY29udHJvbCBvdmVyIGl0Ljwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNp emU6IDExcHQ7Ij48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigxMjcsIDEyNywgMTI3KTsiPi0tLS0t LS0tLS0tPC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj48YnI+DQo8 aHI+DQo8Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9IkdyYXkiIHNpemU9IjEiPlRoaXMgRS1tYWls IGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxl IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRp YWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJs ZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5DQogZm9yIHRoZSB1c2Ugb2YgdGhlIGlu ZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkg bm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBv ciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2ht ZW50cyB0bw0KIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1 bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRo ZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC48 YnI+DQo8L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CF7BDD911911Dwesleygeorgetwcablecom_-- From nobody Tue Apr 22 06:23: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 BDA751A046F for ; Tue, 22 Apr 2014 06:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.773 X-Spam-Level: X-Spam-Status: No, score=-0.773 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.272, 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 ilnmZUU254pJ for ; Tue, 22 Apr 2014 06:23:44 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E7CAF1A0430 for ; Tue, 22 Apr 2014 06:23:43 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:349d:fe5f:bc57:89]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4E47B40221; Tue, 22 Apr 2014 09:23:38 -0400 (EDT) Message-ID: <53566D59.7000202@viagenie.ca> Date: Tue, 22 Apr 2014 09:23:37 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "George, Wes" , Matthew Petach , Ted Lemon References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> <4EABCE38-7CBA-4C95-84EE-686A2300F26E@delong.com> <8E450CDC-FFC5-4649-89FE-387836C8E40B@nominum.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/eyyXZP-dKtB20AgZutD8-xB7Y74 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 22 Apr 2014 13:23:48 -0000 Le 2014-04-22 09:00, George, Wes a écrit : > WG] I think that there’s a need for clarification here. A lot of this > discussion has focused almost exclusively on the full-on disabling of > IPv4. Part of what the draft discusses is that there are differing > things that can be signaled to the local devices from the network based > on the bit set in the proposed option. There is an option that simply > signals “there is no IPv4 support on this network” and makes attendant > recommendations that the device decide on its own what to do for any > local IPv4 traffic on the LAN, including doing nothing, configuring 169 > addresses, etc. but that it should disable IPv4 on the upstream > interface facing the network that provided the signal (I.e. Stop > forwarding IPv4 traffic and stop sending DHCPv4). > I’m willing to go with consensus (if exist) that the more aggressive > option of something like a full-on IPv4 killswitch that affects more > than one interface and affects the local network is a bridge too far, > both for security reasons (It’ll be hard to secure to a level that > exploits aren’t likely) and because it gets into a question about > autonomy and span of control. But I think it’s worth highlighting that > there are also less aggressive options discussed in the draft, and I’d > like to have some sense that those are mostly on the right track, and > your statement is so broad that I wanted to get clarification on what > you think of this. Right. To be very explicit, one of the "less aggressive" options on the table is to specify a "there is no IPv4 on this network" signal while saying nothing about how a host should react to this signal. Each implementation could use that hint however it sees fit. 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 nobody Tue Apr 22 06:50: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 C35111A0441 for ; Tue, 22 Apr 2014 06:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] 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 EduTw45_boeA for ; Tue, 22 Apr 2014 06:50:52 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5561A040D for ; Tue, 22 Apr 2014 06:50:52 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1Wcb5y-0000FMC; Tue, 22 Apr 2014 15:50:46 +0200 Message-Id: To: "George, Wes" From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> <4EABCE38-7CBA-4C95-84EE-686A2300F26E@delong.com> <8E450CDC-FFC5-4649-89FE-387836C8E40B@nominum.com> In-reply-to: Your message of "Tue, 22 Apr 2014 09:00:32 -0400 ." Date: Tue, 22 Apr 2014 15:50:36 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/giTH9wD8RldnkmxeeGfc2U2RZqg Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 22 Apr 2014 13:50:55 -0000 In your letter dated Tue, 22 Apr 2014 09:00:32 -0400 you wrote: > WG] I think that there's a need for clarification here. A lot > of this discussion has focused almost exclusively on the full-on > disabling of IPv4. Part of what the draft discusses is that there are differing things that can be signaled to the local > devices from the network based on the bit set in the proposed > option. There is an option that simply signals "there is no IPv4 > support on this network" and makes attendant recommendations > that the device decide on its own what to do for any local IPv4 > traffic on the LAN, including doing nothing, configuring 169 > addresses, etc. but that it should disable IPv4 on the upstream > interface facing the network that provided the signal (I.e. > Stop forwarding IPv4 traffic and stop sending DHCPv4). I'm really curious about the resistance of putting the no-ipv4 option in DHCPv4. As far as I can tell that can be done safely, with almost no drawbacks. Instead, an endless amount of effort seems to be invested in defending the current choice for DHCPv6 and RA. Maybe there is document the describes why putting the no-ipv4 option in DHCPv4 is such a horrible idea. It is just that I can't find it. Does anyone have a link to that document? (Assuming it exists) From nobody Tue Apr 22 06:54: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 063C01A0423 for ; Tue, 22 Apr 2014 06:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 XegohIW06nfI for ; Tue, 22 Apr 2014 06:54:24 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id B3D1F1A03AE for ; Tue, 22 Apr 2014 06:54:24 -0700 (PDT) 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 B04B91B803F for ; Tue, 22 Apr 2014 06:54:19 -0700 (PDT) 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 A9A6619005C; Tue, 22 Apr 2014 06:54:19 -0700 (PDT) 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; Tue, 22 Apr 2014 06:54:19 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: Date: Tue, 22 Apr 2014 09:54:18 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> <4EABCE38-7CBA-4C95-84EE-686A2300F26E@delong.com> <8E450CDC-FFC5-4649-89FE-387836C8E40B@nominum.com> To: Philip Homburg X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sctY4fuX4ViMi_a5bNwNnATCLsU Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 22 Apr 2014 13:54:29 -0000 On Apr 22, 2014, at 9:50 AM, Philip Homburg = wrote: > I'm really curious about the resistance of putting the no-ipv4 option = in > DHCPv4. As far as I can tell that can be done safely, with almost no=20= > drawbacks. The current draft describes some of the problems. Many of the = objections raised here completely ignore what the current draft says. From nobody Tue Apr 22 07:11: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 754D31A0400 for ; Tue, 22 Apr 2014 07:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] 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 9zM39V5dntQb for ; Tue, 22 Apr 2014 07:11:20 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCF51A03FF for ; Tue, 22 Apr 2014 07:11:19 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1WcbPl-0000COC; Tue, 22 Apr 2014 16:11:13 +0200 Message-Id: To: Ted Lemon From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> <4EABCE38-7CBA-4C95-84EE-686A2300F26E@delong.com> <8E450CDC-FFC5-4649-89FE-387836C8E40B@nominum.com> In-reply-to: Your message of "Tue, 22 Apr 2014 09:54:18 -0400 ." Date: Tue, 22 Apr 2014 16:11:13 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/oDpzjTopujqr37QzxQsZC8lIJhs Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 22 Apr 2014 14:11:21 -0000 In your letter dated Tue, 22 Apr 2014 09:54:18 -0400 you wrote: >The current draft describes some of the problems. Many of the >objections raised here completely ignore what the current draft says. Okay. Let's see. These are all arguments in Section 4.1 of draft-ietf-sunset4-noipv4-00 that are listed as negative for DHCPv4. "- Devices that haven't been updated to speak IPv6 likely won't " recognize a new DHCPv4 code telling them that IPv4 isn't " supported. Doesn't seem to make sense in deciding between DHCPv4 and DHCPv6. " - When the goal is to turn off IPv4, having to maintain and operate " an IPv4 infrastructure (routing, ACLs, etc.) just to be able to " send negative responses to DHCPv4 requests is not productive. " Having the option transported in IPv6 allows the ISP to focus on " operating an IPv6-only network. This one makes sense. So what do we want? A very small amount of code can can send and receive DHCPv4 messages or all of the security problems associated with the alternatives? Let me remark here that in Section 4.1, the security implications, network mangement problems and implementations issues of putting the option in DHCPv6 are all not mentioned. "- Turning IPv4 off using an IPv4-transported signal means that there " is no way to go back. Once the DHCPv4 option has been accepted by " the DHCPv4 client, IPv4 can no longer be turned on remotely " (rebooting the client still works). Configurations change, " mistakes happen, and so it is necessary to have a way to turn IPv4 " back on. With a DHCPv6 option, IPv4 can be turned back on as soon " as the client makes a new DHCPv6 request, which can be the next " scheduled one or can be triggered immediately with a Reconfigure " message. This argument mistakenly assumes that the goal is to switch off the IPv4 stack. However that doesn't follow from the requirements. Suspending DHCPv4 for a while would equally support the requirements. That leaves that in case of an error, a DHCPv6 reconfigure or a RA would allow a more quickly recovery. So conclusion is a that against the many arguments mentioned on this list, putting the option in DHCPv4 requires a small amount of code in routers to send the no-ipv4 option and it relies on timeouts to recover from configuration errors. In contrast, putting the option in RAs and DHCPv6 creates more security problems, a more complex network management and a more complex implementation in a number of operating systems. From nobody Tue Apr 22 08:17: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 110AD1A063C for ; Tue, 22 Apr 2014 08:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 kVndTGg2SQXm for ; Tue, 22 Apr 2014 08:17:36 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 9E94C1A04F1 for ; Tue, 22 Apr 2014 08:17:36 -0700 (PDT) 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 6B8961B8062 for ; Tue, 22 Apr 2014 08:17:31 -0700 (PDT) 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 4F5BE19005C; Tue, 22 Apr 2014 08:17:31 -0700 (PDT) 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; Tue, 22 Apr 2014 08:17:31 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: Date: Tue, 22 Apr 2014 11:17:27 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <118D079B-FC99-4606-B289-4201137A5815@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> <4EABCE38-7CBA-4C95-84EE-686A2300F26E@delong.com> <8E450CDC-FFC5-4649-89FE-387836C8E40B@nominum.com> To: Philip Homburg X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-Z1wga6Su-oOV69V-HWR3fM8kFc Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 22 Apr 2014 15:17:41 -0000 On Apr 22, 2014, at 10:11 AM, Philip Homburg = wrote: > " - When the goal is to turn off IPv4, having to maintain and = operate > " an IPv4 infrastructure (routing, ACLs, etc.) just to be able to > " send negative responses to DHCPv4 requests is not productive. > " Having the option transported in IPv6 allows the ISP to focus = on > " operating an IPv6-only network. >=20 > This one makes sense. So what do we want? A very small amount of code = can > can send and receive DHCPv4 messages or all of the security problems > associated with the alternatives? You are saying this as if there are no security problems associated with = DHCPv4, but of course DHCPv4 has very similar security problems. In = order to prevent DHCPv4-based attacks on the local wire, you must filter = bad DHCPv4 packets. If you are filtering bad DHCPv4 packets on the = wire, filtering bad RA packets is doable as well. And you should be = doing it, because RAs on an IPv4-only wire are a dead simple way to set = up MiTM attacks. I already addressed this point and the others you made in previous = comments. This conversation has gotten extremely repetitive. I think = if you want to make these points again and make sure they have been = addressed, the way to do it is to open up an issue tracker for this = draft, and continue the discussion on the sunset4 mailing list. = Otherwise we're just spamming v6ops, and I'm sure the people on v6ops = who don't care about sunset4 would really like it if we stopped doing = that. From nobody Tue Apr 22 08:27: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 43E7E1A059F for ; Tue, 22 Apr 2014 08:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, UNPARSEABLE_RELAY=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 GHehQECCgAzO for ; Tue, 22 Apr 2014 08:27:13 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.176]) by ietfa.amsl.com (Postfix) with ESMTP id 79F781A04E8 for ; Tue, 22 Apr 2014 08:27:12 -0700 (PDT) Received: from [85.158.137.35:61670] by server-16.bemta-3.messagelabs.com id 74/48-13481-A4A86535; Tue, 22 Apr 2014 15:27:06 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-12.tower-134.messagelabs.com!1398180426!33575295!1 X-Originating-IP: [193.36.79.211] X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29197 invoked from network); 22 Apr 2014 15:27:06 -0000 Received: from unknown (HELO autechre) (193.36.79.211) by server-12.tower-134.messagelabs.com with SMTP; 22 Apr 2014 15:27:06 -0000 Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.14]) by autechre with MailMarshal (v6, 8, 2, 9371) id ; Tue, 22 Apr 2014 16:27:24 +0100 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK30S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a4f::62c:2a4f]) with mapi id 14.02.0318.004; Tue, 22 Apr 2014 16:27:05 +0100 From: "Heatley, Nick" To: "Fred Baker (fred)" , V6 Ops List Thread-Topic: draft-byrne-v6ops-clatip-01 Thread-Index: AQHPXX0VPqKMoKpk4UiNc1ynEex0T5sdwxlg Date: Tue, 22 Apr 2014 15:27:05 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303AE2E9A@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <852615d6f8d742a095d2701496c62275@BY2PR03MB412.namprd03.prod.outlook.com> <37C0752F-8766-43BF-AD3E-29EBB64FED96@tsinghua.edu.cn> <9B724115-1AA3-423C-A0F2-658285D5F43D@cisco.com> In-Reply-To: <9B724115-1AA3-423C-A0F2-658285D5F43D@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/kFri1b7w3dyKW4_TBXp-qSPu7Ec Subject: Re: [v6ops] 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: Tue, 22 Apr 2014 15:27:18 -0000 TmVlZGVkLCBJJ2QgbGlrZSB0byBzZWUgdGhpcyBzdGFuZGFyZGlzZWQgaGVyZS4NCg0KDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBGcmVkIEJha2VyIChmcmVkKQ0KU2VudDogMjEgQXBy aWwgMjAxNCAxNzoxNg0KVG86IFY2IE9wcyBMaXN0DQpTdWJqZWN0OiBbdjZvcHNdIGRyYWZ0LWJ5 cm5lLXY2b3BzLWNsYXRpcC0wMQ0KDQpGb2xsb3dpbmcgdXAgZnJvbSB0aGUgcmVjZW50IG1lZXRp bmcuDQoNCldlIGRpc2N1c3NlZCBjbGF0aXAuIFRoZSBvdXRjb21lIHdhcyB0aGF0IHdlIHdhbnRl ZCB0byBrbm93IHdoYXQgc29mdHdpcmUgd2FudGVkIGRvbmUgd2l0aCBpdCwgYW5kIEkgdG9vayB0 aGUgYWN0aW9uIHRvIGFzay4gDQoNClRoZSByZXNwb25zZSBmcm9tIHRoZSBzb2Z0d2lyZSBjaGFp cnMgd2FzIHRoYXQgdGhleSB3YW50ZWQgdG8gY29uc2lkZXIgdGhlIGRyYWZ0IHRoZXJlLCBhbmQg YWR2YW5jZSBpdCBmcm9tIHRoZXJlLiBIb3dldmVyLCBpdCBhcHBlYXJzIHRvIGJlIGJvdHRsZW5l Y2tlZC4gU28sIHRoZSBzb2Z0d2lyZSBjaGFpcnMgaGF2ZSBzdGVwcGVkIGJhY2suDQoNCkkgd2Fu dCB0aGUgb3BpbmlvbiBvZiB2Nm9wcy4gRG8gd2UgbmVlZCB0aGlzLCBvciBub3Q/IElmIHdlIG5l ZWQgdGhpcywgd2Ugc2hvdWxkIGFkb3B0IGl0LCBhbmQgdGhlbiAoSSB0aGluaykgZ28gdG8gYW4g aW1tZWRpYXRlIFdHTEMgYW5kIHBvdGVudGlhbGx5IGFkdmFuY2UgaXQuIElmIGl04oCZcyBub3Qg bmVlZGVkLCB3ZSBzaG91bGQgc2F5IGl0IGlzIG5vdCBuZWVkZWQuDQoNClBsZWFzZSByZXBseSBp biB0aGlzIHRocmVhZC4NCg0KT24gQXByIDIxLCAyMDE0LCBhdCA1OjU1IEFNLCBZb25nIEN1aSA8 Y3VpeW9uZ0B0c2luZ2h1YS5lZHUuY24+IHdyb3RlOg0KDQo+IEhpIEZyZWQsDQo+IA0KPiBUaGFu a3MgZm9yIHlvdXIgZW1haWwgYW5kIHJlbWluZGluZy4NCj4gDQo+IFlvdSBhcmUgcmlnaHQgdGhh dCB3ZSBhcmUgZ2xhZCB0byB0YWtlIHRoaXMgd29yayBpbiBTb2Z0d2lyZSBhcyB3ZSBkaXNjdXNz ZWQgaW4gTWFyY2guIEhvd2V2ZXIsIGZvciBzb21lIHJlYXNvbnMgd2UgbmVlZCB0byBmb2N1cyBv biBNQVAgcGFja2FnZSByaWdodCBub3cuIFRoZXJlIGlzIHRoZSBjb25zZW5zdXMgdGhhdCBTb2Z0 d2lyZSB3aWxsIE5PVCB0YWtlIGFueSBuZXcgd29yayBiZWZvcmUgd2Ugc3VibWl0IHRoZSBNQVAg cGFja2FnZSB0byBJRVNHLiBUaGVyZSBhcmUgZXZlbiBzb21lIG90aGVyIHdnIGl0ZW1zIGJsb2Nr ZWQgaW4gU29mdHdpcmUgYXQgdGhpcyBtb21lbnQuIFdlIGFyZSB0cnlpbmcgdG8gc29sdmUgdGhl IE1BUCBpc3N1ZXMgYXNhcCBhbmQgYWNjZWxlcmF0ZSB0aGUgcHJvY2Vzcy4gQnV0IEknbSBhZnJh aWQgd2Ugc3RpbGwgbmVlZCBzb21lIHRpbWUuDQo+IA0KPiBTbyBpZiB5b3UnZCBsaWtlIHRvIHRh a2UgdGhpcyB3b3JrIGluIHY2b3BzLCBwbGVhc2UgZG8gc28uIE90aGVyd2lzZSwgd2Ugc3RpbGwg bmVlZCB0byB3YWl0IGZvciBzb21lIHRpbWUgYmVmb3JlIHRha2luZyBpdCBpbiBTb2Z0d2lyZS4N Cj4gDQo+IFRoYW5rcyBmb3IgdW5kZXJzdGFuZGluZyBhbmQgbGV0IHVzIGtub3cgeW91ciBkZWNp c2lvbi4NCj4gDQo+IFlvbmcNCj4gDQo+IE9uIDIwMTQtNC0xOSwgYXQg5LiK5Y2IMTI6MjMsIEZy ZWQgQmFrZXIgKGZyZWQpIDxmcmVkQGNpc2NvLmNvbT4gd3JvdGU6DQo+IA0KPj4gU29mdHdpcmUg Y2hhaXJzOg0KPj4gDQo+PiBJbiBNYXJjaCwgeW91IGluZGljYXRlZCB0aGF0IHlvdSB3YW50ZWQg dG8gcHJvZ3Jlc3MgdGhpcyBpbiBzb2Z0d2lyZS4gVGhlIGF1dGhvcnMgaGF2ZW7igJl0IGhlYXJk IGZyb20geW91IGFuZCBhcmUgbG9va2luZyBmb3IgZ3VpZGFuY2UuIFBpY2sgb25lOiBkbyB5b3Ug d2FudCBpdCwgb3IgZG8geW91IHdhbnQgaXQgZG9uZSBmb3IgeW91Pw0KPj4gDQo+PiBGcmVkDQo+ PiANCj4+IA0KPj4gT24gQXByIDE4LCAyMDE0LCBhdCA0OjU1IEFNLCBUaGVJcHY2Z3V5IC4gPGNi Lmxpc3Q2QGdtYWlsLmNvbT4gd3JvdGU6DQo+PiANCj4+PiAqZml4aW5nIHRoZSBzb2Z0d2lyZSBj aGFpciBlbWFpbCBhZGRyZXNzIHNpbmNlIGl0IGJvdW5jZWQuDQo+Pj4gDQo+Pj4gT24gRnJpLCBB cHIgNCwgMjAxNCBhdCA1OjQ0IFBNLCBGcmVkIEJha2VyIChmcmVkKSA8ZnJlZEBjaXNjby5jb20+ IHdyb3RlOg0KPj4+PiANCj4+Pj4gT24gQXByIDQsIDIwMTQsIGF0IDY6MzQgQU0sIENiIEIgPGNi Lmxpc3Q2QGdtYWlsLmNvbT4gd3JvdGU6DQo+Pj4+IA0KPj4+PiBIZWxsbyBmb2xrcywNCj4+Pj4g DQo+Pj4+IE5vIGZvbGxvdy11cCBpbiBhIHdlZWsuIEkgYXNzdW1lIHRoZSBiZWxvdyBleHBsYW5h dGlvbiBhbmQgDQo+Pj4+IGV4aXNpdGluZyB0ZXh0IGFyZSBvay4NCj4+Pj4gDQo+Pj4+IFRvIHJl c3RhdGUsIHRoaXMgSS1EIHNpbXBseSBnZW5lcmFsaXplcyB0aGUgc2NvcGUgb2YgMTkyLjAuMC4w LzI5LiAgDQo+Pj4+IFRoZXJlIGlzIG5vIGd1aWRhbmNlIG9uIGhvdyBzcGVjaWZpYyBhZGRyZXNz ZXMgbWF5IGJlIHVzZWQuIEl0IGlzIA0KPj4+PiBhc3N1bWVkIHRoZSBkZXBsb3lpbmcgcGFydHkg d2lsbCBub3QgY2F1c2UgYSBjb25mbGljdCBvbiB0aGUgaG9zdCANCj4+Pj4gYnkgYXNzaWdpbmcg dGhlIHNhbWUgYWRkcmVzcyB0byB0aGUgaG9zdCBtdWx0aXBscyB0aW1lcy4uLi4gYXMgdGhhdCAN Cj4+Pj4gaXMgYSBnZW5lcmFsIGlwIGNvbmZpZ3VyYXRpb24gcnVsZS4NCj4+Pj4gDQo+Pj4+IEkg d2lsbCBhc2sgdjZvcHMgdG8gYWNjZXB0IHRoaXMgaS1kIGFuZCBkaXJlY3QgdGhlbSB0byB0aGlz IHRocmVhZCANCj4+Pj4gdG8gc2VlIHRoZSBzb2Z0d2lyZSB2aWV3Lg0KPj4+PiANCj4+Pj4gDQo+ Pj4+IE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBzb2Z0d2lyZXMgd2FudHMgdG8gcHJvZ3Jlc3Mg dGhpcyBvbmUuIEkgDQo+Pj4+IGd1ZXNzIEnigJlkIGxpa2UgdG8gaGVhciBmcm9tIHRoZSBzb2Z0 d2lyZXMgY2hhaXJzIGJlZm9yZSBicmluZ2luZyBpdCBiYWNrLg0KPj4+PiANCj4+PiANCj4+PiAN Cj4+PiBGcmVkLA0KPj4+IA0KPj4+IEl0IGhhcyBiZWVuIDE0IGRheXMgc2luY2UgeW91ciAgZW1h aWwuICBJIGFtIG5vdCBzdXJlIGlmIHlvdSBzZW50IA0KPj4+IHRoZSBlbWFpbCB0byB0aGUgd3Jv bmcgYWRkcmVzcyBvZiBmaXhlZCBpdC4gIEVpdGhlciB3YXksIGkgd291bGQgDQo+Pj4gbGlrZSB0 byBtYWtlIHByb2dyZXNzIG9uIHRoaXMgSS1EIGluIHY2b3BzIHNpbmNlIHRoaXMgSS1EIGlzIGFi b3V0IGEgDQo+Pj4gZ2VuZXJhbGl6ZWQgYXBwcm9hY2ggdGhhdCBleGNlZWRzIHRoZSBib3VuZHMg b2Ygc29mdHdpcmVzLiAgVGhpcyBoYXMgDQo+Pj4gYWxzbyBiZWVuIHByZXNlbnRlZCB0d2ljZSBp biBwZXJzb24gdG8gdjZvcHMuDQo+Pj4gDQo+Pj4gQ2FtZXJvbg0KPj4+IA0KPj4+PiBDQg0KPj4+ PiANCj4+Pj4gT24gTWFyIDI5LCAyMDE0IDQ6NTkgQU0sICJDYiBCIiA8Y2IubGlzdDZAZ21haWwu Y29tPiB3cm90ZToNCj4+Pj4+IA0KPj4+Pj4gT24gVGh1LCBNYXIgMjcsIDIwMTQgYXQgMzozOCBQ TSwgRGF2ZSBUaGFsZXIgDQo+Pj4+PiA8ZHRoYWxlckBtaWNyb3NvZnQuY29tPg0KPj4+Pj4gd3Jv dGU6DQo+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+IEZyb206IFNv ZnR3aXJlcyBbbWFpbHRvOnNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg DQo+Pj4+Pj4+IENiIEINCj4+Pj4+Pj4gU2VudDogVGh1cnNkYXksIE1hcmNoIDI3LCAyMDE0IDEw OjU4IEFNDQo+Pj4+Pj4+IFRvOiBzb2Z0d2lyZXNAaWV0Zi5vcmcNCj4+Pj4+Pj4gU3ViamVjdDog W1NvZnR3aXJlc10gZHJhZnQtYnlybmUtdjZvcHMtY2xhdGlwLTAxDQo+Pj4+Pj4+IA0KPj4+Pj4+ PiBIaSBTb2Z0d2lyZXMsDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBBbGVzIHByZXNlbnRlZCBkcmFmdC1i eXJuZS12Nm9wcy1jbGF0aXAtMDEgaW4gc29mdHdpcmVzIGF0IHRoZSANCj4+Pj4+Pj4gbGFzdCBJ RVRGIG1lZXRpbmcuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBJIGFtIGF0dGVtcHRpbmcgdG8gaGF2ZSB0 aGlzIEktRCBhZG9wdGVkIGJ5IHY2b3BzLCBidXQgdjZvcHMgDQo+Pj4+Pj4+IHJlcXVlc3RlZCBm ZWVkYmFjayBmcm9tIHNvZnR3aXJlcyBmaXJzdC4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IFBlcnRhaW5p bmcgdG8gdGhlIG1pbnV0ZXMsIGkgd291bGQgbGlrZSB0byBhZGRyZXNzIHNvbWUgdG9waWNzIA0K Pj4+Pj4+PiB0byBtYWtlIHN1cmUgaXQgaXMgb2sgIGZvciB2Nm9wcyB0byBtb3ZlIGZvcndhcmQg d2l0aCBhZG9wdGlvbg0KPj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+IGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvd2cvc29mdHdpcmUvbWludXRlcz9pdGVtPW1pbnV0ZXMtODktc29mdHcNCj4+Pj4+ Pj4gaXJlLmh0bWwNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IFRoZSBhZGRyZXNzZXMsIGJvdGggaW4gRFMt bGl0ZSBhbmQgNDY0eGxhdCwgbmV2ZXIgYXBwZWFycyBvbiB0aGUgDQo+Pj4+Pj4+IHdpcmUgc28g dGhlcmUgaXMgbm8gY2hhbmNlIG9mIG92ZXJsYXAgb3IgY29sbGlzaW9uLg0KPj4+Pj4+IA0KPj4+ Pj4+IERpc2FncmVlLCB0aGF0IGNvbmNsdXNpb24gZG9lc24ndCBmb2xsb3cgKGFuZCBpbiBteSBl eHBlcmllbmNlIA0KPj4+Pj4+IGl0J3Mgd3JvbmcpLg0KPj4+Pj4+IE92ZXJsYXAvY29sbGlzaW9u IGhhcHBlbnMgd2hlbiB0aGVyZSBhcmUgdHdvIGludGVyZmFjZXMgb24gdGhlIHNhbWUgaG9zdA0K Pj4+Pj4+IChldmVuIGlmIHRoZXkncmUgbm90IGluIHVzZSBzaW11bHRhbmVvdXNseSkuICAgVGhl IGNvbGxpc2lvbnMgY2FuIGFmZmVjdA0KPj4+Pj4+IHRoZSByb3V0aW5nIHRhYmxlIChpZiB0aGUg aG9zdCBpbXBsZW1lbnRzIGluIHN1Y2ggYSB3YXkpLCBBQ0xzIA0KPj4+Pj4+IGxpa2UgaW4gaG9z dCBmaXJld2FsbCBwb2xpY2llcyBhbmQgc3VjaCwgYW5kIHZhcmlvdXMgYXBwbGljYXRpb24tbGF5 ZXIgdXNlcy4NCj4+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gQWgsIGkgc2VlIHlvdXIgcG9pbnQuICBJ ZiB0aGUgaG9zdCBpcyBpdHNlbGYgYm90aCBhIEI0IGFuZCBhIENMQVQgDQo+Pj4+PiBhdCB0aGUg c2FtZSB0aW1lLCB0aGVuIHRoaXMgY29sbGlzaW9uIG1heSBvY2N1ciB3aXRoaW4gdGhlIGhvc3Qs IA0KPj4+Pj4gbm90IG9uIHRoZSB3aXJlLg0KPj4+Pj4gDQo+Pj4+Pj4gSXQncyBmaW5lIHRvIHNw ZWNpZnkgdXNlIGFzIHRoZSBkZWZhdWx0IHJhbmdlIChlLmcuIGZvciA0NjR4bGF0IA0KPj4+Pj4+ IG9yDQo+Pj4+Pj4gRFMtbGl0ZSkgYnV0DQo+Pj4+Pj4gaW1wb3J0YW50IHRvIG5ldmVyIGNvbnN0 cmFpbiBpdCB0byBvbmx5IHRoYXQgcmFuZ2UsIGFzc3VtaW5nIHRoZSANCj4+Pj4+PiByYW5nZSBp cyBtYWRlIG5vbi1EUy1saXRlIHNwZWNpZmljLg0KPj4+Pj4+IA0KPj4+Pj4+IC1EYXZlDQo+Pj4+ PiANCj4+Pj4+IElzIHRoZXJlIHN1Y2ggYSBjb25zdHJhaW50IHRoYXQgd291bGQgY2F1c2UgYSBw cm9ibGVtPw0KPj4+Pj4gDQo+Pj4+PiBMb29raW5nIGF0IFJGQzYzMzMgYW5kIGRyYWZ0LWJ5cm5l LXY2b3BzLWNsYXRpcCwgaSBzZWUgdGhhdCANCj4+Pj4+IFJGQzYzMzMgc2F5cyB0aGUgQjQgU0hP VUxEIHVzZSAxOTIuMC4wLjIuICBUbyBhIHJhdGlvbmFsIHBlcnNvbiwgYSANCj4+Pj4+IGdvb2Qg cmVhc29uIHRvIG5vdCB1c2UgIDE5Mi4wLjAuMiBpcyB0aGF0IGl0IGlzIGluIHVzZSBmb3IgYSBD TEFUIA0KPj4+Pj4gaW50ZXJmYWNlIG9uIHRoZSBzYW1lIGhvc3QsIHdoaWNoIGZpdHMgd2l0aCB0 aGUgU0hPVUxEIHdvcmRpbmcuDQo+Pj4+PiANCj4+Pj4+IElzIHRoZXJlIHNvbWUgdGV4dCB0aGF0 IHlvdSBjb3VsZCBzdWdnZXN0IHRoYXQgbWF5IGNsYXJpZnkgdGhpcyANCj4+Pj4+IHNpdHVhdGlv biBpbiBkcmFmdC1ieXJuZS12Nm9wcy1jbGF0aXAgb3IgaXMgaXQgb2sgZm9yIHY2b3BzIHRvIA0K Pj4+Pj4gYWRvcHQgYXMtaXM/ICBBcyBpdCBzdGFuZHMsIHRoZSBJLUQgc2ltcGx5IHNheXMgdGhh dCAxOTIuMC4wLjAvMjkgDQo+Pj4+PiB3aWxsIGJlIGdlbmVyYWxpemVkIHdpdGhvdXQgbWFraW5n IGFueSBmdXJ0aGVyIHN0YXRlbWVudHMgaG93IA0KPj4+Pj4gYWRkcmVzc2VzIG1heSBiZSB1c2Vk IHdpdGhpbiB0aGF0IHJhbmdlLg0KPj4+Pj4gDQo+Pj4+PiBDQg0KPj4+PiANCj4+Pj4gDQo+Pj4+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K Pj4+PiA4IGlzc3VlcyBpbiB2aXJ0dWFsIGluZnJhc3RydWN0dXJlDQo+Pj4+IGh0dHA6Ly9kY3Jv Y2tlci5uZXQvI2ZhbGxhY2llcw0KPj4+PiANCj4+IA0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiA4IGlzc3VlcyBpbiB2aXJ0dWFs IGluZnJhc3RydWN0dXJlDQo+PiBodHRwOi8vZGNyb2NrZXIubmV0LyNmYWxsYWNpZXMNCj4+IA0K PiANCj4gDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KOCBpc3N1ZXMgaW4gdmlydHVhbCBpbmZyYXN0cnVjdHVyZQ0KaHR0cDovL2Rjcm9j a2VyLm5ldC8jZmFsbGFjaWVzDQoNCg0KTk9USUNFIEFORCBESVNDTEFJTUVSDQpUaGlzIGUtbWFp bCAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgaXMgaW50ZW5kZWQgZm9yIHRoZSBhYm92ZS1u YW1lZCBwZXJzb24ocykuICBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSwgZGVsZXRlIHRoaXMgZW1haWwgZnJvbSB5b3Vy IHN5c3RlbSBhbmQgZG8gbm90IGRpc2Nsb3NlIG9yIHVzZSBmb3IgYW55IHB1cnBvc2UuICANCiAN CldlIG1heSBtb25pdG9yIGFsbCBpbmNvbWluZyBhbmQgb3V0Z29pbmcgZW1haWxzIGluIGxpbmUg d2l0aCBjdXJyZW50IGxlZ2lzbGF0aW9uLiBXZSBoYXZlIHRha2VuIHN0ZXBzIHRvIGVuc3VyZSB0 aGF0IHRoaXMgZW1haWwgYW5kIGF0dGFjaG1lbnRzIGFyZSBmcmVlIGZyb20gYW55IHZpcnVzLCBi dXQgaXQgcmVtYWlucyB5b3VyIHJlc3BvbnNpYmlsaXR5IHRvIGVuc3VyZSB0aGF0IHZpcnVzZXMg ZG8gbm90IGFkdmVyc2VseSBhZmZlY3QgeW91LiANCg0KRUUgTGltaXRlZA0KUmVnaXN0ZXJlZCBp biBFbmdsYW5kIGFuZCBXYWxlcw0KQ29tcGFueSBSZWdpc3RlcmVkIE51bWJlcjogMDIzODIxNjEN ClJlZ2lzdGVyZWQgT2ZmaWNlIEFkZHJlc3M6IFRyaWRlbnQgUGxhY2UsIE1vc3F1aXRvIFdheSwg SGF0ZmllbGQsIEhlcnRmb3Jkc2hpcmUsIEFMMTAgOUJXDQo= From nobody Tue Apr 22 08: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 51CB21A066B for ; Tue, 22 Apr 2014 08:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 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.272, 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 dRunHpK3UdkL for ; Tue, 22 Apr 2014 08:32:30 -0700 (PDT) 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 0DC781A0676 for ; Tue, 22 Apr 2014 08:32:30 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id rl12so5412448iec.32 for ; Tue, 22 Apr 2014 08:32:24 -0700 (PDT) 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=XKo6J75irth7MB+ISrzrPr7o+UzwEyxlm71aXyVe5B4=; b=YuRUJIfKBIn79exY/1Vf5U6ICBdNQ1irO6t7ykqIERsrExJLyyQyiYtPhCKPj3Frpe 3btR9iInzEiD3guRklvQ2WpK0IwGkZIAtI8vQhrRBfJu56XxA+Xl7+IBQhWbMxo36aDq /FAifbQ3lZ+giLK+8cy/2kGTWKx9LSCs39aB+QAd691QuwwrwaLIvUPbTHfpipWCvh8P w20Pap3BVmDmYvVPOmZ7cRTpt7GrXYS+SgaFWjRDF4Uy55sJYBwalTG8f395pVJTAp0w sDG2bE8+AfTglpjkskUXOQDlNOqUR8NnHj3eJS3z2Yaqz37v3wTqMQHlFO7y+rYI0ImN xBHw== 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=XKo6J75irth7MB+ISrzrPr7o+UzwEyxlm71aXyVe5B4=; b=T0offUJ6j+qBu14I0uEUOZoQ6GiVY1m9vFBJtxOXvBRQSfoWK0GozF9ViuFNChk5Mv /OpsEM3ZbB8GS3AAPXq/UD38FFlbJYunjGaDZRe7MRpOMJh21AZU0t9OOOciKq7aYvfq qE9tml8DQKytt7XvlDe8PHsG868//+zYcQW9r/GC7xooPsLwN7ztfpwlv8672oabju7a owvQ6Nh6FUnJwxOga2BLrLUNB5I7DNBL+8+UzRYwoHXGsGuUjCrz0GFRYMV68I2sjtzy QWwoz+tcf5F+mvlsXM73DTKpsgjm58TJVmlvhclKiqznqa/LqmdPVCHP13PWbrh9LGgn pOQQ== X-Gm-Message-State: ALoCoQlyjbzHXDnj2IWALqCmgs8QPMwRSmONjoOfVc9XHajQLkP5MlIFSb+szc6u3lS4ng2RDAU7ObAWPC39TNYra1CdbOgeL3DI7yoFUrBwvA9MG1RqPG+zgxj71rOiiTBGjwlvMWPNtfFev0uLR8PEijPyGsHrVEBPvu/7WA5i9Pc8BfX6FoX2uG5Pi6Zp6BOnTtN/GS94 X-Received: by 10.50.119.132 with SMTP id ku4mr30385023igb.35.1398180744405; Tue, 22 Apr 2014 08:32:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.106.225 with HTTP; Tue, 22 Apr 2014 08:32:04 -0700 (PDT) In-Reply-To: <118D079B-FC99-4606-B289-4201137A5815@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> <4EABCE38-7CBA-4C95-84EE-686A2300F26E@delong.com> <8E450CDC-FFC5-4649-89FE-387836C8E40B@nominum.com> <118D079B-FC99-4606-B289-4201137A5815@nominum.com> From: Lorenzo Colitti Date: Wed, 23 Apr 2014 00:32:04 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=001a1134428e9ab12904f7a3523a Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/kkFgocL7pgzmutVih4DIzw2sbE4 Cc: Philip Homburg , "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 22 Apr 2014 15:32:34 -0000 --001a1134428e9ab12904f7a3523a Content-Type: text/plain; charset=UTF-8 On Wed, Apr 23, 2014 at 12:17 AM, Ted Lemon wrote: > In order to prevent DHCPv4-based attacks on the local wire, you must > filter bad DHCPv4 packets. If you are filtering bad DHCPv4 packets on the > wire, filtering bad RA packets is doable as well. > In networks that support only IPv4, filtering DHCPv4 packets is probably supported. Filtering DHCPv6 or RA packets may not be supported and may require hardware upgrades. On such networks, the damage from rogue DHCPv6 or RA packets is mitigated by happy eyeballs. The damage from rogue "shut down your entire IPv4 stack" options cannot be. > I already addressed this point and the others you made in previous > comments. > Did you? IIRC, all you said was, "let's wait for the next version of the draft". > This conversation has gotten extremely repetitive. > It takes two to make a quarrel. --001a1134428e9ab12904f7a3523a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On W= ed, Apr 23, 2014 at 12:17 AM, Ted Lemon <ted.lemon@nominum.com>= wrote:
    In order to prevent DHCPv4-b= ased attacks on the local wire, you must filter bad DHCPv4 packets. =C2=A0 = If you are filtering bad DHCPv4 packets on the wire, filtering bad RA packe= ts is doable as well.

    In networks that support only IPv4, filter= ing DHCPv4 packets is probably supported. Filtering DHCPv6 or RA packets ma= y not be supported and may require hardware upgrades. On such networks, the= damage from rogue DHCPv6 or RA packets is mitigated by happy eyeballs. The= damage from rogue "shut down your entire IPv4 stack" options can= not be.
    =C2=A0
    I already a= ddressed this point and the others you made in previous comments.

    Did you? IIRC, all you said was, "let's wait f= or the next version of the draft".
    =C2=A0
    This conversation has gotten extremely repetitive.

    It takes two to make a quarrel.
    --001a1134428e9ab12904f7a3523a-- From nobody Tue Apr 22 08:39: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 266671A0686 for ; Tue, 22 Apr 2014 08:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 dHZ00sBMD-SS for ; Tue, 22 Apr 2014 08:39:18 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id CBBF71A0677 for ; Tue, 22 Apr 2014 08:39:18 -0700 (PDT) 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 C22A91B803F for ; Tue, 22 Apr 2014 08:39:13 -0700 (PDT) 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 B7BEF19005C; Tue, 22 Apr 2014 08:39:13 -0700 (PDT) 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; Tue, 22 Apr 2014 08:39:13 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: Date: Tue, 22 Apr 2014 11:39:11 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> <4EABCE38-7CBA-4C95-84EE-686A2300F26E@delong.com> <8E450CDC-FFC5-4649-89FE-387836C8E40B@nominum.com> <118D079B-FC99-4606-B289-4201137A5815@nominum.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/VSpfCH_HvxudBj6QDFoR_s8ncoI Cc: Philip Homburg , "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 22 Apr 2014 15:39:21 -0000 On Apr 22, 2014, at 11:32 AM, Lorenzo Colitti = wrote: > In networks that support only IPv4, filtering DHCPv4 packets is = probably supported. Filtering DHCPv6 or RA packets may not be supported = and may require hardware upgrades. On such networks, the damage from = rogue DHCPv6 or RA packets is mitigated by happy eyeballs. The damage = from rogue "shut down your entire IPv4 stack" options cannot be. Do you have data on this, or is it just supposition? From nobody Tue Apr 22 09:06: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 984811A069C for ; Tue, 22 Apr 2014 09:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3tFqhqg8tLoI for ; Tue, 22 Apr 2014 09:06:39 -0700 (PDT) Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) by ietfa.amsl.com (Postfix) with ESMTP id E5B581A069A for ; Tue, 22 Apr 2014 09:06:38 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w61so5254154wes.1 for ; Tue, 22 Apr 2014 09:06:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:message-id:from:to:cc:subject:in-reply-to :references:user-agent:mime-version:content-type; bh=MPjtGToZtpU+EGs/gMybCW6nilL+zQKn8g3IbqVG9l8=; b=PeUlEYBAOeSPab9eFUMxIV1i9E30ZiwJ/v639auJpEhGSLeGeW5szE+xO3xJg66SSx f8Xky0kwb/TAeZmpQE4L/G5uc3fjUSlfXnUt1/O9ZWUalDcAIwFzcs79ZCXcrL/F+Z4V +8lIa928VtsRXK6Qxjn+3+rFAf4hlLywJ+GICFBowmWVyGE8BaVA+QanWV4udzDVOfey vz2uFtdRCQ8bqnuMLOPV3E1x/mp1jG5bUkm6upmHKYJTm8u1sbLb8bH6J6kP1U9VpDJ7 S3Hkl9n4MCO5pGXnJDj7KAI5NLETYz9fn9Kwd9P0I5CCRsGxpjE30y5B70XhzHmVCqYh W9OQ== X-Gm-Message-State: ALoCoQmet03tr+99H2v91VMz0Vj/DjhrSuR7BJfdzY3jJVmzJFSd7GcUjEnjy/JzbkLrketPcczB X-Received: by 10.180.24.72 with SMTP id s8mr19502194wif.20.1398182793124; Tue, 22 Apr 2014 09:06:33 -0700 (PDT) Received: from dhcp-c101a625.ucd.ie.ucd.ie ([2001:770:98:e05:914d:d79:1039:6527]) by mx.google.com with ESMTPSA id u8sm62498712wjq.1.2014.04.22.09.06.31 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Apr 2014 09:06:32 -0700 (PDT) Date: Tue, 22 Apr 2014 17:07:13 +0100 Message-ID: From: "Niall O'Reilly" To: Ted Lemon In-Reply-To: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> <4EABCE38-7CBA-4C95-84EE-686A2300F26E@delong.com> <8E450CDC-FFC5-4649-89FE-387836C8E40B@nominum.com> <118D079B-FC99-4606-B289-4201137A5815@nominum.com> <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/uV_Ub22heLKu5klb-k6Zk9gdVLU Cc: Philip Homburg , "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 22 Apr 2014 16:06:40 -0000 At Tue, 22 Apr 2014 11:39:11 -0400, Ted Lemon wrote: > > On Apr 22, 2014, at 11:32 AM, Lorenzo Colitti wrote: > > In networks that support only IPv4, filtering DHCPv4 packets is > > probably supported. Confirmed from personal experience on the campus network where I work. > > Filtering DHCPv6 or RA packets may not be > > supported and may require hardware upgrades. Confirmed as mentioned above. > > On such networks, the > > damage from rogue DHCPv6 or RA packets is mitigated by happy > > eyeballs. I cannot personally confirm this. > > The damage from rogue "shut down your entire IPv4 stack" > > options cannot be. None of us can confirm this, as it depends on future client implementation. > Do you have data on this, or is it just supposition? I expect that the two points I was able to confirm above are widely known among those who have tried to implement IPv6 on an existing IPv4-only network. Best regards, Niall O'Reilly From nobody Tue Apr 22 09:13: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 5C62E1A018E for ; Tue, 22 Apr 2014 09:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 UarIEMc70TVU for ; Tue, 22 Apr 2014 09:12:56 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id D1A2F1A03A1 for ; Tue, 22 Apr 2014 09:12:56 -0700 (PDT) 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 A33DA1B8055 for ; Tue, 22 Apr 2014 09:12:51 -0700 (PDT) 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 9CB3F19005C; Tue, 22 Apr 2014 09:12:51 -0700 (PDT) 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; Tue, 22 Apr 2014 09:12:51 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: Date: Tue, 22 Apr 2014 12:12:48 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> <4EABCE38-7CBA-4C95-84EE-686A2300F26E@delong.com> <8E450CDC-FFC5-4649-89FE-387836C8E40B@nominum.com> <118D079B-FC99-4606-B289-4201137A5815@nominum.com> <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> To: Niall O'Reilly X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8pCrJ8B8IFYMvwt9tvIv7U1NFKY Cc: Philip Homburg , "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 22 Apr 2014 16:13:01 -0000 On Apr 22, 2014, at 12:07 PM, Niall O'Reilly = wrote: >>> On such networks, the >>> damage from rogue DHCPv6 or RA packets is mitigated by happy >>> eyeballs. >=20 > I cannot personally confirm this. I think this would protect from RA-based DoS, but not RA-based MiTM. = RA-based MiTM would be better if it could shut off IPv4, but will still = work some of the time (or possibly all of the time) even if IPv4 is = present. > I expect that the two points I was able to confirm above are widely > known among those who have tried to implement IPv6 on an existing > IPv4-only network. Thanks. So is it the case that there is a UI element that says = "disable DHCPv4 except from the following IP source addresses/on the = following physical ports," and the switch has no way to for instance = disable arbitrary ethertypes? From nobody Tue Apr 22 10:04: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 4BDBB1A06A8 for ; Tue, 22 Apr 2014 10:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] 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 EMuEf87xcHkP for ; Tue, 22 Apr 2014 10:04:42 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id B6D391A06A5 for ; Tue, 22 Apr 2014 10:04:41 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1Wce7X-0000CDC; Tue, 22 Apr 2014 19:04:35 +0200 Message-Id: To: Ted Lemon From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> <4EABCE38-7CBA-4C95-84EE-686A2300F26E@delong.com> <8E450CDC-FFC5-4649-89FE-387836C8E40B@nominum.com> <118D079B-FC99-4606-B289-4201137A5815@nominum.com> In-reply-to: Your message of "Tue, 22 Apr 2014 11:17:27 -0400 ." <118D079B-FC99-4606-B289-4201137A5815@nominum.com> Date: Tue, 22 Apr 2014 19:04:32 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/vo34vY7-qlyUHUYtj2EQeAWVAqY Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 22 Apr 2014 17:04:45 -0000 In your letter dated Tue, 22 Apr 2014 11:17:27 -0400 you wrote: >I already addressed this point and the others you made in previous >comments. I hope I can take from this that the only substantial documented advantage of DHCPv6/RA over DHCPv4 is that the DHCPv4 approach would require a small stub DHCPv4 implementation in future routers that lack IPv4 support. If this is indeed correct, then I will leave to the sunset4 WG to decide how to move forward. In my expectation, host operating systems will either not implement this RFC or leave it disabled by default, defeating its purpose. At least for me, this discussion provides enough arguments why it is a bad idea to ship with this enabled by default. From nobody Tue Apr 22 13:03: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 A1FDC1A00E5 for ; Tue, 22 Apr 2014 13:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.263 X-Spam-Level: X-Spam-Status: No, score=-1.263 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.272, 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 Ur4Oi5qYSGk1 for ; Tue, 22 Apr 2014 13:03:34 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id E5DA21A006E for ; Tue, 22 Apr 2014 13:03:33 -0700 (PDT) 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 s3MK0UXf019173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 22 Apr 2014 13:00:32 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3MK0UXf019173 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1398196834; bh=2XZ9FVa5PWPVOeHZRPCMKP3pMFY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=WyVjCbYYY2IjlPJGyFBOGE8t1y4yYKwfqNqvcmrmvyK9W7M+EPnH5ogS3zx+DprBW xvuDk7awYkjSUt/dr6t4B5gavnTtwBrp98phKwHVYdbkzTvbsYGB2VULqhebGwP+kl vD1VsJBLO/BWzanf/Ap5z1vkreyfU8z0RrNML0nk= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: <53566D59.7000202@viagenie.ca> Date: Tue, 22 Apr 2014 13:04:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> <4EABCE38-7CBA-4C95-84EE-686A2300F26E@delong.com> <8E450CDC-FFC5-4649-89FE-387836C8E40B@nominum.com> <53566D59.7000202@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 22 Apr 2014 13:00:34 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/aw1Puf7zco719P1-_spTf31Ra0Q Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 22 Apr 2014 20:03:39 -0000 On Apr 22, 2014, at 6:23 AM, Simon Perreault = wrote: > Le 2014-04-22 09:00, George, Wes a =E9crit : >> WG] I think that there=92s a need for clarification here. A lot of = this >> discussion has focused almost exclusively on the full-on disabling of >> IPv4. Part of what the draft discusses is that there are differing >> things that can be signaled to the local devices from the network = based >> on the bit set in the proposed option. There is an option that simply >> signals =93there is no IPv4 support on this network=94 and makes = attendant >> recommendations that the device decide on its own what to do for any >> local IPv4 traffic on the LAN, including doing nothing, configuring = 169 >> addresses, etc. but that it should disable IPv4 on the upstream >> interface facing the network that provided the signal (I.e. Stop >> forwarding IPv4 traffic and stop sending DHCPv4).=20 >> I=92m willing to go with consensus (if exist) that the more = aggressive >> option of something like a full-on IPv4 killswitch that affects more >> than one interface and affects the local network is a bridge too far, >> both for security reasons (It=92ll be hard to secure to a level that >> exploits aren=92t likely) and because it gets into a question about >> autonomy and span of control. But I think it=92s worth highlighting = that >> there are also less aggressive options discussed in the draft, and = I=92d >> like to have some sense that those are mostly on the right track, and >> your statement is so broad that I wanted to get clarification on what >> you think of this. >=20 > Right. >=20 > To be very explicit, one of the "less aggressive" options on the table > is to specify a "there is no IPv4 on this network" signal while saying > nothing about how a host should react to this signal. Each > implementation could use that hint however it sees fit. Because IPv6 deployment has been helped so much in the past by ambiguous = standards which allow wildly different implementations from vendor to = vendor. If we=92re going to specify a signal, we should specify what the host = should do with that signal. Owen From nobody Tue Apr 22 13:08: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 292C41A019F for ; Tue, 22 Apr 2014 13:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.824 X-Spam-Level: X-Spam-Status: No, score=-0.824 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] 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 UdlRwui3GPtI for ; Tue, 22 Apr 2014 13:08:30 -0700 (PDT) Received: from mail19.svc.cra.dublin.eircom.net (mail19.svc.cra.dublin.eircom.net [159.134.118.218]) by ietfa.amsl.com (Postfix) with SMTP id D255E1A016E for ; Tue, 22 Apr 2014 13:08:27 -0700 (PDT) Received: (qmail 46500 messnum 998013 invoked from network[213.94.190.12/avas01.vendorsvc.cra.dublin.eircom.net]); 22 Apr 2014 20:08:21 -0000 Received: from avas01.vendorsvc.cra.dublin.eircom.net (213.94.190.12) by mail19.svc.cra.dublin.eircom.net (qp 46500) with SMTP; 22 Apr 2014 20:08:21 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas01.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id t88D1n0040mJ9Tz0188Kz4; Tue, 22 Apr 2014 21:08:21 +0100 From: Ross Chandler Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 22 Apr 2014 21:08:18 +0100 To: v6ops@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ERXSHKj1KlFL0WQkAF_aKdVuFV8 Subject: [v6ops] 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: Tue, 22 Apr 2014 20:08:34 -0000 Would also like to see this advance. Ross -----Original Message----- From: v6ops [mailto:v6ops-bounces at ietf.org] On Behalf Of Fred Baker = (fred) Sent: 21 April 2014 17:16 To: V6 Ops List Subject: [v6ops] draft-byrne-v6ops-clatip-01 Following up from the recent meeting. We discussed clatip. The outcome was that we wanted to know what = softwire wanted done with it, and I took the action to ask.=20 The response from the softwire chairs was that they wanted to consider = the draft there, and advance it from there. However, it appears to be = bottlenecked. So, the softwire chairs have stepped back. I want the opinion of v6ops. Do we need this, or not? If we need this, = we should adopt it, and then (I think) go to an immediate WGLC and = potentially advance it. If it=E2=80=99s not needed, we should say it is = not needed. Please reply in this thread. On Apr 21, 2014, at 5:55 AM, Yong Cui = wrote: > Hi Fred, >=20 > Thanks for your email and reminding. >=20 > You are right that we are glad to take this work in Softwire as we = discussed in March. However, for some reasons we need to focus on MAP = package Eventually. There is the consensus that Softwire will NOT take = any new work before we submit the MAP package to IESG. There are even = some other wg items blocked in Softwire at this moment. We are trying to = solve the MAP issues asap and accelerate the process. But I'm afraid we = still need some time. >=20 > So if you'd like to take this work in v6ops, please do so. Otherwise, = we still need to wait for some time before taking it in Softwire. >=20 > Thanks for understanding and let us know your decision. >=20 > Yong >=20 > On 2014-4-19, at =E4=B8=8A=E5=8D=8812:23, Fred Baker (fred) wrote: >=20 >> Softwire chairs: >>=20 >> In March, you indicated that you wanted to progress this in softwire. = The authors haven=E2=80=99t heard from you and are looking for guidance. = Pick one: do you want it, or do you want it done for you? >>=20 >> Fred >>=20 >>=20 >> On Apr 18, 2014, at 4:55 AM, TheIpv6guy . = wrote: >>=20 >>> *fixing the softwire chair email address since it bounced. >>>=20 >>> On Fri, Apr 4, 2014 at 5:44 PM, Fred Baker (fred) wrote: >>>>=20 >>>> On Apr 4, 2014, at 6:34 AM, Cb B wrote: >>>>=20 >>>> Hello folks, >>>>=20 >>>> No follow-up in a week. I assume the below explanation and=20 >>>> exisiting text are ok. >>>>=20 >>>> To restate, this I-D simply generalizes the scope of 192.0.0.0/29. =20= >>>> There is no guidance on how specific addresses may be used. It is=20= >>>> assumed the deploying party will not cause a conflict on the host=20= >>>> by assiging the same address to the host multipls times.... as that=20= >>>> is a general ip configuration rule. >>>>=20 >>>> I will ask v6ops to accept this i-d and direct them to this thread=20= >>>> to see the softwire view. >>>>=20 >>>>=20 >>>> My understanding is that softwires wants to progress this one. I=20 >>>> guess I=E2=80=99d like to hear from the softwires chairs before = bringing it back. >>>>=20 >>>=20 >>>=20 >>> Fred, >>>=20 >>> It has been 14 days since your email. I am not sure if you sent=20 >>> the email to the wrong address of fixed it. Either way, i would=20 >>> like to make progress on this I-D in v6ops since this I-D is about a=20= >>> generalized approach that exceeds the bounds of softwires. This has=20= >>> also been presented twice in person to v6ops. >>>=20 >>> Cameron >>>=20 >>>> CB From nobody Tue Apr 22 13:16: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 895D11A014D for ; Tue, 22 Apr 2014 13:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 3wBxhRS2MECN for ; Tue, 22 Apr 2014 13:16:01 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id BEF0A1A0240 for ; Tue, 22 Apr 2014 13:16:01 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:15b:212f:d481:de2b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0FAEE40221; Tue, 22 Apr 2014 16:15:55 -0400 (EDT) Message-ID: <5356CDFB.1050802@viagenie.ca> Date: Tue, 22 Apr 2014 16:15:55 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Owen DeLong References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> <4EABCE38-7CBA-4C95-84EE-686A2300F26E@delong.com> <8E450CDC-FFC5-4649-89FE-387836C8E40B@nominum.com> <53566D59.7000202@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/o1fzQyprSW7b2hyD97fOxWF95BY Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 22 Apr 2014 20:16:06 -0000 Le 2014-04-22 16:04, Owen DeLong a écrit : >> To be very explicit, one of the "less aggressive" options on the table >> is to specify a "there is no IPv4 on this network" signal while saying >> nothing about how a host should react to this signal. Each >> implementation could use that hint however it sees fit. > > Because IPv6 deployment has been helped so much in the past by ambiguous standards which allow wildly different implementations from vendor to vendor. > > If we’re going to specify a signal, we should specify what the host should do with that signal. FWIW, I fully agree. I felt that it would only be fair to mention that option which has been suggested by others in the past. 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 nobody Tue Apr 22 23:20: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 94E511A0329 for ; Tue, 22 Apr 2014 23:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.375 X-Spam-Level: * X-Spam-Status: No, score=1.375 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 Bq839UMU7dku for ; Tue, 22 Apr 2014 23:20:24 -0700 (PDT) Received: from ctxmailhub.t-mobile.cz (ctxmailhub.t-mobile.cz [93.153.104.87]) by ietfa.amsl.com (Postfix) with ESMTP id 509561A0096 for ; Tue, 22 Apr 2014 23:20:23 -0700 (PDT) From: =?utf-8?B?VsOtemRhbCBBbGXFoQ==?= To: "Fred Baker (fred)" , V6 Ops List Date: Wed, 23 Apr 2014 08:20:14 +0200 Thread-Topic: draft-byrne-v6ops-clatip-01 Thread-Index: AQHPXX0GoCnfuCMMckahK1B0I3gQqZseuhew Message-ID: <1808340F7EC362469DDFFB112B37E2FCDA3321EDF1@SRVHKE02.rdm.cz> References: <852615d6f8d742a095d2701496c62275@BY2PR03MB412.namprd03.prod.outlook.com> <37C0752F-8766-43BF-AD3E-29EBB64FED96@tsinghua.edu.cn> <9B724115-1AA3-423C-A0F2-658285D5F43D@cisco.com> In-Reply-To: <9B724115-1AA3-423C-A0F2-658285D5F43D@cisco.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forwarded Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ZlPy7ph53ThxYtGIEVqFuHCZL_M Subject: Re: [v6ops] 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: Wed, 23 Apr 2014 06:20:31 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3Bz LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBGcmVkDQo+IEJha2VyIChmcmVkKQ0KPiBT ZW50OiBNb25kYXksIEFwcmlsIDIxLCAyMDE0IDY6MTYgUE0NCj4gVG86IFY2IE9wcyBMaXN0DQo+ IFN1YmplY3Q6IFt2Nm9wc10gZHJhZnQtYnlybmUtdjZvcHMtY2xhdGlwLTAxDQo+DQo+IEZvbGxv d2luZyB1cCBmcm9tIHRoZSByZWNlbnQgbWVldGluZy4NCj4NCj4gV2UgZGlzY3Vzc2VkIGNsYXRp cC4gVGhlIG91dGNvbWUgd2FzIHRoYXQgd2Ugd2FudGVkIHRvIGtub3cNCj4gd2hhdCBzb2Z0d2ly ZSB3YW50ZWQgZG9uZSB3aXRoIGl0LCBhbmQgSSB0b29rIHRoZSBhY3Rpb24gdG8NCj4gYXNrLg0K Pg0KPiBUaGUgcmVzcG9uc2UgZnJvbSB0aGUgc29mdHdpcmUgY2hhaXJzIHdhcyB0aGF0IHRoZXkg d2FudGVkIHRvDQo+IGNvbnNpZGVyIHRoZSBkcmFmdCB0aGVyZSwgYW5kIGFkdmFuY2UgaXQgZnJv bSB0aGVyZS4gSG93ZXZlciwNCj4gaXQgYXBwZWFycyB0byBiZSBib3R0bGVuZWNrZWQuIFNvLCB0 aGUgc29mdHdpcmUgY2hhaXJzIGhhdmUNCj4gc3RlcHBlZCBiYWNrLg0KPg0KPiBJIHdhbnQgdGhl IG9waW5pb24gb2YgdjZvcHMuIERvIHdlIG5lZWQgdGhpcywgb3Igbm90PyBJZiB3ZQ0KPiBuZWVk IHRoaXMsIHdlIHNob3VsZCBhZG9wdCBpdCwgYW5kIHRoZW4gKEkgdGhpbmspIGdvIHRvIGFuDQo+ IGltbWVkaWF0ZSBXR0xDIGFuZCBwb3RlbnRpYWxseSBhZHZhbmNlIGl0LiBJZiBpdOKAmXMgbm90 DQo+IG5lZWRlZCwgd2Ugc2hvdWxkIHNheSBpdCBpcyBub3QgbmVlZGVkLg0KPg0KPiBQbGVhc2Ug cmVwbHkgaW4gdGhpcyB0aHJlYWQuDQoNCjE5Mi4wLjAuMC8yOSBzZWVtcyB0byBiZSBhIG5hdHVy YWwgY2hvaWNlIGZvciBJUHY2IHRyYW5zaXRpb24NCnNvbHV0aW9ucyB0aGF0IHJlcXVpcmUgYSBu b24tcm91dGVkIG51bWJlcmVkIElQdjQgaW50ZXJmYWNlLg0KKHN1Y2ggYXMgNDY0WExBVCkNCg0K SSBzdXBwb3J0IGFkdmFuY2luZyBvZiB0aGlzIHdvcmsuDQoNCkFsZXMNCg0KWsOhc2FkeSBrb211 bmlrYWNlLCBrdGVyw6kgc3BvbGXEjW5vc3QgVC1Nb2JpbGUgQ3plY2ggUmVwdWJsaWMgYS5zLiB1 xb7DrXbDoSBwxZlpIHNqZWRuw6F2w6Fuw60gc21sdXYsIGpzb3UgdXZlZGVueSB6ZGUgIGh0dHA6 Ly93d3cudC1tb2JpbGUuY3ovemFzYWR5LiBOZW7DrS1saSB2IHrDoXNhZMOhY2ggdXZlZGVubyBq aW5haywgbmVwxZllZHN0YXZ1amUgdGF0byB6cHLDoXZhIGtvbmXEjW7DvSBuw6F2cmggbmEgdXph dsWZZW7DrSDEjWkgem3Em251IHNtbG91dnkgYW5pIHDFmWlqZXTDrSB0YWtvdsOpaG8gbsOhdnJo dS4gVGhlIGNvbW11bmljYXRpb24gcHJpbmNpcGxlcyB3aGljaCBULU1vYmlsZSBDemVjaCBSZXB1 YmxpYyBhLnMuIGFwcGxpZXMgd2hlbiBuZWdvdGlhdGluZyBjb250cmFjdHMgYXJlIGRlZmluZWQg aGVyZSBodHRwOi8vd3d3LnQtbW9iaWxlLmN6L3ByaW5jaXBsZXMuIFVubGVzcyBvdGhlcndpc2Ug c3RhdGVkIGluIHRoZSBwcmluY2lwbGVzLCB0aGlzIG1lc3NhZ2UgZG9lcyBub3QgY29uc3RpdHV0 ZSB0aGUgZmluYWwgb2ZmZXIgdG8gY29udHJhY3Qgb3IgYW4gYW1lbmRtZW50IG9mIGEgY29udHJh Y3Qgb3IgYWNjZXB0YW5jZSBvZiBzdWNoIG9mZmVyLg0K From nobody Tue Apr 22 23:31: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 6BDF01A0331 for ; Tue, 22 Apr 2014 23:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] 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 QFwPlvZXL_6R for ; Tue, 22 Apr 2014 23:31:48 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id AE3F41A0091 for ; Tue, 22 Apr 2014 23:31:47 -0700 (PDT) Received: from he111511.emea1.cds.t-internal.com ([10.206.92.114]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 23 Apr 2014 08:31:40 +0200 Received: from HE111490.emea1.cds.t-internal.com ([10.206.92.87]) by HE111511.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 23 Apr 2014 08:31:40 +0200 From: To: Date: Wed, 23 Apr 2014 08:31:38 +0200 Thread-Topic: draft-byrne-v6ops-clatip-01 Thread-Index: AQHPXX0GoCnfuCMMckahK1B0I3gQqZsev+Ng Message-ID: References: <852615d6f8d742a095d2701496c62275@BY2PR03MB412.namprd03.prod.outlook.com> <37C0752F-8766-43BF-AD3E-29EBB64FED96@tsinghua.edu.cn> <9B724115-1AA3-423C-A0F2-658285D5F43D@cisco.com> In-Reply-To: <9B724115-1AA3-423C-A0F2-658285D5F43D@cisco.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/HJ_NPz2mDojnrRIid2s35EE6LLU Subject: Re: [v6ops] 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: Wed, 23 Apr 2014 06:31:53 -0000 SGVsbG8gKiwNCg0KeWVzLCBJIHdvdWxkIGxpa2UgdG8gc2VlIHRoaXMgYWR2YW5jZWQgcGxlYXNl LiBOZWNlc3NhcnkgdG8gYnJpbmcgZm9yd2FyZCBJUHY2LW9ubHkgYWNjZXNzIHNvbHV0aW9ucyBy ZWxpYWJseS4NCg0KSG9sZ2VyDQoNCg0KLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0t LQ0KVm9uOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIEltIEF1ZnRyYWcg dm9uIEZyZWQgQmFrZXIgKGZyZWQpDQpHZXNlbmRldDogTW9udGFnLCAyMS4gQXByaWwgMjAxNCAx ODoxNg0KQW46IFY2IE9wcyBMaXN0DQpCZXRyZWZmOiBbdjZvcHNdIGRyYWZ0LWJ5cm5lLXY2b3Bz LWNsYXRpcC0wMQ0KDQpGb2xsb3dpbmcgdXAgZnJvbSB0aGUgcmVjZW50IG1lZXRpbmcuDQoNCldl IGRpc2N1c3NlZCBjbGF0aXAuIFRoZSBvdXRjb21lIHdhcyB0aGF0IHdlIHdhbnRlZCB0byBrbm93 IHdoYXQgc29mdHdpcmUgd2FudGVkIGRvbmUgd2l0aCBpdCwgYW5kIEkgdG9vayB0aGUgYWN0aW9u IHRvIGFzay4gDQoNClRoZSByZXNwb25zZSBmcm9tIHRoZSBzb2Z0d2lyZSBjaGFpcnMgd2FzIHRo YXQgdGhleSB3YW50ZWQgdG8gY29uc2lkZXIgdGhlIGRyYWZ0IHRoZXJlLCBhbmQgYWR2YW5jZSBp dCBmcm9tIHRoZXJlLiBIb3dldmVyLCBpdCBhcHBlYXJzIHRvIGJlIGJvdHRsZW5lY2tlZC4gU28s IHRoZSBzb2Z0d2lyZSBjaGFpcnMgaGF2ZSBzdGVwcGVkIGJhY2suDQoNCkkgd2FudCB0aGUgb3Bp bmlvbiBvZiB2Nm9wcy4gRG8gd2UgbmVlZCB0aGlzLCBvciBub3Q/IElmIHdlIG5lZWQgdGhpcywg d2Ugc2hvdWxkIGFkb3B0IGl0LCBhbmQgdGhlbiAoSSB0aGluaykgZ28gdG8gYW4gaW1tZWRpYXRl IFdHTEMgYW5kIHBvdGVudGlhbGx5IGFkdmFuY2UgaXQuIElmIGl04oCZcyBub3QgbmVlZGVkLCB3 ZSBzaG91bGQgc2F5IGl0IGlzIG5vdCBuZWVkZWQuDQoNClBsZWFzZSByZXBseSBpbiB0aGlzIHRo cmVhZC4NCg0KT24gQXByIDIxLCAyMDE0LCBhdCA1OjU1IEFNLCBZb25nIEN1aSA8Y3VpeW9uZ0B0 c2luZ2h1YS5lZHUuY24+IHdyb3RlOg0KDQo+IEhpIEZyZWQsDQo+IA0KPiBUaGFua3MgZm9yIHlv dXIgZW1haWwgYW5kIHJlbWluZGluZy4NCj4gDQo+IFlvdSBhcmUgcmlnaHQgdGhhdCB3ZSBhcmUg Z2xhZCB0byB0YWtlIHRoaXMgd29yayBpbiBTb2Z0d2lyZSBhcyB3ZSBkaXNjdXNzZWQgaW4gTWFy Y2guIEhvd2V2ZXIsIGZvciBzb21lIHJlYXNvbnMgd2UgbmVlZCB0byBmb2N1cyBvbiBNQVAgcGFj a2FnZSByaWdodCBub3cuIFRoZXJlIGlzIHRoZSBjb25zZW5zdXMgdGhhdCBTb2Z0d2lyZSB3aWxs IE5PVCB0YWtlIGFueSBuZXcgd29yayBiZWZvcmUgd2Ugc3VibWl0IHRoZSBNQVAgcGFja2FnZSB0 byBJRVNHLiBUaGVyZSBhcmUgZXZlbiBzb21lIG90aGVyIHdnIGl0ZW1zIGJsb2NrZWQgaW4gU29m dHdpcmUgYXQgdGhpcyBtb21lbnQuIFdlIGFyZSB0cnlpbmcgdG8gc29sdmUgdGhlIE1BUCBpc3N1 ZXMgYXNhcCBhbmQgYWNjZWxlcmF0ZSB0aGUgcHJvY2Vzcy4gQnV0IEknbSBhZnJhaWQgd2Ugc3Rp bGwgbmVlZCBzb21lIHRpbWUuDQo+IA0KPiBTbyBpZiB5b3UnZCBsaWtlIHRvIHRha2UgdGhpcyB3 b3JrIGluIHY2b3BzLCBwbGVhc2UgZG8gc28uIE90aGVyd2lzZSwgd2Ugc3RpbGwgbmVlZCB0byB3 YWl0IGZvciBzb21lIHRpbWUgYmVmb3JlIHRha2luZyBpdCBpbiBTb2Z0d2lyZS4NCj4gDQo+IFRo YW5rcyBmb3IgdW5kZXJzdGFuZGluZyBhbmQgbGV0IHVzIGtub3cgeW91ciBkZWNpc2lvbi4NCj4g DQo+IFlvbmcNCj4gDQo+IE9uIDIwMTQtNC0xOSwgYXQg5LiK5Y2IMTI6MjMsIEZyZWQgQmFrZXIg KGZyZWQpIDxmcmVkQGNpc2NvLmNvbT4gd3JvdGU6DQo+IA0KPj4gU29mdHdpcmUgY2hhaXJzOg0K Pj4gDQo+PiBJbiBNYXJjaCwgeW91IGluZGljYXRlZCB0aGF0IHlvdSB3YW50ZWQgdG8gcHJvZ3Jl c3MgdGhpcyBpbiBzb2Z0d2lyZS4gVGhlIGF1dGhvcnMgaGF2ZW7igJl0IGhlYXJkIGZyb20geW91 IGFuZCBhcmUgbG9va2luZyBmb3IgZ3VpZGFuY2UuIFBpY2sgb25lOiBkbyB5b3Ugd2FudCBpdCwg b3IgZG8geW91IHdhbnQgaXQgZG9uZSBmb3IgeW91Pw0KPj4gDQo+PiBGcmVkDQo+PiANCj4+IA0K Pj4gT24gQXByIDE4LCAyMDE0LCBhdCA0OjU1IEFNLCBUaGVJcHY2Z3V5IC4gPGNiLmxpc3Q2QGdt YWlsLmNvbT4gd3JvdGU6DQo+PiANCj4+PiAqZml4aW5nIHRoZSBzb2Z0d2lyZSBjaGFpciBlbWFp bCBhZGRyZXNzIHNpbmNlIGl0IGJvdW5jZWQuDQo+Pj4gDQo+Pj4gT24gRnJpLCBBcHIgNCwgMjAx NCBhdCA1OjQ0IFBNLCBGcmVkIEJha2VyIChmcmVkKSA8ZnJlZEBjaXNjby5jb20+IHdyb3RlOg0K Pj4+PiANCj4+Pj4gT24gQXByIDQsIDIwMTQsIGF0IDY6MzQgQU0sIENiIEIgPGNiLmxpc3Q2QGdt YWlsLmNvbT4gd3JvdGU6DQo+Pj4+IA0KPj4+PiBIZWxsbyBmb2xrcywNCj4+Pj4gDQo+Pj4+IE5v IGZvbGxvdy11cCBpbiBhIHdlZWsuIEkgYXNzdW1lIHRoZSBiZWxvdyBleHBsYW5hdGlvbiBhbmQg DQo+Pj4+IGV4aXNpdGluZyB0ZXh0IGFyZSBvay4NCj4+Pj4gDQo+Pj4+IFRvIHJlc3RhdGUsIHRo aXMgSS1EIHNpbXBseSBnZW5lcmFsaXplcyB0aGUgc2NvcGUgb2YgMTkyLjAuMC4wLzI5LiAgDQo+ Pj4+IFRoZXJlIGlzIG5vIGd1aWRhbmNlIG9uIGhvdyBzcGVjaWZpYyBhZGRyZXNzZXMgbWF5IGJl IHVzZWQuIEl0IGlzIA0KPj4+PiBhc3N1bWVkIHRoZSBkZXBsb3lpbmcgcGFydHkgd2lsbCBub3Qg Y2F1c2UgYSBjb25mbGljdCBvbiB0aGUgaG9zdCANCj4+Pj4gYnkgYXNzaWdpbmcgdGhlIHNhbWUg YWRkcmVzcyB0byB0aGUgaG9zdCBtdWx0aXBscyB0aW1lcy4uLi4gYXMgdGhhdCANCj4+Pj4gaXMg YSBnZW5lcmFsIGlwIGNvbmZpZ3VyYXRpb24gcnVsZS4NCj4+Pj4gDQo+Pj4+IEkgd2lsbCBhc2sg djZvcHMgdG8gYWNjZXB0IHRoaXMgaS1kIGFuZCBkaXJlY3QgdGhlbSB0byB0aGlzIHRocmVhZCAN Cj4+Pj4gdG8gc2VlIHRoZSBzb2Z0d2lyZSB2aWV3Lg0KPj4+PiANCj4+Pj4gDQo+Pj4+IE15IHVu ZGVyc3RhbmRpbmcgaXMgdGhhdCBzb2Z0d2lyZXMgd2FudHMgdG8gcHJvZ3Jlc3MgdGhpcyBvbmUu IEkgDQo+Pj4+IGd1ZXNzIEnigJlkIGxpa2UgdG8gaGVhciBmcm9tIHRoZSBzb2Z0d2lyZXMgY2hh aXJzIGJlZm9yZSBicmluZ2luZyBpdCBiYWNrLg0KPj4+PiANCj4+PiANCj4+PiANCj4+PiBGcmVk LA0KPj4+IA0KPj4+IEl0IGhhcyBiZWVuIDE0IGRheXMgc2luY2UgeW91ciAgZW1haWwuICBJIGFt IG5vdCBzdXJlIGlmIHlvdSBzZW50IA0KPj4+IHRoZSBlbWFpbCB0byB0aGUgd3JvbmcgYWRkcmVz cyBvZiBmaXhlZCBpdC4gIEVpdGhlciB3YXksIGkgd291bGQgDQo+Pj4gbGlrZSB0byBtYWtlIHBy b2dyZXNzIG9uIHRoaXMgSS1EIGluIHY2b3BzIHNpbmNlIHRoaXMgSS1EIGlzIGFib3V0IGEgDQo+ Pj4gZ2VuZXJhbGl6ZWQgYXBwcm9hY2ggdGhhdCBleGNlZWRzIHRoZSBib3VuZHMgb2Ygc29mdHdp cmVzLiAgVGhpcyBoYXMgDQo+Pj4gYWxzbyBiZWVuIHByZXNlbnRlZCB0d2ljZSBpbiBwZXJzb24g dG8gdjZvcHMuDQo+Pj4gDQo+Pj4gQ2FtZXJvbg0KPj4+IA0KPj4+PiBDQg0KPj4+PiANCj4+Pj4g T24gTWFyIDI5LCAyMDE0IDQ6NTkgQU0sICJDYiBCIiA8Y2IubGlzdDZAZ21haWwuY29tPiB3cm90 ZToNCj4+Pj4+IA0KPj4+Pj4gT24gVGh1LCBNYXIgMjcsIDIwMTQgYXQgMzozOCBQTSwgRGF2ZSBU aGFsZXIgDQo+Pj4+PiA8ZHRoYWxlckBtaWNyb3NvZnQuY29tPg0KPj4+Pj4gd3JvdGU6DQo+Pj4+ Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+IEZyb206IFNvZnR3aXJlcyBb bWFpbHRvOnNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgDQo+Pj4+Pj4+ IENiIEINCj4+Pj4+Pj4gU2VudDogVGh1cnNkYXksIE1hcmNoIDI3LCAyMDE0IDEwOjU4IEFNDQo+ Pj4+Pj4+IFRvOiBzb2Z0d2lyZXNAaWV0Zi5vcmcNCj4+Pj4+Pj4gU3ViamVjdDogW1NvZnR3aXJl c10gZHJhZnQtYnlybmUtdjZvcHMtY2xhdGlwLTAxDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBIaSBTb2Z0 d2lyZXMsDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBBbGVzIHByZXNlbnRlZCBkcmFmdC1ieXJuZS12Nm9w cy1jbGF0aXAtMDEgaW4gc29mdHdpcmVzIGF0IHRoZSANCj4+Pj4+Pj4gbGFzdCBJRVRGIG1lZXRp bmcuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBJIGFtIGF0dGVtcHRpbmcgdG8gaGF2ZSB0aGlzIEktRCBh ZG9wdGVkIGJ5IHY2b3BzLCBidXQgdjZvcHMgDQo+Pj4+Pj4+IHJlcXVlc3RlZCBmZWVkYmFjayBm cm9tIHNvZnR3aXJlcyBmaXJzdC4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IFBlcnRhaW5pbmcgdG8gdGhl IG1pbnV0ZXMsIGkgd291bGQgbGlrZSB0byBhZGRyZXNzIHNvbWUgdG9waWNzIA0KPj4+Pj4+PiB0 byBtYWtlIHN1cmUgaXQgaXMgb2sgIGZvciB2Nm9wcyB0byBtb3ZlIGZvcndhcmQgd2l0aCBhZG9w dGlvbg0KPj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv d2cvc29mdHdpcmUvbWludXRlcz9pdGVtPW1pbnV0ZXMtODktc29mdHcNCj4+Pj4+Pj4gaXJlLmh0 bWwNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IFRoZSBhZGRyZXNzZXMsIGJvdGggaW4gRFMtbGl0ZSBhbmQg NDY0eGxhdCwgbmV2ZXIgYXBwZWFycyBvbiB0aGUgDQo+Pj4+Pj4+IHdpcmUgc28gdGhlcmUgaXMg bm8gY2hhbmNlIG9mIG92ZXJsYXAgb3IgY29sbGlzaW9uLg0KPj4+Pj4+IA0KPj4+Pj4+IERpc2Fn cmVlLCB0aGF0IGNvbmNsdXNpb24gZG9lc24ndCBmb2xsb3cgKGFuZCBpbiBteSBleHBlcmllbmNl IA0KPj4+Pj4+IGl0J3Mgd3JvbmcpLg0KPj4+Pj4+IE92ZXJsYXAvY29sbGlzaW9uIGhhcHBlbnMg d2hlbiB0aGVyZSBhcmUgdHdvIGludGVyZmFjZXMgb24gdGhlIHNhbWUgaG9zdA0KPj4+Pj4+IChl dmVuIGlmIHRoZXkncmUgbm90IGluIHVzZSBzaW11bHRhbmVvdXNseSkuICAgVGhlIGNvbGxpc2lv bnMgY2FuIGFmZmVjdA0KPj4+Pj4+IHRoZSByb3V0aW5nIHRhYmxlIChpZiB0aGUgaG9zdCBpbXBs ZW1lbnRzIGluIHN1Y2ggYSB3YXkpLCBBQ0xzIA0KPj4+Pj4+IGxpa2UgaW4gaG9zdCBmaXJld2Fs bCBwb2xpY2llcyBhbmQgc3VjaCwgYW5kIHZhcmlvdXMgYXBwbGljYXRpb24tbGF5ZXIgdXNlcy4N Cj4+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gQWgsIGkgc2VlIHlvdXIgcG9pbnQuICBJZiB0aGUgaG9z dCBpcyBpdHNlbGYgYm90aCBhIEI0IGFuZCBhIENMQVQgDQo+Pj4+PiBhdCB0aGUgc2FtZSB0aW1l LCB0aGVuIHRoaXMgY29sbGlzaW9uIG1heSBvY2N1ciB3aXRoaW4gdGhlIGhvc3QsIA0KPj4+Pj4g bm90IG9uIHRoZSB3aXJlLg0KPj4+Pj4gDQo+Pj4+Pj4gSXQncyBmaW5lIHRvIHNwZWNpZnkgdXNl IGFzIHRoZSBkZWZhdWx0IHJhbmdlIChlLmcuIGZvciA0NjR4bGF0IA0KPj4+Pj4+IG9yDQo+Pj4+ Pj4gRFMtbGl0ZSkgYnV0DQo+Pj4+Pj4gaW1wb3J0YW50IHRvIG5ldmVyIGNvbnN0cmFpbiBpdCB0 byBvbmx5IHRoYXQgcmFuZ2UsIGFzc3VtaW5nIHRoZSANCj4+Pj4+PiByYW5nZSBpcyBtYWRlIG5v bi1EUy1saXRlIHNwZWNpZmljLg0KPj4+Pj4+IA0KPj4+Pj4+IC1EYXZlDQo+Pj4+PiANCj4+Pj4+ IElzIHRoZXJlIHN1Y2ggYSBjb25zdHJhaW50IHRoYXQgd291bGQgY2F1c2UgYSBwcm9ibGVtPw0K Pj4+Pj4gDQo+Pj4+PiBMb29raW5nIGF0IFJGQzYzMzMgYW5kIGRyYWZ0LWJ5cm5lLXY2b3BzLWNs YXRpcCwgaSBzZWUgdGhhdCANCj4+Pj4+IFJGQzYzMzMgc2F5cyB0aGUgQjQgU0hPVUxEIHVzZSAx OTIuMC4wLjIuICBUbyBhIHJhdGlvbmFsIHBlcnNvbiwgYSANCj4+Pj4+IGdvb2QgcmVhc29uIHRv IG5vdCB1c2UgIDE5Mi4wLjAuMiBpcyB0aGF0IGl0IGlzIGluIHVzZSBmb3IgYSBDTEFUIA0KPj4+ Pj4gaW50ZXJmYWNlIG9uIHRoZSBzYW1lIGhvc3QsIHdoaWNoIGZpdHMgd2l0aCB0aGUgU0hPVUxE IHdvcmRpbmcuDQo+Pj4+PiANCj4+Pj4+IElzIHRoZXJlIHNvbWUgdGV4dCB0aGF0IHlvdSBjb3Vs ZCBzdWdnZXN0IHRoYXQgbWF5IGNsYXJpZnkgdGhpcyANCj4+Pj4+IHNpdHVhdGlvbiBpbiBkcmFm dC1ieXJuZS12Nm9wcy1jbGF0aXAgb3IgaXMgaXQgb2sgZm9yIHY2b3BzIHRvIA0KPj4+Pj4gYWRv cHQgYXMtaXM/ICBBcyBpdCBzdGFuZHMsIHRoZSBJLUQgc2ltcGx5IHNheXMgdGhhdCAxOTIuMC4w LjAvMjkgDQo+Pj4+PiB3aWxsIGJlIGdlbmVyYWxpemVkIHdpdGhvdXQgbWFraW5nIGFueSBmdXJ0 aGVyIHN0YXRlbWVudHMgaG93IA0KPj4+Pj4gYWRkcmVzc2VzIG1heSBiZSB1c2VkIHdpdGhpbiB0 aGF0IHJhbmdlLg0KPj4+Pj4gDQo+Pj4+PiBDQg0KPj4+PiANCj4+Pj4gDQo+Pj4+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+PiA4IGlz c3VlcyBpbiB2aXJ0dWFsIGluZnJhc3RydWN0dXJlDQo+Pj4+IGh0dHA6Ly9kY3JvY2tlci5uZXQv I2ZhbGxhY2llcw0KPj4+PiANCj4+IA0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiA4IGlzc3VlcyBpbiB2aXJ0dWFsIGluZnJhc3Ry dWN0dXJlDQo+PiBodHRwOi8vZGNyb2NrZXIubmV0LyNmYWxsYWNpZXMNCj4+IA0KPiANCj4gDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K OCBpc3N1ZXMgaW4gdmlydHVhbCBpbmZyYXN0cnVjdHVyZQ0KaHR0cDovL2Rjcm9ja2VyLm5ldC8j ZmFsbGFjaWVzDQoNCg== From nobody Wed Apr 23 01:11: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 4BBDB1A013A for ; Wed, 23 Apr 2014 01:11:09 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 KMIwrhHmEyns for ; Wed, 23 Apr 2014 01:11:00 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 654F81A00CF for ; Wed, 23 Apr 2014 01:11:00 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id BE08AC07F0; Wed, 23 Apr 2014 10:10:53 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 72A5E180063; Wed, 23 Apr 2014 10:10:50 +0200 (CEST) Received: from PUEXCB1A.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Wed, 23 Apr 2014 10:10:50 +0200 From: To: "Fred Baker (fred)" , V6 Ops List Date: Wed, 23 Apr 2014 10:10:49 +0200 Thread-Topic: draft-byrne-v6ops-clatip-01 Thread-Index: AQHPXX0GoCnfuCMMckahK1B0I3gQqZse2v2g Message-ID: <6153_1398240650_5357758A_6153_11147_1_1B2E7539FECD9048B261B791B1B24A7C518463FA89@PUEXCB1A.nanterre.francetelecom.fr> References: <852615d6f8d742a095d2701496c62275@BY2PR03MB412.namprd03.prod.outlook.com> <37C0752F-8766-43BF-AD3E-29EBB64FED96@tsinghua.edu.cn> <9B724115-1AA3-423C-A0F2-658285D5F43D@cisco.com> In-Reply-To: <9B724115-1AA3-423C-A0F2-658285D5F43D@cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.23.61819 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1L-0pKjjgxzjTpFmLgzdZdRKifc Subject: Re: [v6ops] 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: Wed, 23 Apr 2014 08:11:09 -0000 VGhpcyBwcm9wb3NpdGlvbiBpcyB1c2VmdWwgZm9yIElQdjYtb25seSBkZXNpZ24gYW5kIEkgc3Vw cG9ydCBpdHMgYWRvcHRpb24uIA0KRGF2aWQNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0t DQpEZcKgOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQg ZGUgRnJlZCBCYWtlciAoZnJlZCkNCkVudm95w6nCoDogbHVuZGkgMjEgYXZyaWwgMjAxNCAxODox Ng0Kw4DCoDogVjYgT3BzIExpc3QNCk9iamV0wqA6IFt2Nm9wc10gZHJhZnQtYnlybmUtdjZvcHMt Y2xhdGlwLTAxDQoNCkZvbGxvd2luZyB1cCBmcm9tIHRoZSByZWNlbnQgbWVldGluZy4NCg0KV2Ug ZGlzY3Vzc2VkIGNsYXRpcC4gVGhlIG91dGNvbWUgd2FzIHRoYXQgd2Ugd2FudGVkIHRvIGtub3cg d2hhdCBzb2Z0d2lyZSB3YW50ZWQgZG9uZSB3aXRoIGl0LCBhbmQgSSB0b29rIHRoZSBhY3Rpb24g dG8gYXNrLiANCg0KVGhlIHJlc3BvbnNlIGZyb20gdGhlIHNvZnR3aXJlIGNoYWlycyB3YXMgdGhh dCB0aGV5IHdhbnRlZCB0byBjb25zaWRlciB0aGUgZHJhZnQgdGhlcmUsIGFuZCBhZHZhbmNlIGl0 IGZyb20gdGhlcmUuIEhvd2V2ZXIsIGl0IGFwcGVhcnMgdG8gYmUgYm90dGxlbmVja2VkLiBTbywg dGhlIHNvZnR3aXJlIGNoYWlycyBoYXZlIHN0ZXBwZWQgYmFjay4NCg0KSSB3YW50IHRoZSBvcGlu aW9uIG9mIHY2b3BzLiBEbyB3ZSBuZWVkIHRoaXMsIG9yIG5vdD8gSWYgd2UgbmVlZCB0aGlzLCB3 ZSBzaG91bGQgYWRvcHQgaXQsIGFuZCB0aGVuIChJIHRoaW5rKSBnbyB0byBhbiBpbW1lZGlhdGUg V0dMQyBhbmQgcG90ZW50aWFsbHkgYWR2YW5jZSBpdC4gSWYgaXTigJlzIG5vdCBuZWVkZWQsIHdl IHNob3VsZCBzYXkgaXQgaXMgbm90IG5lZWRlZC4NCg0KUGxlYXNlIHJlcGx5IGluIHRoaXMgdGhy ZWFkLg0KDQpPbiBBcHIgMjEsIDIwMTQsIGF0IDU6NTUgQU0sIFlvbmcgQ3VpIDxjdWl5b25nQHRz aW5naHVhLmVkdS5jbj4gd3JvdGU6DQoNCj4gSGkgRnJlZCwNCj4gDQo+IFRoYW5rcyBmb3IgeW91 ciBlbWFpbCBhbmQgcmVtaW5kaW5nLg0KPiANCj4gWW91IGFyZSByaWdodCB0aGF0IHdlIGFyZSBn bGFkIHRvIHRha2UgdGhpcyB3b3JrIGluIFNvZnR3aXJlIGFzIHdlIGRpc2N1c3NlZCBpbiBNYXJj aC4gSG93ZXZlciwgZm9yIHNvbWUgcmVhc29ucyB3ZSBuZWVkIHRvIGZvY3VzIG9uIE1BUCBwYWNr YWdlIHJpZ2h0IG5vdy4gVGhlcmUgaXMgdGhlIGNvbnNlbnN1cyB0aGF0IFNvZnR3aXJlIHdpbGwg Tk9UIHRha2UgYW55IG5ldyB3b3JrIGJlZm9yZSB3ZSBzdWJtaXQgdGhlIE1BUCBwYWNrYWdlIHRv IElFU0cuIFRoZXJlIGFyZSBldmVuIHNvbWUgb3RoZXIgd2cgaXRlbXMgYmxvY2tlZCBpbiBTb2Z0 d2lyZSBhdCB0aGlzIG1vbWVudC4gV2UgYXJlIHRyeWluZyB0byBzb2x2ZSB0aGUgTUFQIGlzc3Vl cyBhc2FwIGFuZCBhY2NlbGVyYXRlIHRoZSBwcm9jZXNzLiBCdXQgSSdtIGFmcmFpZCB3ZSBzdGls bCBuZWVkIHNvbWUgdGltZS4NCj4gDQo+IFNvIGlmIHlvdSdkIGxpa2UgdG8gdGFrZSB0aGlzIHdv cmsgaW4gdjZvcHMsIHBsZWFzZSBkbyBzby4gT3RoZXJ3aXNlLCB3ZSBzdGlsbCBuZWVkIHRvIHdh aXQgZm9yIHNvbWUgdGltZSBiZWZvcmUgdGFraW5nIGl0IGluIFNvZnR3aXJlLg0KPiANCj4gVGhh bmtzIGZvciB1bmRlcnN0YW5kaW5nIGFuZCBsZXQgdXMga25vdyB5b3VyIGRlY2lzaW9uLg0KPiAN Cj4gWW9uZw0KPiANCj4gT24gMjAxNC00LTE5LCBhdCDkuIrljYgxMjoyMywgRnJlZCBCYWtlciAo ZnJlZCkgPGZyZWRAY2lzY28uY29tPiB3cm90ZToNCj4gDQo+PiBTb2Z0d2lyZSBjaGFpcnM6DQo+ PiANCj4+IEluIE1hcmNoLCB5b3UgaW5kaWNhdGVkIHRoYXQgeW91IHdhbnRlZCB0byBwcm9ncmVz cyB0aGlzIGluIHNvZnR3aXJlLiBUaGUgYXV0aG9ycyBoYXZlbuKAmXQgaGVhcmQgZnJvbSB5b3Ug YW5kIGFyZSBsb29raW5nIGZvciBndWlkYW5jZS4gUGljayBvbmU6IGRvIHlvdSB3YW50IGl0LCBv ciBkbyB5b3Ugd2FudCBpdCBkb25lIGZvciB5b3U/DQo+PiANCj4+IEZyZWQNCj4+IA0KPj4gDQo+ PiBPbiBBcHIgMTgsIDIwMTQsIGF0IDQ6NTUgQU0sIFRoZUlwdjZndXkgLiA8Y2IubGlzdDZAZ21h aWwuY29tPiB3cm90ZToNCj4+IA0KPj4+ICpmaXhpbmcgdGhlIHNvZnR3aXJlIGNoYWlyIGVtYWls IGFkZHJlc3Mgc2luY2UgaXQgYm91bmNlZC4NCj4+PiANCj4+PiBPbiBGcmksIEFwciA0LCAyMDE0 IGF0IDU6NDQgUE0sIEZyZWQgQmFrZXIgKGZyZWQpIDxmcmVkQGNpc2NvLmNvbT4gd3JvdGU6DQo+ Pj4+IA0KPj4+PiBPbiBBcHIgNCwgMjAxNCwgYXQgNjozNCBBTSwgQ2IgQiA8Y2IubGlzdDZAZ21h aWwuY29tPiB3cm90ZToNCj4+Pj4gDQo+Pj4+IEhlbGxvIGZvbGtzLA0KPj4+PiANCj4+Pj4gTm8g Zm9sbG93LXVwIGluIGEgd2Vlay4gSSBhc3N1bWUgdGhlIGJlbG93IGV4cGxhbmF0aW9uIGFuZCAN Cj4+Pj4gZXhpc2l0aW5nIHRleHQgYXJlIG9rLg0KPj4+PiANCj4+Pj4gVG8gcmVzdGF0ZSwgdGhp cyBJLUQgc2ltcGx5IGdlbmVyYWxpemVzIHRoZSBzY29wZSBvZiAxOTIuMC4wLjAvMjkuICANCj4+ Pj4gVGhlcmUgaXMgbm8gZ3VpZGFuY2Ugb24gaG93IHNwZWNpZmljIGFkZHJlc3NlcyBtYXkgYmUg dXNlZC4gSXQgaXMgDQo+Pj4+IGFzc3VtZWQgdGhlIGRlcGxveWluZyBwYXJ0eSB3aWxsIG5vdCBj YXVzZSBhIGNvbmZsaWN0IG9uIHRoZSBob3N0IA0KPj4+PiBieSBhc3NpZ2luZyB0aGUgc2FtZSBh ZGRyZXNzIHRvIHRoZSBob3N0IG11bHRpcGxzIHRpbWVzLi4uLiBhcyB0aGF0IA0KPj4+PiBpcyBh IGdlbmVyYWwgaXAgY29uZmlndXJhdGlvbiBydWxlLg0KPj4+PiANCj4+Pj4gSSB3aWxsIGFzayB2 Nm9wcyB0byBhY2NlcHQgdGhpcyBpLWQgYW5kIGRpcmVjdCB0aGVtIHRvIHRoaXMgdGhyZWFkIA0K Pj4+PiB0byBzZWUgdGhlIHNvZnR3aXJlIHZpZXcuDQo+Pj4+IA0KPj4+PiANCj4+Pj4gTXkgdW5k ZXJzdGFuZGluZyBpcyB0aGF0IHNvZnR3aXJlcyB3YW50cyB0byBwcm9ncmVzcyB0aGlzIG9uZS4g SSANCj4+Pj4gZ3Vlc3MgSeKAmWQgbGlrZSB0byBoZWFyIGZyb20gdGhlIHNvZnR3aXJlcyBjaGFp cnMgYmVmb3JlIGJyaW5naW5nIGl0IGJhY2suDQo+Pj4+IA0KPj4+IA0KPj4+IA0KPj4+IEZyZWQs DQo+Pj4gDQo+Pj4gSXQgaGFzIGJlZW4gMTQgZGF5cyBzaW5jZSB5b3VyICBlbWFpbC4gIEkgYW0g bm90IHN1cmUgaWYgeW91IHNlbnQgDQo+Pj4gdGhlIGVtYWlsIHRvIHRoZSB3cm9uZyBhZGRyZXNz IG9mIGZpeGVkIGl0LiAgRWl0aGVyIHdheSwgaSB3b3VsZCANCj4+PiBsaWtlIHRvIG1ha2UgcHJv Z3Jlc3Mgb24gdGhpcyBJLUQgaW4gdjZvcHMgc2luY2UgdGhpcyBJLUQgaXMgYWJvdXQgYSANCj4+ PiBnZW5lcmFsaXplZCBhcHByb2FjaCB0aGF0IGV4Y2VlZHMgdGhlIGJvdW5kcyBvZiBzb2Z0d2ly ZXMuICBUaGlzIGhhcyANCj4+PiBhbHNvIGJlZW4gcHJlc2VudGVkIHR3aWNlIGluIHBlcnNvbiB0 byB2Nm9wcy4NCj4+PiANCj4+PiBDYW1lcm9uDQo+Pj4gDQo+Pj4+IENCDQo+Pj4+IA0KPj4+PiBP biBNYXIgMjksIDIwMTQgNDo1OSBBTSwgIkNiIEIiIDxjYi5saXN0NkBnbWFpbC5jb20+IHdyb3Rl Og0KPj4+Pj4gDQo+Pj4+PiBPbiBUaHUsIE1hciAyNywgMjAxNCBhdCAzOjM4IFBNLCBEYXZlIFRo YWxlciANCj4+Pj4+IDxkdGhhbGVyQG1pY3Jvc29mdC5jb20+DQo+Pj4+PiB3cm90ZToNCj4+Pj4+ Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4gRnJvbTogU29mdHdpcmVzIFtt YWlsdG86c29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiANCj4+Pj4+Pj4g Q2IgQg0KPj4+Pj4+PiBTZW50OiBUaHVyc2RheSwgTWFyY2ggMjcsIDIwMTQgMTA6NTggQU0NCj4+ Pj4+Pj4gVG86IHNvZnR3aXJlc0BpZXRmLm9yZw0KPj4+Pj4+PiBTdWJqZWN0OiBbU29mdHdpcmVz XSBkcmFmdC1ieXJuZS12Nm9wcy1jbGF0aXAtMDENCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEhpIFNvZnR3 aXJlcywNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEFsZXMgcHJlc2VudGVkIGRyYWZ0LWJ5cm5lLXY2b3Bz LWNsYXRpcC0wMSBpbiBzb2Z0d2lyZXMgYXQgdGhlIA0KPj4+Pj4+PiBsYXN0IElFVEYgbWVldGlu Zy4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEkgYW0gYXR0ZW1wdGluZyB0byBoYXZlIHRoaXMgSS1EIGFk b3B0ZWQgYnkgdjZvcHMsIGJ1dCB2Nm9wcyANCj4+Pj4+Pj4gcmVxdWVzdGVkIGZlZWRiYWNrIGZy b20gc29mdHdpcmVzIGZpcnN0Lg0KPj4+Pj4+PiANCj4+Pj4+Pj4gUGVydGFpbmluZyB0byB0aGUg bWludXRlcywgaSB3b3VsZCBsaWtlIHRvIGFkZHJlc3Mgc29tZSB0b3BpY3MgDQo+Pj4+Pj4+IHRv IG1ha2Ugc3VyZSBpdCBpcyBvayAgZm9yIHY2b3BzIHRvIG1vdmUgZm9yd2FyZCB3aXRoIGFkb3B0 aW9uDQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy93 Zy9zb2Z0d2lyZS9taW51dGVzP2l0ZW09bWludXRlcy04OS1zb2Z0dw0KPj4+Pj4+PiBpcmUuaHRt bA0KPj4+Pj4+PiANCj4+Pj4+Pj4gVGhlIGFkZHJlc3NlcywgYm90aCBpbiBEUy1saXRlIGFuZCA0 NjR4bGF0LCBuZXZlciBhcHBlYXJzIG9uIHRoZSANCj4+Pj4+Pj4gd2lyZSBzbyB0aGVyZSBpcyBu byBjaGFuY2Ugb2Ygb3ZlcmxhcCBvciBjb2xsaXNpb24uDQo+Pj4+Pj4gDQo+Pj4+Pj4gRGlzYWdy ZWUsIHRoYXQgY29uY2x1c2lvbiBkb2Vzbid0IGZvbGxvdyAoYW5kIGluIG15IGV4cGVyaWVuY2Ug DQo+Pj4+Pj4gaXQncyB3cm9uZykuDQo+Pj4+Pj4gT3ZlcmxhcC9jb2xsaXNpb24gaGFwcGVucyB3 aGVuIHRoZXJlIGFyZSB0d28gaW50ZXJmYWNlcyBvbiB0aGUgc2FtZSBob3N0DQo+Pj4+Pj4gKGV2 ZW4gaWYgdGhleSdyZSBub3QgaW4gdXNlIHNpbXVsdGFuZW91c2x5KS4gICBUaGUgY29sbGlzaW9u cyBjYW4gYWZmZWN0DQo+Pj4+Pj4gdGhlIHJvdXRpbmcgdGFibGUgKGlmIHRoZSBob3N0IGltcGxl bWVudHMgaW4gc3VjaCBhIHdheSksIEFDTHMgDQo+Pj4+Pj4gbGlrZSBpbiBob3N0IGZpcmV3YWxs IHBvbGljaWVzIGFuZCBzdWNoLCBhbmQgdmFyaW91cyBhcHBsaWNhdGlvbi1sYXllciB1c2VzLg0K Pj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBBaCwgaSBzZWUgeW91ciBwb2ludC4gIElmIHRoZSBob3N0 IGlzIGl0c2VsZiBib3RoIGEgQjQgYW5kIGEgQ0xBVCANCj4+Pj4+IGF0IHRoZSBzYW1lIHRpbWUs IHRoZW4gdGhpcyBjb2xsaXNpb24gbWF5IG9jY3VyIHdpdGhpbiB0aGUgaG9zdCwgDQo+Pj4+PiBu b3Qgb24gdGhlIHdpcmUuDQo+Pj4+PiANCj4+Pj4+PiBJdCdzIGZpbmUgdG8gc3BlY2lmeSB1c2Ug YXMgdGhlIGRlZmF1bHQgcmFuZ2UgKGUuZy4gZm9yIDQ2NHhsYXQgDQo+Pj4+Pj4gb3INCj4+Pj4+ PiBEUy1saXRlKSBidXQNCj4+Pj4+PiBpbXBvcnRhbnQgdG8gbmV2ZXIgY29uc3RyYWluIGl0IHRv IG9ubHkgdGhhdCByYW5nZSwgYXNzdW1pbmcgdGhlIA0KPj4+Pj4+IHJhbmdlIGlzIG1hZGUgbm9u LURTLWxpdGUgc3BlY2lmaWMuDQo+Pj4+Pj4gDQo+Pj4+Pj4gLURhdmUNCj4+Pj4+IA0KPj4+Pj4g SXMgdGhlcmUgc3VjaCBhIGNvbnN0cmFpbnQgdGhhdCB3b3VsZCBjYXVzZSBhIHByb2JsZW0/DQo+ Pj4+PiANCj4+Pj4+IExvb2tpbmcgYXQgUkZDNjMzMyBhbmQgZHJhZnQtYnlybmUtdjZvcHMtY2xh dGlwLCBpIHNlZSB0aGF0IA0KPj4+Pj4gUkZDNjMzMyBzYXlzIHRoZSBCNCBTSE9VTEQgdXNlIDE5 Mi4wLjAuMi4gIFRvIGEgcmF0aW9uYWwgcGVyc29uLCBhIA0KPj4+Pj4gZ29vZCByZWFzb24gdG8g bm90IHVzZSAgMTkyLjAuMC4yIGlzIHRoYXQgaXQgaXMgaW4gdXNlIGZvciBhIENMQVQgDQo+Pj4+ PiBpbnRlcmZhY2Ugb24gdGhlIHNhbWUgaG9zdCwgd2hpY2ggZml0cyB3aXRoIHRoZSBTSE9VTEQg d29yZGluZy4NCj4+Pj4+IA0KPj4+Pj4gSXMgdGhlcmUgc29tZSB0ZXh0IHRoYXQgeW91IGNvdWxk IHN1Z2dlc3QgdGhhdCBtYXkgY2xhcmlmeSB0aGlzIA0KPj4+Pj4gc2l0dWF0aW9uIGluIGRyYWZ0 LWJ5cm5lLXY2b3BzLWNsYXRpcCBvciBpcyBpdCBvayBmb3IgdjZvcHMgdG8gDQo+Pj4+PiBhZG9w dCBhcy1pcz8gIEFzIGl0IHN0YW5kcywgdGhlIEktRCBzaW1wbHkgc2F5cyB0aGF0IDE5Mi4wLjAu MC8yOSANCj4+Pj4+IHdpbGwgYmUgZ2VuZXJhbGl6ZWQgd2l0aG91dCBtYWtpbmcgYW55IGZ1cnRo ZXIgc3RhdGVtZW50cyBob3cgDQo+Pj4+PiBhZGRyZXNzZXMgbWF5IGJlIHVzZWQgd2l0aGluIHRo YXQgcmFuZ2UuDQo+Pj4+PiANCj4+Pj4+IENCDQo+Pj4+IA0KPj4+PiANCj4+Pj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+IDggaXNz dWVzIGluIHZpcnR1YWwgaW5mcmFzdHJ1Y3R1cmUNCj4+Pj4gaHR0cDovL2Rjcm9ja2VyLm5ldC8j ZmFsbGFjaWVzDQo+Pj4+IA0KPj4gDQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IDggaXNzdWVzIGluIHZpcnR1YWwgaW5mcmFzdHJ1 Y3R1cmUNCj4+IGh0dHA6Ly9kY3JvY2tlci5uZXQvI2ZhbGxhY2llcw0KPj4gDQo+IA0KPiANCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo4 IGlzc3VlcyBpbiB2aXJ0dWFsIGluZnJhc3RydWN0dXJlDQpodHRwOi8vZGNyb2NrZXIubmV0LyNm YWxsYWNpZXMNCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBl dXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmls ZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91 IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBw YXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRy dWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25p cXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0 ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBm YWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29u dGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBw cm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3Ig Y29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl bWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jh bmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBj aGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Wed Apr 23 02:18: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 16BD41A0141 for ; Wed, 23 Apr 2014 02:18:56 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 0Rjs2izAQ5-X for ; Wed, 23 Apr 2014 02:18:54 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 16B121A0140 for ; Wed, 23 Apr 2014 02:18:53 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 79B222AC5F1; Wed, 23 Apr 2014 11:18:47 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 6048C180051; Wed, 23 Apr 2014 11:18:47 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Wed, 23 Apr 2014 11:18:47 +0200 From: To: "Fred Baker (fred)" , V6 Ops List Date: Wed, 23 Apr 2014 11:18:45 +0200 Thread-Topic: draft-byrne-v6ops-clatip-01 Thread-Index: AQHPXX0GoCnfuCMMckahK1B0I3gQqZse7iNQ Message-ID: <94C682931C08B048B7A8645303FDC9F36F56FCBADD@PUEXCB1B.nanterre.francetelecom.fr> References: <852615d6f8d742a095d2701496c62275@BY2PR03MB412.namprd03.prod.outlook.com> <37C0752F-8766-43BF-AD3E-29EBB64FED96@tsinghua.edu.cn> <9B724115-1AA3-423C-A0F2-658285D5F43D@cisco.com> In-Reply-To: <9B724115-1AA3-423C-A0F2-658285D5F43D@cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.23.61819 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ViO8SY941eyPn50lbUm_TFZBwZs Subject: Re: [v6ops] 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: Wed, 23 Apr 2014 09:18:56 -0000 RGVhciBGcmVkLCBhbGwsDQoNCkkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhpcyBkcmFmdC4g DQoNCk9uY2UgY29tbWVudCBhYm91dCB0aGUgcHJvcG9zZWQgbmFtZSBvZiB0aGUgSVB2NCBwcmVm aXgsIEkgd291bGQgdm90ZSBmb3IgIklQdjQgc2VydmljZSBjb250aW51aXR5IFByZWZpeCIgKG9y IHNvbWV0aGluZyBzaW1pbGFyKSBpbnN0ZWFkIG9mICJJUHY2IFRyYW5zaXRpb25hbCBUZWNobm9s b2d5IElQdjQgUHJlZml4Ii4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4tLS0tLU1lc3NhZ2UgZCdvcmln aW5lLS0tLS0NCj5EZcKgOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIERl IGxhIHBhcnQgZGUgRnJlZCBCYWtlciAoZnJlZCkNCj5FbnZvecOpwqA6IGx1bmRpIDIxIGF2cmls IDIwMTQgMTg6MTYNCj7DgMKgOiBWNiBPcHMgTGlzdA0KPk9iamV0wqA6IFt2Nm9wc10gZHJhZnQt YnlybmUtdjZvcHMtY2xhdGlwLTAxDQo+DQo+Rm9sbG93aW5nIHVwIGZyb20gdGhlIHJlY2VudCBt ZWV0aW5nLg0KPg0KPldlIGRpc2N1c3NlZCBjbGF0aXAuIFRoZSBvdXRjb21lIHdhcyB0aGF0IHdl IHdhbnRlZCB0byBrbm93IHdoYXQgc29mdHdpcmUNCj53YW50ZWQgZG9uZSB3aXRoIGl0LCBhbmQg SSB0b29rIHRoZSBhY3Rpb24gdG8gYXNrLg0KPg0KPlRoZSByZXNwb25zZSBmcm9tIHRoZSBzb2Z0 d2lyZSBjaGFpcnMgd2FzIHRoYXQgdGhleSB3YW50ZWQgdG8gY29uc2lkZXIgdGhlDQo+ZHJhZnQg dGhlcmUsIGFuZCBhZHZhbmNlIGl0IGZyb20gdGhlcmUuIEhvd2V2ZXIsIGl0IGFwcGVhcnMgdG8g YmUNCj5ib3R0bGVuZWNrZWQuIFNvLCB0aGUgc29mdHdpcmUgY2hhaXJzIGhhdmUgc3RlcHBlZCBi YWNrLg0KPg0KPkkgd2FudCB0aGUgb3BpbmlvbiBvZiB2Nm9wcy4gRG8gd2UgbmVlZCB0aGlzLCBv ciBub3Q/IElmIHdlIG5lZWQgdGhpcywgd2UNCj5zaG91bGQgYWRvcHQgaXQsIGFuZCB0aGVuIChJ IHRoaW5rKSBnbyB0byBhbiBpbW1lZGlhdGUgV0dMQyBhbmQgcG90ZW50aWFsbHkNCj5hZHZhbmNl IGl0LiBJZiBpdOKAmXMgbm90IG5lZWRlZCwgd2Ugc2hvdWxkIHNheSBpdCBpcyBub3QgbmVlZGVk Lg0KPg0KPlBsZWFzZSByZXBseSBpbiB0aGlzIHRocmVhZC4NCj4NCj5PbiBBcHIgMjEsIDIwMTQs IGF0IDU6NTUgQU0sIFlvbmcgQ3VpIDxjdWl5b25nQHRzaW5naHVhLmVkdS5jbj4gd3JvdGU6DQo+ DQo+PiBIaSBGcmVkLA0KPj4NCj4+IFRoYW5rcyBmb3IgeW91ciBlbWFpbCBhbmQgcmVtaW5kaW5n Lg0KPj4NCj4+IFlvdSBhcmUgcmlnaHQgdGhhdCB3ZSBhcmUgZ2xhZCB0byB0YWtlIHRoaXMgd29y ayBpbiBTb2Z0d2lyZSBhcyB3ZQ0KPmRpc2N1c3NlZCBpbiBNYXJjaC4gSG93ZXZlciwgZm9yIHNv bWUgcmVhc29ucyB3ZSBuZWVkIHRvIGZvY3VzIG9uIE1BUA0KPnBhY2thZ2UgcmlnaHQgbm93LiBU aGVyZSBpcyB0aGUgY29uc2Vuc3VzIHRoYXQgU29mdHdpcmUgd2lsbCBOT1QgdGFrZSBhbnkNCj5u ZXcgd29yayBiZWZvcmUgd2Ugc3VibWl0IHRoZSBNQVAgcGFja2FnZSB0byBJRVNHLiBUaGVyZSBh cmUgZXZlbiBzb21lDQo+b3RoZXIgd2cgaXRlbXMgYmxvY2tlZCBpbiBTb2Z0d2lyZSBhdCB0aGlz IG1vbWVudC4gV2UgYXJlIHRyeWluZyB0byBzb2x2ZQ0KPnRoZSBNQVAgaXNzdWVzIGFzYXAgYW5k IGFjY2VsZXJhdGUgdGhlIHByb2Nlc3MuIEJ1dCBJJ20gYWZyYWlkIHdlIHN0aWxsDQo+bmVlZCBz b21lIHRpbWUuDQo+Pg0KPj4gU28gaWYgeW91J2QgbGlrZSB0byB0YWtlIHRoaXMgd29yayBpbiB2 Nm9wcywgcGxlYXNlIGRvIHNvLiBPdGhlcndpc2UsIHdlDQo+c3RpbGwgbmVlZCB0byB3YWl0IGZv ciBzb21lIHRpbWUgYmVmb3JlIHRha2luZyBpdCBpbiBTb2Z0d2lyZS4NCj4+DQo+PiBUaGFua3Mg Zm9yIHVuZGVyc3RhbmRpbmcgYW5kIGxldCB1cyBrbm93IHlvdXIgZGVjaXNpb24uDQo+Pg0KPj4g WW9uZw0KPj4NCj4+IE9uIDIwMTQtNC0xOSwgYXQg5LiK5Y2IMTI6MjMsIEZyZWQgQmFrZXIgKGZy ZWQpIDxmcmVkQGNpc2NvLmNvbT4gd3JvdGU6DQo+Pg0KPj4+IFNvZnR3aXJlIGNoYWlyczoNCj4+ Pg0KPj4+IEluIE1hcmNoLCB5b3UgaW5kaWNhdGVkIHRoYXQgeW91IHdhbnRlZCB0byBwcm9ncmVz cyB0aGlzIGluIHNvZnR3aXJlLg0KPlRoZSBhdXRob3JzIGhhdmVu4oCZdCBoZWFyZCBmcm9tIHlv dSBhbmQgYXJlIGxvb2tpbmcgZm9yIGd1aWRhbmNlLiBQaWNrIG9uZToNCj5kbyB5b3Ugd2FudCBp dCwgb3IgZG8geW91IHdhbnQgaXQgZG9uZSBmb3IgeW91Pw0KPj4+DQo+Pj4gRnJlZA0KPj4+DQo+ Pj4NCj4+PiBPbiBBcHIgMTgsIDIwMTQsIGF0IDQ6NTUgQU0sIFRoZUlwdjZndXkgLiA8Y2IubGlz dDZAZ21haWwuY29tPiB3cm90ZToNCj4+Pg0KPj4+PiAqZml4aW5nIHRoZSBzb2Z0d2lyZSBjaGFp ciBlbWFpbCBhZGRyZXNzIHNpbmNlIGl0IGJvdW5jZWQuDQo+Pj4+DQo+Pj4+IE9uIEZyaSwgQXBy IDQsIDIwMTQgYXQgNTo0NCBQTSwgRnJlZCBCYWtlciAoZnJlZCkgPGZyZWRAY2lzY28uY29tPg0K Pndyb3RlOg0KPj4+Pj4NCj4+Pj4+IE9uIEFwciA0LCAyMDE0LCBhdCA2OjM0IEFNLCBDYiBCIDxj Yi5saXN0NkBnbWFpbC5jb20+IHdyb3RlOg0KPj4+Pj4NCj4+Pj4+IEhlbGxvIGZvbGtzLA0KPj4+ Pj4NCj4+Pj4+IE5vIGZvbGxvdy11cCBpbiBhIHdlZWsuIEkgYXNzdW1lIHRoZSBiZWxvdyBleHBs YW5hdGlvbiBhbmQgZXhpc2l0aW5nDQo+dGV4dA0KPj4+Pj4gYXJlIG9rLg0KPj4+Pj4NCj4+Pj4+ IFRvIHJlc3RhdGUsIHRoaXMgSS1EIHNpbXBseSBnZW5lcmFsaXplcyB0aGUgc2NvcGUgb2YgMTky LjAuMC4wLzI5Lg0KPlRoZXJlIGlzDQo+Pj4+PiBubyBndWlkYW5jZSBvbiBob3cgc3BlY2lmaWMg YWRkcmVzc2VzIG1heSBiZSB1c2VkLiBJdCBpcyBhc3N1bWVkIHRoZQ0KPj4+Pj4gZGVwbG95aW5n IHBhcnR5IHdpbGwgbm90IGNhdXNlIGEgY29uZmxpY3Qgb24gdGhlIGhvc3QgYnkgYXNzaWdpbmcg dGhlDQo+c2FtZQ0KPj4+Pj4gYWRkcmVzcyB0byB0aGUgaG9zdCBtdWx0aXBscyB0aW1lcy4uLi4g YXMgdGhhdCBpcyBhIGdlbmVyYWwgaXANCj5jb25maWd1cmF0aW9uDQo+Pj4+PiBydWxlLg0KPj4+ Pj4NCj4+Pj4+IEkgd2lsbCBhc2sgdjZvcHMgdG8gYWNjZXB0IHRoaXMgaS1kIGFuZCBkaXJlY3Qg dGhlbSB0byB0aGlzIHRocmVhZCB0bw0KPnNlZQ0KPj4+Pj4gdGhlIHNvZnR3aXJlIHZpZXcuDQo+ Pj4+Pg0KPj4+Pj4NCj4+Pj4+IE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBzb2Z0d2lyZXMgd2Fu dHMgdG8gcHJvZ3Jlc3MgdGhpcyBvbmUuIEkgZ3Vlc3MNCj5J4oCZZA0KPj4+Pj4gbGlrZSB0byBo ZWFyIGZyb20gdGhlIHNvZnR3aXJlcyBjaGFpcnMgYmVmb3JlIGJyaW5naW5nIGl0IGJhY2suDQo+ Pj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBGcmVkLA0KPj4+Pg0KPj4+PiBJdCBoYXMgYmVlbiAxNCBk YXlzIHNpbmNlIHlvdXIgIGVtYWlsLiAgSSBhbSBub3Qgc3VyZSBpZiB5b3Ugc2VudCB0aGUNCj4+ Pj4gZW1haWwgdG8gdGhlIHdyb25nIGFkZHJlc3Mgb2YgZml4ZWQgaXQuICBFaXRoZXIgd2F5LCBp IHdvdWxkIGxpa2UgdG8NCj4+Pj4gbWFrZSBwcm9ncmVzcyBvbiB0aGlzIEktRCBpbiB2Nm9wcyBz aW5jZSB0aGlzIEktRCBpcyBhYm91dCBhDQo+Pj4+IGdlbmVyYWxpemVkIGFwcHJvYWNoIHRoYXQg ZXhjZWVkcyB0aGUgYm91bmRzIG9mIHNvZnR3aXJlcy4gIFRoaXMgaGFzDQo+Pj4+IGFsc28gYmVl biBwcmVzZW50ZWQgdHdpY2UgaW4gcGVyc29uIHRvIHY2b3BzLg0KPj4+Pg0KPj4+PiBDYW1lcm9u DQo+Pj4+DQo+Pj4+PiBDQg0KPj4+Pj4NCj4+Pj4+IE9uIE1hciAyOSwgMjAxNCA0OjU5IEFNLCAi Q2IgQiIgPGNiLmxpc3Q2QGdtYWlsLmNvbT4gd3JvdGU6DQo+Pj4+Pj4NCj4+Pj4+PiBPbiBUaHUs IE1hciAyNywgMjAxNCBhdCAzOjM4IFBNLCBEYXZlIFRoYWxlciA8ZHRoYWxlckBtaWNyb3NvZnQu Y29tPg0KPj4+Pj4+IHdyb3RlOg0KPj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4+Pj4+Pj4+IEZyb206IFNvZnR3aXJlcyBbbWFpbHRvOnNvZnR3aXJlcy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgQ2INCj5CDQo+Pj4+Pj4+PiBTZW50OiBUaHVyc2RheSwgTWFyY2gg MjcsIDIwMTQgMTA6NTggQU0NCj4+Pj4+Pj4+IFRvOiBzb2Z0d2lyZXNAaWV0Zi5vcmcNCj4+Pj4+ Pj4+IFN1YmplY3Q6IFtTb2Z0d2lyZXNdIGRyYWZ0LWJ5cm5lLXY2b3BzLWNsYXRpcC0wMQ0KPj4+ Pj4+Pj4NCj4+Pj4+Pj4+IEhpIFNvZnR3aXJlcywNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBBbGVzIHBy ZXNlbnRlZCBkcmFmdC1ieXJuZS12Nm9wcy1jbGF0aXAtMDEgaW4gc29mdHdpcmVzIGF0IHRoZSBs YXN0DQo+Pj4+Pj4+PiBJRVRGDQo+Pj4+Pj4+PiBtZWV0aW5nLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ IEkgYW0gYXR0ZW1wdGluZyB0byBoYXZlIHRoaXMgSS1EIGFkb3B0ZWQgYnkgdjZvcHMsIGJ1dCB2 Nm9wcw0KPnJlcXVlc3RlZA0KPj4+Pj4+Pj4gZmVlZGJhY2sgZnJvbSBzb2Z0d2lyZXMgZmlyc3Qu DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gUGVydGFpbmluZyB0byB0aGUgbWludXRlcywgaSB3b3VsZCBs aWtlIHRvIGFkZHJlc3Mgc29tZSB0b3BpY3MgdG8NCj5tYWtlDQo+Pj4+Pj4+PiBzdXJlIGl0DQo+ Pj4+Pj4+PiBpcyBvayAgZm9yIHY2b3BzIHRvIG1vdmUgZm9yd2FyZCB3aXRoIGFkb3B0aW9uDQo+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvd2cvc29m dHdpcmUvbWludXRlcz9pdGVtPW1pbnV0ZXMtODktDQo+c29mdHdpcmUuaHRtbA0KPj4+Pj4+Pj4N Cj4+Pj4+Pj4+IFRoZSBhZGRyZXNzZXMsIGJvdGggaW4gRFMtbGl0ZSBhbmQgNDY0eGxhdCwgbmV2 ZXIgYXBwZWFycyBvbiB0aGUNCj53aXJlDQo+Pj4+Pj4+PiBzbw0KPj4+Pj4+Pj4gdGhlcmUgaXMg bm8gY2hhbmNlIG9mIG92ZXJsYXAgb3IgY29sbGlzaW9uLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBEaXNh Z3JlZSwgdGhhdCBjb25jbHVzaW9uIGRvZXNuJ3QgZm9sbG93IChhbmQgaW4gbXkgZXhwZXJpZW5j ZSBpdCdzDQo+Pj4+Pj4+IHdyb25nKS4NCj4+Pj4+Pj4gT3ZlcmxhcC9jb2xsaXNpb24gaGFwcGVu cyB3aGVuIHRoZXJlIGFyZSB0d28gaW50ZXJmYWNlcyBvbiB0aGUgc2FtZQ0KPmhvc3QNCj4+Pj4+ Pj4gKGV2ZW4gaWYgdGhleSdyZSBub3QgaW4gdXNlIHNpbXVsdGFuZW91c2x5KS4gICBUaGUgY29s bGlzaW9ucyBjYW4NCj5hZmZlY3QNCj4+Pj4+Pj4gdGhlIHJvdXRpbmcgdGFibGUgKGlmIHRoZSBo b3N0IGltcGxlbWVudHMgaW4gc3VjaCBhIHdheSksIEFDTHMgbGlrZQ0KPmluDQo+Pj4+Pj4+IGhv c3QgZmlyZXdhbGwgcG9saWNpZXMgYW5kIHN1Y2gsIGFuZCB2YXJpb3VzIGFwcGxpY2F0aW9uLWxh eWVyIHVzZXMuDQo+Pj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBBaCwgaSBzZWUgeW91ciBwb2ludC4g IElmIHRoZSBob3N0IGlzIGl0c2VsZiBib3RoIGEgQjQgYW5kIGEgQ0xBVCBhdA0KPj4+Pj4+IHRo ZSBzYW1lIHRpbWUsIHRoZW4gdGhpcyBjb2xsaXNpb24gbWF5IG9jY3VyIHdpdGhpbiB0aGUgaG9z dCwgbm90IG9uDQo+Pj4+Pj4gdGhlIHdpcmUuDQo+Pj4+Pj4NCj4+Pj4+Pj4gSXQncyBmaW5lIHRv IHNwZWNpZnkgdXNlIGFzIHRoZSBkZWZhdWx0IHJhbmdlIChlLmcuIGZvciA0NjR4bGF0IG9yDQo+ Pj4+Pj4+IERTLWxpdGUpIGJ1dA0KPj4+Pj4+PiBpbXBvcnRhbnQgdG8gbmV2ZXIgY29uc3RyYWlu IGl0IHRvIG9ubHkgdGhhdCByYW5nZSwgYXNzdW1pbmcgdGhlDQo+cmFuZ2UNCj4+Pj4+Pj4gaXMg bWFkZQ0KPj4+Pj4+PiBub24tRFMtbGl0ZSBzcGVjaWZpYy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gLURh dmUNCj4+Pj4+Pg0KPj4+Pj4+IElzIHRoZXJlIHN1Y2ggYSBjb25zdHJhaW50IHRoYXQgd291bGQg Y2F1c2UgYSBwcm9ibGVtPw0KPj4+Pj4+DQo+Pj4+Pj4gTG9va2luZyBhdCBSRkM2MzMzIGFuZCBk cmFmdC1ieXJuZS12Nm9wcy1jbGF0aXAsIGkgc2VlIHRoYXQgUkZDNjMzMw0KPj4+Pj4+IHNheXMg dGhlIEI0IFNIT1VMRCB1c2UgMTkyLjAuMC4yLiAgVG8gYSByYXRpb25hbCBwZXJzb24sIGEgZ29v ZA0KPnJlYXNvbg0KPj4+Pj4+IHRvIG5vdCB1c2UgIDE5Mi4wLjAuMiBpcyB0aGF0IGl0IGlzIGlu IHVzZSBmb3IgYSBDTEFUIGludGVyZmFjZSBvbg0KPnRoZQ0KPj4+Pj4+IHNhbWUgaG9zdCwgd2hp Y2ggZml0cyB3aXRoIHRoZSBTSE9VTEQgd29yZGluZy4NCj4+Pj4+Pg0KPj4+Pj4+IElzIHRoZXJl IHNvbWUgdGV4dCB0aGF0IHlvdSBjb3VsZCBzdWdnZXN0IHRoYXQgbWF5IGNsYXJpZnkgdGhpcw0K Pj4+Pj4+IHNpdHVhdGlvbiBpbiBkcmFmdC1ieXJuZS12Nm9wcy1jbGF0aXAgb3IgaXMgaXQgb2sg Zm9yIHY2b3BzIHRvIGFkb3B0DQo+Pj4+Pj4gYXMtaXM/ICBBcyBpdCBzdGFuZHMsIHRoZSBJLUQg c2ltcGx5IHNheXMgdGhhdCAxOTIuMC4wLjAvMjkgd2lsbCBiZQ0KPj4+Pj4+IGdlbmVyYWxpemVk IHdpdGhvdXQgbWFraW5nIGFueSBmdXJ0aGVyIHN0YXRlbWVudHMgaG93IGFkZHJlc3NlcyBtYXkN Cj5iZQ0KPj4+Pj4+IHVzZWQgd2l0aGluIHRoYXQgcmFuZ2UuDQo+Pj4+Pj4NCj4+Pj4+PiBDQg0K Pj4+Pj4NCj4+Pj4+DQo+Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+IDggaXNzdWVzIGluIHZpcnR1YWwgaW5mcmFzdHJ1Y3R1 cmUNCj4+Pj4+IGh0dHA6Ly9kY3JvY2tlci5uZXQvI2ZhbGxhY2llcw0KPj4+Pj4NCj4+Pg0KPj4+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K Pj4+IDggaXNzdWVzIGluIHZpcnR1YWwgaW5mcmFzdHJ1Y3R1cmUNCj4+PiBodHRwOi8vZGNyb2Nr ZXIubmV0LyNmYWxsYWNpZXMNCj4+Pg0KPj4NCj4+DQo+DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+OCBpc3N1ZXMgaW4gdmlydHVhbCBp bmZyYXN0cnVjdHVyZQ0KPmh0dHA6Ly9kY3JvY2tlci5uZXQvI2ZhbGxhY2llcw0KDQo= From nobody Mon Apr 28 09:19: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 2448E1A6F4C for ; Mon, 28 Apr 2014 09:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 pVz4KHVbqRsN for ; Mon, 28 Apr 2014 09:19:35 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by ietfa.amsl.com (Postfix) with ESMTP id 162DC1A6F3F for ; Mon, 28 Apr 2014 09:19:34 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id cc10so5954845wib.16 for ; Mon, 28 Apr 2014 09:19:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:message-id:from:to:cc:subject:in-reply-to :references:user-agent:mime-version:content-type; bh=d4vaOhqTLPrSy6Ah9Y5BPJYuyxJKTJSuwb4fAgNArSk=; b=mzrSZR1QfR9/6WNZxDvOtv4j+aca09dSsvK5XI9LPaiIADrm/6puzbskrZCi3aOHG/ mXd4Ti//Q+YNXAFpY4Xny40cmYwsiK2wb1evjY+hBLdTQJXS6p/NIWUHb4umQ0xYGWjk tHQCqeBhHfdz4m4xC8YG7goV8K12tcjsJYavmTxTA+zwzSlWrIHTzIHgxAYxrMiTaWDq 2taoBNnmljwgcXTpog5h03aqwuBCVA6lW0EBA/8WEiY3Gojh6Fj4cvff4wqSmXz/sV7P SG9PosdHLK+YBsFAPdQ2n9BOly2ZbicP6s3TZmG25hS3C5e+knlfrLy6CN2xB8edijB0 sAig== X-Gm-Message-State: ALoCoQn4YD4yusmc+Rwi6GphKX31h1u1/UZkUKKXmpyOR1mDUEWLNM7IDKST1kELpRjzupXh5miX X-Received: by 10.180.14.199 with SMTP id r7mr16318833wic.0.1398701973903; Mon, 28 Apr 2014 09:19:33 -0700 (PDT) Received: from dhcp-c101a706.ucd.ie.ucd.ie ([2001:770:98:400:20aa:4caf:2bd7:98ae]) by mx.google.com with ESMTPSA id vp5sm26701883wjc.31.2014.04.28.09.19.32 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Apr 2014 09:19:32 -0700 (PDT) X-Google-Original-From: Niall O'Reilly Date: Mon, 28 Apr 2014 17:20:38 +0100 Message-ID: From: "Niall O'Reilly" To: Ted Lemon In-Reply-To: <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> <4EABCE38-7CBA-4C95-84EE-686A2300F26E@delong.com> <8E450CDC-FFC5-4649-89FE-387836C8E40B@nominum.com> <118D079B-FC99-4606-B289-4201137A5815@nominum.com> <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/0h8RqJJlXuZaGk6JTUPGtJBYzwM Cc: Philip Homburg , "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 28 Apr 2014 16:19:37 -0000 Ted, I'm sorry for the delay in replying. I wasn't aware of a way to disable arbitrary ethertypes on the gear we use. It took a little time to discover whether this was just due to my ignorance, or rather an indication of what the equipment could do. After some digging, I'm still not entirely sure. At Tue, 22 Apr 2014 12:12:48 -0400, Ted Lemon wrote: > > > I expect that the two points I was able to confirm above are widely > > known among those who have tried to implement IPv6 on an existing > > IPv4-only network. > > Thanks. So is it the case that there is a UI element that says > "disable DHCPv4 except from the following IP source addresses/on the > following physical ports," Definitely. > and the switch has no way to for instance disable arbitrary > ethertypes? This is apparently so, as far as I and my colleagues in our Net-Ops team are aware or can establish from the experience and documentation available to us. So, a "yes" to your compound question, as far as I can see. This leaves such pre-IPv6 switch equipment as we have configurable to block rogue DHCP (v4) traffic but unable to protect against rogue IPv6 traffic on the link. ATB Niall O'Reilly From nobody Mon Apr 28 09:23: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 7D72C1A6F52 for ; Mon, 28 Apr 2014 09:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 Ova6fIDED67s for ; Mon, 28 Apr 2014 09:23:52 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 542611A08C5 for ; Mon, 28 Apr 2014 09:23:52 -0700 (PDT) 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 B2ADD1B805A for ; Mon, 28 Apr 2014 09:23:51 -0700 (PDT) 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 57A7219005C; Mon, 28 Apr 2014 09:23:51 -0700 (PDT) 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; Mon, 28 Apr 2014 09:23:51 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: Date: Mon, 28 Apr 2014 12:23:46 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> <4EABCE38-7CBA-4C95-84EE-686A2300F26E@delong.com> <8E450CDC-FFC5-4649-89FE-387836C8E40B@nominum.com> <118D079B-FC99-4606-B289-4201137A5815@nominum.com> <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> To: Niall O'Reilly X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8MUHrMUaKS69t-cwGGWkvjlkWAU Cc: Philip Homburg , "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 28 Apr 2014 16:23:53 -0000 On Apr 28, 2014, at 12:20 PM, Niall O'Reilly = wrote: > This leaves such pre-IPv6 switch equipment as we have configurable > to block rogue DHCP (v4) traffic but unable to protect against rogue > IPv6 traffic on the link. Hm, okay. Are you guys using a specific brand of equipment, or is this = a problem you're seeing with a variety of switches from different = vendors? From nobody Mon Apr 28 11:31: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 1136D1A04F1 for ; Mon, 28 Apr 2014 11:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8VTssJZZ-8eg for ; Mon, 28 Apr 2014 11:30:57 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id E717D1A6F54 for ; Mon, 28 Apr 2014 11:30:56 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id bs8so6158145wib.11 for ; Mon, 28 Apr 2014 11:30:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:message-id:from:to:cc:subject:in-reply-to :references:user-agent:mime-version:content-type; bh=+IscxwHlvDrLKSgJrIBil+wlqufg1xD9zsmyyYUtHx0=; b=Jox+kRINdIPzIz9R3ultgMEFzaZc98cAmXubGYgDgi/4ufIU66ZxFY8Bp0HMyonZTZ Qc8P/UjO54Q8S1BTLLbzIkzUIXPE7m/ya6Ih5MPIeWOr9WlilTbBRm7HlD7lY0yyMraG AKMAU6V4ohFmz5MrELZ8EwMpLVs+Md0VoZPRfiKMJ70cFE7hjOP+DvirFkxY+VyA5ukV RcY46G2NmAgr1StifFivQelzAjNE4lJpg05SKQv4lyWM5DD37opMAbgiAid8wsDjLuCI SxL+AjBLeQQDPx08sAUXJuluVJJ+JQhg9AAjz1gpC8RhqgLnu/VKiafJsmUFNeePRzSc V2fQ== X-Gm-Message-State: ALoCoQk0c3WVTzvMNxgSbLVtgQJ/udkAjarTGREC62wNXii/2MeAzyg0szIJG+OY4yK8mYO9qieC X-Received: by 10.180.189.65 with SMTP id gg1mr16666171wic.56.1398709855660; Mon, 28 Apr 2014 11:30:55 -0700 (PDT) Received: from dhcp-179.wlan.no8.be.ucd.ie ([2001:770:13f:1:f125:4023:95d7:6583]) by mx.google.com with ESMTPSA id fu10sm11932126wib.11.2014.04.28.11.30.54 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Apr 2014 11:30:54 -0700 (PDT) X-Google-Original-From: Niall O'Reilly Date: Mon, 28 Apr 2014 19:30:54 +0100 Message-ID: From: "Niall O'Reilly" To: Ted Lemon In-Reply-To: <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> <4EABCE38-7CBA-4C95-84EE-686A2300F26E@delong.com> <8E450CDC-FFC5-4649-89FE-387836C8E40B@nominum.com> <118D079B-FC99-4606-B289-4201137A5815@nominum.com> <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/9LvyoZTL5sbre17ZG1EYHpPCa9o Cc: Philip Homburg , "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 28 Apr 2014 18:30:59 -0000 At Mon, 28 Apr 2014 12:23:46 -0400, Ted Lemon wrote: > > On Apr 28, 2014, at 12:20 PM, Niall O'Reilly wrote: > > This leaves such pre-IPv6 switch equipment as we have configurable > > to block rogue DHCP (v4) traffic but unable to protect against rogue > > IPv6 traffic on the link. > > Hm, okay. Are you guys using a specific brand of equipment, or is > this a problem you're seeing with a variety of switches from > different vendors? Where I work, we use Cisco gear. Current access-network kit, running a current image, doesn't show the kind of problem I've described, but most of our installed network plant does, and will until its turn for capital spend comes round. ATB Niall From nobody Mon Apr 28 11:52: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 D55BA1A6FEB for ; Mon, 28 Apr 2014 11:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 fieQNrXOvPKZ for ; Mon, 28 Apr 2014 11:52:43 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id AE27D1A6FE8 for ; Mon, 28 Apr 2014 11:52:43 -0700 (PDT) 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 2771A1B803B for ; Mon, 28 Apr 2014 11:52:43 -0700 (PDT) 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 08A7919005C; Mon, 28 Apr 2014 11:52:43 -0700 (PDT) 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; Mon, 28 Apr 2014 11:52:36 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: Date: Mon, 28 Apr 2014 14:52:34 -0400 Content-Transfer-Encoding: 7bit Message-ID: <7310412C-64E9-4A11-9812-92A969082131@nominum.com> References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <20140416155714.GB64039@ricotta.doit.wisc.edu> <4EABCE38-7CBA-4C95-84EE-686A2300F26E@delong.com> <8E450CDC-FFC5-4649-89FE-387836C8E40B@nominum.com> <118D079B-FC99-4606-B289-4201137A5815@nominum.com> <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> To: Niall O'Reilly X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Be3ym75pWWtcqyjAzXrh4B77-mQ Cc: Philip Homburg , "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 28 Apr 2014 18:52:46 -0000 On Apr 28, 2014, at 2:30 PM, Niall O'Reilly wrote: > Current access-network kit, running a current image, doesn't show > the kind of problem I've described, but most of our installed > network plant does, and will until its turn for capital spend > comes round. I thought Cisco had a policy of not charging extra for IPv6 upgrades. From nobody Mon Apr 28 12:08: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 BD6D71A8834 for ; Mon, 28 Apr 2014 12:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 vgNvW-ZPs2P2 for ; Mon, 28 Apr 2014 12:08:07 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 573D11A6FB7 for ; Mon, 28 Apr 2014 12:08:06 -0700 (PDT) Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 229C9629C8 for ; Mon, 28 Apr 2014 21:08:05 +0200 (CEST) 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 D971F629C2 for ; Mon, 28 Apr 2014 21:08:04 +0200 (CEST) Received: (qmail 40834 invoked by uid 1007); 28 Apr 2014 21:08:04 +0200 Date: Mon, 28 Apr 2014 21:08:04 +0200 From: Gert Doering To: Ted Lemon Message-ID: <20140428190804.GK43641@Space.Net> References: <118D079B-FC99-4606-B289-4201137A5815@nominum.com> <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7310412C-64E9-4A11-9812-92A969082131@nominum.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wNRlrYVd2u_K-OYnJ81BsRE0KZU Cc: Philip Homburg , "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 28 Apr 2014 19:08:10 -0000 Hi, On Mon, Apr 28, 2014 at 02:52:34PM -0400, Ted Lemon wrote: > I thought Cisco had a policy of not charging extra for IPv6 upgrades. *If* the hardware you have is IPv6-capable, and *if* the business unit in question remembers that policy, yes. 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 nobody Mon Apr 28 12:53: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 921441A6FB2 for ; Mon, 28 Apr 2014 12:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 mTcAe2DaL1jB for ; Mon, 28 Apr 2014 12:53:27 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8BF1A6FAB for ; Mon, 28 Apr 2014 12:53:27 -0700 (PDT) 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 8FD211B8055 for ; Mon, 28 Apr 2014 12:53:26 -0700 (PDT) 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 77D3F19005C; Mon, 28 Apr 2014 12:53:26 -0700 (PDT) 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; Mon, 28 Apr 2014 12:53:26 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <20140428190804.GK43641@Space.Net> Date: Mon, 28 Apr 2014 15:53:22 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> References: <118D079B-FC99-4606-B289-4201137A5815@nominum.com> <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/VxsdzekEUAIKGddNSlmQbIF7tH4 Cc: Philip Homburg , "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 28 Apr 2014 19:53:28 -0000 On Apr 28, 2014, at 3:08 PM, Gert Doering wrote: > *If* the hardware you have is IPv6-capable, and *if* the business unit > in question remembers that policy, yes. Seems like you could insist. How old is the newest non-IPv6-capable = equipment? From nobody Mon Apr 28 13:38: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 0BEC41A6FB9 for ; Mon, 28 Apr 2014 13:38:02 -0700 (PDT) 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 DH9Hmf5gd4oU for ; Mon, 28 Apr 2014 13:37:55 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id AD7301A6FB7 for ; Mon, 28 Apr 2014 13:37:54 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s3SKbqaq061551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 28 Apr 2014 21:37:52 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <535EBC20.10900@foobar.org> Date: Mon, 28 Apr 2014 21:37:52 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ted Lemon References: <118D079B-FC99-4606-B289-4201137A5815@nominum.com> <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> In-Reply-To: <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ZKBnh_B4riQFKx7rdCi4-fyT67I Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 28 Apr 2014 20:38:02 -0000 On 28/04/2014 20:53, Ted Lemon wrote: > Seems like you could insist. How old is the newest non-IPv6-capable > equipment? Well you can insist, yes, but it takes time and patience, during which your network can be vulnerable to problems. There's a slightly old list for RA guard support here: > https://www.ernw.de/download/raguard_support_05022013.pdf You can see that RA Guard (+ dhcpv6 guard) is absent on the entire Cisco Nexus line. This can be worked around to some degree for physical hardware, but not for virtualised infrastructure, where the situation is pretty grim at least for vmware based hypervisors. I haven't found a similar list for DHCPv6 guard, but from previous investigation, support was even less well developed compared to RA guard due to the complexities involved if the support involves anything other than a simple tcp/udp port block. Nick From nobody Mon Apr 28 14:01: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 E7D721A6FB9 for ; Mon, 28 Apr 2014 14:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 PpR1Wbkn7iWr for ; Mon, 28 Apr 2014 14:01:01 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 14EDC1A6FEE for ; Mon, 28 Apr 2014 14:01:00 -0700 (PDT) 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 8202B1B803B for ; Mon, 28 Apr 2014 14:00:59 -0700 (PDT) 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 5439519005C; Mon, 28 Apr 2014 14:00:59 -0700 (PDT) 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; Mon, 28 Apr 2014 14:00:59 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <535EBC20.10900@foobar.org> Date: Mon, 28 Apr 2014 17:00:55 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <118D079B-FC99-4606-B289-4201137A5815@nominum.com> <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/K7oeTCmzAJ4hgESpyb9uYL6Q1G4 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 28 Apr 2014 21:01:03 -0000 Hm. Cisco documentation for NX-OS does seem scant on the topic of = RA-Guard. Does anybody know any more about this? From nobody Mon Apr 28 14:27: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 D69411A6FB7 for ; Mon, 28 Apr 2014 14:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 SSmMCns8fzYr for ; Mon, 28 Apr 2014 14:27:39 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) by ietfa.amsl.com (Postfix) with ESMTP id 752871A700B for ; Mon, 28 Apr 2014 14:27:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 6DFA74C; Mon, 28 Apr 2014 23:27:37 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzmCY2zyRUQ1; Mon, 28 Apr 2014 23:27:29 +0200 (CEST) Received: from [IPv6:2a00:8640:1::68a4:b11:ea86:7180] (unknown [IPv6:2a00:8640:1:0:68a4:b11:ea86:7180]) by mail.sintact.nl (Postfix) with ESMTPSA id B3ACB38; Mon, 28 Apr 2014 23:27:28 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.0\)) From: Sander Steffann In-Reply-To: Date: Mon, 28 Apr 2014 23:27:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <718C2C7A-B100-4F71-91E9-2804C396ADF4@steffann.nl> References: <118D079B-FC99-4606-B289-4201137A5815@nominum.com> <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> To: Ted Lemon X-Mailer: Apple Mail (2.1878) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/VKGlkM14C8r0boSYmZMfEd7R7Qk Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 28 Apr 2014 21:27:41 -0000 Hi Ted, > Hm. Cisco documentation for NX-OS does seem scant on the topic of = RA-Guard. Does anybody know any more about this? Yes: it really is as bad as it seems :( Cheers, Sander From nobody Mon Apr 28 14:30: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 03F751A07A2 for ; Mon, 28 Apr 2014 14:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 aaB87PcQL3IC for ; Mon, 28 Apr 2014 14:30:49 -0700 (PDT) Received: from smtpauth4.wiscmail.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) by ietfa.amsl.com (Postfix) with ESMTP id B2CC51A6F03 for ; Mon, 28 Apr 2014 14:30:49 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth4.wiscmail.wisc.edu by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0N4R00100FMPSH00@smtpauth4.wiscmail.wisc.edu> for v6ops@ietf.org; Mon, 28 Apr 2014 16:30:48 -0500 (CDT) X-Spam-PmxInfo: Server=avs-4, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.28.212119, SenderIP=0.0.0.0 Received: from havarti.local (desktop129.discovery.wisc.edu [128.104.153.129]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0N4R006LKFRA8K20@smtpauth4.wiscmail.wisc.edu>; Mon, 28 Apr 2014 16:30:48 -0500 (CDT) Date: Mon, 28 Apr 2014 16:30:46 -0500 From: "Dale W. Carder" To: Nick Hilliard Message-id: <20140428213045.GL511@havarti.local> References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> In-reply-to: <535EBC20.10900@foobar.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_KalTpolfi5p33r9SjEhk1EweSA Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 28 Apr 2014 21:30:52 -0000 Thus spake Nick Hilliard (nick@foobar.org) on Mon, Apr 28, 2014 at 09:37:52PM +0100: > On 28/04/2014 20:53, Ted Lemon wrote: > > Seems like you could insist. How old is the newest non-IPv6-capable > > equipment? > > Well you can insist, yes, but it takes time and patience, during which your > network can be vulnerable to problems. > > There's a slightly old list for RA guard support here: > > > https://www.ernw.de/download/raguard_support_05022013.pdf > > You can see that RA Guard (+ dhcpv6 guard) is absent on the entire Cisco > Nexus line. This can be worked around to some degree for physical > hardware RA Guard "the feature" is not there, but the workaround is simple. This example is for a n5548: interface Ethernet1/14 description omg_server :!P: ipv6 port traffic-filter G-T-v6NoDhcpServerNoRouterAdv in switchport mode trunk switchport trunk allowed vlan 38-3880 spanning-tree port type edge trunk spanning-tree guard root spanning-tree bpdufilter enable no snmp trap link-status storm-control broadcast level 0.50 ipv6 access-list G-T-v6NoDhcpServerNoRouterAdv 10 remark Id: G-T-v6NoDhcpServerNoRouterAdv.acl,v 1.2 2010/12/06 00:48:13 m6k Exp 20 deny icmp any any router-advertisement 30 deny udp any eq 547 any eq 546 40 permit ipv6 any any sn-cssc-b217-5-lab# sh ver | inc "system image" system image file is: bootflash:/n5000-uk9.5.0.3.N2.1.bin Dale From nobody Mon Apr 28 14:39: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 E10F71A882C for ; Mon, 28 Apr 2014 14:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 BcJO1jsgKlxc for ; Mon, 28 Apr 2014 14:39:40 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 041431A86F5 for ; Mon, 28 Apr 2014 14:39:40 -0700 (PDT) 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 5B9351B8050 for ; Mon, 28 Apr 2014 14:39:39 -0700 (PDT) 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 4784E190052; Mon, 28 Apr 2014 14:39:39 -0700 (PDT) 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; Mon, 28 Apr 2014 14:39:39 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <20140428213045.GL511@havarti.local> Date: Mon, 28 Apr 2014 17:39:35 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <230FCFCE-7991-4F8D-BAE6-E1B137D0A391@nominum.com> References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> To: "Dale W. Carder" X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/swn8I7kTQsEB_vC424zi7eRX3iI Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 28 Apr 2014 21:39:41 -0000 On Apr 28, 2014, at 5:30 PM, Dale W. Carder wrote: > RA Guard "the feature" is not there, but the workaround is simple. = This > example is for a n5548: [...] Cool, thanks! I'm surprised that I didn't turn up any articles online = on how to do this. Cisco suggests this incantation for Catalyst, but = not Nexus. From nobody Mon Apr 28 14:58: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 2A1DD1A8842 for ; Mon, 28 Apr 2014 14:58:13 -0700 (PDT) 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 Hdl7HLiP7XX3 for ; Mon, 28 Apr 2014 14:58:07 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 64BB91A8839 for ; Mon, 28 Apr 2014 14:58:06 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from [10.230.100.84] (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s3SLw337062311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Apr 2014 22:58:03 +0100 (IST) (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 [10.230.100.84] References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> Mime-Version: 1.0 (1.0) In-Reply-To: <20140428213045.GL511@havarti.local> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> X-Mailer: iPhone Mail (11D201) From: Nick Hilliard Date: Mon, 28 Apr 2014 22:58:02 +0100 To: "Dale W. Carder" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/CmHq2p7oQobcWGmuQ3QcKXSNNuc Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 28 Apr 2014 21:58:13 -0000 On 28 Apr 2014, at 22:30, "Dale W. Carder" wrote: >> You can see that RA Guard (+ dhcpv6 guard) is absent on the entire Cisco >> Nexus line. This can be worked around to some degree for physical >> hardware >=20 > RA Guard "the feature" is not there, but the workaround is simple. This > example is for a n5548: Not supported on nexus 1000 (the virtual switch). IPv6 acls are not supporte= d on this platform at all. That means no functional ipv6 client support on t= he esxi platform at the moment.=20 Nick From nobody Mon Apr 28 15:05: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 13FE41A8850 for ; Mon, 28 Apr 2014 15:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 el24cX9uIzaj for ; Mon, 28 Apr 2014 15:04:52 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id B06621A885B for ; Mon, 28 Apr 2014 15:03:09 -0700 (PDT) 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 2423E1B8038 for ; Mon, 28 Apr 2014 15:03:09 -0700 (PDT) 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 1C68B190052; Mon, 28 Apr 2014 15:03:09 -0700 (PDT) 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; Mon, 28 Apr 2014 15:03:08 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> Date: Mon, 28 Apr 2014 18:03:04 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/dasuejeHTr8PKQfTLUTYEltt_F8 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 28 Apr 2014 22:05:13 -0000 On Apr 28, 2014, at 5:58 PM, Nick Hilliard wrote: > Not supported on nexus 1000 (the virtual switch). IPv6 acls are not = supported on this platform at all. That means no functional ipv6 client = support on the esxi platform at the moment.=20 Yes, but the nexus 1000 has a firewall. Are you telling me that = there's no way to configure the firewall to block rogue RAs? From nobody Mon Apr 28 15:27: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 B56F81A8832 for ; Mon, 28 Apr 2014 15:27:11 -0700 (PDT) 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 r_CLaNvqbFGS for ; Mon, 28 Apr 2014 15:27:09 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 41A7A1A6FB8 for ; Mon, 28 Apr 2014 15:27:08 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from [10.230.100.84] (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s3SMR5Ru062447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Apr 2014 23:27:07 +0100 (IST) (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 [10.230.100.84] References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <24256227-1B50-4B2F-9C2D-1ECA5C51FCEF@foobar.org> X-Mailer: iPhone Mail (11D201) From: Nick Hilliard Date: Mon, 28 Apr 2014 23:27:06 +0100 To: Ted Lemon Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/dlCdlS0gb9kJA8GOhRJvB-boRgA Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 28 Apr 2014 22:27:11 -0000 On 28 Apr 2014, at 23:03, Ted Lemon wrote: > Yes, but the nexus 1000 has a firewall. I think you're getting mixed up here. The nexus 1000v is a virtual switch an= d the asa1000v is the virtual firewall.=20 This isn't a firewalling issue because FWs act at layer 3 and ra guard / dhc= pv6 guard act at l2. If you're referring to vsg, that's zone based protecti= on which is a different kettle of fish. > Are you telling me that there's no way to configure the firewall to block= rogue RAs? There is currently no way to block rogue RAs or rogue dhcpv6 pkts at layer 2= on VMware esxi, either with the Cisco nexus1000v soft-switch or the native s= oft-switch. Nick From nobody Mon Apr 28 19:04: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 1B76B1A8880 for ; Mon, 28 Apr 2014 19:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 KBaExh1CtbpU for ; Mon, 28 Apr 2014 19:04:32 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0F11A887E for ; Mon, 28 Apr 2014 19:04:29 -0700 (PDT) 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 50F471B8055 for ; Mon, 28 Apr 2014 19:04:28 -0700 (PDT) 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 3B8AA19005C; Mon, 28 Apr 2014 19:04:28 -0700 (PDT) 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; Mon, 28 Apr 2014 19:04:28 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> Date: Mon, 28 Apr 2014 22:04:22 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/3WLgWekFIKcOL_D2k2nuPGm3O14 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 29 Apr 2014 02:04:34 -0000 On Apr 28, 2014, at 5:58 PM, Nick Hilliard wrote: > Not supported on nexus 1000 (the virtual switch). IPv6 acls are not = supported on this platform at all. That means no functional ipv6 client = support on the esxi platform at the moment.=20 Hm, so you connect virtual machines that aren't in the same trust domain = to the same virtual layer 2? Why would you do that? From nobody Mon Apr 28 22:18: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 C94E11A8849 for ; Mon, 28 Apr 2014 22:18:33 -0700 (PDT) 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 kU1A9m25NMqG for ; Mon, 28 Apr 2014 22:18:32 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id A4C221A8842 for ; Mon, 28 Apr 2014 22:18:31 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s3T5ISpt066704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 29 Apr 2014 06:18:28 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <535F3624.4020801@foobar.org> Date: Tue, 29 Apr 2014 06:18:28 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ted Lemon References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> In-Reply-To: <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/yfrvi_fBn-SAZNgXqs9pozPKnQM Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 29 Apr 2014 05:18:34 -0000 On 29/04/2014 03:04, Ted Lemon wrote: > Hm, so you connect virtual machines that aren't in the same trust domain > to the same virtual layer 2? Why would you do that? Why is s/virtual/physical/ any different? One reason specific to virtualised environments is that commercial services require high availability with fast failover to alternative gateways. This means VRRP (or your favourite first-hop redundancy protocol) because fast failover with RA isn't feasible. You cannot run a vrrp instance per customer because that doesn't scale. That means putting tenants in a shared domain so you can share the same gateway for multiple customers. Nick From nobody Mon Apr 28 22:29: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 DC3E01A884C for ; Mon, 28 Apr 2014 22:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.602 X-Spam-Level: X-Spam-Status: No, score=-4.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 wmB5M9_DDPsW for ; Mon, 28 Apr 2014 22:29:36 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id E534D1A8843 for ; Mon, 28 Apr 2014 22:29:35 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B5013A2; Tue, 29 Apr 2014 07:29:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1398749373; bh=W7ttrkbcY+bdSTETEHDAVg1oultNuPFahhD4Qx9iAXU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=LytF9tEAJqD+h1FvOjjBcX4vMl6dxp8tIBwVZgYEC3PN+OOeNWyMDO73M206OtL2f xGrxn0qmTy1fJmAvVKtX/8qVjI0TApfPhj5cNQ2E4nU2g801TtHOFwhRq6F+VcL5jp fdbT4+4p3q262t/xfIU+0VxhvLd7q1NZH0NxHDyU= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A9CBDA1; Tue, 29 Apr 2014 07:29:33 +0200 (CEST) Date: Tue, 29 Apr 2014 07:29:33 +0200 (CEST) From: Mikael Abrahamsson To: Nick Hilliard In-Reply-To: <535F3624.4020801@foobar.org> Message-ID: References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> <535F3624.4020801@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; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_x3g2b9OhIbH-7QMVldpIiGFY1E Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 29 Apr 2014 05:29:38 -0000 On Tue, 29 Apr 2014, Nick Hilliard wrote: > One reason specific to virtualised environments is that commercial > services require high availability with fast failover to alternative > gateways. This means VRRP (or your favourite first-hop redundancy > protocol) because fast failover with RA isn't feasible. You cannot run > a vrrp instance per customer because that doesn't scale. That means > putting tenants in a shared domain so you can share the same gateway for > multiple customers. Then demand that the virtualised environment vendors do what the access switch vendors have done for a long time, implement either private vlan or SAVI type functionality. ... or put L3 routing so far out into the network that VRRP actually does scale, or use virtualised machines to do the VRRP so you can split it up between a lot of CPUs. It's not like this is unsolvable. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Apr 28 22:37: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 372111A070B for ; Mon, 28 Apr 2014 22:37:21 -0700 (PDT) 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 JVBU0Zo7iW3B for ; Mon, 28 Apr 2014 22:37:19 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4C81A8847 for ; Mon, 28 Apr 2014 22:37:19 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s3T5bG3w067026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 29 Apr 2014 06:37:17 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <535F3A8C.2050902@foobar.org> Date: Tue, 29 Apr 2014 06:37:16 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> <535F3624.4020801@foobar.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qFLHwEQI6W7CaBb6qxmPfnqcK9U Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 29 Apr 2014 05:37:21 -0000 On 29/04/2014 06:29, Mikael Abrahamsson wrote: > Then demand that the virtualised environment vendors you know how well this works in practice: it takes years and the ability to wave a massive amount of money in front of the vendor. This is getting way off topic, btw. Nick From nobody Tue Apr 29 04:58: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 2A4A51A070A for ; Tue, 29 Apr 2014 04:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 nVTyTWHb78aJ for ; Tue, 29 Apr 2014 04:57:32 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 12F0C1A0816 for ; Tue, 29 Apr 2014 04:57:31 -0700 (PDT) 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 EE6B91B8010 for ; Tue, 29 Apr 2014 04:57:30 -0700 (PDT) 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 CD81119005C; Tue, 29 Apr 2014 04:57:30 -0700 (PDT) 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; Tue, 29 Apr 2014 04:57:30 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <535F3A8C.2050902@foobar.org> Date: Tue, 29 Apr 2014 07:57:16 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> <535F3624.4020801@foobar.org> <535F3A8C.2050902@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/UXnix6oXshyqXvFd7ZkH5VDQ51U Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 29 Apr 2014 11:57:51 -0000 On Apr 29, 2014, at 1:37 AM, Nick Hilliard wrote: > This is getting way off topic, btw. Not really. You said "the following change is needed because X." So = we are exploring the parameters of X. For you it seems to boil down to = "because virtualization software from VMware and Cisco has serious = limitations with respect to IPv6." But given that the whole = virtualization thing is fairly new, and that one of the points of doing = virtualization is to commoditize the network environment, this seems = like a problem that will get solved long before there is any significant = deployment of the No IPv4 proposal. Also, when I read the documentation, there did seem to be a way to = completely disable IPv6 at least on Cisco virtual switches. I don't = know if that causes filtering to happen, or just prevents the switch = from actively supporting IPv6, but it would be interesting to know which = it is. While we didn't actually find a smoking gun on your network, it's = possible that your point is still valid on other networks. If this is = a real problem, it should be addressed. So it's worth evaluating how = serious and long-term a problem it is. I don't know that this is the = right place for that to happen, of course, but it does seem relevant. = This working group has published at least one draft recently on a = closely related topic.= From nobody Tue Apr 29 05:23: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 144E71A08BB for ; Tue, 29 Apr 2014 05:23:12 -0700 (PDT) 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 IxxR-2XBd3Dn for ; Tue, 29 Apr 2014 05:23:09 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id D032A1A078B for ; Tue, 29 Apr 2014 05:23:08 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s3TCN5jt071009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 29 Apr 2014 13:23:06 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <535F99A9.3030402@foobar.org> Date: Tue, 29 Apr 2014 13:23:05 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ted Lemon References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> <535F3624.4020801@foobar.org> <535F3A8C.2050902@foobar.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/AjjsGBo-humHeSdc7LlJV1PPFEI Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 29 Apr 2014 12:23:12 -0000 On 29/04/2014 12:57, Ted Lemon wrote: > For you it seems to boil down to > "because virtualization software from VMware and Cisco has serious > limitations with respect to IPv6." No. I was just clarifying a particular point about a particular question you had about certain forms of ipv6 support on a specific line of cisco kit which I happen to be familiar with. If you do a stack unwind of this conversation: - it is currently not possible to run large scale ipv6 shared L2 domains on specific (albeit market leader) hypervisor platforms, which is a subset of a much bigger problem: - dhcpv6 guard / ra guard support is not supported on plenty of types of kit from a wide variety of vendors (link provided to show the scale of this problem), which means that: - from an operational point of view, the poor support for dhcpv6/ra guard is a general reason why, given the choice between using either (dhcpv4) or (dhcpv6 + ra) for ending up with the same outcome, it would be operationally more attractive to use dhcpv4, - which is only one of many reasons that a bunch of people have put forward to suggest that dhcpv4 might be a better choice as a transport mechanism for delivering the bits specified in draft-ietf-sunset4-noipv4, - assuming that the basic idea of having a signal to shut down ipv4 services as specified in the draft is a sensible idea in the first place. Nick From nobody Tue Apr 29 05:46: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 D30301A08C8 for ; Tue, 29 Apr 2014 05:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 wrGT4LF0Rkbq for ; Tue, 29 Apr 2014 05:46:09 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id A2F901A08C0 for ; Tue, 29 Apr 2014 05:46:07 -0700 (PDT) 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 A89181B805A for ; Tue, 29 Apr 2014 05:46:06 -0700 (PDT) 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 9103919005C; Tue, 29 Apr 2014 05:46:06 -0700 (PDT) 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; Tue, 29 Apr 2014 05:46:06 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <535F99A9.3030402@foobar.org> Date: Tue, 29 Apr 2014 08:45:55 -0400 Content-Transfer-Encoding: 7bit Message-ID: <0C03200E-B349-44D4-BE3F-512AD6A7A417@nominum.com> References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> <535F3624.4020801@foobar.org> <535F3A8C.2050902@foobar.org> <535F99A9.3030402@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/lCaUDqzf3CqOKIWsY8CjtNG5cWY Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 29 Apr 2014 12:46:11 -0000 On Apr 29, 2014, at 8:23 AM, Nick Hilliard wrote: > - dhcpv6 guard / ra guard support is not supported on plenty of types of > kit from a wide variety of vendors (link provided to show the scale of this > problem), which means that: The information in the link you provided was wrong. From nobody Tue Apr 29 08:54: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 E8F151A0910 for ; Tue, 29 Apr 2014 08:54:25 -0700 (PDT) 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 GL3g4QK0Z22p for ; Tue, 29 Apr 2014 08:54:23 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 972021A08F0 for ; Tue, 29 Apr 2014 08:54:23 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s3TFsKrI072672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 29 Apr 2014 16:54:20 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <535FCB2C.3030502@foobar.org> Date: Tue, 29 Apr 2014 16:54:20 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ted Lemon References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> <535F3624.4020801@foobar.org> <535F3A8C.2050902@foobar.org> <535F99A9.3030402@foobar.org> <0C03200E-B349-44D4-BE3F-512AD6A7A417@nominum.com> In-Reply-To: <0C03200E-B349-44D4-BE3F-512AD6A7A417@nominum.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/EBhSRkA6POsGVqWKwL7eX-fbKoM Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 29 Apr 2014 15:54:26 -0000 On 29/04/2014 13:45, Ted Lemon wrote: > The information in the link you provided was wrong. I did mention that the document was both a little old (13 months) and that there were workarounds for some kit. The document specifies "RA Guard", which is a name for a category of ipv6 RA filtering, and some kit can use IPv6 ACLs to implement some of the features suggested by the SAVI folks. Certainly not all, but some yes. This does not invalidate the reality that there is a problem with ipv6 control packet filtering on many l2 devices on the market, physical and virtual. Nick From nobody Tue Apr 29 09:09: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 4D4DD1A090E for ; Tue, 29 Apr 2014 09:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 in8O8cL8CDYH for ; Tue, 29 Apr 2014 09:09:02 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 197B11A090D for ; Tue, 29 Apr 2014 09:09:02 -0700 (PDT) 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 E18241B81D5 for ; Tue, 29 Apr 2014 09:09:00 -0700 (PDT) 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 7ECFE19005C; Tue, 29 Apr 2014 09:09:00 -0700 (PDT) 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; Tue, 29 Apr 2014 09:09:00 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <535FCB2C.3030502@foobar.org> Date: Tue, 29 Apr 2014 12:08:56 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <8DB83B3D-D09C-4977-9B4F-75EA2DD3B71D@nominum.com> References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> <535F3624.4020801@foobar.org> <535F3A8C.2050902@foobar.org> <535F99A9.3030402@foobar.org> <0C03200E-B349-44D4-BE3F-512AD6A7A417@nominum.com> <535FCB2C.3030502@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4XSJtdDsHqgqkG0LT3YXLhpOu8M Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 29 Apr 2014 16:09:07 -0000 On Apr 29, 2014, at 11:54 AM, Nick Hilliard wrote: > This does not invalidate the reality that there is a problem with ipv6 > control packet filtering on many l2 devices on the market, physical = and > virtual. It also doesn't establish it. That was what I was asking for earlier. = I think that if there is a serious gap here, the working group should = consider that. But we haven't actually established that such a gap = exists. My intuition is that you may be right about this, but I'd like = to go on more than intuition. From nobody Tue Apr 29 14:39: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 F182F1A0950 for ; Tue, 29 Apr 2014 14:39:02 -0700 (PDT) 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 X2dtxTonABZo for ; Tue, 29 Apr 2014 14:38:58 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4B11A0957 for ; Tue, 29 Apr 2014 14:38:57 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s3TLcrCN075190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 29 Apr 2014 22:38:54 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <53601BED.4050200@foobar.org> Date: Tue, 29 Apr 2014 22:38:53 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ted Lemon References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> <535F3624.4020801@foobar.org> <535F3A8C.2050902@foobar.org> <535F99A9.3030402@foobar.org> <0C03200E-B349-44D4-BE3F-512AD6A7A417@nominum.com> <535FCB2C.3030502@foobar.org> <8DB83B3D-D09C-4977-9B4F-75EA2DD3B71D@nominum.com> In-Reply-To: <8DB83B3D-D09C-4977-9B4F-75EA2DD3B71D@nominum.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/g7LskhSoVeuTN8xTurI7r4cSVXg Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 29 Apr 2014 21:39:03 -0000 On 29/04/2014 17:08, Ted Lemon wrote: > It also doesn't establish it. That was what I was asking for earlier. > I think that if there is a serious gap here, the working group should > consider that. But we haven't actually established that such a gap > exists. My intuition is that you may be right about this, but I'd like > to go on more than intuition. there are three issues here: 1. how much kit out there that doesn't support ra guard / dhcpv6 snooping or basic ipv6 acls on l2 ports, 2. for the kit that does support these features, how good is that support and 3. how important this is to the noipv4 proposal. #1 is highly platform specific and depends on both hardware and software support. e.g. Cisco Nexus 3000 doesn't support ipv6 acls on L2 ports. cisco nexus 1000v doesn't support ipv6 acls at all. Cisco 6500 boxes support ra guard but not dhcpv6 guard. Brocade ironware boxes will support IPv6 ACLs, but can only install them on L2 ports on certain platforms, and even then only if you don't have mac filters installed on those ports. Same mac||ip filter problem on netiron s/w. #2 is complicated enough that Fernando Gont wrote an ID on the topic. Many platforms are subject to the sort of fragmentation / extension header evasion techniques that Fernando describes. The only switch which I've heard to support ra guard for difficult packets is the windows hyperv soft-switch. Hardware forwarded switches seem to be particularly prone to the problem #3: the ietf is fully within remit to write this off as an operational issue and not a protocol problem, and that if your ipv6 first hop security mechanism is broken, then you have bigger problems. While this is undoubtedly true, the draft will create the requirement for all networks - including legacy ones - to protect against rogue RA / DHCPv6 packets because otherwise you could find that newer clients on unprotected legacy networks would be susceptible to having their ipv4 stacks shut down if someone with a sense of humour starts playing around. #3 means that the network operator must be trusted. I don't trust many of the networks that I connect to because sometimes operators and other agents are malicious and I expect my phone / laptop / etc not to be particularly interfered with by their malice. The level of policy interference from this ID is very large indeed. Nick From nobody Tue Apr 29 14:58: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 2159E1A09E0 for ; Tue, 29 Apr 2014 14:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 Dyy0naTPZNsz for ; Tue, 29 Apr 2014 14:58:43 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) by ietfa.amsl.com (Postfix) with ESMTP id 860561A09DF for ; Tue, 29 Apr 2014 14:58:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id C259F4E; Tue, 29 Apr 2014 23:58:41 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yN2TahoBWi3; Tue, 29 Apr 2014 23:58:37 +0200 (CEST) Received: from [IPv6:2a00:8640:1::30ba:3b4c:3cd7:48ca] (unknown [IPv6:2a00:8640:1:0:30ba:3b4c:3cd7:48ca]) by mail.sintact.nl (Postfix) with ESMTPSA id 9CB114C; Tue, 29 Apr 2014 23:58:36 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.0\)) From: Sander Steffann In-Reply-To: <53601BED.4050200@foobar.org> Date: Tue, 29 Apr 2014 23:58:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> <535F3624.4020801@foobar.org> <535F3A8C.2050902@foobar.org> <535F99A9.3030402@foobar.org> <0C03200E-B349-44D4-BE3F-512AD6A7A417@nominum.com> <535FCB2C.3030502@foobar.org> <8DB83B3D-D09C-4977-9B4F-75EA2DD3B71D@nominum.com> <53601BED.4050200@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1878) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/3zsC-9YBOd09BpM6H0YvMFDzmdc Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 29 Apr 2014 21:58:45 -0000 Hi Nick, Op 29 apr. 2014, om 23:38 heeft Nick Hilliard het = volgende geschreven: > On 29/04/2014 17:08, Ted Lemon wrote: >> It also doesn't establish it. That was what I was asking for = earlier. >> I think that if there is a serious gap here, the working group should >> consider that. But we haven't actually established that such a gap >> exists. My intuition is that you may be right about this, but I'd = like >> to go on more than intuition. >=20 > there are three issues here: 1. how much kit out there that doesn't = support > ra guard / dhcpv6 snooping or basic ipv6 acls on l2 ports, 2. for the = kit > that does support these features, how good is that support and 3. how > important this is to the noipv4 proposal. >=20 > #1 is highly platform specific and depends on both hardware and = software > support. e.g. Cisco Nexus 3000 doesn't support ipv6 acls on L2 ports. > cisco nexus 1000v doesn't support ipv6 acls at all. Cisco 6500 boxes > support ra guard but not dhcpv6 guard. Brocade ironware boxes will = support > IPv6 ACLs, but can only install them on L2 ports on certain platforms, = and > even then only if you don't have mac filters installed on those ports. > Same mac||ip filter problem on netiron s/w. >=20 > #2 is complicated enough that Fernando Gont wrote an ID on the topic. = Many > platforms are subject to the sort of fragmentation / extension header > evasion techniques that Fernando describes. The only switch which = I've > heard to support ra guard for difficult packets is the windows hyperv > soft-switch. Hardware forwarded switches seem to be particularly = prone to > the problem >=20 > #3: the ietf is fully within remit to write this off as an operational > issue and not a protocol problem, and that if your ipv6 first hop = security > mechanism is broken, then you have bigger problems. While this is > undoubtedly true, the draft will create the requirement for all = networks - > including legacy ones - to protect against rogue RA / DHCPv6 packets > because otherwise you could find that newer clients on unprotected = legacy > networks would be susceptible to having their ipv4 stacks shut down if > someone with a sense of humour starts playing around. >=20 > #3 means that the network operator must be trusted. I don't trust = many of > the networks that I connect to because sometimes operators and other = agents > are malicious and I expect my phone / laptop / etc not to be = particularly > interfered with by their malice. The level of policy interference = from > this ID is very large indeed. I think you summarised it really well. Thanks! Sander From nobody Tue Apr 29 15:41: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 6AF7E1A094B for ; Tue, 29 Apr 2014 15:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 s_NzLtlpaDOb for ; Tue, 29 Apr 2014 15:41:45 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 837191A0740 for ; Tue, 29 Apr 2014 15:41:45 -0700 (PDT) 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 49AB61B8055 for ; Tue, 29 Apr 2014 15:41:44 -0700 (PDT) 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 2E3B819005C; Tue, 29 Apr 2014 15:41:44 -0700 (PDT) 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; Tue, 29 Apr 2014 15:41:44 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <53601BED.4050200@foobar.org> Date: Tue, 29 Apr 2014 18:41:35 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <37DC9152-EEE3-4EEF-81C7-AD5B6D0E9892@nominum.com> References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> <535F3624.4020801@foobar.org> <535F3A8C.2050902@foobar.org> <535F99A9.3030402@foobar.org> <0C03200E-B349-44D4-BE3F-512AD6A7A417@nominum.com> <535FCB2C.3030502@foobar.org> <8DB83B3D-D09C-4977-9B4F-75EA2DD3B71D@nominum.com> <53601BED.4050200@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_USx-tOEYaOLlQ-37FUGBI8OA8Y Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 29 Apr 2014 22:41:48 -0000 On Apr 29, 2014, at 5:38 PM, Nick Hilliard wrote: > #3 means that the network operator must be trusted. If you are referring to the proposal that a packet from one network be = able to shut off IPv4 on another network, I agree that that is a bad = idea. This has been discussed at length on this thread, and the = authors agree that that point needs to be reconsidered. Fernando's draft actually suggests filtering ethertype 0x86DD in order = to avoid RA attacks on switches that don't have RA guard, which is why I = assumed that that was an option for IPv4-only networks that don't want = to be affected by this proposal. From nobody Tue Apr 29 16: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 CB5D11A09FD for ; Tue, 29 Apr 2014 16:21:09 -0700 (PDT) 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 07lPKCElIRid for ; Tue, 29 Apr 2014 16:21:06 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id E68B31A09FC for ; Tue, 29 Apr 2014 16:21:05 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s3TNL1SC076057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 30 Apr 2014 00:21:02 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <536033DD.8020800@foobar.org> Date: Wed, 30 Apr 2014 00:21:01 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ted Lemon References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> <535F3624.4020801@foobar.org> <535F3A8C.2050902@foobar.org> <535F99A9.3030402@foobar.org> <0C03200E-B349-44D4-BE3F-512AD6A7A417@nominum.com> <535FCB2C.3030502@foobar.org> <8DB83B3D-D09C-4977-9B4F-75EA2DD3B71D@nominum.com> <53601BED.4050200@foobar.org> <37DC9152-EEE3-4EEF-81C7-AD5B6D0E9892@nominum.com> In-Reply-To: <37DC9152-EEE3-4EEF-81C7-AD5B6D0E9892@nominum.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/YEVzdy-HMElA1ThOytf-_wZWeCY Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 29 Apr 2014 23:21:10 -0000 On 29/04/2014 23:41, Ted Lemon wrote: > Fernando's draft actually suggests filtering ethertype 0x86DD in order > to avoid RA attacks on switches that don't have RA guard, which is why I > assumed that that was an option for IPv4-only networks that don't want > to be affected by this proposal. this creates a new requirement to implement mac layer filtering of 0x86dd across all ipv4 networks, on all network media, everywhere - in order to stop casual jokers from trashing people's ipv4 network connectivity, even if the signal is only the interface option (i.e. semantic option 1). The operational cost of this is not feasible. Nick From nobody Tue Apr 29 18:13: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 F00301A099F for ; Tue, 29 Apr 2014 18:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 5k4lfBHFwfYW for ; Tue, 29 Apr 2014 18:13:54 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id B03351A0909 for ; Tue, 29 Apr 2014 18:13:54 -0700 (PDT) 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 7AFC41B8055 for ; Tue, 29 Apr 2014 18:13:53 -0700 (PDT) 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 6329C19005C; Tue, 29 Apr 2014 18:13:53 -0700 (PDT) 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; Tue, 29 Apr 2014 18:13:53 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <536033DD.8020800@foobar.org> Date: Tue, 29 Apr 2014 21:13:50 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <185E714C-A7F3-411B-8CCE-520416EEB858@nominum.com> References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> <535F3624.4020801@foobar.org> <535F3A8C.2050902@foobar.org> <535F99A9.3030402@foobar.org> <0C03200E-B349-44D4-BE3F-512AD6A7A417@nominum.com> <535FCB2C.3030502@foobar.org> <8DB83B3D-D09C-4977-9B4F-75EA2DD3B71D@nominum.com> <53601BED.4050200@foobar.org> <37DC9152-EEE3-4EEF-81C7-AD5B6D0E9892@nominum.com> <536033DD.8020800@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/9HpN8PgTnZEJf8PZAKQ3XhrVjQ8 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 30 Apr 2014 01:13:56 -0000 On Apr 29, 2014, at 7:21 PM, Nick Hilliard wrote: > this creates a new requirement to implement mac layer filtering of = 0x86dd > across all ipv4 networks, on all network media, everywhere - in order = to > stop casual jokers from trashing people's ipv4 network connectivity, = even > if the signal is only the interface option (i.e. semantic option 1). = The > operational cost of this is not feasible. Yes, it's *much* worse than blocking bogus DHCPv4 servers, which can do = exactly the same thing. I hear what you are saying, Nick. There's no need for hyperbole. From nobody Tue Apr 29 21:09: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 AA2511A0A0A for ; Tue, 29 Apr 2014 21:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.651, 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 qRTAYaSnt3NB for ; Tue, 29 Apr 2014 21:09:48 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 25D421A0A07 for ; Tue, 29 Apr 2014 21:09:47 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8B6BDA6; Wed, 30 Apr 2014 06:09:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1398830984; bh=enV/vQCs2Dcv655Lt7uOMg+kdtMajN+lAp/JfpHyNxA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=lbiI+Xvhy0XHzpvlM9qt0lYaWykdJ9hj3Gk8CjIwSrf/sonsj6abZTcV2/bVaHYyg S/o74NAp2p86s/lNlKzOnfp9DEXeVMT76agEzqNi0+Rns8EdJOxZNu3DJY1p5mWr7U h8iRBVUS/P/8O0EOFAZ+BzDaWB+ysIOrxvdcFAzk= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 7F841A5; Wed, 30 Apr 2014 06:09:44 +0200 (CEST) Date: Wed, 30 Apr 2014 06:09:44 +0200 (CEST) From: Mikael Abrahamsson To: Nick Hilliard In-Reply-To: <536033DD.8020800@foobar.org> Message-ID: References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> <535F3624.4020801@foobar.org> <535F3A8C.2050902@foobar.org> <535F99A9.3030402@foobar.org> <0C03200E-B349-44D4-BE3F-512AD6A7A417@nominum.com> <535FCB2C.3030502@foobar.org> <8DB83B3D-D09C-4977-9B4F-75EA2DD3B71D@nominum.com> <53601BED.4050200@foobar.org> <37DC9152-EEE3-4EEF-81C7-AD5B6D0E9892@nominum.com> <536033DD.8020800@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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/9OtRTNv0J0c1ZE5pEADvD6W1hxk Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 30 Apr 2014 04:09:51 -0000 On Wed, 30 Apr 2014, Nick Hilliard wrote: > this creates a new requirement to implement mac layer filtering of > 0x86dd across all ipv4 networks, on all network media, everywhere - in > order to stop casual jokers from trashing people's ipv4 network > connectivity, even if the signal is only the interface option (i.e. > semantic option 1). The operational cost of this is not feasible. Nick, if you're not doing this today you're exposing your customers to MITM attacks and all kinds of other bad things. What this proposal is doing is adding one more reason to implement proper L2 security. You're already screwed, this mechanism just adds one more way you're screwed. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Apr 29 22:36: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 CF48E1A6EDE for ; Tue, 29 Apr 2014 22:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 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.651, 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 BgdcuKo5zznF for ; Tue, 29 Apr 2014 22:36:25 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD201A6EDC for ; Tue, 29 Apr 2014 22:36:25 -0700 (PDT) Received: by mail-ig0-f176.google.com with SMTP id r10so1178536igi.9 for ; Tue, 29 Apr 2014 22:36:24 -0700 (PDT) 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=E4x6AvBGkH54JkOjEFgenf95jcy5IILU9UhGWOwlVZg=; b=mNWd+/0TKAqVPxaRpe0683Sbnzv4ZhEuX7oBLA3LwiHWZHT979ovWZnKMvUe0n+PIw HH/8fV5MNV99S81WV1Z4l+MPKPdbE8+fpFcF//wRyTu0mTSiBlohUQAenk+iZSGPfAPY DZ0qSMWVY22Dfs+SC8I2wrdWr4B9ONqDOETnTsG9lN+WH/tpSJJW/zHLRJsevETTDKyF xMB7mLSIxMKYrgTbKHtCPAYKStdT5t7Nl39PpsBkLcOHvjfi9SaPZxBBifo2tPlMySPA RqtwAMH7gIjJV/EdWwfXMkHBOwYK8MhM/jsALI/jSMk0V/8I0HLeRfS9WKA018VRhCyZ pdKA== 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=E4x6AvBGkH54JkOjEFgenf95jcy5IILU9UhGWOwlVZg=; b=SCDIsx3eQanue6J0uZx4bU2e2NXKcSNAshf8EP46E2GGWKRARmrAlfMZIdmZ1Ms3Rn CUq6makEmreJLRVL4AkdvTIMnh9s4KkeG/oxTmhcx3ar8lkeoF6ov9fks9QT7/29rUkm BWk0U7XrvY9g7WKj1ovoSLk9IqBcywul+47yQToFw3g27qf88c2+Pbq+XNsxmQ25vIt2 Dz8FlbolW1mtJTadT7roaSsxjce6++o86EbM+53lDhYT6bJuMSFTP1s3R7QMGnHEjHov KLt6+G/Z/8Gi9ArDgr5PbR+lePYLnKep9hXkGVVwR9T6xhcUodnpOvf9DHN/Z2nouisY /lEg== X-Gm-Message-State: ALoCoQmpSk6Mb3lQhHa2OPBDd3A4Y314OI0+lqEZQPpReWaj3UXMMHnJ5wVjM+ukKlLwPCo2KH+VjmleOjS2X8CRhkrQsJ6P59k1ST6g3A2qJQO2+v6BLaGgAQBuOErmLp4gKeVVfzxMQPPXCkq2AJHcbPGTe0iqtgY0gYyiS5Y9qB35C8INghz/6CDb9AXBS+ov+Y6jmjbp X-Received: by 10.50.79.227 with SMTP id m3mr2008061igx.47.1398836183890; Tue, 29 Apr 2014 22:36:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.136 with HTTP; Tue, 29 Apr 2014 22:36:03 -0700 (PDT) In-Reply-To: References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> <535F3624.4020801@foobar.org> <535F3A8C.2050902@foobar.org> <535F99A9.3030402@foobar.org> <0C03200E-B349-44D4-BE3F-512AD6A7A417@nominum.com> <535FCB2C.3030502@foobar.org> <8DB83B3D-D09C-4977-9B4F-75EA2DD3B71D@nominum.com> <53601BED.4050200@foobar.org> <37DC9152-EEE3-4EEF-81C7-AD5B6D0E9892@nominum.com> <536033DD.8020800@foobar.org> From: Lorenzo Colitti Date: Wed, 30 Apr 2014 14:36:03 +0900 Message-ID: To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=089e01175f5dd7269504f83bed10 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/6NAWAxbqgc7E-kUABr-uXkbV-DM Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 30 Apr 2014 05:36:27 -0000 --089e01175f5dd7269504f83bed10 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 30, 2014 at 1:09 PM, Mikael Abrahamsson wrote: > Nick, if you're not doing this today you're exposing your customers to > MITM attacks and all kinds of other bad things. What this proposal is doing > is adding one more reason to implement proper L2 security. You're already > screwed, this mechanism just adds one more way you're screwed. > Today, you're not too badly screwed if your first-hop security supports IPv4 and your network only provides IPv4. Yes, it's true that a rogue RA can still blackhole or MITM your traffic, but happy eyeballs will protect you to some degree against blackholing, and SSL will protect you (to some degree :-)) against MITM. If this draft is published and people implement it, you are completely screwed, because all it takes is one packet to shut down all the machines on the network. --089e01175f5dd7269504f83bed10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On W= ed, Apr 30, 2014 at 1:09 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
    Nick, if you're not doin= g this today you're exposing your customers to MITM attacks and all kin= ds of other bad things. What this proposal is doing is adding one more reas= on to implement proper L2 security. You're already screwed, this mechan= ism just adds one more way you're screwed.

    Today, you're not too badly screwed if= your first-hop security supports IPv4 and your network only provides IPv4.=

    Yes, it's true that a rogue RA can still blac= khole or MITM your traffic, but happy eyeballs will protect you to some deg= ree against blackholing, and SSL will protect you (to some degree :-)) agai= nst MITM.

    If this draft is published and people implement it, you= are completely screwed, because all it takes is one packet to shut down al= l the machines on the network.
    --089e01175f5dd7269504f83bed10-- From nobody Wed Apr 30 01:25: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 612C31A0757 for ; Wed, 30 Apr 2014 01:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.047 X-Spam-Level: X-Spam-Status: No, score=0.047 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, 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 PUQkeOfNl4H3 for ; Wed, 30 Apr 2014 01:25:33 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7EACE1A6F14 for ; Wed, 30 Apr 2014 01:25:33 -0700 (PDT) Received: from [192.168.1.39] (rrcs-67-53-121-163.west.biz.rr.com [67.53.121.163]) by dougbarton.us (Postfix) with ESMTPSA id A92B522B1A; Wed, 30 Apr 2014 08:25:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1398846331; bh=jyUdU/z4jcSkvcpQvX6wrYzdrCUI9TfTl8lm04d5yhA=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=Szdu5+EzV/LUI86ZTaPwHjc/eoFhndZVt/hDiFqoig4odT/Xyyd4T6AapcrV4Zlsy MndIwoGvUVAX1yiwocp60/EujKEdeI2kmNZHfrDQAUKmt0mvBnF3XflpVKAWymQgPc v7Gb4rX4gE6I9Sgk+rpMNeyw0FTuNIXuYEoQRyVc= Message-ID: <5360B37B.8010908@dougbarton.us> Date: Wed, 30 Apr 2014 01:25:31 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ted Lemon References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> In-Reply-To: X-Enigmail-Version: 1.7a1pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/0X0jV9tqV4X8h2bDn0kaGB0d72g Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 30 Apr 2014 08:25:41 -0000 On 04/14/2014 12:42 PM, Ted Lemon wrote: > On Apr 14, 2014, at 2:30 PM, Owen DeLong wrote: >> Seems to me that the same potential for abuse exists with either situation. > > This is true, and the remedy exists as well. It's worth pointing out that "please review" doesn't mean "please redesign this." It means "please point out technical flaws that you see." None of what you or Nick has said sound like technical flaws to me—they sound like "I would prefer to do it this other way." Ted, Sometimes ideas that are cooked up in one environment don't stand the light of day when they escape the environment they were created in. I think this is one of those times. First, any draft that suggests adding new options to RA is going to get a negative reaction from me, for reasons I've stated ad nauseum in the past, and I really don't want to open that can of worms on this point. Second, as others have pointed out this is layering violation of monumental proportions, and thinking about this as an implementor (even if the RA stuff was dropped) I would not be keen to try and navigate this. Services which start up listening on IPv4 networks which suddenly have those networks yanked out from under them comes immediately to mind, but I haven't even started thinking hard about the problem(s) yet. Third, this draft doesn't pass a simple laugh test. If you don't want IPv4 on your network, configure it away ... and you're done. There is no need for any of this. Fourth, it doesn't pass the "stop tinkering with the protocol and let the installed base settle on a feature set" test. Finally, and please pardon me for being brutally honest, this whole concept seems childish. When I saw the subject line I was deeply concerned that this was going to turn out to be a "We hate IPv4 so much we want a knob to make it go away" type of thing. As much as the authors may not have intended it that way, that's exactly how it reads. So with all due respect to the authors, and the working group, this is a terrible idea, and the draft should be allowed to expire. Doug From nobody Wed Apr 30 01: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 DF6BC1A6F28 for ; Wed, 30 Apr 2014 01:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TI2jtQlPm1Ln for ; Wed, 30 Apr 2014 01:27:17 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDEA1A6F24 for ; Wed, 30 Apr 2014 01:27:17 -0700 (PDT) Received: from 114-174-17-190.fibertel.com.ar ([190.17.174.114] helo=[192.168.3.106]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WfPrE-00072j-Ry; Wed, 30 Apr 2014 10:27:13 +0200 Message-ID: <5360AA69.1050400@gont.com.ar> Date: Wed, 30 Apr 2014 04:46:49 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Lorenzo Colitti , Mikael Abrahamsson References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> <535F3624.4020801@foobar.org> <535F3A8C.2050902@foobar.org> <535F99A9.3030402@foobar.org> <0C03200E-B349-44D4-BE3F-512AD6A7A417@nominum.com> <535FCB2C.3030502@foobar.org> <8DB83B3D-D09C-4977-9B4F-75EA2DD3B71D@nominum.com> <53601BED.4050200@foobar.org> <37DC9152-EEE3-4EEF-81C7-AD5B6D0E9892@nominum.com> <536033DD.8020800@foobar.org> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_fms5fWnrbbVUPE0IwVsb-0RLc8 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 30 Apr 2014 08:27:25 -0000 On 04/30/2014 02:36 AM, Lorenzo Colitti wrote: > On Wed, Apr 30, 2014 at 1:09 PM, Mikael Abrahamsson > wrote: > > Nick, if you're not doing this today you're exposing your customers > to MITM attacks and all kinds of other bad things. What this > proposal is doing is adding one more reason to implement proper L2 > security. You're already screwed, this mechanism just adds one more > way you're screwed. > > > Today, you're not too badly screwed if your first-hop security supports > IPv4 and your network only provides IPv4. > > Yes, it's true that a rogue RA can still blackhole or MITM your traffic, > but happy eyeballs will protect you to some degree against blackholing, Not necessarily. For instance, you can send an RA with RDNSS, and then spoof DNS responses, and not even advertise a single A record. Or spoof RAs and DHCP-server packets and advertise yourself as the recursive DNS server. Or just be very fast to respond to the IPv6-based SYN, such that IPv6 wins the HappyEyeballs race. Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Wed Apr 30 01:33: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 219751A0774 for ; Wed, 30 Apr 2014 01:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 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.651, 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 uK13yezJSrYr for ; Wed, 30 Apr 2014 01:33:18 -0700 (PDT) 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 24E591A6F1F for ; Wed, 30 Apr 2014 01:33:00 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id to1so1566506ieb.2 for ; Wed, 30 Apr 2014 01:32:58 -0700 (PDT) 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=4SQnDQUnHtodniWPXnZSsH65lqfBmvwix40mc67srNY=; b=gL/vFDYgpWjL93znZSxeL/AgohWCcqN2Aq7xVY+R7evccKRo+nd3jqhLktBZkEb/sf wDfOjJDEih8W4WEt5vd6qsABrCXmePpvCwWGQLGeYa67zElgU9QWQZx0+JgDQG5IMngY iXtjjFPfgCeKcsGeDCyJ/2PhsZmzwbEuZLNLrSqbiU4pe0TSnKfQj8WQr763SG5km01D jKGpp8Wwan5FF8cArRxwx8J9YFnKBChVKg/2RoRR2KUsS9/d/RPiV9zK0KaR6r5AH/xB +ZxjGgX0KRF75GvICcq57BELphaZZZ9gaahqgLjs0SqLXsIpCplbPsZVzNgvdJyMTgek Ar1g== 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=4SQnDQUnHtodniWPXnZSsH65lqfBmvwix40mc67srNY=; b=Kbf5YYj2sKx7EZLmrWcJgo6neiV5usDFtYa155hfJgD2Jk5iVqRi+2mFefSS4KQ7I1 Ndeq3vQ1iIEVONyW4Qd4JHGQIy8dFikG59WK0EL+4URSGadrPGTK37xDyz1H89kL8/0o teXerGPmQlNjpynD/tS0G/SiqKjZAyyhxq2IY4Jnw5HGl9fAqPg30Thfrwj5LZxgu9gt tafW6Py5a5zhXIvoRxfZPtwWCPKuhQ0Ja07S1csC3Z0AvRwGE3TIzHndOx466QTNGI/N 8OV+Hah/21yTL3WEx/+JTH9UtQwJoQ+il/+AgLkh/4In5VtmSKQMqPitRD5eTCNuzuzL XG0Q== X-Gm-Message-State: ALoCoQmpu4epdt0P0KmSF5xCBPY4cyoWYNwTP9HBvuOJs4ofidWdGQJx+7wYwgIbDrvyHgIf2LUjqsaV+ohQyQqsjFkUZmDN3aJ5ixYcQPfxB8WOMZL5VCGIFqmi7xg+VU+/1OfW6/W4wxXydwI0WbtyMZzwQ6qTj7MaXd6D7AcSx+cc4rZ1xy5zbsVYNp5ZUhJBhz3jW65t X-Received: by 10.42.235.197 with SMTP id kh5mr2363630icb.25.1398846778395; Wed, 30 Apr 2014 01:32:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.136 with HTTP; Wed, 30 Apr 2014 01:32:38 -0700 (PDT) In-Reply-To: <5360AA69.1050400@gont.com.ar> References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> <535F3624.4020801@foobar.org> <535F3A8C.2050902@foobar.org> <535F99A9.3030402@foobar.org> <0C03200E-B349-44D4-BE3F-512AD6A7A417@nominum.com> <535FCB2C.3030502@foobar.org> <8DB83B3D-D09C-4977-9B4F-75EA2DD3B71D@nominum.com> <53601BED.4050200@foobar.org> <37DC9152-EEE3-4EEF-81C7-AD5B6D0E9892@nominum.com> <536033DD.8020800@foobar.org> <5360AA69.1050400@gont.com.ar> From: Lorenzo Colitti Date: Wed, 30 Apr 2014 17:32:38 +0900 Message-ID: To: Fernando Gont Content-Type: multipart/alternative; boundary=20cf30266a825270bc04f83e65b2 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2bn__KBUXnm4SZrikiaDQ9b6f80 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 30 Apr 2014 08:33:23 -0000 --20cf30266a825270bc04f83e65b2 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 30, 2014 at 4:46 PM, Fernando Gont wrote: > > Yes, it's true that a rogue RA can still blackhole or MITM your traffic, > > but happy eyeballs will protect you to some degree against blackholing, > > Not necessarily. [...] Hence the words "to some degree". And really it depends on the HE implementation. If it also races DNS queries and treats IPv4 and IPv6 like ships in the night (i.e., tries all provisioning information from IPv4 consistently, and indipendently from all IPv6 provisioning information), and if it over time blacklists source addresses or protocols that don't work (like the Windows 8 implementation), then it won't be affected. --20cf30266a825270bc04f83e65b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On W= ed, Apr 30, 2014 at 4:46 PM, Fernando Gont <fernando@gont.com.ar>= ; wrote:
    > Yes, it's true that= a rogue RA can still blackhole or MITM your traffic,
    > but happy eyeballs will protect you to some degree against blackholing= ,

    Not necessarily.
    [...]

    Henc= e the words "to some degree". And really it depends on the HE imp= lementation. If it also races DNS queries and treats IPv4 and IPv6 like shi= ps in the night (i.e., tries all provisioning information from IPv4 consist= ently, and indipendently from all IPv6 provisioning information), and if it= over time blacklists source addresses or protocols that don't work (li= ke the Windows 8 implementation), then it won't be affected.
    --20cf30266a825270bc04f83e65b2-- From nobody Wed Apr 30 02:35: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 1C59A1A08B7 for ; Wed, 30 Apr 2014 02:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 wr6hS-QDx5Ea for ; Wed, 30 Apr 2014 02:35:28 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) by ietfa.amsl.com (Postfix) with ESMTP id B1D8A1A06DB for ; Wed, 30 Apr 2014 02:35:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id ADB8D4C; Wed, 30 Apr 2014 11:35:25 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-Dgn8RjO4CY; Wed, 30 Apr 2014 11:35:17 +0200 (CEST) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTPSA id F0C5B38; Wed, 30 Apr 2014 11:35:16 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.0\)) From: Sander Steffann In-Reply-To: <37DC9152-EEE3-4EEF-81C7-AD5B6D0E9892@nominum.com> Date: Wed, 30 Apr 2014 11:35:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> <535F3624.4020801@foobar.org> <535F3A8C.2050902@foobar.org> <535F99A9.3030402@foobar.org> <0C03200E-B349-44D4-BE3F-512AD6A7A417@nominum.com> <535FCB2C.3030502@foobar.org> <8DB83B3D-D09C-4977-9B4F-75EA2DD3B71D@nominum.com> <53601BED.4050200@foobar.org> <37DC9152-EEE3-4EEF-81C7-AD5B6D0E9892@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1878) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/hKrDEjnMa6Lxx-Zw_5TJGeniBxo Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 30 Apr 2014 09:35:30 -0000 Hi Ted, > Fernando's draft actually suggests filtering ethertype 0x86DD in order = to avoid RA attacks on switches that don't have RA guard, which is why I = assumed that that was an option for IPv4-only networks that don't want = to be affected by this proposal. Ouch, a solution like that would then increase the cost of deploying = IPv6 later on. I agree it is effective to prevent (rogue) IPv6 stuff, = but it would be a bit too effective for my taste. Cheers :) Sander From nobody Wed Apr 30 03:04: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 9A27D1A6F34 for ; Wed, 30 Apr 2014 03:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.602 X-Spam-Level: X-Spam-Status: No, score=-4.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 NON-0G5Uyew6 for ; Wed, 30 Apr 2014 03:04:27 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4551A0764 for ; Wed, 30 Apr 2014 03:04:26 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E096CA6; Wed, 30 Apr 2014 12:04:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1398852264; bh=bPAVMpUnCbqQObqwEW4J2Mq816DtbZKgren90Ucv0cM=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=FqwHkAJzfXASWQBzkv3EfJIzP42QbXPkr4h7XKdSjhh4prYIOmeLxSnVGi8VrrQZg TzeYNgSqyRaI4ONYpFDBVvE2gQzvDv0H5NRzELVYNnMRjQMK2mR7MJjqHWkN5smuRz UQOi9TM9pEPs8JDW17yJi4XCtRmnsMxMdCqdVi14= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D8FC4A5; Wed, 30 Apr 2014 12:04:24 +0200 (CEST) Date: Wed, 30 Apr 2014 12:04:24 +0200 (CEST) From: Mikael Abrahamsson To: Sander Steffann In-Reply-To: Message-ID: References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> <535F3624.4020801@foobar.org> <535F3A8C.2050902@foobar.org> <535F99A9.3030402@foobar.org> <0C03200E-B349-44D4-BE3F-512AD6A7A417@nominum.com> <535FCB2C.3030502@foobar.org> <8DB83B3D-D09C-4977-9B4F-75EA2DD3B71D@nominum.com> <53601BED.4050200@foobar.org> <37DC9152-EEE3-4EEF-81C7-AD5B6D0E9892@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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KRnT8z1zdD7lyICYWq0K2f4Iv0Q Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 30 Apr 2014 10:04:33 -0000 On Wed, 30 Apr 2014, Sander Steffann wrote: > Ouch, a solution like that would then increase the cost of deploying > IPv6 later on. I agree it is effective to prevent (rogue) IPv6 stuff, > but it would be a bit too effective for my taste. Not really. I'd say if you are providing IPv4 service, then only allow IPv4 and ARP ethertypes. When you then provide IPv6 service, just allow that one as well. Network-wide change that can be done programatically. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Apr 30 03:10: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 0CF641A0764 for ; Wed, 30 Apr 2014 03:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 7qLh0U_4FMyJ for ; Wed, 30 Apr 2014 03:10:11 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) by ietfa.amsl.com (Postfix) with ESMTP id 95B931A06DF for ; Wed, 30 Apr 2014 03:10:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 408D84C; Wed, 30 Apr 2014 12:10:09 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyG9B4zS6ajM; Wed, 30 Apr 2014 12:10:00 +0200 (CEST) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTPSA id 7E8DE38; Wed, 30 Apr 2014 12:10:00 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.0\)) From: Sander Steffann In-Reply-To: Date: Wed, 30 Apr 2014 12:09:59 +0200 Content-Transfer-Encoding: 7bit Message-Id: <9EF2325E-5B2A-4035-B3C0-1C3DA38FD73F@steffann.nl> References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> <535F3624.4020801@foobar.org> <535F3A8C.2050902@foobar.org> <535F99A9.3030402@foobar.org> <0C03200E-B349-44D4-BE3F-512AD6A7A417@nominum.com> <535FCB2C.3030502@foobar.org> <8DB83B3D-D09C-4977-9B4F-75EA2DD3B71D@nominum.com> <53601BED.4050200@foobar.org> <37DC9152-EEE3-4EEF-81C7-AD5B6D0E9892@nominum.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1878) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xWAAYpMTgJ0MQcMy_fBObp_L_KQ Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 30 Apr 2014 10:10:16 -0000 Hi Mikael, > Network-wide change that can be done programatically. I wish every network was as well-organised as the one you're working on ;) Cheers, Sander From nobody Wed Apr 30 04:29: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 459931A0754 for ; Wed, 30 Apr 2014 04:29:34 -0700 (PDT) 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 Xxeoy8HjOtOL for ; Wed, 30 Apr 2014 04:29:32 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 7D41F1A0723 for ; Wed, 30 Apr 2014 04:29:31 -0700 (PDT) X-Envelope-To: Received: from vpn-254.int.inex.ie (vpn-254.int.inex.ie [193.242.111.254]) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s3UBTRQT083687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 30 Apr 2014 12:29:27 +0100 (IST) (envelope-from nick@foobar.org) Message-ID: <5360DE96.3070407@foobar.org> Date: Wed, 30 Apr 2014 12:29:26 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> <535F3624.4020801@foobar.org> <535F3A8C.2050902@foobar.org> <535F99A9.3030402@foobar.org> <0C03200E-B349-44D4-BE3F-512AD6A7A417@nominum.com> <535FCB2C.3030502@foobar.org> <8DB83B3D-D09C-4977-9B4F-75EA2DD3B71D@nominum.com> <53601BED.4050200@foobar.org> <37DC9152-EEE3-4EEF-81C7-AD5B6D0E9892@nominum.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/UXToQ-8583xhLwg2nJz2q6gZdzg Subject: Re: [v6ops] Please review the No IPv4 draft 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, 30 Apr 2014 11:29:34 -0000 On 30/04/2014 11:04, Mikael Abrahamsson wrote: > as well. Network-wide change that can be done programatically. if both the hardware and software support it. As we're talking about legacy stuff here, this may not be the case. Nick From nobody Wed Apr 30 05:37: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 D7FF21A6F53 for ; Wed, 30 Apr 2014 05:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 Xpk73gfLF_NL for ; Wed, 30 Apr 2014 05:37:24 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 26E091A6F52 for ; Wed, 30 Apr 2014 05:37:22 -0700 (PDT) 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 9D4861B8030 for ; Wed, 30 Apr 2014 05:37:20 -0700 (PDT) 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 7694C19005C; Wed, 30 Apr 2014 05:37:20 -0700 (PDT) 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, 30 Apr 2014 05:37:20 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <5360B37B.8010908@dougbarton.us> Date: Wed, 30 Apr 2014 08:37:11 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> <5360B37B.8010908@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/TNkLbGDimuEVySANJCTQIMCiha0 Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 30 Apr 2014 12:37:26 -0000 On Apr 30, 2014, at 4:25 AM, Doug Barton wrote: > as others have pointed out this is layering violation of monumental = proportions Are you trolling me, Doug? From nobody Wed Apr 30 05:39: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 B4B471A6F59 for ; Wed, 30 Apr 2014 05:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 dW5qSy84_UhM for ; Wed, 30 Apr 2014 05:38:49 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id D18BD1A0829 for ; Wed, 30 Apr 2014 05:38:49 -0700 (PDT) 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 AC13A1B8030 for ; Wed, 30 Apr 2014 05:38:48 -0700 (PDT) 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 A150119005C; Wed, 30 Apr 2014 05:38:48 -0700 (PDT) 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, 30 Apr 2014 05:38:48 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: Date: Wed, 30 Apr 2014 08:38:39 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> <535F3624.4020801@foobar.org> <535F3A8C.2050902@foobar.org> <535F99A9.3030402@foobar.org> <0C03200E-B349-44D4-BE3F-512AD6A7A417@nominum.com> <535FCB2C.3030502@foobar.org> <8DB83B3D-D09C-4977-9B4F-75EA2DD3B71D@nominum.com> <53601BED.4050200@foobar.org> <37DC9152-EEE3-4EEF-81C7-AD5B6D0E9892@nominum.com> <536033DD.8020800@foobar.org> <5360AA69.1050400@gont.com.ar> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/AkxdImLvs9IIp4XYumgMsuSTDF4 Cc: "v6ops@ietf.org WG" , Fernando Gont Subject: Re: [v6ops] Please review the No IPv4 draft 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, 30 Apr 2014 12:38:56 -0000 On Apr 30, 2014, at 4:32 AM, Lorenzo Colitti wrote: > Hence the words "to some degree". And really it depends on the HE = implementation. If it also races DNS queries and treats IPv4 and IPv6 = like ships in the night (i.e., tries all provisioning information from = IPv4 consistently, and indipendently from all IPv6 provisioning = information), and if it over time blacklists source addresses or = protocols that don't work (like the Windows 8 implementation), then it = won't be affected. Hm, this is a good argument for treating IPv4 and IPv6 as separate = provisioning domains in MIF. From nobody Wed Apr 30 05:45: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 B21AC1A6F57 for ; Wed, 30 Apr 2014 05:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 bavVtzLo_Ch4 for ; Wed, 30 Apr 2014 05:45:29 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 56F2F1A081B for ; Wed, 30 Apr 2014 05:45:03 -0700 (PDT) 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 322431B8030 for ; Wed, 30 Apr 2014 05:45:02 -0700 (PDT) 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 2B31919005C; Wed, 30 Apr 2014 05:45:02 -0700 (PDT) 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, 30 Apr 2014 05:45:02 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: Date: Wed, 30 Apr 2014 08:44:53 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> <535F3624.4020801@foobar.org> <535F3A8C.2050902@foobar.org> <535F99A9.3030402@foobar.org> <0C03200E-B349-44D4-BE3F-512AD6A7A417@nominum.com> <535FCB2C.3030502@foobar.org> <8DB83B3D-D09C-4977-9B4F-75EA2DD3B71D@nominum.com> <53601BED.4050200@foobar.org> <37DC9152-EEE3-4EEF-81C7-AD5B6D0E9892@nominum.com> To: Sander Steffann X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/oLOaN2bqaIlFRlNPgxuIaC8zSH4 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 30 Apr 2014 12:45:30 -0000 On Apr 30, 2014, at 5:35 AM, Sander Steffann wrote: > Ouch, a solution like that would then increase the cost of deploying = IPv6 later on. I agree it is effective to prevent (rogue) IPv6 stuff, = but it would be a bit too effective for my taste. Yup, I don't think the IETF should be recommending this. That's why I = abstained when the draft came up for IESG review. RA guard is a much = better solution; it's too bad that it (apparently) isn't universally = available. From nobody Wed Apr 30 05:49: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 54A551A6F6A for ; Wed, 30 Apr 2014 05:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.651, 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 sn_rvn3dNKT6 for ; Wed, 30 Apr 2014 05:48:48 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 26EE41A6F63 for ; Wed, 30 Apr 2014 05:48:47 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id EEEBFA6; Wed, 30 Apr 2014 14:48:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1398862125; bh=Evew2P57y8U+mTUPHRCmewxmGBKrKHGsOpkmxRs9/FM=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=kK9pifZ0jQFX+9a4ujRWQu0MGUW2JCo1ltmCwlDd22m98rPwBlWHOT5VAi2u98iDk Vtdd5jERmqEahSHorj2TwaRIEhTh4gDkIyDaoWAPCpGTjtsADPHzJk5/+v6zHUSg7b AeU6UOFo10v2PPSu+RrToMdWYwO0Q7EIsbI1Aljw= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E60B3A5; Wed, 30 Apr 2014 14:48:45 +0200 (CEST) Date: Wed, 30 Apr 2014 14:48:45 +0200 (CEST) From: Mikael Abrahamsson To: Nick Hilliard In-Reply-To: <5360DE96.3070407@foobar.org> Message-ID: References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> <535F3624.4020801@foobar.org> <535F3A8C.2050902@foobar.org> <535F99A9.3030402@foobar.org> <0C03200E-B349-44D4-BE3F-512AD6A7A417@nominum.com> <535FCB2C.3030502@foobar.org> <8DB83B3D-D09C-4977-9B4F-75EA2DD3B71D@nominum.com> <53601BED.4050200@foobar.org> <37DC9152-EEE3-4EEF-81C7-AD5B6D0E9892@nominum.com> <5360DE96.3070407@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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/9Afqca4lCfD6GSci2uUb1HL0E4g Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 30 Apr 2014 12:48:53 -0000 On Wed, 30 Apr 2014, Nick Hilliard wrote: > On 30/04/2014 11:04, Mikael Abrahamsson wrote: >> as well. Network-wide change that can be done programatically. > > if both the hardware and software support it. As we're talking about > legacy stuff here, this may not be the case. I don't understand what part of my statement you object to. The programmatical change statement, the IPv4+ARP ethertypes solely being allowed, or something else? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Apr 30 05:51: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 5C5841A6F75 for ; Wed, 30 Apr 2014 05:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 6ZT7n2tZe7yy for ; Wed, 30 Apr 2014 05:50:55 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF001A6F77 for ; Wed, 30 Apr 2014 05:50:27 -0700 (PDT) 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 2AB7B1B8030 for ; Wed, 30 Apr 2014 05:50:26 -0700 (PDT) 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 1D34319005C; Wed, 30 Apr 2014 05:50:26 -0700 (PDT) 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, 30 Apr 2014 05:50:26 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <5360DE96.3070407@foobar.org> Date: Wed, 30 Apr 2014 08:50:15 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <354BDE7B-40DF-424C-92C1-15FE00A6D0D1@nominum.com> References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> <535F3624.4020801@foobar.org> <535F3A8C.2050902@foobar.org> <535F99A9.3030402@foobar.org> <0C03200E-B349-44D4-BE3F-512AD6A7A417@nominum.com> <535FCB2C.3030502@foobar.org> <8DB83B3D-D09C-4977-9B4F-75EA2DD3B71D@nominum.com> <53601BED.4050200@foobar.org> <37DC9152-EEE3-4EEF-81C7-AD5B6D0E9892@nominum.com> <5360DE96.3070407@foo bar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/TA9y-qem-QsXi4gUCbyrTjje6kU Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 30 Apr 2014 12:51:01 -0000 On Apr 30, 2014, at 7:29 AM, Nick Hilliard wrote: > if both the hardware and software support it. As we're talking about > legacy stuff here, this may not be the case. Clearly you have to stuff the configuration in somehow, unless the = device doesn't support filtering by ethertype, in which case there's = nothing to undo. From nobody Wed Apr 30 08:05: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 0370A1A6FC2 for ; Wed, 30 Apr 2014 08:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 V0kGge1f-lbu for ; Wed, 30 Apr 2014 08:05:25 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5B81A6F88 for ; Wed, 30 Apr 2014 08:05:24 -0700 (PDT) Received: from 114-174-17-190.fibertel.com.ar ([190.17.174.114] helo=[192.168.3.106]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WfW4T-00005U-KR; Wed, 30 Apr 2014 17:05:17 +0200 Message-ID: <536110FD.4020708@gont.com.ar> Date: Wed, 30 Apr 2014 12:04:29 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ted Lemon , Sander Steffann References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> <535F3624.4020801@foobar.org> <535F3A8C.2050902@foobar.org> <535F99A9.3030402@foobar.org> <0C03200E-B349-44D4-BE3F-512AD6A7A417@nominum.com> <535FCB2C.3030502@foobar.org> <8DB83B3D-D09C-4977-9B4F-75EA2DD3B71D@nominum.com> <53601BED.4050200@foobar.org> <37DC9152-EEE3-4EEF-81C7-AD5B6D0E9892@nominum.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qPrH04nCoQ7WP9leRtitPQXhnjo Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 30 Apr 2014 15:05:28 -0000 On 04/30/2014 09:44 AM, Ted Lemon wrote: > On Apr 30, 2014, at 5:35 AM, Sander Steffann > wrote: >> Ouch, a solution like that would then increase the cost of >> deploying IPv6 later on. I agree it is effective to prevent (rogue) >> IPv6 stuff, but it would be a bit too effective for my taste. > > Yup, I don't think the IETF should be recommending this. That's why > I abstained when the draft came up for IESG review. FWIW, the draft doesn't recommend that. It discusses a problem, and evaluates possible mitigations. There are trade-offs among them (including whether you can cope with the implied risk, feasibility, etc.). > RA guard is a > much better solution; it's too bad that it (apparently) isn't > universally available. It's not just "availability", but also about quality of implementation. -- hopefully RFC7113 will help in this latter area. At the time we reported this to a few vendors years ago, they argued that they would improve RA-Guard, because the right fix for these problems was SEND... That's when the folk needing to address these issues starts thinking about employing whatever he has at hand... Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Wed Apr 30 08:13: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 BF2A31A091C for ; Wed, 30 Apr 2014 08:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 2-IF32yU1bgd for ; Wed, 30 Apr 2014 08:13:16 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id D2D641A08F9 for ; Wed, 30 Apr 2014 08:13:15 -0700 (PDT) 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 5A2611B8035 for ; Wed, 30 Apr 2014 08:13:14 -0700 (PDT) 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 142E519005C; Wed, 30 Apr 2014 08:13:14 -0700 (PDT) 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, 30 Apr 2014 08:13:14 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <536110FD.4020708@gont.com.ar> Date: Wed, 30 Apr 2014 11:13:11 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <7E7C61C4-D5C0-42C1-B726-D15AC2938A2F@nominum.com> References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> <535F3624.4020801@foobar.org> <535F3A8C.2050902@foobar.org> <535F99A9.3030402@foobar.org> <0C03200E-B349-44D4-BE3F-512AD6A7A417@nominum.com> <535FCB2C.3030502@foobar.org> <8DB83B3D-D09C-4977-9B4F-75EA2DD3B71D@nominum.com> <53601BED.4050200@foobar.org> <37DC9152-EEE3-4EEF-81C7-AD5B6D0E9892@nominum.com> <536110FD.4020708@gont.co m.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/fFCCpjqccYUqYyAbUGIPmVZufpA Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Please review the No IPv4 draft 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, 30 Apr 2014 15:13:17 -0000 On Apr 30, 2014, at 11:04 AM, Fernando Gont = wrote: > That's when the folk needing to address these issues starts thinking > about employing whatever he has at hand... To be clear, I'm not saying that what you said in the document is wrong, = or that people shouldn't do it. My argument with it is that the IETF = shouldn't be the one saying it. But I am in the rough on that. Life = goes on... :) From nobody Wed Apr 30 10:53: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 E0A1D1A0942 for ; Wed, 30 Apr 2014 10:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 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.651, 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 e1fuayaMe5Jp for ; Wed, 30 Apr 2014 10:53:01 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 05E551A6FFE for ; Wed, 30 Apr 2014 10:53:01 -0700 (PDT) Received: from [192.168.1.39] (rrcs-67-53-121-163.west.biz.rr.com [67.53.121.163]) by dougbarton.us (Postfix) with ESMTPSA id 2033922B20; Wed, 30 Apr 2014 17:52:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1398880379; bh=cESj7yl1r4uthdqAfON2DGDDPSNn6BBJgL60RHEPkdY=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=fwwty87VwsuDTyd1VJZ8vA1nJJDHKQANmOrKj0FN7bTUbtF2Ezvi5gup7xkW44xGd 9eCctrrZNheZqUNu47LlbgsOcwu68FrTp56LA1RwrUAbn3/qAYqJQSegeCnFsAwr0w P2/9TEYBV2FzGeYWLmU43QcUcLVP+a0fSyNmy5yk= Message-ID: <5361387A.5070805@dougbarton.us> Date: Wed, 30 Apr 2014 10:52:58 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ted Lemon References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> <5360B37B.8010908@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.7a1pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/0MN1v2wM3IoooEU5Ofw9olskFDE Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 30 Apr 2014 17:53:03 -0000 On 04/30/2014 05:37 AM, Ted Lemon wrote: > On Apr 30, 2014, at 4:25 AM, Doug Barton wrote: >> as others have pointed out this is layering violation of monumental proportions > > Are you trolling me, Doug? I'm not sure why you would say that, or why you would snip one phrase out of my entire e-mail to respond to and ignore all of the other arguments I made about why this draft is a bad idea. Doug From nobody Wed Apr 30 11:03: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 494011A0852 for ; Wed, 30 Apr 2014 11:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 kL-4x-MIA_0U for ; Wed, 30 Apr 2014 11:03:23 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 17EC71A04B6 for ; Wed, 30 Apr 2014 11:03:23 -0700 (PDT) Received: from mb-aye.local ([173.247.205.34]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s3UI3K6Z005634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 30 Apr 2014 18:03:21 GMT (envelope-from joelja@bogus.com) Message-ID: <53613AE8.3050405@bogus.com> Date: Wed, 30 Apr 2014 11:03:20 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Thunderbird/29.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> <5360B37B.8010908@dougbarton.us> <5361387A.5070805@dougbarton.us> In-Reply-To: <5361387A.5070805@dougbarton.us> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PaUuQNkOB4UnXLJ0q8vxRfpbkOcR1JxR1" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Wed, 30 Apr 2014 18:03:21 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/848wxRRJloMbOTyD_6bT6EAhdiA Subject: [v6ops] Hey guys, was Re: Please review the No IPv4 draft 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, 30 Apr 2014 18:03:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PaUuQNkOB4UnXLJ0q8vxRfpbkOcR1JxR1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think this discussion has served it's purpose with respect to review of the no ipv4 draft. We can go away an work on this. Thanks joel On 4/30/14, 10:52 AM, Doug Barton wrote: > On 04/30/2014 05:37 AM, Ted Lemon wrote: >> On Apr 30, 2014, at 4:25 AM, Doug Barton wrote: >>> as others have pointed out this is layering violation of monumental >>> proportions >> >> Are you trolling me, Doug? >=20 > I'm not sure why you would say that, or why you would snip one phrase > out of my entire e-mail to respond to and ignore all of the other > arguments I made about why this draft is a bad idea. >=20 > Doug >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --PaUuQNkOB4UnXLJ0q8vxRfpbkOcR1JxR1 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/ iEYEARECAAYFAlNhOugACgkQ8AA1q7Z/VrKJBwCfeVlqUpJYdEbVU2DzeiW/QRaq KVMAn1GXW6l37CInXJQ4JAgdvlag3e30 =kG5x -----END PGP SIGNATURE----- --PaUuQNkOB4UnXLJ0q8vxRfpbkOcR1JxR1-- From nobody Wed Apr 30 11: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 B5B2C1A0776 for ; Wed, 30 Apr 2014 11:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 Mjyg3RPbpT66 for ; Wed, 30 Apr 2014 11:32:01 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9061A04E8 for ; Wed, 30 Apr 2014 11:32:01 -0700 (PDT) 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 BCD0B1B803C for ; Wed, 30 Apr 2014 11:31:59 -0700 (PDT) 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 A8CA319005C; Wed, 30 Apr 2014 11:31:59 -0700 (PDT) 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, 30 Apr 2014 11:31:59 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <5361387A.5070805@dougbarton.us> Date: Wed, 30 Apr 2014 14:31:55 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> <5360B37B.8010908@dougbarton.us> <5361387A.5070805@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/JDHMo7wkVfGepodD4ffn19AAar8 Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 30 Apr 2014 18:32:02 -0000 On Apr 30, 2014, at 1:52 PM, Doug Barton wrote: > I'm not sure why you would say that, or why you would snip one phrase = out of my entire e-mail to respond to and ignore all of the other = arguments I made about why this draft is a bad idea. The less said on this long, repetitive thread, the better. The = particular point I quoted was refuted early on and is utterly absurd. = Your other points have been addressed. Please, can we stop talking = about this and wait for the next version to be published? From nobody Wed Apr 30 12:01: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 6E61B1A8885 for ; Wed, 30 Apr 2014 12:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 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.651, 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 LnDzsJWIG8iU for ; Wed, 30 Apr 2014 12:01:44 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id EAD251A88A2 for ; Wed, 30 Apr 2014 12:01:26 -0700 (PDT) Received: from [192.168.1.39] (rrcs-67-53-121-163.west.biz.rr.com [67.53.121.163]) by dougbarton.us (Postfix) with ESMTPSA id 48C6522B20; Wed, 30 Apr 2014 19:01:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1398884485; bh=a99+ZbtgYDmtgUVqt6T83RTqTQ3qCgul2ddSLklYPxg=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=JzRlQdcgBbMYl5hP5fhG73rucvNyfDuQIeVdC9F3Ye9L+bg6Z9OT5DUnd8YnDCP5a sRyoPnB5kwN7ahIWv16zrBQzVG83/Qfu3qJDBfCR+23uKNmnUnGSMeUSeQulIY5uBL XMvC3TJpWfjVJakzYkcVEvmKmuean4XV3Iyeppbs= Message-ID: <53614884.1010000@dougbarton.us> Date: Wed, 30 Apr 2014 12:01:24 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ted Lemon References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> <5360B37B.8010908@dougbarton.us> <5361387A.5070805@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.7a1pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5RxkLB1OlqhH5_uPX0sYSPJmvMc Cc: v6ops@ietf.org Subject: Re: [v6ops] Please review the No IPv4 draft 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, 30 Apr 2014 19:01:45 -0000 On 04/30/2014 11:31 AM, Ted Lemon wrote: > On Apr 30, 2014, at 1:52 PM, Doug Barton > wrote: >> I'm not sure why you would say that, or why you would snip one >> phrase out of my entire e-mail to respond to and ignore all of the >> other arguments I made about why this draft is a bad idea. > > The less said on this long, repetitive thread, the better. The > particular point I quoted was refuted early on and is utterly absurd. I know that is your position. I, and others, disagree. > Your other points have been addressed. Please, can we stop talking > about this and wait for the next version to be published? Apparently my points have not been addressed adequately if another version of the draft is being considered. (And no, that's not a troll either.) Doug From nobody Wed Apr 30 15:49: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 5921F1A09D8 for ; Wed, 30 Apr 2014 15:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 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.651, 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 Zt489cCsoC0h for ; Wed, 30 Apr 2014 15:48:58 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id ED0461A0955 for ; Wed, 30 Apr 2014 15:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3974; q=dns/txt; s=iport; t=1398898136; x=1400107736; h=from:to:cc:subject:date:message-id:mime-version; bh=CW/RZV16ynXeHFr+JHLGqCYtnxdtHrsl1hbUpxqLdyc=; b=aQrqlymWLz67wrVPkZNQ97X20IJWw8Z3CQK33wInla9SzjBJSRVNCoEb jCSTkX4Rzp08zEG4aC1T3tCohSqAuxoqgeeGBYLRidob/rjQqI53pgeiH MvzogZimIl0ZYpVLLc5XdnWQTR/7UJOsU9QlRqYPLI+d35LYZGfYAln36 Q=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAPV8YVOtJV2c/2dsb2JhbABZgwaBJsE9gw+BIRZ0giUBAQEDAXkFDQEaZhcQBA4TDYgeCMoLF45RgyuBFQSRGYE4hlaSa4Mxgis X-IronPort-AV: E=Sophos;i="4.97,960,1389744000"; d="asc'?scan'208";a="321662055" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 30 Apr 2014 22:48:56 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3UMmtvn031024 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Apr 2014 22:48:56 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.100]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Wed, 30 Apr 2014 17:48:55 -0500 From: "Fred Baker (fred)" To: "Byrne, Cameron" Thread-Topic: Thoughts on draft-byrne-v6ops-clatip-01 Thread-Index: AQHPZMZdvEf566nkWEek5MjWBQOzAA== Date: Wed, 30 Apr 2014 22:48:54 +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.118] Content-Type: multipart/signed; boundary="Apple-Mail=_371F332A-35AA-4777-91A7-FE1C490A7F71"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/NF9mIV3N1-EnhMpHIk9KfrltlQE Cc: V6 Ops List Subject: [v6ops] Thoughts on 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: Wed, 30 Apr 2014 22:49:01 -0000 --Apple-Mail=_371F332A-35AA-4777-91A7-FE1C490A7F71 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > DS-Lite [RFC6333] directs IANA to reserve 192.0.0.0/29 for the B4 > element. This memo generalizes that reservation to include other > cases where a non-routed IPv4 interface must be numbered in an IPv6 > transition solution. idnits whines about =93[RFC6333]=94, preferring =93RFC 6333=94. > 1 Introduction >=20 > DS-Lite [RFC6333] directs IANA to reserve 192.0.0.0/29 for the B4 > element. This memo generalizes that IANA reservation to include > other cases where a non-routed IPv4 interface must be numbered in = an > IPv6 transition solutions. IANA shall list 192.0.0.0/29 to be > reserved for IPv6 Transitional Technology IPv4 Prefix. The result = is ^reserved as an^? > that 192.0.0.0/29 may be used in any system that requires IPv4 > addresses for backward compatibility with IPv4 communications, but > does not emit IPv4 packets "on the wire". >=20 > 2 The Case of 464XLAT >=20 > 464XLAT [RFC6877] describes an architecture for providing IPv4 > communication over an IPv6-only access network. One of the methods > described in [RFC6877] is for the client side translator (CLAT) to = be > embedded in the host, such as a smartphone. In this scenario, the > host must have an IPv4 address configured to present to the network > stack and for applications to bind sockets. >=20 > 3. Choosing 192.0.0.0/29 >=20 > To avoid conflicts with any other network that may communicate with > the CLAT, a locally unique address must be assigned. Dumb question. Is there a reason to not use 169.254.0.0/16? I don=92t = suppose you have a MAC address, but if you can pick a number in 0..31, I = should think you could pick a number in 0..65535, and you might even = have a source for it. > IANA has defined a well-known range, 192.0.0.0/29, in [RFC6333], > which is dedicated for DS-lite. As defined in [RFC6333], this = subnet > is only present between the B4 and the AFTR and never emits packets > from this prefix "on the wire". 464XLAT has the same need for a = non- > routed IPv4 prefix. It is most prudent and effective to generalize > 192.0.0.0/29 for the use of supporting IPv4 interfaces in IPv6 > transition technologies rather than reserving a prefix for every > possible solution. >=20 > 4 Security Considerations >=20 > No new security considerations beyond what is described [RFC6333] = and > [RFC6877]. >=20 >=20 > 5 IANA Considerations >=20 > IANA is directed to generalize the reservation of 192.0.0.0/29 from > DS-lite to "IPv6 Transitional Technology IPv4 Prefix". >=20 >=20 > 6 References >=20 > =20 >=20 >=20 > Byrne Expires July 1, 2014 [Page = 3] > INTERNET DRAFT Transitional IPv4 Prefix December 28, = 2013 >=20 >=20 > 6.1 Normative References >=20 > [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- > Stack Lite Broadband Deployments Following IPv4 > Exhaustion", RFC6333, August 2011. >=20 > [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: > Combination of Stateful and Stateless Translation", > RFC6877, April 2013. --Apple-Mail=_371F332A-35AA-4777-91A7-FE1C490A7F71 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 iD8DBQFTYX3WbjEdbHIsm0MRAtKeAJ4vmtU1incPhfcWj0j4GyFev9hgqwCcD+h4 vjfOeK3WBj8/p06rHEcVDzg= =r7eM -----END PGP SIGNATURE----- --Apple-Mail=_371F332A-35AA-4777-91A7-FE1C490A7F71-- From nobody Wed Apr 30 16:03:18 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 176DF1A0955 for ; Wed, 30 Apr 2014 16:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 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, NORMAL_HTTP_TO_IP=0.001, RP_MATCHES_RCVD=-0.651, 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 3AQWuVHXR-09 for ; Wed, 30 Apr 2014 16:03:14 -0700 (PDT) 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 57CB61A04E8 for ; Wed, 30 Apr 2014 16:03:14 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id rl12so2771580iec.20 for ; Wed, 30 Apr 2014 16:03:12 -0700 (PDT) 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=s8A9VqJd5SM6IDvfwcLcVW2uafquKnFklU5HEP0SH28=; b=edSiXVjFTrSmZtNNnuzyAavA2+c4H9ltrtNNk4jwxlG1QoG8CgM1drR8Iki7HJ7SGV LJcv6RzTrno52IyBpy2EbMfvGdFith9ha7POOPM7R7LOAVvsDBHMmychrjWgg/DgqyAY J3UONL11Io01WQ9O+6bfOwarmSiMSZEXAacX+DZsW8SPLZ7VfHctMLt14N6SUGlFTpbI 1fNWsxQ6MoHCndCEn1rmLUhDD2UreANGpAUXfPk+rb9IO84bD9J/qhDizIj6qcLxoyAP TANEEoj2TqYlwbaWlGCqzvVDWzF4wcCz8ReouSnOikxlGlcLKSzFaYCISwAQvnB9o1X6 M/7A== 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=s8A9VqJd5SM6IDvfwcLcVW2uafquKnFklU5HEP0SH28=; b=nKFGInOofLMZ8iTsrHAWiAVWt6foQ6YzCk8tdz+xcT4HXsYoGiVQXKT4ozxdTQ4ZZ4 K/Ycj1wSGUGo5MXjDWxXeID/pmKwPL7ztw6J6FF3kpK1FLLBiLel+FJeyhKwbz92d1FL bnq4g+owCwsXKsfWn1AMHR8Rh13AaLsfwGMvRn9Ft4HBJ/XeSvTbh3Kx5blBr8iGfCbf f5Jf6t065ol22DVrISn4oopCegWrI+V+0J7H22q7gyWIgvHzqNli3S7He5g6DQF7i1iC hmhfRpOhAPTWKRYoSBsODoYpC2zMyhRfuiblMQ1m8xJYVFYJCOMueJjqRE5J/WEtzg9z LNEA== X-Gm-Message-State: ALoCoQmhouFJ77EzcXpm7qAzJJI8OeCTsL86MIwh395IrJZsIiozUhqSw+XalvXxT5OF/1rb2C0N X-Received: by 10.50.147.9 with SMTP id tg9mr42055192igb.31.1398898637453; Wed, 30 Apr 2014 15:57:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.136 with HTTP; Wed, 30 Apr 2014 15:56:57 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Thu, 1 May 2014 07:56:57 +0900 Message-ID: To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=089e013a03ac5ce25304f84a7804 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/iwNapD9v4GiakXlUNnhTZvudi-g Cc: V6 Ops List , "Byrne, Cameron" Subject: Re: [v6ops] Thoughts on 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: Wed, 30 Apr 2014 23:03:16 -0000 --089e013a03ac5ce25304f84a7804 Content-Type: text/plain; charset=UTF-8 On Thu, May 1, 2014 at 7:48 AM, Fred Baker (fred) wrote: > > To avoid conflicts with any other network that may communicate with > > the CLAT, a locally unique address must be assigned. > > Dumb question. Is there a reason to not use 169.254.0.0/16? > Yes. 169.254.0.0/16 is link-local, which implies no off-link connectivity and no Internet connectivity. If your only IPv4 address is in that range, applications might well assume that there is no off-link connectivity. --089e013a03ac5ce25304f84a7804 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On T= hu, May 1, 2014 at 7:48 AM, Fred Baker (fred) <fred@cisco.com> = wrote:
    > =C2=A0 =C2=A0To avoid conflicts with an= y other network that may communicate with
    > =C2=A0 =C2=A0the CLAT, a locally unique address must be assigned.

    Dumb question. Is there a reason to not use 169.254.0.0/16?

    Yes. 169.254.0.0/16 is link-local, = which implies no off-link connectivity and no Internet connectivity. If you= r only IPv4 address is in that range, applications might well assume that t= here is no off-link connectivity.
    --089e013a03ac5ce25304f84a7804-- From nobody Wed Apr 30 16:24: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 B35FE1A6F30 for ; Wed, 30 Apr 2014 16:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.152 X-Spam-Level: X-Spam-Status: No, score=-110.152 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.651, 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 aL9hWAd_3Ge8 for ; Wed, 30 Apr 2014 16:24:44 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id E53401A6F2B for ; Wed, 30 Apr 2014 16:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2385; q=dns/txt; s=iport; t=1398900279; x=1400109879; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=hhcebVcQRRrDxFYQF1/evtOMVf0zGn3O5Et+LNye7Yw=; b=jnqi6w/QR2BrX3GzTADdw70eFDe+j1N4jrWOwGtBKpZUdsSp1LDKfqqu 3dpzq066PIj0NsTcqk1fKzTWDJVoPQE538TMKA8lt9GPf9dtJkWy7IY6t mX/jjtOWMAVgKReY/pfRM2K9OnJBGxW5mizcwdM/8f3zCtL0UZTMGRdru 0=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAFAPWEYVOtJV2c/2dsb2JhbABZgwaBJsRMgSAWdIIlAQEBAwF5BQsCAQgYLjIlAgQOBQ6IKwjKCxeOUQeDJIEVBIRYA4w+gTiGVpJrgzGCKw X-IronPort-AV: E=Sophos;i="4.97,961,1389744000"; d="asc'?scan'208";a="40130217" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP; 30 Apr 2014 23:24:38 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3UNOcKW026266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Apr 2014 23:24:39 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.100]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Wed, 30 Apr 2014 18:24:38 -0500 From: "Fred Baker (fred)" To: Lorenzo Colitti Thread-Topic: [v6ops] Thoughts on draft-byrne-v6ops-clatip-01 Thread-Index: AQHPZMtaVdgdN36+3ES57hlLMFfb2w== Date: Wed, 30 Apr 2014 23:24:38 +0000 Message-ID: <40C41DA9-3513-4BC3-B6C9-7A1EEF98BBC7@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.118] Content-Type: multipart/signed; boundary="Apple-Mail=_C4DB38E9-3977-466B-8601-CAABC7B68AC1"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jkiw4yJmLQOjA1V_infI6o9405M Cc: V6 Ops List , "Byrne, Cameron" Subject: Re: [v6ops] Thoughts on 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: Wed, 30 Apr 2014 23:24:46 -0000 --Apple-Mail=_C4DB38E9-3977-466B-8601-CAABC7B68AC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 30, 2014, at 3:56 PM, Lorenzo Colitti wrote: > On Thu, May 1, 2014 at 7:48 AM, Fred Baker (fred) = wrote: > > To avoid conflicts with any other network that may communicate = with > > the CLAT, a locally unique address must be assigned. >=20 > Dumb question. Is there a reason to not use 169.254.0.0/16? >=20 > Yes. 169.254.0.0/16 is link-local, which implies no off-link = connectivity and no Internet connectivity. If your only IPv4 address is = in that range, applications might well assume that there is no off-link = connectivity. Ask me someday what thoughts go through my mind about applications = making inferences from network layer addresses. Hey, 192.168.0.0/16 is = for networks that don=92t connect to the Internet. You want proof? =46rom = RFC 1918, the motivation is With the proliferation of TCP/IP technology worldwide, including outside the Internet itself, an increasing number of non-connected enterprises use this technology and its addressing capabilities for sole intra-enterprise communications, without any intention to ever directly connect to other enterprises or the Internet itself. And, in the past two weeks, I have received 471 emails (this particular = one on perpass@ietf.org) that contain lines like Received: from ([169.254.2.21]) by ([169.254.2.21]) with mapi id 15.00.0929.001; Wed, 30 Apr 2014 19:08:41 +0000 But anyway... and 192.0.0.0/29 is...? I=92m not sure I=92m up to rocking boats here. It just seems like they = have equivalent characteristics. Before we ship the document somewhere, = it seems like a reasonable question. --Apple-Mail=_C4DB38E9-3977-466B-8601-CAABC7B68AC1 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 iD8DBQFTYYY1bjEdbHIsm0MRAsptAKCElLGk5pxNqudg9EWlruRlcr9A6QCfUTCx M3wX4bV4F7+t3ASRzuRP1ns= =SC50 -----END PGP SIGNATURE----- --Apple-Mail=_C4DB38E9-3977-466B-8601-CAABC7B68AC1-- From nobody Wed Apr 30 17:02: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 524501A0A02 for ; Wed, 30 Apr 2014 17:02:19 -0700 (PDT) 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_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, NORMAL_HTTP_TO_IP=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 bJ22Xp-W61bA for ; Wed, 30 Apr 2014 17:02:15 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 453081A6FC2 for ; Wed, 30 Apr 2014 17:02:15 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hm4so1858673wib.5 for ; Wed, 30 Apr 2014 17:02:13 -0700 (PDT) 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=g0QOwOI8FSF4JIiekLkqvbOvKb+I1zRGuoSNdsO56L8=; b=jTCVDZiyfyJask7l5KX2+gD3kblZ0GlSRH4E9SauubsKg4kVF/4AnqO/CQt4r9LH+W 3CbasMwk1S1cTjlsNhRytOeblgFdjIw+CrlwTNi4CStulLcZ6uQtaSVGG0YD7GH9VHzs XbBDne4GrEW6LUFIE0iZ+wuo+jxBsNf+SfgN/csTaWoZjxBUWTyjw5SpBNpSigWIXhIt nNw8hkmsJp9xkJJhY5zV3KjGLvdwe7wMO/QM5wpfXyPJkv8OS/Q9EQUrHHVv4vcI6qgx V6Spx8JIv5xuwqUFV5FYxs+hru8SHwkcj6+WH5geEC7g/I+rmdjU/iDYFXK9fnC3zRh+ JkoA== MIME-Version: 1.0 X-Received: by 10.180.80.3 with SMTP id n3mr5814540wix.36.1398902533161; Wed, 30 Apr 2014 17:02:13 -0700 (PDT) Received: by 10.216.189.7 with HTTP; Wed, 30 Apr 2014 17:02:12 -0700 (PDT) Received: by 10.216.189.7 with HTTP; Wed, 30 Apr 2014 17:02:12 -0700 (PDT) In-Reply-To: <40C41DA9-3513-4BC3-B6C9-7A1EEF98BBC7@cisco.com> References: <40C41DA9-3513-4BC3-B6C9-7A1EEF98BBC7@cisco.com> Date: Wed, 30 Apr 2014 17:02:12 -0700 Message-ID: From: "TheIpv6guy ." To: Fred Baker Content-Type: multipart/alternative; boundary=f46d0418253890ba0504f84b60ed Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/JkkVCwyL6gdCZyqDYIZvWinKO90 Cc: V6 Ops List , "Byrne, Cameron" Subject: Re: [v6ops] Thoughts on 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: Thu, 01 May 2014 00:02:19 -0000 --f46d0418253890ba0504f84b60ed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Apr 30, 2014 4:24 PM, "Fred Baker (fred)" wrote: > > > On Apr 30, 2014, at 3:56 PM, Lorenzo Colitti wrote: > > > On Thu, May 1, 2014 at 7:48 AM, Fred Baker (fred) wrote: > > > To avoid conflicts with any other network that may communicate wit= h > > > the CLAT, a locally unique address must be assigned. > > > > Dumb question. Is there a reason to not use 169.254.0.0/16? > > > > Yes. 169.254.0.0/16 is link-local, which implies no off-link connectivity and no Internet connectivity. If your only IPv4 address is in that range, applications might well assume that there is no off-link connectivity. > > Ask me someday what thoughts go through my mind about applications making inferences from network layer addresses. Hey, 192.168.0.0/16 is for networks that don=E2=80=99t connect to the Internet. You want proof? From R= FC 1918, the motivation is > > With the proliferation of TCP/IP technology worldwide, including > outside the Internet itself, an increasing number of non-connected > enterprises use this technology and its addressing capabilities for > sole intra-enterprise communications, without any intention to ever > directly connect to other enterprises or the Internet itself. > > And, in the past two weeks, I have received 471 emails (this particular one on perpass@ietf.org) that contain lines like > > Received: from ([169.254.2.21]) by > ([169.254.2.21]) with mapi id > 15.00.0929.001; Wed, 30 Apr 2014 19:08:41 +0000 > > But anyway... > > and 192.0.0.0/29 is...? > > I=E2=80=99m not sure I=E2=80=99m up to rocking boats here. It just seems = like they have equivalent characteristics. Before we ship the document somewhere, it seems like a reasonable question. > It is a reasonable question. https://tools.ietf.org/html/rfc3927#section-2.6 There is defined the limitations of the ipv4 link local addresses. This includes that the addresses may not be forwarded and all offlink communication requires an ARP. In practice, neither of these MUSTs can be implemented since the CLAT generally must "forward" this packet to an rfc6145 function using a "default route" , within a host. Also, as Lorenzo noted, applications may gleen "no connectivity" from the 169.254 address 192.0.0.0/29 is a globally routable address it works well here, this is know in production (7 million nodes deployed as such in my network). I believe it is more natural to generalize the use of 192.0.0.0/29 as defined in rfc6333 rather than cause a conflict / violation to rfc3927. At the end of the day, this draft is simply stating that the b4 ipv4 function defined in rfc6333 has utility beyond ds-lite, and therefore the usage of the address should be generalized. CB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --f46d0418253890ba0504f84b60ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


    On Apr 30, 2014 4:24 PM, "Fred Baker (fred)" <fred@cisco.com> wrote:
    >
    >
    > On Apr 30, 2014, at 3:56 PM, Lorenzo Colitti <lorenzo@google.com> wrote:
    >
    > > On Thu, May 1, 2014 at 7:48 AM, Fred Baker (fred) <fred@cisco.com> wrote:
    > > > =C2=A0 =C2=A0To avoid conflicts with any other network that = may communicate with
    > > > =C2=A0 =C2=A0the CLAT, a locally unique address must be assi= gned.
    > >
    > > Dumb question. Is there a reason to not use 169.254.0.0/16?
    > >
    > > Yes. 169.254.0.0/16 is link= -local, which implies no off-link connectivity and no Internet connectivity= . If your only IPv4 address is in that range, applications might well assum= e that there is no off-link connectivity.
    >
    > Ask me someday what thoughts go through my mind about applications mak= ing inferences from network layer addresses. Hey, 192.168.0.0/16 is for networks that don=E2=80=99t connect to t= he Internet. You want proof? From RFC 1918, the motivation is
    >
    > =C2=A0 =C2=A0With the proliferation of TCP/IP technology worldwide, in= cluding
    > =C2=A0 =C2=A0outside the Internet itself, an increasing number of non-= connected
    > =C2=A0 =C2=A0enterprises use this technology and its addressing capabi= lities for
    > =C2=A0 =C2=A0sole intra-enterprise communications, without any intenti= on to ever
    > =C2=A0 =C2=A0directly connect to other enterprises or the Internet its= elf.
    >
    > And, in the past two weeks, I have received 471 emails (this particula= r one on perpass@ietf.org) that con= tain lines like
    >
    > Received: from <name> ([169.254.2.21]) by
    > =C2=A0<name> =C2=A0([169.254.2.21]) with mapi id
    > =C2=A015.00.0929.001; Wed, 30 Apr 2014 19:08:41 +0000
    >
    > But anyway...
    >
    > and 192.0.0.0/29 is...?
    >
    > I=E2=80=99m not sure I=E2=80=99m up to rocking boats here. It just see= ms like they have equivalent characteristics. Before we ship the document s= omewhere, it seems like a reasonable question.
    >

    It is a reasonable question.

    = https://tools.ietf.org/html/rfc3927#section-2.6

    There is defined the limitations of the ipv4 link local addr= esses. This includes that the addresses may not be forwarded and all offlin= k communication requires an ARP.

    In practice, neither of these MUSTs can be implemented since= the CLAT generally must "forward" this packet to an rfc6145 func= tion using a "default route" , within a host.=C2=A0 Also, as Lore= nzo noted, applications may gleen "no connectivity" from the 169.= 254 address

    192.0.0.0/29 is a global= ly routable address it works well here, this is know in production (7 milli= on nodes deployed as such in my network).

    I believe it is more natural to generalize the use of 192.0.0.0/29 as defined in rfc6333 rather tha= n cause a conflict / violation=C2=A0 to rfc3927.

    At the end of the day, this draft is simply stating that the= b4 ipv4 function defined in rfc6333 has utility beyond ds-lite, and theref= ore the usage of the address should be generalized.

    CB

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

    --f46d0418253890ba0504f84b60ed-- From nobody Wed Apr 30 19:55: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 372221A093E for ; Wed, 30 Apr 2014 19:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 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, NORMAL_HTTP_TO_IP=0.001, RP_MATCHES_RCVD=-0.651, 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 7t8i8yV5TCLm for ; Wed, 30 Apr 2014 19:55:28 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A5BF21A092F for ; Wed, 30 Apr 2014 19:55:28 -0700 (PDT) Received: by mail-ig0-f174.google.com with SMTP id h18so21524igc.7 for ; Wed, 30 Apr 2014 19:55:26 -0700 (PDT) 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=N2oFRZiNA9iV9T9Yv3ftJ22opZ03G2kaXGN6DQ7GU14=; b=NsCoHaA4+TldQ/RBuNLLC/D4RClHBNWh3VXvxvPOd+20Te2TnzjD4W+MpLcWN6mNSC ZhOTvXvCJpLSXnsrIAjbdVqtZjnGLpkBcthtkrvLORPg+Vsob8djF68FOkVherAtIgme 1NS+b2YBixLiRU9XiqUqAxmcVsy52Zv6wRTf6tiMQfvV8c38aoNAsNU/N/quWSrM1enI Une/yFpHbHgOfY3dVIpHdj0P+2EHf4kfwlBSciuMLIvaXxXU3JjqaoAQmMUz1xvoTwWD fAnwGthiqmzIy6tBze4uQw53LsNerb7HjXhXmRRhf2qSCZpYehwcZf1lRROEXpi8ReZT KFDQ== 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=N2oFRZiNA9iV9T9Yv3ftJ22opZ03G2kaXGN6DQ7GU14=; b=ar3eqfoRpPmhnIet7U6GwRZfxqFJzNVOV1oi9bKajafjS6ymmseA7YQGVT2AH+f2cV 4hI6QpPqByNwrn4oEg/AxuPRy7NpqM5lg8wTq8/f3czsvjyO37r2AtU7zx+ch4XqfQ/B k2fS7dZY8IjPUmtusYrP1BCdN6S6k5NFxedgz8zLuwE6R9IlRoEjmJPwQi8mEWrXeykK 3v0WsEF1M87ndb4sxlFygkAIqfRLhOT7sAeXomDzKl8FB7NldExRBcETQgHshL/tbrsq zt8Qbtav7ofeMvEbI8e2tJO4whymaE0soOgpIA48/QhMoKEQBJZnfDBEUbd5r5NojI2b 7STQ== X-Gm-Message-State: ALoCoQmDjmkjHj7KAR5JRiiyrSqdpVdcZ42Wqpl8cgN4nbLAhnBNZnmccbf0VlAIE59ZHdYxRdU/ X-Received: by 10.50.79.227 with SMTP id m3mr117132igx.47.1398912926735; Wed, 30 Apr 2014 19:55:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.136 with HTTP; Wed, 30 Apr 2014 19:55:06 -0700 (PDT) In-Reply-To: <40C41DA9-3513-4BC3-B6C9-7A1EEF98BBC7@cisco.com> References: <40C41DA9-3513-4BC3-B6C9-7A1EEF98BBC7@cisco.com> From: Lorenzo Colitti Date: Thu, 1 May 2014 11:55:06 +0900 Message-ID: To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=089e01175f5d12156d04f84dcc92 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Y9ndmkshS-4USG9u5dPuLs7w-X4 Cc: V6 Ops List , "Byrne, Cameron" Subject: Re: [v6ops] Thoughts on 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: Thu, 01 May 2014 02:55:30 -0000 --089e01175f5d12156d04f84dcc92 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, May 1, 2014 at 8:24 AM, Fred Baker (fred) wrote: > Ask me someday what thoughts go through my mind about applications making > inferences from network layer addresses. > The wording in RFC 3927 is much stronger. For example, it states multiple times that packets sourced from 169.254/16 MUST NOT be forwarded, and that they MUST NOT ever be sent to any router for forwarding. I think it's perfectly reasonable for an app (or even an OS!) to assume that such addresses have no connectivity. > Hey, 192.168.0.0/16 is for networks that don=E2=80=99t connect to the Int= ernet. > You want proof? From RFC 1918, the motivation is > > With the proliferation of TCP/IP technology worldwide, including > outside the Internet itself, an increasing number of non-connected > enterprises use this technology and its addressing capabilities for > sole intra-enterprise communications, without any intention to ever > directly connect to other enterprises or the Internet itself. > Funny, that's what the proponents of ULA-only networks say too - "no, this network will NEVER connect to the Internet, ever!!11" I suspect they do so because they know that saying "we want to use NAT to connect this network to the Internet like we do in IPv4" is going to result in strong opinions and removal of support for the use case. But that's off-topic here. --089e01175f5d12156d04f84dcc92 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On T= hu, May 1, 2014 at 8:24 AM, Fred Baker (fred) <fred@cisco.com> = wrote:
    Ask me someday what thoughts go through my mind about applicati= ons making inferences from network layer addresses.

    The wording in RFC 3927 is much stro= nger. For example, it states multiple times that packets sourced from 169.2= 54/16 MUST NOT be forwarded, and that they MUST NOT ever be sent to any rou= ter for forwarding. I think it's perfectly reasonable for an app (or ev= en an OS!) to assume that such addresses have no connectivity.
    =C2=A0
    Hey, 192.168.0.0/16 is= for networks that don=E2=80=99t connect to the Internet. You want proof? F= rom RFC 1918, the motivation is

    =C2=A0 =C2=A0With the proliferation of TCP/IP technology worldwide, includi= ng
    =C2=A0 =C2=A0outside the Internet itself, an increasing number of non-conne= cted
    =C2=A0 =C2=A0enterprises use this technology and its addressing capabilitie= s for
    =C2=A0 =C2=A0sole intra-enterprise communications, without any intention to= ever
    =C2=A0 =C2=A0directly connect to other enterprises or the Internet itself.<= br>

    Funny, that's what the proponents o= f ULA-only networks say too - "no, this network will NEVER connect to = the Internet, ever!!11" I suspect they do so because they know that sa= ying "we want to use NAT to connect this network to the Internet like = we do in IPv4" is going to result in strong opinions and removal of su= pport for the use case. But that's off-topic here.
    --089e01175f5d12156d04f84dcc92-- From nobody Wed Apr 30 22:30: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 505D81A09F7 for ; Wed, 30 Apr 2014 22:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NORMAL_HTTP_TO_IP=0.001, RP_MATCHES_RCVD=-0.651] 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 6dAhlBfdt-kj for ; Wed, 30 Apr 2014 22:30:51 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFDE1A09F1 for ; Wed, 30 Apr 2014 22:30:51 -0700 (PDT) Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s415UfuN009538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 1 May 2014 05:30:41 GMT (envelope-from joelja@bogus.com) Message-ID: <5361DBFA.3010403@bogus.com> Date: Wed, 30 Apr 2014 22:30:34 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Thunderbird/29.0 MIME-Version: 1.0 To: Lorenzo Colitti , "Fred Baker (fred)" References: <40C41DA9-3513-4BC3-B6C9-7A1EEF98BBC7@cisco.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TUHF9TRJLRS5U5S4jKOGdOPPVCKFiR7fD" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Thu, 01 May 2014 05:30:42 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/t6NEKAK6nJr2iFlfuGRCquKh1YA Cc: V6 Ops List , "Byrne, Cameron" Subject: Re: [v6ops] Thoughts on 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: Thu, 01 May 2014 05:30:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TUHF9TRJLRS5U5S4jKOGdOPPVCKFiR7fD Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 4/30/14, 7:55 PM, Lorenzo Colitti wrote: > On Thu, May 1, 2014 at 8:24 AM, Fred Baker (fred) > wrote: >=20 > Ask me someday what thoughts go through my mind about applications > making inferences from network layer addresses. >=20 >=20 > The wording in RFC 3927 is much stronger. For example, it states > multiple times that packets sourced from 169.254/16 MUST NOT be > forwarded, and that they MUST NOT ever be sent to any router for > forwarding. I think it's perfectly reasonable for an app (or even an > OS!) to assume that such addresses have no connectivity. > =20 >=20 > Hey, 192.168.0.0/16 is for networks that > don=92t connect to the Internet. You want proof? From RFC 1918, the= > motivation is >=20 > With the proliferation of TCP/IP technology worldwide, including= > outside the Internet itself, an increasing number of non-connect= ed > enterprises use this technology and its addressing capabilities = for > sole intra-enterprise communications, without any intention to e= ver > directly connect to other enterprises or the Internet itself. >=20 >=20 > Funny, that's what the proponents of ULA-only networks say too - "no, > this network will NEVER connect to the Internet, ever!!11" I suspect > they do so because they know that saying "we want to use NAT to connect= > this network to the Internet like we do in IPv4" is going to result in > strong opinions and removal of support for the use case. But that's > off-topic here. site-local unicast in ipv6 and rfc 1918 are relatively contemporaneous ideas... I don't thing the pressures that produce such solutions are particularly new in fact it's pretty easy to assert that they co-evolved. >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --TUHF9TRJLRS5U5S4jKOGdOPPVCKFiR7fD 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/ iEYEARECAAYFAlNh2/sACgkQ8AA1q7Z/VrLNyACeNUFBSswEWTswvmdnZ/JzgxBB st4AnjM3k1TLP9gHAaZypKXEnKSPisdS =KUfk -----END PGP SIGNATURE----- --TUHF9TRJLRS5U5S4jKOGdOPPVCKFiR7fD-- From nobody Wed Apr 30 23:09: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 CE4DF1A09F8; Wed, 30 Apr 2014 23:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 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.651, 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 ClyiU_4L0904; Wed, 30 Apr 2014 23:08:54 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 300011A0A03; Wed, 30 Apr 2014 23:08:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=779; q=dns/txt; s=iport; t=1398924532; x=1400134132; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Vte9Knz0JjhgdbAJ1kp3eKKp3ToonmUBVOihCQgxQ+g=; b=IsqidTfcc30ArMFreNaKt0c6brNj2SKNlCN8ZCo1pAluHEJaWd+Ci9Oe XWlAzAJ92+OiEYY0iziK1OkPdt2jkt/LH503Sr7tai186awJa1AOCPn9i 9ujEe2LHkSUyJrB21kstU1jSwuunyg8Syqu0L7Wg/CzzIL3EkwcN8lYNk o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAB3kYVOtJA2L/2dsb2JhbABZgwZPV8RYgRgWdIIsOj8SAT5CJwQBDYhGDcoGF45RhEAEmSqBPJEwgzOCKw X-IronPort-AV: E=Sophos;i="4.97,963,1389744000"; d="scan'208";a="40196646" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-5.cisco.com with ESMTP; 01 May 2014 06:08:52 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s4168qRh016918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 May 2014 06:08:52 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.41]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Thu, 1 May 2014 01:08:52 -0500 From: "Rajiv Asati (rajiva)" To: "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org" Thread-Topic: Q about IPv4-mapped IPv6 address & MPLS Thread-Index: AQHPZQPSCzbpGVI9y0mONiS9cBGpHw== Date: Thu, 1 May 2014 06:08:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.82.218.19] Content-Type: text/plain; charset="us-ascii" Content-ID: <63CAFEE989E18C4398F9ABD33C077125@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/FQxf_e-Rt3VqFBAkL1f9NAHOL-M Cc: "mpls@ietf.org" Subject: [v6ops] Q about IPv4-mapped IPv6 address & MPLS 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, 01 May 2014 06:08:58 -0000 We need your guidance on handling v4-mapped v6 addresses (section 2.5.5.2 of [RFC4291]).=20 1. Should/Would they appear in IPv6 routing table? 2. Should an IPv6 packet with ::FFFF:127.0.0.0 be forwarded or dropped or treated as a loopback packet, if ever received? The answer to Q#1 will help MPLS WG to decide the proper handling of v4-mapped v6 addresses in LDPv6 draft section 7 1st para. http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-12#section-7 * The answer to Q2 will help us assess the efficacy of RFC4379. Thanks.=20 --=20 Cheers, Rajiv=20 * // An LSR MUST treat the IPv4-mapped IPv6 address, defined in section 2.5.5.2 of [RFC4291], the same as that of a global IPv6 address and not mix it with the 'corresponding' IPv4 address. // From nobody Wed Apr 30 23:40: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 452411A0A1D; Wed, 30 Apr 2014 23:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.651, 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 Xlf-HPyfvtsC; Wed, 30 Apr 2014 23:40:05 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 0948D1A0A17; Wed, 30 Apr 2014 23:40:04 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 41647A6; Thu, 1 May 2014 08:40:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1398926401; bh=IUHzY9P5Tzupc+oTZ9Cw00jAZ0R12KITCQd0JZw7mT8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=v9iSrtsKIY6SlqfOHArroPqa2T7ik1NVdcSEWIWkldg0RNfVZmbMtfF+BrgcpmuZq 3VRaVh/8zy+n1Z2s+Ol4Lgn/L/sKA+JWtQVmdhC7S4UYkIh8kOMz91uRIwm2x5ywAo k5asWe7ioeDjuKaX1yw1Y7fZCMl438Vn0IVEWQd4= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3D8FAA5; Thu, 1 May 2014 08:40:01 +0200 (CEST) Date: Thu, 1 May 2014 08:40:01 +0200 (CEST) From: Mikael Abrahamsson To: "Rajiv Asati (rajiva)" In-Reply-To: Message-ID: References: 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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/LannvsuaRlC7P2NSusb7ov92MjI Cc: "mpls@ietf.org" , "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org> Subject: Re: [v6ops] Q about IPv4-mapped IPv6 address & MPLS 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, 01 May 2014 06:40:07 -0000 On Thu, 1 May 2014, Rajiv Asati (rajiva) wrote: > > We need your guidance on handling v4-mapped v6 addresses (section 2.5.5.2 > of [RFC4291]). > > 1. Should/Would they appear in IPv6 routing table? > 2. Should an IPv6 packet with ::FFFF:127.0.0.0 be forwarded or dropped or > treated as a loopback packet, if ever received? > > The answer to Q#1 will help MPLS WG to decide the proper handling of > v4-mapped v6 addresses in LDPv6 draft section 7 1st para. > http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-12#section-7 * > > The answer to Q2 will help us assess the efficacy of RFC4379. http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02 I realise this draft seems to have died, but I would never expect to see packets with these addresses on the wire or in the routing table and if they're there, I would want hosts/routers to drop them. Not doing this seems to me it would open to all kinds of unwanted consequences when it comes to filtering etc. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Apr 30 23:45: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 BDD8A1A0A17; Wed, 30 Apr 2014 23:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vTFzjQ12N6O9; Wed, 30 Apr 2014 23:44:38 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) by ietfa.amsl.com (Postfix) with ESMTP id 9D32F1A0A15; Wed, 30 Apr 2014 23:44:37 -0700 (PDT) Received: from BLUPR03MB424.namprd03.prod.outlook.com (10.141.78.152) by BLUPR03MB423.namprd03.prod.outlook.com (10.141.78.150) with Microsoft SMTP Server (TLS) id 15.0.929.12; Thu, 1 May 2014 06:44:29 +0000 Received: from BLUPR03MB424.namprd03.prod.outlook.com ([10.141.78.152]) by BLUPR03MB424.namprd03.prod.outlook.com ([10.141.78.152]) with mapi id 15.00.0929.001; Thu, 1 May 2014 06:44:29 +0000 From: Christian Huitema To: "Rajiv Asati (rajiva)" , "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org" Thread-Topic: Q about IPv4-mapped IPv6 address & MPLS Thread-Index: AQHPZQPSCzbpGVI9y0mONiS9cBGpH5srRWcQ Date: Thu, 1 May 2014 06:44:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.16.156.113] x-forefront-prvs: 01986AE76B x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(51704005)(77096999)(87936001)(33646001)(2201001)(19580395003)(85852003)(20776003)(76576001)(15202345003)(46102001)(79102001)(83072002)(101416001)(81342001)(77982001)(92566001)(54356999)(86362001)(50986999)(99396002)(83322001)(80022001)(99286001)(81542001)(74502001)(86612001)(4396001)(80976001)(2656002)(66066001)(31966008)(15975445006)(76176999)(76482001)(74662001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB423; H:BLUPR03MB424.namprd03.prod.outlook.com; FPR:BCA2C0F5.3EFE1DC9.9D11349.C68AE311.201EE; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/JL7FAutRoetgSqL0JaO9-HD9v4A Cc: "mpls@ietf.org" Subject: Re: [v6ops] Q about IPv4-mapped IPv6 address & MPLS 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, 01 May 2014 06:44:42 -0000 > We need your guidance on handling v4-mapped v6 addresses (section 2.5.5.2 > of [RFC4291]).=20 > > 1. Should/Would they appear in IPv6 routing table? > 2. Should an IPv6 packet with ::FFFF:127.0.0.0 be forwarded or dropped o= r > treated as a loopback packet, if ever received? > > The answer to Q#1 will help MPLS WG to decide the proper handling of > v4-mapped v6 addresses in LDPv6 draft section 7 1st para. > http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-12#section-7 * You may want to check RFC 6052, IPv6 Addressing of IPv4/IPv6 Translators. R= FC 6052 updates RFC4291, and lets translators construct domain specific add= resses that can actually be used in the routing tables. It also includes an= answer to your loopback packet question: The Well-Known Prefix MUST NOT be used to represent non-global IPv4 addresses, such as those defined in [RFC1918] or listed in Section 3 of [RFC5735]. Address translators MUST NOT translate packets in which an address is composed of the Well-Known Prefix and a non- global IPv4 address; they MUST drop these packets. -- Christian Huitema From nobody Wed Apr 30 23:46: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 998FB1A0A3F for ; Wed, 30 Apr 2014 23:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable 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 Unf21wo5bx40 for ; Wed, 30 Apr 2014 23:46:47 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id A4E3A1A0A38 for ; Wed, 30 Apr 2014 23:46:46 -0700 (PDT) Received: from [203.219.211.243] (helo=[192.168.0.8]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1WfklV-0006Ph-Va; Thu, 01 May 2014 16:46:42 +1000 User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Thu, 01 May 2014 16:46:33 +1000 From: Hesham Soliman To: Mikael Abrahamsson , "Rajiv Asati (rajiva)" Message-ID: Thread-Topic: [v6ops] Q about IPv4-mapped IPv6 address & MPLS References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-User: hesham@elevatemobile.com Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/P4tIUEC7J6Kj8TaNLpOiRKIwbf8 Cc: "mpls@ietf.org" , "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org> Subject: Re: [v6ops] Q about IPv4-mapped IPv6 address & MPLS 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, 01 May 2014 06:46:49 -0000 >> >>We need your guidance on handling v4-mapped v6 addresses (section 2.5.5.2 >> of [RFC4291]). >> >> 1. Should/Would they appear in IPv6 routing table? >> 2. Should an IPv6 packet with ::FFFF:127.0.0.0 be forwarded or dropped >>or >> treated as a loopback packet, if ever received? >> >> The answer to Q#1 will help MPLS WG to decide the proper handling of >> v4-mapped v6 addresses in LDPv6 draft section 7 1st para. >> http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-12#section-7 * >> >> The answer to Q2 will help us assess the efficacy of RFC4379. > >http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02 > >I realise this draft seems to have died, but I would never expect to see >packets with these addresses on the wire =3D> I recall an information RFC but don=B9t remember the number. I agree they will most likely not appear on the wire. > or in the routing table =3D> That=B9s a different story. I don=B9t think there is anything banning this, not least due to the fact that it is an implementation issue. If that entry points to an IPv4 tunnel it should be fine. So it is possible to implement a tunnel that way inside the host/router and nothing to stop someone from doing unless I missed an RFC. > and if=20 >they're there, I would want hosts/routers to drop them. =3D> Is that behaviour documented somewhere? Also, you=B9re mixing them appearing on the wire with an internal implementation issue. Hesham >Not doing this=20 >seems to me it would open to all kinds of unwanted consequences when it >comes to filtering etc. > >--=20 >Mikael Abrahamsson email: swmike@swm.pp.se > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Apr 30 23:59: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 472AD1A0A27; Wed, 30 Apr 2014 23:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.602 X-Spam-Level: X-Spam-Status: No, score=-4.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 k07gSmZUr0tY; Wed, 30 Apr 2014 23:59:25 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 14EA51A0A17; Wed, 30 Apr 2014 23:59:25 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8B4FCA6; Thu, 1 May 2014 08:59:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1398927562; bh=8xqZPIWyBXZqp6CTGwV0Pcox1VFGEELHcpcDyoP4C6o=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=y0mdbxSSvD+nRQBAoYSpkaZ6yRxzHjDS5vmaEe/Mhw4WWxMKaBn43953IW2wzLa6h jL1kokdz7ISR24CwYn1LEx3puCia6sYgb8PzLCy0I1MQHa+1hIcyv8WKVxwvwjzDai AsEaanXlo9009qbDj0kfNDEJ+xJgta+lxRRHEucU= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 7DB4CA5; Thu, 1 May 2014 08:59:22 +0200 (CEST) Date: Thu, 1 May 2014 08:59:22 +0200 (CEST) From: Mikael Abrahamsson To: Hesham Soliman In-Reply-To: Message-ID: References: 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-478116969-1398927562=:29282" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/C84UyWyzUu2KXFnZ4SegBrWv0s4 Cc: "mpls@ietf.org" , "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org> Subject: Re: [v6ops] Q about IPv4-mapped IPv6 address & MPLS 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, 01 May 2014 06:59:27 -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-478116969-1398927562=:29282 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 1 May 2014, Hesham Soliman wrote: >> or in the routing table > > => Thatšs a different story. I donšt think there is anything banning this, > not least due to the fact that it is an implementation issue. If that > entry points to an IPv4 tunnel it should be fine. So it is possible to > implement a tunnel that way inside the host/router and nothing to stop > someone from doing unless I missed an RFC. Let me qualify my statement that I don't want to see it outside the box, ie in routes it's sending to anyone else. If it's in the internal RIB I have no problem with it, if it starts being announced in IGP and BGP then I think it's a bigger issue. >> and if >> they're there, I would want hosts/routers to drop them. > > => Is that behaviour documented somewhere? Also, youšre mixing them > appearing on the wire with an internal implementation issue. If this is documented somewhere, I am not aware, but I am definitely not the right person to ask about what might be in what RFC. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-478116969-1398927562=:29282--