From iesg-secretary@ietf.org Mon Jan 2 09:59:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D46411E80B4; Mon, 2 Jan 2012 09:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.128 X-Spam-Level: X-Spam-Status: No, score=-102.128 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lydpOrwXsVwx; Mon, 2 Jan 2012 09:59:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A7511E80B6; Mon, 2 Jan 2012 09:59:22 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120102175922.19306.84675.idtracker@ietfa.amsl.com> Date: Mon, 02 Jan 2012 09:59:22 -0800 Cc: v6ops mailing list , v6ops chair , RFC Editor Subject: [v6ops] Protocol Action: 'Happy Eyeballs: Success with Dual-Stack Hosts' to Proposed Standard (draft-ietf-v6ops-happy-eyeballs-07.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 17:59:23 -0000 The IESG has approved the following document: - 'Happy Eyeballs: Success with Dual-Stack Hosts' (draft-ietf-v6ops-happy-eyeballs-07.txt) as a Proposed Standard This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Ron Bonica and Dan Romascanu. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-v6ops-happy-eyeballs/ Technical Summary When the IPv4 server and path is working but the IPv6 server or IPv6 path is down, a dual-stack client application experiences significant connection delay compared to an IPv4-only client. This is undesirable because it causes the dual-stack client to have a worse user experience. This document specifies requirements for algorithms that reduce this delay, and provides an example algorithm. Working Group Summary v6ops considered this carefully, and tested various possible implementations of the solution. Document Quality The document appears to be of high quality per the numerous reviews received. Personnel Joel Jaegli is shepherd From fred@cisco.com Tue Jan 3 15:27:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6301F0C35 for ; Tue, 3 Jan 2012 15:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.428 X-Spam-Level: X-Spam-Status: No, score=-106.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zN6HGjBteOEF for ; Tue, 3 Jan 2012 15:27:07 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 215EB21F84F8 for ; Tue, 3 Jan 2012 15:27:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2047; q=dns/txt; s=iport; t=1325633227; x=1326842827; h=from:subject:date:references:to:message-id:mime-version: content-transfer-encoding; bh=qdWAU6Q6CTJ8YC9mst6OKukofO39Eqt8r8ovO6bBcJ8=; b=ebR2FClpiS2RRnXt7mQ3WItg3L4637VfeF64g/TKwrqiebKZZBGUPZrR RmvkWuacXJciZmy9QHa1zw4qTJpHvfVT5Ky8OUuRRVeLdd3gMpQmoEzQi KlS8Hf6X+7ozEoyX/NUx7lAip9aALhq5mRSVlxeJ6AXtJ9JAd4ANDRlGk 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQIAGyOA0+rRDoJ/2dsb2JhbABDggWqXIEFgXIBAQEDAQEBAQ8BJzQQCxwDAQIvJx8HAggGEwkZh1gIlzoBng2LLGMEiDeMS4VPhSOHYw X-IronPort-AV: E=Sophos;i="4.71,452,1320624000"; d="scan'208";a="23654348" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 03 Jan 2012 23:26:57 +0000 Received: from stealth-10-32-244-220.cisco.com (stealth-10-32-244-220.cisco.com [10.32.244.220]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q03NQvf6005054 for ; Tue, 3 Jan 2012 23:26:57 GMT Received: from [127.0.0.1] by stealth-10-32-244-220.cisco.com (PGP Universal service); Tue, 03 Jan 2012 15:26:57 -0800 X-PGP-Universal: processed; by stealth-10-32-244-220.cisco.com on Tue, 03 Jan 2012 15:26:57 -0800 From: Fred Baker Date: Tue, 3 Jan 2012 15:26:46 -0800 References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com> To: "v6ops@ietf.org WG" Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 23:27:08 -0000 Folks - there is a new draft of 6204bis. Those that have issues with = previous drafts are encouraged to comment on this version. Begin forwarded message: > From: internet-drafts@ietf.org > Date: December 22, 2011 1:03:18 PM PST > To: i-d-announce@ietf.org > Cc: v6ops@ietf.org > Subject: I-D Action: draft-ietf-v6ops-6204bis-05.txt > Reply-To: internet-drafts@ietf.org >=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 : Basic Requirements for IPv6 Customer Edge = Routers > Author(s) : Hemant Singh > Wes Beebee > Chris Donley > Barbara Stark > Ole Troan > Filename : draft-ietf-v6ops-6204bis-05.txt > Pages : 21 > Date : 2011-12-22 >=20 > This document specifies requirements for an IPv6 Customer Edge (CE) > router. Specifically, the current version of this document focuses > on the basic provisioning of an IPv6 CE router and the provisioning > of IPv6 hosts attached to it. The document also covers IP = transition > technologies. Two transition technologies in RFC 5969's 6rd and RFC > 6333's DS-Lite. are covered in the document. The document obsoletes > RFC 6204, if approved. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6204bis-05.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-6204bis-05.txt >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From ari.keranen@nomadiclab.com Wed Jan 4 08:29:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEB021F87DC for ; Wed, 4 Jan 2012 08:29:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52IS-CBXf2NU for ; Wed, 4 Jan 2012 08:29:37 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD8C21F87D7 for ; Wed, 4 Jan 2012 08:29:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id A8B4D4E6DF; Wed, 4 Jan 2012 18:29:35 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFge5c9aqVtx; Wed, 4 Jan 2012 18:29:34 +0200 (EET) Received: from n212.nomadiclab.com (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 0858A4E6DA; Wed, 4 Jan 2012 18:29:34 +0200 (EET) Message-ID: <4F047E6B.2050609@nomadiclab.com> Date: Wed, 04 Jan 2012 18:29:31 +0200 From: Ari Keranen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Fred Baker References: <5D1D055D-6043-42F8-91F8-84C317267F21@cisco.com><033501cc5035$13e0f360$4001a8c0@gateway.2wire.net><032501cc5104$5c4a6440$4001a8c0@gateway.2wire.net><6235E21D-22B9-40A7-ACB3-690A8864206D@nomadiclab.com> <022e01cc5355$5f083240$4001a8c0@gateway.2wire.net> <034301ccbf40$0c672440$4001a8c0@gateway.2wire.net> <4EF1E481.2060705@nomadiclab.com> In-Reply-To: <4EF1E481.2060705@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Nevil Brownlee , Jari Arkko , Ron Bonica Subject: Re: [v6ops] draft-keranen-ipv6day-measurements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 16:29:38 -0000 Hi, We have now submitted an updated version of the draft to the ID tracker: http://tools.ietf.org/html/draft-keranen-ipv6day-measurements-02 We think the draft is ready to move forward on the independent track. Thank you to everyone in the v6ops WG for comments and feedback. Cheers, Ari On 12/21/11 3:52 PM, Ari Keranen wrote: > Fred, Tom, > > I agree that the best path for this draft is the independent track. > We'll do an update to the draft taking into account the feedback and > submit a new version soon. > > > Cheers, > Ari > > On 12/20/11 9:04 PM, Fred Baker wrote: >> Copying the ISE and the Ops AD. In my opinion, the best path for the >> document, if it is to be published as an RFC, is the independent >> track. If we take it as a working group document, I suspect it needs >> to be a very different one, and that isn't in keeping with the >> author's intent. >> >> On Dec 20, 2011, at 9:50 AM, t.petch wrote: >> >>> I had hoped to see this progress towards an RFC; like >>> 'draft-arkko-ipv6-only-experience', I see it as a memo 'of the >>> moment', out of date as soon as it is written but still valuable as >>> long as it does not take too long to hit the streets ie I would >>> still like it to progress, but could change my mind in future! >>> >>> Tom Petch >>> >>> >>> ----- Original Message ----- From: "t.petch" >>> To: "Ari Keranen" Cc: "IPv6 >>> Operations" Sent: Friday, August 05, 2011 10:52 AM >>> inline >>>> --- Original Message ----- From: "Ari >>>> Keranen" To: >>>> "t.petch" Cc: "IPv6 >>>> Operations" Sent: Thursday, August 04, 2011 11:33 >>>> AM On Aug 2, 2011, at 2:07 PM, t.petch wrote: >>>>> In the hope that you will take up Fred's generous offer to push >>>>> this through >>>> to >>>>> an RFC, I hope that you will find these comments helpful >>>> >>>> Thanks for the feedback! As Jari already mentioned, we haven't >>>> fixed our plans regarding how and if these results should be >>>> published, but if there is >>> interest >>>> in the WG, v6ops RFC is indeed one good option. >>>> >>>>> I would like to see more references, for 6to4 and for the >>>>> various .pdf; I >>>> think >>>>> it works better to have them all in one place. >>>> >>>> By .pdf do you mean the graph PDFs, other presentations something >>>> else? >>>> >>>> I mean the graph PDFs, where you have the URI in the text >>>> but not in the References, I would like it at least in the >>>> latter, less concerned about the former. >>>> >>>>> I find the X-axis of the graphs unclear; time presumably, but >>>>> what time? >>>> >>>> It's the sequence number of the measurement run; so something >>>> like "time in 3 hour steps since the start of the tests". >>>> Probably hours (or even time and >>> date) >>>> would work better here. >>>> >>>> Yes, date and time would be lovely; I thought it was >>>> measurement run but did >>> not >>>> have a start point and the interval was not obvious. >>>> >>>>> I think that the biggest conclusion is omitted; only 2.45% of >>>>> the top 10,000 sites offer IPv6 via DNS ie next to none; I >>>>> think that this should be in BIG BOLD LETTERS. >>>> >>>> True, but that was not news to anyone :) >>>> >>>> Disagree; we know that the availability of IPv6 is >>>> negligible but we do not >>> know >>>> how much it is, and a hard data point at a point in time will >>>> provide a >>> valuable >>>> record. I was surprised at how small it was, I would have >>>> guessed 10-20% ( >>> but >>>> then I am probably misled but the amount of traffic on the v6ops >>>> list:-) >>>> >>>>> And while comprehension is no problem, the idiom is sometimes >>>>> slightly odd. Doubtless the RFC Editor will fix it but I could >>>>> point some of these out to >>>> you >>>>> if you want. >>>> >>>> That'd be helpful; please send me a mail with those off-list. >>>> >>>> I hope you do; Fred has indicated a willingness to help. I >>>> cannot think of a way to put it without being unfair to Fred, but >>>> it is an offer never to spurn. >>>> >>>> Tom Petch Cheers, Ari >>>> >>>> P.S. I'll be out of office for a couple of weeks, so it may take >>>> a while >>> before >>>> I have a chance to follow up on this >>>> >>>> >>>>> Tom Petch >>>>> From wesley.george@twcable.com Wed Jan 4 13:11:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3957311E80C1 for ; Wed, 4 Jan 2012 13:11:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.763 X-Spam-Level: X-Spam-Status: No, score=-0.763 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZFPwQpSLqFJ for ; Wed, 4 Jan 2012 13:11:04 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id BABC321F8592 for ; Wed, 4 Jan 2012 13:11:03 -0800 (PST) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.71,457,1320642000"; d="scan'208";a="319574024" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 04 Jan 2012 16:04:42 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Wed, 4 Jan 2012 16:10:47 -0500 From: "George, Wes" To: Chris Grundemann , Fred Baker , v6ops v6ops WG Date: Wed, 4 Jan 2012 16:10:46 -0500 Thread-Topic: [v6ops] Please review draft-donley-behave-deterministic-cgn Thread-Index: AczE3hYrxNASJmabRUaOCTV/UHGuUgGHG/Pw Message-ID: References: <34E4F50CAFA10349A41E0756550084FB11D94DA3@PRVPEXVS04.corp.twcable.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Behave Chairs , "draft-donley-behave-deterministic-cgn@tools.ietf.org" Subject: Re: [v6ops] Please review draft-donley-behave-deterministic-cgn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 21:11:07 -0000 > From: Chris Grundemann [mailto:C.Grundemann@cablelabs.com] > Sent: Tuesday, December 27, 2011 4:26 PM > Subject: Re: [v6ops] Please review draft-donley-behave-deterministic- > cgn > > >In terms of the meat of the document, I think that the document needs > to > >cover the case where ports are not allocated sequentially (such as in > >order to reduce the determinisim and make it harder for a rogue entity > to > >guess the next port, or for privacy reasons). It may work basically > the > >same way as when a subscriber exceeds their pre-allocated ports, but > the > >draft should explicitly cover this. > > I may be misunderstanding but I believe this is covered in Section 2, > Step > 2, which reads in part: > ... [WEG] Yeah, you're right, I don't know how I missed that. > > I'm not opposed to adding a section covering failover but I believe > that it would be fairly simple. > ... > > Perhaps I'm missing something though, and this is more complicated than > I > propose. > [WEG] mostly that sounds right, but I think it's worth discussing. Likely s= marter people than me will have more constructive feedback once the section= is there to get them thinking about it. This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From dthaler@microsoft.com Wed Jan 4 14:27:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8BA21F8626 for ; Wed, 4 Jan 2012 14:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.174 X-Spam-Level: X-Spam-Status: No, score=-104.174 tagged_above=-999 required=5 tests=[AWL=-1.175, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8oCS-YCRxoy for ; Wed, 4 Jan 2012 14:27:10 -0800 (PST) Received: from VA3EHSOBE003.bigfish.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1E41D21F860F for ; Wed, 4 Jan 2012 14:27:10 -0800 (PST) Received: from mail192-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Wed, 4 Jan 2012 22:27:09 +0000 Received: from mail192-va3 (localhost [127.0.0.1]) by mail192-va3-R.bigfish.com (Postfix) with ESMTP id 6F58164009B; Wed, 4 Jan 2012 22:27:08 +0000 (UTC) X-SpamScore: -31 X-BigFish: VS-31(zz9371I1b0bM542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail192-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail192-va3 (localhost.localdomain [127.0.0.1]) by mail192-va3 (MessageSwitch) id 1325716028169667_22202; Wed, 4 Jan 2012 22:27:08 +0000 (UTC) Received: from VA3EHSMHS002.bigfish.com (unknown [10.7.14.237]) by mail192-va3.bigfish.com (Postfix) with ESMTP id 22D666025A; Wed, 4 Jan 2012 22:27:08 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS002.bigfish.com (10.7.99.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 4 Jan 2012 22:27:06 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.2.247.5; Wed, 4 Jan 2012 14:27:02 -0800 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.90]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.01.0355.003; Wed, 4 Jan 2012 14:27:04 -0800 From: Dave Thaler To: v6ops v6ops WG Thread-Topic: Please review draft-donley-behave-deterministic-cgn Thread-Index: AQHMiB1PAUTmyciOvUu0UD0+xRbzl5X9T2eQ Date: Wed, 4 Jan 2012 22:27:04 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B37B11E@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: <3C8B8B8F-6B08-43DE-AF8B-5FF37B087A5F@cisco.com> In-Reply-To: <3C8B8B8F-6B08-43DE-AF8B-5FF37B087A5F@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Behave Chairs , "draft-donley-behave-deterministic-cgn@tools.ietf.org" Subject: Re: [v6ops] Please review draft-donley-behave-deterministic-cgn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:27:10 -0000 Yes operational commentary would be very welcome. Also FYI, the author of the draft has declared IPR on it: https://datatracker.ietf.org/ipr/1617/ -Dave -----Original Message----- From: Fred Baker [mailto:fred@cisco.com]=20 Sent: Tuesday, October 11, 2011 6:52 AM To: v6ops v6ops WG Cc: Behave Chairs; draft-donley-behave-deterministic-cgn@tools.ietf.org Subject: Please review draft-donley-behave-deterministic-cgn Operators subject to law enforcement subpoenas and using Carrier Grade NAT = are having difficulties with the syslog rate for per-connection logging. Ch= ris Donley has proposed a simplification; the provider allocates a determin= istic set of source ports to his subscribers, and only needs to log excepti= ons. Research in the area suggests that usage of source ports is pareto dis= tributed; a typical user has a requirement on the order of 4 port numbers i= n simultaneous use (median), but port scans and other large volume uses dri= ve the average quite a bit higher.=20 They haven't asked for it, but I suspect the behave chairs would appreciate= operational commentary on the draft. http://tools.ietf.org/html/draft-donley-behave-deterministic-cgn "Deterministic Address Mapping to Reduce Logging in Carrier Grade NATs", Chris Donley, Chris Grundemann, Vikas Sarawat, Karthik Sundaresan, 26-Sep-11 From fred@cisco.com Wed Jan 4 14:31:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E0F11E80EE for ; Wed, 4 Jan 2012 14:31:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.149 X-Spam-Level: X-Spam-Status: No, score=-106.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iogtvebcnHbj for ; Wed, 4 Jan 2012 14:31:21 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1E011E80C1 for ; Wed, 4 Jan 2012 14:31:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1545; q=dns/txt; s=iport; t=1325716280; x=1326925880; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=iTEd3vOzn7slpB9Boh3FTethBc6iNf0GMllhxdN8RBM=; b=A5Pbbqh1jOCJuWbQTTCMvJ3ePv3IgrfKcEmsC8vPd4N/i+OaS8Fawf/c D5kFsWVFtul+boUsW5XmrzHxaMD6rr4C2X6ISUyjhxBqAjHDTfsWdmmHR 0z7bQlwUO9l1Du1MTVhBzQTa0l5y3YppNdfVDZ/Co/p+QeCblEHP/3SHb E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An0AAM3SBE+rRDoH/2dsb2JhbABDggWaIpBFgQWBcgEBAQMBEgEnLRIFBwQLDgMEAQEoB0YJCAYTIodYCJcVAZ4JiyxjBIg4jEyFT40G X-IronPort-AV: E=Sophos;i="4.71,458,1320624000"; d="scan'208";a="22132775" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 04 Jan 2012 22:31:20 +0000 Received: from stealth-10-32-244-220.cisco.com (stealth-10-32-244-220.cisco.com [10.32.244.220]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q04MVKxU031284; Wed, 4 Jan 2012 22:31:20 GMT Received: from [127.0.0.1] by stealth-10-32-244-220.cisco.com (PGP Universal service); Wed, 04 Jan 2012 14:31:20 -0800 X-PGP-Universal: processed; by stealth-10-32-244-220.cisco.com on Wed, 04 Jan 2012 14:31:20 -0800 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B37B11E@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Date: Wed, 4 Jan 2012 14:31:08 -0800 Message-Id: <4B79E585-694C-46D3-82CA-544AAD17798E@cisco.com> References: <3C8B8B8F-6B08-43DE-AF8B-5FF37B087A5F@cisco.com> <9B57C850BB53634CACEC56EF4853FF653B37B11E@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> To: Dave Thaler X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops WG , Behave Chairs , "draft-donley-behave-deterministic-cgn@tools.ietf.org" Subject: Re: [v6ops] Please review draft-donley-behave-deterministic-cgn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:31:21 -0000 On Jan 4, 2012, at 2:27 PM, Dave Thaler wrote: > Yes operational commentary would be very welcome. >=20 > Also FYI, the author of the draft has declared IPR on it: > https://datatracker.ietf.org/ipr/1617/ I wish them luck when they try to enforce it.=20 > -Dave >=20 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com]=20 > Sent: Tuesday, October 11, 2011 6:52 AM > To: v6ops v6ops WG > Cc: Behave Chairs; = draft-donley-behave-deterministic-cgn@tools.ietf.org > Subject: Please review draft-donley-behave-deterministic-cgn >=20 > Operators subject to law enforcement subpoenas and using Carrier Grade = NAT are having difficulties with the syslog rate for per-connection = logging. Chris Donley has proposed a simplification; the provider = allocates a deterministic set of source ports to his subscribers, and = only needs to log exceptions. Research in the area suggests that usage = of source ports is pareto distributed; a typical user has a requirement = on the order of 4 port numbers in simultaneous use (median), but port = scans and other large volume uses drive the average quite a bit higher.=20= >=20 > They haven't asked for it, but I suspect the behave chairs would = appreciate operational commentary on the draft. >=20 > http://tools.ietf.org/html/draft-donley-behave-deterministic-cgn > "Deterministic Address Mapping to Reduce Logging in Carrier Grade = NATs", > Chris Donley, Chris Grundemann, Vikas Sarawat, Karthik Sundaresan, > 26-Sep-11 >=20 >=20 >=20 From jmh@joelhalpern.com Wed Jan 4 14:32:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEC221F85D7 for ; Wed, 4 Jan 2012 14:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.94 X-Spam-Level: X-Spam-Status: No, score=-101.94 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaXkEh1xkTJl for ; Wed, 4 Jan 2012 14:32:24 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5C821F85D6 for ; Wed, 4 Jan 2012 14:32:20 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 2F20ACD186 for ; Wed, 4 Jan 2012 14:32:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 5A5BC1804D3; Wed, 4 Jan 2012 14:32:18 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-89.clppva.btas.verizon.net [71.161.50.89]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id F24541804DD; Wed, 4 Jan 2012 14:32:16 -0800 (PST) Message-ID: <4F04D370.7030403@joelhalpern.com> Date: Wed, 04 Jan 2012 17:32:16 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Dave Thaler References: <3C8B8B8F-6B08-43DE-AF8B-5FF37B087A5F@cisco.com> <9B57C850BB53634CACEC56EF4853FF653B37B11E@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B37B11E@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops v6ops WG , Behave Chairs , "draft-donley-behave-deterministic-cgn@tools.ietf.org" Subject: Re: [v6ops] Please review draft-donley-behave-deterministic-cgn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:32:25 -0000 When I asked on operator about the port distribution, their answer was somewhat different. What they said was that when the users are idle, they don't use many ports. But when the user is busy, they use a lot of ports. This makes repeated, largeish, block allocation sensible, but makes pre-allocation of a small number, and then individual allocation thereafter, a bad strategy, as it will basically log as much as current. I do not have access to any research results to disambiguate these two reports. Yours, Joel On 1/4/2012 5:27 PM, Dave Thaler wrote: > Yes operational commentary would be very welcome. > > Also FYI, the author of the draft has declared IPR on it: > https://datatracker.ietf.org/ipr/1617/ > > -Dave > > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Tuesday, October 11, 2011 6:52 AM > To: v6ops v6ops WG > Cc: Behave Chairs; draft-donley-behave-deterministic-cgn@tools.ietf.org > Subject: Please review draft-donley-behave-deterministic-cgn > > Operators subject to law enforcement subpoenas and using Carrier Grade NAT are having difficulties with the syslog rate for per-connection logging. Chris Donley has proposed a simplification; the provider allocates a deterministic set of source ports to his subscribers, and only needs to log exceptions. Research in the area suggests that usage of source ports is pareto distributed; a typical user has a requirement on the order of 4 port numbers in simultaneous use (median), but port scans and other large volume uses drive the average quite a bit higher. > > They haven't asked for it, but I suspect the behave chairs would appreciate operational commentary on the draft. > > http://tools.ietf.org/html/draft-donley-behave-deterministic-cgn > "Deterministic Address Mapping to Reduce Logging in Carrier Grade NATs", > Chris Donley, Chris Grundemann, Vikas Sarawat, Karthik Sundaresan, > 26-Sep-11 > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From cb.list6@gmail.com Wed Jan 4 14:56:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D70711E80FF for ; Wed, 4 Jan 2012 14:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSGLCpb24dAV for ; Wed, 4 Jan 2012 14:56:28 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 91E9711E8105 for ; Wed, 4 Jan 2012 14:56:28 -0800 (PST) Received: by dajz8 with SMTP id z8so16676757daj.31 for ; Wed, 04 Jan 2012 14:56:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XU7FquEG+HfAsMtN+DfMb3213YCAedBbYqWQWCAqhpg=; b=McXQNHdz28MQbfxkGyHNuRWiYoEs4lBMC81ltMmki0rloYtY7ud+IXPGHZBjthx+J0 LH58g4Y1v74cdOaUMOV8KGfXofhWDu06sQ3ApsAuvWVYT0oNjefuGvjlH3+MS+R7VYxD d+sakdRMIGB0UmPFiphlQSCfa4Fa3YpcEBdf8= MIME-Version: 1.0 Received: by 10.68.213.41 with SMTP id np9mr144706373pbc.71.1325717788366; Wed, 04 Jan 2012 14:56:28 -0800 (PST) Received: by 10.143.67.21 with HTTP; Wed, 4 Jan 2012 14:56:28 -0800 (PST) In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B37B11E@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: <3C8B8B8F-6B08-43DE-AF8B-5FF37B087A5F@cisco.com> <9B57C850BB53634CACEC56EF4853FF653B37B11E@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Date: Wed, 4 Jan 2012 14:56:28 -0800 Message-ID: From: Cameron Byrne To: Dave Thaler Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops v6ops WG , Behave Chairs , "draft-donley-behave-deterministic-cgn@tools.ietf.org" Subject: Re: [v6ops] Please review draft-donley-behave-deterministic-cgn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:56:29 -0000 On Wed, Jan 4, 2012 at 2:27 PM, Dave Thaler wrote: > Yes operational commentary would be very welcome. > OK then. As someone who has operated LSN/CGN before such terms were used, i feel qualified to say that we do not need this function. Others may find it useful, but not my network. Regarding port usage, it can be north of 1,000 ports simultaneously. Depends on the user, it's very bursty. The trend is more and more ports. Regarding logging, my CGN does not have this problem and does not need this solution. Regarding is it deploy-able? I don't think so. "You cannot get there from here". If you are following your ARIN policies and are 80% to 100% utilizing your allocated blocks, how do you get to this model of putting your users behind these bounded static allocations? It seems like there is a high barrier to entry here, that is not achievable for the target audience of IPv4 constrained networks. And if you want geographic redundancy from N locations, you must cut your address allocation by 1/N? This is yet another IPv4 life support effort that i would like to see go away. CB From fred@cisco.com Wed Jan 4 15:18:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7594611E8118 for ; Wed, 4 Jan 2012 15:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.132 X-Spam-Level: X-Spam-Status: No, score=-106.132 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfcuH35D6lmE for ; Wed, 4 Jan 2012 15:18:33 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEF811E8112 for ; Wed, 4 Jan 2012 15:18:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3670; q=dns/txt; s=iport; t=1325719113; x=1326928713; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=wk44NCGRiGcBojC7qY36333p2cnnwVeuPP5V+JV5QFI=; b=Z7gbNVfMt4i37k+llWlBA0YBxavTqyNQrrSS0E9Fudk1X44zCqB3QvXo XC+9RO7x1k9BFmdp2n8NCmigV3heYDN75FhBXbuzU4ZUSqFuvW2axuDLJ fiffVZ0HYD6dPbFGhBvyZWFWwNsBAW7vBXCKsAxzUALgridgj/Ictojil s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An4AAKTdBE+rRDoG/2dsb2JhbABDFoFvmiKQRYEFgXIBAQECAQEBAQEPASctBwsFBwQLEQQBAQEnBycfCQgGEyKHWAiXDwGeBossYwSIOIxMhU+NBg X-IronPort-AV: E=Sophos;i="4.71,458,1320624000"; d="scan'208";a="23775817" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 04 Jan 2012 23:18:33 +0000 Received: from stealth-10-32-244-220.cisco.com (stealth-10-32-244-220.cisco.com [10.32.244.220]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q04NIW8f001460; Wed, 4 Jan 2012 23:18:32 GMT Received: from [127.0.0.1] by stealth-10-32-244-220.cisco.com (PGP Universal service); Wed, 04 Jan 2012 15:18:32 -0800 X-PGP-Universal: processed; by stealth-10-32-244-220.cisco.com on Wed, 04 Jan 2012 15:18:32 -0800 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4F04D370.7030403@joelhalpern.com> Date: Wed, 4 Jan 2012 15:18:20 -0800 Message-Id: References: <3C8B8B8F-6B08-43DE-AF8B-5FF37B087A5F@cisco.com> <9B57C850BB53634CACEC56EF4853FF653B37B11E@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4F04D370.7030403@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "draft-donley-behave-deterministic-cgn@tools.ietf.org" , v6ops v6ops WG , Behave Chairs , Dave Thaler Subject: Re: [v6ops] Please review draft-donley-behave-deterministic-cgn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 23:18:34 -0000 On Jan 4, 2012, at 2:32 PM, Joel M. Halpern wrote: > When I asked on operator about the port distribution, their answer was = somewhat different. > What they said was that when the users are idle, they don't use many = ports. But when the user is busy, they use a lot of ports. > This makes repeated, largeish, block allocation sensible, but makes = pre-allocation of a small number, and then individual allocation = thereafter, a bad strategy, as it will basically log as much as current. >=20 > I do not have access to any research results to disambiguate these two = reports. Chris should step in here.=20 https://www.ietf.org/proceedings/82/slides/behave-5.pdf, quoting http://www.wand.net.nz/~salcock/someisp/flow_counting/result_page.html also referenced by RFC 6269 In the wand.net.nz HTML, look specifically for "mean number of peak = sessions for active subscribers only for each 30 minute period"; the = HTML doesn't have tags that would allow me to simply get you there. I suspect that Chris/WAND and your service provider might be defining = "user" and "a lot" differently. The Waikato numbers are very likely = typical of a residential network behind a NAT - in a home, even if = several computers are in use, it's unlikely that everyone in the home is = web surfing during the same minute. Common browsers usually limit the = number of TCPs they open in parallel to something like 2 or 4, and those = sessions usually stay open single digit numbers of seconds; this says = that in a typical residential network, they see 2-4 computers = simultaneously doing that, for a peak of 4-8 TCP sessions simultaneously = active. That would be very surprising in a corporate network, but makes = sense for residential network. Is the service provider you asked talking about corporate subscribers? > Yours, > Joel >=20 > On 1/4/2012 5:27 PM, Dave Thaler wrote: >> Yes operational commentary would be very welcome. >>=20 >> Also FYI, the author of the draft has declared IPR on it: >> https://datatracker.ietf.org/ipr/1617/ >>=20 >> -Dave >>=20 >> -----Original Message----- >> From: Fred Baker [mailto:fred@cisco.com] >> Sent: Tuesday, October 11, 2011 6:52 AM >> To: v6ops v6ops WG >> Cc: Behave Chairs; = draft-donley-behave-deterministic-cgn@tools.ietf.org >> Subject: Please review draft-donley-behave-deterministic-cgn >>=20 >> Operators subject to law enforcement subpoenas and using Carrier = Grade NAT are having difficulties with the syslog rate for = per-connection logging. Chris Donley has proposed a simplification; the = provider allocates a deterministic set of source ports to his = subscribers, and only needs to log exceptions. Research in the area = suggests that usage of source ports is pareto distributed; a typical = user has a requirement on the order of 4 port numbers in simultaneous = use (median), but port scans and other large volume uses drive the = average quite a bit higher. >>=20 >> They haven't asked for it, but I suspect the behave chairs would = appreciate operational commentary on the draft. >>=20 >> http://tools.ietf.org/html/draft-donley-behave-deterministic-cgn >> "Deterministic Address Mapping to Reduce Logging in Carrier Grade = NATs", >> Chris Donley, Chris Grundemann, Vikas Sarawat, Karthik Sundaresan, >> 26-Sep-11 >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From joelja@bogus.com Wed Jan 4 16:15:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3361F0C49 for ; Wed, 4 Jan 2012 16:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNB3pHGhfqsV for ; Wed, 4 Jan 2012 16:15:39 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3941F0C48 for ; Wed, 4 Jan 2012 16:15:39 -0800 (PST) Received: from Joels-MacBook-Pro.local (host-64-47-136-190.masergy.com [64.47.136.190]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q050FZ7O031836 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 5 Jan 2012 00:15:36 GMT (envelope-from joelja@bogus.com) Message-ID: <4F04EBA2.2060406@bogus.com> Date: Wed, 04 Jan 2012 16:15:30 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Fred Baker References: <3C8B8B8F-6B08-43DE-AF8B-5FF37B087A5F@cisco.com> <9B57C850BB53634CACEC56EF4853FF653B37B11E@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4F04D370.7030403@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 05 Jan 2012 00:15:37 +0000 (UTC) Cc: Dave Thaler , v6ops v6ops WG , Behave Chairs , "draft-donley-behave-deterministic-cgn@tools.ietf.org" Subject: Re: [v6ops] Please review draft-donley-behave-deterministic-cgn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 00:15:40 -0000 On 1/4/12 15:18 , Fred Baker wrote: > > On Jan 4, 2012, at 2:32 PM, Joel M. Halpern wrote: > >> When I asked on operator about the port distribution, their answer >> was somewhat different. What they said was that when the users are >> idle, they don't use many ports. But when the user is busy, they >> use a lot of ports. This makes repeated, largeish, block allocation >> sensible, but makes pre-allocation of a small number, and then >> individual allocation thereafter, a bad strategy, as it will >> basically log as much as current. >> >> I do not have access to any research results to disambiguate these >> two reports. > > Chris should step in here. > > https://www.ietf.org/proceedings/82/slides/behave-5.pdf, quoting > http://www.wand.net.nz/~salcock/someisp/flow_counting/result_page.html > > also referenced by RFC 6269 > > In the wand.net.nz HTML, look specifically for "mean number of peak > sessions for active subscribers only for each 30 minute period"; the > HTML doesn't have tags that would allow me to simply get you there. > > I suspect that Chris/WAND and your service provider might be defining > "user" and "a lot" differently. The Waikato numbers are very likely > typical of a residential network behind a NAT - in a home, even if > several computers are in use, it's unlikely that everyone in the home > is web surfing during the same minute. Common browsers usually limit > the number of TCPs they open in parallel to something like 2 or 4, per page... pardon my the lack of regex foo. as mostly idle mac says the following. Joels-MacBook-Pro:~ jjaeggli$ netstat -ln |egrep '(80|443)' | grep EST| wc -l 74 20 minutes later it says: Joels-MacBook-Pro:~ jjaeggli$ netstat -ln |egrep '(80|443)' | grep EST| wc -l 58 your facebook page, and gmail and ap foo are going to hold those connections open forever if they can. > and those sessions usually stay open single digit numbers of seconds; > this says that in a typical residential network, they see 2-4 > computers simultaneously doing that, for a peak of 4-8 TCP sessions > simultaneously active. That would be very surprising in a corporate > network, but makes sense for residential network. > > Is the service provider you asked talking about corporate > subscribers? > >> Yours, Joel >> >> On 1/4/2012 5:27 PM, Dave Thaler wrote: >>> Yes operational commentary would be very welcome. >>> >>> Also FYI, the author of the draft has declared IPR on it: >>> https://datatracker.ietf.org/ipr/1617/ >>> >>> -Dave >>> >>> -----Original Message----- From: Fred Baker >>> [mailto:fred@cisco.com] Sent: Tuesday, October 11, 2011 6:52 AM >>> To: v6ops v6ops WG Cc: Behave Chairs; >>> draft-donley-behave-deterministic-cgn@tools.ietf.org Subject: >>> Please review draft-donley-behave-deterministic-cgn >>> >>> Operators subject to law enforcement subpoenas and using Carrier >>> Grade NAT are having difficulties with the syslog rate for >>> per-connection logging. Chris Donley has proposed a >>> simplification; the provider allocates a deterministic set of >>> source ports to his subscribers, and only needs to log >>> exceptions. Research in the area suggests that usage of source >>> ports is pareto distributed; a typical user has a requirement on >>> the order of 4 port numbers in simultaneous use (median), but >>> port scans and other large volume uses drive the average quite a >>> bit higher. >>> >>> They haven't asked for it, but I suspect the behave chairs would >>> appreciate operational commentary on the draft. >>> >>> http://tools.ietf.org/html/draft-donley-behave-deterministic-cgn >>> "Deterministic Address Mapping to Reduce Logging in Carrier Grade >>> NATs", Chris Donley, Chris Grundemann, Vikas Sarawat, Karthik >>> Sundaresan, 26-Sep-11 >>> >>> >>> >>> _______________________________________________ v6ops mailing >>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From fred@cisco.com Wed Jan 4 16:38:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F396C11E80EA for ; Wed, 4 Jan 2012 16:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.419 X-Spam-Level: X-Spam-Status: No, score=-106.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irScVdL8PWGC for ; Wed, 4 Jan 2012 16:38:25 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFA511E80D7 for ; Wed, 4 Jan 2012 16:38:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1460; q=dns/txt; s=iport; t=1325723905; x=1326933505; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=6ZWmeJYJa4AkYv/j4KVStXcJ4i5ThqA81ZMy/aYQukQ=; b=EadS4nPXBx6ByEdHaXam0sn31/v7aIgvd1n1pJho5l8BqirQFZ9l0sHX iw5e5uGcP+hcHL9fYM21gBR3VvPWzvWbX/FIx5rEtVo4iAndr77BgLenB nSsRN9ahgZ26UtAJ/7PBpmCg0h8tbhs8fATqqpiiUyU87ai35FCN9FFWh 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAPrvBE+rRDoI/2dsb2JhbABDggWqZ4EFgXIBAQEDARIBJz8QC0ZXBiwJh1iXIAGeA4ssYwSIOIcIhUSFT40G X-IronPort-AV: E=Sophos;i="4.71,459,1320624000"; d="scan'208";a="23790251" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 05 Jan 2012 00:38:25 +0000 Received: from stealth-10-32-244-220.cisco.com (stealth-10-32-244-220.cisco.com [10.32.244.220]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q050cOl8023516; Thu, 5 Jan 2012 00:38:24 GMT Received: from [127.0.0.1] by stealth-10-32-244-220.cisco.com (PGP Universal service); Wed, 04 Jan 2012 16:38:25 -0800 X-PGP-Universal: processed; by stealth-10-32-244-220.cisco.com on Wed, 04 Jan 2012 16:38:25 -0800 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4F04EBA2.2060406@bogus.com> Date: Wed, 4 Jan 2012 16:38:13 -0800 Message-Id: <52CEB56A-A831-4979-9E9E-5FEBCAB1D3CC@cisco.com> References: <3C8B8B8F-6B08-43DE-AF8B-5FF37B087A5F@cisco.com> <9B57C850BB53634CACEC56EF4853FF653B37B11E@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4F04D370.7030403@joelhalpern.com> <4F04EBA2.2060406@bogus.com> To: Joel jaeggli X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Dave Thaler , v6ops v6ops WG , Behave Chairs , "draft-donley-behave-deterministic-cgn@tools.ietf.org" Subject: Re: [v6ops] Please review draft-donley-behave-deterministic-cgn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 00:38:26 -0000 On Jan 4, 2012, at 4:15 PM, Joel jaeggli wrote: >> I suspect that Chris/WAND and your service provider might be defining >> "user" and "a lot" differently. The Waikato numbers are very likely >> typical of a residential network behind a NAT - in a home, even if >> several computers are in use, it's unlikely that everyone in the home >> is web surfing during the same minute. Common browsers usually limit >> the number of TCPs they open in parallel to something like 2 or 4, >=20 > per page... pardon my the lack of regex foo. >=20 > as mostly idle mac says the following. >=20 > Joels-MacBook-Pro:~ jjaeggli$ netstat -ln |egrep '(80|443)' | grep = EST| > wc -l > 74 >=20 > 20 minutes later it says: >=20 > Joels-MacBook-Pro:~ jjaeggli$ netstat -ln |egrep '(80|443)' | grep = EST| > wc -l > 58 >=20 > your facebook page, and gmail and ap foo are going to hold those > connections open forever if they can. OK. Let's compromise at 128. That's bigger than your or WAND's numbers = (BTW, I don't leave a FB or GMail page open; neither do the other big = users in my life. We close applications we're not using, and gmail comes = to my mail tool using POP). Define "big". We can theoretically have 512=3D2^(16-7) subscribers share = a single address. Issues, yes. 512 subscribers per address... a whole lot more than we = have now. And for anything else, there's MasterCard. Oops, wrong commercial...= From fgont@si6networks.com Wed Jan 4 16:59:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74CC721F85AF for ; Wed, 4 Jan 2012 16:59:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.359 X-Spam-Level: X-Spam-Status: No, score=-0.359 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUC-3T8thCPf for ; Wed, 4 Jan 2012 16:59:07 -0800 (PST) Received: from srv01.bbserve.nl (srv01.bbserve.nl [46.21.160.232]) by ietfa.amsl.com (Postfix) with ESMTP id E502B21F85AD for ; Wed, 4 Jan 2012 16:59:06 -0800 (PST) Received: from [190.48.252.193] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RibfV-0003hg-4c; Thu, 05 Jan 2012 01:58:57 +0100 Message-ID: <4F04F5CA.6010802@si6networks.com> Date: Wed, 04 Jan 2012 21:58:50 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: IPv6 Operations X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [v6ops] Revised I-D: Advice on RA-Guard Implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 00:59:07 -0000 Folks, We've published the IETF I-D "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)". It is available at: This I-D is based on our original I-D draft-gont-v6ops-ra-guard-evasion-01, but now focuses on providing advice to RA-Guard implementations, rather than on the evasion techniques that have been found effective against most popular implementations of RA-Guard. Producing effective RA-Guard implementations is important to provide feature parity with similar mitigation techniques already available and employed in the IPv4 world. Any feedback will be greatly appreciated. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From marc.blanchet@viagenie.ca Wed Jan 4 17:26:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99BF11E80DC for ; Wed, 4 Jan 2012 17:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.794 X-Spam-Level: X-Spam-Status: No, score=-101.794 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIfpvNUeeVVp for ; Wed, 4 Jan 2012 17:26:29 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id E20D311E80DB for ; Wed, 4 Jan 2012 17:26:17 -0800 (PST) Received: from [IPv6:2607:fa48:6e6b:c280:d5b7:6481:4188:3855] (unknown [IPv6:2607:fa48:6e6b:c280:d5b7:6481:4188:3855]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 492BE21F4A; Wed, 4 Jan 2012 20:25:47 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Marc Blanchet In-Reply-To: <4F04F5CA.6010802@si6networks.com> Date: Wed, 4 Jan 2012 20:25:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F04F5CA.6010802@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1251.1) Cc: IPv6 Operations Subject: Re: [v6ops] Revised I-D: Advice on RA-Guard Implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 01:26:29 -0000 - how much is this really about RA Guard?=20 - my summary is that whatever device needs to inspect XYZ type packet = before doing some processing, make sure to look at extension headers = (carefully) since they may be obscuring the data. Marc. Le 2012-01-04 =E0 19:58, Fernando Gont a =E9crit : > Folks, >=20 > We've published the IETF I-D "Implementation Advice for IPv6 Router > Advertisement Guard (RA-Guard)". It is available at: > = >=20 > This I-D is based on our original I-D > draft-gont-v6ops-ra-guard-evasion-01, but now focuses on providing > advice to RA-Guard implementations, rather than on the evasion > techniques that have been found effective against most popular > implementations of RA-Guard. >=20 > Producing effective RA-Guard implementations is important to provide > feature parity with similar mitigation techniques already available = and > employed in the IPv4 world. >=20 > Any feedback will be greatly appreciated. >=20 > Thanks! >=20 > Best regards, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fgont@si6networks.com Wed Jan 4 17:59:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE84621F86B2 for ; Wed, 4 Jan 2012 17:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpVsWdPDNoTV for ; Wed, 4 Jan 2012 17:59:50 -0800 (PST) Received: from srv01.bbserve.nl (srv01.bbserve.nl [46.21.160.232]) by ietfa.amsl.com (Postfix) with ESMTP id 5729B21F86AF for ; Wed, 4 Jan 2012 17:59:49 -0800 (PST) Received: from [190.48.252.193] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Ricbx-00041p-DQ; Thu, 05 Jan 2012 02:59:22 +0100 Message-ID: <4F0503EE.10301@si6networks.com> Date: Wed, 04 Jan 2012 22:59:10 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Marc Blanchet References: <4F04F5CA.6010802@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] Revised I-D: Advice on RA-Guard Implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 01:59:50 -0000 Hi, Mark, On 01/04/2012 10:25 PM, Marc Blanchet wrote: > - how much is this really about RA Guard? - my summary is that > whatever device needs to inspect XYZ type packet before doing some > processing, make sure to look at extension headers (carefully) since > they may be obscuring the data. 1) RA-Guard implements packet-filtering at layer-2 (rather than layer-3), so the trivial answer "reassemble, filter, and forward" does not apply here. Otoh, Layer-3 devices need to take care of tunnels.. but that doesn't apply to RA-Guard. In summary, the constraints are very different. (an I-D on firewall filtering could easily be 10x more complex than this one). 2) At least one popular RA-Guard implementation is vulnerable to these issues. Fixing these issues is key to provide FHS (First Hop Security) feature parity between IPv4 and IPv6. 3) This WG published two documents on RA-Guard (RFC6104 nad RFC6105), which I'd say indicated that this is an important feature. Given that the outcome has probalby not been the expected, it seems sensible for the IETF to provide advice on how to get RA-Guard "right". Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From cb.list6@gmail.com Wed Jan 4 18:44:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FB611E8080 for ; Wed, 4 Jan 2012 18:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mirUuBVs0IMj for ; Wed, 4 Jan 2012 18:44:45 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3099E11E8072 for ; Wed, 4 Jan 2012 18:43:11 -0800 (PST) Received: by pbdd12 with SMTP id d12so77651pbd.31 for ; Wed, 04 Jan 2012 18:43:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f4McDMS8Wun5rwFWwAX+MJQxLb/b98Kpfm2EQA57Mlw=; b=B/3o9Az4rSZ8bg9Se2qOXhu+SX7JHPVgSrcO1DoA9JoK8iyaqVVR6j283ZofIyQVze 2KRnDZ62+Y8Q42uJLXiSr7eatW/DiepGyFOLKvfhpdfK31MJBzIdRw4J4BWGswySz4iu 0lziizGQngugtXMUJq8EI6AW/nrszq2fMxXYo= MIME-Version: 1.0 Received: by 10.68.212.232 with SMTP id nn8mr631239pbc.105.1325731390914; Wed, 04 Jan 2012 18:43:10 -0800 (PST) Received: by 10.143.67.21 with HTTP; Wed, 4 Jan 2012 18:43:10 -0800 (PST) Received: by 10.143.67.21 with HTTP; Wed, 4 Jan 2012 18:43:10 -0800 (PST) In-Reply-To: <52CEB56A-A831-4979-9E9E-5FEBCAB1D3CC@cisco.com> References: <3C8B8B8F-6B08-43DE-AF8B-5FF37B087A5F@cisco.com> <9B57C850BB53634CACEC56EF4853FF653B37B11E@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4F04D370.7030403@joelhalpern.com> <4F04EBA2.2060406@bogus.com> <52CEB56A-A831-4979-9E9E-5FEBCAB1D3CC@cisco.com> Date: Wed, 4 Jan 2012 18:43:10 -0800 Message-ID: From: Cameron Byrne To: Fred Baker Content-Type: multipart/alternative; boundary=e89a8ffba8a59f818904b5bee4c5 Cc: v6ops v6ops WG , Dave Thaler , Behave Chairs , "draft-donley-behave-deterministic-cgn@tools.ietf.org" Subject: Re: [v6ops] Please review draft-donley-behave-deterministic-cgn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 02:44:45 -0000 --e89a8ffba8a59f818904b5bee4c5 Content-Type: text/plain; charset=ISO-8859-1 On Jan 4, 2012 4:38 PM, "Fred Baker" wrote: > > > On Jan 4, 2012, at 4:15 PM, Joel jaeggli wrote: > > >> I suspect that Chris/WAND and your service provider might be defining > >> "user" and "a lot" differently. The Waikato numbers are very likely > >> typical of a residential network behind a NAT - in a home, even if > >> several computers are in use, it's unlikely that everyone in the home > >> is web surfing during the same minute. Common browsers usually limit > >> the number of TCPs they open in parallel to something like 2 or 4, > > > > per page... pardon my the lack of regex foo. > > > > as mostly idle mac says the following. > > > > Joels-MacBook-Pro:~ jjaeggli$ netstat -ln |egrep '(80|443)' | grep EST| > > wc -l > > 74 > > > > 20 minutes later it says: > > > > Joels-MacBook-Pro:~ jjaeggli$ netstat -ln |egrep '(80|443)' | grep EST| > > wc -l > > 58 > > > > your facebook page, and gmail and ap foo are going to hold those > > connections open forever if they can. > > > OK. Let's compromise at 128. That's bigger than your or WAND's numbers (BTW, I don't leave a FB or GMail page open; neither do the other big users in my life. We close applications we're not using, and gmail comes to my mail tool using POP). > > Define "big". We can theoretically have 512=2^(16-7) subscribers share a single address. > > Issues, yes. 512 subscribers per address... a whole lot more than we have now. > Who is we? I have 30+ million subscribers and 100k ipv4. Cb > And for anything else, there's MasterCard. Oops, wrong commercial... > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --e89a8ffba8a59f818904b5bee4c5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jan 4, 2012 4:38 PM, "Fred Baker" <fred@cisco.com> wrote:
>
>
> On Jan 4, 2012, at 4:15 PM, Joel jaeggli wrote:
>
> >> I suspect that Chris/WAND and your service provider might be = defining
> >> "user" and "a lot" differently. The Waika= to numbers are very likely
> >> typical of a residential network behind a NAT - in a home, ev= en if
> >> several computers are in use, it's unlikely that everyone= in the home
> >> is web surfing during the same minute. Common browsers usuall= y limit
> >> the number of TCPs they open in parallel to something like 2 = or 4,
> >
> > per page... pardon my the lack of regex foo.
> >
> > as mostly idle mac says the following.
> >
> > Joels-MacBook-Pro:~ jjaeggli$ netstat -ln |egrep '(80|443)= 9; | grep EST|
> > wc -l
> > =A0 =A0 =A074
> >
> > 20 minutes later it says:
> >
> > Joels-MacBook-Pro:~ jjaeggli$ netstat -ln |egrep '(80|443)= 9; | grep EST|
> > wc -l
> > =A0 =A0 =A058
> >
> > your facebook page, and gmail and =A0ap foo are going to hold tho= se
> > connections open forever if they can.
>
>
> OK. Let's compromise at 128. That's bigger than your or WAND&#= 39;s numbers (BTW, I don't leave a FB or GMail page open; neither do th= e other big users in my life. We close applications we're not using, an= d gmail comes to my mail tool using POP).
>
> Define "big". We can theoretically have 512=3D2^(16-7) subsc= ribers share a single address.
>
> Issues, yes. 512 subscribers per address... a whole lot more than we h= ave now.
>

Who is we? I have 30+ million subscribers and 100k ipv4.

Cb

> And for anything else, there's MasterCard. Oops, wrong commerci= al...
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--e89a8ffba8a59f818904b5bee4c5-- From jmh@joelhalpern.com Thu Jan 5 00:08:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2DE21F865C for ; Thu, 5 Jan 2012 00:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.929 X-Spam-Level: X-Spam-Status: No, score=-101.929 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2qOcBkEovoT for ; Thu, 5 Jan 2012 00:08:33 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 23D7E21F864F for ; Thu, 5 Jan 2012 00:08:33 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 01345CCFE4 for ; Thu, 5 Jan 2012 00:08:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 174621C08CD; Thu, 5 Jan 2012 00:08:31 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-89.clppva.btas.verizon.net [71.161.50.89]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id CA2A61C011D; Thu, 5 Jan 2012 00:08:29 -0800 (PST) Message-ID: <4F055A81.4070100@joelhalpern.com> Date: Thu, 05 Jan 2012 03:08:33 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Fred Baker References: <3C8B8B8F-6B08-43DE-AF8B-5FF37B087A5F@cisco.com> <9B57C850BB53634CACEC56EF4853FF653B37B11E@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4F04D370.7030403@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-donley-behave-deterministic-cgn@tools.ietf.org" , v6ops v6ops WG , Behave Chairs , Dave Thaler Subject: Re: [v6ops] Please review draft-donley-behave-deterministic-cgn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 08:08:34 -0000 The operator was a residential operator, reporting onnot for attribution on observed residential patterns. (I had asked because I was looking at some ideas loosely related to the ones Chris is proposing.) Apparently, it has to do with the number of connections that various common applications have taken to opening, within the browser context. Not being an applications guy, I took his word on that front. I will look at the wand data. Yours, Joel On 1/4/2012 6:18 PM, Fred Baker wrote: > > On Jan 4, 2012, at 2:32 PM, Joel M. Halpern wrote: > >> When I asked on operator about the port distribution, their answer was somewhat different. >> What they said was that when the users are idle, they don't use many ports. But when the user is busy, they use a lot of ports. >> This makes repeated, largeish, block allocation sensible, but makes pre-allocation of a small number, and then individual allocation thereafter, a bad strategy, as it will basically log as much as current. >> >> I do not have access to any research results to disambiguate these two reports. > > Chris should step in here. > > https://www.ietf.org/proceedings/82/slides/behave-5.pdf, quoting > http://www.wand.net.nz/~salcock/someisp/flow_counting/result_page.html > also referenced by RFC 6269 > > In the wand.net.nz HTML, look specifically for "mean number of peak sessions for active subscribers only for each 30 minute period"; the HTML doesn't have tags that would allow me to simply get you there. > > I suspect that Chris/WAND and your service provider might be defining "user" and "a lot" differently. The Waikato numbers are very likely typical of a residential network behind a NAT - in a home, even if several computers are in use, it's unlikely that everyone in the home is web surfing during the same minute. Common browsers usually limit the number of TCPs they open in parallel to something like 2 or 4, and those sessions usually stay open single digit numbers of seconds; this says that in a typical residential network, they see 2-4 computers simultaneously doing that, for a peak of 4-8 TCP sessions simultaneously active. That would be very surprising in a corporate network, but makes sense for residential network. > > Is the service provider you asked talking about corporate subscribers? > >> Yours, >> Joel >> >> On 1/4/2012 5:27 PM, Dave Thaler wrote: >>> Yes operational commentary would be very welcome. >>> >>> Also FYI, the author of the draft has declared IPR on it: >>> https://datatracker.ietf.org/ipr/1617/ >>> >>> -Dave >>> >>> -----Original Message----- >>> From: Fred Baker [mailto:fred@cisco.com] >>> Sent: Tuesday, October 11, 2011 6:52 AM >>> To: v6ops v6ops WG >>> Cc: Behave Chairs; draft-donley-behave-deterministic-cgn@tools.ietf.org >>> Subject: Please review draft-donley-behave-deterministic-cgn >>> >>> Operators subject to law enforcement subpoenas and using Carrier Grade NAT are having difficulties with the syslog rate for per-connection logging. Chris Donley has proposed a simplification; the provider allocates a deterministic set of source ports to his subscribers, and only needs to log exceptions. Research in the area suggests that usage of source ports is pareto distributed; a typical user has a requirement on the order of 4 port numbers in simultaneous use (median), but port scans and other large volume uses drive the average quite a bit higher. >>> >>> They haven't asked for it, but I suspect the behave chairs would appreciate operational commentary on the draft. >>> >>> http://tools.ietf.org/html/draft-donley-behave-deterministic-cgn >>> "Deterministic Address Mapping to Reduce Logging in Carrier Grade NATs", >>> Chris Donley, Chris Grundemann, Vikas Sarawat, Karthik Sundaresan, >>> 26-Sep-11 >>> >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > From joelja@bogus.com Thu Jan 5 00:14:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAF111E8073 for ; Thu, 5 Jan 2012 00:14:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrYYE1wunMUN for ; Thu, 5 Jan 2012 00:14:23 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5595A21F865C for ; Thu, 5 Jan 2012 00:14:19 -0800 (PST) Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q058EGKR040672 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 5 Jan 2012 08:14:16 GMT (envelope-from joelja@bogus.com) Message-ID: <4F055BD8.2030303@bogus.com> Date: Thu, 05 Jan 2012 00:14:16 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Fred Baker References: <3C8B8B8F-6B08-43DE-AF8B-5FF37B087A5F@cisco.com> <9B57C850BB53634CACEC56EF4853FF653B37B11E@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4F04D370.7030403@joelhalpern.com> <4F04EBA2.2060406@bogus.com> <52CEB56A-A831-4979-9E9E-5FEBCAB1D3CC@cisco.com> In-Reply-To: <52CEB56A-A831-4979-9E9E-5FEBCAB1D3CC@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 05 Jan 2012 08:14:17 +0000 (UTC) Cc: Dave Thaler , v6ops v6ops WG , Behave Chairs , "draft-donley-behave-deterministic-cgn@tools.ietf.org" Subject: Re: [v6ops] Please review draft-donley-behave-deterministic-cgn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 08:14:24 -0000 On 1/4/12 16:38 , Fred Baker wrote: > > On Jan 4, 2012, at 4:15 PM, Joel jaeggli wrote: > >>> I suspect that Chris/WAND and your service provider might be defining >>> "user" and "a lot" differently. The Waikato numbers are very likely >>> typical of a residential network behind a NAT - in a home, even if >>> several computers are in use, it's unlikely that everyone in the home >>> is web surfing during the same minute. Common browsers usually limit >>> the number of TCPs they open in parallel to something like 2 or 4, >> >> per page... pardon my the lack of regex foo. >> >> as mostly idle mac says the following. >> >> Joels-MacBook-Pro:~ jjaeggli$ netstat -ln |egrep '(80|443)' | grep EST| >> wc -l >> 74 >> >> 20 minutes later it says: >> >> Joels-MacBook-Pro:~ jjaeggli$ netstat -ln |egrep '(80|443)' | grep EST| >> wc -l >> 58 >> >> your facebook page, and gmail and ap foo are going to hold those >> connections open forever if they can. > > > OK. Let's compromise at 128. That's bigger than your or WAND's numbers (BTW, I don't leave a FB or GMail page open; neither do the other big users in my life. We close applications we're not using, and gmail comes to my mail tool using POP). > > Define "big". We can theoretically have 512=2^(16-7) subscribers share a single address. > > Issues, yes. 512 subscribers per address... a whole lot more than we have now. I agree that's more realistic. whether it's enough to make the model work I guess is something I'm not convinced of... I've got enough experience with non-overloaded nats in non-residential circumstances that I know they can suck up more ip addresses than I have available to me at the time. > And for anything else, there's MasterCard. Oops, wrong commercial... > From v6ops@globis.net Thu Jan 5 05:32:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BCD21F8822 for ; Thu, 5 Jan 2012 05:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uflfMK6o2fcJ for ; Thu, 5 Jan 2012 05:32:04 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED4321F881C for ; Thu, 5 Jan 2012 05:32:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 17CBB870088; Thu, 5 Jan 2012 14:32:01 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net 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 6oVF1DL4+1Fk; Thu, 5 Jan 2012 14:31:48 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 791A287007F; Thu, 5 Jan 2012 14:31:48 +0100 (CET) Message-ID: <4F05A644.3080905@globis.net> Date: Thu, 05 Jan 2012 14:31:48 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Cameron Byrne References: <3C8B8B8F-6B08-43DE-AF8B-5FF37B087A5F@cisco.com> <9B57C850BB53634CACEC56EF4853FF653B37B11E@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070602090802050909010408" Cc: "draft-donley-behave-deterministic-cgn@tools.ietf.org" , v6ops v6ops WG , Behave Chairs , Dave Thaler Subject: Re: [v6ops] Please review draft-donley-behave-deterministic-cgn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 13:32:05 -0000 This is a multi-part message in MIME format. --------------070602090802050909010408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IMVH operational experience of processing firewall/ NAT/ netflow logs, any solution that relies on a certain fixed statistical distribution of mean port usage per user for it's long term success is likely to fail, simply because there is no standard behavior for how many ports an individual machine or user or household or application should or may open simultaneously. Applications change. Traffic patterns change. Port usage varies greatly per machine over time, and as Cameron says, can be bursty. A scheme more like those used to avoid excessive disk fragmentation might be more appropriate for bursty allocations that extend far above the long-term mean. This could be based on "allocation groups" of blocks of outside ports in a range, which are then dynamically associated on the fly with individual inside port mappings. Only a single record containing the outside IP address and outside port range plus the the inside IP address/UID (not the individual inside ports) would have to be logged in order to be able trace back from an outside session to a unique identifiable source covering many inside sessions. Use of allocation groups could also allow a certain amount of parallelism in the allocation process of establishing NAT mappings. And it might avoid intellectual property issues, due to prior art. I can't see any definition in the draft of appropriate behavior when the Maximum ports per user (M) parameter is exceeded. Should the CGN drop user traffic if it cannot be logged? Where's the standard that says an individual IPv4 address cannot source more than 5040 ports simultaneously (over the period of the CGN NAT association timeout)? I know many CGN manufacturers allow you to create different user profiles, but good luck in retrospectively enforcing such restrictions in a fair use agreement. There should also be a note in Additional Logging Considerations that the CGN operator should check whether this form of CGN logging complies with their local telecommunication data retention law, as the exact requirements for the individual entries in a data traffic log may vary per jurisdiction. Some would seem to require logging the detail of every single session, incuding source and destination address, source and destination port, and protocol. regards, RayH Cameron Byrne wrote: > On Wed, Jan 4, 2012 at 2:27 PM, Dave Thaler wrote: > >> Yes operational commentary would be very welcome. >> >> > > OK then. > > As someone who has operated LSN/CGN before such terms were used, i > feel qualified to say that we do not need this function. Others may > find it useful, but not my network. > > Regarding port usage, it can be north of 1,000 ports simultaneously. > Depends on the user, it's very bursty. The trend is more and more > ports. > > Regarding logging, my CGN does not have this problem and does not need > this solution. > > Regarding is it deploy-able? I don't think so. "You cannot get there > from here". If you are following your ARIN policies and are 80% to > 100% utilizing your allocated blocks, how do you get to this model of > putting your users behind these bounded static allocations? It seems > like there is a high barrier to entry here, that is not achievable for > the target audience of IPv4 constrained networks. > > And if you want geographic redundancy from N locations, you must cut > your address allocation by 1/N? > > This is yet another IPv4 life support effort that i would like to see go away. > > CB > > --------------070602090802050909010408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit IMVH operational experience of processing firewall/ NAT/ netflow logs, any solution that relies on a certain fixed statistical distribution of mean port usage per user for it's long term success is likely to fail, simply because there is no standard behavior for how many ports an individual machine or user or household or application should or may open simultaneously. Applications change. Traffic patterns change. Port usage varies greatly per machine over time, and as Cameron says, can be bursty.

A scheme more like those used to avoid excessive disk fragmentation might be more appropriate for bursty allocations that extend far above the long-term mean. This could be based on "allocation groups" of blocks of outside ports in a range, which are then dynamically associated on the fly with individual inside port mappings. Only a single record containing the outside IP address and outside port range plus the the inside IP address/UID (not the individual inside ports) would have to be logged in order to be able trace back from an outside session to a unique identifiable source covering many inside sessions. Use of allocation groups could also allow a certain amount of parallelism in the allocation process of establishing NAT mappings. And it might avoid intellectual property issues, due to prior art.

I can't see any definition in the draft of appropriate behavior when the Maximum ports per user (M) parameter is exceeded. Should the CGN drop user traffic if it cannot be logged? Where's the standard that says an individual IPv4 address cannot source more than 5040 ports simultaneously (over the period of the CGN NAT association timeout)? I know many CGN manufacturers  allow you to create different user profiles, but good luck in retrospectively enforcing such restrictions in a fair use agreement.

There should also be a note in Additional Logging Considerations that the CGN operator should check whether this form of CGN logging complies with their local telecommunication data retention law, as the exact requirements for the individual entries in a data traffic log may vary per jurisdiction. Some would seem to require logging the detail of every single session, incuding source and destination address, source and destination port, and protocol.

regards,
RayH

Cameron Byrne wrote: 
On Wed, Jan 4, 2012 at 2:27 PM, Dave Thaler <dthaler@microsoft.com> wrote:
  
Yes operational commentary would be very welcome.

    

OK then.

As someone who has operated LSN/CGN before such terms were used, i
feel qualified to say that we do not need this function.  Others may
find it useful, but not my network.

Regarding port usage, it can be north of 1,000 ports simultaneously.
Depends on the user, it's very bursty.  The trend is more and more
ports.

Regarding logging, my CGN does not have this problem and does not need
this solution.

Regarding is it deploy-able?  I don't think so. "You cannot get there
from here".  If you are following your ARIN policies and are 80% to
100% utilizing your allocated blocks, how do you get to this model of
putting your users behind these bounded static allocations?  It seems
like there is a high barrier to entry here, that is not achievable for
the target audience of IPv4 constrained networks.

And if you want geographic redundancy from N locations, you must cut
your address allocation by 1/N?

This is yet another IPv4 life support effort that i would like to see go away.

CB
--------------070602090802050909010408-- From simon.perreault@viagenie.ca Thu Jan 5 05:50:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1E821F881C for ; Thu, 5 Jan 2012 05:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDOC4sKdp2Jm for ; Thu, 5 Jan 2012 05:50:49 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id CEED721F87FF for ; Thu, 5 Jan 2012 05:50:47 -0800 (PST) Received: from banana.viagenie.ca (unknown [IPv6:2620:0:230:c000:92e6:baff:fe57:8a72]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AE98E21BD3 for ; Thu, 5 Jan 2012 08:50:16 -0500 (EST) Message-ID: <4F05AA98.4090400@viagenie.ca> Date: Thu, 05 Jan 2012 08:50:16 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: v6ops@ietf.org References: <4F04F5CA.6010802@si6networks.com> In-Reply-To: <4F04F5CA.6010802@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Revised I-D: Advice on RA-Guard Implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 13:50:50 -0000 Fernando Gont wrote, on 01/04/2012 07:58 PM: > We've published the IETF I-D "Implementation Advice for IPv6 Router > Advertisement Guard (RA-Guard)". It is available at: > Section 3 (implementation advice) does not explicitly mention fragment handling. Is this intentional? Does the advice implicitly apply to fragments? Some clarification is needed IMHO. 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 wesley.george@twcable.com Thu Jan 5 06:16:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864F221F87F8 for ; Thu, 5 Jan 2012 06:16:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.371 X-Spam-Level: X-Spam-Status: No, score=-0.371 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnbNWcqC4wEB for ; Thu, 5 Jan 2012 06:16:23 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id D522521F873E for ; Thu, 5 Jan 2012 06:16:22 -0800 (PST) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.71,460,1320642000"; d="scan'208";a="304024293" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 05 Jan 2012 09:14:45 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Thu, 5 Jan 2012 09:16:02 -0500 From: "George, Wes" To: Cameron Byrne , Dave Thaler Date: Thu, 5 Jan 2012 09:16:01 -0500 Thread-Topic: [v6ops] Please review draft-donley-behave-deterministic-cgn Thread-Index: AczLNCfSzdYmmLYLS8+7YTWRfASigwAevgsg Message-ID: References: <3C8B8B8F-6B08-43DE-AF8B-5FF37B087A5F@cisco.com> <9B57C850BB53634CACEC56EF4853FF653B37B11E@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: v6ops v6ops WG , Behave Chairs , "draft-donley-behave-deterministic-cgn@tools.ietf.org" Subject: Re: [v6ops] Please review draft-donley-behave-deterministic-cgn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 14:16:23 -0000 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Cameron Byrne > Sent: Wednesday, January 04, 2012 5:56 PM > Subject: Re: [v6ops] Please review draft-donley-behave-deterministic- > cgn > > As someone who has operated LSN/CGN before such terms were used, i > feel qualified to say that we do not need this function. Others may > find it useful, but not my network. [WEG] yes, others do need it. We don't have the experience of operating it = yet, but our networks are somewhat different. I'm glad you don't. I wish we= didn't. > > Regarding port usage, it can be north of 1,000 ports simultaneously. > Depends on the user, it's very bursty. The trend is more and more > ports. [WEG] Given that your application is typically one user doing periodic mobi= le web access (NAT44), one could extrapolate that the average residential e= nvironment where each customer has multiple such hosts behind a common devi= ce (NAT444) and longer periods of user activity due to the device format an= d lack of battery life and data cap concerns, the numbers on simultaneous p= ort use will be higher, perhaps linearly based on the number of simultaneou= s users behind the CPE device. > > Regarding logging, my CGN does not have this problem and does not need > this solution. [WEG] That's because IIRC, mobile has other places to log the relationship = between user/device and IP, so addressing abuse/LEA requests can be handled= somewhat differently than it is in a non-mobile network. In a former life,= I remember having variants of this discussion, and it seemed that for the = most part, LEAs haven't figured out that they might care about mobile data = based on the IP address (and port) - the LEA compliance folks in mobility l= ooked at me funny when I asked about it, because all they'd ever gotten was= requests associated with a phone number. We've done the math (based on some assumptions). I'm not at liberty to shar= e specifics, but I can say that worst case if we log every session is *very= * bad - hundreds of terabytes of logging per year. SAN vendors would love u= s. Anything that reduces the logging by orders of magnitude is a big win. I do need to caveat my last statement. I make it assuming that CGN is a for= egone conclusion, so it probably should be deployable, because I do not bel= ieve in the notion of punishing operators by making it difficult in an atte= mpt to prevent people from deploying it. I'd prefer to never have to use th= is, but if I do, it's useful. I view a "win" in this category as being told= , "I'm going to flog you" instead of "I'm going to flog you while forcing y= ou to watch the Twilight movies" -- it simply sucks less than the alternat= ive. Thanks Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From fred@cisco.com Thu Jan 5 06:55:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD0021F87B5 for ; Thu, 5 Jan 2012 06:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDi+vhMNuB+o for ; Thu, 5 Jan 2012 06:55:02 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1433A21F876C for ; Thu, 5 Jan 2012 06:55:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=142; q=dns/txt; s=iport; t=1325775302; x=1326984902; h=date:from:message-id:to:subject:cc; bh=NQVurUKW/es7PtQN9qbVmRpG2hyvdDyudvajLoMjIs4=; b=hqWLYEC+RymWgm/roZQRHn/AY04X1xzOfaLEH9YwrDFzhvQ4Cs9YOrfa JneQ+e36CpCWfRnQ+q9G66Zu+YKkK7+S916meNDqdVCUKCdYcfVuQip/8 G+VVcbGYhawdwicS318E0igvoMGsBR/9XeWr44HeWzR1knoH8P5WAGoJh g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYGAM+4BU+rRDoI/2dsb2JhbABCnHQBhB0Di2iBBYILAWY8LYEKh2CXSQGeDoh3gxoEiDmfIw X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; d="scan'208";a="23950130" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 05 Jan 2012 14:55:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q05Et16K008431; Thu, 5 Jan 2012 14:55:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id q05Et1e24421; Thu, 5 Jan 2012 06:55:01 -0800 (PST) Date: Thu, 5 Jan 2012 06:55:01 -0800 (PST) From: Message-Id: <201201051455.q05Et1e24421@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-gont-v6ops-ra-guard-implementation@tools.ietf.org Subject: [v6ops] new draft: draft-gont-v6ops-ra-guard-implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 14:55:02 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-gont-v6ops-ra-guard-implementation. Please take a look at it and comment. From cb.list6@gmail.com Thu Jan 5 07:33:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C88A421F875F for ; Thu, 5 Jan 2012 07:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zb1mqQcDeeTG for ; Thu, 5 Jan 2012 07:33:29 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id D699F21F8780 for ; Thu, 5 Jan 2012 07:33:22 -0800 (PST) Received: by pbdd12 with SMTP id d12so499748pbd.31 for ; Thu, 05 Jan 2012 07:33:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GIkNZBXcJySldYGgloQdZLM9g2nr6liFdkkVVMFP8lo=; b=SYc3C+QHe8hsoA95kRggV9I8eJpqLRIkeTezl1CE7UhvMo8/57pWDseVeB5pbijnej 4KzvnbSt+h+0Fc36kNp57vkq60juhOGZzy5AWd5fdQuNaX9+L5/zBG43Y2XYjKCUaWpF NfBfCDYsVIrF949UnKsbnfZoI4t80/zUZyP6E= MIME-Version: 1.0 Received: by 10.68.212.232 with SMTP id nn8mr6167360pbc.105.1325777602520; Thu, 05 Jan 2012 07:33:22 -0800 (PST) Received: by 10.143.67.21 with HTTP; Thu, 5 Jan 2012 07:33:22 -0800 (PST) Received: by 10.143.67.21 with HTTP; Thu, 5 Jan 2012 07:33:22 -0800 (PST) In-Reply-To: References: <3C8B8B8F-6B08-43DE-AF8B-5FF37B087A5F@cisco.com> <9B57C850BB53634CACEC56EF4853FF653B37B11E@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 5 Jan 2012 07:33:22 -0800 Message-ID: From: Cameron Byrne To: "George, Wes" Content-Type: multipart/alternative; boundary=e89a8ffba8a50ca5d004b5c9a700 Cc: "draft-donley-behave-deterministic-cgn@tools.ietf.org" , v6ops v6ops WG , Behave Chairs , Dave Thaler Subject: Re: [v6ops] Please review draft-donley-behave-deterministic-cgn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 15:33:30 -0000 --e89a8ffba8a50ca5d004b5c9a700 Content-Type: text/plain; charset=ISO-8859-1 On Jan 5, 2012 6:16 AM, "George, Wes" wrote: > > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > > Of Cameron Byrne > > Sent: Wednesday, January 04, 2012 5:56 PM > > Subject: Re: [v6ops] Please review draft-donley-behave-deterministic- > > cgn > > > > As someone who has operated LSN/CGN before such terms were used, i > > feel qualified to say that we do not need this function. Others may > > find it useful, but not my network. > [WEG] yes, others do need it. We don't have the experience of operating it yet, but our networks are somewhat different. I'm glad you don't. I wish we didn't. > Ack. I said *my* network for just that reason. > > > > Regarding port usage, it can be north of 1,000 ports simultaneously. > > Depends on the user, it's very bursty. The trend is more and more > > ports. > [WEG] Given that your application is typically one user doing periodic mobile web access (NAT44), one could extrapolate that the average residential environment where each customer has multiple such hosts behind a common device (NAT444) and longer periods of user activity due to the device format and lack of battery life and data cap concerns, the numbers on simultaneous port use will be higher, perhaps linearly based on the number of simultaneous users behind the CPE device. > It is always interesting to hear outsiders views of my network. But don't feel burdened to scope and caveat my feedback about how a draft applies to my network or mobile networks. I know it is strange and usual for a mobile operator to participate in the IETF, but it is no longer strange and usual for mobile devices to communicate on the internet. That said, I disagree with your statement above and say the trend is that most devices I ship have mobile hot spot functionality , which is nat444. Thanks Android. Also, the trend is that most phones are connected to many clouds constantly: Gmail, updates, Facebook, twitter, email (@home, @work, @school ...) ...everything is "always on":and "push". Oh. And that "group on" app wants to push you a coupon because you walked into Starbucks. And BBC has breaking news alerts. ... and that all goes via long lived Nat cloud attachment. > > > > Regarding logging, my CGN does not have this problem and does not need > > this solution. > [WEG] That's because IIRC, mobile has other places to log the relationship between user/device and IP, so addressing abuse/LEA requests can be handled somewhat differently than it is in a non-mobile network. In a former life, I remember having variants of this discussion, and it seemed that for the most part, LEAs haven't figured out that they might care about mobile data based on the IP address (and port) - the LEA compliance folks in mobility looked at me funny when I asked about it, because all they'd ever gotten was requests associated with a phone number. > > We've done the math (based on some assumptions). I'm not at liberty to share specifics, but I can say that worst case if we log every session is *very* bad - hundreds of terabytes of logging per year. SAN vendors would love us. Anything that reduces the logging by orders of magnitude is a big win. > I do need to caveat my last statement. I make it assuming that CGN is a foregone conclusion, so it probably should be deployable, because I do not believe in the notion of punishing operators by making it difficult in an attempt to prevent people from deploying it. I'd prefer to never have to use this, but if I do, it's useful. I view a "win" in this category as being told, "I'm going to flog you" instead of "I'm going to flog you while forcing you to watch the Twilight movies" -- it simply sucks less than the alternative. > That's fine for *you*. I am just making it clear that this is not at all appealing in my network. It is not deployable in networks that look my mobile network, and we already do a lot of cgn. Cb > Thanks > Wes George > > This E-mail and any of 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 intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents 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. On Jan 5, 2012 6:16 AM, "George, Wes" wrote: > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > > Of Cameron Byrne > > Sent: Wednesday, January 04, 2012 5:56 PM > > Subject: Re: [v6ops] Please review draft-donley-behave-deterministic- > > cgn > > > > As someone who has operated LSN/CGN before such terms were used, i > > feel qualified to say that we do not need this function. Others may > > find it useful, but not my network. > [WEG] yes, others do need it. We don't have the experience of operating it > yet, but our networks are somewhat different. I'm glad you don't. I wish we > didn't. > > > > > Regarding port usage, it can be north of 1,000 ports simultaneously. > > Depends on the user, it's very bursty. The trend is more and more > > ports. > [WEG] Given that your application is typically one user doing periodic > mobile web access (NAT44), one could extrapolate that the average > residential environment where each customer has multiple such hosts behind > a common device (NAT444) and longer periods of user activity due to the > device format and lack of battery life and data cap concerns, the numbers > on simultaneous port use will be higher, perhaps linearly based on the > number of simultaneous users behind the CPE device. > > > > > Regarding logging, my CGN does not have this problem and does not need > > this solution. > [WEG] That's because IIRC, mobile has other places to log the relationship > between user/device and IP, so addressing abuse/LEA requests can be handled > somewhat differently than it is in a non-mobile network. In a former life, > I remember having variants of this discussion, and it seemed that for the > most part, LEAs haven't figured out that they might care about mobile data > based on the IP address (and port) - the LEA compliance folks in mobility > looked at me funny when I asked about it, because all they'd ever gotten > was requests associated with a phone number. > > We've done the math (based on some assumptions). I'm not at liberty to > share specifics, but I can say that worst case if we log every session is > *very* bad - hundreds of terabytes of logging per year. SAN vendors would > love us. Anything that reduces the logging by orders of magnitude is a big > win. > I do need to caveat my last statement. I make it assuming that CGN is a > foregone conclusion, so it probably should be deployable, because I do not > believe in the notion of punishing operators by making it difficult in an > attempt to prevent people from deploying it. I'd prefer to never have to > use this, but if I do, it's useful. I view a "win" in this category as > being told, "I'm going to flog you" instead of "I'm going to flog you while > forcing you to watch the Twilight movies" -- it simply sucks less than the > alternative. > > Thanks > Wes George > > This E-mail and any of 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 intended recipient of this E-mail, you are hereby notified that > any dissemination, distribution, copying, or action taken in relation to > the contents 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. > --e89a8ffba8a50ca5d004b5c9a700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jan 5, 2012 6:16 AM, "George, Wes" <wesley.george@twcable.com> wrote:
>
> > From: v6ops-bounces@iet= f.org [mailto:v6ops-bounces@i= etf.org] On Behalf
> > Of Cameron Byrne
> > Sent: Wednesday, January 04, 2012 5:56 PM
> > Subject: Re: [v6ops] Please review draft-donley-behave-determinis= tic-
> > cgn
> >
> > As someone who has operated LSN/CGN before such terms were used, = i
> > feel qualified to say that we do not need this function. =A0Other= s may
> > find it useful, but not my network.
> [WEG] yes, others do need it. We don't have the experience of oper= ating it yet, but our networks are somewhat different. I'm glad you don= 't. I wish we didn't.
>

Ack. I said *my* network for just that reason.

> >
> > Regarding port usage, it can be north of 1,000 ports simultaneous= ly.
> > Depends on the user, it's very bursty. =A0The trend is more a= nd more
> > ports.
> [WEG] Given that your application is typically one user doing periodic= mobile web access (NAT44), one could extrapolate that the average resident= ial environment where each customer has multiple such hosts behind a common= device (NAT444) and longer periods of user activity due to the device form= at and lack of battery life and data cap concerns, the numbers on simultane= ous port use will be higher, perhaps linearly based on the number of simult= aneous users behind the CPE device.
>

It is always interesting to hear outsiders views of my network. But don&= #39;t feel burdened to scope and caveat my feedback about how a draft appli= es to my network or mobile networks.=A0 I know it is strange and usual for = a mobile operator to participate in the IETF, but it is no longer strange a= nd usual for mobile devices to communicate on the internet.

That said, I disagree with your statement above and say the trend is tha= t most devices I ship have mobile hot spot functionality , which is nat444.= Thanks Android.

Also, the trend is that most phones are connected to many clouds constan= tly: Gmail, updates, Facebook, twitter, email (@home, @work, @school ...) .= ..everything is "always on":and "push".=A0 Oh. And that= "group on" app wants to push you a coupon because you walked int= o Starbucks.=A0 And BBC has breaking news alerts. ... and that all goes via= long lived Nat cloud attachment.

> >
> > Regarding logging, my CGN does not have this problem and does not= need
> > this solution.
> [WEG] That's because IIRC, mobile has other places to log the rela= tionship between user/device and IP, so addressing abuse/LEA requests can b= e handled somewhat differently than it is in a non-mobile network. In a for= mer life, I remember having variants of this discussion, and it seemed that= for the most part, LEAs haven't figured out that they might care about= mobile data based on the IP address (and port) - the LEA compliance folks = in mobility looked at me funny when I asked about it, because all they'= d ever gotten was requests associated with a phone number.
>
> We've done the math (based on some assumptions). I'm not at li= berty to share specifics, but I can say that worst case if we log every ses= sion is *very* bad - hundreds of terabytes of logging per year. SAN vendors= would love us. Anything that reduces the logging by orders of magnitude is= a big win.
> I do need to caveat my last statement. I make it assuming that CGN is = a foregone conclusion, so it probably should be deployable, because I do no= t believe in the notion of punishing operators by making it difficult in an= attempt to prevent people from deploying it. I'd prefer to never have = to use this, but if I do, it's useful. I view a "win" in this= category as being told, "I'm going to flog you" instead of &= quot;I'm going to flog you while forcing you to watch the Twilight movi= es" =A0-- it simply sucks less than the alternative.
>

That's fine for *you*.=A0 I am just making it clear that this is not= at all appealing in my network. It is not deployable in networks that look= my mobile network, and we already do a lot of cgn.

Cb
> Thanks
> Wes George
>
> This E-mail and any of its attachments may contain Time Warner Cable p= roprietary information, which is privileged, confidential, or subject to co= pyright 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 no= t the intended recipient of this E-mail, you are hereby notified that any d= issemination, distribution, copying, or action taken in relation to the con= tents of and attachments to this E-mail is strictly prohibited and may be u= nlawful. If you have received this E-mail in error, please notify the sende= r immediately and permanently delete the original and any copy of this E-ma= il and any printout.

On Jan 5, 2012 6:16 AM, "George, Wes" = <wesley.george@twcable.com<= /a>> wrote:
> From: v6ops-bounces@ietf.org= [mailto:v6ops-bounces@ietf.o= rg] On Behalf
> Of Cameron Byrne
> Sent: Wednesday, January 04, 2012 5:56 PM
> Subject: Re: [v6ops] Please review draft-donley-behave-deterministic-<= br> > cgn
>
> As someone who has operated LSN/CGN before such terms were used, i
> feel qualified to say that we do not need this function. =A0Others may=
> find it useful, but not my network.
[WEG] yes, others do need it. We don't have the experience of operating= it yet, but our networks are somewhat different. I'm glad you don'= t. I wish we didn't.

>
> Regarding port usage, it can be north of 1,000 ports simultaneously. > Depends on the user, it's very bursty. =A0The trend is more and mo= re
> ports.
[WEG] Given that your application is typically one user doing periodic mobi= le web access (NAT44), one could extrapolate that the average residential e= nvironment where each customer has multiple such hosts behind a common devi= ce (NAT444) and longer periods of user activity due to the device format an= d lack of battery life and data cap concerns, the numbers on simultaneous p= ort use will be higher, perhaps linearly based on the number of simultaneou= s users behind the CPE device.

>
> Regarding logging, my CGN does not have this problem and does not need=
> this solution.
[WEG] That's because IIRC, mobile has other places to log the relations= hip between user/device and IP, so addressing abuse/LEA requests can be han= dled somewhat differently than it is in a non-mobile network. In a former l= ife, I remember having variants of this discussion, and it seemed that for = the most part, LEAs haven't figured out that they might care about mobi= le data based on the IP address (and port) - the LEA compliance folks in mo= bility looked at me funny when I asked about it, because all they'd eve= r gotten was requests associated with a phone number.

We've done the math (based on some assumptions). I'm not at liberty= to share specifics, but I can say that worst case if we log every session = is *very* bad - hundreds of terabytes of logging per year. SAN vendors woul= d love us. Anything that reduces the logging by orders of magnitude is a bi= g win.
I do need to caveat my last statement. I make it assuming that CGN is a for= egone conclusion, so it probably should be deployable, because I do not bel= ieve in the notion of punishing operators by making it difficult in an atte= mpt to prevent people from deploying it. I'd prefer to never have to us= e this, but if I do, it's useful. I view a "win" in this cate= gory as being told, "I'm going to flog you" instead of "= I'm going to flog you while forcing you to watch the Twilight movies&qu= ot; =A0-- it simply sucks less than the alternative.

Thanks
Wes George

This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout.
--e89a8ffba8a50ca5d004b5c9a700-- From cb.list6@gmail.com Thu Jan 5 08:33:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA9721F87EA for ; Thu, 5 Jan 2012 08:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ark64IifoitV for ; Thu, 5 Jan 2012 08:33:57 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0016721F870F for ; Thu, 5 Jan 2012 08:33:56 -0800 (PST) Received: by pbdd12 with SMTP id d12so541841pbd.31 for ; Thu, 05 Jan 2012 08:33:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=yfgffTjgXjfLC/NFwqWKhLoMwfWxa/mKU1ZSaCIX0O4=; b=vxT6LI6YHUDOy+Fxejjz4iLdsa11gmI0xWPfWct9GCIwZ8s2qpoKrwrsKqD8q4wuDF Ldc1HnCiLE1nSk5RisSr58BL5MkxzqsxiYWAY0AcW2C+yXgmdvKAitYf6SGeO7l5LWdv 0h7XcHnZtiYMyIlXoP5I3UPKot8+sFzTJy9ss= MIME-Version: 1.0 Received: by 10.68.73.70 with SMTP id j6mr6855995pbv.20.1325781236021; Thu, 05 Jan 2012 08:33:56 -0800 (PST) Received: by 10.143.67.21 with HTTP; Thu, 5 Jan 2012 08:33:55 -0800 (PST) In-Reply-To: References: <3C8B8B8F-6B08-43DE-AF8B-5FF37B087A5F@cisco.com> <9B57C850BB53634CACEC56EF4853FF653B37B11E@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 5 Jan 2012 08:33:55 -0800 Message-ID: From: Cameron Byrne To: "George, Wes" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "draft-donley-behave-deterministic-cgn@tools.ietf.org" , v6ops v6ops WG , Behave Chairs , Dave Thaler Subject: Re: [v6ops] Please review draft-donley-behave-deterministic-cgn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 16:33:58 -0000 On Thu, Jan 5, 2012 at 7:33 AM, Cameron Byrne wrote: > > On Jan 5, 2012 6:16 AM, "George, Wes" wrote: >> >> > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >> > Of Cameron Byrne >> > Sent: Wednesday, January 04, 2012 5:56 PM >> > Subject: Re: [v6ops] Please review draft-donley-behave-deterministic- >> > cgn >> > >> > As someone who has operated LSN/CGN before such terms were used, i >> > feel qualified to say that we do not need this function. =A0Others may >> > find it useful, but not my network. >> [WEG] yes, others do need it. We don't have the experience of operating = it >> yet, but our networks are somewhat different. I'm glad you don't. I wish= we >> didn't. >> > > Ack. I said *my* network for just that reason. > >> > >> > Regarding port usage, it can be north of 1,000 ports simultaneously. >> > Depends on the user, it's very bursty. =A0The trend is more and more >> > ports. >> [WEG] Given that your application is typically one user doing periodic >> mobile web access (NAT44), one could extrapolate that the average >> residential environment where each customer has multiple such hosts behi= nd a >> common device (NAT444) and longer periods of user activity due to the de= vice >> format and lack of battery life and data cap concerns, the numbers on >> simultaneous port use will be higher, perhaps linearly based on the numb= er >> of simultaneous users behind the CPE device. >> > > It is always interesting to hear outsiders views of my network. But don't > feel burdened to scope and caveat my feedback about how a draft applies t= o > my network or mobile networks.=A0 I know it is strange and usual for a mo= bile > operator to participate in the IETF, but it is no longer strange and usua= l > for mobile devices to communicate on the internet. > > That said, I disagree with your statement above and say the trend is that > most devices I ship have mobile hot spot functionality , which is nat444. > Thanks Android. > > Also, the trend is that most phones are connected to many clouds constant= ly: > Gmail, updates, Facebook, twitter, email (@home, @work, @school ...) > ...everything is "always on":and "push".=A0 Oh. And that "group on" app w= ants > to push you a coupon because you walked into Starbucks.=A0 And BBC has > breaking news alerts. ... and that all goes via long lived Nat cloud > attachment. > Alas, sometimes my words are not enough, and other times i just cant stop talking so you are going to get some more of it. Here is *one* data point on why more and more apps are "push" / always-on http://urbanairship.com/blog/2011/11/04/customer-success-story-swirl-uses-p= ush-to-boost-mobile-orders-by-20/ And, they even describe how they handle the scale on their side in the cloud, they can get about 500K "sessions" per EC2 instance. Their cost per session is cheaper than mine on the middlebox... http://urbanairship.com/blog/2010/09/29/linux-kernel-tuning-for-c500k/ Great. So, what does that mean for a mobile operator? Not "periodic mobile web access" as you say. It means there are a lot of long lived and sustained CGN sessions. Or, an alternative solution, dare i say the forbidden word on an IPv4 life support thread? ... ipv6. Let me also clear up something, most of mobile operator traffic is volume is video. http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns8= 27/white_paper_c11-520862.html "Mobile video traffic will exceed 50 percent for the first time in 2011. Mobile video traffic was 49.8 percent of total mobile data traffic at the end of 2010, and will account for 52.8 percent of traffic by the end of 2011." Once again, "not periodic mobile web" cb >> > >> > Regarding logging, my CGN does not have this problem and does not need >> > this solution. >> [WEG] That's because IIRC, mobile has other places to log the relationsh= ip >> between user/device and IP, so addressing abuse/LEA requests can be hand= led >> somewhat differently than it is in a non-mobile network. In a former lif= e, I >> remember having variants of this discussion, and it seemed that for the = most >> part, LEAs haven't figured out that they might care about mobile data ba= sed >> on the IP address (and port) - the LEA compliance folks in mobility look= ed >> at me funny when I asked about it, because all they'd ever gotten was >> requests associated with a phone number. >> >> We've done the math (based on some assumptions). I'm not at liberty to >> share specifics, but I can say that worst case if we log every session i= s >> *very* bad - hundreds of terabytes of logging per year. SAN vendors woul= d >> love us. Anything that reduces the logging by orders of magnitude is a b= ig >> win. >> I do need to caveat my last statement. I make it assuming that CGN is a >> foregone conclusion, so it probably should be deployable, because I do n= ot >> believe in the notion of punishing operators by making it difficult in a= n >> attempt to prevent people from deploying it. I'd prefer to never have to= use >> this, but if I do, it's useful. I view a "win" in this category as being >> told, "I'm going to flog you" instead of "I'm going to flog you while >> forcing you to watch the Twilight movies" =A0-- it simply sucks less tha= n the >> alternative. >> > > That's fine for *you*.=A0 I am just making it clear that this is not at a= ll > appealing in my network. It is not deployable in networks that look my > mobile network, and we already do a lot of cgn. > > Cb > > >> Thanks >> Wes George >> >> This E-mail and any of its attachments may contain Time Warner Cable >> proprietary information, which is privileged, confidential, or subject t= o >> 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 intended recipient of this E-mail, you are hereby notified that any >> dissemination, distribution, copying, or action taken in relation to the >> contents of and attachments to this E-mail is strictly prohibited and ma= y 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 t= his >> E-mail and any printout. > > On Jan 5, 2012 6:16 AM, "George, Wes" wrote: >> >> > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >> > Of Cameron Byrne >> > Sent: Wednesday, January 04, 2012 5:56 PM >> > Subject: Re: [v6ops] Please review draft-donley-behave-deterministic- >> > cgn >> > >> > As someone who has operated LSN/CGN before such terms were used, i >> > feel qualified to say that we do not need this function. =A0Others may >> > find it useful, but not my network. >> [WEG] yes, others do need it. We don't have the experience of operating = it >> yet, but our networks are somewhat different. I'm glad you don't. I wish= we >> didn't. >> >> > >> > Regarding port usage, it can be north of 1,000 ports simultaneously. >> > Depends on the user, it's very bursty. =A0The trend is more and more >> > ports. >> [WEG] Given that your application is typically one user doing periodic >> mobile web access (NAT44), one could extrapolate that the average >> residential environment where each customer has multiple such hosts behi= nd a >> common device (NAT444) and longer periods of user activity due to the de= vice >> format and lack of battery life and data cap concerns, the numbers on >> simultaneous port use will be higher, perhaps linearly based on the numb= er >> of simultaneous users behind the CPE device. >> >> > >> > Regarding logging, my CGN does not have this problem and does not need >> > this solution. >> [WEG] That's because IIRC, mobile has other places to log the relationsh= ip >> between user/device and IP, so addressing abuse/LEA requests can be hand= led >> somewhat differently than it is in a non-mobile network. In a former lif= e, I >> remember having variants of this discussion, and it seemed that for the = most >> part, LEAs haven't figured out that they might care about mobile data ba= sed >> on the IP address (and port) - the LEA compliance folks in mobility look= ed >> at me funny when I asked about it, because all they'd ever gotten was >> requests associated with a phone number. >> >> We've done the math (based on some assumptions). I'm not at liberty to >> share specifics, but I can say that worst case if we log every session i= s >> *very* bad - hundreds of terabytes of logging per year. SAN vendors woul= d >> love us. Anything that reduces the logging by orders of magnitude is a b= ig >> win. >> I do need to caveat my last statement. I make it assuming that CGN is a >> foregone conclusion, so it probably should be deployable, because I do n= ot >> believe in the notion of punishing operators by making it difficult in a= n >> attempt to prevent people from deploying it. I'd prefer to never have to= use >> this, but if I do, it's useful. I view a "win" in this category as being >> told, "I'm going to flog you" instead of "I'm going to flog you while >> forcing you to watch the Twilight movies" =A0-- it simply sucks less tha= n the >> alternative. >> >> Thanks >> Wes George >> >> This E-mail and any of its attachments may contain Time Warner Cable >> proprietary information, which is privileged, confidential, or subject t= o >> 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 intended recipient of this E-mail, you are hereby notified that any >> dissemination, distribution, copying, or action taken in relation to the >> contents of and attachments to this E-mail is strictly prohibited and ma= y 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 t= his >> E-mail and any printout. From wesley.george@twcable.com Thu Jan 5 08:51:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDF021F881D for ; Thu, 5 Jan 2012 08:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.93 X-Spam-Level: X-Spam-Status: No, score=0.93 tagged_above=-999 required=5 tests=[AWL=-1.222, BAYES_40=-0.185, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OVaQGpFXgMr for ; Thu, 5 Jan 2012 08:51:08 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id D5F8D21F8839 for ; Thu, 5 Jan 2012 08:51:07 -0800 (PST) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.71,461,1320642000"; d="scan'208,217";a="320022003" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 05 Jan 2012 11:45:00 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Thu, 5 Jan 2012 11:51:06 -0500 From: "George, Wes" To: Cameron Byrne Date: Thu, 5 Jan 2012 11:51:05 -0500 Thread-Topic: [v6ops] Please review draft-donley-behave-deterministic-cgn Thread-Index: AczLv12k15F6lfe9QbSyoXVZjhzl9QABWcRA Message-ID: References: <3C8B8B8F-6B08-43DE-AF8B-5FF37B087A5F@cisco.com> <9B57C850BB53634CACEC56EF4853FF653B37B11E@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DCC302FAA9FE5F4BBA4DCAD4656937791737347901PRVPEXVS03cor_" MIME-Version: 1.0 Cc: "draft-donley-behave-deterministic-cgn@tools.ietf.org" , v6ops v6ops WG , Behave Chairs , Dave Thaler Subject: Re: [v6ops] Please review draft-donley-behave-deterministic-cgn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 16:51:10 -0000 --_000_DCC302FAA9FE5F4BBA4DCAD4656937791737347901PRVPEXVS03cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Cameron Byrne [mailto:cb.list6@gmail.com] Sent: Thursday, January 05, 2012 10:33 AM To: George, Wes Cc: Behave Chairs; Dave Thaler; draft-donley-behave-deterministic-cgn@tools= .ietf.org; v6ops v6ops WG Subject: RE: [v6ops] Please review draft-donley-behave-deterministic-cgn It is always interesting to hear outsiders views of my network. But don't f= eel burdened to scope and caveat my feedback about how a draft applies to m= y network or mobile networks. I know it is strange and usual for a mobile = operator to participate in the IETF, but it is no longer strange and usual = for mobile devices to communicate on the internet. [WEG] It's not necessary to have a chip on your shoulder, Cameron. :-) I w= asn't caveatting or trying to minimize your feedback. I was trying to contr= ibute to the overall discussion regarding a reasonable assumption about por= t numbers based on my own experience with a reasonably data-centric mobile = network, and what I know about other broadband networks. Tl;dr version of m= y comment was "it could be even worse than this" That said, I disagree with your statement above and say the trend is that m= ost devices I ship have mobile hot spot functionality , which is nat444. Th= anks Android. [WEG] no argument here. However, simply because most have it doesn't mean t= hat they all use it, nor does it mean that their usage profile becomes exac= tly like a residential broadband customer, especially on the extreme end of= the usage (bandwidth or number of devices behind the NAT) spectrum. That's= the distinction I was making. Mobile devices still have limitations which = drive tradeoffs in user behavior - most notably, batteries and data caps. A= nd yes, there are exceptions that prove me wrong. Don't read too much into = it :-) Also, the trend is that most phones are connected to many clouds constantly= : Gmail, updates, Facebook, twitter, email (@home, @work, @school ...) ...e= verything is "always on":and "push". Oh. And that "group on" app wants to = push you a coupon because you walked into Starbucks. And BBC has breaking = news alerts. ... and that all goes via long lived Nat cloud attachment. [WEG] Yeah, Android (and iOS, et al) is a chatty beast, and that lives on t= he mobile network... until it gets offloaded to a WiFi link, in which case = it's one of multiple devices doing the same thing behind the first round CP= E NAT. Again, I was simply trying to reinforce the point that your experien= ces show a baseline, but when you consider a home where all 3-5 residents h= ave at least one (if not 2 or 3) devices doing exactly that, the problem is= magnified, which is why the problem is maybe different for me. Was not try= ing to imply that I know what goes on in your network better than you do. A= pologies if that's how it came across. Thanks Wes ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_DCC302FAA9FE5F4BBA4DCAD4656937791737347901PRVPEXVS03cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: Cameron = Byrne [mailto:cb.list6@gmail.com]
Sent: Thursday, January 05, 2012 10:33 AM
To: George, Wes
Cc: Behave Chairs; Dave Thaler; draft-donley-behave-deterministic-cg= n@tools.ietf.org; v6ops v6ops WG
Subject: RE: [v6ops] Please review draft-donley-behave-deterministic= -cgn

 

It is always interesting to hear outsiders views of my network. But don'= t feel burdened to scope and caveat my feedback about how a draft applies t= o my network or mobile networks.  I know it is strange and usual for a= mobile operator to participate in the IETF, but it is no longer strange and usual for mobile devices to communic= ate on the internet.

[WEG] It’s not necessary to have = a chip on your shoulder, Cameron. :-)  I wasn’t caveatting or tr= ying to minimize your feedback. I was trying to contribute to the overall discussion regarding a reasonable assumption about port numbers based on m= y own experience with a reasonably data-centric mobile network, and what I = know about other broadband networks. Tl;dr version of my comment was “= ;it could be even worse than this”

That said, I disagree with your statement above and say the trend is tha= t most devices I ship have mobile hot spot functionality , which is nat444.= Thanks Android.

[WEG] no argument here. However, simply= because most have it doesn’t mean that they all use it, nor does it = mean that their usage profile becomes exactly like a residential broadband customer, especially on the extreme end of the usage (bandwidth = or number of devices behind the NAT) spectrum. That’s the distinction= I was making. Mobile devices still have limitations which drive tradeoffs = in user behavior – most notably, batteries and data caps. And yes, there are exceptions that prove me wrong. Don̵= 7;t read too much into it :-)

Also, the trend is that most phones are connected to many clouds constan= tly: Gmail, updates, Facebook, twitter, email (@home, @work, @school ...) .= ..everything is "always on":and "push".  Oh. And t= hat "group on" app wants to push you a coupon because you walked into Starbucks.  And BBC has breaking news alerts. ... and tha= t all goes via long lived Nat cloud attachment.

[WEG] Yeah, Android (and iOS, et al) is= a chatty beast, and that lives on the mobile network… until it gets = offloaded to a WiFi link, in which case it’s one of multiple devices doing the same thing behind the first round CPE NAT. Again, I was = simply trying to reinforce the point that your experiences show a baseline,= but when you consider a home where all 3-5 residents have at least one (if= not 2 or 3) devices doing exactly that, the problem is magnified, which is why the problem is maybe differen= t for me. Was not trying to imply that I know what goes on in your network = better than you do. Apologies if that’s how it came across.

Thanks

Wes


This E-mail and any of its a= ttachments 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 a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_DCC302FAA9FE5F4BBA4DCAD4656937791737347901PRVPEXVS03cor_-- From Carl.Wuyts@technicolor.com Fri Jan 6 01:27:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4702621F88EB for ; Fri, 6 Jan 2012 01:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DC9gFa07+Fon for ; Fri, 6 Jan 2012 01:27:25 -0800 (PST) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by ietfa.amsl.com (Postfix) with ESMTP id 29CF121F88F0 for ; Fri, 6 Jan 2012 01:27:20 -0800 (PST) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKTwa+bPKSbNlv9/+t97jgxznjyC93uk0k@postini.com; Fri, 06 Jan 2012 01:27:25 PST Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 6 Jan 2012 10:25:05 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.20]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Fri, 6 Jan 2012 10:25:17 +0100 From: Wuyts Carl To: Fred Baker , "v6ops@ietf.org WG" Date: Fri, 6 Jan 2012 10:25:15 +0100 Thread-Topic: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt Thread-Index: AczKbz9i1zkbN140RnGW9W0m3Un6XwB4wLkQ Message-ID: <867F4B6A1672E541A94676D556793ACD0CB56952D5@MOPESMBX01.eu.thmulti.com> References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 09:27:30 -0000 WAA-7: If the IPv6 CE router does not acquire global IPv6 address(es) from either SLAAC or DHCPv6, then it MUST create global IPv6 address(es) from its delegated prefix(es) and configure those on one of its internal virtual network interfaces, unless configured to require a global IPv6 address on the WAN interface I've commented on this a long time ago, when it was WAA-8 in version 02, bu= t seems like it's still more or less in the same unclear condition. My remarks: 1. what is considered as virtual interface ? 2. what about behavior with ia_pd=3D64 ? I've got various answers to question one on the "virtual" interface, alread= y making clear that the description is/was not clear enough. Some (includi= ng myself) considered this virtual intf as the "loop interface", but in thi= s case, it's not even possible when only getting an ia_pd of length=3D64 (u= nless some "tricks" gets introduced (e.g. proxy) as suggested by Lorenzo ba= ck then). Other answers suggested to just put this one on the Lan interfac= e of the CPE, so in same subnet as LAN hosts. This would be ok in ia_pd=3D= 64 use case, ok for sourcing IPv6 packets and so on. >From the above WAA-7 description, I still cannot retrieve that kind of info= rmation. It still mentions "virtual interface", while this is a possibilit= y only in a situation with an ia_pd value < 64. WPD-5: If the IPv6 CE router is configured to initiate DHCPv6 before receiving a Router Advertisement, it MUST also request an IA_NA option in DHCPv6. Fully disagree. =20 First of all, what if stateless configuration is in place ? the CPE should= ask for ia_na ? =20 What is RA comes just after it ? Why should the CPE being charged with a task like this ? If CAN be configu= red like this, but for sure it's no mandatory thing!! As I've mentioned a = couple of times before now, from residential CPE point-of-view, too many ta= sks are being put on the CPE shoulders. There's no valid reason to enforce= the behavior of WPD-5!!! A CPE must be capable of configuring all kind of models, so be very flexibl= e to meet the customer requirements, but the WPD-5 is nothing to be enforce= d at all!! Regs Carl -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of F= red Baker Sent: woensdag 4 januari 2012 0:27 To: v6ops@ietf.org WG Subject: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt Folks - there is a new draft of 6204bis. Those that have issues with previo= us drafts are encouraged to comment on this version. Begin forwarded message: > From: internet-drafts@ietf.org > Date: December 22, 2011 1:03:18 PM PST > To: i-d-announce@ietf.org > Cc: v6ops@ietf.org > Subject: I-D Action: draft-ietf-v6ops-6204bis-05.txt > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the IPv6 Operations Working Group of th= e IETF. >=20 > Title : Basic Requirements for IPv6 Customer Edge Routers > Author(s) : Hemant Singh > Wes Beebee > Chris Donley > Barbara Stark > Ole Troan > Filename : draft-ietf-v6ops-6204bis-05.txt > Pages : 21 > Date : 2011-12-22 >=20 > This document specifies requirements for an IPv6 Customer Edge (CE) > router. Specifically, the current version of this document focuses > on the basic provisioning of an IPv6 CE router and the provisioning > of IPv6 hosts attached to it. The document also covers IP transition > technologies. Two transition technologies in RFC 5969's 6rd and RFC > 6333's DS-Lite. are covered in the document. The document obsoletes > RFC 6204, if approved. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6204bis-05.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-6204bis-05.txt >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From gvandeve@cisco.com Fri Jan 6 01:29:13 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFD721F88F5 for ; Fri, 6 Jan 2012 01:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUH3EaJEQWgk for ; Fri, 6 Jan 2012 01:29:12 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 866F221F88F2 for ; Fri, 6 Jan 2012 01:29:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=2109; q=dns/txt; s=iport; t=1325842152; x=1327051752; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=N5KyZSuDxDKD7q4L4yQY5MvVzGdQYB+JCP6HdHhTKQI=; b=c1Hs7KjVURjnomtrEssieRf7kt43csAn28isoOSAykVEdjQO3fH8gSOv FNDiGCs03MZg7kZJYA1OFNJqSMNQzPs93NYwqjfrzjzLBpJK0HiGgjKhT u6aleVG3leYNzlx7ufMuzC2vBUSe+awMl2Gr2USIehruCj5mFj6Xi1rJ8 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAq+Bk+Q/khL/2dsb2JhbABDrQmBBYFyAQEBBAEBAQ8BHQo0FwQCAQgOAwQBAQsGBRIBBgEmHwkIAQEEARIIARIHh2CXeQGeIohrgkNjBKc9 X-IronPort-AV: E=Sophos;i="4.71,467,1320624000"; d="scan'208";a="62900925" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 06 Jan 2012 09:29:10 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q069TAIG015087; Fri, 6 Jan 2012 09:29:10 GMT Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Jan 2012 10:29:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Jan 2012 10:29:10 +0100 Message-ID: <4269EA985EACD24987D82DAE2FEC62E504DA8736@XMB-AMS-101.cisco.com> In-Reply-To: <4F04F5CA.6010802@si6networks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Revised I-D: Advice on RA-Guard Implementation Thread-Index: AczLRUEHPFapTVnxSYWj9DnjQa+DggBDzCFQ References: <4F04F5CA.6010802@si6networks.com> From: "Gunter Van de Velde (gvandeve)" To: "Fernando Gont" , "IPv6 Operations" X-OriginalArrivalTime: 06 Jan 2012 09:29:10.0651 (UTC) FILETIME=[A56C0CB0:01CCCC55] Subject: Re: [v6ops] Revised I-D: Advice on RA-Guard Implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 09:29:13 -0000 Hi Fernando, Many thanks for taking my comments and guidelines into account. I am less opposed now, then i was before. You are correct when stating that a bad implementation of the RA filtering obscures the effect of RA-Guard. I do believe that describing how exactly the filtering needs to be=20 implemented is a step too far. Most types of filter will have consequences regarding extension headers. It is a well known limitation of traditional edge access lists that routers are using, unless the router is doing inspection beyond L3, and that is most of the time an expensive operation. RA-Guard is a poor-man solution for access networks against rogue RA's... the grown up solution is SeND. Maybe adding a line in the RA-Guard RFC in the security section would be a better solution as creating a new RFC explaining the implementation. G/ -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Fernando Gont Sent: donderdag 5 januari 2012 1:59 To: IPv6 Operations Subject: [v6ops] Revised I-D: Advice on RA-Guard Implementation Folks, We've published the IETF I-D "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)". It is available at: This I-D is based on our original I-D draft-gont-v6ops-ra-guard-evasion-01, but now focuses on providing advice to RA-Guard implementations, rather than on the evasion techniques that have been found effective against most popular implementations of RA-Guard. Producing effective RA-Guard implementations is important to provide feature parity with similar mitigation techniques already available and employed in the IPv4 world. Any feedback will be greatly appreciated. Thanks! Best regards, --=20 Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From fgont@si6networks.com Fri Jan 6 02:33:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3593721F8959 for ; Fri, 6 Jan 2012 02:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.662 X-Spam-Level: X-Spam-Status: No, score=-0.662 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lE5qM3003yw for ; Fri, 6 Jan 2012 02:33:35 -0800 (PST) Received: from srv01.bbserve.nl (srv01.bbserve.nl [46.21.160.232]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBB121F8957 for ; Fri, 6 Jan 2012 02:33:35 -0800 (PST) Received: from [186.137.77.114] (helo=[192.168.1.106]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Rj6nK-0001E1-RW; Fri, 06 Jan 2012 11:13:07 +0100 Message-ID: <4F06C555.4020509@si6networks.com> Date: Fri, 06 Jan 2012 06:56:37 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: "Gunter Van de Velde (gvandeve)" References: <4F04F5CA.6010802@si6networks.com> <4269EA985EACD24987D82DAE2FEC62E504DA8736@XMB-AMS-101.cisco.com> In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E504DA8736@XMB-AMS-101.cisco.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] Revised I-D: Advice on RA-Guard Implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 10:33:36 -0000 Gunter, On 01/06/2012 06:29 AM, Gunter Van de Velde (gvandeve) wrote: > Many thanks for taking my comments and guidelines into account. I am > less opposed now, then i was before. My understanting was that, based on our off-list exchange circa Jul 29, 2011, that you were in favor of a document that addressed this issue from this angle (implementation advice). So I'm kinda surprised that you're "less opposed"... as this revision (including change of title and filename) was mostly meant to please you. > I do believe that describing how exactly the filtering needs to be > implemented is a step too far. The RA-Guard stuff (and RFCs) was meant to be implemented, right? So we have one problem statement document, one framework (?) document, but it is still hard to figure out how to get RA-Guard right. Should live happily with that? > Most types of filter will have > consequences regarding extension headers. > It is a well known limitation of traditional edge access lists that > routers are using, unless the router is doing inspection beyond L3, and > that is most of the time an expensive operation. Huh? What's the "limitation" you're referring to? > RA-Guard is a poor-man solution for access networks against rogue > RA's... the grown up solution is SeND. You may s/poor-man/deployable/, as well. > Maybe adding a line in the RA-Guard RFC in the security section would be > a better solution as creating a new RFC explaining the implementation. What would that line say? "The rest of the document talks about a security mitigation, but it can be trivially evaded by using extension headers", or what? My take is that RFC 6105 is underspecified, and lacking a real Security Considerations section -- not just "a missing line". Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From gvandeve@cisco.com Fri Jan 6 02:34:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6791221F862C for ; Fri, 6 Jan 2012 02:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUsgQFMupKRW for ; Fri, 6 Jan 2012 02:34:25 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 871C021F8616 for ; Fri, 6 Jan 2012 02:34:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=3142; q=dns/txt; s=iport; t=1325846065; x=1327055665; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=oMAgKEP9z2PazFLlDBIr9c5DMgoWrbCwnhoOHyy9a+Y=; b=Q8MeQ64BSIVpHISdjMLtSeSsz1pnb6BPhPYYU4H7eFU6S2ZA9aiBRvlR JCTp2evWnCCN46h9wEjP6pzhGWVIOkWvqXpP6Hqut5rBYTgB1NkUw3Q2Y aUA2mTxdycu62MRrGtbjigPoptDqP6getqMPFJJnykaP3KuF15YWjbEoL A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMvMBk+Q/khN/2dsb2JhbABDrEeBBYFyAQEBAwESAR0KPwUHBAIBCA4DBAEBAQoGBRIBBgFFCQgBAQQTCBMHh1iYBwGeIohrgkNjBKc9 X-IronPort-AV: E=Sophos;i="4.71,467,1320624000"; d="scan'208";a="125618923" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 06 Jan 2012 10:34:24 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q06AYOZA017396; Fri, 6 Jan 2012 10:34:24 GMT Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Jan 2012 11:34:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Jan 2012 11:34:23 +0100 Message-ID: <4269EA985EACD24987D82DAE2FEC62E504DA8754@XMB-AMS-101.cisco.com> In-Reply-To: <4F06C555.4020509@si6networks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Revised I-D: Advice on RA-Guard Implementation Thread-Index: AczMW8rGu4MKqOYHTMy6SOzB+hCyiQAAU8NQ References: <4F04F5CA.6010802@si6networks.com> <4269EA985EACD24987D82DAE2FEC62E504DA8736@XMB-AMS-101.cisco.com> <4F06C555.4020509@si6networks.com> From: "Gunter Van de Velde (gvandeve)" To: "Fernando Gont" X-OriginalArrivalTime: 06 Jan 2012 10:34:24.0423 (UTC) FILETIME=[C2364370:01CCCC5E] Cc: IPv6 Operations Subject: Re: [v6ops] Revised I-D: Advice on RA-Guard Implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 10:34:26 -0000 Hi Fernando, What i wrote to you in a 1-2-1 mail was: <>start<> Hi Fernando, I just read your paper. It indeed removes my concerns. Many thanks for taking them into consideration. Speak later, G/ <>end<> It means that i will not fight anymore to have this work put in=20 the bit-bucket. Its interesting to read, and deals with an interesting=20 problem statement. However, the issue is bigger as 'just' RA-Guard implementation imho. It is how data-traffic filters really should be implemented, taking ext headers into account. I am just not sure it justifies a potential RFC, mainly because its well known access-list avoidance. I do agree that security section of RA-Guard is not detailed enough, particular taking your=20 work into consideration, and i take blame for that. We could respin the security section, however i have no clue on how to that and how the logistics work for that. G/ -----Original Message----- From: Fernando Gont [mailto:fgont@si6networks.com]=20 Sent: vrijdag 6 januari 2012 10:57 To: Gunter Van de Velde (gvandeve) Cc: IPv6 Operations Subject: Re: [v6ops] Revised I-D: Advice on RA-Guard Implementation Gunter, On 01/06/2012 06:29 AM, Gunter Van de Velde (gvandeve) wrote: > Many thanks for taking my comments and guidelines into account. I am > less opposed now, then i was before. My understanting was that, based on our off-list exchange circa Jul 29, 2011, that you were in favor of a document that addressed this issue from this angle (implementation advice). So I'm kinda surprised that you're "less opposed"... as this revision (including change of title and filename) was mostly meant to please you. > I do believe that describing how exactly the filtering needs to be=20 > implemented is a step too far.=20 The RA-Guard stuff (and RFCs) was meant to be implemented, right? So we have one problem statement document, one framework (?) document, but it is still hard to figure out how to get RA-Guard right. Should live happily with that? > Most types of filter will have > consequences regarding extension headers. > It is a well known limitation of traditional edge access lists that > routers are using, unless the router is doing inspection beyond L3, and > that is most of the time an expensive operation. Huh? What's the "limitation" you're referring to? > RA-Guard is a poor-man solution for access networks against rogue > RA's... the grown up solution is SeND. You may s/poor-man/deployable/, as well. > Maybe adding a line in the RA-Guard RFC in the security section would be > a better solution as creating a new RFC explaining the implementation. What would that line say? "The rest of the document talks about a security mitigation, but it can be trivially evaded by using extension headers", or what? My take is that RFC 6105 is underspecified, and lacking a real Security Considerations section -- not just "a missing line". Thanks, --=20 Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From ichiroumakino@gmail.com Fri Jan 6 02:42:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D5C21F8935 for ; Fri, 6 Jan 2012 02:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6TyMJNFf6S7 for ; Fri, 6 Jan 2012 02:42:43 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6D321F8955 for ; Fri, 6 Jan 2012 02:42:43 -0800 (PST) Received: by wibhj6 with SMTP id hj6so1255124wib.31 for ; Fri, 06 Jan 2012 02:42:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=OwFV6wQGITpJLESDTzPSKokLNTWbdom61QuCrCPNKV4=; b=XqIiY0pp/cD/h+ZGLzRRqv/4OidMENjNawNiPxj3kvf7Of4qqRTAvnsE+j2aaqWRlA qQRF1LwUf3003PtOoMb61ZEYyq0rA6GyMKUmikwAInGeI+8WM6oHDdgyrYyQkRI8/t3C m0TZGosvlXlWV+FjsuAcXhTBYVd0yjAGFrxc0= Received: by 10.180.90.136 with SMTP id bw8mr6428158wib.1.1325846562532; Fri, 06 Jan 2012 02:42:42 -0800 (PST) Received: from [10.147.13.99] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id q34sm53871573wbm.15.2012.01.06.02.42.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Jan 2012 02:42:41 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <867F4B6A1672E541A94676D556793ACD0CB56952D5@MOPESMBX01.eu.thmulti.com> Date: Fri, 6 Jan 2012 11:42:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8FFE15EA-B90E-4553-A776-7C2C5C221852@employees.org> References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com> <867F4B6A1672E541A94676D556793ACD0CB56952D5@MOPESMBX01.eu.thmulti.com> To: Wuyts Carl X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 10:42:44 -0000 Carl, > WAA-7: If the IPv6 CE router does not acquire global IPv6 > address(es) from either SLAAC or DHCPv6, then it MUST create > global IPv6 address(es) from its delegated prefix(es) and > configure those on one of its internal virtual network > interfaces, unless configured to require a global IPv6 > address on the WAN interface >=20 > I've commented on this a long time ago, when it was WAA-8 in version = 02, but seems like it's still more or less in the same unclear = condition. > My remarks: > 1. what is considered as virtual interface ? > 2. what about behavior with ia_pd=3D64 ? >=20 > I've got various answers to question one on the "virtual" interface, = already making clear that the description is/was not clear enough. Some = (including myself) considered this virtual intf as the "loop interface", = but in this case, it's not even possible when only getting an ia_pd of = length=3D64 (unless some "tricks" gets introduced (e.g. proxy) as = suggested by Lorenzo back then). Other answers suggested to just put = this one on the Lan interface of the CPE, so in same subnet as LAN = hosts. This would be ok in ia_pd=3D64 use case, ok for sourcing IPv6 = packets and so on. given that all OSes I know about implement virtual network interfaces, = I'm not sure I understand what the confusion is? could add this to the terminology section from: = http://tools.ietf.org/html/draft-ietf-netext-logical-interface-support-04 LIF (Logical Interface) - It is a virtual interface in the IP = stack. It appears just as any other physical interface, provides similar semantics with respect to packet transmit and receive functions to the upper layers in the IP stack. However, it is only logical construct and is not a representation of an instance of any physical hardware. if you think that helps. now, with regards to the corner case of a ia_pd=3D64 and no address on = the WAN interface. if we assume that we agree that giving IPv6 service on the LAN interface = is more important than giving the CPE a stable IPv6 address, then the = only option within the realm of 6204 is to only configure the LAN = interface, and not a virtual interface. any suggestions for good text including that corner case? WAA-7: If the IPv6 CE router does not acquire global IPv6 address(es) from either SLAAC or DHCPv6, then if the delegated = prefix is large enough to assign to each of its interfaces it MUST create global IPv6 address(es) from = its delegated prefix(es) and configure those on one of its internal virtual network interfaces. slightly awkward that text... we can of course leave it undefined, or strongly recommend that ISPs = delegate enough prefixes to number both LAN and internal interfaces. > =46rom the above WAA-7 description, I still cannot retrieve that kind = of information. It still mentions "virtual interface", while this is a = possibility only in a situation with an ia_pd value < 64. >=20 >=20 >=20 > WPD-5: If the IPv6 CE router is configured to initiate DHCPv6 before > receiving a Router Advertisement, it MUST also request an > IA_NA option in DHCPv6. >=20 > Fully disagree. =20 this is where I think bis gets it wrong, the 6204 text is: WPD-5: If the IPv6 CE router initiates DHCPv6 before receiving a Router Advertisement, it MUST also request an IA_NA option in DHCPv6. > First of all, what if stateless configuration is in place ? the CPE = should ask for ia_na ? =20 both SLAAC and DHCP can exist at the same time and both be used for = address assignment. > What is RA comes just after it ? so what? if the DHCP server didn't give out IA_NAs then nothing was = different. if the DHCP server was willing to give out addresses, but the M bit was = unset, well, you do get inconsistent behaviour, but I would claim that's a configuration error. > Why should the CPE being charged with a task like this ? If CAN be = configured like this, but for sure it's no mandatory thing!! As I've = mentioned a couple of times before now, from residential CPE = point-of-view, too many tasks are being put on the CPE shoulders. = There's no valid reason to enforce the behavior of WPD-5!!! > A CPE must be capable of configuring all kind of models, so be very = flexible to meet the customer requirements, but the WPD-5 is nothing to = be enforced at all!! actually this requirement was trying to achieve the exact opposite. to = simplify the CPE. avoiding a coupling between RA processing and DHCP. with the above text the two processes can run independently from each = other. (the above assumes that the DHC working group will figure out a solution = to multiple stateless option in a single DHCP session). cheers, Ole From gert@space.net Fri Jan 6 03:24:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061B821F84AA for ; Fri, 6 Jan 2012 03:24:22 -0800 (PST) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XAMldS8Ds9d for ; Fri, 6 Jan 2012 03:24:21 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 417A121F86EE for ; Fri, 6 Jan 2012 03:09:50 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id ECBACF8A75 for ; Fri, 6 Jan 2012 12:09:48 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id D7DF0F8A76 for ; Fri, 6 Jan 2012 12:09:48 +0100 (CET) Received: (qmail 85532 invoked by uid 1007); 6 Jan 2012 12:09:48 +0100 Date: Fri, 6 Jan 2012 12:09:48 +0100 From: Gert Doering To: "Gunter Van de Velde \(gvandeve\)" Message-ID: <20120106110948.GD72014@Space.Net> References: <4F04F5CA.6010802@si6networks.com> <4269EA985EACD24987D82DAE2FEC62E504DA8736@XMB-AMS-101.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E504DA8736@XMB-AMS-101.cisco.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Operations Subject: Re: [v6ops] Revised I-D: Advice on RA-Guard Implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 11:24:22 -0000 Hi, On Fri, Jan 06, 2012 at 10:29:10AM +0100, Gunter Van de Velde (gvandeve) wrote: > RA-Guard is a poor-man solution for access networks against rogue > RA's... the grown up solution is SeND. We need both. SeND won't help if network participants are not able to prime their machines with the certificates needed to authenticate RAs. Think IETF networks... 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 (89) 32356-444 USt-IdNr.: DE813185279 From Carl.Wuyts@technicolor.com Fri Jan 6 04:05:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A38121F885F for ; Fri, 6 Jan 2012 04:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdkRMXQ67o6L for ; Fri, 6 Jan 2012 04:05:49 -0800 (PST) Received: from na3sys009aog122.obsmtp.com (na3sys009aog122.obsmtp.com [74.125.149.147]) by ietfa.amsl.com (Postfix) with ESMTP id A709321F8838 for ; Fri, 6 Jan 2012 04:05:47 -0800 (PST) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob122.postini.com ([74.125.148.12]) with SMTP ID DSNKTwbjjkIxMom8wX/AwgoNasna6Qb84S85@postini.com; Fri, 06 Jan 2012 04:05:49 PST Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 6 Jan 2012 13:02:44 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.20]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Fri, 6 Jan 2012 13:02:57 +0100 From: Wuyts Carl To: Ole Troan Date: Fri, 6 Jan 2012 13:02:55 +0100 Thread-Topic: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt Thread-Index: AczMX+5H70nM80m0QLuA4an/4+TAZAAAI6sA Message-ID: <867F4B6A1672E541A94676D556793ACD0CB569536F@MOPESMBX01.eu.thmulti.com> References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com> <867F4B6A1672E541A94676D556793ACD0CB56952D5@MOPESMBX01.eu.thmulti.com> <8FFE15EA-B90E-4553-A776-7C2C5C221852@employees.org> In-Reply-To: <8FFE15EA-B90E-4553-A776-7C2C5C221852@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 12:05:50 -0000 Ole, Thx for the fast reply. Comments inline. regs Carl > WAA-7: If the IPv6 CE router does not acquire global IPv6 > address(es) from either SLAAC or DHCPv6, then it MUST create > global IPv6 address(es) from its delegated prefix(es) and > configure those on one of its internal virtual network > interfaces, unless configured to require a global IPv6 > address on the WAN interface >=20 > I've commented on this a long time ago, when it was WAA-8 in version 02, = but seems like it's still more or less in the same unclear condition. > My remarks: > 1. what is considered as virtual interface ? > 2. what about behavior with ia_pd=3D64 ? >=20 > I've got various answers to question one on the "virtual" interface, alre= ady making clear that the description is/was not clear enough. Some (inclu= ding myself) considered this virtual intf as the "loop interface", but in t= his case, it's not even possible when only getting an ia_pd of length=3D64 = (unless some "tricks" gets introduced (e.g. proxy) as suggested by Lorenzo = back then). Other answers suggested to just put this one on the Lan interf= ace of the CPE, so in same subnet as LAN hosts. This would be ok in ia_pd= =3D64 use case, ok for sourcing IPv6 packets and so on. given that all OSes I know about implement virtual network interfaces, I'm = not sure I understand what the confusion is? could add this to the terminology section from: http://tools.ietf.org/html/= draft-ietf-netext-logical-interface-support-04 LIF (Logical Interface) - It is a virtual interface in the IP stack. It appears just as any other physical interface, provides similar semantics with respect to packet transmit and receive functions to the upper layers in the IP stack. However, it is only logical construct and is not a representation of an instance of any physical hardware. if you think that helps. [Carl] not a bad idea now, with regards to the corner case of a ia_pd=3D64 and no address on the = WAN interface. if we assume that we agree that giving IPv6 service on the LAN interface is= more important than giving the CPE a stable IPv6 address, then the only op= tion within the realm of 6204 is to only configure the LAN interface, and n= ot a virtual interface. any suggestions for good text including that corner case? WAA-7: If the IPv6 CE router does not acquire global IPv6 address(es) from either SLAAC or DHCPv6, then if the delegated pr= efix is large enough to assign to each of its interfaces it MUST create global IPv6 address(es) from its= delegated prefix(es) and configure those on one of its internal virtual network interfaces. slightly awkward that text... we can of course leave it undefined, or strongly recommend that ISPs delega= te enough prefixes to number both LAN and internal interfaces. [Carl}=20 Why not split it up, i.e., the current text, with clarification on LIF as s= uggested by you + extra statement on ia_pd=3D64, so something like: WAA-7: If the IPv6 CE router does not acquire global IPv6 address(es) from= either SLAAC or DHCPv6,=20 then if ia_pa length >64 it MUST create global IPv6 address(es) from its delegated prefix(es) and= configure those on one of its internal virtual network interfaces, unless configured to require a global IPv6 address= on the WAN interface else if ia_pd length=3D64=20 it must create global IPv6 address(es) from its delegated prefix(es) and= configure those on one of its lan interface, unless configured to requi= re a global IPv6 address on the WAN interface OR WAA-7: If the IPv6 CE router does not acquire global IPv6 address(es) from= either SLAAC or DHCPv6,=20 then if it MUST create global IPv6 address(es) from its delegated prefix(= es) and configure those on one of its internal virtual network interfaces (if ia_pd length >64) or on its lan interface (if ia= _pd length =3D 64), unless configured to require a global IPv6 address on = the WAN interface > From the above WAA-7 description, I still cannot retrieve that kind of in= formation. It still mentions "virtual interface", while this is a possibil= ity only in a situation with an ia_pd value < 64. >=20 >=20 >=20 > WPD-5: If the IPv6 CE router is configured to initiate DHCPv6 before > receiving a Router Advertisement, it MUST also request an > IA_NA option in DHCPv6. >=20 > Fully disagree. =20 this is where I think bis gets it wrong, the 6204 text is: WPD-5: If the IPv6 CE router initiates DHCPv6 before receiving a Router Advertisement, it MUST also request an IA_NA option in DHCPv6. > First of all, what if stateless configuration is in place ? the CPE shou= ld ask for ia_na ? =20 both SLAAC and DHCP can exist at the same time and both be used for address= assignment [Carl] agree, but it's not mandatory to have ia_na, so why enforce CPE of a= sking it in these circumstances ? > What is RA comes just after it ? so what? if the DHCP server didn't give out IA_NAs then nothing was differe= nt. if the DHCP server was willing to give out addresses, but the M bit was uns= et, well, you do get inconsistent behaviour, but I would claim that's a con= figuration error. [Carl] hm, bit of mixed feeling here, seems like "hiding" behind configurat= ion mistake ... > Why should the CPE being charged with a task like this ? If CAN be confi= gured like this, but for sure it's no mandatory thing!! As I've mentioned = a couple of times before now, from residential CPE point-of-view, too many = tasks are being put on the CPE shoulders. There's no valid reason to enfor= ce the behavior of WPD-5!!! > A CPE must be capable of configuring all kind of models, so be very flexi= ble to meet the customer requirements, but the WPD-5 is nothing to be enfor= ced at all!! actually this requirement was trying to achieve the exact opposite. to simp= lify the CPE. avoiding a coupling between RA processing and DHCP. with the above text the two processes can run independently from each other= . (the above assumes that the DHC working group will figure out a solution to= multiple stateless option in a single DHCP session). [Carl] Indeed, de-coupling RA processing from DHCP is exact what I've sugge= sted before, and glad to see some activity on this. However DHCPv6 client c= an be configured in many ways. Enforcing "automatic" ia_na requesting is n= ot a good idea. If you want the CPE to ask for IA_NA, then configure it as= such. With the current statement, there's still coupling of DHCPv6 and RA= , but in a different way than before. I don't see any reason to keep this = requirement at all, it does not bring any added value. cheers, Ole From ichiroumakino@gmail.com Fri Jan 6 05:08:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421E321F87B8 for ; Fri, 6 Jan 2012 05:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZ29pw1cKqss for ; Fri, 6 Jan 2012 05:08:10 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 673FA21F85BE for ; Fri, 6 Jan 2012 05:08:10 -0800 (PST) Received: by wibhj6 with SMTP id hj6so1361418wib.31 for ; Fri, 06 Jan 2012 05:08:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=hIL7zjFXD7D1tXDljwH//vhxkeGqk1rQa2DQi0HZUr0=; b=j52v9Dd+GR6fS/cNjsyA+d7ryQsvEXQGkMCRv12PypdZ83wQLufZrKZFVRL6Pga9MG jLnaOIfWmoVSua7klAi3yzM2VOzpfDEGqyW1gjv+WGDm0204QGQ4Z9LGx/vt9z+GjKNg 64/JrTJqrgPuwR4J7j3motHbpYlG/XfXIthaQ= Received: by 10.181.13.179 with SMTP id ez19mr11169078wid.11.1325855289638; Fri, 06 Jan 2012 05:08:09 -0800 (PST) Received: from [10.147.13.99] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id em4sm68235409wbb.20.2012.01.06.05.08.06 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Jan 2012 05:08:08 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <867F4B6A1672E541A94676D556793ACD0CB569536F@MOPESMBX01.eu.thmulti.com> Date: Fri, 6 Jan 2012 14:08:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <478BBBA2-3D32-4038-A5E4-CD886A417EB8@employees.org> References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com> <867F4B6A1672E541A94676D556793ACD0CB56952D5@MOPESMBX01.eu.thmulti.com> <8FFE15EA-B90E-4553-A776-7C2C5C221852@employees.org> <867F4B6A1672E541A94676D556793ACD0CB569536F@MOPESMBX01.eu.thmulti.com> To: Wuyts Carl X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 13:08:11 -0000 Carl, >> Why should the CPE being charged with a task like this ? If CAN be = configured like this, but for sure it's no mandatory thing!! As I've = mentioned a couple of times before now, from residential CPE = point-of-view, too many tasks are being put on the CPE shoulders. = There's no valid reason to enforce the behavior of WPD-5!!! >> A CPE must be capable of configuring all kind of models, so be very = flexible to meet the customer requirements, but the WPD-5 is nothing to = be enforced at all!! >=20 > actually this requirement was trying to achieve the exact opposite. to = simplify the CPE. avoiding a coupling between RA processing and DHCP. > with the above text the two processes can run independently from each = other. >=20 > (the above assumes that the DHC working group will figure out a = solution to multiple stateless option in a single DHCP session). >=20 > [Carl] Indeed, de-coupling RA processing from DHCP is exact what I've = suggested before, and glad to see some activity on this. However DHCPv6 = client can be configured in many ways. Enforcing "automatic" ia_na = requesting is not a good idea. If you want the CPE to ask for IA_NA, = then configure it as such. With the current statement, there's still = coupling of DHCPv6 and RA, but in a different way than before. I don't = see any reason to keep this requirement at all, it does not bring any = added value. if we want to keep RA and DHCP processes independent. meaning that the = two state machines can be run in parallel. for the purpose of DHCP, the M/O bits are basically ignored. if the network only offers addresses via DHCP, how does the network = trigger the CPE to ask for an IA_NA? 6204 solution is to require the device to always ask. cheers, Ole= From Carl.Wuyts@technicolor.com Fri Jan 6 05:13:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D9D21F8446 for ; Fri, 6 Jan 2012 05:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2A0D-RezqF7 for ; Fri, 6 Jan 2012 05:13:53 -0800 (PST) Received: from na3sys009aog122.obsmtp.com (na3sys009aog122.obsmtp.com [74.125.149.147]) by ietfa.amsl.com (Postfix) with ESMTP id 1787721F8445 for ; Fri, 6 Jan 2012 05:13:51 -0800 (PST) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob122.postini.com ([74.125.148.12]) with SMTP ID DSNKTwbzgYXf3vqjwMzV2egBqvkacy2kpems@postini.com; Fri, 06 Jan 2012 05:13:52 PST Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 6 Jan 2012 14:13:10 +0100 Received: from MOPESMBX01.eu.thmulti.com ([141.11.100.105]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Fri, 6 Jan 2012 14:13:23 +0100 From: Wuyts Carl To: Ole Troan Date: Fri, 6 Jan 2012 14:13:21 +0100 Thread-Topic: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt Thread-Index: AczMdD/4LTc86bCFT9mT+c+aPoyfugAAC83g Message-ID: <867F4B6A1672E541A94676D556793ACD0CB56953B7@MOPESMBX01.eu.thmulti.com> References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com> <867F4B6A1672E541A94676D556793ACD0CB56952D5@MOPESMBX01.eu.thmulti.com> <8FFE15EA-B90E-4553-A776-7C2C5C221852@employees.org> <867F4B6A1672E541A94676D556793ACD0CB569536F@MOPESMBX01.eu.thmulti.com> <478BBBA2-3D32-4038-A5E4-CD886A417EB8@employees.org> In-Reply-To: <478BBBA2-3D32-4038-A5E4-CD886A417EB8@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 13:13:53 -0000 if the network only offers addresses via DHCP, how does the network trigger= the CPE to ask for an IA_NA? 6204 solution is to require the device to always ask. [Carl]Just configuration, nothing more, nothing less. If you want ia_na, a= sk ia_na, if you don't, don't ask, no need to enforce this. What if you en= force ia_na and the server doesn't answer anyway ? Nothing accomplished. = What if you ask ia_na and the server is configured as such to not hand-out = anything if ia_na is requested (full match of requested options, if not mat= ch fully: nak) Keep it simple, it's usually the best. If customer wants ia_na, configure = the device as such, don't expect the CPE to do these things "auto-magically= " -----Original Message----- From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan Sent: vrijdag 6 januari 2012 14:08 To: Wuyts Carl Cc: Fred Baker; v6ops@ietf.org WG Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt Carl, >> Why should the CPE being charged with a task like this ? If CAN be conf= igured like this, but for sure it's no mandatory thing!! As I've mentioned= a couple of times before now, from residential CPE point-of-view, too many= tasks are being put on the CPE shoulders. There's no valid reason to enfo= rce the behavior of WPD-5!!! >> A CPE must be capable of configuring all kind of models, so be very flex= ible to meet the customer requirements, but the WPD-5 is nothing to be enfo= rced at all!! >=20 > actually this requirement was trying to achieve the exact opposite. to si= mplify the CPE. avoiding a coupling between RA processing and DHCP. > with the above text the two processes can run independently from each oth= er. >=20 > (the above assumes that the DHC working group will figure out a solution = to multiple stateless option in a single DHCP session). >=20 > [Carl] Indeed, de-coupling RA processing from DHCP is exact what I've sug= gested before, and glad to see some activity on this. However DHCPv6 client= can be configured in many ways. Enforcing "automatic" ia_na requesting is= not a good idea. If you want the CPE to ask for IA_NA, then configure it = as such. With the current statement, there's still coupling of DHCPv6 and = RA, but in a different way than before. I don't see any reason to keep thi= s requirement at all, it does not bring any added value. if we want to keep RA and DHCP processes independent. meaning that the two = state machines can be run in parallel. for the purpose of DHCP, the M/O bits are basically ignored. if the network only offers addresses via DHCP, how does the network trigger= the CPE to ask for an IA_NA? 6204 solution is to require the device to always ask. cheers, Ole From ichiroumakino@gmail.com Fri Jan 6 05:16:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7EC521F8470 for ; Fri, 6 Jan 2012 05:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeHEnLLlTzbX for ; Fri, 6 Jan 2012 05:16:48 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 155E821F8449 for ; Fri, 6 Jan 2012 05:16:47 -0800 (PST) Received: by werb14 with SMTP id b14so1337074wer.31 for ; Fri, 06 Jan 2012 05:16:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=0+iXOtLy5a2Ss2oRmGXHlV0PV1pM8YvtAl3o9K4Rwgs=; b=PD7TUxixhCLmdLbzA2UatT/GGKVZcofEsKTuSj5ZNlIHUKCOd083DDdIKQb/LMegVj ydaxCFPe9+Hodf8gKoKKITuaiGilYFaW6Jug1cBl5X/30dG4CMGD2/vtT8DEbhGJRVPc jFGxbZkzsj0omzX82/1vqZuTFB/Vw/DdiACKg= Received: by 10.216.135.154 with SMTP id u26mr2989520wei.20.1325855807209; Fri, 06 Jan 2012 05:16:47 -0800 (PST) Received: from [10.147.13.99] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id q5sm19508138wbo.8.2012.01.06.05.16.46 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Jan 2012 05:16:46 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <867F4B6A1672E541A94676D556793ACD0CB56953B7@MOPESMBX01.eu.thmulti.com> Date: Fri, 6 Jan 2012 14:16:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1E00A66B-B0A3-4FFC-AF0E-ED3A2CACEA60@employees.org> References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com> <867F4B6A1672E541A94676D556793ACD0CB56952D5@MOPESMBX01.eu.thmulti.com> <8FFE15EA-B90E-4553-A776-7C2C5C221852@employees.org> <867F4B6A1672E541A94676D556793ACD0CB569536F@MOPESMBX01.eu.thmulti.com> <478BBBA2-3D32-4038-A5E4-CD886A417EB8@employees.org> <867F4B6A1672E541A94676D556793ACD0CB56953B7@MOPESMBX01.eu.thmulti.com> To: Wuyts Carl X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 13:16:49 -0000 Carl, > if the network only offers addresses via DHCP, how does the network = trigger the CPE to ask for an IA_NA? > 6204 solution is to require the device to always ask. > [Carl]Just configuration, nothing more, nothing less. If you want = ia_na, ask ia_na, if you don't, don't ask, no need to enforce this. = What if you enforce ia_na and the server doesn't answer anyway ? = Nothing accomplished. What if you ask ia_na and the server is = configured as such to not hand-out anything if ia_na is requested (full = match of requested options, if not match fully: nak) > Keep it simple, it's usually the best. If customer wants ia_na, = configure the device as such, don't expect the CPE to do these things = "auto-magically" this isn't up to the customer. it is a choice by the access network. and = I don't think the "here is a fax from your ISP, just type in these = parameters" scheme is the best we can do. ;-) cheers, Ole >=20 >=20 > -----Original Message----- > From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole = Troan > Sent: vrijdag 6 januari 2012 14:08 > To: Wuyts Carl > Cc: Fred Baker; v6ops@ietf.org WG > Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt >=20 > Carl, >=20 >>> Why should the CPE being charged with a task like this ? If CAN be = configured like this, but for sure it's no mandatory thing!! As I've = mentioned a couple of times before now, from residential CPE = point-of-view, too many tasks are being put on the CPE shoulders. = There's no valid reason to enforce the behavior of WPD-5!!! >>> A CPE must be capable of configuring all kind of models, so be very = flexible to meet the customer requirements, but the WPD-5 is nothing to = be enforced at all!! >>=20 >> actually this requirement was trying to achieve the exact opposite. = to simplify the CPE. avoiding a coupling between RA processing and DHCP. >> with the above text the two processes can run independently from each = other. >>=20 >> (the above assumes that the DHC working group will figure out a = solution to multiple stateless option in a single DHCP session). >>=20 >> [Carl] Indeed, de-coupling RA processing from DHCP is exact what I've = suggested before, and glad to see some activity on this. However DHCPv6 = client can be configured in many ways. Enforcing "automatic" ia_na = requesting is not a good idea. If you want the CPE to ask for IA_NA, = then configure it as such. With the current statement, there's still = coupling of DHCPv6 and RA, but in a different way than before. I don't = see any reason to keep this requirement at all, it does not bring any = added value. >=20 > if we want to keep RA and DHCP processes independent. meaning that the = two state machines can be run in parallel. > for the purpose of DHCP, the M/O bits are basically ignored. >=20 > if the network only offers addresses via DHCP, how does the network = trigger the CPE to ask for an IA_NA? > 6204 solution is to require the device to always ask. >=20 > cheers, > Ole From Carl.Wuyts@technicolor.com Fri Jan 6 05:20:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64A121F87EF for ; Fri, 6 Jan 2012 05:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIzeMV-F3YRf for ; Fri, 6 Jan 2012 05:20:17 -0800 (PST) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with ESMTP id 2898821F85B6 for ; Fri, 6 Jan 2012 05:20:15 -0800 (PST) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKTwb1DpfztPv0ONQ3V2R+4G5OOf/uFDOx@postini.com; Fri, 06 Jan 2012 05:20:16 PST Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 6 Jan 2012 14:19:08 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.20]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Fri, 6 Jan 2012 14:19:21 +0100 From: Wuyts Carl To: Ole Troan Date: Fri, 6 Jan 2012 14:19:19 +0100 Thread-Topic: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt Thread-Index: AczMdXP9bvL1atLATqCJsW9Qpr5u7wAAA/GA Message-ID: <867F4B6A1672E541A94676D556793ACD0CB56953BE@MOPESMBX01.eu.thmulti.com> References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com> <867F4B6A1672E541A94676D556793ACD0CB56952D5@MOPESMBX01.eu.thmulti.com> <8FFE15EA-B90E-4553-A776-7C2C5C221852@employees.org> <867F4B6A1672E541A94676D556793ACD0CB569536F@MOPESMBX01.eu.thmulti.com> <478BBBA2-3D32-4038-A5E4-CD886A417EB8@employees.org> <867F4B6A1672E541A94676D556793ACD0CB56953B7@MOPESMBX01.eu.thmulti.com> <1E00A66B-B0A3-4FFC-AF0E-ED3A2CACEA60@employees.org> In-Reply-To: <1E00A66B-B0A3-4FFC-AF0E-ED3A2CACEA60@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 13:20:17 -0000 Carl, > if the network only offers addresses via DHCP, how does the network trigg= er the CPE to ask for an IA_NA? > 6204 solution is to require the device to always ask. > [Carl]Just configuration, nothing more, nothing less. If you want=20 > ia_na, ask ia_na, if you don't, don't ask, no need to enforce this. What= if you enforce ia_na and the server doesn't answer anyway ? Nothing accom= plished. What if you ask ia_na and the server is configured as such to not= hand-out anything if ia_na is requested (full match of requested options, = if not match fully: nak) Keep it simple, it's usually the best. If custome= r wants ia_na, configure the device as such, don't expect the CPE to do the= se things "auto-magically" this isn't up to the customer. it is a choice by the access network. and I = don't think the "here is a fax from your ISP, just type in these parameters= " scheme is the best we can do. ;-) [Carl] True, but there will be no "fax" from the ISP to the customer either= to ask to switch something in configuration off either if it wouldn't work= . Anyway, I'm always flexible, so I say make it a SHOULD iso MUST, meaning= "you should ask it unless you have a good reason not to do so", no ?? cheers, Ole >=20 >=20 > -----Original Message----- > From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole=20 > Troan > Sent: vrijdag 6 januari 2012 14:08 > To: Wuyts Carl > Cc: Fred Baker; v6ops@ietf.org WG > Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt >=20 > Carl, >=20 >>> Why should the CPE being charged with a task like this ? If CAN be con= figured like this, but for sure it's no mandatory thing!! As I've mentione= d a couple of times before now, from residential CPE point-of-view, too man= y tasks are being put on the CPE shoulders. There's no valid reason to enf= orce the behavior of WPD-5!!! >>> A CPE must be capable of configuring all kind of models, so be very fle= xible to meet the customer requirements, but the WPD-5 is nothing to be enf= orced at all!! >>=20 >> actually this requirement was trying to achieve the exact opposite. to s= implify the CPE. avoiding a coupling between RA processing and DHCP. >> with the above text the two processes can run independently from each ot= her. >>=20 >> (the above assumes that the DHC working group will figure out a solution= to multiple stateless option in a single DHCP session). >>=20 >> [Carl] Indeed, de-coupling RA processing from DHCP is exact what I've su= ggested before, and glad to see some activity on this. However DHCPv6 clien= t can be configured in many ways. Enforcing "automatic" ia_na requesting i= s not a good idea. If you want the CPE to ask for IA_NA, then configure it= as such. With the current statement, there's still coupling of DHCPv6 and= RA, but in a different way than before. I don't see any reason to keep th= is requirement at all, it does not bring any added value. >=20 > if we want to keep RA and DHCP processes independent. meaning that the tw= o state machines can be run in parallel. > for the purpose of DHCP, the M/O bits are basically ignored. >=20 > if the network only offers addresses via DHCP, how does the network trigg= er the CPE to ask for an IA_NA? > 6204 solution is to require the device to always ask. >=20 > cheers, > Ole From ichiroumakino@gmail.com Fri Jan 6 06:57:13 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0400021F8812 for ; Fri, 6 Jan 2012 06:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clsx8WSj3jqp for ; Fri, 6 Jan 2012 06:57:12 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADB421F87B9 for ; Fri, 6 Jan 2012 06:57:12 -0800 (PST) Received: by wgbds13 with SMTP id ds13so1665960wgb.1 for ; Fri, 06 Jan 2012 06:57:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ocwKxqCSgnhl5M4eL80N9GPmdws4H3rumdGixkaQHlE=; b=mJ/Z7PtVXRvg7tt8uRG4L5y7AyAU7WFLACFCIBfl0YMXG1jxNpm1RtWH0Zk/POfvKs V1qpA2jeBIJ2HoyiowFuKIMO6hc6gT1nBxSIuX1jHQOEy/geKpcmZXFyEOQctJm6EgAz zN9KXdj+q0SWDHK8UtYqmGK451iCllrWJdpnY= Received: by 10.180.94.97 with SMTP id db1mr11900354wib.16.1325861831437; Fri, 06 Jan 2012 06:57:11 -0800 (PST) Received: from dhcp-10-55-84-1.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id bl10sm3031326wib.0.2012.01.06.06.57.09 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Jan 2012 06:57:10 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <867F4B6A1672E541A94676D556793ACD0CB56953BE@MOPESMBX01.eu.thmulti.com> Date: Fri, 6 Jan 2012 15:57:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2B940363-1E7B-45F9-9FB9-37E6691F57E2@employees.org> References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com> <867F4B6A1672E541A94676D556793ACD0CB56952D5@MOPESMBX01.eu.thmulti.com> <8FFE15EA-B90E-4553-A776-7C2C5C221852@employees.org> <867F4B6A1672E541A94676D556793ACD0CB569536F@MOPESMBX01.eu.thmulti.com> <478BBBA2-3D32-4038-A5E4-CD886A417EB8@employees.org> <867F4B6A1672E541A94676D556793ACD0CB56953B7@MOPESMBX01.eu.thmulti.com> <1E00A66B-B0A3-4FFC-AF0E-ED3A2CACEA60@employees.org> <867F4B6A1672E541A94676D556793ACD0CB56953BE@MOPESMBX01.eu.thmulti.com> To: Wuyts Carl X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 14:57:13 -0000 Carl, >> if the network only offers addresses via DHCP, how does the network = trigger the CPE to ask for an IA_NA? >> 6204 solution is to require the device to always ask. >> [Carl]Just configuration, nothing more, nothing less. If you want=20 >> ia_na, ask ia_na, if you don't, don't ask, no need to enforce this. = What if you enforce ia_na and the server doesn't answer anyway ? = Nothing accomplished. What if you ask ia_na and the server is = configured as such to not hand-out anything if ia_na is requested (full = match of requested options, if not match fully: nak) Keep it simple, = it's usually the best. If customer wants ia_na, configure the device as = such, don't expect the CPE to do these things "auto-magically" >=20 > this isn't up to the customer. it is a choice by the access network. = and I don't think the "here is a fax from your ISP, just type in these = parameters" scheme is the best we can do. ;-) >=20 > [Carl] True, but there will be no "fax" from the ISP to the customer = either to ask to switch something in configuration off either if it = wouldn't work. Anyway, I'm always flexible, so I say make it a SHOULD = iso MUST, meaning "you should ask it unless you have a good reason not = to do so", no ?? the goal here is to specify a CPE that will work on any access network = and without any user configuration. note that this requirement is within an "if block", you only need to do = this if you don't want to wait for the RA with the M/O flags. cheers, Ole= From bs7652@att.com Fri Jan 6 07:07:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C262221F882C for ; Fri, 6 Jan 2012 07:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.519 X-Spam-Level: X-Spam-Status: No, score=-105.519 tagged_above=-999 required=5 tests=[AWL=1.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyOeZ3r5ni7S for ; Fri, 6 Jan 2012 07:07:50 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 0016321F8829 for ; Fri, 6 Jan 2012 07:07:49 -0800 (PST) X-Env-Sender: bs7652@att.com X-Msg-Ref: server-11.tower-119.messagelabs.com!1325862467!9255034!1 X-Originating-IP: [144.160.20.146] X-StarScan-Version: 6.4.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8284 invoked from network); 6 Jan 2012 15:07:47 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-11.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Jan 2012 15:07:47 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q06F6GKX013946; Fri, 6 Jan 2012 10:06:17 -0500 Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q06F6B9c013787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jan 2012 10:06:12 -0500 Received: from 01AL10015010625.AD.BLS.COM (01AL10015010625.ad.bls.com [90.152.44.194]) by sflint04.pst.cso.att.com (RSA Interceptor); Fri, 6 Jan 2012 10:07:21 -0500 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01AL10015010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Jan 2012 09:06:27 -0600 Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Jan 2012 10:06:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Jan 2012 10:07:17 -0500 Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F21CFE5E5@crexc50p> In-Reply-To: <867F4B6A1672E541A94676D556793ACD0CB56953BE@MOPESMBX01.eu.thmulti.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt Thread-Index: AczMdXP9bvL1atLATqCJsW9Qpr5u7wAAA/GAAAHkilA= References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com><867F4B6A1672E541A94676D556793ACD0CB56952D5@MOPESMBX01.eu.thmulti.com><8FFE15EA-B90E-4553-A776-7C2C5C221852@employees.org><867F4B6A1672E541A94676D556793ACD0CB569536F@MOPESMBX01.eu.thmulti.com><478BBBA2-3D32-4038-A5E4-CD886A417EB8@employees.org><867F4B6A1672E541A94676D556793ACD0CB56953B7@MOPESMBX01.eu.thmulti.com><1E00A66B-B0A3-4FFC-AF0E-ED3A2CACEA60@employees.org> <867F4B6A1672E541A94676D556793ACD0CB56953BE@MOPESMBX01.eu.thmulti.com> From: "STARK, BARBARA H" To: "Wuyts Carl" , "Ole Troan" X-OriginalArrivalTime: 06 Jan 2012 15:06:26.0598 (UTC) FILETIME=[C2FC8460:01CCCC84] X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 15:07:50 -0000 > > if the network only offers addresses via DHCP, how does the network > trigger the CPE to ask for an IA_NA? > > 6204 solution is to require the device to always ask. > > [Carl]Just configuration, nothing more, nothing less. If you want > > ia_na, ask ia_na, if you don't, don't ask, no need to enforce this. > What if you enforce ia_na and the server doesn't answer anyway ? > Nothing accomplished. What if you ask ia_na and the server is > configured as such to not hand-out anything if ia_na is requested (full > match of requested options, if not match fully: nak) Keep it simple, > it's usually the best. If customer wants ia_na, configure the device > as such, don't expect the CPE to do these things "auto-magically" >=20 > this isn't up to the customer. it is a choice by the access network. > and I don't think the "here is a fax from your ISP, just type in these > parameters" scheme is the best we can do. ;-) >=20 > [Carl] True, but there will be no "fax" from the ISP to the customer > either to ask to switch something in configuration off either if it > wouldn't work. Anyway, I'm always flexible, so I say make it a SHOULD > iso MUST, meaning "you should ask it unless you have a good reason not > to do so", no ?? The current requirement means that the customer doesn't have to know anything about the access network (SLAAC or DHCPv6 IA_NA or unnumbered). When we created 6204, one of the core goals was to identify requirements that would allow a customer to plug the CE router in and not have to know what address assignment mechanism the access network used. Changing WPD-5 from MUST to SHOULD would completely demolish that goal. If someone doesn't want to design their CE router per 6204, then there's absolutely nothing that says they have to. It's not a "standard". But if someone wants to build a router that can come up without user configuration when connected to an access network that does either SLAAC or DHCPv6 IA_NA or unnumbered, then this is what the CE router must do. If someone wants a separate RFC for CE routers intended for a different environment, then that's fine, too. But 6204 is for the CE router intended to work in the environment specified in 6204. As for the virtual interface comment -- my recollection of that was that CE router designers wanted language that would basically let them put that "unnumbered model" address wherever made sense for their box: LAN interface, internal interface, logical interface, whatever. No need to be specific, and leave it up to them. It just isn't the WAN interface (because there's an RFC that says that's prohibited). From my perspective, the CE router is a black box. If the access network provides IA_PD, but no IA_NA and no SLAAC, then I want that CE router to pick an address from a /64 of the IA_PD and be able to use that address for sending/receiving traffic to/from the LAN/WAN (while making the entire rest of that very same /64 available to the LAN for SLAAC). I think that the new proposals (in the last few emails on this thread) to split cases around when to put the address on a LAN interface and when to put it on an internal interface based on =3D or > /64 in IA_PD go in exactly the wrong direction. My experience has been that CE router vendors are perfectly capable of determining the interface that makes sense for their box. Realistically, the tests run at UNH-IOL wouldn't check to see what interface the address is on. Because the specific interface is not externally verifiable. The tests would check for (a) is the device able to send/receive traffic to/from all ports (assuming LAN isn't configured for multiple segments) using an address from the IA_PD, and (b) does it also advertise the rest of that same /64 for use on the LAN (SLAAC), and (c) do things just work after all this. Barbara From Carl.Wuyts@technicolor.com Fri Jan 6 07:13:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E7721F87CC for ; Fri, 6 Jan 2012 07:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8uYQbjmTKHM for ; Fri, 6 Jan 2012 07:13:54 -0800 (PST) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCCA21F87B0 for ; Fri, 6 Jan 2012 07:13:35 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKTwcPnTFG97+S66oYqXfQ2ocmn/C8opM5@postini.com; Fri, 06 Jan 2012 07:13:37 PST Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 6 Jan 2012 16:07:09 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.20]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Fri, 6 Jan 2012 16:07:17 +0100 From: Wuyts Carl To: Ole Troan Date: Fri, 6 Jan 2012 16:07:15 +0100 Thread-Topic: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt Thread-Index: AczMg35FW0vy8A1cSM+hHtkhhXfe+wAAFw7A Message-ID: <867F4B6A1672E541A94676D556793ACD0CB569544D@MOPESMBX01.eu.thmulti.com> References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com> <867F4B6A1672E541A94676D556793ACD0CB56952D5@MOPESMBX01.eu.thmulti.com> <8FFE15EA-B90E-4553-A776-7C2C5C221852@employees.org> <867F4B6A1672E541A94676D556793ACD0CB569536F@MOPESMBX01.eu.thmulti.com> <478BBBA2-3D32-4038-A5E4-CD886A417EB8@employees.org> <867F4B6A1672E541A94676D556793ACD0CB56953B7@MOPESMBX01.eu.thmulti.com> <1E00A66B-B0A3-4FFC-AF0E-ED3A2CACEA60@employees.org> <867F4B6A1672E541A94676D556793ACD0CB56953BE@MOPESMBX01.eu.thmulti.com> <2B940363-1E7B-45F9-9FB9-37E6691F57E2@employees.org> In-Reply-To: <2B940363-1E7B-45F9-9FB9-37E6691F57E2@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 15:13:55 -0000 Ole, >> if the network only offers addresses via DHCP, how does the network trig= ger the CPE to ask for an IA_NA? >> 6204 solution is to require the device to always ask. >> [Carl]Just configuration, nothing more, nothing less. If you want=20 >> ia_na, ask ia_na, if you don't, don't ask, no need to enforce this. Wha= t if you enforce ia_na and the server doesn't answer anyway ? Nothing acco= mplished. What if you ask ia_na and the server is configured as such to no= t hand-out anything if ia_na is requested (full match of requested options,= if not match fully: nak) Keep it simple, it's usually the best. If custom= er wants ia_na, configure the device as such, don't expect the CPE to do th= ese things "auto-magically" >=20 > this isn't up to the customer. it is a choice by the access network.=20 > and I don't think the "here is a fax from your ISP, just type in these=20 > parameters" scheme is the best we can do. ;-) >=20 > [Carl] True, but there will be no "fax" from the ISP to the customer eith= er to ask to switch something in configuration off either if it wouldn't wo= rk. Anyway, I'm always flexible, so I say make it a SHOULD iso MUST, meani= ng "you should ask it unless you have a good reason not to do so", no ?? the goal here is to specify a CPE that will work on any access network and = without any user configuration. note that this requirement is within an "if block", you only need to do thi= s if you don't want to wait for the RA with the M/O flags. [carl] Well, we've the ability to either listen to the RA or not; if not, y= ou decide (in fact it is the operator deciding in our deployment model) wha= t mode you want to run in, so firmware configuration for that operator will= either include or not include the ia_na option, no interference from user = needed. Thing is. If you don't listen/wait for the RA option, you fall ba= ck on configuration, so nothing happens "auto-magically"; it's just configu= ration. Our protocols can fully run independent, as they should, no coupli= ng unless specifically configured. It's not the first time, and probably n= ot the last :-), that I'm fighting for protocol de-coupling. And in our ca= se, no user configuration is needed, just plug the box in. Please note tha= t I think it's only in "Utopia" that all devices will work on all networks.= You're depending on the access side, you're depending on the used DHCPv6 = server, proxy, relay or whatever in use, hence the device works in 100% of = the cases is virtually impossible. Have a nice weekend Carl From fgont@si6networks.com Fri Jan 6 08:15:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB1321F8872 for ; Fri, 6 Jan 2012 08:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.373 X-Spam-Level: X-Spam-Status: No, score=-0.373 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDgwhYzyUseI for ; Fri, 6 Jan 2012 08:15:20 -0800 (PST) Received: from srv01.bbserve.nl (srv01.bbserve.nl [46.21.160.232]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE6521F876C for ; Fri, 6 Jan 2012 08:15:19 -0800 (PST) Received: from [190.48.248.59] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RjCRk-0003PO-6p; Fri, 06 Jan 2012 17:15:12 +0100 Message-ID: <4F06DD25.6080506@si6networks.com> Date: Fri, 06 Jan 2012 08:38:13 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: "Gunter Van de Velde (gvandeve)" References: <4F04F5CA.6010802@si6networks.com> <4269EA985EACD24987D82DAE2FEC62E504DA8736@XMB-AMS-101.cisco.com> <4F06C555.4020509@si6networks.com> <4269EA985EACD24987D82DAE2FEC62E504DA8754@XMB-AMS-101.cisco.com> In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E504DA8754@XMB-AMS-101.cisco.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] Revised I-D: Advice on RA-Guard Implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 16:15:20 -0000 Hi, Gunter, On 01/06/2012 07:34 AM, Gunter Van de Velde (gvandeve) wrote: > Hi Fernando, > > What i wrote to you in a 1-2-1 mail was: > [..] I was referring to the e-mails you sent me off-list right after this I-D was presented at the IETF meeting in July 2011. You not only agreed with pursuing this effort, but also put me in contact with one folk at Cisco, so that we'd "resubmit" the I-D together. I've just forwarded you those e-mails of list. I can copy an excerpt to the list, if you want. > I am just not sure it justifies a potential RFC, mainly because its well > known access-list avoidance. So essentially your saying that the IETF went through the effort of publishing RFC 6105 even when it was it was well-known that RA-Guard could be trivially evaded? -- Sorry, but I don't buy that. > I do agree that security section of RA-Guard is not detailed enough, > particular taking your > work into consideration, and i take blame for that. There's no "blame" to take. An specs is published, someone finds holes or "missing stuff", and it gets fixed. That's why we have the "update" metadata, after all, isn't it? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From v6ops@globis.net Sat Jan 7 04:44:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4AD21F850F for ; Sat, 7 Jan 2012 04:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUWIkax7Ft7j for ; Sat, 7 Jan 2012 04:44:04 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6B521F8507 for ; Sat, 7 Jan 2012 04:44:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id E78A68700AC; Sat, 7 Jan 2012 13:44:02 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net 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 NrPUVwok9uhw; Sat, 7 Jan 2012 13:43:49 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 16DFF87005C; Sat, 7 Jan 2012 13:43:49 +0100 (CET) Message-ID: <4F083E04.5050908@globis.net> Date: Sat, 07 Jan 2012 13:43:48 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: "STARK, BARBARA H" References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com><867F4B6A1672E541A94676D556793ACD0CB56952D5@MOPESMBX01.eu.thmulti.com><8FFE15EA-B90E-4553-A776-7C2C5C221852@employees.org><867F4B6A1672E541A94676D556793ACD0CB569536F@MOPESMBX01.eu.thmulti.com><478BBBA2-3D32-4038-A5E4-CD886A417EB8@employees.org><867F4B6A1672E541A94676D556793ACD0CB56953B7@MOPESMBX01.eu.thmulti.com><1E00A66B-B0A3-4FFC-AF0E-ED3A2CACEA60@employees.org> <867F4B6A1672E541A94676D556793ACD0CB56953BE@MOPESMBX01.eu.thmulti.com> <750BF7861EBBE048B3E648B4BB6E8F4F21CFE5E5@crexc50p> In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F21CFE5E5@crexc50p> Content-Type: multipart/alternative; boundary="------------040104030707030008050105" Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 12:44:05 -0000 This is a multi-part message in MIME format. --------------040104030707030008050105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Speaking as an end user of the Internet: and in the spirit of your comment on virtual interfaces, why should v6ops make life difficult for itself and get involved at all in corner cases where there is a conflict between what are essentially network operators' deployment decisions, and router vendors' engineering decisions? IMVVVVHO V6ops should not be defining technical workarounds for non-technical problems like the size of the PD assignment. Various authorities have bent over backwards to ensure that IPv6 addresses are globally plentiful and that they are "very much cheaper" than IPv4 addresses in terms of LIR fees. The equivalent billing in RIPE for an IPv4 /32 is an IPv6 /43. IMVHO assigning a single /64 IPv6 range per household seems unnecessarily mean and potentially harmful to transparent end-to-end connectivity on the Internet, possibly forcing end users to deploy complex prefix splitting beyond /64 within their CPE router and thus breaking SLAAC, or perhaps even worse, deploying NAT66. Perhaps the practical solution for 6204bis would be for v6ops to recommend that network operators delegate "sufficient addresses" to end user sites (as suggested earlier by Ole), and perhaps even going as far as recommending a minimum PD assignment of /60 or /56 for customers using 6204bis compliant equipment. The choice of /60 or /56 being based on the ability to potentially delegate reverse DNS, and to allow end users of the Internet to deploy flexible and reasonable local topologies e.g. a separate DMZ LAN interface on the CPE router (In 6204bis, an IPv6 CE router may have one or more network-layer LAN interfaces). Regards, RayH STARK, BARBARA H wrote: >>> if the network only offers addresses via DHCP, how does the network >>> >> trigger the CPE to ask for an IA_NA? >> >>> 6204 solution is to require the device to always ask. >>> [Carl]Just configuration, nothing more, nothing less. If you want >>> ia_na, ask ia_na, if you don't, don't ask, no need to enforce this. >>> >> What if you enforce ia_na and the server doesn't answer anyway ? >> Nothing accomplished. What if you ask ia_na and the server is >> configured as such to not hand-out anything if ia_na is requested >> > (full > >> match of requested options, if not match fully: nak) Keep it simple, >> it's usually the best. If customer wants ia_na, configure the device >> as such, don't expect the CPE to do these things "auto-magically" >> >> this isn't up to the customer. it is a choice by the access network. >> and I don't think the "here is a fax from your ISP, just type in these >> parameters" scheme is the best we can do. ;-) >> >> [Carl] True, but there will be no "fax" from the ISP to the customer >> either to ask to switch something in configuration off either if it >> wouldn't work. Anyway, I'm always flexible, so I say make it a SHOULD >> iso MUST, meaning "you should ask it unless you have a good reason not >> to do so", no ?? >> > > The current requirement means that the customer doesn't have to > know anything about the access network (SLAAC or DHCPv6 IA_NA or > unnumbered). When we created 6204, one of the core goals was to identify > requirements that would allow a customer to plug the CE router in and > not have to know what address assignment mechanism the access network > used. Changing WPD-5 from MUST to SHOULD would completely demolish that > goal. If someone doesn't want to design their CE router per 6204, then > there's absolutely nothing that says they have to. It's not a > "standard". But if someone wants to build a router that can come up > without user configuration when connected to an access network that does > either SLAAC or DHCPv6 IA_NA or unnumbered, then this is what the CE > router must do. If someone wants a separate RFC for CE routers intended > for a different environment, then that's fine, too. But 6204 is for the > CE router intended to work in the environment specified in 6204. > > As for the virtual interface comment -- my recollection of that was that > CE router designers wanted language that would basically let them put > that "unnumbered model" address wherever made sense for their box: LAN > interface, internal interface, logical interface, whatever. No need to > be specific, and leave it up to them. It just isn't the WAN interface > (because there's an RFC that says that's prohibited). From my > perspective, the CE router is a black box. If the access network > provides IA_PD, but no IA_NA and no SLAAC, then I want that CE router to > pick an address from a /64 of the IA_PD and be able to use that address > for sending/receiving traffic to/from the LAN/WAN (while making the > entire rest of that very same /64 available to the LAN for SLAAC). I > think that the new proposals (in the last few emails on this thread) to > split cases around when to put the address on a LAN interface and when > to put it on an internal interface based on =r> /64 in IA_PD go in > exactly the wrong direction. My experience has been that CE router > vendors are perfectly capable of determining the interface that makes > sense for their box. Realistically, the tests run at UNH-IOL wouldn't > check to see what interface the address is on. Because the specific > interface is not externally verifiable. The tests would check for (a) is > the device able to send/receive traffic to/from all ports (assuming LAN > isn't configured for multiple segments) using an address from the IA_PD, > and (b) does it also advertise the rest of that same /64 for use on the > LAN (SLAAC), and (c) do things just work after all this. > Barbara > > > --------------040104030707030008050105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Speaking as an end user of the Internet: and in the spirit of your comment on virtual interfaces, why should v6ops make life difficult for itself and get involved at all in corner cases where there is a conflict between what are essentially network operators' deployment decisions, and router vendors' engineering decisions? IMVVVVHO V6ops should not be defining technical workarounds for non-technical problems like the size of the PD assignment.

Various authorities have bent over backwards to ensure that IPv6 addresses are globally plentiful and that they are "very much cheaper" than IPv4 addresses in terms of LIR fees. The equivalent billing in RIPE for an IPv4 /32 is an IPv6 /43. IMVHO assigning a single /64 IPv6 range per household seems unnecessarily mean and potentially harmful to transparent end-to-end connectivity on the Internet, possibly forcing end users to deploy complex prefix splitting beyond /64 within their CPE router and thus breaking SLAAC, or perhaps even worse, deploying NAT66.

Perhaps the practical solution for 6204bis would be for v6ops to recommend that network operators delegate "sufficient addresses" to end user sites (as suggested earlier by Ole), and perhaps even going as far as recommending a minimum PD assignment of /60 or /56 for customers using 6204bis compliant equipment. The choice of /60 or /56 being based on the ability to potentially delegate reverse DNS, and to allow end users of the Internet to deploy flexible and reasonable local topologies e.g. a separate DMZ LAN interface on the CPE router (In 6204bis, an IPv6 CE router may have one or more network-layer LAN interfaces).

Regards,
RayH

STARK, BARBARA H wrote: 
if the network only offers addresses via DHCP, how does the network
      
trigger the CPE to ask for an IA_NA?
    
6204 solution is to require the device to always ask.
[Carl]Just configuration, nothing more, nothing less.  If you want
ia_na, ask ia_na, if you don't, don't ask, no need to enforce this.
      
What if you enforce ia_na and the server doesn't answer anyway ?
Nothing accomplished.  What if you ask ia_na and the server is
configured as such to not hand-out anything if ia_na is requested
    
(full
  
match of requested options, if not match fully: nak) Keep it simple,
it's usually the best.  If customer wants ia_na, configure the device
as such, don't expect the CPE to do these things "auto-magically"

this isn't up to the customer. it is a choice by the access network.
and I don't think the "here is a fax from your ISP, just type in these
parameters" scheme is the best we can do. ;-)

[Carl] True, but there will be no "fax" from the ISP to the customer
either to ask to switch something in configuration off either if it
wouldn't work.  Anyway, I'm always flexible, so I say make it a SHOULD
iso MUST, meaning "you should ask it unless you have a good reason not
to do so", no ??
    

<bhs> The current requirement means that the customer doesn't have to
know anything about the access network (SLAAC or DHCPv6 IA_NA or
unnumbered). When we created 6204, one of the core goals was to identify
requirements that would allow a customer to plug the CE router in and
not have to know what address assignment mechanism the access network
used. Changing WPD-5 from MUST to SHOULD would completely demolish that
goal. If someone doesn't want to design their CE router per 6204, then
there's absolutely nothing that says they have to. It's not a
"standard". But if someone wants to build a router that can come up
without user configuration when connected to an access network that does
either SLAAC or DHCPv6 IA_NA or unnumbered, then this is what the CE
router must do. If someone wants a separate RFC for CE routers intended
for a different environment, then that's fine, too. But 6204 is for the
CE router intended to work in the environment specified in 6204.

As for the virtual interface comment -- my recollection of that was that
CE router designers wanted language that would basically let them put
that "unnumbered model" address wherever made sense for their box: LAN
interface, internal interface, logical interface, whatever. No need to
be specific, and leave it up to them. It just isn't the WAN interface
(because there's an RFC that says that's prohibited). From my
perspective, the CE router is a black box. If the access network
provides IA_PD, but no IA_NA and no SLAAC, then I want that CE router to
pick an address from a /64 of the IA_PD and be able to use that address
for sending/receiving traffic to/from the LAN/WAN (while making the
entire rest of that very same /64 available to the LAN for SLAAC). I
think that the new proposals (in the last few emails on this thread) to
split cases around when to put the address on a LAN interface and when
to put it on an internal interface based on =r > /64 in IA_PD go in
exactly the wrong direction. My experience has been that CE router
vendors are perfectly capable of determining the interface that makes
sense for their box. Realistically, the tests run at UNH-IOL wouldn't
check to see what interface the address is on. Because the specific
interface is not externally verifiable. The tests would check for (a) is
the device able to send/receive traffic to/from all ports (assuming LAN
isn't configured for multiple segments) using an address from the IA_PD,
and (b) does it also advertise the rest of that same /64 for use on the
LAN (SLAAC), and (c) do things just work after all this.</bhs>
Barbara
--------------040104030707030008050105-- From internet-drafts@ietf.org Sun Jan 8 10:50:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6F521F851E; Sun, 8 Jan 2012 10:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JXSn4XVCa3f; Sun, 8 Jan 2012 10:50:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8420221F850C; Sun, 8 Jan 2012 10:50:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120108185055.18560.59579.idtracker@ietfa.amsl.com> Date: Sun, 08 Jan 2012 10:50:55 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-v6nd-problems-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 18:50:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : Operational Neighbor Discovery Problems Author(s) : Igor Gashinsky Joel Jaeggli Warren Kumari Filename : draft-ietf-v6ops-v6nd-problems-02.txt Pages : 13 Date : 2012-01-08 In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of Neighbor Discovery can be vulnerable to deliberate or accidental denial of service, whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial of attacks can be launched intentionally (by an attacker), or result from legitimate operational tools or accident conditions. As a result of these vulnerabilities, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing IPv6 transported flows may be interrupted. This document describes the potential for DOS in detail and suggests possible implementation improvements as well as operational mitigation techniques that can in some cases be used to protect against or at least alleviate the impact of such attacks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6nd-problems-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-v6nd-problems-02.txt From shemant@cisco.com Sun Jan 8 14:10:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0144021F84F4 for ; Sun, 8 Jan 2012 14:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.239 X-Spam-Level: X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hckfiUhdbDHS for ; Sun, 8 Jan 2012 14:09:57 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C386021F84F1 for ; Sun, 8 Jan 2012 14:09:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=4802; q=dns/txt; s=iport; t=1326060596; x=1327270196; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=jlQJeqqR/1RqcFBG4Ssu9CanEO4Qzy9jaYpqUnD2JM8=; b=MI7Zfe4fyQoRPMCfAI/9CeXP1iEWdgnVWHGV45/JFPthBLi09z79pLo+ Ycz8Y3ACrB7O+cx7senNT9ZSaAep0EzshUX6L4zb89pJij/9tigoO4uXY NJj3unfvn+UZFvfhsY45n1Z51+2oyFIRvzojclO+7E63HhJrWguOanNQs c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKATCk+tJXG+/2dsb2JhbAA4CqxFgQWBcgEBAQMBAQEBDwEdCjQLDAQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBMHh1gIlw0BnVgEiFaCWGMEiDmfKA X-IronPort-AV: E=Sophos;i="4.71,476,1320624000"; d="scan'208";a="49581859" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 08 Jan 2012 22:09:49 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q08M9mWl028812; Sun, 8 Jan 2012 22:09:48 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 Jan 2012 16:09:48 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 8 Jan 2012 16:09:46 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303B4034E@XMB-RCD-109.cisco.com> In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F21CFE5E5@crexc50p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt Thread-Index: AczMdXP9bvL1atLATqCJsW9Qpr5u7wAAA/GAAAHkilAAdQrOIA== References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com><867F4B6A1672E541A94676D556793ACD0CB56952D5@MOPESMBX01.eu.thmulti.com><8FFE15EA-B90E-4553-A776-7C2C5C221852@employees.org><867F4B6A1672E541A94676D556793ACD0CB569536F@MOPESMBX01.eu.thmulti.com><478BBBA2-3D32-4038-A5E4-CD886A417EB8@employees.org><867F4B6A1672E541A94676D556793ACD0CB56953B7@MOPESMBX01.eu.thmulti.com><1E00A66B-B0A3-4FFC-AF0E-ED3A2CACEA60@employees.org><867F4B6A1672E541A94676D556793ACD0CB56953BE@MOPESMBX01.eu.thmulti.com> <750BF7861EBBE048B3E648B4BB6E8F4F21CFE5E5@crexc50p> From: "Hemant Singh (shemant)" To: "STARK, BARBARA H" , "Wuyts Carl" , "Ole Troan" X-OriginalArrivalTime: 08 Jan 2012 22:09:48.0680 (UTC) FILETIME=[3CA22080:01CCCE52] Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 22:10:36 -0000 Carl, It would also be good to join the cpe router mailing list if you have so many comments on the document. Please email fred@cisco.com and he will add you to the mailer. All your questions have been closed in the design team mailer without changing any more text in the rfc6204bis document. An SP doling out an IA_PD of /64 length does not make sense. The device is an IPv6 router and it is so common for a router to create a virtual interface to source packets from.=20 Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of STARK, BARBARA H Sent: Friday, January 06, 2012 10:07 AM To: Wuyts Carl; Ole Troan Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt > > if the network only offers addresses via DHCP, how does the network > trigger the CPE to ask for an IA_NA? > > 6204 solution is to require the device to always ask. > > [Carl]Just configuration, nothing more, nothing less. If you want > > ia_na, ask ia_na, if you don't, don't ask, no need to enforce this. > What if you enforce ia_na and the server doesn't answer anyway ? > Nothing accomplished. What if you ask ia_na and the server is > configured as such to not hand-out anything if ia_na is requested (full > match of requested options, if not match fully: nak) Keep it simple, > it's usually the best. If customer wants ia_na, configure the device > as such, don't expect the CPE to do these things "auto-magically" >=20 > this isn't up to the customer. it is a choice by the access network. > and I don't think the "here is a fax from your ISP, just type in these > parameters" scheme is the best we can do. ;-) >=20 > [Carl] True, but there will be no "fax" from the ISP to the customer > either to ask to switch something in configuration off either if it > wouldn't work. Anyway, I'm always flexible, so I say make it a SHOULD > iso MUST, meaning "you should ask it unless you have a good reason not > to do so", no ?? The current requirement means that the customer doesn't have to know anything about the access network (SLAAC or DHCPv6 IA_NA or unnumbered). When we created 6204, one of the core goals was to identify requirements that would allow a customer to plug the CE router in and not have to know what address assignment mechanism the access network used. Changing WPD-5 from MUST to SHOULD would completely demolish that goal. If someone doesn't want to design their CE router per 6204, then there's absolutely nothing that says they have to. It's not a "standard". But if someone wants to build a router that can come up without user configuration when connected to an access network that does either SLAAC or DHCPv6 IA_NA or unnumbered, then this is what the CE router must do. If someone wants a separate RFC for CE routers intended for a different environment, then that's fine, too. But 6204 is for the CE router intended to work in the environment specified in 6204. As for the virtual interface comment -- my recollection of that was that CE router designers wanted language that would basically let them put that "unnumbered model" address wherever made sense for their box: LAN interface, internal interface, logical interface, whatever. No need to be specific, and leave it up to them. It just isn't the WAN interface (because there's an RFC that says that's prohibited). From my perspective, the CE router is a black box. If the access network provides IA_PD, but no IA_NA and no SLAAC, then I want that CE router to pick an address from a /64 of the IA_PD and be able to use that address for sending/receiving traffic to/from the LAN/WAN (while making the entire rest of that very same /64 available to the LAN for SLAAC). I think that the new proposals (in the last few emails on this thread) to split cases around when to put the address on a LAN interface and when to put it on an internal interface based on =3D or > /64 in IA_PD go in exactly the wrong direction. My experience has been that CE router vendors are perfectly capable of determining the interface that makes sense for their box. Realistically, the tests run at UNH-IOL wouldn't check to see what interface the address is on. Because the specific interface is not externally verifiable. The tests would check for (a) is the device able to send/receive traffic to/from all ports (assuming LAN isn't configured for multiple segments) using an address from the IA_PD, and (b) does it also advertise the rest of that same /64 for use on the LAN (SLAAC), and (c) do things just work after all this. Barbara _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Sun Jan 8 22:19:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4B121F849A for ; Sun, 8 Jan 2012 22:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.021 X-Spam-Level: X-Spam-Status: No, score=-106.021 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rE11FIL9diRJ for ; Sun, 8 Jan 2012 22:19:51 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4D00D21F845C for ; Sun, 8 Jan 2012 22:19:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=5403; q=dns/txt; s=iport; t=1326089991; x=1327299591; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=UBex10y/TAa2C8VElCxmoFahSIBpCCoPlhoWhy/oD9g=; b=BiW3SmTHQ3rcASEM6cGjTMjYN74C7NnQ8ayTceIYNmFFuU+U8ghfWb92 L0HcCAbvJ9UPfPoJeGQQK+3PbYMIndt98vzlVKDfgNEF0pTh1+fL3iijY me2g3J7/ragZEHDI1jqJ+IZnMkGnoaZZ31g36n9AWlkeFAV7HsdWL80Er 8=; X-IronPort-AV: E=Sophos;i="4.71,479,1320624000"; d="scan'208";a="24318312" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 09 Jan 2012 06:19:51 +0000 Received: from stealth-10-32-244-220.cisco.com (stealth-10-32-244-220.cisco.com [10.32.244.220]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q096JoQx030764; Mon, 9 Jan 2012 06:19:50 GMT Received: from [127.0.0.1] by stealth-10-32-244-220.cisco.com (PGP Universal service); Sun, 08 Jan 2012 22:19:50 -0800 X-PGP-Universal: processed; by stealth-10-32-244-220.cisco.com on Sun, 08 Jan 2012 22:19:50 -0800 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303B4034E@XMB-RCD-109.cisco.com> Date: Sun, 8 Jan 2012 22:19:19 -0800 Message-Id: <6610766D-5EAA-4CD4-9743-09B55DF813F0@cisco.com> References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com><867F4B6A1672E541A94676D556793ACD0CB56952D5@MOPESMBX01.eu.thmulti.com><8FFE15EA-B90E-4553-A776-7C2C5C221852@employees.org><867F4B6A1672E541A94676D556793ACD0CB569536F@MOPESMBX01.eu.thmulti.com><478BBBA2-3D32-4038-A5E4-CD886A417EB8@employees.org><867F4B6A1672E541A94676D556793ACD0CB56953B7@MOPESMBX01.eu.thmulti.com><1E00A66B-B0A3-4FFC-AF0E-ED3A2CACEA60@employees.org><867F4B6A1672E541A94676D556793ACD0CB56953BE@MOPESMBX01.eu.thmulti.com> <750BF7861EBBE048B3E648B4BB6E8F4F21CFE5E5@crexc50p> <5B6B2B64C9FE2A489045EEEADDAFF2C303B4034E@XMB-RCD-109.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops WG Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 06:19:52 -0000 I'll add him to the list. However, frankly, it would b good to be having = the discussions in the open as the draft is being finalized. It's a = working group document. On Jan 8, 2012, at 2:09 PM, Hemant Singh (shemant) wrote: > Carl, >=20 > It would also be good to join the cpe router mailing list if you have = so > many comments on the document. Please email fred@cisco.com and he = will > add you to the mailer. All your questions have been closed in the > design team mailer without changing any more text in the rfc6204bis > document. An SP doling out an IA_PD of /64 length does not make = sense. > The device is an IPv6 router and it is so common for a router to = create > a virtual interface to source packets from.=20 >=20 > Hemant >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of STARK, BARBARA H > Sent: Friday, January 06, 2012 10:07 AM > To: Wuyts Carl; Ole Troan > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt >=20 >>> if the network only offers addresses via DHCP, how does the network >> trigger the CPE to ask for an IA_NA? >>> 6204 solution is to require the device to always ask. >>> [Carl]Just configuration, nothing more, nothing less. If you want >>> ia_na, ask ia_na, if you don't, don't ask, no need to enforce this. >> What if you enforce ia_na and the server doesn't answer anyway ? >> Nothing accomplished. What if you ask ia_na and the server is >> configured as such to not hand-out anything if ia_na is requested > (full >> match of requested options, if not match fully: nak) Keep it simple, >> it's usually the best. If customer wants ia_na, configure the device >> as such, don't expect the CPE to do these things "auto-magically" >>=20 >> this isn't up to the customer. it is a choice by the access network. >> and I don't think the "here is a fax from your ISP, just type in = these >> parameters" scheme is the best we can do. ;-) >>=20 >> [Carl] True, but there will be no "fax" from the ISP to the customer >> either to ask to switch something in configuration off either if it >> wouldn't work. Anyway, I'm always flexible, so I say make it a = SHOULD >> iso MUST, meaning "you should ask it unless you have a good reason = not >> to do so", no ?? >=20 > The current requirement means that the customer doesn't have to > know anything about the access network (SLAAC or DHCPv6 IA_NA or > unnumbered). When we created 6204, one of the core goals was to = identify > requirements that would allow a customer to plug the CE router in and > not have to know what address assignment mechanism the access network > used. Changing WPD-5 from MUST to SHOULD would completely demolish = that > goal. If someone doesn't want to design their CE router per 6204, then > there's absolutely nothing that says they have to. It's not a > "standard". But if someone wants to build a router that can come up > without user configuration when connected to an access network that = does > either SLAAC or DHCPv6 IA_NA or unnumbered, then this is what the CE > router must do. If someone wants a separate RFC for CE routers = intended > for a different environment, then that's fine, too. But 6204 is for = the > CE router intended to work in the environment specified in 6204. >=20 > As for the virtual interface comment -- my recollection of that was = that > CE router designers wanted language that would basically let them put > that "unnumbered model" address wherever made sense for their box: LAN > interface, internal interface, logical interface, whatever. No need to > be specific, and leave it up to them. It just isn't the WAN interface > (because there's an RFC that says that's prohibited). =46rom my > perspective, the CE router is a black box. If the access network > provides IA_PD, but no IA_NA and no SLAAC, then I want that CE router = to > pick an address from a /64 of the IA_PD and be able to use that = address > for sending/receiving traffic to/from the LAN/WAN (while making the > entire rest of that very same /64 available to the LAN for SLAAC). I > think that the new proposals (in the last few emails on this thread) = to > split cases around when to put the address on a LAN interface and when > to put it on an internal interface based on =3D or > /64 in IA_PD go = in > exactly the wrong direction. My experience has been that CE router > vendors are perfectly capable of determining the interface that makes > sense for their box. Realistically, the tests run at UNH-IOL wouldn't > check to see what interface the address is on. Because the specific > interface is not externally verifiable. The tests would check for (a) = is > the device able to send/receive traffic to/from all ports (assuming = LAN > isn't configured for multiple segments) using an address from the = IA_PD, > and (b) does it also advertise the rest of that same /64 for use on = the > LAN (SLAAC), and (c) do things just work after all this. > Barbara >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Sun Jan 8 22:32:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9D021F866C for ; Sun, 8 Jan 2012 22:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.319 X-Spam-Level: X-Spam-Status: No, score=-106.319 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cM7QuzFPGRQS for ; Sun, 8 Jan 2012 22:32:57 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0238121F866B for ; Sun, 8 Jan 2012 22:32:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=614; q=dns/txt; s=iport; t=1326090777; x=1327300377; h=subject:mime-version:from:date:cc:reply-to:message-id:to: content-transfer-encoding; bh=kHl504r1MBgQO3Z2hEozsFeymge07xoNyzui9srZwQw=; b=b9EOA9peqNGc0KJDEw64ck8Tva4BPPjLh7yu80PFCBkoAdDhe3rcPRVy eIdSviKIrjzPhufQNu+rFRzkpYMrBa7uJntfRK0JwbYKqZg30gSfaKWgT 8IDxw+T0BuCa9n8wC/vEch6ejLsW89nwOrz8pYGc758BQqXMrP8doEHpq I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAK6JCk+rRDoH/2dsb2JhbABDrEiBBYILASc/gXOfDwGdd4h3gjdjBIg5jFCFUY0J X-IronPort-AV: E=Sophos;i="4.71,479,1320624000"; d="scan'208";a="24414180" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 09 Jan 2012 06:32:56 +0000 Received: from stealth-10-32-244-220.cisco.com (stealth-10-32-244-220.cisco.com [10.32.244.220]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q096WuL5028189; Mon, 9 Jan 2012 06:32:56 GMT Received: from [127.0.0.1] by stealth-10-32-244-220.cisco.com (PGP Universal service); Sun, 08 Jan 2012 22:32:56 -0800 X-PGP-Universal: processed; by stealth-10-32-244-220.cisco.com on Sun, 08 Jan 2012 22:32:56 -0800 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker Date: Sun, 8 Jan 2012 22:32:26 -0800 Message-Id: <2AD7A9CB-A67C-41CD-8F9F-664EBBE4E880@cisco.com> To: v6ops@ietf.org X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops-chairs@tools.ietf.org, Ron Bonica Subject: [v6ops] draft-ietf-v6ops-v6nd-problems WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: v6ops v6ops WG List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 06:32:57 -0000 This is to initiate a two week working group last call of = draft-ietf-v6ops-v6nd-problems. Please read it now. If you find nits = (spelling errors, minor suggested wording changes, etc), comment to the = authors; if you find greater issues, such as disagreeing with a = statement or finding additional issues that need to be addressed, please = post your comments to the list. We are looking specifically for comments on the importance of the = document as well as its content. If you have read the document and = believe it to be of operational utility, that is also an important = comment to make.= From Carl.Wuyts@technicolor.com Sun Jan 8 23:16:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C2921F84F6 for ; Sun, 8 Jan 2012 23:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.183 X-Spam-Level: X-Spam-Status: No, score=-6.183 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sj8i909GDP2p for ; Sun, 8 Jan 2012 23:16:05 -0800 (PST) Received: from na3sys009aog116.obsmtp.com (na3sys009aog116.obsmtp.com [74.125.149.240]) by ietfa.amsl.com (Postfix) with ESMTP id B7BC921F84E7 for ; Sun, 8 Jan 2012 23:15:59 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob116.postini.com ([74.125.148.12]) with SMTP ID DSNKTwqUIrlWzWgowxRHhRhxQeVuxtFO9F0p@postini.com; Sun, 08 Jan 2012 23:16:03 PST Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 9 Jan 2012 08:15:42 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.20]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Mon, 9 Jan 2012 08:15:44 +0100 From: Wuyts Carl To: Ray Hunter , "STARK, BARBARA H" Date: Mon, 9 Jan 2012 08:15:41 +0100 Thread-Topic: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt Thread-Index: AczNOgwqFdWfvcPlShSmwOqFVV6b9QBYC7AA Message-ID: <867F4B6A1672E541A94676D556793ACD0CB6819DC3@MOPESMBX01.eu.thmulti.com> References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com><867F4B6A1672E541A94676D556793ACD0CB56952D5@MOPESMBX01.eu.thmulti.com><8FFE15EA-B90E-4553-A776-7C2C5C221852@employees.org><867F4B6A1672E541A94676D556793ACD0CB569536F@MOPESMBX01.eu.thmulti.com><478BBBA2-3D32-4038-A5E4-CD886A417EB8@employees.org><867F4B6A1672E541A94676D556793ACD0CB56953B7@MOPESMBX01.eu.thmulti.com><1E00A66B-B0A3-4FFC-AF0E-ED3A2CACEA60@employees.org> <867F4B6A1672E541A94676D556793ACD0CB56953BE@MOPESMBX01.eu.thmulti.com> <750BF7861EBBE048B3E648B4BB6E8F4F21CFE5E5@crexc50p> <4F083E04.5050908@globis.net> In-Reply-To: <4F083E04.5050908@globis.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_867F4B6A1672E541A94676D556793ACD0CB6819DC3MOPESMBX01eut_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 07:16:11 -0000 --_000_867F4B6A1672E541A94676D556793ACD0CB6819DC3MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well, seems like my comments are being taken the "wrong" way. To come back on Barbara's comments: "" The current requirement means that the customer doesn't have to know = anything about the access network (SLAAC or DHCPv6 IA_NA or unnumbered). [Carl] I agree When we created 6204, one of the core goals was to identify requirements th= at would allow a customer to plug the CE router in and not have to know wha= t address assignment mechanism the access network used. [Carl] I agree Changing WPD-5 from MUST to SHOULD would completely demolish that goal. If = someone doesn't want to design their CE router per 6204, then there's absol= utely nothing that says they have to. It's not a "standard". But if someone= wants to build a router that can come up without user configuration when c= onnected to an access network that does either SLAAC or DHCPv6 IA_NA or unn= umbered, then this is what the CE router must do. [Carl But I do not agree on this one. You want a "user configuration" that = either does SLAAC, DHCP_IA_NA or unnumbered. In your opinion, this must be= done from a single configuration (no end-user interference, so from "facto= ry defaults"). So, the CPE must either able to "sense" the configuration o= r just request all of the possible things ?? Sorry, but not a good idea. = So, how must the CPE "sense" this and request the appropriate configuration= ? Listen to RA ? Fine, although you would run into problems when, on a c= ertain link (just say e.g. PPP), nothing would be received, what would you = do with that ? No RA received, so ask IA_NA ? Fine again, but what if the= DHCPv6 server does not provide anything ? Then you'd swap to "unnumbered"= ? What interface are you going to use to put an address from ia_pd onto ?= Play "safe" and put it on Lan interface (just to avoid issues if ia_pd = =3D 64) ? This maybe sounds ok for you, but in fact it's not. Suppose the CPE has be= en configured with all of the above, you might end with both putting an add= ress from ia_pd on top of an interface (no matter lan or virtual), which is= ok for me, but what if you end up in a situation, where the DHCPv6 server = does not return anything unless you ask for a specific set of DHCPv6 option= s and if not, no info would be sent ? In that case, you're CPE ends up wit= h ... no configuration at all, only link local addresses. What if your acc= ess network would support SLAAC, so you get a prefix on the WAN intf trough= SLAAC, but at the same time, you're also asking IA_NA, so might get that o= ne too + you put a prefix from ia_pa too ? It can still work, but not sure= this would be the best idea though. So no matter how much more things you're adding for the CPE, you will never= have a 100% coverage. If someone wants a separate RFC for CE routers intended for a different env= ironment, then that's fine, too. But 6204 is for the CE router intended to = work in the environment specified in 6204. "" And on the one of "virtual intfs": I can of course only agree that CPE vendors are perfectly capable of decidi= ng for the appropriate intf to put an address from ia_pa on top off, howeve= r, if your req in RFC6204 uses "virtual interface" then I'd say your req c= an never be met in case of ia_pd length =3D 64. If you want to keep using = this exact phrasing, then it is wrong. So, if you know state it does not m= atter what terminology is being used, then I'm wondering why RFcs keep both= ering to use lan, wan virtual, ... ??? On the comments from Ray on usage of /64 ia_pd length: I can only say it is allowed. I don't say it is a good idea, I don't say w= e recommend it, but it's being used in the real world, so we're facing it f= rom day to day (again, it's residential market, and we have to cope with th= ose too, as after all, it is valid to use /64). And although you might con= sider this to be a "corner case", which I don't think is really the case, t= hen I would imagine it should still be possible to use the RFC, no ? If no= t, a statement must be added to the RFC that this is only to be applied if = your CPE is using ia_pd lengths of < 64, which goes in against the basic IP= v6 RFCs I'd say. Regs Carl From: Ray Hunter [mailto:v6ops@globis.net] Sent: zaterdag 7 januari 2012 13:44 To: STARK, BARBARA H Cc: Wuyts Carl; Ole Troan; v6ops@ietf.org Subject: Re: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt Speaking as an end user of the Internet: and in the spirit of your comment = on virtual interfaces, why should v6ops make life difficult for itself and = get involved at all in corner cases where there is a conflict between what = are essentially network operators' deployment decisions, and router vendors= ' engineering decisions? IMVVVVHO V6ops should not be defining technical wo= rkarounds for non-technical problems like the size of the PD assignment. Various authorities have bent over backwards to ensure that IPv6 addresses = are globally plentiful and that they are "very much cheaper" than IPv4 addr= esses in terms of LIR fees. The equivalent billing in RIPE for an IPv4 /32 = is an IPv6 /43. IMVHO assigning a single /64 IPv6 range per household seems= unnecessarily mean and potentially harmful to transparent end-to-end conne= ctivity on the Internet, possibly forcing end users to deploy complex prefi= x splitting beyond /64 within their CPE router and thus breaking SLAAC, or = perhaps even worse, deploying NAT66. Perhaps the practical solution for 6204bis would be for v6ops to recommend = that network operators delegate "sufficient addresses" to end user sites (a= s suggested earlier by Ole), and perhaps even going as far as recommending = a minimum PD assignment of /60 or /56 for customers using 6204bis compliant= equipment. The choice of /60 or /56 being based on the ability to potentia= lly delegate reverse DNS, and to allow end users of the Internet to deploy = flexible and reasonable local topologies e.g. a separate DMZ LAN interface = on the CPE router (In 6204bis, an IPv6 CE router may have one or more netwo= rk-layer LAN interfaces). Regards, RayH STARK, BARBARA H wrote: if the network only offers addresses via DHCP, how does the network trigger the CPE to ask for an IA_NA? 6204 solution is to require the device to always ask. [Carl]Just configuration, nothing more, nothing less. If you want ia_na, ask ia_na, if you don't, don't ask, no need to enforce this. What if you enforce ia_na and the server doesn't answer anyway ? Nothing accomplished. What if you ask ia_na and the server is configured as such to not hand-out anything if ia_na is requested (full match of requested options, if not match fully: nak) Keep it simple, it's usually the best. If customer wants ia_na, configure the device as such, don't expect the CPE to do these things "auto-magically" this isn't up to the customer. it is a choice by the access network. and I don't think the "here is a fax from your ISP, just type in these parameters" scheme is the best we can do. ;-) [Carl] True, but there will be no "fax" from the ISP to the customer either to ask to switch something in configuration off either if it wouldn't work. Anyway, I'm always flexible, so I say make it a SHOULD iso MUST, meaning "you should ask it unless you have a good reason not to do so", no ?? The current requirement means that the customer doesn't have to know anything about the access network (SLAAC or DHCPv6 IA_NA or unnumbered). When we created 6204, one of the core goals was to identify requirements that would allow a customer to plug the CE router in and not have to know what address assignment mechanism the access network used. Changing WPD-5 from MUST to SHOULD would completely demolish that goal. If someone doesn't want to design their CE router per 6204, then there's absolutely nothing that says they have to. It's not a "standard". But if someone wants to build a router that can come up without user configuration when connected to an access network that does either SLAAC or DHCPv6 IA_NA or unnumbered, then this is what the CE router must do. If someone wants a separate RFC for CE routers intended for a different environment, then that's fine, too. But 6204 is for the CE router intended to work in the environment specified in 6204. As for the virtual interface comment -- my recollection of that was that CE router designers wanted language that would basically let them put that "unnumbered model" address wherever made sense for their box: LAN interface, internal interface, logical interface, whatever. No need to be specific, and leave it up to them. It just isn't the WAN interface (because there's an RFC that says that's prohibited). From my perspective, the CE router is a black box. If the access network provides IA_PD, but no IA_NA and no SLAAC, then I want that CE router to pick an address from a /64 of the IA_PD and be able to use that address for sending/receiving traffic to/from the LAN/WAN (while making the entire rest of that very same /64 available to the LAN for SLAAC). I think that the new proposals (in the last few emails on this thread) to split cases around when to put the address on a LAN interface and when to put it on an internal interface based on =3Dr > /64 in IA_PD go in exactly the wrong direction. My experience has been that CE router vendors are perfectly capable of determining the interface that makes sense for their box. Realistically, the tests run at UNH-IOL wouldn't check to see what interface the address is on. Because the specific interface is not externally verifiable. The tests would check for (a) is the device able to send/receive traffic to/from all ports (assuming LAN isn't configured for multiple segments) using an address from the IA_PD, and (b) does it also advertise the rest of that same /64 for use on the LAN (SLAAC), and (c) do things just work after all this. Barbara --_000_867F4B6A1672E541A94676D556793ACD0CB6819DC3MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Well, seems like my comments are being taken the “wrong”= way.

 

To come back on Barbara’s comment= s:

“”

<bhs> The current requirement me= ans that the customer doesn't have to know anything about the access networ= k (SLAAC or DHCPv6 IA_NA or unnumbered).

[Carl] I agree

When we created 6= 204, one of the core goals was to identify requirements that would allow a = customer to plug the CE router in and not have to know what address assignm= ent mechanism the access network used.

[Carl] I agree

Changing WPD-5 from = MUST to SHOULD would completely demolish that goal. If someone doesn't want= to design their CE router per 6204, then there's absolutely nothing that s= ays they have to. It's not a "standard". But if someone wants to = build a router that can come up without user configuration when connected t= o an access network that does either SLAAC or DHCPv6 IA_NA or unnumbered, t= hen this is what the CE router must do.

[Carl But I do not agree on this one. You want a “user configurati= on” that either does SLAAC, DHCP_IA_NA or unnumbered.  In your o= pinion, this must be done from a single configuration (no end-user interfer= ence, so from “factory defaults”).  So, the CPE must eithe= r able to “sense” the configuration or just request all of the = possible things ??  Sorry, but not a good idea.  So, how must the= CPE “sense” this and request the appropriate configuration ?&n= bsp; Listen to RA ?  Fine, although you would run into problems when, = on a certain link (just say e.g. PPP), nothing would be received, what woul= d you do with that ?  No RA received, so ask IA_NA ?  Fine again,= but what if the DHCPv6 server does not provide anything ?  Then you&#= 8217;d swap to “unnumbered” ?  What interface are you goin= g to use to put an address from ia_pd onto ?  Play “safe” = and put it on Lan interface (just to avoid issues if ia_pd =3D 64) ?

This maybe sounds ok for you, but in fact i= t’s not.  Suppose the CPE has been configured with all of the ab= ove, you might end with both putting an address from ia_pd on top of an int= erface (no matter lan or virtual), which is ok for me, but what if you end = up in a situation, where the DHCPv6 server does not return anything unless = you ask for a specific set of DHCPv6 options and if not, no info would be s= ent ?  In that case, you’re CPE ends up with … no configur= ation at all, only link local addresses.  What if your access network = would support SLAAC, so you get a prefix on the WAN intf trough SLAAC, but = at the same time, you’re also asking IA_NA, so might get that one too= + you put a prefix from ia_pa too ?  It can still work, but not sure = this would be the best idea though.

S= o no matter how much more things you’re adding for the CPE, you will = never have a 100% coverage.

&nbs= p;

If someone wants a separate RFC for CE = routers intended for a different environment, then that's fine, too. But 62= 04 is for the CE router intended to work in the environment specified in 62= 04.

“”

And on the one of “virtual intfs&#= 8221;:

I can of course onl= y agree that CPE vendors are perfectly capable of deciding for the appropri= ate intf to put an address from ia_pa on top off, however, if your req in R= FC6204 uses “virtual interface” then  I’d say your r= eq can never be met in case of ia_pd length =3D 64.  If you want to ke= ep using this exact phrasing, then it is wrong.  So, if you know state= it does not matter what terminology is being used, then I’m wonderin= g why RFcs keep bothering to use lan, wan virtual, … ???

 

On the comments from Ray on usage of /64 ia_pd length:<= o:p>

I can only say it is allow= ed.  I don’t say it is a good idea, I don’t say we recomme= nd it, but it’s being used in the real world, so we’re facing i= t from day to day (again, it’s residential market, and we have to cop= e with those too, as after all, it is valid to use /64).  And although= you might consider this to be a “corner case”, which I donR= 17;t think is really the case, then I would imagine it should still be poss= ible to use the RFC, no ?  If not, a statement must be added to the RF= C that this is only to be applied if your CPE is using ia_pd lengths of <= ; 64, which goes in against the basic IPv6 RFCs I’d say.

 

Regs

C= arl

 

 

 

 

Fr= om: Ray Hunter [mailto:v6ops@globis.net]
Sent: zaterdag 7 januari 2012 13:44
To: STARK, BARBARA H
Cc: Wuyts Carl; Ole Troan; v6ops@ietf.org
Subject: Re: Re: [v6ops]= Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt

 

Spea= king as an end user of the Internet: and in the spirit of your comment on v= irtual interfaces, why should v6ops make life difficult for itself and get = involved at all in corner cases where there is a conflict between what are = essentially network operators' deployment decisions, and router vendors' en= gineering decisions? IMVVVVHO V6ops should not be defining technical workar= ounds for non-technical problems like the size of the PD assignment.
Various authorities have bent over backwards to ensure that IPv6 addresses= are globally plentiful and that they are "very much cheaper" tha= n IPv4 addresses in terms of LIR fees. The equivalent billing in RIPE for a= n IPv4 /32 is an IPv6 /43. IMVHO assigning a single /64 IPv6 range per hous= ehold seems unnecessarily mean and potentially harmful to transparent end-t= o-end connectivity on the Internet, possibly forcing end users to deploy co= mplex prefix splitting beyond /64 within their CPE router and thus breaking= SLAAC, or perhaps even worse, deploying NAT66.

Perhaps the practica= l solution for 6204bis would be for v6ops to recommend that network operato= rs delegate "sufficient addresses" to end user sites (as suggeste= d earlier by Ole), and perhaps even going as far as recommending a minimum = PD assignment of /60 or /56 for customers using 6204bis compliant equipment= . The choice of /60 or /56 being based on the ability to potentially delega= te reverse DNS, and to allow end users of the Internet to deploy flexible a= nd reasonable local topologies e.g. a separate DMZ LAN interface on the CPE= router (In 6204bis, an IPv6 CE router may have one or more network-layer L= AN interfaces).

Regards,
RayH

STARK, BARBARA H wrote: 

if the network o=
nly offers addresses via DHCP, how does the network
&n=
bsp;     
trigger the=
 CPE to ask for an IA_NA?
    
620=
4 solution is to require the device to always ask.
[Ca=
rl]Just configuration, nothing more, nothing less.  If you want
ia_na, ask ia_na, if you don't, don't ask, no need to enforc=
e this.
      
What if you enforce ia_na and the server doesn't answer=
 anyway ?
Nothing accomplished.  What if you ask =
ia_na and the server is
configured as such to not hand=
-out anything if ia_na is requested
   =
 
(full
  =
match of requested options, if not match fully: nak) Keep it simple,<= /o:p>
it's usually the best.  If customer wants ia_na, confi=
gure the device
as such, don't expect the CPE to do th=
ese things "auto-magically"
 
this isn't up to the customer. it is a choice by the access net=
work.
and I don't think the "here is a fax from y=
our ISP, just type in these
parameters" scheme is=
 the best we can do. ;-)
 
[=
Carl] True, but there will be no "fax" from the ISP to the custom=
er
either to ask to switch something in configuration =
off either if it
wouldn't work.  Anyway, I'm alwa=
ys flexible, so I say make it a SHOULD
iso MUST, meani=
ng "you should ask it unless you have a good reason not
to do so", no ??
    <=
/o:p>
 
<bhs> The cu=
rrent requirement means that the customer doesn't have to
<= pre>know anything about the access network (SLAAC or DHCPv6 IA_NA or
unnumbered). When we created 6204, one of the core goals was=
 to identify
requirements that would allow a customer =
to plug the CE router in and
not have to know what add=
ress assignment mechanism the access network
used. Cha=
nging WPD-5 from MUST to SHOULD would completely demolish that
goal. If someone doesn't want to design their CE router per 6204, =
then
there's absolutely nothing that says they have to=
. It's not a
"standard". But if someone want=
s to build a router that can come up
without user conf=
iguration when connected to an access network that does
either SLAAC or DHCPv6 IA_NA or unnumbered, then this is what the CE=

router must do. If someone wants a separate RFC for CE rou=
ters intended
for a different environment, then that's=
 fine, too. But 6204 is for the
CE router intended to =
work in the environment specified in 6204.
 =

As for the virtual interface comment -- my recollection of=
 that was that
CE router designers wanted language tha=
t would basically let them put
that "unnumbered m=
odel" address wherever made sense for their box: LAN
<= pre>interface, internal interface, logical interface, whatever. No need to<= o:p>
be specific, and leave it up to them. It just isn't th=
e WAN interface
(because there's an RFC that says that=
's prohibited). From my
perspective, the CE router is =
a black box. If the access network
provides IA_PD, but=
 no IA_NA and no SLAAC, then I want that CE router to
=
pick an address from a /64 of the IA_PD and be able to use that address
for sending/receiving traffic to/from the LAN/WAN (while =
making the
entire rest of that very same /64 available=
 to the LAN for SLAAC). I
think that the new proposals=
 (in the last few emails on this thread) to
split case=
s around when to put the address on a LAN interface and when
to put it on an internal interface based on =3Dr > /64 in IA_PD g=
o in
exactly the wrong direction. My experience has be=
en that CE router
vendors are perfectly capable of det=
ermining the interface that makes
sense for their box.=
 Realistically, the tests run at UNH-IOL wouldn't
chec=
k to see what interface the address is on. Because the specific<=
/pre>
interface is not externally verifiable. The tests would check for=
 (a) is
the device able to send/receive traffic to/fro=
m all ports (assuming LAN
isn't configured for multipl=
e segments) using an address from the IA_PD,
and (b) d=
oes it also advertise the rest of that same /64 for use on the
LAN (SLAAC), and (c) do things just work after all this.</bhs&g=
t;
Barbara
 
 
 
= --_000_867F4B6A1672E541A94676D556793ACD0CB6819DC3MOPESMBX01eut_-- From fgont@si6networks.com Mon Jan 9 01:59:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384FD21F8699 for ; Mon, 9 Jan 2012 01:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=-0.664, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7azjH0q93Jr5 for ; Mon, 9 Jan 2012 01:59:44 -0800 (PST) Received: from srv01.bbserve.nl (srv01.bbserve.nl [46.21.160.232]) by ietfa.amsl.com (Postfix) with ESMTP id 86AF121F8697 for ; Mon, 9 Jan 2012 01:59:44 -0800 (PST) Received: from [186.137.77.114] (helo=[192.168.1.106]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RkC0y-0001mC-Ne; Mon, 09 Jan 2012 10:59:41 +0100 Message-ID: <4F0A4D7F.6000101@si6networks.com> Date: Sun, 08 Jan 2012 23:14:23 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Simon Perreault References: <4F04F5CA.6010802@si6networks.com> <4F05AA98.4090400@viagenie.ca> In-Reply-To: <4F05AA98.4090400@viagenie.ca> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Revised I-D: Advice on RA-Guard Implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 09:59:45 -0000 Hi, Simon, Thanks so much for your feedback! Please find my comments in-line... On 01/05/2012 10:50 AM, Simon Perreault wrote: > Fernando Gont wrote, on 01/04/2012 07:58 PM: >> We've published the IETF I-D "Implementation Advice for IPv6 Router >> Advertisement Guard (RA-Guard)". It is available at: >> > > Section 3 (implementation advice) does not explicitly mention fragment handling. > Is this intentional? Does the advice implicitly apply to fragments? Some > clarification is needed IMHO. The second bullet in Section 3 is meant to address fragment-handling: o If the layer-2 device is unable to identify whether the packet is an ICMPv6 Router Advertisement message or not (i.e., the packet is a fragment, and the necessary information is missing), and the IPv6 Source Address of the packet is a link-local address or the unspecified address (::), block the packet. The idea is that if that non-first fragments are always forwarded, whereas first-fragments are blocked if: a) We've found that what follows the fragment header is an RA packet, or, b) this is a first-fragment, and it is missing upper-layer protocol information. Please let me know if you still feel that further clarification is needed. And, if so, whether you feel that an additional bullet should be added, or whether the aforementioned clarification should be added right after the bullets (i.e., non-bulleted). Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From pch-b29AA871B@u-1.phicoh.com Mon Jan 9 03:46:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658D321F8701 for ; Mon, 9 Jan 2012 03:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11jzGovfXVHY for ; Mon, 9 Jan 2012 03:46:29 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 96C2C21F8700 for ; Mon, 9 Jan 2012 03:46:28 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1RkDRk-0001ZiC; Mon, 9 Jan 2012 12:31:24 +0100 Message-Id: To: Fernando Gont From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <4F04F5CA.6010802@si6networks.com> <4F05AA98.4090400@viagenie.ca> <4F0A4D7F.6000101@si6networks.com> In-reply-to: Your message of "Sun, 08 Jan 2012 23:14:23 -0300 ." <4F0A4D7F.6000101@si6networks.com> Date: Mon, 09 Jan 2012 12:31:22 +0100 Cc: v6ops@ietf.org Subject: Re: [v6ops] Revised I-D: Advice on RA-Guard Implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 11:46:29 -0000 In your letter dated Sun, 08 Jan 2012 23:14:23 -0300 you wrote: >The idea is that if that non-first fragments are always forwarded, >whereas first-fragments are blocked if: > >a) We've found that what follows the fragment header is an RA packet, or, > >b) this is a first-fragment, and it is missing upper-layer protocol >information. In theory (when it comes to RA or other ND packets) it should be secure to let the fragment through if the hop count is not equal to 255. From bs7652@att.com Mon Jan 9 06:57:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF55C21F87AC for ; Mon, 9 Jan 2012 06:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.758 X-Spam-Level: X-Spam-Status: No, score=-105.758 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkYZeWOIFyub for ; Mon, 9 Jan 2012 06:57:04 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id A524421F873E for ; Mon, 9 Jan 2012 06:57:04 -0800 (PST) X-Env-Sender: bs7652@att.com X-Msg-Ref: server-3.tower-120.messagelabs.com!1326121021!57533248!1 X-Originating-IP: [144.160.20.146] X-StarScan-Version: 6.4.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8879 invoked from network); 9 Jan 2012 14:57:02 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-3.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Jan 2012 14:57:02 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q09EtVJj003794; Mon, 9 Jan 2012 09:55:32 -0500 Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q09EtNPp003496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jan 2012 09:55:23 -0500 Received: from 01AL10015010627.AD.BLS.COM (01AL10015010627.ad.bls.com [90.152.44.196]) by sflint04.pst.cso.att.com (RSA Interceptor); Mon, 9 Jan 2012 09:56:37 -0500 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01AL10015010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Jan 2012 08:55:42 -0600 Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Jan 2012 09:55:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCCEDE.C1CA3BDA" Date: Mon, 9 Jan 2012 09:56:33 -0500 Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F21CFEB81@crexc50p> In-Reply-To: <4F083E04.5050908@globis.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt Thread-Index: AczNOexWI2RPFe33T5GFQA1THBxtegBodZtg References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com><867F4B6A1672E541A94676D556793ACD0CB56952D5@MOPESMBX01.eu.thmulti.com><8FFE15EA-B90E-4553-A776-7C2C5C221852@employees.org><867F4B6A1672E541A94676D556793ACD0CB569536F@MOPESMBX01.eu.thmulti.com><478BBBA2-3D32-4038-A5E4-CD886A417EB8@employees.org><867F4B6A1672E541A94676D556793ACD0CB56953B7@MOPESMBX01.eu.thmulti.com><1E00A66B-B0A3-4FFC-AF0E-ED3A2CACEA60@employees.org> <867F4B6A1672E541A94676D556793ACD0CB56953BE@MOPESMBX01.eu.thmulti.com> <750BF7861EBBE048B3E648B4BB6E8F4F21CFE5E5@crexc50p> <4F083E04.5050908@globis.net> From: "STARK, BARBARA H" To: "Ray Hunter" X-OriginalArrivalTime: 09 Jan 2012 14:55:41.0737 (UTC) FILETIME=[C1DBC990:01CCCEDE] X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 14:57:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCCEDE.C1CA3BDA Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable 6204bis is a CE router requirements document. Not an operator requirements document.=20 RFC 6177 provides guidance regarding assignment of IPv6 prefixes to end sites. Since this RFC already exists, and was recently published, I see no need to try to write it again at this time. Barbara =20 From: Ray Hunter [mailto:v6ops@globis.net]=20 Sent: Saturday, January 07, 2012 7:44 AM To: STARK, BARBARA H Cc: Wuyts Carl; Ole Troan; v6ops@ietf.org Subject: Re: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt =20 Speaking as an end user of the Internet: and in the spirit of your comment on virtual interfaces, why should v6ops make life difficult for itself and get involved at all in corner cases where there is a conflict between what are essentially network operators' deployment decisions, and router vendors' engineering decisions? IMVVVVHO V6ops should not be defining technical workarounds for non-technical problems like the size of the PD assignment. Various authorities have bent over backwards to ensure that IPv6 addresses are globally plentiful and that they are "very much cheaper" than IPv4 addresses in terms of LIR fees. The equivalent billing in RIPE for an IPv4 /32 is an IPv6 /43. IMVHO assigning a single /64 IPv6 range per household seems unnecessarily mean and potentially harmful to transparent end-to-end connectivity on the Internet, possibly forcing end users to deploy complex prefix splitting beyond /64 within their CPE router and thus breaking SLAAC, or perhaps even worse, deploying NAT66. Perhaps the practical solution for 6204bis would be for v6ops to recommend that network operators delegate "sufficient addresses" to end user sites (as suggested earlier by Ole), and perhaps even going as far as recommending a minimum PD assignment of /60 or /56 for customers using 6204bis compliant equipment. The choice of /60 or /56 being based on the ability to potentially delegate reverse DNS, and to allow end users of the Internet to deploy flexible and reasonable local topologies e.g. a separate DMZ LAN interface on the CPE router (In 6204bis, an IPv6 CE router may have one or more network-layer LAN interfaces). Regards, RayH STARK, BARBARA H wrote:=20 if the network only offers addresses via DHCP, how does the network =20 trigger the CPE to ask for an IA_NA? =20 6204 solution is to require the device to always ask. [Carl]Just configuration, nothing more, nothing less. If you want ia_na, ask ia_na, if you don't, don't ask, no need to enforce this. =20 What if you enforce ia_na and the server doesn't answer anyway ? Nothing accomplished. What if you ask ia_na and the server is configured as such to not hand-out anything if ia_na is requested =20 (full =20 match of requested options, if not match fully: nak) Keep it simple, it's usually the best. If customer wants ia_na, configure the device as such, don't expect the CPE to do these things "auto-magically" =20 this isn't up to the customer. it is a choice by the access network. and I don't think the "here is a fax from your ISP, just type in these parameters" scheme is the best we can do. ;-) =20 [Carl] True, but there will be no "fax" from the ISP to the customer either to ask to switch something in configuration off either if it wouldn't work. Anyway, I'm always flexible, so I say make it a SHOULD iso MUST, meaning "you should ask it unless you have a good reason not to do so", no ?? =20 =20 The current requirement means that the customer doesn't have to know anything about the access network (SLAAC or DHCPv6 IA_NA or unnumbered). When we created 6204, one of the core goals was to identify requirements that would allow a customer to plug the CE router in and not have to know what address assignment mechanism the access network used. Changing WPD-5 from MUST to SHOULD would completely demolish that goal. If someone doesn't want to design their CE router per 6204, then there's absolutely nothing that says they have to. It's not a "standard". But if someone wants to build a router that can come up without user configuration when connected to an access network that does either SLAAC or DHCPv6 IA_NA or unnumbered, then this is what the CE router must do. If someone wants a separate RFC for CE routers intended for a different environment, then that's fine, too. But 6204 is for the CE router intended to work in the environment specified in 6204. =20 As for the virtual interface comment -- my recollection of that was that CE router designers wanted language that would basically let them put that "unnumbered model" address wherever made sense for their box: LAN interface, internal interface, logical interface, whatever. No need to be specific, and leave it up to them. It just isn't the WAN interface (because there's an RFC that says that's prohibited). From my perspective, the CE router is a black box. If the access network provides IA_PD, but no IA_NA and no SLAAC, then I want that CE router to pick an address from a /64 of the IA_PD and be able to use that address for sending/receiving traffic to/from the LAN/WAN (while making the entire rest of that very same /64 available to the LAN for SLAAC). I think that the new proposals (in the last few emails on this thread) to split cases around when to put the address on a LAN interface and when to put it on an internal interface based on =3Dr > /64 in IA_PD go in exactly the wrong direction. My experience has been that CE router vendors are perfectly capable of determining the interface that makes sense for their box. Realistically, the tests run at UNH-IOL wouldn't check to see what interface the address is on. Because the specific interface is not externally verifiable. The tests would check for (a) is the device able to send/receive traffic to/from all ports (assuming LAN isn't configured for multiple segments) using an address from the IA_PD, and (b) does it also advertise the rest of that same /64 for use on the LAN (SLAAC), and (c) do things just work after all this. Barbara =20 =20 =20 ------_=_NextPart_001_01CCCEDE.C1CA3BDA Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

6204bis is a CE router requirements document. Not an operator = requirements document.

RFC 6177 provides guidance regarding assignment of IPv6 prefixes to = end sites. Since this RFC already exists, and was recently published, I = see no need to try to write it again at this = time.

Barbara

 

From: Ray Hunter [mailto:v6ops@globis.net]
Sent: Saturday, = January 07, 2012 7:44 AM
To: STARK, BARBARA H
Cc: = Wuyts Carl; Ole Troan; v6ops@ietf.org
Subject: Re: Re: [v6ops] = Fwd: I-D Action: = draft-ietf-v6ops-6204bis-05.txt

 

Speaking as = an end user of the Internet: and in the spirit of your comment on = virtual interfaces, why should v6ops make life difficult for itself and = get involved at all in corner cases where there is a conflict between = what are essentially network operators' deployment decisions, and router = vendors' engineering decisions? IMVVVVHO V6ops should not be defining = technical workarounds for non-technical problems like the size of the PD = assignment.

Various authorities have bent over backwards to = ensure that IPv6 addresses are globally plentiful and that they are = "very much cheaper" than IPv4 addresses in terms of LIR fees. = The equivalent billing in RIPE for an IPv4 /32 is an IPv6 /43. IMVHO = assigning a single /64 IPv6 range per household seems unnecessarily mean = and potentially harmful to transparent end-to-end connectivity on the = Internet, possibly forcing end users to deploy complex prefix splitting = beyond /64 within their CPE router and thus breaking SLAAC, or perhaps = even worse, deploying NAT66.

Perhaps the practical solution for = 6204bis would be for v6ops to recommend that network operators delegate = "sufficient addresses" to end user sites (as suggested earlier = by Ole), and perhaps even going as far as recommending a minimum PD = assignment of /60 or /56 for customers using 6204bis compliant = equipment. The choice of /60 or /56 being based on the ability to = potentially delegate reverse DNS, and to allow end users of the Internet = to deploy flexible and reasonable local topologies e.g. a separate DMZ = LAN interface on the CPE router (In 6204bis, an IPv6 CE router may have = one or more network-layer LAN = interfaces).

Regards,
RayH

STARK, BARBARA H wrote: = 

if the network only =
offers addresses via DHCP, how does the =
network
      =

trigger the CPE to ask for an =
IA_NA?
    =

6204 solution is to =
require the device to always ask.
[Carl]Just =
configuration, nothing more, nothing less.  If you =
want
ia_na, ask ia_na, if you don't, don't ask, no =
need to enforce =
this.
      =

What if you enforce ia_na and the =
server doesn't answer anyway ?
Nothing =
accomplished.  What if you ask ia_na and the server =
is
configured as such to not hand-out anything if =
ia_na is requested
    =

(full
  =

match of requested =
options, if not match fully: nak) Keep it =
simple,
it's usually the best.  If customer =
wants ia_na, configure the device
as such, don't =
expect the CPE to do these things =
"auto-magically"
 
this isn't up to the customer. it is a choice by the access = network.
and I don't think the "here is a fax =
from your ISP, just type in these
parameters" =
scheme is the best we can do. =
;-)
 
[Carl] True, but =
there will be no "fax" from the ISP to the =
customer
either to ask to switch something in =
configuration off either if it
wouldn't work.  =
Anyway, I'm always flexible, so I say make it a =
SHOULD
iso MUST, meaning "you should ask it =
unless you have a good reason not
to do so", =
no ??
    =

 
<bhs>=
; The current requirement means that the customer doesn't have =
to
know anything about the access network (SLAAC or =
DHCPv6 IA_NA or
unnumbered). When we created 6204, =
one of the core goals was to identify
requirements =
that would allow a customer to plug the CE router in =
and
not have to know what address assignment =
mechanism the access network
used. Changing WPD-5 =
from MUST to SHOULD would completely demolish =
that
goal. If someone doesn't want to design their =
CE router per 6204, then
there's absolutely nothing =
that says they have to. It's not =
a
"standard". But if someone wants to =
build a router that can come up
without user =
configuration when connected to an access network that =
does
either SLAAC or DHCPv6 IA_NA or unnumbered, =
then this is what the CE
router must do. If someone =
wants a separate RFC for CE routers intended
for a =
different environment, then that's fine, too. But 6204 is for =
the
CE router intended to work in the environment =
specified in 6204.
 
As =
for the virtual interface comment -- my recollection of that was =
that
CE router designers wanted language that would =
basically let them put
that "unnumbered =
model" address wherever made sense for their box: =
LAN
interface, internal interface, logical =
interface, whatever. No need to
be specific, and =
leave it up to them. It just isn't the WAN =
interface
(because there's an RFC that says that's =
prohibited). From my
perspective, the CE router is =
a black box. If the access network
provides IA_PD, =
but no IA_NA and no SLAAC, then I want that CE router =
to
pick an address from a /64 of the IA_PD and be =
able to use that address
for sending/receiving =
traffic to/from the LAN/WAN (while making =
the
entire rest of that very same /64 available to =
the LAN for SLAAC). I
think that the new proposals =
(in the last few emails on this thread) to
split =
cases around when to put the address on a LAN interface and =
when
to put it on an internal interface based on =
=3Dr > /64 in IA_PD go in
exactly the wrong =
direction. My experience has been that CE =
router
vendors are perfectly capable of determining =
the interface that makes
sense for their box. =
Realistically, the tests run at UNH-IOL =
wouldn't
check to see what interface the address is =
on. Because the specific
interface is not =
externally verifiable. The tests would check for (a) =
is
the device able to send/receive traffic to/from =
all ports (assuming LAN
isn't configured for =
multiple segments) using an address from the =
IA_PD,
and (b) does it also advertise the rest of =
that same /64 for use on the
LAN (SLAAC), and (c) =
do things just work after all =
this.</bhs>
Barbara
=
 
 
  =
------_=_NextPart_001_01CCCEDE.C1CA3BDA-- From bs7652@att.com Mon Jan 9 08:39:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A2121F8552 for ; Mon, 9 Jan 2012 08:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.838 X-Spam-Level: X-Spam-Status: No, score=-105.838 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P05Z9zcOLf4P for ; Mon, 9 Jan 2012 08:39:15 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 3F56211E8072 for ; Mon, 9 Jan 2012 08:39:15 -0800 (PST) X-Env-Sender: bs7652@att.com X-Msg-Ref: server-11.tower-120.messagelabs.com!1326127152!57493519!1 X-Originating-IP: [144.160.20.146] X-StarScan-Version: 6.4.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26958 invoked from network); 9 Jan 2012 16:39:13 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-11.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Jan 2012 16:39:13 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q09Gbgkm003632; Mon, 9 Jan 2012 11:37:43 -0500 Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q09Gbb7o003530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jan 2012 11:37:37 -0500 Received: from 01AL10015010625.AD.BLS.COM (01AL10015010625.ad.bls.com [90.152.44.194]) by sflint04.pst.cso.att.com (RSA Interceptor); Mon, 9 Jan 2012 11:38:51 -0500 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01AL10015010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Jan 2012 10:37:57 -0600 Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Jan 2012 11:37:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCCEED.0A40415F" Date: Mon, 9 Jan 2012 11:38:48 -0500 Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F21CFECA1@crexc50p> In-Reply-To: <867F4B6A1672E541A94676D556793ACD0CB6819DC3@MOPESMBX01.eu.thmulti.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt Thread-Index: AczNOgwqFdWfvcPlShSmwOqFVV6b9QBYC7AAABFgEeA= References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com><867F4B6A1672E541A94676D556793ACD0CB56952D5@MOPESMBX01.eu.thmulti.com><8FFE15EA-B90E-4553-A776-7C2C5C221852@employees.org><867F4B6A1672E541A94676D556793ACD0CB569536F@MOPESMBX01.eu.thmulti.com><478BBBA2-3D32-4038-A5E4-CD886A417EB8@employees.org><867F4B6A1672E541A94676D556793ACD0CB56953B7@MOPESMBX01.eu.thmulti.com><1E00A66B-B0A3-4FFC-AF0E-ED3A2CACEA60@employees.org><867F4B6A1672E541A94676D556793ACD0CB56953BE@MOPESMBX01.eu.thmulti.com> <750BF7861EBBE048B3E648B4BB6E8F4F21CFE5E5@crexc50p> <4F083E04.5050908@globis.net> <867F4B6A1672E541A94676D556793ACD0CB6819DC3@MOPESMBX01.eu.thmulti.com> From: "STARK, BARBARA H" To: "Wuyts Carl" , "Ray Hunter" X-OriginalArrivalTime: 09 Jan 2012 16:37:56.0081 (UTC) FILETIME=[0A366610:01CCCEED] X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 16:39:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCCEED.0A40415F Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable By actively engaging in the creation of RFC 6204 and 6204bis, the operator community engaged in this effort has effectively said that: 1. Operators who expect 6204(bis)-compliant CE routers to work with their IPv6 access networks won't do things in their IPv6 access networks that will cause these CE routers not to work. Operators who do not expect these CE routers to work in their access networks may well do things that cause these CE routers not to work in their access networks. It is absolutely true that a 6204(bis)-compliant CE router cannot be expected to work in an environment where it is not expected to work. 2. Operators who expect 6204(bis)-compliant CE routers to establish a native IPv6 connection with their access networks will send RA. That RA may or may not have a SLAAC ("A") prefix. This includes operators who do PPP. See BBF TR-187 http://www.broadband-forum.org/technical/download/TR-187.pdf. [Things may change in the future, but that change will have to be coordinated.] 3. Operators who expect 6204(bis)-compliant CE routers to establish a native IPv6 connection with their IPv6 access networks will have a DHCPv6 server that provides IA_PD and DNS. It may or may not supply IA_NA or other config info. =20 The above operator expectations are implicit in RFC 6204(bis). =20 The requirements tell the CE router that a) If you don't get an RA or a response to DHCPv6 SOLICIT, then you aren't expected to be able to establish an IPv6 connection with this access network. b) If you get an "A" prefix in the RA, do SLAAC. If you don't get an "A" prefix, that's ok. Clearly, the access network doesn't expect you to do SLAAC if it doesn't send an "A" prefix. If it does send an "A" prefix, then it does expect you to do SLAAC. c) It's OK to always ask for IA_NA. But if M=3D1, then you MUST ask for IA_NA. If you get an IA_NA offer, take it. If you don't get one, that's ok. If the access network doesn't offer an IA_NA after you've asked for one (or if M=3D0), then clearly it doesn't intend for you to have one. d) Always ask for IA_PD. If you don't get IA_PD, then you aren't expected to be able to establish IPv6 connectivity for your LAN. This access network has no intention of supplying your LAN with IPv6 connectivity.=20 e) If you get IA_PD but no IA_NA and you get RA without "A" prefix, then take a single address from a /64, and associate it with an interface (not the WAN interface) where you can use the address for sending/receiving traffic to/from the LAN/WAN. IMO, the entire rest of the /64 should always be available for use in the LAN. The "unnumbered" model should never lock up an entire prefix. But we don't say that anywhere. So I guess operators can't expect this to be the case. I wouldn't be opposed to either stating that the unnumbered model might lock up a /64 prefix, or requiring that it not lock up a /64 prefix. But how to not lock up a prefix (if that's required) should be up to the CE router vendor to implement. =20 It's important to understand that if an operator wants these CE routers to work with their access network, then the operator won't do things that will cause the device not to work. If an operator doesn't want the CE router to work with their access network, then you shouldn't expect to be able to create requirements that will allow the device to work. Operators should expect CE routers to request IA_NA, independent of what the operator puts in the RA (M bits, "A" flags). I agree that it's not a good idea for the operator to support both SLAAC and IA_NA. And operators know this. Contrary to popular belief, we aren't clueless. While these requirements do not preclude stupidity in access network design, operators are working hard (and together) to avoid stupid access network design. And we're working with the CE community to try to make sure that we express (reasonable) expectations for devices to work with the access networks we design. Again, you're absolutely correct that the expectations we've expressed are not intended to ensure that the devices work on access networks of operators that have not been engaged in creation of 6204(bis). But I can only assume that such operators have no interest in such interoperability. Otherwise, they would be here. Barbara =20 =20 From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com]=20 Sent: Monday, January 09, 2012 2:16 AM To: Ray Hunter; STARK, BARBARA H Cc: Ole Troan; v6ops@ietf.org Subject: RE: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt =20 Well, seems like my comments are being taken the "wrong" way. =20 To come back on Barbara's comments: "" The current requirement means that the customer doesn't have to know anything about the access network (SLAAC or DHCPv6 IA_NA or unnumbered). [Carl] I agree=20 When we created 6204, one of the core goals was to identify requirements that would allow a customer to plug the CE router in and not have to know what address assignment mechanism the access network used. [Carl] I agree Changing WPD-5 from MUST to SHOULD would completely demolish that goal. If someone doesn't want to design their CE router per 6204, then there's absolutely nothing that says they have to. It's not a "standard". But if someone wants to build a router that can come up without user configuration when connected to an access network that does either SLAAC or DHCPv6 IA_NA or unnumbered, then this is what the CE router must do. [Carl But I do not agree on this one. You want a "user configuration" that either does SLAAC, DHCP_IA_NA or unnumbered. In your opinion, this must be done from a single configuration (no end-user interference, so from "factory defaults"). So, the CPE must either able to "sense" the configuration or just request all of the possible things ?? Sorry, but not a good idea. So, how must the CPE "sense" this and request the appropriate configuration ? Listen to RA ? Fine, although you would run into problems when, on a certain link (just say e.g. PPP), nothing would be received, what would you do with that ? No RA received, so ask IA_NA ? Fine again, but what if the DHCPv6 server does not provide anything ? Then you'd swap to "unnumbered" ? What interface are you going to use to put an address from ia_pd onto ? Play "safe" and put it on Lan interface (just to avoid issues if ia_pd =3D 64) ? This maybe sounds ok for you, but in fact it's not. Suppose the CPE has been configured with all of the above, you might end with both putting an address from ia_pd on top of an interface (no matter lan or virtual), which is ok for me, but what if you end up in a situation, where the DHCPv6 server does not return anything unless you ask for a specific set of DHCPv6 options and if not, no info would be sent ? In that case, you're CPE ends up with ... no configuration at all, only link local addresses. What if your access network would support SLAAC, so you get a prefix on the WAN intf trough SLAAC, but at the same time, you're also asking IA_NA, so might get that one too + you put a prefix from ia_pa too ? It can still work, but not sure this would be the best idea though. So no matter how much more things you're adding for the CPE, you will never have a 100% coverage. =20 If someone wants a separate RFC for CE routers intended for a different environment, then that's fine, too. But 6204 is for the CE router intended to work in the environment specified in 6204. "" And on the one of "virtual intfs": I can of course only agree that CPE vendors are perfectly capable of deciding for the appropriate intf to put an address from ia_pa on top off, however, if your req in RFC6204 uses "virtual interface" then I'd say your req can never be met in case of ia_pd length =3D 64. If you = want to keep using this exact phrasing, then it is wrong. So, if you know state it does not matter what terminology is being used, then I'm wondering why RFcs keep bothering to use lan, wan virtual, ... ??? =20 On the comments from Ray on usage of /64 ia_pd length: I can only say it is allowed. I don't say it is a good idea, I don't say we recommend it, but it's being used in the real world, so we're facing it from day to day (again, it's residential market, and we have to cope with those too, as after all, it is valid to use /64). And although you might consider this to be a "corner case", which I don't think is really the case, then I would imagine it should still be possible to use the RFC, no ? If not, a statement must be added to the RFC that this is only to be applied if your CPE is using ia_pd lengths of < 64, which goes in against the basic IPv6 RFCs I'd say. =20 Regs Carl =20 =20 =20 =20 From: Ray Hunter [mailto:v6ops@globis.net]=20 Sent: zaterdag 7 januari 2012 13:44 To: STARK, BARBARA H Cc: Wuyts Carl; Ole Troan; v6ops@ietf.org Subject: Re: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt =20 Speaking as an end user of the Internet: and in the spirit of your comment on virtual interfaces, why should v6ops make life difficult for itself and get involved at all in corner cases where there is a conflict between what are essentially network operators' deployment decisions, and router vendors' engineering decisions? IMVVVVHO V6ops should not be defining technical workarounds for non-technical problems like the size of the PD assignment. Various authorities have bent over backwards to ensure that IPv6 addresses are globally plentiful and that they are "very much cheaper" than IPv4 addresses in terms of LIR fees. The equivalent billing in RIPE for an IPv4 /32 is an IPv6 /43. IMVHO assigning a single /64 IPv6 range per household seems unnecessarily mean and potentially harmful to transparent end-to-end connectivity on the Internet, possibly forcing end users to deploy complex prefix splitting beyond /64 within their CPE router and thus breaking SLAAC, or perhaps even worse, deploying NAT66. Perhaps the practical solution for 6204bis would be for v6ops to recommend that network operators delegate "sufficient addresses" to end user sites (as suggested earlier by Ole), and perhaps even going as far as recommending a minimum PD assignment of /60 or /56 for customers using 6204bis compliant equipment. The choice of /60 or /56 being based on the ability to potentially delegate reverse DNS, and to allow end users of the Internet to deploy flexible and reasonable local topologies e.g. a separate DMZ LAN interface on the CPE router (In 6204bis, an IPv6 CE router may have one or more network-layer LAN interfaces). Regards, RayH STARK, BARBARA H wrote:=20 if the network only offers addresses via DHCP, how does the network =20 trigger the CPE to ask for an IA_NA? =20 6204 solution is to require the device to always ask. [Carl]Just configuration, nothing more, nothing less. If you want ia_na, ask ia_na, if you don't, don't ask, no need to enforce this. =20 What if you enforce ia_na and the server doesn't answer anyway ? Nothing accomplished. What if you ask ia_na and the server is configured as such to not hand-out anything if ia_na is requested =20 (full =20 match of requested options, if not match fully: nak) Keep it simple, it's usually the best. If customer wants ia_na, configure the device as such, don't expect the CPE to do these things "auto-magically" =20 this isn't up to the customer. it is a choice by the access network. and I don't think the "here is a fax from your ISP, just type in these parameters" scheme is the best we can do. ;-) =20 [Carl] True, but there will be no "fax" from the ISP to the customer either to ask to switch something in configuration off either if it wouldn't work. Anyway, I'm always flexible, so I say make it a SHOULD iso MUST, meaning "you should ask it unless you have a good reason not to do so", no ?? =20 =20 The current requirement means that the customer doesn't have to know anything about the access network (SLAAC or DHCPv6 IA_NA or unnumbered). When we created 6204, one of the core goals was to identify requirements that would allow a customer to plug the CE router in and not have to know what address assignment mechanism the access network used. Changing WPD-5 from MUST to SHOULD would completely demolish that goal. If someone doesn't want to design their CE router per 6204, then there's absolutely nothing that says they have to. It's not a "standard". But if someone wants to build a router that can come up without user configuration when connected to an access network that does either SLAAC or DHCPv6 IA_NA or unnumbered, then this is what the CE router must do. If someone wants a separate RFC for CE routers intended for a different environment, then that's fine, too. But 6204 is for the CE router intended to work in the environment specified in 6204. =20 As for the virtual interface comment -- my recollection of that was that CE router designers wanted language that would basically let them put that "unnumbered model" address wherever made sense for their box: LAN interface, internal interface, logical interface, whatever. No need to be specific, and leave it up to them. It just isn't the WAN interface (because there's an RFC that says that's prohibited). From my perspective, the CE router is a black box. If the access network provides IA_PD, but no IA_NA and no SLAAC, then I want that CE router to pick an address from a /64 of the IA_PD and be able to use that address for sending/receiving traffic to/from the LAN/WAN (while making the entire rest of that very same /64 available to the LAN for SLAAC). I think that the new proposals (in the last few emails on this thread) to split cases around when to put the address on a LAN interface and when to put it on an internal interface based on =3Dr > /64 in IA_PD go in exactly the wrong direction. My experience has been that CE router vendors are perfectly capable of determining the interface that makes sense for their box. Realistically, the tests run at UNH-IOL wouldn't check to see what interface the address is on. Because the specific interface is not externally verifiable. The tests would check for (a) is the device able to send/receive traffic to/from all ports (assuming LAN isn't configured for multiple segments) using an address from the IA_PD, and (b) does it also advertise the rest of that same /64 for use on the LAN (SLAAC), and (c) do things just work after all this. Barbara =20 =20 =20 ------_=_NextPart_001_01CCCEED.0A40415F Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

By actively engaging in the creation of RFC 6204 and 6204bis, the = operator community engaged in this effort has effectively said = that:

1. Operators who expect 6204(bis)-compliant CE routers to work with = their IPv6 access networks won’t do things in their IPv6 access = networks that will cause these CE routers not to work. Operators who do = not expect these CE routers to work in their access networks may well do = things that cause these CE routers not to work in their access networks. = It is absolutely true that a 6204(bis)-compliant CE router cannot be = expected to work in an environment where it is not expected to = work.

2. Operators who expect 6204(bis)-compliant CE routers to establish a = native IPv6 connection with their access networks will send RA. That RA = may or may not have a SLAAC (“A”) prefix. This includes = operators who do PPP. See BBF TR-187 htt= p://www.broadband-forum.org/technical/download/TR-187.pdf. [Things = may change in the future, but that change will have to be = coordinated.]

3. Operators who expect 6204(bis)-compliant CE routers to establish a = native IPv6 connection with their IPv6 access networks will have a = DHCPv6 server that provides IA_PD and DNS. It may or may not supply = IA_NA or other config info.

 

The above operator expectations are implicit in RFC = 6204(bis).

 

The requirements tell the CE router that

a) If you don’t get an RA or a response to DHCPv6 SOLICIT, then = you aren’t expected to be able to establish an IPv6 connection = with this access network.

b) If you get an “A” prefix in the RA, do SLAAC. If you = don’t get an “A” prefix, that’s ok. Clearly, the = access network doesn’t expect you to do SLAAC if it doesn’t = send an “A” prefix. If it does send an “A” = prefix, then it does expect you to do SLAAC.

c) It’s OK to always ask for IA_NA. But if M=3D1, then you MUST = ask for IA_NA. If you get an IA_NA offer, take it. If you don’t = get one, that’s ok. If the access network doesn’t offer an = IA_NA after you’ve asked for one (or if M=3D0), then clearly it = doesn’t intend for you to have one.

d) Always ask for IA_PD. If you don’t get IA_PD, then you = aren’t expected to be able to establish IPv6 connectivity for your = LAN. This access network has no intention of supplying your LAN with = IPv6 connectivity.

e) If you get IA_PD but no IA_NA and you get RA without = “A” prefix, then take a single address from a /64, and = associate it with an interface (not the WAN interface) where you can use = the address for sending/receiving traffic to/from the LAN/WAN. IMO, the = entire rest of the /64 should always be available for use in the LAN. = The “unnumbered” model should never lock up an entire = prefix. But we don’t say that anywhere. So I guess operators = can’t expect this to be the case. I wouldn’t be opposed to = either stating that the unnumbered model might lock up a /64 prefix, or = requiring that it not lock up a /64 prefix. But how to not lock up a = prefix (if that’s required) should be up to the CE router vendor = to implement.

 

It’s important to understand that if an operator wants these CE = routers to work with their access network, then the operator won’t = do things that will cause the device not to work. If an operator = doesn’t want the CE router to work with their access network, then = you shouldn’t expect to be able to create requirements that will = allow the device to work. Operators should expect CE routers to request = IA_NA, independent of what the operator puts in the RA (M bits, = “A” flags). I agree that it’s not a good idea for the = operator to support both SLAAC and IA_NA. And operators know this. = Contrary to popular belief, we aren’t clueless. While these = requirements do not preclude stupidity in access network design, = operators are working hard (and together) to avoid stupid access network = design. And we’re working with the CE community to try to make = sure that we express (reasonable) expectations for devices to work with = the access networks we design. Again, you’re absolutely correct = that the expectations we’ve expressed are not intended to ensure = that the devices work on access networks of operators that have not been = engaged in creation of 6204(bis). But I can only assume that such = operators have no interest in such interoperability. Otherwise, they = would be here.

Barbara

 

 

From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com]
Sent: = Monday, January 09, 2012 2:16 AM
To: Ray Hunter; STARK, = BARBARA H
Cc: Ole Troan; v6ops@ietf.org
Subject: RE: = Re: [v6ops] Fwd: I-D Action: = draft-ietf-v6ops-6204bis-05.txt

 

Well, seems like my comments are being taken the “wrong” = way.

 

To come back on Barbara’s comments:

“”

<bhs> The current requirement means that the = customer doesn't have to know anything about the access network (SLAAC = or DHCPv6 IA_NA or unnumbered).

[Carl] I agree

When we created 6204, one of the core goals was to = identify requirements that would allow a customer to plug the CE router = in and not have to know what address assignment mechanism the access = network used.

[Carl] I = agree

Changing WPD-5 from MUST to = SHOULD would completely demolish that goal. If someone doesn't want to = design their CE router per 6204, then there's absolutely nothing that = says they have to. It's not a "standard". But if someone wants = to build a router that can come up without user configuration when = connected to an access network that does either SLAAC or DHCPv6 IA_NA or = unnumbered, then this is what the CE router must do.

[Carl But I do not agree on this one. You want a = “user configuration” that either does SLAAC, DHCP_IA_NA or = unnumbered.  In your opinion, this must be done from a single = configuration (no end-user interference, so from “factory = defaults”).  So, the CPE must either able to = “sense” the configuration or just request all of the = possible things ??  Sorry, but not a good idea.  So, how must = the CPE “sense” this and request the appropriate = configuration ?  Listen to RA ?  Fine, although you would run = into problems when, on a certain link (just say e.g. PPP), nothing would = be received, what would you do with that ?  No RA received, so ask = IA_NA ?  Fine again, but what if the DHCPv6 server does not provide = anything ?  Then you’d swap to “unnumbered” = ?  What interface are you going to use to put an address from ia_pd = onto ?  Play “safe” and put it on Lan interface (just = to avoid issues if ia_pd =3D 64) ?

This maybe sounds ok for you, but in fact = it’s not.  Suppose the CPE has been configured with all of = the above, you might end with both putting an address from ia_pd on top = of an interface (no matter lan or virtual), which is ok for me, but what = if you end up in a situation, where the DHCPv6 server does not return = anything unless you ask for a specific set of DHCPv6 options and if not, = no info would be sent ?  In that case, you’re CPE ends up = with … no configuration at all, only link local addresses.  = What if your access network would support SLAAC, so you get a prefix on = the WAN intf trough SLAAC, but at the same time, you’re also = asking IA_NA, so might get that one too + you put a prefix from ia_pa = too ?  It can still work, but not sure this would be the best idea = though.

So no matter how much more = things you’re adding for the CPE, you will never have a 100% = coverage.

 

If someone wants a separate RFC for CE routers = intended for a different environment, then that's fine, too. But 6204 is = for the CE router intended to work in the environment specified in = 6204.

“”

And on the one of “virtual = intfs”:

I can of course only agree that CPE vendors are perfectly capable of = deciding for the appropriate intf to put an address from ia_pa on top = off, however, if your req in RFC6204 uses “virtual = interface” then  I’d say your req can never be met in = case of ia_pd length =3D 64.  If you want to keep using this exact = phrasing, then it is wrong.  So, if you know state it does not = matter what terminology is being used, then I’m wondering why RFcs = keep bothering to use lan, wan virtual, … = ???

 

On the comments from Ray on usage of /64 ia_pd = length:

I can only say it is allowed.  I don’t say it is a good = idea, I don’t say we recommend it, but it’s being used in = the real world, so we’re facing it from day to day (again, = it’s residential market, and we have to cope with those too, as = after all, it is valid to use /64).  And although you might = consider this to be a “corner case”, which I don’t = think is really the case, then I would imagine it should still be = possible to use the RFC, no ?  If not, a statement must be added to = the RFC that this is only to be applied if your CPE is using ia_pd = lengths of < 64, which goes in against the basic IPv6 RFCs I’d = say.

 

Regs

Carl

 

 

 

 

From: Ray Hunter [mailto:v6ops@globis.net]
Sent: zaterdag 7 = januari 2012 13:44
To: STARK, BARBARA H
Cc: Wuyts = Carl; Ole Troan; v6ops@ietf.org
Subject: Re: Re: [v6ops] Fwd: = I-D Action: = draft-ietf-v6ops-6204bis-05.txt

 

Speaking as = an end user of the Internet: and in the spirit of your comment on = virtual interfaces, why should v6ops make life difficult for itself and = get involved at all in corner cases where there is a conflict between = what are essentially network operators' deployment decisions, and router = vendors' engineering decisions? IMVVVVHO V6ops should not be defining = technical workarounds for non-technical problems like the size of the PD = assignment.

Various authorities have bent over backwards to = ensure that IPv6 addresses are globally plentiful and that they are = "very much cheaper" than IPv4 addresses in terms of LIR fees. = The equivalent billing in RIPE for an IPv4 /32 is an IPv6 /43. IMVHO = assigning a single /64 IPv6 range per household seems unnecessarily mean = and potentially harmful to transparent end-to-end connectivity on the = Internet, possibly forcing end users to deploy complex prefix splitting = beyond /64 within their CPE router and thus breaking SLAAC, or perhaps = even worse, deploying NAT66.

Perhaps the practical solution for = 6204bis would be for v6ops to recommend that network operators delegate = "sufficient addresses" to end user sites (as suggested earlier = by Ole), and perhaps even going as far as recommending a minimum PD = assignment of /60 or /56 for customers using 6204bis compliant = equipment. The choice of /60 or /56 being based on the ability to = potentially delegate reverse DNS, and to allow end users of the Internet = to deploy flexible and reasonable local topologies e.g. a separate DMZ = LAN interface on the CPE router (In 6204bis, an IPv6 CE router may have = one or more network-layer LAN = interfaces).

Regards,
RayH

STARK, BARBARA H wrote: = 

if the network only =
offers addresses via DHCP, how does the =
network
      =

trigger the CPE to ask for an =
IA_NA?
    =

6204 solution is to =
require the device to always ask.
[Carl]Just =
configuration, nothing more, nothing less.  If you =
want
ia_na, ask ia_na, if you don't, don't ask, no =
need to enforce =
this.
      =

What if you enforce ia_na and the =
server doesn't answer anyway ?
Nothing =
accomplished.  What if you ask ia_na and the server =
is
configured as such to not hand-out anything if =
ia_na is requested
    =

(full
  =

match of requested =
options, if not match fully: nak) Keep it =
simple,
it's usually the best.  If customer =
wants ia_na, configure the device
as such, don't =
expect the CPE to do these things =
"auto-magically"
 
this isn't up to the customer. it is a choice by the access = network.
and I don't think the "here is a fax =
from your ISP, just type in these
parameters" =
scheme is the best we can do. =
;-)
 
[Carl] True, but =
there will be no "fax" from the ISP to the =
customer
either to ask to switch something in =
configuration off either if it
wouldn't work.  =
Anyway, I'm always flexible, so I say make it a =
SHOULD
iso MUST, meaning "you should ask it =
unless you have a good reason not
to do so", =
no ??
    =

 
<bhs>=
; The current requirement means that the customer doesn't have =
to
know anything about the access network (SLAAC or =
DHCPv6 IA_NA or
unnumbered). When we created 6204, =
one of the core goals was to identify
requirements =
that would allow a customer to plug the CE router in =
and
not have to know what address assignment =
mechanism the access network
used. Changing WPD-5 =
from MUST to SHOULD would completely demolish =
that
goal. If someone doesn't want to design their =
CE router per 6204, then
there's absolutely nothing =
that says they have to. It's not =
a
"standard". But if someone wants to =
build a router that can come up
without user =
configuration when connected to an access network that =
does
either SLAAC or DHCPv6 IA_NA or unnumbered, =
then this is what the CE
router must do. If someone =
wants a separate RFC for CE routers intended
for a =
different environment, then that's fine, too. But 6204 is for =
the
CE router intended to work in the environment =
specified in 6204.
 
As =
for the virtual interface comment -- my recollection of that was =
that
CE router designers wanted language that would =
basically let them put
that "unnumbered =
model" address wherever made sense for their box: =
LAN
interface, internal interface, logical =
interface, whatever. No need to
be specific, and =
leave it up to them. It just isn't the WAN =
interface
(because there's an RFC that says that's =
prohibited). From my
perspective, the CE router is =
a black box. If the access network
provides IA_PD, =
but no IA_NA and no SLAAC, then I want that CE router =
to
pick an address from a /64 of the IA_PD and be =
able to use that address
for sending/receiving =
traffic to/from the LAN/WAN (while making =
the
entire rest of that very same /64 available to =
the LAN for SLAAC). I
think that the new proposals =
(in the last few emails on this thread) to
split =
cases around when to put the address on a LAN interface and =
when
to put it on an internal interface based on =
=3Dr > /64 in IA_PD go in
exactly the wrong =
direction. My experience has been that CE =
router
vendors are perfectly capable of determining =
the interface that makes
sense for their box. =
Realistically, the tests run at UNH-IOL =
wouldn't
check to see what interface the address is =
on. Because the specific
interface is not =
externally verifiable. The tests would check for (a) =
is
the device able to send/receive traffic to/from =
all ports (assuming LAN
isn't configured for =
multiple segments) using an address from the =
IA_PD,
and (b) does it also advertise the rest of =
that same /64 for use on the
LAN (SLAAC), and (c) =
do things just work after all =
this.</bhs>
Barbara
=
 
 
  =
------_=_NextPart_001_01CCCEED.0A40415F-- From joelja@bogus.com Mon Jan 9 09:03:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BAC21F86EA for ; Mon, 9 Jan 2012 09:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BLjbQO-ywjy for ; Mon, 9 Jan 2012 09:03:21 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5407D21F86CC for ; Mon, 9 Jan 2012 09:03:19 -0800 (PST) Received: from Joels-MacBook-Pro.local (host-64-47-136-190.masergy.com [64.47.136.190]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q09H3FlK052073 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 9 Jan 2012 17:03:16 GMT (envelope-from joelja@bogus.com) Message-ID: <4F0B1DCF.8070608@bogus.com> Date: Mon, 09 Jan 2012 09:03:11 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Gert Doering References: <4F04F5CA.6010802@si6networks.com> <4269EA985EACD24987D82DAE2FEC62E504DA8736@XMB-AMS-101.cisco.com> <20120106110948.GD72014@Space.Net> In-Reply-To: <20120106110948.GD72014@Space.Net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 09 Jan 2012 17:03:17 +0000 (UTC) Cc: IPv6 Operations Subject: Re: [v6ops] Revised I-D: Advice on RA-Guard Implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 17:03:21 -0000 On 1/6/12 03:09 , Gert Doering wrote: > Hi, > > On Fri, Jan 06, 2012 at 10:29:10AM +0100, Gunter Van de Velde (gvandeve) wrote: >> RA-Guard is a poor-man solution for access networks against rogue >> RA's... the grown up solution is SeND. > > We need both. SeND won't help if network participants are not able > to prime their machines with the certificates needed to authenticate RAs. > > Think IETF networks... Think any network where no pre-existing relationship exists. > Gert Doering > -- NetMaster From v6ops@globis.net Mon Jan 9 09:36:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CD011E80DB for ; Mon, 9 Jan 2012 09:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fluAHeeWER6X for ; Mon, 9 Jan 2012 09:36:18 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2CED511E80D7 for ; Mon, 9 Jan 2012 09:36:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id CAFB08700F6; Mon, 9 Jan 2012 18:36:15 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net 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 tTIjE6iPBnzV; Mon, 9 Jan 2012 18:36:07 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 3485A870098; Mon, 9 Jan 2012 18:36:07 +0100 (CET) Message-ID: <4F0B2587.7020600@globis.net> Date: Mon, 09 Jan 2012 18:36:07 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: "STARK, BARBARA H" References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com><867F4B6A1672E541A94676D556793ACD0CB56952D5@MOPESMBX01.eu.thmulti.com><8FFE15EA-B90E-4553-A776-7C2C5C221852@employees.org><867F4B6A1672E541A94676D556793ACD0CB569536F@MOPESMBX01.eu.thmulti.com><478BBBA2-3D32-4038-A5E4-CD886A417EB8@employees.org><867F4B6A1672E541A94676D556793ACD0CB56953B7@MOPESMBX01.eu.thmulti.com><1E00A66B-B0A3-4FFC-AF0E-ED3A2CACEA60@employees.org> <867F4B6A1672E541A94676D556793ACD0CB56953BE@MOPESMBX01.eu.thmulti.com> <750BF7861EBBE048B3E648B4BB6E8F4F21CFE5E5@crexc50p> <4F083E04.5050908@globis.net> <750BF7861EBBE048B3E648B4BB6E8F4F21CFEB81@crexc50p> In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F21CFEB81@crexc50p> Content-Type: multipart/alternative; boundary="------------080705020706010904060609" Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 17:36:19 -0000 This is a multi-part message in MIME format. --------------080705020706010904060609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks. Maybe not on your network, but apparently there are operators out there who are forcing router manufacturers to do the best they can with a single delegated /64 per end user site. So why not then quote RFC6177 as an additional normative reference for 6204bis? quote rfc6177 > One particular situation that must be avoided is having an end site feel compelled to use IPv6-to-IPv6 Network Address Translation or other burdensome address conservation techniques because it could not get sufficient address space. quote rfc6177 > a site, by definition, implies multiple subnets and multiple devices Both quotes seem to be pertinent advice, so that this particular corner case is avoided altogether in 6204bis. regards RayH STARK, BARBARA H wrote: > 6204bis is a CE router requirements document. Not an operator > requirements document. > > RFC 6177 provides guidance regarding assignment of IPv6 prefixes to > end sites. Since this RFC already exists, and was recently published, > I see no need to try to write it again at this time. > > Barbara --------------080705020706010904060609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks.

Maybe not on your network, but apparently there are operators out there who are forcing router manufacturers to do the best they can with a single delegated /64 per end user site.

So why not then quote RFC6177 as an additional normative reference for 6204bis?

quote rfc6177 > One particular situation that must be avoided is having an end site feel compelled to use IPv6-to-IPv6 Network Address Translation or other burdensome address conservation techniques because it could not get sufficient address space.

quote rfc6177 >  a site, by definition, implies multiple subnets and multiple devices

Both quotes seem to be pertinent advice, so that this particular corner case is avoided altogether in 6204bis.

regards
RayH

STARK, BARBARA H wrote:
6204bis is a CE router requirements document. Not an operator requirements document.

RFC 6177 provides guidance regarding assignment of IPv6 prefixes to end sites. Since this RFC already exists, and was recently published, I see no need to try to write it again at this time.

Barbara

--------------080705020706010904060609-- From internet-drafts@ietf.org Mon Jan 9 09:40:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B11311E80EE; Mon, 9 Jan 2012 09:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGTox43dTi-7; Mon, 9 Jan 2012 09:40:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B0611E80E6; Mon, 9 Jan 2012 09:40:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120109174027.19995.38700.idtracker@ietfa.amsl.com> Date: Mon, 09 Jan 2012 09:40:27 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-discard-prefix-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 17:40:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : A Discard Prefix for IPv6 Author(s) : Nick Hilliard Filename : draft-ietf-v6ops-ipv6-discard-prefix-02.txt Pages : 5 Date : 2012-01-09 Remote triggered black hole filtering describes a method of militating against denial-of-service attacks by selectively discarding traffic based on source or destination address. Remote triggered black hole routing describes a method of selectively re- routing traffic into a sinkhole router (for further analysis) based on destination address. This document updates RFC5156 by explaining why a unique IPv6 prefix should be formally assigned by IANA for the purpose of facilitating IPv6 remote triggered black hole filtering and routing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-discard-prefix-02= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-discard-prefix-02.= txt From gert@space.net Mon Jan 9 10:12:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8221211E80AB for ; Mon, 9 Jan 2012 10:12:15 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4d4Q6HbYhOKb for ; Mon, 9 Jan 2012 10:12:15 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id DDA9D21F881E for ; Mon, 9 Jan 2012 10:12:14 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id A046CF89A2 for ; Mon, 9 Jan 2012 19:12:12 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 8286BF898D for ; Mon, 9 Jan 2012 19:12:12 +0100 (CET) Received: (qmail 42518 invoked by uid 1007); 9 Jan 2012 19:12:12 +0100 Date: Mon, 9 Jan 2012 19:12:12 +0100 From: Gert Doering To: Joel jaeggli Message-ID: <20120109181212.GY72014@Space.Net> References: <4F04F5CA.6010802@si6networks.com> <4269EA985EACD24987D82DAE2FEC62E504DA8736@XMB-AMS-101.cisco.com> <20120106110948.GD72014@Space.Net> <4F0B1DCF.8070608@bogus.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ID+W8RKoASbgH896" Content-Disposition: inline In-Reply-To: <4F0B1DCF.8070608@bogus.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Operations Subject: Re: [v6ops] Revised I-D: Advice on RA-Guard Implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 18:12:15 -0000 --ID+W8RKoASbgH896 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Jan 09, 2012 at 09:03:11AM -0800, Joel jaeggli wrote: > On 1/6/12 03:09 , Gert Doering wrote: [..] > > Think IETF networks... > Think any network where no pre-existing relationship exists. Of course. IETF networks are just an example that readers on this=20 list should recognize, and nothing particularily exotic. 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 (89) 32356-444 USt-IdNr.: DE813185279 --ID+W8RKoASbgH896 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQCVAwUBTwst/KkuBuNlUUl1AQL1jQP/cq5CVwCbWjdKwxj57ZV1+O9JxDIdhUYK hlBKFKY2gArIQS2OvjSiXfm+WHqpRxeXiuVait9LRuGP7oH6UvQtZK7CseGASGbG CNidjbnTgUnatLP6AIBtm7+WIsK9kYKt4SiTeYFSpK633WmR2VSxZORqF81JFcOM SM9EG94uJDA= =7q8p -----END PGP SIGNATURE----- --ID+W8RKoASbgH896-- From iesg-secretary@ietf.org Mon Jan 9 10:44:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B499721F883B; Mon, 9 Jan 2012 10:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.259 X-Spam-Level: X-Spam-Status: No, score=-102.259 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGKX-OEO28bM; Mon, 9 Jan 2012 10:44:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF5721F8777; Mon, 9 Jan 2012 10:44:57 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120109184457.6520.42337.idtracker@ietfa.amsl.com> Date: Mon, 09 Jan 2012 10:44:57 -0800 Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (A Discard Prefix for IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 18:44:58 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'A Discard Prefix for IPv6' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-01-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Remote triggered black hole filtering describes a method of militating against denial-of-service attacks by selectively discarding traffic based on source or destination address. Remote triggered black hole routing describes a method of selectively re- routing traffic into a sinkhole router (for further analysis) based on destination address. This document updates RFC5156 by explaining why a unique IPv6 prefix should be formally assigned by IANA for the purpose of facilitating IPv6 remote triggered black hole filtering and routing. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-discard-prefix/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-discard-prefix/ No IPR declarations have been submitted directly on this I-D. From brian.e.carpenter@gmail.com Mon Jan 9 17:41:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C168511E8080 for ; Mon, 9 Jan 2012 17:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.479 X-Spam-Level: X-Spam-Status: No, score=-103.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XD91fxAdLZhn for ; Mon, 9 Jan 2012 17:41:56 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id DFBFA11E809B for ; Mon, 9 Jan 2012 17:41:55 -0800 (PST) Received: by yenl8 with SMTP id l8so1513607yen.31 for ; Mon, 09 Jan 2012 17:41:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=kRLf+MaCL6QWK1dCIB+wwefhMX2k8X3A3vjujwlca68=; b=k41qh1wQ0cNI4cj1r6TMi8hYT7yNXtJHF4XVvxIsOT2QNj74WGlrw9JdBfhtAEtW5c 17PSWr+7zBkheHraaL/MSoD+hx5KZqKRDo02LOQkTy4Quw5T6zfV49g+cJgr66vbPCGm Bi+1OAMQ4IbrngAhWbJ4B/Kc9oqvdqMxIq0EE= Received: by 10.236.182.167 with SMTP id o27mr23639279yhm.115.1326159714482; Mon, 09 Jan 2012 17:41:54 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id z3sm48246873yhd.3.2012.01.09.17.41.52 (version=SSLv3 cipher=OTHER); Mon, 09 Jan 2012 17:41:53 -0800 (PST) Message-ID: <4F0B975E.60604@gmail.com> Date: Tue, 10 Jan 2012 14:41:50 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [v6ops] [Fwd: I-D Action: draft-carpenter-v6ops-icp-guidance-02.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 01:41:56 -0000 Hi, We've updated this according to the comments received since Taipei. At this point we'd like opinions about the future of the document. Should it become a WG draft, or should we progress it as an individual submission? Brian -------- Original Message -------- Subject: I-D Action: draft-carpenter-v6ops-icp-guidance-02.txt Date: Fri, 06 Jan 2012 11:37:09 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Guidance for Internet Content and Application Service Providers Author(s) : Brian Carpenter Sheng Jiang Filename : draft-carpenter-v6ops-icp-guidance-02.txt Pages : 16 Date : 2012-01-06 This document provides guidance and suggestions for Internet Content Providers and Application Service Providers who wish to offer their service to both IPv6 and IPv4 customers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-02.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From victor.kuarsingh@gmail.com Mon Jan 9 18:45:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF70C21F8552 for ; Mon, 9 Jan 2012 18:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuI3ZIHgiswM for ; Mon, 9 Jan 2012 18:45:50 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF5D21F854E for ; Mon, 9 Jan 2012 18:45:50 -0800 (PST) Received: by vbbfo1 with SMTP id fo1so3432765vbb.31 for ; Mon, 09 Jan 2012 18:45:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type:content-transfer-encoding; bh=y5MdWo91sFvaiDnHC5uGakVHnkVTpbmjNdEvSYzjdU0=; b=J97FASdjmV9WRV/XhkdWYZAQ4Wj4rrbKkq2Cw9qBxggUk8AGDYz3O1++xCHPMPkOTu sNv2ccJ+gL/6TXjw0PAFNvZxgx/My5zn+eY5QM8ES/AZFSqOzDCcESTHaqReZBNDb5Ji x3otON2I58NFQ8oGeeHzukqXTyO+b8zFxiyCc= Received: by 10.52.33.99 with SMTP id q3mr8681131vdi.100.1326163549613; Mon, 09 Jan 2012 18:45:49 -0800 (PST) Received: from [192.168.100.89] ([67.224.83.162]) by mx.google.com with ESMTPS id z1sm11186121vdh.11.2012.01.09.18.45.48 (version=SSLv3 cipher=OTHER); Mon, 09 Jan 2012 18:45:48 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Mon, 09 Jan 2012 21:45:45 -0500 From: Victor Kuarsingh To: Brian E Carpenter , IPv6 Operations Message-ID: Thread-Topic: [v6ops] [Fwd: I-D Action: draft-carpenter-v6ops-icp-guidance-02.txt] In-Reply-To: <4F0B975E.60604@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [v6ops] [Fwd: I-D Action: draft-carpenter-v6ops-icp-guidance-02.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 02:45:51 -0000 Brian, I would support this as a WG item. I think this document outlines sound guidance for considering IPv6 in the environments (ICS / ASP) noted. I would also suggest that sections 3-8 and 11,12 are applicable for more then just the ICS/ASP environment (good general text). The document seems to capture a number of very important points for orgs looking to support IPv6. I would suggest that we may want to consider putting a bit more in section 5.2 (routing) and section 6 (Load balancers) as the document progresses. I.e. For example, in the routing section, perhaps the mention of other protocols such as IS-IS can be mentioned? I would also think there may be some additional guidance that can be given here as to what analysis can/should be done by an org when considering running dual stack. The document suggests that IPv6 routing can be put in without impact to IPv4, but I think that may be simplifying the point a bit. There are considerations that can be highlighted here (I.e. Performance on routers running more protocols, non-congruent IPv4/IPv6 topology considerations, etc). Also, I think much of this text in sections I highlighted above should also be directed to enterprises as it captures many key points of considering IPv6 deployment succinctly. Regards, Victor K On 12-01-09 8:41 PM, "Brian E Carpenter" wrote: >Hi, > >We've updated this according to the comments received since Taipei. > >At this point we'd like opinions about the future of the document. >Should it become a WG draft, or should we progress it as an >individual submission? > > Brian > >-------- Original Message -------- >Subject: I-D Action: draft-carpenter-v6ops-icp-guidance-02.txt >Date: Fri, 06 Jan 2012 11:37:09 -0800 >From: internet-drafts@ietf.org >Reply-To: internet-drafts@ietf.org >To: i-d-announce@ietf.org > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : IPv6 Guidance for Internet Content and Application >Service Providers > Author(s) : Brian Carpenter > Sheng Jiang > Filename : draft-carpenter-v6ops-icp-guidance-02.txt > Pages : 16 > Date : 2012-01-06 > > This document provides guidance and suggestions for Internet Content > Providers and Application Service Providers who wish to offer their > service to both IPv6 and IPv4 customers. > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-02. >txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >This Internet-Draft can be retrieved at: >ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-02.t >xt > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From wwwrun@rfc-editor.org Mon Jan 9 21:46:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3823321F8508; Mon, 9 Jan 2012 21:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.44 X-Spam-Level: X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaetaPK-Dl0M; Mon, 9 Jan 2012 21:46:13 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 9346F21F842D; Mon, 9 Jan 2012 21:46:13 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id F129972E004; Mon, 9 Jan 2012 21:43:39 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120110054339.F129972E004@rfc-editor.org> Date: Mon, 9 Jan 2012 21:43:39 -0800 (PST) Cc: v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] RFC 6459 on IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 05:46:14 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6459 Title: IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS) Author: J. Korhonen, Ed., J. Soininen, B. Patil, T. Savolainen, G. Bajko, K. Iisakkila Status: Informational Stream: IETF Date: January 2012 Mailbox: jouni.nospam@gmail.com, jonne.soininen@renesasmobile.com, basavaraj.patil@nokia.com, teemu.savolainen@nokia.com, gabor.bajko@nokia.com, kaisu.iisakkila@renesasmobile.com Pages: 36 Characters: 84769 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-3gpp-eps-08.txt URL: http://www.rfc-editor.org/rfc/rfc6459.txt The use of cellular broadband for accessing the Internet and other data services via smartphones, tablets, and notebook/netbook computers has increased rapidly as a result of high-speed packet data networks such as HSPA, HSPA+, and now Long-Term Evolution (LTE) being deployed. Operators that have deployed networks based on 3rd Generation Partnership Project (3GPP) network architectures are facing IPv4 address shortages at the Internet registries and are feeling pressure to migrate to IPv6. This document describes the support for IPv6 in 3GPP network architectures. This document is not an Internet Standards Track specification; it is published for informational purposes. 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/rfcsearch.html. 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 From Carl.Wuyts@technicolor.com Mon Jan 9 23:28:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E4B21F8770 for ; Mon, 9 Jan 2012 23:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.17 X-Spam-Level: X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b67Tpac86cHa for ; Mon, 9 Jan 2012 23:28:26 -0800 (PST) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0BF21F84F1 for ; Mon, 9 Jan 2012 23:28:19 -0800 (PST) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKTwvokGGNKyO95yPSqT8yQK4alEKAFs5M@postini.com; Mon, 09 Jan 2012 23:28:24 PST Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Tue, 10 Jan 2012 08:28:09 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.20]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Tue, 10 Jan 2012 08:28:11 +0100 From: Wuyts Carl To: "STARK, BARBARA H" , Ray Hunter Date: Tue, 10 Jan 2012 08:28:09 +0100 Thread-Topic: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt Thread-Index: AczNOgwqFdWfvcPlShSmwOqFVV6b9QBYC7AAABFgEeAAIiE/cA== Message-ID: <867F4B6A1672E541A94676D556793ACD0CB681A1E6@MOPESMBX01.eu.thmulti.com> References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com><867F4B6A1672E541A94676D556793ACD0CB56952D5@MOPESMBX01.eu.thmulti.com><8FFE15EA-B90E-4553-A776-7C2C5C221852@employees.org><867F4B6A1672E541A94676D556793ACD0CB569536F@MOPESMBX01.eu.thmulti.com><478BBBA2-3D32-4038-A5E4-CD886A417EB8@employees.org><867F4B6A1672E541A94676D556793ACD0CB56953B7@MOPESMBX01.eu.thmulti.com><1E00A66B-B0A3-4FFC-AF0E-ED3A2CACEA60@employees.org><867F4B6A1672E541A94676D556793ACD0CB56953BE@MOPESMBX01.eu.thmulti.com> <750BF7861EBBE048B3E648B4BB6E8F4F21CFE5E5@crexc50p> <4F083E04.5050908@globis.net> <867F4B6A1672E541A94676D556793ACD0CB6819DC3@MOPESMBX01.eu.thmulti.com> <750BF7861EBBE048B3E648B4BB6E8F4F21CFECA1@crexc50p> In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F21CFECA1@crexc50p> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_867F4B6A1672E541A94676D556793ACD0CB681A1E6MOPESMBX01eut_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 07:28:35 -0000 --_000_867F4B6A1672E541A94676D556793ACD0CB681A1E6MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well, my final comment on this. First of all, FYI: operators are our customers, not present in retail. So = all my findings are based upon real life scenarios, not invented. If I say= there's no RA on certain deployments, then it means that there is no RA. = Should they have sent one ? Probably they should, but they didn't. does i= t work: Yes it does. Operational deployement does not necessarily always l= ine up with the theory of an RFC, this is just a fact, nothing new for IPv6= . I'm just trying to feed in some info from another angle. I see most contri= butors in this area are not in our position. I see you state that you can always ask IA_NA, in fact, looking at those bi= s reqs, you MUST always ask IA_NA (unless you want some mechanism in place = to check for "X Y and Z" to start asking something, but this is no realisti= c scenario in residential CPE devices). Please note that lots of operators= expect a cheap CPE device, to be able to survice in the market, so putting= in lots of extra intelligence is possible, but unlikely to happen. Please note we try, as all CPEs should do imho, to be compliant with most r= elevant RFCs. RFC6204bis being one of them from my point-of-view. Regs Carl From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: maandag 9 januari 2012 17:39 To: Wuyts Carl; Ray Hunter Cc: Ole Troan; v6ops@ietf.org Subject: RE: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt By actively engaging in the creation of RFC 6204 and 6204bis, the operator = community engaged in this effort has effectively said that: 1. Operators who expect 6204(bis)-compliant CE routers to work with their I= Pv6 access networks won't do things in their IPv6 access networks that will= cause these CE routers not to work. Operators who do not expect these CE r= outers to work in their access networks may well do things that cause these= CE routers not to work in their access networks. It is absolutely true tha= t a 6204(bis)-compliant CE router cannot be expected to work in an environm= ent where it is not expected to work. 2. Operators who expect 6204(bis)-compliant CE routers to establish a nativ= e IPv6 connection with their access networks will send RA. That RA may or m= ay not have a SLAAC ("A") prefix. This includes operators who do PPP. See B= BF TR-187 http://www.broadband-forum.org/technical/download/TR-187.pdf. [Th= ings may change in the future, but that change will have to be coordinated.= ] 3. Operators who expect 6204(bis)-compliant CE routers to establish a nativ= e IPv6 connection with their IPv6 access networks will have a DHCPv6 server= that provides IA_PD and DNS. It may or may not supply IA_NA or other confi= g info. The above operator expectations are implicit in RFC 6204(bis). The requirements tell the CE router that a) If you don't get an RA or a response to DHCPv6 SOLICIT, then you aren't = expected to be able to establish an IPv6 connection with this access networ= k. b) If you get an "A" prefix in the RA, do SLAAC. If you don't get an "A" pr= efix, that's ok. Clearly, the access network doesn't expect you to do SLAAC= if it doesn't send an "A" prefix. If it does send an "A" prefix, then it d= oes expect you to do SLAAC. c) It's OK to always ask for IA_NA. But if M=3D1, then you MUST ask for IA_= NA. If you get an IA_NA offer, take it. If you don't get one, that's ok. If= the access network doesn't offer an IA_NA after you've asked for one (or i= f M=3D0), then clearly it doesn't intend for you to have one. d) Always ask for IA_PD. If you don't get IA_PD, then you aren't expected t= o be able to establish IPv6 connectivity for your LAN. This access network = has no intention of supplying your LAN with IPv6 connectivity. e) If you get IA_PD but no IA_NA and you get RA without "A" prefix, then ta= ke a single address from a /64, and associate it with an interface (not the= WAN interface) where you can use the address for sending/receiving traffic= to/from the LAN/WAN. IMO, the entire rest of the /64 should always be avai= lable for use in the LAN. The "unnumbered" model should never lock up an en= tire prefix. But we don't say that anywhere. So I guess operators can't exp= ect this to be the case. I wouldn't be opposed to either stating that the u= nnumbered model might lock up a /64 prefix, or requiring that it not lock u= p a /64 prefix. But how to not lock up a prefix (if that's required) should= be up to the CE router vendor to implement. It's important to understand that if an operator wants these CE routers to = work with their access network, then the operator won't do things that will= cause the device not to work. If an operator doesn't want the CE router to= work with their access network, then you shouldn't expect to be able to cr= eate requirements that will allow the device to work. Operators should expe= ct CE routers to request IA_NA, independent of what the operator puts in th= e RA (M bits, "A" flags). I agree that it's not a good idea for the operato= r to support both SLAAC and IA_NA. And operators know this. Contrary to pop= ular belief, we aren't clueless. While these requirements do not preclude s= tupidity in access network design, operators are working hard (and together= ) to avoid stupid access network design. And we're working with the CE comm= unity to try to make sure that we express (reasonable) expectations for dev= ices to work with the access networks we design. Again, you're absolutely c= orrect that the expectations we've expressed are not intended to ensure tha= t the devices work on access networks of operators that have not been engag= ed in creation of 6204(bis). But I can only assume that such operators have= no interest in such interoperability. Otherwise, they would be here. Barbara From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com] Sent: Monday, January 09, 2012 2:16 AM To: Ray Hunter; STARK, BARBARA H Cc: Ole Troan; v6ops@ietf.org Subject: RE: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt Well, seems like my comments are being taken the "wrong" way. To come back on Barbara's comments: "" The current requirement means that the customer doesn't have to know = anything about the access network (SLAAC or DHCPv6 IA_NA or unnumbered). [Carl] I agree When we created 6204, one of the core goals was to identify requirements th= at would allow a customer to plug the CE router in and not have to know wha= t address assignment mechanism the access network used. [Carl] I agree Changing WPD-5 from MUST to SHOULD would completely demolish that goal. If = someone doesn't want to design their CE router per 6204, then there's absol= utely nothing that says they have to. It's not a "standard". But if someone= wants to build a router that can come up without user configuration when c= onnected to an access network that does either SLAAC or DHCPv6 IA_NA or unn= umbered, then this is what the CE router must do. [Carl But I do not agree on this one. You want a "user configuration" that = either does SLAAC, DHCP_IA_NA or unnumbered. In your opinion, this must be= done from a single configuration (no end-user interference, so from "facto= ry defaults"). So, the CPE must either able to "sense" the configuration o= r just request all of the possible things ?? Sorry, but not a good idea. = So, how must the CPE "sense" this and request the appropriate configuration= ? Listen to RA ? Fine, although you would run into problems when, on a c= ertain link (just say e.g. PPP), nothing would be received, what would you = do with that ? No RA received, so ask IA_NA ? Fine again, but what if the= DHCPv6 server does not provide anything ? Then you'd swap to "unnumbered"= ? What interface are you going to use to put an address from ia_pd onto ?= Play "safe" and put it on Lan interface (just to avoid issues if ia_pd = =3D 64) ? This maybe sounds ok for you, but in fact it's not. Suppose the CPE has be= en configured with all of the above, you might end with both putting an add= ress from ia_pd on top of an interface (no matter lan or virtual), which is= ok for me, but what if you end up in a situation, where the DHCPv6 server = does not return anything unless you ask for a specific set of DHCPv6 option= s and if not, no info would be sent ? In that case, you're CPE ends up wit= h ... no configuration at all, only link local addresses. What if your acc= ess network would support SLAAC, so you get a prefix on the WAN intf trough= SLAAC, but at the same time, you're also asking IA_NA, so might get that o= ne too + you put a prefix from ia_pa too ? It can still work, but not sure= this would be the best idea though. So no matter how much more things you're adding for the CPE, you will never= have a 100% coverage. If someone wants a separate RFC for CE routers intended for a different env= ironment, then that's fine, too. But 6204 is for the CE router intended to = work in the environment specified in 6204. "" And on the one of "virtual intfs": I can of course only agree that CPE vendors are perfectly capable of decidi= ng for the appropriate intf to put an address from ia_pa on top off, howeve= r, if your req in RFC6204 uses "virtual interface" then I'd say your req c= an never be met in case of ia_pd length =3D 64. If you want to keep using = this exact phrasing, then it is wrong. So, if you know state it does not m= atter what terminology is being used, then I'm wondering why RFcs keep both= ering to use lan, wan virtual, ... ??? On the comments from Ray on usage of /64 ia_pd length: I can only say it is allowed. I don't say it is a good idea, I don't say w= e recommend it, but it's being used in the real world, so we're facing it f= rom day to day (again, it's residential market, and we have to cope with th= ose too, as after all, it is valid to use /64). And although you might con= sider this to be a "corner case", which I don't think is really the case, t= hen I would imagine it should still be possible to use the RFC, no ? If no= t, a statement must be added to the RFC that this is only to be applied if = your CPE is using ia_pd lengths of < 64, which goes in against the basic IP= v6 RFCs I'd say. Regs Carl From: Ray Hunter [mailto:v6ops@globis.net] Sent: zaterdag 7 januari 2012 13:44 To: STARK, BARBARA H Cc: Wuyts Carl; Ole Troan; v6ops@ietf.org Subject: Re: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt Speaking as an end user of the Internet: and in the spirit of your comment = on virtual interfaces, why should v6ops make life difficult for itself and = get involved at all in corner cases where there is a conflict between what = are essentially network operators' deployment decisions, and router vendors= ' engineering decisions? IMVVVVHO V6ops should not be defining technical wo= rkarounds for non-technical problems like the size of the PD assignment. Various authorities have bent over backwards to ensure that IPv6 addresses = are globally plentiful and that they are "very much cheaper" than IPv4 addr= esses in terms of LIR fees. The equivalent billing in RIPE for an IPv4 /32 = is an IPv6 /43. IMVHO assigning a single /64 IPv6 range per household seems= unnecessarily mean and potentially harmful to transparent end-to-end conne= ctivity on the Internet, possibly forcing end users to deploy complex prefi= x splitting beyond /64 within their CPE router and thus breaking SLAAC, or = perhaps even worse, deploying NAT66. Perhaps the practical solution for 6204bis would be for v6ops to recommend = that network operators delegate "sufficient addresses" to end user sites (a= s suggested earlier by Ole), and perhaps even going as far as recommending = a minimum PD assignment of /60 or /56 for customers using 6204bis compliant= equipment. The choice of /60 or /56 being based on the ability to potentia= lly delegate reverse DNS, and to allow end users of the Internet to deploy = flexible and reasonable local topologies e.g. a separate DMZ LAN interface = on the CPE router (In 6204bis, an IPv6 CE router may have one or more netwo= rk-layer LAN interfaces). Regards, RayH STARK, BARBARA H wrote: if the network only offers addresses via DHCP, how does the network trigger the CPE to ask for an IA_NA? 6204 solution is to require the device to always ask. [Carl]Just configuration, nothing more, nothing less. If you want ia_na, ask ia_na, if you don't, don't ask, no need to enforce this. What if you enforce ia_na and the server doesn't answer anyway ? Nothing accomplished. What if you ask ia_na and the server is configured as such to not hand-out anything if ia_na is requested (full match of requested options, if not match fully: nak) Keep it simple, it's usually the best. If customer wants ia_na, configure the device as such, don't expect the CPE to do these things "auto-magically" this isn't up to the customer. it is a choice by the access network. and I don't think the "here is a fax from your ISP, just type in these parameters" scheme is the best we can do. ;-) [Carl] True, but there will be no "fax" from the ISP to the customer either to ask to switch something in configuration off either if it wouldn't work. Anyway, I'm always flexible, so I say make it a SHOULD iso MUST, meaning "you should ask it unless you have a good reason not to do so", no ?? The current requirement means that the customer doesn't have to know anything about the access network (SLAAC or DHCPv6 IA_NA or unnumbered). When we created 6204, one of the core goals was to identify requirements that would allow a customer to plug the CE router in and not have to know what address assignment mechanism the access network used. Changing WPD-5 from MUST to SHOULD would completely demolish that goal. If someone doesn't want to design their CE router per 6204, then there's absolutely nothing that says they have to. It's not a "standard". But if someone wants to build a router that can come up without user configuration when connected to an access network that does either SLAAC or DHCPv6 IA_NA or unnumbered, then this is what the CE router must do. If someone wants a separate RFC for CE routers intended for a different environment, then that's fine, too. But 6204 is for the CE router intended to work in the environment specified in 6204. As for the virtual interface comment -- my recollection of that was that CE router designers wanted language that would basically let them put that "unnumbered model" address wherever made sense for their box: LAN interface, internal interface, logical interface, whatever. No need to be specific, and leave it up to them. It just isn't the WAN interface (because there's an RFC that says that's prohibited). From my perspective, the CE router is a black box. If the access network provides IA_PD, but no IA_NA and no SLAAC, then I want that CE router to pick an address from a /64 of the IA_PD and be able to use that address for sending/receiving traffic to/from the LAN/WAN (while making the entire rest of that very same /64 available to the LAN for SLAAC). I think that the new proposals (in the last few emails on this thread) to split cases around when to put the address on a LAN interface and when to put it on an internal interface based on =3Dr > /64 in IA_PD go in exactly the wrong direction. My experience has been that CE router vendors are perfectly capable of determining the interface that makes sense for their box. Realistically, the tests run at UNH-IOL wouldn't check to see what interface the address is on. Because the specific interface is not externally verifiable. The tests would check for (a) is the device able to send/receive traffic to/from all ports (assuming LAN isn't configured for multiple segments) using an address from the IA_PD, and (b) does it also advertise the rest of that same /64 for use on the LAN (SLAAC), and (c) do things just work after all this. Barbara --_000_867F4B6A1672E541A94676D556793ACD0CB681A1E6MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Well, my final comment on this.

 

F= irst of all, FYI: operators are our customers, not present in retail. = So all my findings are based upon real life scenarios, not invented. = If I say there’s no RA on certain deployments, then it means that th= ere is no RA.  Should they have sent one ?  Probably they should,= but they didn’t.  does it work: Yes it does.  Operational = deployement does not necessarily always line up with the theory of an RFC, = this is just a fact, nothing new for IPv6.

 

I&= #8217;m just trying to feed in some info from another angle.  I see mo= st contributors in this area are not in our position.

=

I see you state that you can always ask IA_NA, = in fact, looking at those bis reqs, you MUST always ask IA_NA (unless you w= ant some mechanism in place to check for “X Y and Z” to start a= sking something, but this is no realistic scenario in residential CPE devic= es).  Please note that lots of operators expect a cheap CPE device, to= be able to survice in the market, so putting in lots of extra intelligence= is possible, but unlikely to happen.

Please note we try, as all CPEs should do imho, to be compliant= with most relevant RFCs.  RFC6204bis being one of them from my point-= of-view.

 =

Regs

Carl

<= o:p> 

 

 

=

From: STARK, = BARBARA H [mailto:bs7652@att.com]
Sent: maandag 9 januari 2012 1= 7:39
To: Wuyts Carl; Ray Hunter
Cc: Ole Troan; v6ops@ie= tf.org
Subject: RE: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops= -6204bis-05.txt

=  

By actively engaging in the cre= ation of RFC 6204 and 6204bis, the operator community engaged in this effor= t has effectively said that:

1. Operators who expect 6204(bis)-compliant CE routers to work with thei= r IPv6 access networks won’t do things in their IPv6 access networks = that will cause these CE routers not to work. Operators who do not expect t= hese CE routers to work in their access networks may well do things that ca= use these CE routers not to work in their access networks. It is absolutely= true that a 6204(bis)-compliant CE router cannot be expected to work in an= environment where it is not expected to work.

2. Operators who expect 6204(bis)-compliant CE routers= to establish a native IPv6 connection with their access networks will send= RA. That RA may or may not have a SLAAC (“A”) prefix. This inc= ludes operators who do PPP. See BBF TR-187 http://www.broadband-forum.org/tec= hnical/download/TR-187.pdf. [Things may change in the future, but that = change will have to be coordinated.]

3. Operators who expect 6204(bis)-compliant CE routers to establ= ish a native IPv6 connection with their IPv6 access networks will have a DH= CPv6 server that provides IA_PD and DNS. It may or may not supply IA_NA or = other config info.

&n= bsp;

The above operator expecta= tions are implicit in RFC 6204(bis).

 

The requ= irements tell the CE router that

= a) If you don’t get an RA or a response to DHCPv6 SOLICIT, the= n you aren’t expected to be able to establish an IPv6 connection with= this access network.

b) I= f you get an “A” prefix in the RA, do SLAAC. If you don’t= get an “A” prefix, that’s ok. Clearly, the access networ= k doesn’t expect you to do SLAAC if it doesn’t send an “A= ” prefix. If it does send an “A” prefix, then it does exp= ect you to do SLAAC.

c) I= t’s OK to always ask for IA_NA. But if M=3D1, then you MUST ask for I= A_NA. If you get an IA_NA offer, take it. If you don’t get one, that&= #8217;s ok. If the access network doesn’t offer an IA_NA after you= 217;ve asked for one (or if M=3D0), then clearly it doesn’t intend fo= r you to have one.

d) Alwa= ys ask for IA_PD. If you don’t get IA_PD, then you aren’t expec= ted to be able to establish IPv6 connectivity for your LAN. This access net= work has no intention of supplying your LAN with IPv6 connectivity.

e) If you get IA_PD but no IA_NA= and you get RA without “A” prefix, then take a single address = from a /64, and associate it with an interface (not the WAN interface) wher= e you can use the address for sending/receiving traffic to/from the LAN/WAN= . IMO, the entire rest of the /64 should always be available for use in the= LAN. The “unnumbered” model should never lock up an entire pre= fix. But we don’t say that anywhere. So I guess operators can’t= expect this to be the case. I wouldn’t be opposed to either stating = that the unnumbered model might lock up a /64 prefix, or requiring that it = not lock up a /64 prefix. But how to not lock up a prefix (if that’s = required) should be up to the CE router vendor to implement.

 

It’s important to understand that if an operator want= s these CE routers to work with their access network, then the operator won= ’t do things that will cause the device not to work. If an operator d= oesn’t want the CE router to work with their access network, then you= shouldn’t expect to be able to create requirements that will allow t= he device to work. Operators should expect CE routers to request IA_NA, ind= ependent of what the operator puts in the RA (M bits, “A” flags= ). I agree that it’s not a good idea for the operator to support both= SLAAC and IA_NA. And operators know this. Contrary to popular belief, we a= ren’t clueless. While these requirements do not preclude stupidity in= access network design, operators are working hard (and together) to avoid = stupid access network design. And we’re working with the CE community= to try to make sure that we express (reasonable) expectations for devices = to work with the access networks we design. Again, you’re absolutely = correct that the expectations we’ve expressed are not intended to ens= ure that the devices work on access networks of operators that have not bee= n engaged in creation of 6204(bis). But I can only assume that such operato= rs have no interest in such interoperability. Otherwise, they would be here= .

Barbara

 

 

From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com]
Sent: Monday, January 09, 2012 2:16 AM
To: Ray Hunter; STARK= , BARBARA H
Cc: Ole Troan; v6op= s@ietf.org
Subject: RE: Re: [v6ops] Fwd: I-D Action: draft-ie= tf-v6ops-6204bis-05.txt

 

Well, seems like my com= ments are being taken the “wrong” way.

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>To come back on Barbara’s comments:

“”

<bhs> The current requirement means that the customer doesn't = have to know anything about the access network (SLAAC or DHCPv6 IA_NA or un= numbered).

[Carl] I agree =

When we created 6204, one of the core goals was= to identify requirements that would allow a customer to plug the CE router= in and not have to know what address assignment mechanism the access netwo= rk used.

[Carl] I agree

Changing WPD-5 from MUST to SHOULD would completel= y demolish that goal. If someone doesn't want to design their CE router per= 6204, then there's absolutely nothing that says they have to. It's not a &= quot;standard". But if someone wants to build a router that can come u= p without user configuration when connected to an access network that does = either SLAAC or DHCPv6 IA_NA or unnumbered, then this is what the CE router= must do.

[Carl But I do not agree on= this one. You want a “user configuration” that either does SLA= AC, DHCP_IA_NA or unnumbered.  In your opinion, this must be done from= a single configuration (no end-user interference, so from “factory d= efaults”).  So, the CPE must either able to “sense” = the configuration or just request all of the possible things ??  Sorry= , but not a good idea.  So, how must the CPE “sense” this = and request the appropriate configuration ?  Listen to RA ?  Fine= , although you would run into problems when, on a certain link (just say e.= g. PPP), nothing would be received, what would you do with that ?  No = RA received, so ask IA_NA ?  Fine again, but what if the DHCPv6 server= does not provide anything ?  Then you’d swap to “unnumber= ed” ?  What interface are you going to use to put an address fro= m ia_pd onto ?  Play “safe” and put it on Lan interface (j= ust to avoid issues if ia_pd =3D 64) ?

This maybe sounds ok for you, but in fact it’s not.  Suppose t= he CPE has been configured with all of the above, you might end with both p= utting an address from ia_pd on top of an interface (no matter lan or virtu= al), which is ok for me, but what if you end up in a situation, where the D= HCPv6 server does not return anything unless you ask for a specific set of = DHCPv6 options and if not, no info would be sent ?  In that case, you&= #8217;re CPE ends up with … no configuration at all, only link local = addresses.  What if your access network would support SLAAC, so you ge= t a prefix on the WAN intf trough SLAAC, but at the same time, you’re= also asking IA_NA, so might get that one too + you put a prefix from ia_pa= too ?  It can still work, but not sure this would be the best idea th= ough.

So no matter how much more thin= gs you’re adding for the CPE, you will never have a 100% coverage.

 

If someone wants a separate RFC for CE routers intended for a differe= nt environment, then that's fine, too. But 6204 is for the CE router intend= ed to work in the environment specified in 6204.

“”

And on the one of “virtual intfs”:

I can of course only agree that CPE vendors are p= erfectly capable of deciding for the appropriate intf to put an address fro= m ia_pa on top off, however, if your req in RFC6204 uses “virtual int= erface” then  I’d say your req can never be met in case of= ia_pd length =3D 64.  If you want to keep using this exact phrasing, = then it is wrong.  So, if you know state it does not matter what termi= nology is being used, then I’m wondering why RFcs keep bothering to u= se lan, wan virtual, … ???

=  

On the comme= nts from Ray on usage of /64 ia_pd length:

I can only say it is allowed.  I don’t say it i= s a good idea, I don’t say we recommend it, but it’s being used= in the real world, so we’re facing it from day to day (again, itR= 17;s residential market, and we have to cope with those too, as after all, = it is valid to use /64).  And although you might consider this to be a= “corner case”, which I don’t think is really the case, t= hen I would imagine it should still be possible to use the RFC, no ?  = If not, a statement must be added to the RFC that this is only to be applie= d if your CPE is using ia_pd lengths of < 64, which goes in against the = basic IPv6 RFCs I’d say.

 

Regs

Carl

 

 

 <= /span>

 

From: Ray Hunter = [mailto:v6ops@globis.net]
Se= nt: zaterdag 7 januari 2012 13:44
To: STARK, BARBARA H
= Cc: Wuyts Carl; Ole Troan; v6ops@ietf= .org
Subject: Re: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6o= ps-6204bis-05.txt

 

Speaking as an end user of the Inter= net: and in the spirit of your comment on virtual interfaces, why should v6= ops make life difficult for itself and get involved at all in corner cases = where there is a conflict between what are essentially network operators' d= eployment decisions, and router vendors' engineering decisions? IMVVVVHO V6= ops should not be defining technical workarounds for non-technical problems= like the size of the PD assignment.

Various authorities have bent o= ver backwards to ensure that IPv6 addresses are globally plentiful and that= they are "very much cheaper" than IPv4 addresses in terms of LIR= fees. The equivalent billing in RIPE for an IPv4 /32 is an IPv6 /43. IMVHO= assigning a single /64 IPv6 range per household seems unnecessarily mean a= nd potentially harmful to transparent end-to-end connectivity on the Intern= et, possibly forcing end users to deploy complex prefix splitting beyond /6= 4 within their CPE router and thus breaking SLAAC, or perhaps even worse, d= eploying NAT66.

Perhaps the practical solution for 6204bis would be = for v6ops to recommend that network operators delegate "sufficient add= resses" to end user sites (as suggested earlier by Ole), and perhaps e= ven going as far as recommending a minimum PD assignment of /60 or /56 for = customers using 6204bis compliant equipment. The choice of /60 or /56 being= based on the ability to potentially delegate reverse DNS, and to allow end= users of the Internet to deploy flexible and reasonable local topologies e= .g. a separate DMZ LAN interface on the CPE router (In 6204bis, an IPv6 CE = router may have one or more network-layer LAN interfaces).

Regards,<= br>RayH

STARK, BARBARA H wrote: 

if the network only offers addresses via DHCP, h=
ow does the network
      
trigger the CPE to ask for an IA_NA?
    
6204 solution is to require the dev=
ice to always ask.
[Carl]Just configuration, nothing m=
ore, nothing less.  If you want
ia_na, ask ia_na,=
 if you don't, don't ask, no need to enforce this.
&nb=
sp;     
What if you =
enforce ia_na and the server doesn't answer anyway ?
N=
othing accomplished.  What if you ask ia_na and the server is
configured as such to not hand-out anything if ia_na is reques=
ted
   
<= pre>(full
  
match of requested options, if =
not match fully: nak) Keep it simple,
it's usually the=
 best.  If customer wants ia_na, configure the device
= 
as such, don't expect the CPE to do these things "auto-magically&=
quot;
 
this isn't up to the=
 customer. it is a choice by the access network.
and I=
 don't think the "here is a fax from your ISP, just type in these=

parameters" scheme is the best we can do. ;-)
 
[Carl] True, but there will be no=
 "fax" from the ISP to the customer
either t=
o ask to switch something in configuration off either if it
wouldn't work.  Anyway, I'm always flexible, so I say make it a =
SHOULD
iso MUST, meaning "you should ask it unles=
s you have a good reason not
to do so", no ??
    
 
<bhs> The current requirement means that the=
 customer doesn't have to
know anything about the acce=
ss network (SLAAC or DHCPv6 IA_NA or
unnumbered). When=
 we created 6204, one of the core goals was to identify
requirements that would allow a customer to plug the CE router in and
not have to know what address assignment mechanism the ac=
cess network
used. Changing WPD-5 from MUST to SHOULD =
would completely demolish that
goal. If someone doesn'=
t want to design their CE router per 6204, then
there'=
s absolutely nothing that says they have to. It's not a
"standard". But if someone wants to build a router that can com= e up
without user configuration when connected to an a=
ccess network that does
either SLAAC or DHCPv6 IA_NA o=
r unnumbered, then this is what the CE
router must do.=
 If someone wants a separate RFC for CE routers intended
for a different environment, then that's fine, too. But 6204 is for the<= o:p>
CE router intended to work in the environment specifie=
d in 6204.
 
As for the virt=
ual interface comment -- my recollection of that was that
<= pre>CE router designers wanted language that would basically let them put
that "unnumbered model" address wherever made=
 sense for their box: LAN
interface, internal interfac=
e, logical interface, whatever. No need to
be specific=
, and leave it up to them. It just isn't the WAN interface
= 
(because there's an RFC that says that's prohibited). From my
perspective, the CE router is a black box. If the access netwo=
rk
provides IA_PD, but no IA_NA and no SLAAC, then I w=
ant that CE router to
pick an address from a /64 of th=
e IA_PD and be able to use that address
for sending/re=
ceiving traffic to/from the LAN/WAN (while making the
=
entire rest of that very same /64 available to the LAN for SLAAC). I
think that the new proposals (in the last few emails on this=
 thread) to
split cases around when to put the address=
 on a LAN interface and when
to put it on an internal =
interface based on =3Dr > /64 in IA_PD go in
exactl=
y the wrong direction. My experience has been that CE router
vendors are perfectly capable of determining the interface that make=
s
sense for their box. Realistically, the tests run at=
 UNH-IOL wouldn't
check to see what interface the addr=
ess is on. Because the specific
interface is not exter=
nally verifiable. The tests would check for (a) is
the=
 device able to send/receive traffic to/from all ports (assuming LAN
isn't configured for multiple segments) using an address fro=
m the IA_PD,
and (b) does it also advertise the rest o=
f that same /64 for use on the
LAN (SLAAC), and (c) do=
 things just work after all this.</bhs>
Barbara<=
o:p>
 
 
 
= --_000_867F4B6A1672E541A94676D556793ACD0CB681A1E6MOPESMBX01eut_-- From leo.liubing@huawei.com Tue Jan 10 01:44:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B50F721F85C2 for ; Tue, 10 Jan 2012 01:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Az7r+gSt6pz3 for ; Tue, 10 Jan 2012 01:44:57 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8900F21F85EF for ; Tue, 10 Jan 2012 01:44:56 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXK00FQYTQJ4O@szxga05-in.huawei.com> for v6ops@ietf.org; Tue, 10 Jan 2012 17:44:44 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXK00F0LTQD3T@szxga05-in.huawei.com> for v6ops@ietf.org; Tue, 10 Jan 2012 17:44:43 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGF58786; Tue, 10 Jan 2012 17:44:43 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jan 2012 17:44:39 +0800 Received: from SZXEML509-MBX.china.huawei.com ([169.254.1.21]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Tue, 10 Jan 2012 17:44:33 +0800 Date: Tue, 10 Jan 2012 09:44:32 +0000 From: "Leo Liu(bing)" In-reply-to: X-Originating-IP: [10.108.4.84] To: Brian E Carpenter , IPv6 Operations Message-id: <8AE0F17B87264D4CAC7DE0AA6C406F4523681AA0@szxeml509-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [v6ops] [Fwd: I-D Action: draft-carpenter-v6ops-icp-guidance-02.txt] Thread-index: AQHMzzkur1VbzP7hfkCUkW/3enVX15YEX1iAgAD3ViA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4F0B975E.60604@gmail.com> Subject: Re: [v6ops] [Fwd: I-D Action: draft-carpenter-v6ops-icp-guidance-02.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 09:44:58 -0000 Hi, Brian I also support this to be a WG item. I agree with Victor's comment that some of the content not only suitable for ICP, but also enterprise and any other organizations who want to introduce IPv6 to their current network. They need to know the impact to various infrastructures include routing, servers, balancers, CDN etc. I think the draft is quite helpful for them to get start with IPv6, especially for the mid-small sized organizations, who may not have enough IPv6 experience/knowledge. For my personal interest, I want to see more discussion of dual stack OPS in the draft, since it seems there always been controversial about the complexity of running dual stack, and I think the issue may be more sensitive for the mid-small organizations. > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Victor Kuarsingh > Sent: Tuesday, January 10, 2012 10:46 AM > To: Brian E Carpenter; IPv6 Operations > Subject: Re: [v6ops] [Fwd: I-D Action: > draft-carpenter-v6ops-icp-guidance-02.txt] > > Brian, > > I would support this as a WG item. > > I think this document outlines sound guidance for considering IPv6 in the > environments (ICS / ASP) noted. I would also suggest that sections 3-8 > and 11,12 are applicable for more then just the ICS/ASP environment (good > general text). > > The document seems to capture a number of very important points for orgs > looking to support IPv6. I would suggest that we may want to consider > putting a bit more in section 5.2 (routing) and section 6 (Load balancers) > as the document progresses. > > I.e. For example, in the routing section, perhaps the mention of other > protocols such as IS-IS can be mentioned? I would also think there may be > some additional guidance that can be given here as to what analysis > can/should be done by an org when considering running dual stack. The > document suggests that IPv6 routing can be put in without impact to IPv4, > but I think that may be simplifying the point a bit. There are > considerations that can be highlighted here (I.e. Performance on routers > running more protocols, non-congruent IPv4/IPv6 topology considerations, > etc). > > Also, I think much of this text in sections I highlighted above should > also be directed to enterprises as it captures many key points of > considering IPv6 deployment succinctly. > > Regards, > > Victor K > > > > On 12-01-09 8:41 PM, "Brian E Carpenter" > wrote: > > >Hi, > > > >We've updated this according to the comments received since Taipei. > > > >At this point we'd like opinions about the future of the document. > >Should it become a WG draft, or should we progress it as an > >individual submission? > > > > Brian > > > >-------- Original Message -------- > >Subject: I-D Action: draft-carpenter-v6ops-icp-guidance-02.txt > >Date: Fri, 06 Jan 2012 11:37:09 -0800 > >From: internet-drafts@ietf.org > >Reply-To: internet-drafts@ietf.org > >To: i-d-announce@ietf.org > > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > Title : IPv6 Guidance for Internet Content and Application > >Service Providers > > Author(s) : Brian Carpenter > > Sheng Jiang > > Filename : draft-carpenter-v6ops-icp-guidance-02.txt > > Pages : 16 > > Date : 2012-01-06 > > > > This document provides guidance and suggestions for Internet Content > > Providers and Application Service Providers who wish to offer their > > service to both IPv6 and IPv4 customers. > > > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-02. > >txt > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >This Internet-Draft can be retrieved at: > >ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-02.t > >xt > > > >_______________________________________________ > >I-D-Announce mailing list > >I-D-Announce@ietf.org > >https://www.ietf.org/mailman/listinfo/i-d-announce > >Internet-Draft directories: http://www.ietf.org/shadow.html > >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > >_______________________________________________ > >v6ops mailing list > >v6ops@ietf.org > >https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From C.Donley@cablelabs.com Tue Jan 10 10:16:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A73421F87CF for ; Tue, 10 Jan 2012 10:16:04 -0800 (PST) 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_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwhG9+JicubT for ; Tue, 10 Jan 2012 10:16:03 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 560FC21F862D for ; Tue, 10 Jan 2012 10:15:59 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q0AI7BWR002655; Tue, 10 Jan 2012 11:15:53 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Tue, 10 Jan 2012 11:07:11 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 10 Jan 2012 11:13:58 -0700 From: Chris Donley To: Fred Baker , "Joel M. Halpern" Date: Tue, 10 Jan 2012 11:13:55 -0700 Thread-Topic: [v6ops] Please review draft-donley-behave-deterministic-cgn Thread-Index: AczPw57BrPFU+hVVTiabSatHl9fObg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: v6ops v6ops WG , Dave Thaler , Behave Chairs , "draft-donley-behave-deterministic-cgn@tools.ietf.org" Subject: Re: [v6ops] Please review draft-donley-behave-deterministic-cgn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 18:16:04 -0000 This comes down to compression density. You're right that most subscribers use few ports, but a few subs do use a very large number (see the WAND data). If you pack a lot of subscribers (let's say 1,000) behind a single IP address, each gets only a handful of ports, and this proposal almost turns into bulk port logging since many subscribers will be requesting additional allocations (we're not suggesting per-connection logging on the overflow). However, if you pack fewer subs behind a single public IP (let's say 60), each sub gets ~1000 ports, and 99% or so will never request another block. Then, using bulk port logging for the remainder makes for a very small quantity of log messages. In the example I presented in Taipei, we can get 100,000x-1,000,000x reduction in log messages, depending on the size of the port blocks offered for subsequent allocation. You're correct that there is a tradeoff between compression density (per-connection logging wins) and minimizing logging volume (Juniper's SD-NAT wins). On that continuum, we believe our proposal provides a balance that keeps log sizes small, but allows a reasonable compression density while allowing some flexibility to accommodate the 1% of users who consume significant numbers of ports. Chris On 1/4/12 4:18 PM, "Fred Baker" wrote: > >On Jan 4, 2012, at 2:32 PM, Joel M. Halpern wrote: > >> When I asked on operator about the port distribution, their answer was >>somewhat different. >> What they said was that when the users are idle, they don't use many >>ports. But when the user is busy, they use a lot of ports. >> This makes repeated, largeish, block allocation sensible, but makes >>pre-allocation of a small number, and then individual allocation >>thereafter, a bad strategy, as it will basically log as much as current. >>=20 >> I do not have access to any research results to disambiguate these two >>reports. > >Chris should step in here. > >https://www.ietf.org/proceedings/82/slides/behave-5.pdf, quoting >http://www.wand.net.nz/~salcock/someisp/flow_counting/result_page.html >also referenced by RFC 6269 > >In the wand.net.nz HTML, look specifically for "mean number of peak >sessions for active subscribers only for each 30 minute period"; the HTML >doesn't have tags that would allow me to simply get you there. > >I suspect that Chris/WAND and your service provider might be defining >"user" and "a lot" differently. The Waikato numbers are very likely >typical of a residential network behind a NAT - in a home, even if >several computers are in use, it's unlikely that everyone in the home is >web surfing during the same minute. Common browsers usually limit the >number of TCPs they open in parallel to something like 2 or 4, and those >sessions usually stay open single digit numbers of seconds; this says >that in a typical residential network, they see 2-4 computers >simultaneously doing that, for a peak of 4-8 TCP sessions simultaneously >active. That would be very surprising in a corporate network, but makes >sense for residential network. > >Is the service provider you asked talking about corporate subscribers? > >> Yours, >> Joel >>=20 >> On 1/4/2012 5:27 PM, Dave Thaler wrote: >>> Yes operational commentary would be very welcome. >>>=20 >>> Also FYI, the author of the draft has declared IPR on it: >>> https://datatracker.ietf.org/ipr/1617/ >>>=20 >>> -Dave >>>=20 >>> -----Original Message----- >>> From: Fred Baker [mailto:fred@cisco.com] >>> Sent: Tuesday, October 11, 2011 6:52 AM >>> To: v6ops v6ops WG >>> Cc: Behave Chairs; draft-donley-behave-deterministic-cgn@tools.ietf.org >>> Subject: Please review draft-donley-behave-deterministic-cgn >>>=20 >>> Operators subject to law enforcement subpoenas and using Carrier Grade >>>NAT are having difficulties with the syslog rate for per-connection >>>logging. Chris Donley has proposed a simplification; the provider >>>allocates a deterministic set of source ports to his subscribers, and >>>only needs to log exceptions. Research in the area suggests that usage >>>of source ports is pareto distributed; a typical user has a requirement >>>on the order of 4 port numbers in simultaneous use (median), but port >>>scans and other large volume uses drive the average quite a bit higher. >>>=20 >>> They haven't asked for it, but I suspect the behave chairs would >>>appreciate operational commentary on the draft. >>>=20 >>> http://tools.ietf.org/html/draft-donley-behave-deterministic-cgn >>> "Deterministic Address Mapping to Reduce Logging in Carrier Grade >>>NATs", >>> Chris Donley, Chris Grundemann, Vikas Sarawat, Karthik Sundaresan, >>> 26-Sep-11 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From simon.perreault@viagenie.ca Wed Jan 11 05:14:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94B621F86F4 for ; Wed, 11 Jan 2012 05:14:23 -0800 (PST) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPsX1BcG5QqU for ; Wed, 11 Jan 2012 05:14:23 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5C521F86D8 for ; Wed, 11 Jan 2012 05:14:23 -0800 (PST) Received: from balaise.nomis80.org (modemcable070.153-130-66.mc.videotron.ca [66.130.153.70]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7284A20D15; Wed, 11 Jan 2012 08:13:52 -0500 (EST) Message-ID: <4F0D8B0F.2030400@viagenie.ca> Date: Wed, 11 Jan 2012 08:13:51 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Fernando Gont References: <4F04F5CA.6010802@si6networks.com> <4F05AA98.4090400@viagenie.ca> <4F0A4D7F.6000101@si6networks.com> In-Reply-To: <4F0A4D7F.6000101@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Revised I-D: Advice on RA-Guard Implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 13:14:23 -0000 On 01/08/2012 09:14 PM, Fernando Gont wrote: > The second bullet in Section 3 is meant to address fragment-handling: > > o If the layer-2 device is unable to identify whether the packet is > an ICMPv6 Router Advertisement message or not (i.e., the packet is > a fragment, and the necessary information is missing), and the > IPv6 Source Address of the packet is a link-local address or the > unspecified address (::), block the packet. > > The idea is that if that non-first fragments are always forwarded, > whereas first-fragments are blocked if: > > a) We've found that what follows the fragment header is an RA packet, or, > > b) this is a first-fragment, and it is missing upper-layer protocol > information. Ok, I understand now. Thanks. I still don't see where in the text it is said that non-first fragments are always forwarded. It looks like it makes no difference between first and non-first. 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 wesley.george@twcable.com Wed Jan 11 06:54:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5C621F861F for ; Wed, 11 Jan 2012 06:54:01 -0800 (PST) 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=[AWL=-0.174, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVB-2zEz-F21 for ; Wed, 11 Jan 2012 06:54:01 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id C0BF621F85FC for ; Wed, 11 Jan 2012 06:54:00 -0800 (PST) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="306711896" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 11 Jan 2012 09:52:23 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Wed, 11 Jan 2012 09:53:59 -0500 From: "George, Wes" To: Brian E Carpenter , IPv6 Operations Date: Wed, 11 Jan 2012 09:53:58 -0500 Thread-Topic: [v6ops] [Fwd: I-D Action: draft-carpenter-v6ops-icp-guidance-02.txt] Thread-Index: AczPOQ8xglH06HDwS961sz04+t7y4ABNiA/g Message-ID: References: <4F0B975E.60604@gmail.com> In-Reply-To: <4F0B975E.60604@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] [Fwd: I-D Action: draft-carpenter-v6ops-icp-guidance-02.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 14:54:01 -0000 Brian - Thanks for addressing my comments in this version. I'm still on the fence about the draft status - I'm no longer opposed to ad= opting it as a WG item if that's the general consensus, but I think it woul= d be ok as an individual draft as well. A couple of additional comments from this read. In your introduction, You mention the "first do no harm" concept - don't ma= ke IPv4 worse by deploying IPv6 (with the implication that some IPv6 transi= tion technologies might have that effect). I think you might be able to take that a step further and note that IPv4 *e= xtension* technologies (CGN, etc) on the client side may also have that eff= ect, meaning that this is one of the reasons why ubiquitous IPv6 support (p= erhaps "on by default" even) is critical for ASP/ICP - it increases the cha= nces that their service transits to an end customer largely unmolested by I= Pv4 extension technologies. Additionally, it might be worth mentioning the connection between the ICP/A= SP and their partners and their partner's uplinks - that is, if an ASP/ICP = has a direct business relationship with the consumers/clients of their cont= ent or the networks that connect them to their clients, they should be work= ing with those partners to ensure that they have a plan to enable IPv6 on t= heir side (especially in implementations that require IPv6 support in speci= alized programs or systems for the IPv6 support on the ICP/ASP to be useful= ), and that they have first-class IPv6 connectivity between the networks. T= his coordination and testing detail is something that's sometimes overlooke= d, and while it's getting to a point where it might be a safe assumption th= at IPv6 is already available on the remote side, at this point it's worth m= entioning explicitly. Thanks, Wes George > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Brian E Carpenter > Sent: Monday, January 09, 2012 8:42 PM > To: IPv6 Operations > Subject: [v6ops] [Fwd: I-D Action: draft-carpenter-v6ops-icp-guidance- > 02.txt] > > Hi, > > We've updated this according to the comments received since Taipei. > > At this point we'd like opinions about the future of the document. > Should it become a WG draft, or should we progress it as an > individual submission? > > Brian > > -------- Original Message -------- > Subject: I-D Action: draft-carpenter-v6ops-icp-guidance-02.txt > Date: Fri, 06 Jan 2012 11:37:09 -0800 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : IPv6 Guidance for Internet Content and > Application Service Providers > Author(s) : Brian Carpenter > Sheng Jiang > Filename : draft-carpenter-v6ops-icp-guidance-02.txt > Pages : 16 > Date : 2012-01-06 > > This document provides guidance and suggestions for Internet Content > Providers and Application Service Providers who wish to offer their > service to both IPv6 and IPv4 customers. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance- > 02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance- > 02.txt > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From C.Grundemann@cablelabs.com Wed Jan 11 09:02:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2B421F887A for ; Wed, 11 Jan 2012 09:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.974 X-Spam-Level: * X-Spam-Status: No, score=1.974 tagged_above=-999 required=5 tests=[AWL=0.578, BAYES_20=-0.74, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qfxal8vYuBB for ; Wed, 11 Jan 2012 09:02:33 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1C46621F886F for ; Wed, 11 Jan 2012 09:02:33 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q0BH2T7S026734; Wed, 11 Jan 2012 10:02:29 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 11 Jan 2012 10:02:29 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 11 Jan 2012 10:02:29 -0700 From: Chris Grundemann To: Cameron Byrne , Wesley George Date: Wed, 11 Jan 2012 10:02:27 -0700 Thread-Topic: [v6ops] Please review draft-donley-behave-deterministic-cgn Thread-Index: AczQgs1wYPcT2B4jQbyALHSU1BLGaA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: v6ops v6ops WG , Dave Thaler , Behave Chairs , "draft-donley-behave-deterministic-cgn@tools.ietf.org" Subject: Re: [v6ops] Please review draft-donley-behave-deterministic-cgn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 17:02:33 -0000 On 1/5/12 9:33 AM, "Cameron Byrne" wrote: > >So, what does that mean for a mobile operator? Not "periodic mobile >web access" as you say. It means there are a lot of long lived and >sustained CGN sessions. Or, an alternative solution, dare i say the >forbidden word on an IPv4 life support thread? ... ipv6. Yes, as mobile Internet usage becomes more and more like fixed Internet usage, mobile operators are going to have to look more and more to solutions that look more like those of the fixed operators (lower IPv4 CGN compression ratios and native IPv6 to name a couple). >Let me also clear up something, most of mobile operator traffic is >volume is video. > >http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns >827/white_paper_c11-520862.html > >"Mobile video traffic will exceed 50 percent for the first time in >2011. Mobile video traffic was 49.8 percent of total mobile data >traffic at the end of 2010, and will account for 52.8 percent of >traffic by the end of 2011." > >Once again, "not periodic mobile web" Yes, mobile data usage is growing, but the delta is still massive between what people do online at home and on the go. Specific to video, Nielson reports that the average user watches 27 minutes a month of video online at home and only 7 minutes a month on mobile. http://techcrunch.com/2012/01/08/how-people-watch-tv-online/ So mobile's still about 4x shy (on average) in time and don't forget that many apps are "optimized" for mobile viewing, giving the user less ports, lower bit-rates, etc=8A Chris, ~Chris > >cb >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From C.Grundemann@cablelabs.com Wed Jan 11 09:45:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7629621F86FD for ; Wed, 11 Jan 2012 09:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.5 X-Spam-Level: * X-Spam-Status: No, score=1.5 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_05=-1.11, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ex0lIYKC6r3R for ; Wed, 11 Jan 2012 09:45:46 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0397A21F86FA for ; Wed, 11 Jan 2012 09:45:45 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q0BHjhZ3031701; Wed, 11 Jan 2012 10:45:43 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 11 Jan 2012 10:45:43 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 11 Jan 2012 10:45:43 -0700 From: Chris Grundemann To: "Joel M. Halpern" , Dave Thaler Date: Wed, 11 Jan 2012 10:45:41 -0700 Thread-Topic: [v6ops] Please review draft-donley-behave-deterministic-cgn Thread-Index: AczQiNclTwW04G2GTtmksmBFvldprw== Message-ID: In-Reply-To: <4F04D370.7030403@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: v6ops v6ops WG , Behave Chairs , "draft-donley-behave-deterministic-cgn@tools.ietf.org" Subject: Re: [v6ops] Please review draft-donley-behave-deterministic-cgn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 17:45:46 -0000 On 1/4/12 3:32 PM, "Joel M. Halpern" wrote: >When I asked on operator about the port distribution, their answer was >somewhat different. >What they said was that when the users are idle, they don't use many >ports. But when the user is busy, they use a lot of ports. >This makes repeated, largeish, block allocation sensible, but makes >pre-allocation of a small number, and then individual allocation >thereafter, a bad strategy, as it will basically log as much as current. We (the authors) actually agree that very small port allocations are a bad idea with this methodology. Deterministic CGN should be used with low compression ratios for the greatest gains over dynamic block allocations. Remember that with just a 2:1 compression ratio (2 subscribers to each 1 public IPv4 address) you double the number of customers possible with your existing IP allocation(s). Plus, each of those customers has access to over 30,000 ports. However, you probably don't want to subject ALL of your customers to CGN, so higher compression ratios are likely needed. If you go all the way up to 64:1, you can put roughly 16,000 subscribers behind a single /24 and still dedicate about 1,000 ports to each of them (with zero need for logging). Then, you add in the ability to overflow into a shared, block-allocation pool for extreme bursts (because, again, we agree that some users are port-hogs and are often bursty in their usage). We feel that this approach truly is the best strategy, as long as you are able to keep the compression ratio's low (low enough that the static/deterministic allocation covers the majority of your customer's peak port utilization) in your network. Cheers, ~Chris > >I do not have access to any research results to disambiguate these two >reports. > >Yours, >Joel From cb.list6@gmail.com Wed Jan 11 12:06:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7261B21F84B5 for ; Wed, 11 Jan 2012 12:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.804 X-Spam-Level: X-Spam-Status: No, score=-2.804 tagged_above=-999 required=5 tests=[AWL=-0.694, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfJ0APYi+J9M for ; Wed, 11 Jan 2012 12:06:20 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id BEE6721F84B4 for ; Wed, 11 Jan 2012 12:06:20 -0800 (PST) Received: by dajz8 with SMTP id z8so839535daj.31 for ; Wed, 11 Jan 2012 12:06:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PblhG3QElqOL/AQx9xJwuJHvkyxggP1hGNmBHG+aHhU=; b=M51FCzkfxxyumwyA22ao9UtdckCvEisJMcvi+bbGyOSLNk398PJ/3CW4kIA5jYL0ZC HmK0L884+peDAHPNPNTx3nMStmKyvQRnLbmod+PJLu4WHUF7RitIvCotKiKTCyxfYxR0 x5NzW4BXpWzhaWUw+nanwGIAr2aW9gKdHGhzM= MIME-Version: 1.0 Received: by 10.68.115.17 with SMTP id jk17mr1979307pbb.47.1326312380516; Wed, 11 Jan 2012 12:06:20 -0800 (PST) Received: by 10.142.211.2 with HTTP; Wed, 11 Jan 2012 12:06:20 -0800 (PST) In-Reply-To: References: Date: Wed, 11 Jan 2012 12:06:20 -0800 Message-ID: From: Cameron Byrne To: Chris Grundemann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops WG , Dave Thaler , "draft-donley-behave-deterministic-cgn@tools.ietf.org" , Behave Chairs Subject: Re: [v6ops] Please review draft-donley-behave-deterministic-cgn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 20:06:21 -0000 On Wed, Jan 11, 2012 at 9:02 AM, Chris Grundemann wrote: > > > On 1/5/12 9:33 AM, "Cameron Byrne" wrote: >> >>So, what does that mean for a mobile operator? Not "periodic mobile >>web access" as you say. =C2=A0It means there are a lot of long lived and >>sustained CGN sessions. =C2=A0Or, an alternative solution, dare i say the >>forbidden word on an IPv4 life support thread? ... ipv6. > > Yes, as mobile Internet usage becomes more and more like fixed Internet > usage, mobile operators are going to have to look more and more to > solutions that look more like those of the fixed operators (lower IPv4 CG= N > compression ratios and native IPv6 to name a couple). > I don't think suggesting incrementally lower IPv4 efficiency is a helpful solution to the IPv4 exhaust problem. >>Let me also clear up something, most of mobile operator traffic is >>volume is video. >> >>http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/n= s >>827/white_paper_c11-520862.html >> >>"Mobile video traffic will exceed 50 percent for the first time in >>2011. Mobile video traffic was 49.8 percent of total mobile data >>traffic at the end of 2010, and will account for 52.8 percent of >>traffic by the end of 2011." >> >>Once again, "not periodic mobile web" > > Yes, mobile data usage is growing, but the delta is still massive between > what people do online at home and on the go. Specific to video, Nielson > reports that the average user watches 27 minutes a month of video online > at home and only 7 minutes a month on mobile. > > http://techcrunch.com/2012/01/08/how-people-watch-tv-online/ > > So mobile's still about 4x shy (on average) in time and don't forget that > many apps are "optimized" for mobile viewing, giving the user less ports, > lower bit-rates, etc=C5=A0 > From C.Grundemann@cablelabs.com Wed Jan 11 12:21:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE8811E80C2 for ; Wed, 11 Jan 2012 12:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.597 X-Spam-Level: X-Spam-Status: No, score=0.597 tagged_above=-999 required=5 tests=[AWL=1.060, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nj54vohi92kH for ; Wed, 11 Jan 2012 12:21:25 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5F97111E80AB for ; Wed, 11 Jan 2012 12:21:25 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q0BKLM6x016229; Wed, 11 Jan 2012 13:21:22 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 11 Jan 2012 13:21:22 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 11 Jan 2012 13:21:22 -0700 From: Chris Grundemann To: Cameron Byrne Date: Wed, 11 Jan 2012 13:21:20 -0700 Thread-Topic: [v6ops] Please review draft-donley-behave-deterministic-cgn Thread-Index: AczQnpWitnjqN+hVSzmcF44zsxbqTg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: v6ops v6ops WG , Dave Thaler , "draft-donley-behave-deterministic-cgn@tools.ietf.org" , Behave Chairs Subject: Re: [v6ops] Please review draft-donley-behave-deterministic-cgn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 20:21:26 -0000 On 1/11/12 1:06 PM, "Cameron Byrne" wrote: >On Wed, Jan 11, 2012 at 9:02 AM, Chris Grundemann > wrote: >> >> >> On 1/5/12 9:33 AM, "Cameron Byrne" wrote: >>> >>>So, what does that mean for a mobile operator? Not "periodic mobile >>>web access" as you say. It means there are a lot of long lived and >>>sustained CGN sessions. Or, an alternative solution, dare i say the >>>forbidden word on an IPv4 life support thread? ... ipv6. >> >> Yes, as mobile Internet usage becomes more and more like fixed Internet >> usage, mobile operators are going to have to look more and more to >> solutions that look more like those of the fixed operators (lower IPv4 >>CGN >> compression ratios and native IPv6 to name a couple). >> > >I don't think suggesting incrementally lower IPv4 efficiency is a >helpful solution to the IPv4 exhaust problem. I wasn't suggesting lower IPv4 efficiency as a solution to the IPv4 exhaust problem. I was stating the fact that if mobile operators want their data services to look/feel/behave more like fixed ISP services (DSL/cable/etc), then they will have to operate their networks accordingly. I do agree that this creates a problem for mobile operators who choose not to deploy IPv6. Since we're veering off the topic of this thread, I'll leave it at that (I'm happy to continue the discussion off-line if you'd like). Cheers, ~Chris =20 > >>>Let me also clear up something, most of mobile operator traffic is >>>volume is video. >>> >>>http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ >>>ns >>>827/white_paper_c11-520862.html >>> >>>"Mobile video traffic will exceed 50 percent for the first time in >>>2011. Mobile video traffic was 49.8 percent of total mobile data >>>traffic at the end of 2010, and will account for 52.8 percent of >>>traffic by the end of 2011." >>> >>>Once again, "not periodic mobile web" >> >> Yes, mobile data usage is growing, but the delta is still massive >>between >> what people do online at home and on the go. Specific to video, Nielson >> reports that the average user watches 27 minutes a month of video online >> at home and only 7 minutes a month on mobile. >> >> http://techcrunch.com/2012/01/08/how-people-watch-tv-online/ >> >> So mobile's still about 4x shy (on average) in time and don't forget >>that >> many apps are "optimized" for mobile viewing, giving the user less >>ports, >> lower bit-rates, etc=A9 >> From v6ops@globis.net Thu Jan 12 03:00:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21DDA21F85A4 for ; Thu, 12 Jan 2012 03:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQAgNVrl-2py for ; Thu, 12 Jan 2012 03:00:34 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 910F621F8594 for ; Thu, 12 Jan 2012 03:00:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 7C5A88700E3; Thu, 12 Jan 2012 12:00:31 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net 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 1v0crNUjbcom; Thu, 12 Jan 2012 12:00:22 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id F14FC87005C; Thu, 12 Jan 2012 12:00:21 +0100 (CET) Message-ID: <4F0EBD45.3070003@globis.net> Date: Thu, 12 Jan 2012 12:00:21 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: v6ops v6ops WG References: <2AD7A9CB-A67C-41CD-8F9F-664EBBE4E880@cisco.com> In-Reply-To: <2AD7A9CB-A67C-41CD-8F9F-664EBBE4E880@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-v6nd-problems WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 11:00:35 -0000 I have reviewed this document in detail, and forwarded a number of nits direct to the authors. I believe that the document contains important operational information and advice to the v6ops community. regards, RayH Fred Baker wrote: > This is to initiate a two week working group last call of draft-ietf-v6ops-v6nd-problems. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list. > > We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make. > From fgont@si6networks.com Thu Jan 12 07:56:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDAB21F85E6 for ; Thu, 12 Jan 2012 07:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[AWL=1.079, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akXtu5B76Luj for ; Thu, 12 Jan 2012 07:56:49 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id B6BD321F85E9 for ; Thu, 12 Jan 2012 07:56:49 -0800 (PST) Received: from [190.48.225.51] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RlN10-0001Ui-NU; Thu, 12 Jan 2012 16:56:38 +0100 Message-ID: <4F0EF14E.7080305@si6networks.com> Date: Thu, 12 Jan 2012 11:42:22 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Simon Perreault References: <4F04F5CA.6010802@si6networks.com> <4F05AA98.4090400@viagenie.ca> <4F0A4D7F.6000101@si6networks.com> <4F0D8B0F.2030400@viagenie.ca> In-Reply-To: <4F0D8B0F.2030400@viagenie.ca> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Revised I-D: Advice on RA-Guard Implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 15:56:50 -0000 Hi, Simon, On 01/11/2012 10:13 AM, Simon Perreault wrote: >> The idea is that if that non-first fragments are always forwarded, >> whereas first-fragments are blocked if: >> >> a) We've found that what follows the fragment header is an RA packet, or, >> >> b) this is a first-fragment, and it is missing upper-layer protocol >> information. > > Ok, I understand now. Thanks. > > I still don't see where in the text it is said that non-first fragments > are always forwarded. It looks like it makes no difference between first > and non-first. You're right. I will improve the corresponding section and send you a heads up so that you can take a look and comment before I rev the document. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From joelja@bogus.com Thu Jan 12 08:50:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBDD221F8597 for ; Thu, 12 Jan 2012 08:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.074 X-Spam-Level: X-Spam-Status: No, score=-101.074 tagged_above=-999 required=5 tests=[AWL=-1.375, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MANGLED_TOOL=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypL2TN4vNWIz for ; Thu, 12 Jan 2012 08:50:43 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7504521F84E0 for ; Thu, 12 Jan 2012 08:50:43 -0800 (PST) Received: from Joels-MacBook-Pro.local (host-64-47-136-190.masergy.com [64.47.136.190]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q0CGodp3030522 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 12 Jan 2012 16:50:39 GMT (envelope-from joelja@bogus.com) Message-ID: <4F0F0F5A.10805@bogus.com> Date: Thu, 12 Jan 2012 08:50:34 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: v6ops v6ops WG References: <2AD7A9CB-A67C-41CD-8F9F-664EBBE4E880@cisco.com> In-Reply-To: <2AD7A9CB-A67C-41CD-8F9F-664EBBE4E880@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 12 Jan 2012 16:50:40 +0000 (UTC) Cc: v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-v6nd-problems WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 16:50:44 -0000 On 1/8/12 22:32 , Fred Baker wrote: > This is to initiate a two week working group last call of draft-ietf-v6ops-v6nd-problems. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list. > > We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make. The version 01 contains the last major change, to reflect concerns brian raised at wg acceptance. version 02 is largely just corrections. The diff2 from 00 to 01 is here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-v6nd-problems-01.txt _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From wesley.george@twcable.com Fri Jan 13 09:01:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3ED21F84D7 for ; Fri, 13 Jan 2012 09:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.562 X-Spam-Level: X-Spam-Status: No, score=-0.562 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xnWhww8e4gN for ; Fri, 13 Jan 2012 09:01:56 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 7C25821F84D0 for ; Fri, 13 Jan 2012 09:01:56 -0800 (PST) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.71,504,1320642000"; d="scan'208";a="323842877" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 13 Jan 2012 11:55:21 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Fri, 13 Jan 2012 12:01:41 -0500 From: "George, Wes" To: v6ops v6ops WG Date: Fri, 13 Jan 2012 12:01:40 -0500 Thread-Topic: [v6ops] draft-ietf-v6ops-v6nd-problems WGLC Thread-Index: AczOmIqTkFMAmHD9SnKpjzimbY2cZADdJsUg Message-ID: References: <2AD7A9CB-A67C-41CD-8F9F-664EBBE4E880@cisco.com> In-Reply-To: <2AD7A9CB-A67C-41CD-8F9F-664EBBE4E880@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops-chairs@tools.ietf.org" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-v6nd-problems WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 17:01:57 -0000 This is a very useful document overall, and I support its advancement. A few LC comments: Section 4 "..during testing... 4 simultaneous NMAP sessions... make a route= r's ND process unusable..." Since you specify that the NMAP sessions were running on a low-end PC, it w= ould be worth characterizing what type/vintage of router we're talking abou= t here. Big difference between killing a small-office type router (eg 2600)= vs a major core router with the latest and greatest multi-core CPU. I thin= k that the last sentence in section 4 may be trying to imply that it really= doesn't matter the relative size/scale of the platform, but it's a bit unc= lear, especially given the specific mention of running 4 NMAP sessions... I'm not certain that section 5 is totally necessary - shouldn't this assume= that one either knows how ND works or has read the helpful references prov= ided elsewhere in the document? If you keep the section, for completeness it might be worth saying somethin= g about if/when the device doesn't receive the Neighbor Advertisement and t= he packet gets dropped. 6.3 - might be worth discussing the alternative of using a separate routing= protocol from the IGP and doing redistribution rather than using the same = IGP - this at least gets away from the concern about having end hosts parti= cipating directly in the IGP. 7.1 - I'd prefer that there be some recommendation that these prioritizatio= ns be configurable - while this priority might be the default and work in m= ost cases, for maximum flexibility, it makes sense to be able to prioritize= differently rather than having this be hard-coded. #4 especially comes wit= h some tradeoffs depending on the type of network and what the hosts are do= ing on it. Thanks, Wes George > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Fred Baker > Sent: Monday, January 09, 2012 1:32 AM > To: v6ops@ietf.org > Cc: v6ops-chairs@tools.ietf.org; Ron Bonica > Subject: [v6ops] draft-ietf-v6ops-v6nd-problems WGLC > > This is to initiate a two week working group last call of draft-ietf- > v6ops-v6nd-problems. Please read it now. If you find nits (spelling > errors, minor suggested wording changes, etc), comment to the authors; > if you find greater issues, such as disagreeing with a statement or > finding additional issues that need to be addressed, please post your > comments to the list. > > We are looking specifically for comments on the importance of the > document as well as its content. If you have read the document and > believe it to be of operational utility, that is also an important > comment to make. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From fred@cisco.com Fri Jan 13 12:50:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70FF311E807A for ; Fri, 13 Jan 2012 12:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.354 X-Spam-Level: X-Spam-Status: No, score=-106.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oaKZSlSxNXTn for ; Fri, 13 Jan 2012 12:50:33 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id C403711E8072 for ; Fri, 13 Jan 2012 12:50:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1456; q=dns/txt; s=iport; t=1326487832; x=1327697432; h=from:subject:date:references:to:message-id:mime-version: content-transfer-encoding; bh=2Mdvw01Uv62mzx2msWyCbj3BFsP0pd/13u6FRk87toI=; b=KeU2yFECFrwp1P27yNW/jxDeMMK8y8ZVTcpHjyMdHzPsi4M737cqiLMf tfr07CuN49otuzhaGRoUwf61vG/w71y9d+iTJSy1PX90yliuL/B0zdGIr Yo0iWGuITEsFnUxHJrWgLHDdTWY7UgNEISlFUEJ1cp70YzsJ7Ile1G3wv U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAOSXEE+rRDoJ/2dsb2JhbABCrS+BBYFyAQEBAwESASdECxwDAQIvTQIIBhMih1gImF4BniKLOmMEiDyMVoVRjQ8 X-IronPort-AV: E=Sophos;i="4.71,506,1320624000"; d="scan'208";a="23618979" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 13 Jan 2012 20:50:32 +0000 Received: from stealth-10-32-244-220.cisco.com (stealth-10-32-244-220.cisco.com [10.32.244.220]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0DKoWju025507 for ; Fri, 13 Jan 2012 20:50:32 GMT Received: from [127.0.0.1] by stealth-10-32-244-220.cisco.com (PGP Universal service); Fri, 13 Jan 2012 12:50:32 -0800 X-PGP-Universal: processed; by stealth-10-32-244-220.cisco.com on Fri, 13 Jan 2012 12:50:32 -0800 From: Fred Baker Date: Fri, 13 Jan 2012 12:50:23 -0800 References: <060c01ccd22f$f7269ae0$e573d0a0$@com> To: v6ops v6ops WG Message-Id: <32EAD8B3-E30A-4A99-97A4-992757AD43A5@cisco.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [v6ops] Fwd: slashdot: IPv6-only Is Becoming Viable X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 20:50:35 -0000 Several interesting comments in here, most notably the reference to = IPv6-capable applications and to IPv4 as a "boat anchor". > From: "Dan Wing" > Date: January 13, 2012 12:14:31 PM PST > Subject: slashdot: IPv6-only Is Becoming Viable >=20 > http://slashdot.org/submission/1909164/ >=20 > it has lots of slashdot-style embedded links, and text is: >=20 > "With the success of world IPv6 day in 2011, there is a lot of > speculation about IPv6 in 2012. But simply turning on IPv6 does not = make the > problems of IPv4 exhaustion go away. It is only when services are = usable > with IPv6-only that the internet can clip the ties to the IPv4 boat = anchor. > That said, FreeBSD, Windows, and Android are working on IPv6-only > capabilities. There are multiple accounts of IPv6-only network = deployments. > =46rom those, we we now know that IPv6-only is viable in mobile, where = over > 80% (of a sampling of the top 200 apps) work well with IPv6-only. = Mobile > especially needs IPv6, since their are only 4 billion IPv4 address and > approaching 50 billion mobile devices in the next 8 years. Ironically, = the > Android test data shows that the apps most likely to fail are = peer-to-peer, > like Skype. Traversing NAT and relying on broken IPv4 is built into = their > method of operating. P2P communications was supposed to be one of the = key > improvements in IPv6." >=20 >=20 >=20 >=20 From dougb@dougbarton.us Fri Jan 13 15:41:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325F621F8562 for ; Fri, 13 Jan 2012 15:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fO7ydef6ZTwS for ; Fri, 13 Jan 2012 15:41:33 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 6A66C21F855D for ; Fri, 13 Jan 2012 15:41:33 -0800 (PST) Received: (qmail 31168 invoked by uid 399); 13 Jan 2012 23:41:19 -0000 Received: from unknown (HELO 172-17-198-245.globalsuite.net) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 13 Jan 2012 23:41:19 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <4F10C113.2040403@dougbarton.us> Date: Fri, 13 Jan 2012 15:41:07 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Fred Baker References: <060c01ccd22f$f7269ae0$e573d0a0$@com> <32EAD8B3-E30A-4A99-97A4-992757AD43A5@cisco.com> In-Reply-To: <32EAD8B3-E30A-4A99-97A4-992757AD43A5@cisco.com> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops v6ops WG Subject: Re: [v6ops] Fwd: slashdot: IPv6-only Is Becoming Viable X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 23:41:34 -0000 On 01/13/2012 12:50, Fred Baker wrote: > FreeBSD, Windows, and Android are working on IPv6-only capabilities. http://wiki.freebsd.org/IPv6Only -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From mawatari@jpix.ad.jp Sun Jan 15 17:51:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2E621F84D8 for ; Sun, 15 Jan 2012 17:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id My9ycWpO1uho for ; Sun, 15 Jan 2012 17:51:21 -0800 (PST) Received: from mx20.jpix.ad.jp (mx20.jpix.ad.jp [210.171.225.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1B421F844E for ; Sun, 15 Jan 2012 17:51:20 -0800 (PST) Received: from [10.10.31.235] (eth3-1-bb-fw-34.jpix.ad.jp [210.171.226.102]) by mx20.jpix.ad.jp (Postfix) with ESMTP id CCEABFC021 for ; Mon, 16 Jan 2012 10:51:17 +0900 (JST) Date: Mon, 16 Jan 2012 10:51:18 +0900 From: MAWATARI Masataka To: v6ops@ietf.org Message-Id: <20120116105118.9F36.8FE1F57E@jpix.ad.jp> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------_4F136D67000000009F2B_MULTIPART_MIXED_" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.57.03 [ja] Subject: [v6ops] Fw: New Version Notification for draft-mawatari-v6ops-464xlat-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 01:51:22 -0000 --------_4F136D67000000009F2B_MULTIPART_MIXED_ Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Dear v6ops, I am Masataka Mawatari from JPIX. We had submitted a draft that describes an architecture and our experience for providing IPv4 connectivity across IPv6 network by combining stateful protocol translation RFC 6146 in network and stateless protocol translation RFC 6145 at CPE. This architecture in the draft is called "464XLAT". http://tools.ietf.org/html/draft-mawatari-v6ops-464xlat-00 We believe the 464XLAT informational draft fits with #1 and #4 in the v6ops charter for identifying solutions that promote the ability of network operators to deploy IPv6 and integrate with the IPv4/IPv6 internet. The 464XLAT architecture uses standards created in BEHAVE WG. We believe this draft best fits with v6ops WG since it outlines a proven and deployed architecture that leverages existing standards for solving the IP number problem by better enabling IPv6-only networks to meet the needs of operators (cost, simplicity, time to market...) and subscribers (it just works ...). T-Mobile USA has been operating a beta IPv6-only NAT64/DNS64 network for nearly 2 years now, and on that trial network (which is full production in SF Bay, and will be national full production by end of Q1) the need for 464XLAT emerged to overcome the issue of IPv4-only applications and IPv4 referrals. The T-Mobile USA users solved the problem themselves by coding a stateless translation application on the Nokia N900: http://code.google.com/p/n900ipv6/wiki/Nat64D JPIX (Japan Internet Exchange) has been providing 464XLAT trial service for JPIX members since July 2010 to deploy IPv6 access service in wireline networks. Especially small-medium ISPs do not have a operation resource and much IPv4 address pool to solve IPv4 address exhaustion in each ISP backbone network so JPIX proposes to support IPv4 address sharing solution. We have a CPE router with stateless translation implemented by NEC AccessTechnica. http://www.apricot.net/apricot2011/media/Masataka_Mawatari_IPv6v4_Exchange_= Service_for_sharing_IPv4_address.pdf =46rom there, it became apparent that the solution was viable both in wireless and wireline networks. We are currently in the process of stewarding the 464XLAT CLAT code via the Android code contribution process, and we have a working implementation here: http://code.google.com/p/android-clat/ We believe our draft creates a reasonable solution for the problem statement created in draft-arkko-ipv6-only-experience. We are seeking the groups feedback on if this draft should be a working group item that would benefit from working group review and refinement to better extend and repeat what has already been achieved with 464XLAT. Kind Regards, Masataka MAWATARI --------_4F136D67000000009F2B_MULTIPART_MIXED_ Content-Type: message/rfc822 Content-Description: New Version Notification for draft-mawatari-v6ops-464xlat-00.txt Return-Path: X-Original-To: mawatari@jpix.ad.jp Delivered-To: mawatari@jpix.ad.jp Received: from mg1.jpix.ad.jp (mg1.jpix.ad.jp [210.171.225.84]) by mx20.jpix.ad.jp (Postfix) with ESMTP id 44D56FC021 for ; Mon, 16 Jan 2012 00:12:11 +0900 (JST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8CALDrEk8MFjoemWdsb2JhbABEhRGYIQGQAyIBAQEBAQgLCxslghxUAi0IAiYCSQKsNJBpgS+HTIIGgRYEiDuMVQGSYg X-IronPort-AV: E=Sophos;i="4.71,514,1320591600"; d="scan'208";a="113456" Received: from mail.ietf.org ([12.22.58.30]) by mg1.jpix.ad.jp with ESMTP; 16 Jan 2012 00:12:10 +0900 Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8FC21F8498; Sun, 15 Jan 2012 07:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AThivIYGhr-X; Sun, 15 Jan 2012 07:12:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187EA21F849A; Sun, 15 Jan 2012 07:12:04 -0800 (PST) MIME-Version: 1.0 From: internet-drafts@ietf.org To: kawashimam@vx.jp.nec.com Cc: mawatari@jpix.ad.jp, kawashimam@vx.jp.nec.com, cameron.byrne@t-mobile.com Subject: New Version Notification for draft-mawatari-v6ops-464xlat-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120115151204.14422.79592.idtracker@ietfa.amsl.com> Date: Sun, 15 Jan 2012 07:12:04 -0800 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable A new version of I-D, draft-mawatari-v6ops-464xlat-00.txt has been successf= ully submitted by Masanobu Kawashima and posted to the IETF repository. Filename: draft-mawatari-v6ops-464xlat Revision: 00 Title: 464XLAT: Combination of Stateful and Stateless Translation Creation date: 2012-01-15 WG ID: Individual Submission Number of pages: 14 Abstract: This document describes an architecture (464XLAT) for providing IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation RFC 6146 and stateless protocol translation RFC 6145. 464XLAT is a simple and scalable technique to quickly deploy IPv4 access service to mobile and wireline IPv6-only networks without encapsulation. = = The IETF Secretariat --------_4F136D67000000009F2B_MULTIPART_MIXED_-- From fx.lebail@yahoo.com Mon Jan 16 05:59:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B91C21F85EA for ; Mon, 16 Jan 2012 05:59:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.715 X-Spam-Level: X-Spam-Status: No, score=0.715 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oe4R47tBEkcp for ; Mon, 16 Jan 2012 05:59:36 -0800 (PST) Received: from nm21-vm3.bullet.mail.ne1.yahoo.com (nm21-vm3.bullet.mail.ne1.yahoo.com [98.138.91.151]) by ietfa.amsl.com (Postfix) with SMTP id 99F1221F85DA for ; Mon, 16 Jan 2012 05:59:34 -0800 (PST) Received: from [98.138.90.50] by nm21.bullet.mail.ne1.yahoo.com with NNFMP; 16 Jan 2012 13:59:34 -0000 Received: from [98.138.89.254] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 16 Jan 2012 13:59:34 -0000 Received: from [127.0.0.1] by omp1046.mail.ne1.yahoo.com with NNFMP; 16 Jan 2012 13:59:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 885643.45442.bm@omp1046.mail.ne1.yahoo.com Received: (qmail 53470 invoked by uid 60001); 16 Jan 2012 13:59:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1326722373; bh=g39Y2X65cLlCzoW6p1E+l0zJvlNjubTV8Dwa+vW+f4Y=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=YB02H8zd5K/OsYWsxSmiBlGcrA2a86Z76Rn1MadLVH3/KW3Bj20Wua/4OAFazY9YE6E1WHMlBvUN15bTqmQLyqHfX1kKmusJcl6+ucj5LOSTr8eUZvs5FTP5FGYpX92QMPabPIxfDEAvYVpIM86NKTyC01kcrzR/0KJDOjO11Qc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=IjOpFsJ3wNgTaUXkW4uEMxeiRw7B6c+kTUk+ZuqoDmff2HdiffoXa2Mp+EI8OQRDLtq+oo7FnPO0oIGULzSB9CFLmPru+eNN1vaYSC3SEsxnWUHUQ1lrrN8uk+oICemPL/MdQmig+X9lr8uw7DarQnmURnNAv0fuvI3vDPa9er8=; X-YMail-OSG: obk_3MkVM1naW38frZH1CO1JaidCIwE7dcOa283Fk3LuStm 7.19G3lKJ6kOtKYu0m4jnLy5R5.8g35VPhGclHSYGyzJBE8iiOOIKm6kel1p jJyt2WFk5dmNpGcgrWI6QuIRM4M7glvUZHV8O0zjdB0rq7zLGTgJUtYBdovC SW5mcjsk3q5aaMbLC7nj205mGgEwn.bRMUIvc8SaTINJXh4moZZGLd8urhyH PAUzkoHO6qVv3hV1G1xMyul4qPE5c.m7899jO2TIBbFhZTwlqZbE4q0jL5tQ V8RP320XOanFk2EmArVne7uundQMXvFjW.JOEmU9WjBp18etHg4vQrgwV_11 _KlE3ldHQLZg8xkLwfB1wPyZfqsccd2UgKpBm_mgcdJGdTMlixBXMgc8_HHf EXwgQ3RhHCSZ7mVoWmqZizsyv.X91KPN6Khb5ayAkTxgnoOoHYc5fg5Hq.NZ HWmIdXRoE Received: from [193.49.124.107] by web126005.mail.ne1.yahoo.com via HTTP; Mon, 16 Jan 2012 05:59:33 PST X-Mailer: YahooMailWebService/0.8.115.331698 References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com> Message-ID: <1326722373.49203.YahooMailNeo@web126005.mail.ne1.yahoo.com> Date: Mon, 16 Jan 2012 05:59:33 -0800 (PST) From: =?iso-8859-1?Q?Fran=E7ois-Xavier_Le_Bail?= To: "v6ops@ietf.org WG" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: =?iso-8859-1?Q?Fran=E7ois-Xavier_Le_Bail?= List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 13:59:36 -0000 Hi,=0AG-1: An IPv6 CE router is an IPv6 node according to the IPv6 Node Re= quirements [RFC4294] specification. =0ARFC 4294 -> RFC 6434 ?=0A=0ACheers,= =0AFran=E7ois-Xavier=0A=0A=0A=0A----- Original Message -----=0A> From: Fred= Baker =0A> To: "v6ops@ietf.org WG" =0A> Cc= : =0A> Sent: Wednesday, January 4, 2012 12:26 AM=0A> Subject: [v6ops] Fwd: = I-D Action: draft-ietf-v6ops-6204bis-05.txt=0A> =0A> Folks - there is a new= draft of 6204bis. Those that have issues with previous =0A> drafts are enc= ouraged to comment on this version.=0A> =0A> Begin forwarded message:=0A> = =0A>> From: internet-drafts@ietf.org=0A>> Date: December 22, 2011 1:03:18= PM PST=0A>> To: i-d-announce@ietf.org=0A>> Cc: v6ops@ietf.org=0A>> Subj= ect: I-D Action: draft-ietf-v6ops-6204bis-05.txt=0A>> Reply-To: internet-d= rafts@ietf.org=0A>> =0A>> =0A>> A New Internet-Draft is available from the= on-line Internet-Drafts =0A> directories. This draft is a work item of the= IPv6 Operations Working Group of =0A> the IETF.=0A>> =0A>> =A0=A0=A0 Titl= e=A0 =A0 =A0 =A0 =A0 : Basic Requirements for IPv6 Customer Edge Routers= =0A>> =A0=A0=A0 Author(s)=A0 =A0 =A0 : Hemant Singh=0A>> =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Wes Beebee=0A>> =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 Chris Donley=0A>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 Barbara Stark=0A>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 Ole Troan=0A>> =A0=A0=A0 Filename=A0 =A0 =A0 =A0 : dra= ft-ietf-v6ops-6204bis-05.txt=0A>> =A0=A0=A0 Pages=A0 =A0 =A0 =A0 =A0 : 21= =0A>> =A0=A0=A0 Date=A0 =A0 =A0 =A0 =A0 =A0 : 2011-12-22=0A>> =0A>> =A0 T= his document specifies requirements for an IPv6 Customer Edge (CE)=0A>> =A0= router.=A0 Specifically, the current version of this document focuses=0A>= > =A0 on the basic provisioning of an IPv6 CE router and the provisioning= =0A>> =A0 of IPv6 hosts attached to it.=A0 The document also covers IP tra= nsition=0A>> =A0 technologies.=A0 Two transition technologies in RFC 5969'= s 6rd and RFC=0A>> =A0 6333's DS-Lite. are covered in the document.=A0 The= document obsoletes=0A>> =A0 RFC 6204, if approved.=0A>> =0A>> =0A>> A UR= L for this Internet-Draft is:=0A>> http://www.ietf.org/internet-drafts/dra= ft-ietf-v6ops-6204bis-05.txt=0A>> =0A>> Internet-Drafts are also available= by anonymous FTP at:=0A>> ftp://ftp.ietf.org/internet-drafts/=0A>> =0A>> = This Internet-Draft can be retrieved at:=0A>> ftp://ftp.ietf.org/internet= -drafts/draft-ietf-v6ops-6204bis-05.txt=0A>> =0A>> _______________________= ________________________=0A>> I-D-Announce mailing list=0A>> I-D-Announce= @ietf.org=0A>> https://www.ietf.org/mailman/listinfo/i-d-announce=0A>> In= ternet-Draft directories: http://www.ietf.org/shadow.html=0A>> or ftp://ft= p.ietf.org/ietf/1shadow-sites.txt=0A> =0A> ________________________________= _______________=0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https://www.i= etf.org/mailman/listinfo/v6ops=0A> From fred@cisco.com Mon Jan 16 07:48:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0E421F85D5 for ; Mon, 16 Jan 2012 07:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.368 X-Spam-Level: X-Spam-Status: No, score=-106.368 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+rr3W2oZccK for ; Mon, 16 Jan 2012 07:48:06 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id C3C9121F85D1 for ; Mon, 16 Jan 2012 07:48:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=997; q=dns/txt; s=iport; t=1326728886; x=1327938486; h=from:subject:date:message-id:cc:to:mime-version; bh=/YgR9aantodZP+ZockwteQ93lWxpR9RqkZBuAm1xzaQ=; b=XED04/V0oD2PKng50KpFEzDxJE7nhpT+Z8ODurYePJqpwxOLVnp5+OdO 3r31OcXypdtyH/z3yPNftWd7XXrecuy4eVEsM26xP7/G2L4a9kkYC7isR cQdY/s9sQF9GGJ33vJBySmRXUo2WqVDFmQSl/JtcNJ6Q4Eu4/UB0YQhot c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJ9GFE+rRDoG/2dsb2JhbABDgk2pYYELgQWCCwEKXB4BgVSfRAGeBYk1FhICAQENBQQRBQEGAQEGAQUXFQEBAQEBAgECAQIBAQEBAgcQBQ4mDEQQBQuBRSsCBgFMgjljBIg7jFaFUY0R X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208,217";a="25472760" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 16 Jan 2012 15:48:04 +0000 Received: from stealth-10-32-244-220.cisco.com (stealth-10-32-244-220.cisco.com [10.32.244.220]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0GFldoI012269; Mon, 16 Jan 2012 15:48:03 GMT Received: from [127.0.0.1] by stealth-10-32-244-220.cisco.com (PGP Universal service); Mon, 16 Jan 2012 07:48:03 -0800 X-PGP-Universal: processed; by stealth-10-32-244-220.cisco.com on Mon, 16 Jan 2012 07:48:03 -0800 From: Fred Baker Date: Mon, 16 Jan 2012 07:48:02 -0800 Message-Id: <9F17268C-B161-46B4-963B-FA449727DE96@cisco.com> To: v6ops@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: multipart/alternative; boundary=Apple-Mail-11-529331654 Cc: v6ops-chairs@tools.ietf.org, Ron Bonica Subject: [v6ops] Reminder: draft-ietf-v6ops-v6nd-problems WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 15:48:07 -0000 --Apple-Mail-11-529331654 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The working group last call for this draft announced last week continues = for another week. Please feel free to comment on it. --Apple-Mail-11-529331654 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
The working group last call for this draft announced last week continues for another week. Please feel free to comment on it.

--Apple-Mail-11-529331654-- From warren@kumari.net Mon Jan 16 13:33:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429E021F86C1 for ; Mon, 16 Jan 2012 13:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.234 X-Spam-Level: X-Spam-Status: No, score=-106.234 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4s5EIRBX4qW for ; Mon, 16 Jan 2012 13:33:57 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id C917921F86BE for ; Mon, 16 Jan 2012 13:33:57 -0800 (PST) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id C44741B4069C; Mon, 16 Jan 2012 16:33:56 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <4F0EBD45.3070003@globis.net> Date: Mon, 16 Jan 2012 16:33:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2AD7A9CB-A67C-41CD-8F9F-664EBBE4E880@cisco.com> <4F0EBD45.3070003@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1084) Cc: v6ops v6ops WG , v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-v6nd-problems WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 21:33:58 -0000 On Jan 12, 2012, at 6:00 AM, Ray Hunter wrote: > I have reviewed this document in detail, and forwarded a number of = nits direct to the authors. Yes, yes you did[0]=85 and the authors are remiss in not having = incorporated them yet=85 >=20 > I believe that the document contains important operational information = and advice to the v6ops community. Thanks! W [0]: And thank you for making them clear and helpful! >=20 > regards, > RayH >=20 > Fred Baker wrote: >> This is to initiate a two week working group last call of = draft-ietf-v6ops-v6nd-problems. Please read it now. If you find nits = (spelling errors, minor suggested wording changes, etc), comment to the = authors; if you find greater issues, such as disagreeing with a = statement or finding additional issues that need to be addressed, please = post your comments to the list. >>=20 >> We are looking specifically for comments on the importance of the = document as well as its content. If you have read the document and = believe it to be of operational utility, that is also an important = comment to make. >> =20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --- Don't be impressed with unintelligible stuff said condescendingly . -- Radia Perlman. Warren Kumari warren@kumari.net From fred@cisco.com Tue Jan 17 06:55:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCAAE21F85E6 for ; Tue, 17 Jan 2012 06:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-ZmQ8W1+G7U for ; Tue, 17 Jan 2012 06:55:02 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3864821F85C6 for ; Tue, 17 Jan 2012 06:55:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=130; q=dns/txt; s=iport; t=1326812102; x=1328021702; h=date:from:message-id:to:subject:cc; bh=LNCFC1RrwRhgAsqyhLKgSKwqYm8IWkMJIOl5dj3SR00=; b=L716zVZn8xGYu+U1KD9Tsy5vMA9OdlYKs2ZB/46kHid5G6YPsBTRC6nO 5m2Q4ZfO411Pppi3CqaBnXWDorcpTCXyHFl56t7WsUN79SAhLMeeRbT8C AeZ1dRGyB+JFgRmNvFjiLvDRVsup4ZiBbxU7fjkX4y0K9wZz4MzUL18VM c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsHACqLFU+rRDoJ/2dsb2JhbABEnUkBhCEDilGBBoEFggsBZjwtgQqHYJhKAZ5BiQcXPwECAQENAQoFCAw7AQEBAQEBAQECAQIBAQEBAoMwAgYBTIMcBIg7nzg X-IronPort-AV: E=Sophos;i="4.71,523,1320624000"; d="scan'208";a="25762954" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 17 Jan 2012 14:55:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0HEt0Pv027404; Tue, 17 Jan 2012 14:55:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id q0HEt0014873; Tue, 17 Jan 2012 06:55:00 -0800 (PST) Date: Tue, 17 Jan 2012 06:55:00 -0800 (PST) From: Message-Id: <201201171455.q0HEt0014873@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-mawatari-v6ops-464xlat@tools.ietf.org Subject: [v6ops] new draft: draft-mawatari-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 14:55:02 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-mawatari-v6ops-464xlat. Please take a look at it and comment. From shemant@cisco.com Tue Jan 17 10:43:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E4711E8089 for ; Tue, 17 Jan 2012 10:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.349 X-Spam-Level: X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pn+rl95dTcQ8 for ; Tue, 17 Jan 2012 10:43:18 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 48CB511E8073 for ; Tue, 17 Jan 2012 10:43:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=489; q=dns/txt; s=iport; t=1326825798; x=1328035398; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=px2Q7RvjCYCUMoCfesOOnVzM89c5IkpIR+3butgqJfY=; b=HnFIU4lQESWtnc1QuMPksSqbEagUeREpVIFe8gohrzMWf9ST5QakbEzW LAInMXsk9s7pie6VBL64XxgNTKJKPCxlQ4YdFDC4o+z1cDsizzXDQ0P7E Hgl+Aua7xJjs5slSejnFOnYq075t/ZshrZOh17PbsSD48lHfUeCRST22I Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGHAFU+tJXG8/2dsb2JhbABErECBBoEFgXIBAQEEEgEUCVUEAgEIEQQBAQsGFwEGAUUJCAEBBAESCBqgRQGePIkqMwIBAVUBBAcBCwECAQECAwECAQEBAQJJCkqBaFcXgktjBIgIM582 X-IronPort-AV: E=Sophos;i="4.71,524,1320624000"; d="scan'208";a="51811176" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 17 Jan 2012 18:43:17 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0HIhHkl020061; Tue, 17 Jan 2012 18:43:17 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Jan 2012 12:43:17 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Jan 2012 12:43:16 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303BEC4D6@XMB-RCD-109.cisco.com> In-Reply-To: <1326722373.49203.YahooMailNeo@web126005.mail.ne1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt Thread-Index: AczUVx4jxjhu/KjTQx+BEkZZYBbEHAA8J8gA References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com> <1326722373.49203.YahooMailNeo@web126005.mail.ne1.yahoo.com> From: "Hemant Singh (shemant)" To: =?iso-8859-1?Q?Fran=E7ois-Xavier_Le_Bail?= , X-OriginalArrivalTime: 17 Jan 2012 18:43:17.0707 (UTC) FILETIME=[E0C171B0:01CCD547] Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 18:43:19 -0000 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Fran=E7ois-Xavier Le Bail Sent: Monday, January 16, 2012 9:00 AM To: v6ops@ietf.org WG Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt >G-1: An IPv6 CE router is an IPv6 node according to the IPv6 Node = Requirements [RFC4294] specification.=20 >RFC 4294 -> RFC 6434 ? Thanks much for this catch. I made the change for the -06 version. Hemant From brian.e.carpenter@gmail.com Tue Jan 17 13:14:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4457D21F8567 for ; Tue, 17 Jan 2012 13:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.227 X-Spam-Level: X-Spam-Status: No, score=-103.227 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73KrvCK1xKqK for ; Tue, 17 Jan 2012 13:14:09 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAA621F853F for ; Tue, 17 Jan 2012 13:14:09 -0800 (PST) Received: by wgbdq11 with SMTP id dq11so1764444wgb.13 for ; Tue, 17 Jan 2012 13:14:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:content-type:content-transfer-encoding; bh=abeDXs0L03lXsZBLJNdJIrNrGV1XL85jJfvxCC4EFLg=; b=ZAdTlsLqOQHRKcasDaglUdLQWD71vCGixIOHKuZYpju1llWtrN1II2/If94y/lE0/+ 8r5BBb0Udq9mgZOZv31WcKnQQEIudYsKfGDeTyXCgKVDvuUxcQUNvDQP26Ei60GqxTmd Tmp/1bdVeojH1+5GG5T4IkS6UbZRctebdtNKY= Received: by 10.180.83.69 with SMTP id o5mr31788746wiy.1.1326834848766; Tue, 17 Jan 2012 13:14:08 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id d9sm19082447wiy.2.2012.01.17.13.14.04 (version=SSLv3 cipher=OTHER); Tue, 17 Jan 2012 13:14:08 -0800 (PST) Message-ID: <4F15E499.5040908@gmail.com> Date: Wed, 18 Jan 2012 10:14:01 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Willy Tarreau Subject: [v6ops] [Fwd: I-D Action: draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 21:14:10 -0000 This is a significant update since the version discussed in Taipei, with an additional author who is a practitioner in the field, and incorporating comments from implementors. Of course we would like more feedback. For the moment I suggest discussion on the v6ops list, although that may not be the final home for this draft. Please keep Willy on CC since I'm not sure he's on this list. Brian Carpenter -------- Original Message -------- Subject: I-D Action: draft-carpenter-v6ops-label-balance-01.txt Date: Tue, 17 Jan 2012 12:40:05 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using the IPv6 Flow Label for Server Load Balancing Author(s) : Brian Carpenter Sheng Jiang Willy Tarreau Filename : draft-carpenter-v6ops-label-balance-01.txt Pages : 12 Date : 2012-01-17 This document describes how the IPv6 flow label can be used in support of layer 3/4 load distribution and balancing for large server farms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-label-balance-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-label-balance-01.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From w@1wt.eu Tue Jan 17 13:44:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB6C11E80BC for ; Tue, 17 Jan 2012 13:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.044 X-Spam-Level: X-Spam-Status: No, score=-4.044 tagged_above=-999 required=5 tests=[AWL=-2.001, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWgi4rokrDIL for ; Tue, 17 Jan 2012 13:44:34 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id F376A11E80AF for ; Tue, 17 Jan 2012 13:44:33 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q0HLiWJ3020402; Tue, 17 Jan 2012 22:44:32 +0100 Date: Tue, 17 Jan 2012 22:44:32 +0100 From: Willy Tarreau To: Brian E Carpenter Message-ID: <20120117214432.GC20322@1wt.eu> References: <4F15E499.5040908@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F15E499.5040908@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action: draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 21:44:34 -0000 Hello Brian and WG members, On Wed, Jan 18, 2012 at 10:14:01AM +1300, Brian E Carpenter wrote: > Please keep Willy on CC since I'm not sure he's on this list. I've just subscribed now so that's OK. Thanks, Willy From fred@cisco.com Wed Jan 18 04:50:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC3021F8781 for ; Wed, 18 Jan 2012 04:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.082 X-Spam-Level: X-Spam-Status: No, score=-106.082 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FF4qQPdohDTc for ; Wed, 18 Jan 2012 04:50:55 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 67E4B21F8792 for ; Wed, 18 Jan 2012 04:50:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1131; q=dns/txt; s=iport; t=1326891055; x=1328100655; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=vVRy0zzCqBBNCD4dPYngFPjxndoQX5cMgMNBJLFl1Ck=; b=blrYlVi+Qp4T19dCgB+sjSLhUMttWeJdCLfbFiAX8tlnjXNwumf9xsSU +hrOxWdWFtjEdrJyuAj+FIEETF79fmNwRSDLe4ZKg0qNlsyh8HOHK1mj+ Sm1dM95bPxkulSl9PjgdQnB8dCpR+VTLNTAMUvbe9C5SSxeDtHdqnpjKA U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADO/Fk+rRDoH/2dsb2JhbABErEWBAYEFgXIBAQEDARIBZgULC0ZXBjWHWJoEAZ5viTYBCwkUCQICAQENBQQRBQEGAQEGAQUXFQECAQEFAwEBAQECBxAFDiYMRBAFC4FFOYMAYwSIO4xYhVWNEg X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="25964767" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 18 Jan 2012 12:50:54 +0000 Received: from stealth-10-32-244-220.cisco.com (stealth-10-32-244-220.cisco.com [10.32.244.220]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q0ICorNN012595; Wed, 18 Jan 2012 12:50:53 GMT Received: from [127.0.0.1] by stealth-10-32-244-220.cisco.com (PGP Universal service); Wed, 18 Jan 2012 04:50:53 -0800 X-PGP-Universal: processed; by stealth-10-32-244-220.cisco.com on Wed, 18 Jan 2012 04:50:53 -0800 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Wed, 18 Jan 2012 04:50:41 -0800 Message-Id: <826C4939-095F-47FD-8BF5-51915D07F734@cisco.com> References: To: "Li Lianyuan" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops WG Subject: Re: [v6ops] IPv6 Day in 2012 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 12:50:57 -0000 On Jan 17, 2012, at 11:15 PM, Li Lianyuan wrote: > Dear Fred, > This is Li Lianyuan in China Mobile speaking hello to you. We had = met before in IETF meeting several times. > I am told that on 6 June this year, IPv6 Day will be held again. = But I didn=92t find any discussion in v6ops emailing list. So could you = give me some information on it? > =20 > Thanks > =20 > Li Lianyuan I'll do both in the same email - tell you and tell the list. A set of usual suspects, led by the Internet Society, has announced a = follow-on to the "World IPv6 Day" that was held 8 June 2011. On that = one, the objective was to test connectivity and capabilities. The result = was that a number sites (about 800 by my measurements) tested WWW access = via IPv6, demonstrated basic capabilities, and then at least in many = cases shut it down again. In this event, starting 6 June 2012, the = objective is to globally turn on IPv6 and leave it on.=20 http://www.worldipv6launch.org/ Apologies to all of those networks that turned on IPv6 a decade or more = back and have been quietly operating it...= From w@1wt.eu Wed Jan 18 05:10:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02E521F87E8 for ; Wed, 18 Jan 2012 05:10:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=-3.387, BAYES_20=-0.74, HELO_IS_SMALL6=0.556, J_CHICKENPOX_13=0.6, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5DYWPFCDsM0 for ; Wed, 18 Jan 2012 05:10:07 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id D49EB21F87EE for ; Wed, 18 Jan 2012 05:10:04 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q0ID9rNG024236; Wed, 18 Jan 2012 14:09:53 +0100 Date: Wed, 18 Jan 2012 14:09:53 +0100 From: Willy Tarreau To: Fred Baker Message-ID: <20120118130953.GD23190@1wt.eu> References: <826C4939-095F-47FD-8BF5-51915D07F734@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <826C4939-095F-47FD-8BF5-51915D07F734@cisco.com> User-Agent: Mutt/1.4.2.3i Cc: v6ops v6ops WG , Li Lianyuan Subject: Re: [v6ops] IPv6 Day in 2012 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 13:10:31 -0000 Hi, On Wed, Jan 18, 2012 at 04:50:41AM -0800, Fred Baker wrote: > > On Jan 17, 2012, at 11:15 PM, Li Lianyuan wrote: > > > Dear Fred, > > This is Li Lianyuan in China Mobile speaking hello to you. We had met before in IETF meeting several times. > > I am told that on 6 June this year, IPv6 Day will be held again. But I didn?t find any discussion in v6ops emailing list. So could you give me some information on it? > > > > Thanks > > > > Li Lianyuan > > I'll do both in the same email - tell you and tell the list. > > A set of usual suspects, led by the Internet Society, has announced a > follow-on to the "World IPv6 Day" that was held 8 June 2011. On that one, the > objective was to test connectivity and capabilities. The result was that a > number sites (about 800 by my measurements) tested WWW access via IPv6, > demonstrated basic capabilities, and then at least in many cases shut it down > again. In this event, starting 6 June 2012, the objective is to globally turn > on IPv6 and leave it on. Is it known how many left it turned on after last year's event ? I personally know a small number of sites which successfully left it enabled (at least mine and my company's plus a few customers and enthousiasts). Regards, Willy From fred@cisco.com Wed Jan 18 08:35:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E3E21F87D1 for ; Wed, 18 Jan 2012 08:35:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.798 X-Spam-Level: X-Spam-Status: No, score=-105.798 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHwYp-Of9rmU for ; Wed, 18 Jan 2012 08:35:45 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAF921F87D0 for ; Wed, 18 Jan 2012 08:35:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3220; q=dns/txt; s=iport; t=1326904545; x=1328114145; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=EpOH/sOpEN841snQwXifGToXqQrLvPq1Z4cmcluY0Qc=; b=CCfYpI/OH1HOuPIuMqbuTVR11nHKPXSYs4eYaiPHQOXodOeCYOn2IkDv 1083TRpbyA9224+iYuQ/NAmdQy1G5t3qkHHs7IFKc+hp5uVKY2hOsOwan GYMe73fMeYPOABBVoAreUTBQUXr1ARuXvFqNSREo5nzJ4VZw3dduEFbg9 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABP0Fk+rRDoJ/2dsb2JhbABErEWBAoEFgXIBAQEDARIBJz8FCwsOCi5XBi0Ih1iaMAGeWIh9DgQCAgoBAQoFAQgHBAkFAQUJCQICAQENBQQRBQEGAQEGAQUXFQECAQEIAQEBAwcQBQ4mDEQQBQuBRYM5YwSIO4xYhVWNEg X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="26020418" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 18 Jan 2012 16:35:44 +0000 Received: from stealth-10-32-244-220.cisco.com (stealth-10-32-244-220.cisco.com [10.32.244.220]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0IGZiQc008695; Wed, 18 Jan 2012 16:35:44 GMT Received: from [127.0.0.1] by stealth-10-32-244-220.cisco.com (PGP Universal service); Wed, 18 Jan 2012 08:35:44 -0800 X-PGP-Universal: processed; by stealth-10-32-244-220.cisco.com on Wed, 18 Jan 2012 08:35:44 -0800 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <20120118130953.GD23190@1wt.eu> Date: Wed, 18 Jan 2012 08:35:31 -0800 Message-Id: References: <826C4939-095F-47FD-8BF5-51915D07F734@cisco.com> <20120118130953.GD23190@1wt.eu> To: Willy Tarreau X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops WG , Li Lianyuan Subject: Re: [v6ops] IPv6 Day in 2012 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 16:35:46 -0000 On Jan 18, 2012, at 5:09 AM, Willy Tarreau wrote: > Hi, >=20 > On Wed, Jan 18, 2012 at 04:50:41AM -0800, Fred Baker wrote: >>=20 >> On Jan 17, 2012, at 11:15 PM, Li Lianyuan wrote: >>=20 >>> Dear Fred, >>> This is Li Lianyuan in China Mobile speaking hello to you. We had = met before in IETF meeting several times. >>> I am told that on 6 June this year, IPv6 Day will be held again. = But I didn?t find any discussion in v6ops emailing list. So could you = give me some information on it? >>>=20 >>> Thanks >>>=20 >>> Li Lianyuan >>=20 >> I'll do both in the same email - tell you and tell the list. >>=20 >> A set of usual suspects, led by the Internet Society, has announced a >> follow-on to the "World IPv6 Day" that was held 8 June 2011. On that = one, the >> objective was to test connectivity and capabilities. The result was = that a >> number sites (about 800 by my measurements) tested WWW access via = IPv6, >> demonstrated basic capabilities, and then at least in many cases shut = it down >> again. In this event, starting 6 June 2012, the objective is to = globally turn >> on IPv6 and leave it on.=20 >=20 > Is it known how many left it turned on after last year's event ? I = personally > know a small number of sites which successfully left it enabled (at = least mine > and my company's plus a few customers and enthousiasts). I personally only have my measurements. During the week before, I was = curious to see what the ramp-up looked like. So I took the set of sites = that had stated that they would participate (about 300 IIRC) and slowly = (one page from each, and then one derivative page from each, etc) = spidered their sites, picking up links outside of them as well. I added = those sites to my spidering. Predictably, at the beginning of the week = there were few that were IPv6-accessible, and that number grew over the = week. I left the spider running through the weekend following and then = turned it off.=20 By my observation, the number of individual sites I was able to reach = last June peaked at a tad over 700, indicating that on average each = "participating" site led me to another site that was IPv6-capable but = not overtly participating. To my small mind, that was the real news - = that there were already a number of sites out there that were just doing = it. The drop afterwards was perhaps half - some put it up as an = experiment, and some simply put it (or had it) up. Another part of the story is http://sixy.ch/. Sixy.ch, in their own = words, "aims to be a directory of web sites that are accessible via = IPv6." I'm not certain what motivates sites to register with sixy.ch, = but as of this morning it reports 8657 sites in its database. I sat this = morning clicking on links from the site for a few minutes, which is = something the site really isn't set up to do (if I were Leslie Daigle, I = might be interested to contact the webmasters of those sites for various = reasons), but which is possible. It lists their IPv6 addresses, and when = I accessed the first couple of dozen listed, I can report that I was = able to access them using IPv6. > Regards, > Willy >=20 From dwing@cisco.com Thu Jan 19 18:26:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B53121F84B5 for ; Thu, 19 Jan 2012 18:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNOQ23QLSQzk for ; Thu, 19 Jan 2012 18:26:25 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id C74B021F849D for ; Thu, 19 Jan 2012 18:26:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=624; q=dns/txt; s=iport; t=1327026386; x=1328235986; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=6bsfGWg5qzCYWiGko+O/Ko13LOey5knynZCq6JhXtcg=; b=I4eZQFAIAjOtGrBrh9E4WvBojt+/Y4DLjc1wHDR3DHiir6uotilit2Dt I3F6quZiObA6gIaojY+FLOcIe1Rez9WZsC948CEZUgcD4eRo5kcO4SQTX wU0V+EiI0ZygEZblnI4YaMfrQxuQiRuFG5a+Jzmn1mnh2++kgKVbfZEvi c=; X-IronPort-AV: E=Sophos;i="4.71,539,1320624000"; d="scan'208";a="26117229" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 20 Jan 2012 02:26:25 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0K2QPrx005655; Fri, 20 Jan 2012 02:26:25 GMT From: "Dan Wing" To: "'Willy Tarreau'" References: <826C4939-095F-47FD-8BF5-51915D07F734@cisco.com> <20120118130953.GD23190@1wt.eu> In-Reply-To: <20120118130953.GD23190@1wt.eu> Date: Thu, 19 Jan 2012 18:26:25 -0800 Message-ID: <086001ccd71a$e87eb000$b97c1000$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczV4pSjoq/sVtsVT/WZwmrciSaFqABN72yQ Content-Language: en-us Cc: 'v6ops v6ops WG' , 'Li Lianyuan' Subject: Re: [v6ops] IPv6 Day in 2012 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 02:26:26 -0000 > Is it known how many left it turned on after last year's event ? I > personally > know a small number of sites which successfully left it enabled (at > least mine > and my company's plus a few customers and enthousiasts). See https://labs.ripe.net/Members/emileaben/copy_of_alexadetail.png/view Among all the other data available from real researchers, I maintain http://www.employees.org/~dwing/aaaa-stats.html which gives breakdown on actual site names that come and go, and do GET over IPv6 TCP/80 (instead of blindly assuming an AAAA means that IPv6 works). I don't have pretty graphs, though. -d From w@1wt.eu Thu Jan 19 23:09:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E856221F85A1 for ; Thu, 19 Jan 2012 23:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.968 X-Spam-Level: X-Spam-Status: No, score=-3.968 tagged_above=-999 required=5 tests=[AWL=-1.925, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POLRMHzPS9GI for ; Thu, 19 Jan 2012 23:09:03 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD9621F8596 for ; Thu, 19 Jan 2012 23:09:01 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q0K78omu003270; Fri, 20 Jan 2012 08:08:50 +0100 Date: Fri, 20 Jan 2012 08:08:50 +0100 From: Willy Tarreau To: Dan Wing Message-ID: <20120120070850.GB3231@1wt.eu> References: <826C4939-095F-47FD-8BF5-51915D07F734@cisco.com> <20120118130953.GD23190@1wt.eu> <086001ccd71a$e87eb000$b97c1000$@com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <086001ccd71a$e87eb000$b97c1000$@com> User-Agent: Mutt/1.4.2.3i Cc: 'v6ops v6ops WG' , 'Li Lianyuan' Subject: Re: [v6ops] IPv6 Day in 2012 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 07:09:04 -0000 On Thu, Jan 19, 2012 at 06:26:25PM -0800, Dan Wing wrote: > > Is it known how many left it turned on after last year's event ? I > > personally > > know a small number of sites which successfully left it enabled (at > > least mine > > and my company's plus a few customers and enthousiasts). > > See > https://labs.ripe.net/Members/emileaben/copy_of_alexadetail.png/view > > Among all the other data available from real researchers, > I maintain http://www.employees.org/~dwing/aaaa-stats.html which > gives breakdown on actual site names that come and go, and do GET > over IPv6 TCP/80 (instead of blindly assuming an AAAA means that > IPv6 works). I don't have pretty graphs, though. Nice, both your experiments and the graph above show what I suspected, ie that the ipv6 day encouraged a large number of sites to leave v6 turned on after the experiment. From your stats, it appears that the number of v6-capable sites today is 4 times what we had at the same date one year ago, and doubled thanks to the v6-day. We could reasonably think that after next v6-day, the number of enabled sites could roughly match the number of participants to previous v6-day, which would already be a nice progression. Thanks for sharing these stats, Willy From joelja@bogus.com Sat Jan 21 15:44:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2621521F848B for ; Sat, 21 Jan 2012 15:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MoZ5bE-JvCj for ; Sat, 21 Jan 2012 15:44:42 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id EBF0021F8487 for ; Sat, 21 Jan 2012 15:44:41 -0800 (PST) Received: from Joels-MacBook-Pro.local (243.sub-166-250-44.myvzw.com [166.250.44.243]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q0LNiX3T073907 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 21 Jan 2012 23:44:34 GMT (envelope-from joelja@bogus.com) Message-ID: <4F1B4DDB.6040009@bogus.com> Date: Sat, 21 Jan 2012 15:44:27 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Fred Baker References: <9F17268C-B161-46B4-963B-FA449727DE96@cisco.com> In-Reply-To: <9F17268C-B161-46B4-963B-FA449727DE96@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 21 Jan 2012 23:44:36 +0000 (UTC) Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-v6nd-problems WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 23:44:43 -0000 we've had comments from wes george and and extensive review from ray hunter which will be incorpoortated into a new draft. So far that's it for WGLC feedback. While that's useful it's not a strong demonstration of support for publication as a WG document. the WGLC timer is offcially up on the 22nd. joel On 1/16/12 07:48 , Fred Baker wrote: > The working group last call for this draft announced last week continues > for another week. Please feel free to comment on it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From mark@townsley.net Mon Jan 23 16:09:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD3621F8670 for ; Mon, 23 Jan 2012 16:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.069 X-Spam-Level: X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RB-ROoojhYbJ for ; Mon, 23 Jan 2012 16:09:09 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id A239521F8669 for ; Mon, 23 Jan 2012 16:09:09 -0800 (PST) Received: by wgbed3 with SMTP id ed3so2648194wgb.13 for ; Mon, 23 Jan 2012 16:09:08 -0800 (PST) Received: by 10.180.73.72 with SMTP id j8mr17049413wiv.2.1327363748785; Mon, 23 Jan 2012 16:09:08 -0800 (PST) Received: from ams-townsley-8715.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id fr8sm37117241wib.10.2012.01.23.16.09.06 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Jan 2012 16:09:07 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) From: Mark Townsley In-Reply-To: <826C4939-095F-47FD-8BF5-51915D07F734@cisco.com> Date: Tue, 24 Jan 2012 01:09:05 +0100 Message-Id: <55D479B9-EC45-43E9-BD74-CC0ABEDCF002@townsley.net> References: <826C4939-095F-47FD-8BF5-51915D07F734@cisco.com> To: v6ops v6ops WG X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmEgaRt2dgyigDDk8Ej647QpwO0YP35Yz74xZ0kTNhXyObGJlUbI1Wo5XikGicrxZixYfiR Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] IPv6 Day in 2012 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 00:09:12 -0000 On Jan 18, 2012, at 1:50 PM, Fred Baker wrote: >=20 > On Jan 17, 2012, at 11:15 PM, Li Lianyuan wrote: >=20 >> Dear Fred, >> This is Li Lianyuan in China Mobile speaking hello to you. We had = met before in IETF meeting several times. >> I am told that on 6 June this year, IPv6 Day will be held again. = But I didn=92t find any discussion in v6ops emailing list. So could you = give me some information on it? >>=20 >> Thanks >>=20 >> Li Lianyuan >=20 > I'll do both in the same email - tell you and tell the list. >=20 > A set of usual suspects, led by the Internet Society, has announced a = follow-on to the "World IPv6 Day" that was held 8 June 2011. On that = one, the objective was to test connectivity and capabilities. The result = was that a number sites (about 800 by my measurements) tested WWW access = via IPv6, demonstrated basic capabilities, and then at least in many = cases shut it down again. In this event, starting 6 June 2012, the = objective is to globally turn on IPv6 and leave it on.=20 In addition, there are participation categories for ISPs (with = measurements taken by participating websites) and Residential Home = Gateway products (with a commitment to pass a latest version of the CPE = v6 ready logo test as well as v6 enabled by default). The point is for = IPv6 to become "the normal course of business" rather than opt-in.=20 - Mark >=20 > http://www.worldipv6launch.org/ >=20 > Apologies to all of those networks that turned on IPv6 a decade or = more back and have been quietly operating it... > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From mark@townsley.net Mon Jan 23 16:11:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5098321F8670 for ; Mon, 23 Jan 2012 16:11:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4QMk1B61D+z for ; Mon, 23 Jan 2012 16:11:28 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 01A7721F8667 for ; Mon, 23 Jan 2012 16:11:27 -0800 (PST) Received: by wibhn9 with SMTP id hn9so3310380wib.31 for ; Mon, 23 Jan 2012 16:11:27 -0800 (PST) Received: by 10.180.84.201 with SMTP id b9mr11800601wiz.4.1327363886972; Mon, 23 Jan 2012 16:11:26 -0800 (PST) Received: from ams-townsley-8715.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id cb8sm11435907wib.0.2012.01.23.16.11.24 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Jan 2012 16:11:26 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) From: Mark Townsley In-Reply-To: Date: Tue, 24 Jan 2012 01:11:22 +0100 Message-Id: <8057C18A-4857-42A9-91F8-AFA0ADE4D3CC@townsley.net> References: <826C4939-095F-47FD-8BF5-51915D07F734@cisco.com> <20120118130953.GD23190@1wt.eu> To: Fred Baker X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkRxSxtb/ZE/2VdIcDtOcMfRXzSCspJWOmWFHjPN7J6ppIzJBbh2cGvpaGDDDNOi6IfJN1f Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops WG , Willy Tarreau , Li Lianyuan Subject: Re: [v6ops] IPv6 Day in 2012 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 00:11:29 -0000 Strato, a hosting company in Germany, reportedly enabled IPv6 on world = day last year to all four million sites that it hosts, and did not turn = it off after. youtube kept AAAAs for its video streaming, which accounts for a big = chunk of traffic that "stuck around" after world day.=20 - Mark On Jan 18, 2012, at 5:35 PM, Fred Baker wrote: >=20 > On Jan 18, 2012, at 5:09 AM, Willy Tarreau wrote: >=20 >> Hi, >>=20 >> On Wed, Jan 18, 2012 at 04:50:41AM -0800, Fred Baker wrote: >>>=20 >>> On Jan 17, 2012, at 11:15 PM, Li Lianyuan wrote: >>>=20 >>>> Dear Fred, >>>> This is Li Lianyuan in China Mobile speaking hello to you. We had = met before in IETF meeting several times. >>>> I am told that on 6 June this year, IPv6 Day will be held again. = But I didn?t find any discussion in v6ops emailing list. So could you = give me some information on it? >>>>=20 >>>> Thanks >>>>=20 >>>> Li Lianyuan >>>=20 >>> I'll do both in the same email - tell you and tell the list. >>>=20 >>> A set of usual suspects, led by the Internet Society, has announced = a >>> follow-on to the "World IPv6 Day" that was held 8 June 2011. On that = one, the >>> objective was to test connectivity and capabilities. The result was = that a >>> number sites (about 800 by my measurements) tested WWW access via = IPv6, >>> demonstrated basic capabilities, and then at least in many cases = shut it down >>> again. In this event, starting 6 June 2012, the objective is to = globally turn >>> on IPv6 and leave it on.=20 >>=20 >> Is it known how many left it turned on after last year's event ? I = personally >> know a small number of sites which successfully left it enabled (at = least mine >> and my company's plus a few customers and enthousiasts). >=20 > I personally only have my measurements. During the week before, I was = curious to see what the ramp-up looked like. So I took the set of sites = that had stated that they would participate (about 300 IIRC) and slowly = (one page from each, and then one derivative page from each, etc) = spidered their sites, picking up links outside of them as well. I added = those sites to my spidering. Predictably, at the beginning of the week = there were few that were IPv6-accessible, and that number grew over the = week. I left the spider running through the weekend following and then = turned it off.=20 >=20 > By my observation, the number of individual sites I was able to reach = last June peaked at a tad over 700, indicating that on average each = "participating" site led me to another site that was IPv6-capable but = not overtly participating. To my small mind, that was the real news - = that there were already a number of sites out there that were just doing = it. The drop afterwards was perhaps half - some put it up as an = experiment, and some simply put it (or had it) up. >=20 > Another part of the story is http://sixy.ch/. Sixy.ch, in their own = words, "aims to be a directory of web sites that are accessible via = IPv6." I'm not certain what motivates sites to register with sixy.ch, = but as of this morning it reports 8657 sites in its database. I sat this = morning clicking on links from the site for a few minutes, which is = something the site really isn't set up to do (if I were Leslie Daigle, I = might be interested to contact the webmasters of those sites for various = reasons), but which is possible. It lists their IPv6 addresses, and when = I accessed the first couple of dozen listed, I can report that I was = able to access them using IPv6. >=20 >> Regards, >> Willy >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Mon Jan 23 17:44:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FF921F8650 for ; Mon, 23 Jan 2012 17:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.506 X-Spam-Level: X-Spam-Status: No, score=-103.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jsF6Z2XG9tn for ; Mon, 23 Jan 2012 17:44:06 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 184F921F85E6 for ; Mon, 23 Jan 2012 17:44:06 -0800 (PST) Received: by ggnq4 with SMTP id q4so1245774ggn.31 for ; Mon, 23 Jan 2012 17:44:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=g871uB/a/KLE/x3afrvvERkj9O9t2qWDqxo0ZXZxGsk=; b=BgbUY/M+6AkJ2g+FjESlSFdTm3eeACoX7CCjzJhs065qO/bwSA2FYcuGFNVFtlziPI 6wIItt7rEhDfEFI2tGLeiWkMNejWG2+8yDL3XGJlP7wb3AA2w6MjVPwBRRyKQBFz1x9F RakqmxIEBDhNVBSBjp5SG4Nk8rHh2aAm+YNRs= Received: by 10.236.80.4 with SMTP id j4mr10378892yhe.120.1327369445769; Mon, 23 Jan 2012 17:44:05 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id i12sm40254707anm.6.2012.01.23.17.44.03 (version=SSLv3 cipher=OTHER); Mon, 23 Jan 2012 17:44:04 -0800 (PST) Message-ID: <4F1E0CEB.2060007@gmail.com> Date: Tue, 24 Jan 2012 14:44:11 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations References: <20120115151150.14422.12309.idtracker@ietfa.amsl.com> In-Reply-To: <20120115151150.14422.12309.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] I-D Action: draft-mawatari-v6ops-464xlat-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 01:44:06 -0000 > 7.4. DNS Proxy Implementation > > If a router implement CLAT function, it performs DNS Proxy for IPv4 > hosts and IPv6 hosts in end-user network. Why is this necessary? As far as I can see, the client could use any normal DNS server, because the A and AAAA records it needs are completely standard. Regards Brian Carpenter From cb.list6@gmail.com Mon Jan 23 19:16:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334AE21F85F8 for ; Mon, 23 Jan 2012 19:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.168 X-Spam-Level: X-Spam-Status: No, score=-3.168 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YELIQvBKwfOh for ; Mon, 23 Jan 2012 19:16:29 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id AF67D21F85ED for ; Mon, 23 Jan 2012 19:16:29 -0800 (PST) Received: by dadq14 with SMTP id q14so318899dad.31 for ; Mon, 23 Jan 2012 19:16:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gA0MFPO9+gZBQx4HzoMTs5kHUXa1URAlYfwINtu9LnI=; b=MLlDZ3gRrwOJCiDywnupMwyTcBWxD6O4VYouRWEr2yo7jEzZwp3ZTLhUrmvasuAs5R bNb+MYcon7xaHwJ7+XveTUzyUYte/Igq1UAxEOcziusWC59pHRMPraAPgcYxDoycYTMh /ifih4sb2rI2VauXIdz6j6hKelNeZ+casnV2o= MIME-Version: 1.0 Received: by 10.68.229.2 with SMTP id sm2mr26862706pbc.98.1327374988111; Mon, 23 Jan 2012 19:16:28 -0800 (PST) Received: by 10.142.161.6 with HTTP; Mon, 23 Jan 2012 19:16:28 -0800 (PST) Received: by 10.142.161.6 with HTTP; Mon, 23 Jan 2012 19:16:28 -0800 (PST) In-Reply-To: <4F1B4DDB.6040009@bogus.com> References: <9F17268C-B161-46B4-963B-FA449727DE96@cisco.com> <4F1B4DDB.6040009@bogus.com> Date: Mon, 23 Jan 2012 19:16:28 -0800 Message-ID: From: Cameron Byrne To: Joel jaeggli Content-Type: multipart/alternative; boundary=047d7b162fd7a66db004b73d924f Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-v6nd-problems WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 03:16:30 -0000 --047d7b162fd7a66db004b73d924f Content-Type: text/plain; charset=ISO-8859-1 On Jan 21, 2012 3:44 PM, "Joel jaeggli" wrote: > > we've had comments from wes george and and extensive review from ray > hunter which will be incorpoortated into a new draft. So far that's it > for WGLC feedback. > > While that's useful it's not a strong demonstration of support for > publication as a WG document. > > the WGLC timer is offcially up on the 22nd. > Sorry for being a day late. I support this draft as being useful to ipv6 network operators and network vendors. Cb > joel > > On 1/16/12 07:48 , Fred Baker wrote: > > The working group last call for this draft announced last week continues > > for another week. Please feel free to comment on it. > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --047d7b162fd7a66db004b73d924f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jan 21, 2012 3:44 PM, "Joel jaeggli" <joelja@bogus.com> wrote:
>
> we've had comments from wes george and =A0and extensive review fro= m ray
> hunter which will be incorpoortated into a new draft. So far that'= s it
> for WGLC feedback.
>
> While that's useful it's not a strong demonstration of support= for
> publication as a WG document.
>
> the WGLC timer is offcially up on the 22nd.
>

Sorry for being a day late.=A0 I support this draft as being useful to i= pv6 network operators and network=A0 vendors.

Cb
> joel
>
> On 1/16/12 07:48 , Fred Baker wrote:
> > The working group last call for this draft announced last week co= ntinues
> > for another week. Please feel free to comment on it.
> >
> >
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://w= ww.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--047d7b162fd7a66db004b73d924f-- From warren@kumari.net Mon Jan 23 19:23:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C71E121F84A1 for ; Mon, 23 Jan 2012 19:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.208 X-Spam-Level: X-Spam-Status: No, score=-106.208 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+Qb05k5LXCG for ; Mon, 23 Jan 2012 19:23:34 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 4718B21F848F for ; Mon, 23 Jan 2012 19:23:33 -0800 (PST) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 0682C1B40680; Mon, 23 Jan 2012 22:23:32 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: Date: Mon, 23 Jan 2012 22:23:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9F17268C-B161-46B4-963B-FA449727DE96@cisco.com> <4F1B4DDB.6040009@bogus.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-v6nd-problems WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 03:23:34 -0000 On Jan 23, 2012, at 10:16 PM, Cameron Byrne wrote: >=20 > On Jan 21, 2012 3:44 PM, "Joel jaeggli" wrote: > > > > we've had comments from wes george and and extensive review from = ray > > hunter which will be incorpoortated into a new draft. So far that's = it > > for WGLC feedback. > > > > While that's useful it's not a strong demonstration of support for > > publication as a WG document. > > > > the WGLC timer is offcially up on the 22nd. > > >=20 > Sorry for being a day late. I support this draft as being useful to = ipv6 network operators and network vendors. Whoo thanks=85. Even though the WGLC has officially closed, input like this is still = useful so that the chairs can determine if there is still interest, if = they should restart WGLC, call consensus, or what=85 It is also *really* helpful to the authors -- we wrote this because we = figured folk might like it and it might be useful -- even if the doc = never progresses it is nice to know that folk like it... W >=20 > Cb > > joel > > > > On 1/16/12 07:48 , Fred Baker wrote: > > > The working group last call for this draft announced last week = continues > > > for another week. Please feel free to comment on it. > > > > > > > > > > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman. From john_brzozowski@cable.comcast.com Mon Jan 23 20:10:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5767611E8071 for ; Mon, 23 Jan 2012 20:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.297 X-Spam-Level: X-Spam-Status: No, score=-100.297 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rFpaK+YvXZ8 for ; Mon, 23 Jan 2012 20:10:36 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id BD6B421F85D2 for ; Mon, 23 Jan 2012 20:10:04 -0800 (PST) Received: from ([24.40.56.115]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.2730470; Mon, 23 Jan 2012 23:06:22 -0500 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%17]) with mapi id 14.01.0355.002; Mon, 23 Jan 2012 23:09:52 -0500 From: "Brzozowski, John" To: Warren Kumari , Cameron Byrne Thread-Topic: [v6ops] Reminder: draft-ietf-v6ops-v6nd-problems WGLC Thread-Index: AQHM2kaWDOIM3pfV7kCB48hpMCQ82ZYbLl0A//+5FYA= Date: Tue, 24 Jan 2012 04:09:51 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.25.249.108] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8E9DE7916EF6A24DAFEDC60749AE6539@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" , Ron Bonica Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-v6nd-problems WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 04:10:37 -0000 Warren, I of course am board and support this as well even though I am sending this email after WGLC has concluded. John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 1/23/12 10:23 PM, "Warren Kumari" wrote: > >On Jan 23, 2012, at 10:16 PM, Cameron Byrne wrote: > >>=20 >> On Jan 21, 2012 3:44 PM, "Joel jaeggli" wrote: >> > >> > we've had comments from wes george and and extensive review from ray >> > hunter which will be incorpoortated into a new draft. So far that's it >> > for WGLC feedback. >> > >> > While that's useful it's not a strong demonstration of support for >> > publication as a WG document. >> > >> > the WGLC timer is offcially up on the 22nd. >> > >>=20 >> Sorry for being a day late. I support this draft as being useful to >>ipv6 network operators and network vendors. > >Whoo thanks=8A. > >Even though the WGLC has officially closed, input like this is still >useful so that the chairs can determine if there is still interest, if >they should restart WGLC, call consensus, or what=8A > >It is also *really* helpful to the authors -- we wrote this because we >figured folk might like it and it might be useful -- even if the doc >never progresses it is nice to know that folk like it... > > > >W > >>=20 >> Cb >> > joel >> > >> > On 1/16/12 07:48 , Fred Baker wrote: >> > > The working group last call for this draft announced last week >>continues >> > > for another week. Please feel free to comment on it. >> > > >> > > >> > > >> > > _______________________________________________ >> > > v6ops mailing list >> > > v6ops@ietf.org >> > > https://www.ietf.org/mailman/listinfo/v6ops >> > >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > >-- >Don't be impressed with unintelligible stuff said condescendingly. > -- Radia Perlman. > > > > > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From jared@puck.nether.net Mon Jan 23 20:33:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E945D21F85EF for ; Mon, 23 Jan 2012 20:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.903 X-Spam-Level: X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJC7prJKWNbo for ; Mon, 23 Jan 2012 20:33:55 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 336BD21F85ED for ; Mon, 23 Jan 2012 20:33:55 -0800 (PST) Received: from [10.1.192.17] (mobile-198-228-220-232.mycingular.net [198.228.220.232]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q0O4WpdE018934 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Jan 2012 23:32:53 -0500 References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=utf-8 Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (9B5141a) From: Jared Mauch Date: Mon, 23 Jan 2012 21:33:43 -0700 To: "Brzozowski, John" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Mon, 23 Jan 2012 23:32:55 -0500 (EST) Cc: "v6ops-chairs@tools.ietf.org" , "v6ops@ietf.org" , Ron Bonica Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-v6nd-problems WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 04:33:56 -0000 Also here. Sorry thought I had communicated support in the past.=20 Jared Mauch On Jan 23, 2012, at 9:09 PM, "Brzozowski, John" wrote: > Warren, >=20 > I of course am board and support this as well even though I am sending > this email after WGLC has concluded. >=20 > John > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > John Jason Brzozowski > Comcast Cable > e) mailto:john_brzozowski@cable.comcast.com > o) 609-377-6594 > m) 484-962-0060 > w) http://www.comcast6.net > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >=20 >=20 > On 1/23/12 10:23 PM, "Warren Kumari" wrote: >=20 >>=20 >> On Jan 23, 2012, at 10:16 PM, Cameron Byrne wrote: >>=20 >>>=20 >>> On Jan 21, 2012 3:44 PM, "Joel jaeggli" wrote: >>>>=20 >>>> we've had comments from wes george and and extensive review from ray >>>> hunter which will be incorpoortated into a new draft. So far that's it >>>> for WGLC feedback. >>>>=20 >>>> While that's useful it's not a strong demonstration of support for >>>> publication as a WG document. >>>>=20 >>>> the WGLC timer is offcially up on the 22nd. >>>>=20 >>>=20 >>> Sorry for being a day late. I support this draft as being useful to >>> ipv6 network operators and network vendors. >>=20 >> Whoo thanks=C5=A0. >>=20 >> Even though the WGLC has officially closed, input like this is still >> useful so that the chairs can determine if there is still interest, if >> they should restart WGLC, call consensus, or what=C5=A0 >>=20 >> It is also *really* helpful to the authors -- we wrote this because we >> figured folk might like it and it might be useful -- even if the doc >> never progresses it is nice to know that folk like it... >>=20 >>=20 >>=20 >> W >>=20 >>>=20 >>> Cb >>>> joel >>>>=20 >>>> On 1/16/12 07:48 , Fred Baker wrote: >>>>> The working group last call for this draft announced last week >>> continues >>>>> for another week. Please feel free to comment on it. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> v6ops mailing list >>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>=20 >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >> -- >> Don't be impressed with unintelligible stuff said condescendingly. >> -- Radia Perlman. >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From kawashimam@vx.jp.nec.com Tue Jan 24 09:23:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1313911E807A for ; Tue, 24 Jan 2012 09:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XW+kRDIyfAGz for ; Tue, 24 Jan 2012 09:23:07 -0800 (PST) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by ietfa.amsl.com (Postfix) with ESMTP id C40DC11E8075 for ; Tue, 24 Jan 2012 09:22:39 -0800 (PST) Received: from mailgate3.nec.co.jp ([10.7.69.193]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id q0OHMbmb014422; Wed, 25 Jan 2012 02:22:37 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id q0OHMbP08385; Wed, 25 Jan 2012 02:22:37 +0900 (JST) Received: from mail03.kamome.nec.co.jp (mail03.kamome.nec.co.jp [10.25.43.7]) by mailsv3.nec.co.jp (8.13.8/8.13.4) with ESMTP id q0OHMbvj026304; Wed, 25 Jan 2012 02:22:37 +0900 (JST) Received: from shoin.jp.nec.com ([10.26.220.3] [10.26.220.3]) by mail02.kamome.nec.co.jp with ESMTP id BT-MMP-528071; Wed, 25 Jan 2012 02:21:24 +0900 Received: from siznecatg159185 ([10.3.159.185] [10.3.159.185]) by mail.jp.nec.com with ESMTP; Wed, 25 Jan 2012 02:21:22 +0900 To: Brian E Carpenter In-reply-to: <4F1E0CEB.2060007@gmail.com> References: <4F1E0CEB.2060007@gmail.com> Message-Id: <20120125022122kawashimam@mail.jp.nec.com> Mime-Version: 1.0 X-Mailer: StarOffice21/MailClient[4.65 Step9] From: Masanobu Kawashima Date: Wed, 25 Jan 2012 02:21:20 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-mawatari-v6ops-464xlat-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 17:23:08 -0000 Hi Brian, Thank you for your comment. I take your point. However, a CLAT can only learn the address of an IPv6 DNS recursive server through DHCPv6 (or other way). The CLAT can not easily discover the address of an IPv4 DNS recursive server, and it has to perform all DNS resolution over IPv6. The CLAT can pass this IPv6 address to downstream IPv6 hosts, but not to downstream IPv4 hosts. As such, the CLAT should implement a DNS proxy. Regards, Masanobu >> 7.4. DNS Proxy Implementation >> >> If a router implement CLAT function, it performs DNS Proxy for IPv4 >> hosts and IPv6 hosts in end-user network. > >Why is this necessary? As far as I can see, the client could use any >normal DNS server, because the A and AAAA records it needs are completely >standard. > >Regards > Brian Carpenter > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops ======================================== NEC AccessTechnica, Ltd. Product Development Department Masanobu Kawashima kawashimam@vx.jp.nec.com http://www.necat.co.jp/ ======================================== From brian.e.carpenter@gmail.com Tue Jan 24 12:21:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB82D21F84DA for ; Tue, 24 Jan 2012 12:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.15 X-Spam-Level: X-Spam-Status: No, score=-103.15 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id didn541meLdR for ; Tue, 24 Jan 2012 12:21:10 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF0A21F84D7 for ; Tue, 24 Jan 2012 12:21:09 -0800 (PST) Received: by ggnq4 with SMTP id q4so1813446ggn.31 for ; Tue, 24 Jan 2012 12:21:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HwRy2dVDTwtO34IJXhsa14hQMFttQb+Q+JlpfPStOXs=; b=nTvs3VVoSR/a2WIo03ZuDhzFul8r8MPus+4m+JJJ1XQ13H7duDPs3htWNi89ds9vCL kSYdP6Hi8Nk1d6oZMhOg/H/zN2vEZowsXD/t8Ta3nbcNzBfP3TUqcasq5/UstCuAdm8g KQ1ZLGE/+qbkOs/raXkp9C21SFqZXy3obnmcE= Received: by 10.50.42.167 with SMTP id p7mr16101611igl.20.1327436469071; Tue, 24 Jan 2012 12:21:09 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id r18sm61782464ibh.4.2012.01.24.12.21.06 (version=SSLv3 cipher=OTHER); Tue, 24 Jan 2012 12:21:08 -0800 (PST) Message-ID: <4F1F12B3.4000905@gmail.com> Date: Wed, 25 Jan 2012 09:21:07 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Masanobu Kawashima References: <4F1E0CEB.2060007@gmail.com> <20120125022122kawashimam@mail.jp.nec.com> In-Reply-To: <20120125022122kawashimam@mail.jp.nec.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-mawatari-v6ops-464xlat-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 20:21:11 -0000 On 2012-01-25 06:21, Masanobu Kawashima wrote: > Hi Brian, > > Thank you for your comment. > > I take your point. However, a CLAT can only learn the address of an IPv6 > DNS recursive server through DHCPv6 (or other way). The CLAT can not easily > discover the address of an IPv4 DNS recursive server, and it has to perform > all DNS resolution over IPv6. > > The CLAT can pass this IPv6 address to downstream IPv6 hosts, but not to > downstream IPv4 hosts. As such, the CLAT should implement a DNS proxy. But it should also be transparent to DNS queries over v4 or v6, if the client acquires a DNS server address by other means. Thanks Brian > > Regards, > Masanobu > > >>> 7.4. DNS Proxy Implementation >>> >>> If a router implement CLAT function, it performs DNS Proxy for IPv4 >>> hosts and IPv6 hosts in end-user network. >> Why is this necessary? As far as I can see, the client could use any >> normal DNS server, because the A and AAAA records it needs are completely >> standard. >> >> Regards >> Brian Carpenter >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > ======================================== > NEC AccessTechnica, Ltd. > Product Development Department > Masanobu Kawashima > kawashimam@vx.jp.nec.com > http://www.necat.co.jp/ > ======================================== > > From kawashimam@vx.jp.nec.com Tue Jan 24 16:38:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D9021F8566 for ; Tue, 24 Jan 2012 16:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.21 X-Spam-Level: X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecvEXLt-Y8G5 for ; Tue, 24 Jan 2012 16:38:11 -0800 (PST) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by ietfa.amsl.com (Postfix) with ESMTP id CF6E121F856D for ; Tue, 24 Jan 2012 16:38:10 -0800 (PST) Received: from mailgate3.nec.co.jp ([10.7.69.195]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id q0P0c7ps024954; Wed, 25 Jan 2012 09:38:07 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id q0P0c5t09924; Wed, 25 Jan 2012 09:38:05 +0900 (JST) Received: from mail01b.kamome.nec.co.jp (mail01b.kamome.nec.co.jp [10.25.43.2]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id q0P0c4r3014708; Wed, 25 Jan 2012 09:38:05 +0900 (JST) Received: from shikibu.jp.nec.com ([10.26.220.2] [10.26.220.2]) by mail02.kamome.nec.co.jp with ESMTP id BT-MMP-530051; Wed, 25 Jan 2012 09:36:43 +0900 Received: from siznecatg159185 ([10.3.159.185] [10.3.159.185]) by mail.jp.nec.com with ESMTP; Wed, 25 Jan 2012 09:36:43 +0900 To: Brian E Carpenter In-reply-to: <4F1F12B3.4000905@gmail.com> Message-Id: <20120125093643kawashimam@mail.jp.nec.com> References: <4F1F12B3.4000905@gmail.com> Mime-Version: 1.0 X-Mailer: StarOffice21/MailClient[4.65 Step9] From: Masanobu Kawashima Date: Wed, 25 Jan 2012 09:36:42 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-mawatari-v6ops-464xlat-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 00:38:11 -0000 Hi Brian, I agree with you completely. The CLAT should be a DNS proxy to support IPv4 and IPv6 clients of the CLAT and ensure that IPv6 end to end is preserved between the CLAT and the IPv6 DNS sever. The 464XLAT should also allow for the less optimal IPv4 DNS queries from clients, which would require 464XLAT translation between the IPv4 hosts and the IPv4 DNS servers. IPv6 enabled host may also directly query an IPv6 DNS server. We will add some clarifying language about this in the next revision. Thank you for your helpful comments. Regards, Masanobu >On 2012-01-25 06:21, Masanobu Kawashima wrote: >> Hi Brian, >> >> Thank you for your comment. >> >> I take your point. However, a CLAT can only learn the address of an IPv6 >> DNS recursive server through DHCPv6 (or other way). The CLAT can not easily >> discover the address of an IPv4 DNS recursive server, and it has to perform >> all DNS resolution over IPv6. >> >> The CLAT can pass this IPv6 address to downstream IPv6 hosts, but not to >> downstream IPv4 hosts. As such, the CLAT should implement a DNS proxy. > >But it should also be transparent to DNS queries over v4 or v6, if the >client acquires a DNS server address by other means. > >Thanks > Brian > >> >> Regards, >> Masanobu >> >> >>>> 7.4. DNS Proxy Implementation >>>> >>>> If a router implement CLAT function, it performs DNS Proxy for IPv4 >>>> hosts and IPv6 hosts in end-user network. >>> Why is this necessary? As far as I can see, the client could use any >>> normal DNS server, because the A and AAAA records it needs are completely >>> standard. >>> >>> Regards >>> Brian Carpenter >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> >> ======================================== >> NEC AccessTechnica, Ltd. >> Product Development Department >> Masanobu Kawashima >> kawashimam@vx.jp.nec.com >> http://www.necat.co.jp/ >> ======================================== >> >> ======================================== NEC AccessTechnica, Ltd. Product Development Department Masanobu Kawashima kawashimam@vx.jp.nec.com http://www.necat.co.jp/ ======================================== From victor.kuarsingh@gmail.com Wed Jan 25 07:10:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFDDD21F8683 for ; Wed, 25 Jan 2012 07:10:35 -0800 (PST) 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=[AWL=-0.998, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1OgDaavddHV for ; Wed, 25 Jan 2012 07:10:35 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC8E21F864D for ; Wed, 25 Jan 2012 07:10:34 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so3958713vcb.31 for ; Wed, 25 Jan 2012 07:10:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=S2Xos8BDLWMJO4Rt7HR6LpAdQ8b/LyOLw7qQ3TG2wRE=; b=keofsw/1+/9CjJmaXnPcGZCcGnU6eKGp58s1XLjkp/50IfaERsg11Dg0sOSc22VNou l8v0grr81cCab6hSUjDsYfT6vv85ehPXFY1gvtdaX5Ipgx15ews958cCXm/WswvC4HE7 4M7RIkIDRK94IqucKnSQOjLKerKA7cWH3U8m8= Received: by 10.52.90.171 with SMTP id bx11mr9524241vdb.26.1327504234017; Wed, 25 Jan 2012 07:10:34 -0800 (PST) Received: from [192.168.100.89] ([67.224.83.162]) by mx.google.com with ESMTPS id z1sm561308vdh.11.2012.01.25.07.10.28 (version=SSLv3 cipher=OTHER); Wed, 25 Jan 2012 07:10:32 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Wed, 25 Jan 2012 10:10:26 -0500 From: Victor Kuarsingh To: Jared Mauch , John Jason Brzozowski Message-ID: Thread-Topic: [v6ops] Reminder: draft-ietf-v6ops-v6nd-problems WGLC In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-2" Content-transfer-encoding: quoted-printable Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" , Ron Bonica Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-v6nd-problems WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 15:10:36 -0000 I too support this as I have noted in the past. As noted by Cameron, this is useful for network operations. Regards, Victor K On 12-01-23 11:33 PM, "Jared Mauch" wrote: >Also here. Sorry thought I had communicated support in the past. > >Jared Mauch > >On Jan 23, 2012, at 9:09 PM, "Brzozowski, John" > wrote: > >> Warren, >>=20 >> I of course am board and support this as well even though I am sending >> this email after WGLC has concluded. >>=20 >> John >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> John Jason Brzozowski >> Comcast Cable >> e) mailto:john_brzozowski@cable.comcast.com >> o) 609-377-6594 >> m) 484-962-0060 >> w) http://www.comcast6.net >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >>=20 >>=20 >>=20 >> On 1/23/12 10:23 PM, "Warren Kumari" wrote: >>=20 >>>=20 >>> On Jan 23, 2012, at 10:16 PM, Cameron Byrne wrote: >>>=20 >>>>=20 >>>> On Jan 21, 2012 3:44 PM, "Joel jaeggli" wrote: >>>>>=20 >>>>> we've had comments from wes george and and extensive review from ray >>>>> hunter which will be incorpoortated into a new draft. So far that's >>>>>it >>>>> for WGLC feedback. >>>>>=20 >>>>> While that's useful it's not a strong demonstration of support for >>>>> publication as a WG document. >>>>>=20 >>>>> the WGLC timer is offcially up on the 22nd. >>>>>=20 >>>>=20 >>>> Sorry for being a day late. I support this draft as being useful to >>>> ipv6 network operators and network vendors. >>>=20 >>> Whoo thanks=A9. >>>=20 >>> Even though the WGLC has officially closed, input like this is still >>> useful so that the chairs can determine if there is still interest, if >>> they should restart WGLC, call consensus, or what=A9 >>>=20 >>> It is also *really* helpful to the authors -- we wrote this because we >>> figured folk might like it and it might be useful -- even if the doc >>> never progresses it is nice to know that folk like it... >>>=20 >>>=20 >>>=20 >>> W >>>=20 >>>>=20 >>>> Cb >>>>> joel >>>>>=20 >>>>> On 1/16/12 07:48 , Fred Baker wrote: >>>>>> The working group last call for this draft announced last week >>>> continues >>>>>> for another week. Please feel free to comment on it. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> v6ops mailing list >>>>>> v6ops@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>>=20 >>>>> _______________________________________________ >>>>> v6ops mailing list >>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>> -- >>> Don't be impressed with unintelligible stuff said condescendingly. >>> -- Radia Perlman. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From internet-drafts@ietf.org Wed Jan 25 12:16:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAAA21F8522; Wed, 25 Jan 2012 12:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5TlWoMpncND; Wed, 25 Jan 2012 12:16:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065FC21F84EF; Wed, 25 Jan 2012 12:16:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120125201643.4405.40900.idtracker@ietfa.amsl.com> Date: Wed, 25 Jan 2012 12:16:43 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-v6nd-problems-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 20:16:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : Operational Neighbor Discovery Problems Author(s) : Igor Gashinsky Joel Jaeggli Warren Kumari Filename : draft-ietf-v6ops-v6nd-problems-03.txt Pages : 13 Date : 2012-01-25 In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of Neighbor Discovery (ND) can be vulnerable to deliberate or accidental denial of service, whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial of attacks can be launched intentionally (by an attacker), or result from legitimate operational tools or accident conditions. As a result of these vulnerabilities, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing IPv6 transported flows may be interrupted. This document describes the potential for DOS in detail and suggests possible implementation improvements as well as operational mitigation techniques that can in some cases be used to protect against or at least alleviate the impact of such attacks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6nd-problems-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-v6nd-problems-03.txt From warren@kumari.net Wed Jan 25 12:48:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5E121F8570 for ; Wed, 25 Jan 2012 12:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.202 X-Spam-Level: X-Spam-Status: No, score=-106.202 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhiMiOR7XN+m for ; Wed, 25 Jan 2012 12:48:12 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE2621F8508 for ; Wed, 25 Jan 2012 12:48:12 -0800 (PST) Received: from dhcp-172-19-119-228.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 2EB8F1B414C6; Wed, 25 Jan 2012 15:48:11 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <20120125201643.4405.40900.idtracker@ietfa.amsl.com> Date: Wed, 25 Jan 2012 15:48:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120125201643.4405.40900.idtracker@ietfa.amsl.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1084) Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-v6nd-problems-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 20:48:13 -0000 This simply folds in the comments that folk sent to the list during = WGLC. W On Jan 25, 2012, at 3:16 PM, 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 : Operational Neighbor Discovery Problems > Author(s) : Igor Gashinsky > Joel Jaeggli > Warren Kumari > Filename : draft-ietf-v6ops-v6nd-problems-03.txt > Pages : 13 > Date : 2012-01-25 >=20 > In IPv4, subnets are generally small, made just large enough to = cover > the actual number of machines on the subnet. In contrast, the > default IPv6 subnet size is a /64, a number so large it covers > trillions of addresses, the overwhelming number of which will be > unassigned. Consequently, simplistic implementations of Neighbor > Discovery (ND) can be vulnerable to deliberate or accidental denial > of service, whereby they attempt to perform address resolution for > large numbers of unassigned addresses. Such denial of attacks can = be > launched intentionally (by an attacker), or result from legitimate > operational tools or accident conditions. As a result of these > vulnerabilities, new devices may not be able to "join" a network, it > may be impossible to establish new IPv6 flows, and existing IPv6 > transported flows may be interrupted. >=20 > This document describes the potential for DOS in detail and suggests > possible implementation improvements as well as operational > mitigation techniques that can in some cases be used to protect > against or at least alleviate the impact of such attacks. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6nd-problems-03.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-v6nd-problems-03.txt >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From shemant@cisco.com Wed Jan 25 13:56:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1DB11E80B9 for ; Wed, 25 Jan 2012 13:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53ORx0LM8875 for ; Wed, 25 Jan 2012 13:56:55 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B2F6A11E8098 for ; Wed, 25 Jan 2012 13:56:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2786; q=dns/txt; s=iport; t=1327528615; x=1328738215; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=fmXjDfSAg4wCVgLpcVhRMntIPsd2z9ubwVlY64pkq80=; b=BsGT0R2oSN9Aj8yTDrhD+aD8zmi1yoaU/PI9QGZmvpEIsyoUMcWsms5P hyPb/hwOnS7S5hhcN1rZ7ZpLMhyABxCeXf/Ek8go3lq+A/Q/NbXhauRMc U7VyXzXkHJs4LC0cGobclfV7WOkIXsD41mYOP0wywupwB/JqDI7FpRfzX Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFR6IE+tJXG+/2dsb2JhbABDrkSBBYFyAQEBAwEBAQEPAR0KNBcEAgEIEQQBAQsGFwEGASYfCQgBAQQBEggBGYdaCJlcAZ45iSsCAS6CcgQRYhyCUGMEiD+fTw X-IronPort-AV: E=Sophos;i="4.71,570,1320624000"; d="scan'208";a="53882807" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 25 Jan 2012 21:56:55 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0PLutrc020128; Wed, 25 Jan 2012 21:56:55 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Jan 2012 15:56:55 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Jan 2012 15:56:54 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303D50D85@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-v6nd-problems-03.txt Thread-Index: Aczboq5jYKh6w/QfS1errdK5PHFF1QACYDmw References: <20120125201643.4405.40900.idtracker@ietfa.amsl.com> From: "Hemant Singh (shemant)" To: "Warren Kumari" , "IPv6 Operations" X-OriginalArrivalTime: 25 Jan 2012 21:56:55.0175 (UTC) FILETIME=[409C6170:01CCDBAC] Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-v6nd-problems-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 21:56:56 -0000 Warren, Thanks. I support the document to move forward to the IESG. Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Warren Kumari Sent: Wednesday, January 25, 2012 3:48 PM To: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-v6nd-problems-03.txt This simply folds in the comments that folk sent to the list during WGLC. W On Jan 25, 2012, at 3:16 PM, 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 : Operational Neighbor Discovery Problems > Author(s) : Igor Gashinsky > Joel Jaeggli > Warren Kumari > Filename : draft-ietf-v6ops-v6nd-problems-03.txt > Pages : 13 > Date : 2012-01-25 >=20 > In IPv4, subnets are generally small, made just large enough to cover > the actual number of machines on the subnet. In contrast, the > default IPv6 subnet size is a /64, a number so large it covers > trillions of addresses, the overwhelming number of which will be > unassigned. Consequently, simplistic implementations of Neighbor > Discovery (ND) can be vulnerable to deliberate or accidental denial > of service, whereby they attempt to perform address resolution for > large numbers of unassigned addresses. Such denial of attacks can be > launched intentionally (by an attacker), or result from legitimate > operational tools or accident conditions. As a result of these > vulnerabilities, new devices may not be able to "join" a network, it > may be impossible to establish new IPv6 flows, and existing IPv6 > transported flows may be interrupted. >=20 > This document describes the potential for DOS in detail and suggests > possible implementation improvements as well as operational > mitigation techniques that can in some cases be used to protect > against or at least alleviate the impact of such attacks. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6nd-problems-03.tx t >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-v6nd-problems-03.txt >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From Tina.Tsou.Zouting@huawei.com Wed Jan 25 16:23:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E5411E80A1 for ; Wed, 25 Jan 2012 16:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.217 X-Spam-Level: X-Spam-Status: No, score=-6.217 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oQqLDwqNFhe for ; Wed, 25 Jan 2012 16:23:03 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1940B11E8097 for ; Wed, 25 Jan 2012 16:23:03 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYD00FHEQECGF@szxga05-in.huawei.com> for v6ops@ietf.org; Thu, 26 Jan 2012 08:23:00 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYD00IEVQECAW@szxga05-in.huawei.com> for v6ops@ietf.org; Thu, 26 Jan 2012 08:23:00 +0800 (CST) Received: from szxeml210-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGO64902; Thu, 26 Jan 2012 08:21:58 +0800 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by szxeml210-edg.china.huawei.com (172.24.2.183) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 26 Jan 2012 08:21:43 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.225]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Thu, 26 Jan 2012 08:22:33 +0800 Date: Thu, 26 Jan 2012 00:21:48 +0000 From: Tina TSOU In-reply-to: <5B6B2B64C9FE2A489045EEEADDAFF2C303D50D85@XMB-RCD-109.cisco.com> X-Originating-IP: [10.193.34.128] To: "Hemant Singh (shemant)" , Warren Kumari , IPv6 Operations Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [v6ops] I-D Action: draft-ietf-v6ops-v6nd-problems-03.txt Thread-index: AQHM255UuVLISg1SFk6lwjPdJRuNwZYdB/GAgAATNQCAAK1qQA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20120125201643.4405.40900.idtracker@ietfa.amsl.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303D50D85@XMB-RCD-109.cisco.com> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-v6nd-problems-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 00:23:04 -0000 Indeed, SLAAC is showing up primarily in environment instrumentation (sensors) and sometimes in the DC for server provisioning coupled with dynamic DNS. It is a good catch besides RA Guard (http://tools.ietf.org/html/rfc6105), a feature in big demand by enterprise customers. Tina > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Hemant Singh (shemant) > Sent: Wednesday, January 25, 2012 1:57 PM > To: Warren Kumari; IPv6 Operations > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-v6nd-problems-03.txt > > Warren, > > Thanks. I support the document to move forward to the IESG. > > Hemant > > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Warren Kumari > Sent: Wednesday, January 25, 2012 3:48 PM > To: IPv6 Operations > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-v6nd-problems-03.txt > > This simply folds in the comments that folk sent to the list during > WGLC. > > W > On Jan 25, 2012, at 3:16 PM, internet-drafts@ietf.org wrote: > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the IPv6 Operations Working > Group of the IETF. > > > > Title : Operational Neighbor Discovery Problems > > Author(s) : Igor Gashinsky > > Joel Jaeggli > > Warren Kumari > > Filename : draft-ietf-v6ops-v6nd-problems-03.txt > > Pages : 13 > > Date : 2012-01-25 > > > > In IPv4, subnets are generally small, made just large enough to > cover > > the actual number of machines on the subnet. In contrast, the > > default IPv6 subnet size is a /64, a number so large it covers > > trillions of addresses, the overwhelming number of which will be > > unassigned. Consequently, simplistic implementations of Neighbor > > Discovery (ND) can be vulnerable to deliberate or accidental denial > > of service, whereby they attempt to perform address resolution for > > large numbers of unassigned addresses. Such denial of attacks can > be > > launched intentionally (by an attacker), or result from legitimate > > operational tools or accident conditions. As a result of these > > vulnerabilities, new devices may not be able to "join" a network, it > > may be impossible to establish new IPv6 flows, and existing IPv6 > > transported flows may be interrupted. > > > > This document describes the potential for DOS in detail and suggests > > possible implementation improvements as well as operational > > mitigation techniques that can in some cases be used to protect > > against or at least alleviate the impact of such attacks. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6nd-problems-03.tx > t > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > This Internet-Draft can be retrieved at: > > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-v6nd-problems-03.txt > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From tjc@ecs.soton.ac.uk Thu Jan 26 02:19:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2869A21F86BD for ; Thu, 26 Jan 2012 02:19:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NulskokIgGc7 for ; Thu, 26 Jan 2012 02:19:38 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id C468F21F86B9 for ; Thu, 26 Jan 2012 02:19:37 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q0QAJVI0025629 for ; Thu, 26 Jan 2012 10:19:31 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q0QAJVI0025629 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1327573172; bh=tNgjcbjlD2fDsAh8y7p4e75Tj0s=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=vTfoE2VHGhTeL2EAILPQWjIxWLK+oa4bTtbtjiYiYuO8HnOBVyd7TTsQtXXiHWJql W9eKBcDBZOVTa6+MHsEU/X3TE8QeN8qzO8NDpdLJxOdG21dOIMpj8MF3Sw+p6yQRYV tBUOpFKCLi9BLb4n6EKVuzaBXdt0laldPiaagG9E= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id o0PAJV0543718785vz ret-id none; Thu, 26 Jan 2012 10:19:31 +0000 Received: from [IPv6:2001:630:d0:ed03:ad12:d71a:5d01:8b2c] ([IPv6:2001:630:d0:ed03:ad12:d71a:5d01:8b2c]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q0QAJSbZ000321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 26 Jan 2012 10:19:29 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Tim Chown In-Reply-To: Date: Thu, 26 Jan 2012 10:19:29 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20120125201643.4405.40900.idtracker@ietfa.amsl.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303D50D85@XMB-RCD-109.cisco.com> <49F8E2B4-62A6-453E-BAA5-8A8108285299@ecs.soton.ac.uk> To: IPv6 Operations X-Mailer: Apple Mail (2.1251.1) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o0PAJV054371878500; tid=o0PAJV0543718785vz; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q0QAJVI0025629 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-v6nd-problems-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 10:19:39 -0000 Looks ready to go. Where SLAAC is best or most commonly used is not really relevant, and = the text imo rightly avoids the topic. Tim On 26 Jan 2012, at 00:21, Tina TSOU wrote: > Indeed, SLAAC is showing up primarily in environment instrumentation = (sensors) and sometimes in the DC for server provisioning coupled with = dynamic DNS. >=20 > It is a good catch besides RA Guard = (http://tools.ietf.org/html/rfc6105), a feature in big demand by = enterprise customers. >=20 >=20 > Tina >=20 >=20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of >> Hemant Singh (shemant) >> Sent: Wednesday, January 25, 2012 1:57 PM >> To: Warren Kumari; IPv6 Operations >> Subject: Re: [v6ops] I-D Action: = draft-ietf-v6ops-v6nd-problems-03.txt >>=20 >> Warren, >>=20 >> Thanks. I support the document to move forward to the IESG. >>=20 >> Hemant >>=20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf >> Of Warren Kumari >> Sent: Wednesday, January 25, 2012 3:48 PM >> To: IPv6 Operations >> Subject: Re: [v6ops] I-D Action: = draft-ietf-v6ops-v6nd-problems-03.txt >>=20 >> This simply folds in the comments that folk sent to the list during >> WGLC. >>=20 >> W >> On Jan 25, 2012, at 3:16 PM, internet-drafts@ietf.org wrote: >>=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 : Operational Neighbor Discovery Problems >>> Author(s) : Igor Gashinsky >>> Joel Jaeggli >>> Warren Kumari >>> Filename : draft-ietf-v6ops-v6nd-problems-03.txt >>> Pages : 13 >>> Date : 2012-01-25 >>>=20 >>> In IPv4, subnets are generally small, made just large enough to >> cover >>> the actual number of machines on the subnet. In contrast, the >>> default IPv6 subnet size is a /64, a number so large it covers >>> trillions of addresses, the overwhelming number of which will be >>> unassigned. Consequently, simplistic implementations of Neighbor >>> Discovery (ND) can be vulnerable to deliberate or accidental denial >>> of service, whereby they attempt to perform address resolution for >>> large numbers of unassigned addresses. Such denial of attacks can >> be >>> launched intentionally (by an attacker), or result from legitimate >>> operational tools or accident conditions. As a result of these >>> vulnerabilities, new devices may not be able to "join" a network, = it >>> may be impossible to establish new IPv6 flows, and existing IPv6 >>> transported flows may be interrupted. >>>=20 >>> This document describes the potential for DOS in detail and = suggests >>> possible implementation improvements as well as operational >>> mitigation techniques that can in some cases be used to protect >>> against or at least alleviate the impact of such attacks. >>>=20 >>>=20 >>> A URL for this Internet-Draft is: >>>=20 >> = http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6nd-problems-03.tx >> t >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> This Internet-Draft can be retrieved at: >>>=20 >> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-v6nd-problems-03.txt >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From rajiva@cisco.com Thu Jan 26 07:50:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A4721F86C2 for ; Thu, 26 Jan 2012 07:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.239 X-Spam-Level: X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjuN4K360Tsu for ; Thu, 26 Jan 2012 07:50:30 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 51D6021F8682 for ; Thu, 26 Jan 2012 07:50:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=3244; q=dns/txt; s=iport; t=1327593030; x=1328802630; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=e3Tqe2bDWBABzOBN89OI/fjPuU/aoyz2XprhsFRz3Qw=; b=h6cG51rC34fuyGkqvk7UlYeC/xSanjZbBI4SMq+l/FBNDDCqjkKH389V gkGMkAe8oK4Km+B38jz6AMb1/f/hoTnGw7rlAQKpnNNUGA3lBy3fB//sC Y5eGEIWDd/LtmVOlaCuqfnbgBLL3H0xYspSM6/F8YhanXiP/PZ0H1B4Mt c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFACl1IU+tJV2c/2dsb2JhbABCrkqBBYFyAQEBBAEBAQ8BFAkKNAsMBAIBCBEBAwEBCwYXAQYBJh8DBggBAQQBEggah2KZNgGeRIkYJjUehEuCWGMEiD+fUA X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="54082316" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 26 Jan 2012 15:50:30 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q0QFoTGp019992; Thu, 26 Jan 2012 15:50:29 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Jan 2012 09:50:29 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Jan 2012 09:50:29 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C073C54B4@XMB-RCD-111.cisco.com> In-Reply-To: <20120125022122kawashimam@mail.jp.nec.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] I-D Action: draft-mawatari-v6ops-464xlat-00.txt Thread-Index: AczavN48j/LZ+jCTRJ+mEVcyWd8wGgAxTI9g References: <4F1E0CEB.2060007@gmail.com> <20120125022122kawashimam@mail.jp.nec.com> From: "Rajiv Asati (rajiva)" To: "Masanobu Kawashima" , "Brian E Carpenter" X-OriginalArrivalTime: 26 Jan 2012 15:50:29.0741 (UTC) FILETIME=[3AAF21D0:01CCDC42] Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-mawatari-v6ops-464xlat-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 15:50:31 -0000 Masanobu-san, This is an interesting discussion and proposal. Few Q -- 1. How is IPv4 address getting assigned to the host? 2. Could we not use an existing DHCP option to convey DNS server IPv4 address to the CLAT device, which can convey the DNSv4 address the same way as IPv4 address is conveyed? If we could, then we would not need DNS proxy function on CLAT.=20 3. Section 7.4 requires CLAT device to have router function. What happens if it is a typical host device (without any router function)? ~~~~~~~~~ 7.4. DNS Proxy Implementation If a router implement CLAT function, it performs DNS Proxy for IPv4 hosts and IPv6 hosts in end-user network. It MUST provide name resolution with IPv6 transport. It does not need DNS64 [RFC6147] ~~~~~~~~~~~~~~~ 4. In section 8, did you mean to say IPv4 -> IPv6 -> IPv4 translation below? :-) ~~~~~~~~~~~~ ... This 464XLAT architecture has two capabilities. One is a IPv6 -> IPv4 -> IPv6 translation for sharing global IPv4 addresses, another ~~~~~~~~~ =09 5. Section 7.7 (Auto IPv6 Prefix Assignment) could benefit from some explicit recommendation (since the current text says source v6 prefix assignment is done via DHCPv6-PD or another method, and destination IPv6 prefix assignment is via some method). =09 Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Masanobu Kawashima > Sent: Tuesday, January 24, 2012 12:21 PM > To: Brian E Carpenter > Cc: IPv6 Operations > Subject: Re: [v6ops] I-D Action: draft-mawatari-v6ops-464xlat-00.txt >=20 >=20 > Hi Brian, >=20 > Thank you for your comment. >=20 > I take your point. However, a CLAT can only learn the address of an IPv6 > DNS recursive server through DHCPv6 (or other way). The CLAT can not easily > discover the address of an IPv4 DNS recursive server, and it has to perform > all DNS resolution over IPv6. >=20 > The CLAT can pass this IPv6 address to downstream IPv6 hosts, but not to > downstream IPv4 hosts. As such, the CLAT should implement a DNS proxy. >=20 > Regards, > Masanobu >=20 >=20 > >> 7.4. DNS Proxy Implementation > >> > >> If a router implement CLAT function, it performs DNS Proxy for IPv4 > >> hosts and IPv6 hosts in end-user network. > > > >Why is this necessary? As far as I can see, the client could use any > >normal DNS server, because the A and AAAA records it needs are completely > >standard. > > > >Regards > > Brian Carpenter > > > >_______________________________________________ > >v6ops mailing list > >v6ops@ietf.org > >https://www.ietf.org/mailman/listinfo/v6ops >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > NEC AccessTechnica, Ltd. > Product Development Department > Masanobu Kawashima > kawashimam@vx.jp.nec.com > http://www.necat.co.jp/ > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From kawashimam@vx.jp.nec.com Thu Jan 26 17:33:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5554011E8072 for ; Thu, 26 Jan 2012 17:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.36 X-Spam-Level: X-Spam-Status: No, score=0.36 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFvlIXzo9gr3 for ; Thu, 26 Jan 2012 17:33:05 -0800 (PST) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by ietfa.amsl.com (Postfix) with ESMTP id 4D47F21F85C2 for ; Thu, 26 Jan 2012 17:33:05 -0800 (PST) Received: from mailgate3.nec.co.jp ([10.7.69.197]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id q0R1X08F028259; Fri, 27 Jan 2012 10:33:00 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id q0R1X0k21214; Fri, 27 Jan 2012 10:33:00 +0900 (JST) Received: from mail01b.kamome.nec.co.jp (mail01b.kamome.nec.co.jp [10.25.43.2]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id q0R1WxHf023812; Fri, 27 Jan 2012 10:32:59 +0900 (JST) Received: from shoin.jp.nec.com ([10.26.220.3] [10.26.220.3]) by mail01b.kamome.nec.co.jp with ESMTP id BT-MMP-593175; Fri, 27 Jan 2012 10:31:19 +0900 Received: from siznecatg159185 ([10.3.159.185] [10.3.159.185]) by mail.jp.nec.com with ESMTP; Fri, 27 Jan 2012 10:31:18 +0900 To: "Rajiv Asati (rajiva)" In-reply-to: <067E6CE33034954AAC05C9EC85E2577C073C54B4@XMB-RCD-111.cisco.com> Message-Id: <20120127103118kawashimam@mail.jp.nec.com> References: <067E6CE33034954AAC05C9EC85E2577C073C54B4@XMB-RCD-111.cisco.com> Mime-Version: 1.0 X-Mailer: StarOffice21/MailClient[4.65 Step9] From: Masanobu Kawashima Date: Fri, 27 Jan 2012 10:31:17 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-mawatari-v6ops-464xlat-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 01:33:06 -0000 Dear Rajiv, Thank you for your comments. >1. How is IPv4 address getting assigned to the host? The 464XLAT architecture does not have any requirements on how the IPv4 address is assigned. It can be assigned via static or dhcpv4. We should add some language that the subnet must be defined in the CLAT to better define the scope of stateless translation. The CLAT can acts just like other home gateways or mobile hotspots that assign RFC1918 address (such as 192.168.1.x/24) to clients. There is nothing special about the CLAT in how it assigns the address to a client. >2. Could we not use an existing DHCP option to convey DNS server IPv4 >address to the CLAT device, which can convey the DNSv4 address the same >way as IPv4 address is conveyed? If we could, then we would not need DNS >proxy function on CLAT. The focus of this effort is on an IPv6-only access network. We don't see an architectural benefit of doing 464XLAT translation for each DNS request. As stated to Brian, the host may have its own choice of DNS servers, including IPv4 DNS servers that require 464XLAT, but that is not the design we would like to promote as the ideal case. >3. Section 7.4 requires CLAT device to have router function. What >happens if it is a typical host device (without any router function)? > >~~~~~~~~~ >7.4. DNS Proxy Implementation > If a router implement CLAT function, it performs DNS Proxy for IPv4 > hosts and IPv6 hosts in end-user network. It MUST provide name > resolution with IPv6 transport. It does not need DNS64 [RFC6147] >~~~~~~~~~~~~~~~ The router function can be virtual. This is the case of the Nokia n900 and Android, which are really just hosts. >4. In section 8, did you mean to say IPv4 -> IPv6 -> IPv4 translation >below? :-) >~~~~~~~~~~~~ >... > This 464XLAT architecture has two capabilities. One is a IPv6 -> > IPv4 -> IPv6 translation for sharing global IPv4 addresses, another >~~~~~~~~~ Yes. It is an error in writing. :-) >5. Section 7.7 (Auto IPv6 Prefix Assignment) could benefit from some >explicit recommendation (since the current text says source v6 prefix >assignment is done via DHCPv6-PD or another method, and destination IPv6 >prefix assignment is via some method). It depends on network operator. Why would more explicit help? We would like to keep the options flexible so that solution can evolve with different wireline and wireless network capabilities. But, we agree dhcpv6-pd is good today. We just do not want to exclude other options without a reason. Regards, Masanobu >Masanobu-san, > >This is an interesting discussion and proposal. Few Q -- > >1. How is IPv4 address getting assigned to the host? >2. Could we not use an existing DHCP option to convey DNS server IPv4 >address to the CLAT device, which can convey the DNSv4 address the same >way as IPv4 address is conveyed? If we could, then we would not need DNS >proxy function on CLAT. >3. Section 7.4 requires CLAT device to have router function. What >happens if it is a typical host device (without any router function)? > >~~~~~~~~~ >7.4. DNS Proxy Implementation > If a router implement CLAT function, it performs DNS Proxy for IPv4 > hosts and IPv6 hosts in end-user network. It MUST provide name > resolution with IPv6 transport. It does not need DNS64 [RFC6147] >~~~~~~~~~~~~~~~ > >4. In section 8, did you mean to say IPv4 -> IPv6 -> IPv4 translation >below? :-) >~~~~~~~~~~~~ >... > This 464XLAT architecture has two capabilities. One is a IPv6 -> > IPv4 -> IPv6 translation for sharing global IPv4 addresses, another >~~~~~~~~~ > >5. Section 7.7 (Auto IPv6 Prefix Assignment) could benefit from some >explicit recommendation (since the current text says source v6 prefix >assignment is done via DHCPv6-PD or another method, and destination IPv6 >prefix assignment is via some method). > >Cheers, >Rajiv > > >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >Of >> Masanobu Kawashima >> Sent: Tuesday, January 24, 2012 12:21 PM >> To: Brian E Carpenter >> Cc: IPv6 Operations >> Subject: Re: [v6ops] I-D Action: draft-mawatari-v6ops-464xlat-00.txt >> >> >> Hi Brian, >> >> Thank you for your comment. >> >> I take your point. However, a CLAT can only learn the address of an >IPv6 >> DNS recursive server through DHCPv6 (or other way). The CLAT can not >easily >> discover the address of an IPv4 DNS recursive server, and it has to >perform >> all DNS resolution over IPv6. >> >> The CLAT can pass this IPv6 address to downstream IPv6 hosts, but not >to >> downstream IPv4 hosts. As such, the CLAT should implement a DNS proxy. >> >> Regards, >> Masanobu >> >> >> >> 7.4. DNS Proxy Implementation >> >> >> >> If a router implement CLAT function, it performs DNS Proxy for >IPv4 >> >> hosts and IPv6 hosts in end-user network. >> > >> >Why is this necessary? As far as I can see, the client could use any >> >normal DNS server, because the A and AAAA records it needs are >completely >> >standard. >> > >> >Regards >> > Brian Carpenter >> > >> >_______________________________________________ >> >v6ops mailing list >> >v6ops@ietf.org >> >https://www.ietf.org/mailman/listinfo/v6ops >> >> ======================================== >> NEC AccessTechnica, Ltd. >> Product Development Department >> Masanobu Kawashima >> kawashimam@vx.jp.nec.com >> http://www.necat.co.jp/ >> ======================================== >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops ======================================== NEC AccessTechnica, Ltd. Product Development Department Masanobu Kawashima kawashimam@vx.jp.nec.com http://www.necat.co.jp/ ======================================== From dwing@cisco.com Fri Jan 27 11:59:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F4821F85D2; Fri, 27 Jan 2012 11:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.278 X-Spam-Level: X-Spam-Status: No, score=-106.278 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fZfDtM9zs4y; Fri, 27 Jan 2012 11:59:20 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 059A621F85BD; Fri, 27 Jan 2012 11:59:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2191; q=dns/txt; s=iport; t=1327694360; x=1328903960; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=4iP71SayWxHTJ7P6QfTflKS0Rix2A/csyPPvgdKiMVE=; b=eIUSJMu4LhNj99AS+7DhdZ3Mu5BphSX4NSetX7U0sAFl8xeS8h3dqfkE LA/axy4YVvJGFNIgCtiVpxYrVmcWbY7x85CT8LkJ8QQ+Oz7m1tK+86IP0 2shIR/by4rP6zQJEKzypwEn53JAhEUbM3V5dZLoB3YSgcz7RurjvVy0+8 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAOABI0+rRDoI/2dsb2JhbABEn12OdoEFgXkICgEXED8NBRhQIxwBBB4Xh2KZZAGeOwSJEAEkCycRAg4BhBM3gzsEiD+FBJpF X-IronPort-AV: E=Sophos;i="4.71,582,1320624000"; d="scan'208";a="27487979" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 27 Jan 2012 19:59:12 +0000 Received: from dwingWS ([10.32.240.197]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0RJxCHP006021; Fri, 27 Jan 2012 19:59:12 GMT From: "Dan Wing" To: "'v6ops'" Date: Fri, 27 Jan 2012 11:59:12 -0800 Message-ID: <169401ccdd2e$23b48910$6b1d9b30$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczdLiNo+NvlTE2QQH2IlmZasEPwAg== Content-Language: en-us Cc: pcp@ietf.org, draft-ietf-v6ops-6204bis@tools.ietf.org Subject: [v6ops] PCP server in draft-ietf-v6ops-6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 19:59:20 -0000 v6ops, I was reading over draft-ietf-v6ops-6204bis today and have a suggestion. Background: RFC6092 is v6ops's Simple CPE Security document, which recommends that a protocol be used to allow a passive listener (e.g., web camera) to open a pinhole. In that document, James Woodyatt's ALD was suggested as a possible candidate protocol for that function. But I see that both the old RFC6204 and draft-ietf-v6ops-6204bis-05 say this (I added uppercase for emphasis): S-1: The IPv6 CE router SHOULD support [RFC6092]. In particular, the IPv6 CE router SHOULD support functionality sufficient for implementing the set of recommendations in [RFC6092], Section 4. This document takes no position on whether such functionality is enabled by default OR MECHANISMS BY WHICH USERS WOULD CONFIGURE IT. I would like draft-ietf-v6ops-6204bis to take the position that Port Control Protocol (PCP) be the protocol for the uppercased function. Stated more clearly, I would like the above paragraph to read: S-1: The IPv6 CE router SHOULD support [RFC6092]. In particular, the IPv6 CE router SHOULD support functionality sufficient for implementing the set of recommendations in [RFC6092], Section 4. This document takes no position on whether such functionality is enabled by default. The IPv6 CE router ...............................................^^^^^^^^^^^^^^^^^^ SHOULD implement a PCP server [I-D.ietf-pcp-base] so that .........^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ hosts can configure this functionality. .........^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If you need more background, please be sure to read both REQ-48 and REQ-49 of RFC6092. PCP would be a specific protocol that fulfills REQ-49. In anticipation of one of the earlier objections that making PCP a normative requirement would delay draft-ietf-v6ops-6204bis, https://datatracker.ietf.org/doc/draft-ietf-pcp-base shows the document status is Publication Requested because the PCP working group finished its WGLC on the document. -d From bs7652@att.com Fri Jan 27 12:18:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC8421F8677; Fri, 27 Jan 2012 12:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-u80Qxmxxoi; Fri, 27 Jan 2012 12:18:25 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 8E08B21F8517; Fri, 27 Jan 2012 12:18:25 -0800 (PST) X-Env-Sender: bs7652@att.com X-Msg-Ref: server-5.tower-119.messagelabs.com!1327695504!12743523!1 X-Originating-IP: [144.160.20.146] X-StarScan-Version: 6.4.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3051 invoked from network); 27 Jan 2012 20:18:24 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-5.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Jan 2012 20:18:24 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q0RKGrhD015847; Fri, 27 Jan 2012 15:16:53 -0500 Received: from sflint03.pst.cso.att.com (sflint03.pst.cso.att.com [144.154.234.230]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q0RKGlYS015694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jan 2012 15:16:47 -0500 Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (gaalpa1msghub9e.itservices.sbc.com [130.8.36.91]) by sflint03.pst.cso.att.com (RSA Interceptor); Fri, 27 Jan 2012 15:18:01 -0500 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([169.254.6.206]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.01.0355.002; Fri, 27 Jan 2012 15:18:01 -0500 From: "STARK, BARBARA H" To: "'dwing@cisco.com'" , "'v6ops@ietf.org'" Thread-Topic: [v6ops] PCP server in draft-ietf-v6ops-6204bis Thread-Index: AczdLiNo+NvlTE2QQH2IlmZasEPwAgAAqESi Date: Fri, 27 Jan 2012 20:18:01 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611025315@GAALPA1MSGUSR9N.ITServices.sbc.com> In-Reply-To: <169401ccdd2e$23b48910$6b1d9b30$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.8.36.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Cc: "'pcp@ietf.org'" , "'draft-ietf-v6ops-6204bis@tools.ietf.org'" Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 20:18:26 -0000 I disagree.=20 I believe the marketplace should determine the winning technology in this c= ase, if there is to be a winning technology. RFC6204bis needs to continue t= o take no position.=20 Just because other solutions weren't created by IETF doesn't mean they are = any less good.=20 Barbara ----- Original Message ----- From: Dan Wing [mailto:dwing@cisco.com] Sent: Friday, January 27, 2012 02:59 PM=0A= To: 'v6ops' Cc: pcp@ietf.org ; draft-ietf-v6ops-6204bis@tools.ietf.org Subject: [v6ops] PCP server in draft-ietf-v6ops-6204bis v6ops, I was reading over draft-ietf-v6ops-6204bis today and have a=20 suggestion. Background: RFC6092 is v6ops's Simple CPE Security document, which=20 recommends that a protocol be used to allow a passive listener (e.g.,=20 web camera) to open a pinhole. In that document, James Woodyatt's=20 ALD was suggested as a possible candidate protocol for that function. But I see that both the old RFC6204 and draft-ietf-v6ops-6204bis-05 say this (I added uppercase for emphasis):=09 S-1: The IPv6 CE router SHOULD support [RFC6092]. In particular, the IPv6 CE router SHOULD support functionality sufficient for implementing the set of recommendations in [RFC6092], Section 4. This document takes no position on whether such functionality is enabled by default OR MECHANISMS BY WHICH=20 USERS WOULD CONFIGURE IT. I would like draft-ietf-v6ops-6204bis to take the position that=20 Port Control Protocol (PCP) be the protocol for the uppercased function. Stated more clearly, I would like the above paragraph to read: S-1: The IPv6 CE router SHOULD support [RFC6092]. In particular, the IPv6 CE router SHOULD support functionality sufficient for implementing the set of recommendations in [RFC6092], Section 4. This document takes no position on whether such functionality is enabled by default. The IPv6 CE router=20 ...............................................^^^^^^^^^^^^^^^^^^ SHOULD implement a PCP server [I-D.ietf-pcp-base] so that .........^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ hosts can configure this functionality. .........^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If you need more background, please be sure to read both REQ-48 and REQ-49 of RFC6092. PCP would be a specific protocol that fulfills REQ-49. In anticipation of one of the earlier objections that making PCP a normativ= e requirement would delay draft-ietf-v6ops-6204bis, https://datatracker.ietf.org/doc/draft-ietf-pcp-base shows the document status is Publication Requested because the PCP working group finished its WGLC on the document. -d _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From simon.perreault@viagenie.ca Fri Jan 27 12:49:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5137521F86D5; Fri, 27 Jan 2012 12:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyqeZYb17ZPU; Fri, 27 Jan 2012 12:49:57 -0800 (PST) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id B7A9021F8664; Fri, 27 Jan 2012 12:49:57 -0800 (PST) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:d74:bb6d:ddaf:2764]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E742E21F82; Fri, 27 Jan 2012 15:49:56 -0500 (EST) Message-ID: <4F230DF4.4040808@viagenie.ca> Date: Fri, 27 Jan 2012 15:49:56 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: "STARK, BARBARA H" References: <2D09D61DDFA73D4C884805CC7865E611025315@GAALPA1MSGUSR9N.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611025315@GAALPA1MSGUSR9N.ITServices.sbc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'v6ops@ietf.org'" , "'pcp@ietf.org'" , "'draft-ietf-v6ops-6204bis@tools.ietf.org'" Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 20:49:58 -0000 On 2012-01-27 15:18, STARK, BARBARA H wrote: > Just because other solutions weren't created by IETF doesn't mean they are any less good. Right. They are less good because PCP is better. Sorry, couldn't resist. ;) Seriously: We already have consensus on a "SHOULD implement a PCP server" in draft-ietf-behave-lsn-requirements. I think we should also have it on the CPE. Having only one protocol to support would make it so much easier for application developers! 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 dwing@cisco.com Fri Jan 27 12:54:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983A221F86E3; Fri, 27 Jan 2012 12:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.27 X-Spam-Level: X-Spam-Status: No, score=-106.27 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTXcHt2gbnJg; Fri, 27 Jan 2012 12:54:36 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id CDE7821F86DD; Fri, 27 Jan 2012 12:54:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=4108; q=dns/txt; s=iport; t=1327697676; x=1328907276; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=u8eOj26ml+RWa/4nS+vwmvOsZSJGSaYNweKGWnPOtzo=; b=DVX/gtR5bv6GSzVOUb1Qlnu7r5QAY/l0i20W0CI4BH7ZgSwcfoqmXEFO csXl3l22mDOuc2/b1wWuvBsdLCje1213h8JOIbDpU1SaDeyEjRb964kpI rNfpMdNur1EibuLZTu2lYH49fNrAp9DehvUlVqMkPHFpQn+bGsHaEJt7U k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAI4OI0+rRDoG/2dsb2JhbABEn16OdoEFgXIBAQEDAQEBAQUKARcQNAsFBwEDAgkPAgQBASgHGQ4VCgkIAQEEARILEAeHWgiZYAGeOASJEAEkCycRAg+EEzeDOwSIP4UEmkU X-IronPort-AV: E=Sophos;i="4.71,582,1320624000"; d="scan'208";a="25814058" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 27 Jan 2012 20:54:36 +0000 Received: from dwingWS ([10.32.240.197]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0RKsad7020154; Fri, 27 Jan 2012 20:54:36 GMT From: "Dan Wing" To: "'STARK, BARBARA H'" , References: <169401ccdd2e$23b48910$6b1d9b30$@com> <2D09D61DDFA73D4C884805CC7865E611025315@GAALPA1MSGUSR9N.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611025315@GAALPA1MSGUSR9N.ITServices.sbc.com> Date: Fri, 27 Jan 2012 12:54:36 -0800 Message-ID: <16ef01ccdd35$e0f5ebc0$a2e1c340$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczdLiNo+NvlTE2QQH2IlmZasEPwAgAAqESiAAEndkA= Content-Language: en-us Cc: pcp@ietf.org, draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 20:54:37 -0000 > -----Original Message----- > From: STARK, BARBARA H [mailto:bs7652@att.com] > Sent: Friday, January 27, 2012 12:18 PM > To: 'dwing@cisco.com'; 'v6ops@ietf.org' > Cc: 'pcp@ietf.org'; 'draft-ietf-v6ops-6204bis@tools.ietf.org' > Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis > > I disagree. > I believe the marketplace should determine the winning technology in > this case, if there is to be a winning technology. RFC6204bis needs to > continue to take no position. > > Just because other solutions weren't created by IETF doesn't mean they > are any less good. I suppose you are referring to UPnP IGD 2, which added IPv6 firewall support (among other things of less interest to v6ops). If it said "or UPnP IGD 2", would you still object or would that be acceptable? Right now, the text allows any sorts of thing -- including a web portal operated by the ISP, Web UI on the CPE itself, CLI on the CPE (accessed via ssh or telnet), holding a little red button in the back for 3 seconds to allow port 80 or 30 seconds to allow port 443, or whatever someone wants to design and claim compliance. This sort of free-for-all seems incongruent with Internet and IPv6 going into billions of homes and businesses and a standards-making organization such as the IETF. -d > Barbara > > ----- Original Message ----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Friday, January 27, 2012 02:59 PM > To: 'v6ops' > Cc: pcp@ietf.org ; draft-ietf-v6ops- > 6204bis@tools.ietf.org > Subject: [v6ops] PCP server in draft-ietf-v6ops-6204bis > > v6ops, > > I was reading over draft-ietf-v6ops-6204bis today and have a > suggestion. > > Background: RFC6092 is v6ops's Simple CPE Security document, which > recommends that a protocol be used to allow a passive listener (e.g., > web camera) to open a pinhole. In that document, James Woodyatt's > ALD was suggested as a possible candidate protocol for that function. > > But I see that both the old RFC6204 and draft-ietf-v6ops-6204bis-05 > say this (I added uppercase for emphasis): > > S-1: The IPv6 CE router SHOULD support [RFC6092]. In particular, > the IPv6 CE router SHOULD support functionality sufficient for > implementing the set of recommendations in [RFC6092], > Section 4. This document takes no position on whether such > functionality is enabled by default OR MECHANISMS BY WHICH > USERS WOULD CONFIGURE IT. > > > I would like draft-ietf-v6ops-6204bis to take the position that > Port Control Protocol (PCP) be the protocol for the uppercased > function. > > Stated more clearly, I would like the above paragraph to read: > > S-1: The IPv6 CE router SHOULD support [RFC6092]. In particular, > the IPv6 CE router SHOULD support functionality sufficient for > implementing the set of recommendations in [RFC6092], > Section 4. This document takes no position on whether such > functionality is enabled by default. The IPv6 CE router > ...............................................^^^^^^^^^^^^^^^^^^ > SHOULD implement a PCP server [I-D.ietf-pcp-base] so that > .........^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > hosts can configure this functionality. > .........^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > If you need more background, please be sure to read both REQ-48 and > REQ-49 > of RFC6092. PCP would be a specific protocol that fulfills REQ-49. > > > In anticipation of one of the earlier objections that making PCP a > normative > requirement would delay draft-ietf-v6ops-6204bis, > https://datatracker.ietf.org/doc/draft-ietf-pcp-base shows the document > status is Publication Requested because the PCP working group finished > its > WGLC on the document. > > -d > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From mbaugher@cisco.com Fri Jan 27 12:57:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A006421F85E6; Fri, 27 Jan 2012 12:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IU1JpN+8JSwJ; Fri, 27 Jan 2012 12:57:47 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id D346521F85DD; Fri, 27 Jan 2012 12:57:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mbaugher@cisco.com; l=3715; q=dns/txt; s=iport; t=1327697867; x=1328907467; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=CqVRc0VzPqFtw/idsAfAZhJXrkof3eSwGTjyisicHXw=; b=XWhmqyj8hmauOOyfqBl/Qz74h76BXDTHmexImZVd/pEfgMQWOIy04qns 9lLcj4SSlgZJcpFBC8ubOeABLwYTIh6R0Jz2DH59ZocUG0Vor79FVmBUQ ckdQBzjAsfgzdlMJhQLyth3KFM49SIz5LwO9VvAYifBIImzA6OI6o7QZV k=; X-IronPort-AV: E=Sophos;i="4.71,582,1320624000"; d="scan'208";a="27327014" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 27 Jan 2012 20:57:47 +0000 Received: from sjc-mbaugher-8711.cisco.com (sjc-mbaugher-8711.cisco.com [10.19.93.34]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0RKvl4m003125; Fri, 27 Jan 2012 20:57:47 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Mark Baugher In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611025315@GAALPA1MSGUSR9N.ITServices.sbc.com> Date: Fri, 27 Jan 2012 12:57:47 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0C554E3A-2933-490B-B42F-469105FFFADE@cisco.com> References: <2D09D61DDFA73D4C884805CC7865E611025315@GAALPA1MSGUSR9N.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1251.1) Cc: "'v6ops@ietf.org'" , "'pcp@ietf.org'" , "'draft-ietf-v6ops-6204bis@tools.ietf.org'" Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 20:57:48 -0000 On Jan 27, 2012, at 12:18 PM, STARK, BARBARA H wrote: > I disagree.=20 > I believe the marketplace should determine the winning technology in = this case, if there is to be a winning technology. There really is no marketplace but rather a situation where different = sets of vendors ship different solutions on products that are not = differentiated by how well they open up firewalls. This has been the = case for sometime now, and I don't expect to see a winning technology. = PCP also does more than IGD or NAT-PMP that is of interest to IPv6. Mark > RFC6204bis needs to continue to take no position.=20 >=20 > Just because other solutions weren't created by IETF doesn't mean they = are any less good.=20 > Barbara >=20 > ----- Original Message ----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Friday, January 27, 2012 02:59 PM > To: 'v6ops' > Cc: pcp@ietf.org ; = draft-ietf-v6ops-6204bis@tools.ietf.org = > Subject: [v6ops] PCP server in draft-ietf-v6ops-6204bis >=20 > v6ops, >=20 > I was reading over draft-ietf-v6ops-6204bis today and have a=20 > suggestion. >=20 > Background: RFC6092 is v6ops's Simple CPE Security document, which=20 > recommends that a protocol be used to allow a passive listener (e.g.,=20= > web camera) to open a pinhole. In that document, James Woodyatt's=20 > ALD was suggested as a possible candidate protocol for that function. >=20 > But I see that both the old RFC6204 and draft-ietf-v6ops-6204bis-05 > say this (I added uppercase for emphasis):=09 >=20 > S-1: The IPv6 CE router SHOULD support [RFC6092]. In particular, > the IPv6 CE router SHOULD support functionality sufficient for > implementing the set of recommendations in [RFC6092], > Section 4. This document takes no position on whether such > functionality is enabled by default OR MECHANISMS BY WHICH=20 > USERS WOULD CONFIGURE IT. >=20 >=20 > I would like draft-ietf-v6ops-6204bis to take the position that=20 > Port Control Protocol (PCP) be the protocol for the uppercased = function. >=20 > Stated more clearly, I would like the above paragraph to read: >=20 > S-1: The IPv6 CE router SHOULD support [RFC6092]. In particular, > the IPv6 CE router SHOULD support functionality sufficient for > implementing the set of recommendations in [RFC6092], > Section 4. This document takes no position on whether such > functionality is enabled by default. The IPv6 CE router=20 > ...............................................^^^^^^^^^^^^^^^^^^ > SHOULD implement a PCP server [I-D.ietf-pcp-base] so that > .........^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > hosts can configure this functionality. > .........^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >=20 > If you need more background, please be sure to read both REQ-48 and = REQ-49 > of RFC6092. PCP would be a specific protocol that fulfills REQ-49. >=20 >=20 > In anticipation of one of the earlier objections that making PCP a = normative > requirement would delay draft-ietf-v6ops-6204bis, > https://datatracker.ietf.org/doc/draft-ietf-pcp-base shows the = document > status is Publication Requested because the PCP working group finished = its > WGLC on the document. >=20 > -d >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From shemant@cisco.com Fri Jan 27 14:42:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CB821F8532; Fri, 27 Jan 2012 14:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.168 X-Spam-Level: X-Spam-Status: No, score=-8.168 tagged_above=-999 required=5 tests=[AWL=1.831, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqb7oQ2rce27; Fri, 27 Jan 2012 14:41:59 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4739721F8526; Fri, 27 Jan 2012 14:41:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1762; q=dns/txt; s=iport; t=1327704119; x=1328913719; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=W4HFlpUjCRdO+vuJsXdCfrDFI42rnf/jrgeLoIS1pe0=; b=ap/cCpqN7N1Q5j7ZM9KRjNEO5ddGbBqiUkG6ZLgTAAIWL0z2IO8W624O ldr6ahL5p2ttgv6CDEI+nAahbdmrnd1VqJvqSIVkA8bd7I3+FDeBuDbec 7zAvRJhCSQW5c/sr0WWbvubCC6R9pLFwPFSfFCER5BpL1YjEF/XxMx7bT w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAL0mI0+tJV2d/2dsb2JhbABErH6BV4EFgXIBAQEDARIBHQo/BQcEAgEIEQQBAQsGFwEGAUUJCAEBBAESCBqHWplaAZ46iQ8mNRsDhEuCWGMEiD+fRw X-IronPort-AV: E=Sophos;i="4.71,582,1320624000"; d="scan'208";a="54470209" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 27 Jan 2012 22:41:58 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q0RMfwOI012637; Fri, 27 Jan 2012 22:41:58 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Jan 2012 16:41:58 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Jan 2012 16:41:57 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303DE3753@XMB-RCD-109.cisco.com> In-Reply-To: <169401ccdd2e$23b48910$6b1d9b30$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] PCP server in draft-ietf-v6ops-6204bis Thread-Index: AczdLiNo+NvlTE2QQH2IlmZasEPwAgAFfTSQ References: <169401ccdd2e$23b48910$6b1d9b30$@com> From: "Hemant Singh (shemant)" To: "Dan Wing (dwing)" , "v6ops" X-OriginalArrivalTime: 27 Jan 2012 22:41:58.0610 (UTC) FILETIME=[E0CF5320:01CCDD44] Cc: pcp@ietf.org, mohamed.boucadair@orange-ftgroup.com, Dave Thaler , draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 22:42:00 -0000 Dan, -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Dan Wing (dwing) Sent: Friday, January 27, 2012 2:59 PM To: 'v6ops' Cc: pcp@ietf.org; draft-ietf-v6ops-6204bis@tools.ietf.org Subject: [v6ops] PCP server in draft-ietf-v6ops-6204bis > S-1: The IPv6 CE router SHOULD support [RFC6092]. In particular, > the IPv6 CE router SHOULD support functionality sufficient for > implementing the set of recommendations in [RFC6092], > Section 4. This document takes no position on whether such > functionality is enabled by default. The IPv6 CE router=20 >...............................................^^^^^^^^^^^^^^^^^^ > SHOULD implement a PCP server [I-D.ietf-pcp-base] so that >.........^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > hosts can configure this functionality. >.........^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The plan of record for rfc6204bis was indeed to add a PCP requirement if during the progression of the rfc6204bis document to the IESG, PCPbase became an RFC or is pending publication. "PCPbase pending publication" has happened - good. Now the specific req related to PCP we had agreed upon with v6ops during the last discussion was to include a PCP client in the CPE router, not a server. We had not agreed to a server because for one, one large host OS vendor is Microsoft does not have PCP support yet or least not as of a few months back. I have cced to Dave Thaler who had also agreed at the time to not include a server. Why can't the user of the CPE router manually provision a pinhole port and the PCP client in the CPE router sends a request to the DS-Lite AFTR. Hemant From randy@psg.com Fri Jan 27 14:42:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D5021F8570; Fri, 27 Jan 2012 14:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crlSkRyoeiq8; Fri, 27 Jan 2012 14:42:02 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id BB2FC21F8573; Fri, 27 Jan 2012 14:42:02 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RquUW-000E2R-MW; Fri, 27 Jan 2012 22:41:57 +0000 Date: Sat, 28 Jan 2012 07:41:54 +0900 Message-ID: From: Randy Bush To: "STARK, BARBARA H" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611025315@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <169401ccdd2e$23b48910$6b1d9b30$@com> <2D09D61DDFA73D4C884805CC7865E611025315@GAALPA1MSGUSR9N.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "'v6ops@ietf.org'" , "'pcp@ietf.org'" , "'draft-ietf-v6ops-6204bis@tools.ietf.org'" Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 22:42:03 -0000 > I believe the marketplace should determine the winning technology in > this case, if there is to be a winning technology. RFC6204bis needs to > continue to take no position. perhaps the users would like interoperability between their toys and their border? as far as the market deciding, i suspect less than .001 of the users even know there is a protocol used to make this work, let alone care. randy From Francis.Dupont@fdupont.fr Sat Jan 28 07:05:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E903621F85D2; Sat, 28 Jan 2012 07:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwnJAZrVrSRt; Sat, 28 Jan 2012 07:05:08 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 21F3A21F859F; Sat, 28 Jan 2012 07:05:07 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q0SF51fU007229; Sat, 28 Jan 2012 16:05:01 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201201281505.q0SF51fU007229@givry.fdupont.fr> From: Francis Dupont To: "STARK, BARBARA H" In-reply-to: Your message of Fri, 27 Jan 2012 20:18:01 GMT. <2D09D61DDFA73D4C884805CC7865E611025315@GAALPA1MSGUSR9N.ITServices.sbc.com> Date: Sat, 28 Jan 2012 16:05:01 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "'v6ops@ietf.org'" , "'pcp@ietf.org'" , "'draft-ietf-v6ops-6204bis@tools.ietf.org'" Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 15:05:09 -0000 In your previous mail you wrote: > I disagree. > I believe the marketplace should determine the winning technology > in this case, if there is to be a winning technology. RFC6204bis > needs to continue to take no position. > > Just because other solutions weren't created by IETF doesn't mean > they are any less good. => +1: if we want to recommend a protocol there is no reason to forget UPnP IGD v2 (to take a solution similar to PCP) or the zillion of other ways to control NAT/Fireall. Regards Francis.Dupont@fdupont.fr From otroan@cisco.com Sat Jan 28 07:52:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF3FF21F8517; Sat, 28 Jan 2012 07:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.136 X-Spam-Level: X-Spam-Status: No, score=-7.136 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kANsukeQRV0w; Sat, 28 Jan 2012 07:52:58 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id D51FE21F850F; Sat, 28 Jan 2012 07:52:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=otroan@cisco.com; l=943; q=dns/txt; s=iport; t=1327765979; x=1328975579; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=OVCHk5xTcvzc82Fmbch4EOx64/coIimXwspag9wohQo=; b=J5ZcX+JSXyCwlVRh3YaXIQx4WvpRZkxf2Cut261/ZvxbhODe7v59DfI0 gXIH/G96BDwHXTZ7mO5RkVnPtgRdYX9Qh+jGwtJvmNwEbbBt8Ahklns3q 5ZFm6cy+8kqsvZZ85qBiEwFNWP00valxzqIiUZkFRZpRVdNhwpkSzQZ0a c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8GAMcYJE+Q/khN/2dsb2JhbABDiVOkFW8CgQWBcgEBAQMBEgEnPxACAQgQCC5XAQEEExsHh1qaRQGeCog7JwYyAQIECQQDA4JwGgIOAgaBKQUFgk5jBJUaklI X-IronPort-AV: E=Sophos;i="4.71,585,1320624000"; d="scan'208";a="64848082" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 28 Jan 2012 15:52:55 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0SFqs4A022015; Sat, 28 Jan 2012 15:52:54 GMT Received: from xmb-ams-112.cisco.com ([144.254.74.87]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 28 Jan 2012 16:52:54 +0100 Received: from 72.163.43.4 ([72.163.43.4]) by XMB-AMS-112.cisco.com ([144.254.74.87]) with Microsoft Exchange Server HTTP-DAV ; Sat, 28 Jan 2012 15:52:54 +0000 References: <201201281505.q0SF51fU007229@givry.fdupont.fr> Content-Transfer-Encoding: quoted-printable From: "Ole Troan (otroan)" Thread-Topic: [v6ops] PCP server in draft-ietf-v6ops-6204bis Content-Type: text/plain; charset="us-ascii" Thread-Index: Aczd1OVhSqM/aXfST86xxkqZYzOe+A== In-Reply-To: <201201281505.q0SF51fU007229@givry.fdupont.fr> Message-ID: <60670B21-C2E8-4E4E-949A-9AD4C8A5F46C@cisco.com> Date: Sat, 28 Jan 2012 16:52:44 +0100 To: "Francis Dupont" MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 28 Jan 2012 15:52:54.0374 (UTC) FILETIME=[E5B7E060:01CCDDD4] X-Mailman-Approved-At: Sat, 28 Jan 2012 08:24:03 -0800 Cc: draft-ietf-v6ops-6204bis@tools.ietf.org, v6ops@ietf.org, pcp@ietf.org Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 16:11:29 -0000 The proposal here is for the protocol between the cpe and the cgn. I wasn't a= ware of other proposals than pcp for that.=20 On the LAN side I expect we need to support all alternatives. The cpe will t= hen have a whatever to pcp proxy.=20 Cheers, Ole On 28 Jan 2012, at 16:05, "Francis Dupont" wrote= : >=20 > In your previous mail you wrote: >=20 >> I disagree.=20 >> I believe the marketplace should determine the winning technology >> in this case, if there is to be a winning technology. RFC6204bis >> needs to continue to take no position. >>=20 >> Just because other solutions weren't created by IETF doesn't mean >> they are any less good. >=20 > =3D> +1: if we want to recommend a protocol there is no reason to > forget UPnP IGD v2 (to take a solution similar to PCP) or the > zillion of other ways to control NAT/Fireall. >=20 > Regards >=20 > Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Sun Jan 29 08:08:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81BFB21F85D6; Sun, 29 Jan 2012 08:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7ksYSEvUYkE; Sun, 29 Jan 2012 08:08:58 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id A472E21F85AC; Sun, 29 Jan 2012 08:08:57 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q0TG8oCF098440; Sun, 29 Jan 2012 17:08:50 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201201291608.q0TG8oCF098440@givry.fdupont.fr> From: Francis Dupont To: "Ole Troan (otroan)" In-reply-to: Your message of Sat, 28 Jan 2012 16:52:44 +0100. <60670B21-C2E8-4E4E-949A-9AD4C8A5F46C@cisco.com> Date: Sun, 29 Jan 2012 17:08:50 +0100 Sender: Francis.Dupont@fdupont.fr Cc: draft-ietf-v6ops-6204bis@tools.ietf.org, v6ops@ietf.org, pcp@ietf.org Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 16:08:58 -0000 In your previous mail you wrote: > The proposal here is for the protocol between the cpe and the > cgn. I wasn't aware of other proposals than pcp for that. => there are already plenty of (far too many according to some :-) protocols providing the control so I believe you'd like to limit the way they work: the CPE-CGN case disqualifies NAT-PMP but UPnP IGD v2 does the job, it was just published after the PCP effort beginning. > On the LAN side I expect we need to support all alternatives. The > cpe will then have a whatever to pcp proxy. => this can raise some security issue when an intermediate node (e.g., a cpe) embeds a NAT and there are more than one, so IMHO we should first determine if the best solution is to put the intelligence in intermediate nodes or to manage arbitrary complexity in end nodes/hosts? Regards Francis.Dupont@fdupont.fr From jhw@apple.com Sun Jan 29 09:51:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64FC321F859B; Sun, 29 Jan 2012 09:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7c-GgRZghCi; Sun, 29 Jan 2012 09:51:53 -0800 (PST) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id E163221F858F; Sun, 29 Jan 2012 09:51:53 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_/EjFAwBgv5Eye98+843R4A)" Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0LYK00MMXMYEFM00@mail-out.apple.com>; Sun, 29 Jan 2012 09:51:53 -0800 (PST) X-AuditID: 1180711d-b7b41ae000004823-3f-4f258738334b Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id 40.58.18467.937852F4; Sun, 29 Jan 2012 09:51:53 -0800 (PST) From: james woodyatt In-reply-to: <201201291608.q0TG8oCF098440@givry.fdupont.fr> Date: Sun, 29 Jan 2012 09:51:52 -0800 Message-id: <85BE2EBF-C8AC-45E1-BF93-1E3066AD3172@apple.com> References: <201201291608.q0TG8oCF098440@givry.fdupont.fr> To: Francis Dupont X-Mailer: Apple Mail (2.1251.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUieJDXQdeyXdXfoG2OmMXNqxdZLB5N28lq 0bbhFYvF5GO/WS1OH9vL7MDqMeX3RlaPd1P/sHosWfKTyePL5c9sASxRXDYpqTmZZalF+nYJ XBnHjh5hLfgsXfF+UkID42aJLkZODgkBE4l/d26wQdhiEhfurQeyuTiEBGYzSdyZfI8RJCEs YC2xt/0RK4jNK2AssebWOxYQm1kgQeLroyawOJuAisS3y3eZQGxOoPqzH3eB1bAIqEq03W9l hKivkFi9aTk7xBwbiUVth8HqhQSsJDY96QCLiwjoSby7epAd4iB5iZavd9gmMPLNQrJ6FpLV ELa2xLKFr5lnMXIA2ToSkxcyogpD2B/PH2FawMi2ilGwKDUnsdLQWC+xoCAnVS85P3cTIyio GwpldzDu/8l/iFGAg1GJh/fkUhV/IdbEsuLK3EOMEhzMSiK8jjOBQrwpiZVVqUX58UWlOanF hxilOViUxHk3WSv7CwmkJ5akZqemFqQWwWSZODilGhjj51qvnXvP8cDMFW4C/40emhtfvTL1 +aL42Sure+MUV1ycd5HJey0TP2/6P9W5WYlsGn+sDv/Q6JjaN+Vc78kdrLnbLfnkra5P19/J dfZI5uqHPi+P3iy4edDZdt3xw3bvKm2fM7me4E0uv79OMObZlpYKlg/Fm+8s+/DW9E3JapeU 3A9qvEt2KrEUZyQaajEXFScCAMd/JlRmAgAA Cc: v6ops@ietf.org, pcp@ietf.org, "Ole Troan \(otroan\)" , draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 17:51:54 -0000 --Boundary_(ID_/EjFAwBgv5Eye98+843R4A) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On Jan 29, 2012, at 08:08 , Francis Dupont wrote: > > UPnP IGD v2 does the job, it was just published after the PCP effort beginning. Was it published under terms that permit IETF to cite it in a standards track document as a normative requirement? This has, in the past, been a problem with UPnP IGDv1. -- j h woodyatt --Boundary_(ID_/EjFAwBgv5Eye98+843R4A) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
UPnP IGD v2 = does the job, it was just published after the PCP = effort beginning.

Was it = published under terms that permit IETF to cite it in a standards track = document as a normative requirement?  This has, in the past, been a = problem with UPnP IGDv1.


--
j h woodyatt <jhw@apple.com>

= --Boundary_(ID_/EjFAwBgv5Eye98+843R4A)-- From brian.e.carpenter@gmail.com Sun Jan 29 14:34:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B84E21F8513 for ; Sun, 29 Jan 2012 14:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.277 X-Spam-Level: X-Spam-Status: No, score=-103.277 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBFOnHxTgoQ6 for ; Sun, 29 Jan 2012 14:34:08 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 889FE21F850F for ; Sun, 29 Jan 2012 14:34:08 -0800 (PST) Received: by eekc1 with SMTP id c1so1196670eek.31 for ; Sun, 29 Jan 2012 14:34:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5RzZahil2DpBhghyUeNm4wROMHrSqn6p/XPWeQfZzhI=; b=Z3AfjCvtJwCVOgwnhiw7VdnTIJ+qm8DrAoQs4cRJNYNGnZdYZto7QkvnBpcSs1HGPI 8LHGg5ZRkj1rJ8rFbNzFX+1xdlzFkXtrt7QJii0L/aOOPf8h9ZeBvgQbFZ7DeW/UUbIf 8vYBFiUp5irYIGc6fF77mnnPewZy5c1elSsSM= Received: by 10.14.13.204 with SMTP id b52mr1762927eeb.24.1327876446131; Sun, 29 Jan 2012 14:34:06 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id c16sm64421164eei.1.2012.01.29.14.34.04 (version=SSLv3 cipher=OTHER); Sun, 29 Jan 2012 14:34:05 -0800 (PST) Message-ID: <4F25C955.8070704@gmail.com> Date: Mon, 30 Jan 2012 11:33:57 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations References: <4F15E499.5040908@gmail.com> In-Reply-To: <4F15E499.5040908@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] [Fwd: I-D Action: draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 22:34:09 -0000 Hi, I'm not seeing more comments on this. The authors would like advice: Should we ask for v6ops to adopt this? Should we ask another WG to adopt it? Should we propose it as an individual submission? Should we forget about it? Regards Brian Carpenter On 2012-01-18 10:14, Brian E Carpenter wrote: > This is a significant update since the version discussed in Taipei, > with an additional author who is a practitioner in the field, > and incorporating comments from implementors. > > Of course we would like more feedback. For the moment I suggest > discussion on the v6ops list, although that may not be the > final home for this draft. > > Please keep Willy on CC since I'm not sure he's on this list. > > Brian Carpenter > > -------- Original Message -------- > Subject: I-D Action: draft-carpenter-v6ops-label-balance-01.txt > Date: Tue, 17 Jan 2012 12:40:05 -0800 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Using the IPv6 Flow Label for Server Load Balancing > Author(s) : Brian Carpenter > Sheng Jiang > Willy Tarreau > Filename : draft-carpenter-v6ops-label-balance-01.txt > Pages : 12 > Date : 2012-01-17 > > This document describes how the IPv6 flow label can be used in > support of layer 3/4 load distribution and balancing for large server > farms. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-label-balance-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-label-balance-01.txt > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > From brian.e.carpenter@gmail.com Sun Jan 29 14:35:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F2621F8528 for ; Sun, 29 Jan 2012 14:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.571 X-Spam-Level: X-Spam-Status: No, score=-103.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rt2a5Y5fDCeq for ; Sun, 29 Jan 2012 14:35:23 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7356921F850F for ; Sun, 29 Jan 2012 14:35:23 -0800 (PST) Received: by eekc1 with SMTP id c1so1196890eek.31 for ; Sun, 29 Jan 2012 14:35:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LTDLZfbBKMt3FFesEYxmyzw60K3EKrJ5WohyYzFWyDI=; b=WeBlkRICWMSKNPUxCH8hB+hb5/q/AAWdjiJ8ixTvzzLGotEFa1tWD/sRlH/8lW9YGB 19ZUTB7xC+2zPksBEMMpatEVy84Yho3vj21NbT9QTOgkfb8/ZV9g3V605ZrY0GbgG37D F0qFGaAv18SO4ViEXw5cQ2l3s7JiG1GkMcJIU= Received: by 10.14.48.8 with SMTP id u8mr1452141eeb.37.1327876522666; Sun, 29 Jan 2012 14:35:22 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id x4sm64412577eeb.4.2012.01.29.14.35.20 (version=SSLv3 cipher=OTHER); Sun, 29 Jan 2012 14:35:22 -0800 (PST) Message-ID: <4F25C9A1.7010209@gmail.com> Date: Mon, 30 Jan 2012 11:35:13 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations References: <4F0B975E.60604@gmail.com> In-Reply-To: <4F0B975E.60604@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] [Fwd: I-D Action: draft-carpenter-v6ops-icp-guidance-02.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 22:35:24 -0000 Still waiting to hear WG opinions on this... On 2012-01-10 14:41, Brian E Carpenter wrote: > Hi, > > We've updated this according to the comments received since Taipei. > > At this point we'd like opinions about the future of the document. > Should it become a WG draft, or should we progress it as an > individual submission? > > Brian > > -------- Original Message -------- > Subject: I-D Action: draft-carpenter-v6ops-icp-guidance-02.txt > Date: Fri, 06 Jan 2012 11:37:09 -0800 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : IPv6 Guidance for Internet Content and Application Service Providers > Author(s) : Brian Carpenter > Sheng Jiang > Filename : draft-carpenter-v6ops-icp-guidance-02.txt > Pages : 16 > Date : 2012-01-06 > > This document provides guidance and suggestions for Internet Content > Providers and Application Service Providers who wish to offer their > service to both IPv6 and IPv4 customers. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-02.txt > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > From Carl.Wuyts@technicolor.com Mon Jan 30 00:05:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE4D21F85FC; Mon, 30 Jan 2012 00:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.158 X-Spam-Level: X-Spam-Status: No, score=-6.158 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyVL1063dxOK; Mon, 30 Jan 2012 00:05:57 -0800 (PST) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by ietfa.amsl.com (Postfix) with ESMTP id CDEBC21F85F7; Mon, 30 Jan 2012 00:05:44 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKTyZPVyAPgPcfFotdy3GHPwM1jD1T3cXa@postini.com; Mon, 30 Jan 2012 00:05:57 PST Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 30 Jan 2012 09:03:39 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.206]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Mon, 30 Jan 2012 09:03:41 +0100 From: Wuyts Carl To: james woodyatt , Francis Dupont Date: Mon, 30 Jan 2012 09:03:38 +0100 Thread-Topic: [v6ops] PCP server in draft-ietf-v6ops-6204bis Thread-Index: AczerrnXT7Ic2xwYQ+K4iDFQAcxmvAAdrdKQ Message-ID: <867F4B6A1672E541A94676D556793ACD0E91F41122@MOPESMBX01.eu.thmulti.com> References: <201201291608.q0TG8oCF098440@givry.fdupont.fr> <85BE2EBF-C8AC-45E1-BF93-1E3066AD3172@apple.com> In-Reply-To: <85BE2EBF-C8AC-45E1-BF93-1E3066AD3172@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_867F4B6A1672E541A94676D556793ACD0E91F41122MOPESMBX01eut_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "pcp@ietf.org" , "Ole Troan \(otroan\)" , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 08:05:58 -0000 --_000_867F4B6A1672E541A94676D556793ACD0E91F41122MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable + 1 on Barbara's statement. V6ops should take no position to select a mech= anism here. PCP seems to get the most attention but it should not make v6o= ps to decide to take it along explicitly in RFC6204bis. Regs Carl From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of j= ames woodyatt Sent: zondag 29 januari 2012 18:52 To: Francis Dupont Cc: v6ops@ietf.org; pcp@ietf.org; Ole Troan (otroan); draft-ietf-v6ops-6204= bis@tools.ietf.org Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis On Jan 29, 2012, at 08:08 , Francis Dupont wrote: UPnP IGD v2 does the job, it was just published after the PCP effort beginn= ing. Was it published under terms that permit IETF to cite it in a standards tra= ck document as a normative requirement? This has, in the past, been a prob= lem with UPnP IGDv1. -- j h woodyatt > --_000_867F4B6A1672E541A94676D556793ACD0E91F41122MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+ 1 on Ba= rbara’s statement.  V6ops should take no position to select a me= chanism here.  PCP seems to get the most attention but it should not m= ake v6ops to decide to take it along explicitly in RFC6204bis.

 

Regs

C= arl

 =

 

From: v6ops-bounces@ietf.org [mailto:v6ops-b= ounces@ietf.org] On Behalf Of james woodyatt
Sent: zondag = 29 januari 2012 18:52
To: Francis Dupont
Cc: v6ops@ietf= .org; pcp@ietf.org; Ole Troan (otroan); draft-ietf-v6ops-6204bis@tools.ietf= .org
Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis<= o:p>

 

=

On Jan 29, 2012, at 08:08 , Francis Dupont w= rote:

 

UPnP IGD v2 does the job, it was just published after = the PCP effort beginning.

 

Was it published under terms that permit IETF to cite it in a standards t= rack document as a normative requirement?  This has, in the past, been= a problem with UPnP IGDv1.

<= br>
=

 

--

j h woodyatt <jhw@apple.com>



 

= --_000_867F4B6A1672E541A94676D556793ACD0E91F41122MOPESMBX01eut_-- From ales.vizdal@t-mobile.cz Mon Jan 30 02:35:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D394B21F84F7 for ; Mon, 30 Jan 2012 02:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTt0Xo2x++8S for ; Mon, 30 Jan 2012 02:35:37 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDEB21F8542 for ; Mon, 30 Jan 2012 02:35:36 -0800 (PST) Received: from srvhk503.rdm.cz (unknown [10.246.143.95]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id A7F552857DA; Mon, 30 Jan 2012 11:35:34 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::2cec:9ace:94f2:601a]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Mon, 30 Jan 2012 11:35:34 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: "STARK, BARBARA H" , Wuyts Carl , Ray Hunter Date: Mon, 30 Jan 2012 11:36:26 +0100 Thread-Topic: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt Thread-Index: AczNOgwqFdWfvcPlShSmwOqFVV6b9QBYC7AAABFgEeAEE0CDgA== Message-ID: <1808340F7EC362469DDFFB112B37E2FCC67E0645D1@SRVHKE02.rdm.cz> References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com><867F4B6A1672E541A94676D556793ACD0CB56952D5@MOPESMBX01.eu.thmulti.com><8FFE15EA-B90E-4553-A776-7C2C5C221852@employees.org><867F4B6A1672E541A94676D556793ACD0CB569536F@MOPESMBX01.eu.thmulti.com><478BBBA2-3D32-4038-A5E4-CD886A417EB8@employees.org><867F4B6A1672E541A94676D556793ACD0CB56953B7@MOPESMBX01.eu.thmulti.com><1E00A66B-B0A3-4FFC-AF0E-ED3A2CACEA60@employees.org><867F4B6A1672E541A94676D556793ACD0CB56953BE@MOPESMBX01.eu.thmulti.com> <750BF7861EBBE048B3E648B4BB6E8F4F21CFE5E5@crexc50p> <4F083E04.5050908@globis.net> <867F4B6A1672E541A94676D556793ACD0CB6819DC3@MOPESMBX01.eu.thmulti.com> <750BF7861EBBE048B3E648B4BB6E8F4F21CFECA1@crexc50p> In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F21CFECA1@crexc50p> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_1808340F7EC362469DDFFB112B37E2FCC67E0645D1SRVHKE02rdmcz_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 10:35:40 -0000 --_000_1808340F7EC362469DDFFB112B37E2FCC67E0645D1SRVHKE02rdmcz_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi, let me comment from a mobile operator perspective. From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of S= TARK, BARBARA H Sent: Monday, January 09, 2012 5:39 PM To: Wuyts Carl; Ray Hunter Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt By actively engaging in the creation of RFC 6204 and 6204bis, the operator = community engaged in this effort has effectively said that: 1. Operators who expect 6204(bis)-compliant CE routers to work with their I= Pv6 access networks won't do things in their IPv6 access networks that will= cause these CE routers not to work. Operators who do not expect these CE r= outers to work in their access networks may well do things that cause these= CE routers not to work in their access networks. It is absolutely true tha= t a 6204(bis)-compliant CE router cannot be expected to work in an environm= ent where it is not expected to work. 2. Operators who expect 6204(bis)-compliant CE routers to establish a nativ= e IPv6 connection with their access networks will send RA. That RA may or m= ay not have a SLAAC ("A") prefix. This includes operators who do PPP. See B= BF TR-187 http://www.broadband-forum.org/technical/download/TR-187.pdf. [Th= ings may change in the future, but that change will have to be coordinated.= ] 3. Operators who expect 6204(bis)-compliant CE routers to establish a nativ= e IPv6 connection with their IPv6 access networks will have a DHCPv6 server= that provides IA_PD and DNS. It may or may not supply IA_NA or other confi= g info. The above listed expectations so far comply with 3GPP networks at the scena= rio setting level. The above operator expectations are implicit in RFC 6204(bis). The requirements tell the CE router that a) If you don't get an RA or a response to DHCPv6 SOLICIT, then you aren't = expected to be able to establish an IPv6 connection with this access networ= k. b) If you get an "A" prefix in the RA, do SLAAC. If you don't get an "A" pr= efix, that's ok. Clearly, the access network doesn't expect you to do SLAAC= if it doesn't send an "A" prefix. If it does send an "A" prefix, then it d= oes expect you to do SLAAC. c) It's OK to always ask for IA_NA. But if M=3D1, then you MUST ask for IA_= NA. If you get an IA_NA offer, take it. If you don't get one, that's ok. If= the access network doesn't offer an IA_NA after you've asked for one (or i= f M=3D0), then clearly it doesn't intend for you to have one. d) Always ask for IA_PD. If you don't get IA_PD, then you aren't expected t= o be able to establish IPv6 connectivity for your LAN. This access network = has no intention of supplying your LAN with IPv6 connectivity. e) If you get IA_PD but no IA_NA and you get RA without "A" prefix, then ta= ke a single address from a /64, and associate it with an interface (not the= WAN interface) where you can use the address for sending/receiving traffic= to/from the LAN/WAN. IMO, the entire rest of the /64 should always be avai= lable for use in the LAN. The "unnumbered" model should never lock up an en= tire prefix. But we don't say that anywhere. So I guess operators can't exp= ect this to be the case. I wouldn't be opposed to either stating that the u= nnumbered model might lock up a /64 prefix, or requiring that it not lock u= p a /64 prefix. But how to not lock up a prefix (if that's required) should= be up to the CE router vendor to implement. The above is actually more or less aligned with 3GPP networks, which is fin= e, except that it does not spell out the exclusion case (as already pointed out on the list earlier, the exclusion case is not 3GPP= specific and could be used in other deployments as well). That means that the delegated prefix in IA_PD might be just half of the res= erved prefix to the subscription, in order for the PGW to be able to do the aggregation of the PDN connection /64 prefix and the d= elegated prefix to a single prefix. So it can work, but for the network to be 'sure' things work right, it has = to waste some address space with the above mentioned work-around. Does the 6204bis design team have a clear view on the OPTION_PD_EXCLUDE as = specified in draft-ietf-dhc-pd-exclude? It's important to understand that if an operator wants these CE routers to = work with their access network, then the operator won't do things that will= cause the device not to work. If an operator doesn't want the CE router to= work with their access network, then you shouldn't expect to be able to cr= eate requirements that will allow the device to work. Operators should expe= ct CE routers to request IA_NA, independent of what the operator puts in th= e RA (M bits, "A" flags). I agree that it's not a good idea for the operato= r to support both SLAAC and IA_NA. And operators know this. Contrary to pop= ular belief, we aren't clueless. While these requirements do not preclude s= tupidity in access network design, operators are working hard (and together= ) to avoid stupid access network design. And we're working with the CE comm= unity to try to make sure that we express (reasonable) expectations for dev= ices to work with the access networks we design. Again, you're absolutely c= orrect that the expectations we've expressed are not intended to ensure tha= t the devices work on access networks of operators that have not been engag= ed in creation of 6204(bis). But I can only assume that such operators have= no interest in such interoperability. Otherwise, they would be here. Barbara Cheers, Ales --_000_1808340F7EC362469DDFFB112B37E2FCC67E0645D1SRVHKE02rdmcz_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

= Hi,

 

let me comment from a mobile opera= tor perspective.

&nbs= p;

From: v6ops-bounces@ietf.org [= mailto:v6ops-bounces@ietf.org] On Behalf Of STARK, BARBARA H
S= ent: Monday, January 09, 2012 5:39 PM
To: Wuyts Carl; Ray Hun= ter
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Fwd: I-D Ac= tion: draft-ietf-v6ops-6204bis-05.txt

 

By actively engaging in the creation of RFC 6204 and 6204bis, the opera= tor community engaged in this effort has effectively said that:<= /span>

1. Operators who expect = 6204(bis)-compliant CE routers to work with their IPv6 access networks won&= #8217;t do things in their IPv6 access networks that will cause these CE ro= uters not to work. Operators who do not expect these CE routers to work in = their access networks may well do things that cause these CE routers not to= work in their access networks. It is absolutely true that a 6204(bis)-comp= liant CE router cannot be expected to work in an environment where it is no= t expected to work.

2. Operators who expect 6204(bis)-compliant CE routers to establish = a native IPv6 connection with their access networks will send RA. That RA m= ay or may not have a SLAAC (“A”) prefix. This includes operator= s who do PPP. See BBF TR-187 http://www.broadband-forum.org/technical/downloa= d/TR-187.pdf. [Things may change in the future, but that change will ha= ve to be coordinated.]

3. Operators who expect 6204(bis)-compliant CE routers to establi= sh a native IPv6 connection with their IPv6 access networks will have a DHC= Pv6 server that provides IA_PD and DNS. It may or may not supply IA_NA or o= ther config info.

 

The above listed expectations so far compl= y with 3GPP networks at the scenario setting level.

 

The above operator expectations are implic= it in RFC 6204(bis).

 

The requirements tell the CE router that

a) If you don’t get an RA or a respo= nse to DHCPv6 SOLICIT, then you aren’t expected to be able to establi= sh an IPv6 connection with this access network.

b) If you get an “A” prefix = in the RA, do SLAAC. If you don’t get an “A” prefix, that= ’s ok. Clearly, the access network doesn’t expect you to do SLA= AC if it doesn’t send an “A” prefix. If it does send an &= #8220;A” prefix, then it does expect you to do SLAAC.

c) It’s OK to always a= sk for IA_NA. But if M=3D1, then you MUST ask for IA_NA. If you get an IA_N= A offer, take it. If you don’t get one, that’s ok. If the acces= s network doesn’t offer an IA_NA after you’ve asked for one (or= if M=3D0), then clearly it doesn’t intend for you to have one.<= /o:p>

d) Always ask for = IA_PD. If you don’t get IA_PD, then you aren’t expected to be a= ble to establish IPv6 connectivity for your LAN. This access network has no= intention of supplying your LAN with IPv6 connectivity. =

e) If you get IA_PD but no IA_= NA and you get RA without “A” prefix, then take a single addres= s from a /64, and associate it with an interface (not the WAN interface) wh= ere you can use the address for sending/receiving traffic to/from the LAN/W= AN. IMO, the entire rest of the /64 should always be available for use in t= he LAN. The “unnumbered” model should never lock up an entire p= refix. But we don’t say that anywhere. So I guess operators can’= ;t expect this to be the case. I wouldn’t be opposed to either statin= g that the unnumbered model might lock up a /64 prefix, or requiring that i= t not lock up a /64 prefix. But how to not lock up a prefix (if that’= s required) should be up to the CE router vendor to implement.

 <= /p>

The above is actually more or l= ess aligned with 3GPP networks, which is fine, except that it does not spel= l out the exclusion case

(as already pointed out on the list earlier, the exclusion case= is not 3GPP specific and could be used in other deployments as well).

 

That means that the de= legated prefix in IA_PD might be just half of the reserved prefix to the su= bscription, in order for the PGW

= to be able to do the aggregation of the PDN connection = /64 prefix and the delegated prefix to a single prefix.

 

So it can work, but for the network to= be 'sure' things work right, it has to waste some address space with the a= bove mentioned work-around.

 

Does the 6204bis design team have a clear view on the OPTION_PD_E= XCLUDE as specified in draft-ietf-dhc-pd-exclude?

 

It’s important to understand that if= an operator wants these CE routers to work with their access network, then= the operator won’t do things that will cause the device not to work.= If an operator doesn’t want the CE router to work with their access = network, then you shouldn’t expect to be able to create requirements = that will allow the device to work. Operators should expect CE routers to r= equest IA_NA, independent of what the operator puts in the RA (M bits, R= 20;A” flags). I agree that it’s not a good idea for the operato= r to support both SLAAC and IA_NA. And operators know this. Contrary to pop= ular belief, we aren’t clueless. While these requirements do not prec= lude stupidity in access network design, operators are working hard (and to= gether) to avoid stupid access network design. And we’re working with= the CE community to try to make sure that we express (reasonable) expectat= ions for devices to work with the access networks we design. Again, youR= 17;re absolutely correct that the expectations we’ve expressed are no= t intended to ensure that the devices work on access networks of operators = that have not been engaged in creation of 6204(bis). But I can only assume = that such operators have no interest in such interoperability. Otherwise, t= hey would be here.

Barbara

 

Cheers,

Ales

= --_000_1808340F7EC362469DDFFB112B37E2FCC67E0645D1SRVHKE02rdmcz_-- From Carl.Wuyts@technicolor.com Mon Jan 30 04:47:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4779F21F8567 for ; Mon, 30 Jan 2012 04:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ue-9SPGNJWrb for ; Mon, 30 Jan 2012 04:47:24 -0800 (PST) Received: from na3sys009aog106.obsmtp.com (na3sys009aob106.obsmtp.com [74.125.149.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7F421F852D for ; Mon, 30 Jan 2012 04:47:15 -0800 (PST) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKTyaRUBXThhh+rVXqucw64Fgx7xJjLLBP@postini.com; Mon, 30 Jan 2012 04:47:20 PST Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 30 Jan 2012 13:45:11 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.206]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Mon, 30 Jan 2012 13:45:11 +0100 From: Wuyts Carl To: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= , "STARK, BARBARA H" , Ray Hunter Date: Mon, 30 Jan 2012 13:45:09 +0100 Thread-Topic: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt Thread-Index: AczNOgwqFdWfvcPlShSmwOqFVV6b9QBYC7AAABFgEeAEE0CDgAAH5QtA Message-ID: <867F4B6A1672E541A94676D556793ACD0E91F412D6@MOPESMBX01.eu.thmulti.com> References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com><867F4B6A1672E541A94676D556793ACD0CB56952D5@MOPESMBX01.eu.thmulti.com><8FFE15EA-B90E-4553-A776-7C2C5C221852@employees.org><867F4B6A1672E541A94676D556793ACD0CB569536F@MOPESMBX01.eu.thmulti.com><478BBBA2-3D32-4038-A5E4-CD886A417EB8@employees.org><867F4B6A1672E541A94676D556793ACD0CB56953B7@MOPESMBX01.eu.thmulti.com><1E00A66B-B0A3-4FFC-AF0E-ED3A2CACEA60@employees.org><867F4B6A1672E541A94676D556793ACD0CB56953BE@MOPESMBX01.eu.thmulti.com> <750BF7861EBBE048B3E648B4BB6E8F4F21CFE5E5@crexc50p> <4F083E04.5050908@globis.net> <867F4B6A1672E541A94676D556793ACD0CB6819DC3@MOPESMBX01.eu.thmulti.com> <750BF7861EBBE048B3E648B4BB6E8F4F21CFECA1@crexc50p> <1808340F7EC362469DDFFB112B37E2FCC67E0645D1@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC67E0645D1@SRVHKE02.rdm.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_867F4B6A1672E541A94676D556793ACD0E91F412D6MOPESMBX01eut_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 12:47:28 -0000 --_000_867F4B6A1672E541A94676D556793ACD0E91F412D6MOPESMBX01eut_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Nice overview Ales. Just want to add that I have nothing against the below statements, I fully = support them, however, as you mention below requesting IA_NA should be expe= cted by every operator, but the thing is that it should not be depending on= check X, Y and Z prior of doing that. Just request/don't request, and get= / don't get it back, perfectly fine. WRT to the fact that some operators explicitly don't want to sent RA on PPP= links. We can cope with those too, no worries, however, I was just warnin= g about the fact that this happens in real life, not that is should be done= like that or not. Is it "stupid" ? I don't know, whoami to judge ? Sam= e goes for DAD on PPP links: do or don't ? Regs Carl Hi, let me comment from a mobile operator perspective. From: v6ops-bounces@ietf.org [mailto:v6ops-b= ounces@ietf.org] On Behalf Of STARK, BARBARA H Sent: Monday, January 09, 2012 5:39 PM To: Wuyts Carl; Ray Hunter Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt By actively engaging in the creation of RFC 6204 and 6204bis, the operator = community engaged in this effort has effectively said that: 1. Operators who expect 6204(bis)-compliant CE routers to work with their I= Pv6 access networks won't do things in their IPv6 access networks that will= cause these CE routers not to work. Operators who do not expect these CE r= outers to work in their access networks may well do things that cause these= CE routers not to work in their access networks. It is absolutely true tha= t a 6204(bis)-compliant CE router cannot be expected to work in an environm= ent where it is not expected to work. 2. Operators who expect 6204(bis)-compliant CE routers to establish a nativ= e IPv6 connection with their access networks will send RA. That RA may or m= ay not have a SLAAC ("A") prefix. This includes operators who do PPP. See B= BF TR-187 http://www.broadband-forum.org/technical/download/TR-187.pdf. [Th= ings may change in the future, but that change will have to be coordinated.= ] 3. Operators who expect 6204(bis)-compliant CE routers to establish a nativ= e IPv6 connection with their IPv6 access networks will have a DHCPv6 server= that provides IA_PD and DNS. It may or may not supply IA_NA or other confi= g info. The above listed expectations so far comply with 3GPP networks at the scena= rio setting level. The above operator expectations are implicit in RFC 6204(bis). The requirements tell the CE router that a) If you don't get an RA or a response to DHCPv6 SOLICIT, then you aren't = expected to be able to establish an IPv6 connection with this access networ= k. b) If you get an "A" prefix in the RA, do SLAAC. If you don't get an "A" pr= efix, that's ok. Clearly, the access network doesn't expect you to do SLAAC= if it doesn't send an "A" prefix. If it does send an "A" prefix, then it d= oes expect you to do SLAAC. c) It's OK to always ask for IA_NA. But if M=3D1, then you MUST ask for IA_= NA. If you get an IA_NA offer, take it. If you don't get one, that's ok. If= the access network doesn't offer an IA_NA after you've asked for one (or i= f M=3D0), then clearly it doesn't intend for you to have one. d) Always ask for IA_PD. If you don't get IA_PD, then you aren't expected t= o be able to establish IPv6 connectivity for your LAN. This access network = has no intention of supplying your LAN with IPv6 connectivity. e) If you get IA_PD but no IA_NA and you get RA without "A" prefix, then ta= ke a single address from a /64, and associate it with an interface (not the= WAN interface) where you can use the address for sending/receiving traffic= to/from the LAN/WAN. IMO, the entire rest of the /64 should always be avai= lable for use in the LAN. The "unnumbered" model should never lock up an en= tire prefix. But we don't say that anywhere. So I guess operators can't exp= ect this to be the case. I wouldn't be opposed to either stating that the u= nnumbered model might lock up a /64 prefix, or requiring that it not lock u= p a /64 prefix. But how to not lock up a prefix (if that's required) should= be up to the CE router vendor to implement. The above is actually more or less aligned with 3GPP networks, which is fin= e, except that it does not spell out the exclusion case (as already pointed out on the list earlier, the exclusion case is not 3GPP= specific and could be used in other deployments as well). That means that the delegated prefix in IA_PD might be just half of the res= erved prefix to the subscription, in order for the PGW to be able to do the aggregation of the PDN connection /64 prefix and the d= elegated prefix to a single prefix. So it can work, but for the network to be 'sure' things work right, it has = to waste some address space with the above mentioned work-around. Does the 6204bis design team have a clear view on the OPTION_PD_EXCLUDE as = specified in draft-ietf-dhc-pd-exclude? It's important to understand that if an operator wants these CE routers to = work with their access network, then the operator won't do things that will= cause the device not to work. If an operator doesn't want the CE router to= work with their access network, then you shouldn't expect to be able to cr= eate requirements that will allow the device to work. Operators should expe= ct CE routers to request IA_NA, independent of what the operator puts in th= e RA (M bits, "A" flags). I agree that it's not a good idea for the operato= r to support both SLAAC and IA_NA. And operators know this. Contrary to pop= ular belief, we aren't clueless. While these requirements do not preclude s= tupidity in access network design, operators are working hard (and together= ) to avoid stupid access network design. And we're working with the CE comm= unity to try to make sure that we express (reasonable) expectations for dev= ices to work with the access networks we design. Again, you're absolutely c= orrect that the expectations we've expressed are not intended to ensure tha= t the devices work on access networks of operators that have not been engag= ed in creation of 6204(bis). But I can only assume that such operators have= no interest in such interoperability. Otherwise, they would be here. Barbara Cheers, Ales --_000_867F4B6A1672E541A94676D556793ACD0E91F412D6MOPESMBX01eut_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

= Nice overview Ales.

Just want to add that I have nothing against the below statements, I full= y support them, however, as you mention below requesting IA_NA should be ex= pected by every operator, but the thing is that it should not be depending = on check X, Y and Z prior of doing that.=A0 Just request/don’t reques= t, and get / don’t get it back, perfectly fine.

=

WRT to the fact that some operators explicitly = don’t want to sent RA on PPP links.=A0 We can cope with those too, no= worries, however, I was just warning about the fact that this happens in r= eal life, not that is should be done like that or not.=A0 Is it “stup= id” ?=A0 I don’t know, whoami to judge ?=A0=A0 Same goes for DA= D on PPP links: do or don’t=A0 ?

 

Regs

Carl

 

Hi,

 

let = me comment from a mobile operator perspective.

 

<= div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0= cm 0cm'>

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Beha= lf Of STARK, BARBARA H
Sent: Monday, January 09, 2012 5:39 PM=
To: Wuyts Carl; Ray Hunter
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Fwd: I-D Actio= n: draft-ietf-v6ops-6204bis-05.txt

 

By actively engaging in the creation of RFC 6204 and 6204bis,= the operator community engaged in this effort has effectively said that:

1. Operators who expect 620= 4(bis)-compliant CE routers to work with their IPv6 access networks wonR= 17;t do things in their IPv6 access networks that will cause these CE route= rs not to work. Operators who do not expect these CE routers to work in the= ir access networks may well do things that cause these CE routers not to wo= rk in their access networks. It is absolutely true that a 6204(bis)-complia= nt CE router cannot be expected to work in an environment where it is not e= xpected to work.

2. Operat= ors who expect 6204(bis)-compliant CE routers to establish a native IPv6 co= nnection with their access networks will send RA. That RA may or may not ha= ve a SLAAC (“A”) prefix. This includes operators who do PPP. Se= e BBF TR-187 http://www.broadband-forum.org/technical/download/TR-187.pdf= . [Things may change in the future, but that change will have to be coordin= ated.]

3. Operators who ex= pect 6204(bis)-compliant CE routers to establish a native IPv6 connection w= ith their IPv6 access networks will have a DHCPv6 server that provides IA_P= D and DNS. It may or may not supply IA_NA or other config info.<= /span>

 

The above listed expectations so far comply with 3= GPP networks at the scenario setting level.

 

The above operator expectations are implicit in RFC 6204(bis).<= /span>

 

The requirements tell the CE router that

a) If you don’t get an RA or a res= ponse to DHCPv6 SOLICIT, then you aren’t expected to be able to estab= lish an IPv6 connection with this access network.

b) If you get an “A” prefix in the RA, = do SLAAC. If you don’t get an “A” prefix, that’s ok= . Clearly, the access network doesn’t expect you to do SLAAC if it do= esn’t send an “A” prefix. If it does send an “AR= 21; prefix, then it does expect you to do SLAAC.

c) It’s OK to always ask for IA_NA. But if M= =3D1, then you MUST ask for IA_NA. If you get an IA_NA offer, take it. If y= ou don’t get one, that’s ok. If the access network doesn’= t offer an IA_NA after you’ve asked for one (or if M=3D0), then clear= ly it doesn’t intend for you to have one.

d) Always ask for IA_PD. If you don’t get IA_PD= , then you aren’t expected to be able to establish IPv6 connectivity = for your LAN. This access network has no intention of supplying your LAN wi= th IPv6 connectivity.

e) = If you get IA_PD but no IA_NA and you get RA without “A” prefix= , then take a single address from a /64, and associate it with an interface= (not the WAN interface) where you can use the address for sending/receivin= g traffic to/from the LAN/WAN. IMO, the entire rest of the /64 should alway= s be available for use in the LAN. The “unnumbered” model shoul= d never lock up an entire prefix. But we don’t say that anywhere. So = I guess operators can’t expect this to be the case. I wouldn’t = be opposed to either stating that the unnumbered model might lock up a /64 = prefix, or requiring that it not lock up a /64 prefix. But how to not lock = up a prefix (if that’s required) should be up to the CE router vendor= to implement.

 =

The above is actually more or = less aligned with 3GPP networks, which is fine, except that it does not spe= ll out the exclusion case

= (as already pointed out on the list earlier, the exclusion case is not 3GPP= specific and could be used in other deployments as well).

 

That means that the delegated prefix in IA_PD might be just = half of the reserved prefix to the subscription, in order for the PGW<= /o:p>

to be able to do the aggregatio= n of the PDN connection /64 prefix and the delegated prefix to a single pre= fix.

 

So it can work, but for the network to b= e 'sure' things work right, it has to waste some address space with the abo= ve mentioned work-around.

=  

Does the 6204bis de= sign team have a clear view on the OPTION_PD_EXCLUDE as specified in draft-= ietf-dhc-pd-exclude?

 

It’s important to= understand that if an operator wants these CE routers to work with their a= ccess network, then the operator won’t do things that will cause the = device not to work. If an operator doesn’t want the CE router to work= with their access network, then you shouldn’t expect to be able to c= reate requirements that will allow the device to work. Operators should exp= ect CE routers to request IA_NA, independent of what the operator puts in t= he RA (M bits, “A” flags). I agree that it’s not a good i= dea for the operator to support both SLAAC and IA_NA. And operators know th= is. Contrary to popular belief, we aren’t clueless. While these requi= rements do not preclude stupidity in access network design, operators are w= orking hard (and together) to avoid stupid access network design. And we= 217;re working with the CE community to try to make sure that we express (r= easonable) expectations for devices to work with the access networks we des= ign. Again, you’re absolutely correct that the expectations we’= ve expressed are not intended to ensure that the devices work on access net= works of operators that have not been engaged in creation of 6204(bis). But= I can only assume that such operators have no interest in such interoperab= ility. Otherwise, they would be here.

Barbara

 

Cheers,

Ales

= --_000_867F4B6A1672E541A94676D556793ACD0E91F412D6MOPESMBX01eut_-- From jhw@apple.com Mon Jan 30 11:16:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB82321F8540; Mon, 30 Jan 2012 11:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, SARE_BAYES_5x7=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjMfWKc74yOm; Mon, 30 Jan 2012 11:16:52 -0800 (PST) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 4E12221F853F; Mon, 30 Jan 2012 11:16:52 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0LYM00MQILIU3F91@mail-out.apple.com>; Mon, 30 Jan 2012 11:16:25 -0800 (PST) X-AuditID: 11807137-b7b2fae00000523c-42-4f26ec88585e Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id A8.7B.21052.98CE62F4; Mon, 30 Jan 2012 11:16:25 -0800 (PST) From: james woodyatt In-reply-to: <867F4B6A1672E541A94676D556793ACD0E91F41122@MOPESMBX01.eu.thmulti.com> Date: Mon, 30 Jan 2012 11:16:24 -0800 Content-transfer-encoding: quoted-printable Message-id: <0E34E6A5-ADB8-4634-9152-902C2D983EA8@apple.com> References: <201201291608.q0TG8oCF098440@givry.fdupont.fr> <85BE2EBF-C8AC-45E1-BF93-1E3066AD3172@apple.com> <867F4B6A1672E541A94676D556793ACD0E91F41122@MOPESMBX01.eu.thmulti.com> To: draft-ietf-v6ops-6204bis@tools.ietf.org X-Mailer: Apple Mail (2.1251.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUieJDXQbfzjZq/QctmAYubVy+yWEw+9pvV 4vSxvcwOzB5Llvxk8vhy+TNbAFMUl01Kak5mWWqRvl0CV8b25u8sBSs5Kna+ymlgPMLWxcjJ ISFgInFvxTlGCFtM4sK99UBxLg4hgdlMEhcam8CKhAWsJfa2P2IFsXkFjCXW3HrHAmIzC+hJ 7Lj+CyzOJqAi8e3yXaYuRg4OToFgiYU/80HCLAKqElOW7GGCKLeS2L7sOlSrtsSyha+ZIUba SFxaOpEdYu8mRokjd76DzRQBKpp29AQrxHHyEi1f77BNYOSfheSMWUjOmIVk7gJG5lWMgkWp OYmVhmZ6iQUFOal6yfm5mxhB4ddQaL6DcftfuUOMAhyMSjy8P3+r+guxJpYVV+YeYpTgYFYS 4X2zWs1fiDclsbIqtSg/vqg0J7X4EKM0B4uSOO82a2V/IYH0xJLU7NTUgtQimCwTB6dUA2P8 +y273k2UzT91gEfpsGSa08ce6YgOywnlPe0enBN4Nr/eW8b4tDLr311OZukpPWcCN5bYVH9U i/SVdV0R8eJ0XoJ++4UDai7fjzq6ny+68j9OYLkKt8NV/h0b1v+bPf/Pi2Cdsvx2iX//HmzS /VakaixtIcq7bKn4r2Ln9I4dRzbxSAde5FNiKc5INNRiLipOBACwJKeCOwIAAA== Cc: IPv6 Operations , PCP Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 19:16:52 -0000 On Jan 30, 2012, at 24:03 , Wuyts Carl wrote: > + 1 on Barbara=92s statement. V6ops should take no position to select = a mechanism here. PCP seems to get the most attention but it should not = make v6ops to decide to take it along explicitly in RFC6204bis. I vigorously disagree with the reasoning in these statements. If IETF cannot bring itself, in RFC 6204bis, to "require" its own = standard protocol, which was intended for meeting REC-48 in RFC 6092, = then I don't see why we should keep S-1 at all. Put another way: if we believe there should be no standard mechanism in = IPv6 CE routers for "host applications to solicit inbound traffic = without advance knowledge of the addresses of exterior nodes with which = they expect to communicate" then why do we believe that IPv6 CE routers = should implement RFC 6092? I am NOT just ranting here. This is a very serious question, and I = would like the working group to address it. I would very much like to = see serious answers given. -- j h woodyatt From Francis.Dupont@fdupont.fr Mon Jan 30 11:36:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7ED11E8093; Mon, 30 Jan 2012 11:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1O+KN6+DQyyt; Mon, 30 Jan 2012 11:36:23 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 832BD11E8081; Mon, 30 Jan 2012 11:36:23 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q0UJaEft000156; Mon, 30 Jan 2012 20:36:14 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201201301936.q0UJaEft000156@givry.fdupont.fr> From: Francis Dupont To: james woodyatt In-reply-to: Your message of Sun, 29 Jan 2012 09:51:52 PST. <85BE2EBF-C8AC-45E1-BF93-1E3066AD3172@apple.com> Date: Mon, 30 Jan 2012 20:36:14 +0100 Sender: Francis.Dupont@fdupont.fr Cc: v6ops@ietf.org, pcp@ietf.org, "Ole Troan \(otroan\)" , draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 19:36:24 -0000 In your previous mail you wrote: > > UPnP IGD v2 does the job, it was just published after the PCP > > effort beginning. > > Was it published under terms that permit IETF to cite it in a > standards track document as a normative requirement? This has, in > the past, been a problem with UPnP IGDv1. => I am not a lawyer so I can't say... but the text of the standard is freely available (in all meanings of the word 'free') so at least one can make its own opinion. Regards Francis.Dupont@fdupont.fr From bs7652@att.com Mon Jan 30 11:59:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8760B21F850D for ; Mon, 30 Jan 2012 11:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxMDBc5ZY4Zk for ; Mon, 30 Jan 2012 11:59:05 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id B55C121F84F2 for ; Mon, 30 Jan 2012 11:59:04 -0800 (PST) X-Env-Sender: bs7652@att.com X-Msg-Ref: server-4.tower-119.messagelabs.com!1327953542!13136646!1 X-Originating-IP: [144.160.20.146] X-StarScan-Version: 6.4.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21751 invoked from network); 30 Jan 2012 19:59:03 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-4.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Jan 2012 19:59:03 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q0UJvVRp007751; Mon, 30 Jan 2012 14:57:31 -0500 Received: from sflint03.pst.cso.att.com (sflint03.pst.cso.att.com [144.154.234.230]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q0UJvQZ0007644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jan 2012 14:57:27 -0500 Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (gaalpa1msghub9e.itservices.sbc.com [130.8.36.91]) by sflint03.pst.cso.att.com (RSA Interceptor); Mon, 30 Jan 2012 14:58:41 -0500 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([169.254.6.206]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.01.0355.002; Mon, 30 Jan 2012 14:58:41 -0500 From: "STARK, BARBARA H" To: Francis Dupont , james woodyatt Thread-Topic: [v6ops] PCP server in draft-ietf-v6ops-6204bis Thread-Index: AQHM34Zty/cRV1j9DUSbChwVr26jwZYlUQmQ Date: Mon, 30 Jan 2012 19:58:40 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611025B49@GAALPA1MSGUSR9N.ITServices.sbc.com> References: Your message of Sun, 29 Jan 2012 09:51:52 PST. <85BE2EBF-C8AC-45E1-BF93-1E3066AD3172@apple.com> <201201301936.q0UJaEft000156@givry.fdupont.fr> In-Reply-To: <201201301936.q0UJaEft000156@givry.fdupont.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.169.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Cc: "v6ops@ietf.org" , "Ole Troan \(otroan\)" , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 19:59:05 -0000 To come at this from a procedural angle, then... With the advent of the homenet WG, I thought we agreed that we would not ma= ke any attempt to address new additional LAN technology recommendations in = a 6204bis document. We said 6204bis would only try to deal with WAN-side tr= ansition technologies, and other "fix existing 6204 recommendations, becaus= e now we know better" changes. Recommending PCP as a LAN technology is, IMO, a homenet issue. It has no pl= ace in 6204bis. PCP as a WAN technology that some want to see used in conjunction with IPv4= /IPv6 transition mechanisms that put an IPv4 CGN in the access network, is,= IMO, a reasonable addition to 6204bis (as a SHOULD, which I think is what = proposed verbiage has).=20 Barbara > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Francis Dupont > Sent: Monday, January 30, 2012 2:36 PM > To: james woodyatt > Cc: v6ops@ietf.org; pcp@ietf.org; Ole Troan (otroan); draft-ietf-v6ops- > 6204bis@tools.ietf.org > Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis >=20 > In your previous mail you wrote: >=20 > > > UPnP IGD v2 does the job, it was just published after the PCP > > > effort beginning. > > > > Was it published under terms that permit IETF to cite it in a > > standards track document as a normative requirement? This has, in > > the past, been a problem with UPnP IGDv1. >=20 > =3D> I am not a lawyer so I can't say... but the text of the standard > is freely available (in all meanings of the word 'free') so at least > one can make its own opinion. >=20 > Regards >=20 > Francis.Dupont@fdupont.fr > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jhw@apple.com Mon Jan 30 12:17:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53AFC21F84F7; Mon, 30 Jan 2012 12:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.998 X-Spam-Level: X-Spam-Status: No, score=-109.998 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Su2YZ7O0+B69; Mon, 30 Jan 2012 12:17:14 -0800 (PST) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 92D9821F84C9; Mon, 30 Jan 2012 12:17:14 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_2E1OyrqytBL2F0MU9bXWkw)" Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0LYM00KCEOCFPUK1@mail-out.apple.com>; Mon, 30 Jan 2012 12:17:14 -0800 (PST) X-AuditID: 11807136-b7c60ae000007a90-bb-4f26fac93ef7 Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id B1.54.31376.9CAF62F4; Mon, 30 Jan 2012 12:17:13 -0800 (PST) From: james woodyatt In-reply-to: <2D09D61DDFA73D4C884805CC7865E611025B49@GAALPA1MSGUSR9N.ITServices.sbc.com> Date: Mon, 30 Jan 2012 12:17:13 -0800 Message-id: <4A687585-399D-4077-91AC-A1DC4F101E03@apple.com> References: "29 Jan 2012 09:51:52 PST." <85BE2EBF-C8AC-45E1-BF93-1E3066AD3172@apple.com> <201201301936.q0UJaEft000156@givry.fdupont.fr> <2D09D61DDFA73D4C884805CC7865E611025B49@GAALPA1MSGUSR9N.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1251.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUieJDXQffkLzV/g4YWa4tJf38yWty8epHF YvKx36wWp4/tZXZg8XjZP4fRY8mSn0weXy5/ZgtgjuKySUnNySxLLdK3S+DKODf7EkvBWa2K fe0bWRoYN6p0MXJySAiYSMx795ERwhaTuHBvPVsXIxeHkMBsJonbdxtYQBLCAtYSe9sfsYLY vALGEmtuvQOLMwskSPzsmcEMYrMJqEh8u3yXCcTmFIiQWDV7N1g9i4CqxPPX7awQ9akSG+9e Y4eYYyMxqec7E8Syy4wSve0/wYpEBNQlVk2bzgpxkbxEy9c7bBMY+WYh2T0LyW4IW1ti2cLX QDYHkK0jMXkhI6owhP3x/BGmBYxsqxgFi1JzEisNTfUSCwpyUvWS83M3MYKCuKHQbAfjjr9y hxgFOBiVeHh3vFfzF2JNLCuuzD3EKMHBrCTC+2Y1UIg3JbGyKrUoP76oNCe1+BCjNAeLkjjv VmtlfyGB9MSS1OzU1ILUIpgsEwenVAMjc9CqQzt5FK49W991lk+RN67RoXnzQ6a7EdHny4tK N5suU972K/NpEcOEY08S5j0NljqZ9OPxav1zfouWq3zN2p3udjzIzGY7i3rDHulwjytt8+Y0 9WbddPKoP+x185XuRFv5jb1Zr9YI3dikba229XBSnpF/XmsJl6fRivO3VAP3+TeeX6anxFKc kWioxVxUnAgAgJHXyF4CAAA= Cc: IPv6 Operations , PCP , draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 20:17:15 -0000 --Boundary_(ID_2E1OyrqytBL2F0MU9bXWkw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On Jan 30, 2012, at 11:58 , STARK, BARBARA H wrote: > > To come at this from a procedural angle, then... > > With the advent of the homenet WG, I thought we agreed that we would not make any attempt to address new additional LAN technology recommendations in a 6204bis document. We said 6204bis would only try to deal with WAN-side transition technologies, and other "fix existing 6204 recommendations, because now we know better" changes. > > Recommending PCP as a LAN technology is, IMO, a homenet issue. It has no place in 6204bis. This reasoning applies just as well to the recommendation of RFC 6092 Simple Security, which is about protecting LAN hosts according to local network policy. If recommending a PCP server is for HOMENET to do, and it has no place in RFC 6204bis from V6OPS, then recommending RFC 6092 Simple Security neither has any place in RFC 6204bis and it should therefore be removed, and a notice inserted into RFC 6204bis to explain why the previous document was in error and to note that forthcoming documents from HOMENET will address the issue properly. I would very much like to get a better understanding of how you are reasoning on this issue. -- j h woodyatt --Boundary_(ID_2E1OyrqytBL2F0MU9bXWkw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
To come at = this from a procedural angle, then...

With the advent of the = homenet WG, I thought we agreed that we would not make any attempt to = address new additional LAN technology recommendations in a 6204bis = document. We said 6204bis would only try to deal with WAN-side = transition technologies, and other "fix existing 6204 recommendations, = because now we know better" changes.

Recommending PCP as a LAN = technology is, IMO, a homenet issue. It has no place in = 6204bis.

This reasoning = applies just as well to the recommendation of RFC 6092 Simple Security, = which is about protecting LAN hosts according to local network = policy.

If recommending a PCP server is for HOMENET = to do, and it has no place in RFC 6204bis from V6OPS, then recommending = RFC 6092 Simple Security neither has any place in RFC 6204bis and it = should therefore be removed, and a notice inserted into RFC 6204bis to = explain why the previous document was in error and to note that = forthcoming documents from HOMENET will address the issue = properly.

I = would very much like to get a better understanding of how you are = reasoning on this issue.


--
j h woodyatt <jhw@apple.com>

= --Boundary_(ID_2E1OyrqytBL2F0MU9bXWkw)-- From bs7652@att.com Mon Jan 30 13:00:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD37E1F0C4A for ; Mon, 30 Jan 2012 13:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYDx6Hz-T89O for ; Mon, 30 Jan 2012 13:00:02 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3361F0C41 for ; Mon, 30 Jan 2012 13:00:02 -0800 (PST) X-Env-Sender: bs7652@att.com X-Msg-Ref: server-11.tower-120.messagelabs.com!1327957200!61255489!1 X-Originating-IP: [144.160.20.146] X-StarScan-Version: 6.4.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30211 invoked from network); 30 Jan 2012 21:00:01 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-11.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Jan 2012 21:00:01 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q0UKwS2X009691; Mon, 30 Jan 2012 15:58:30 -0500 Received: from sflint03.pst.cso.att.com (sflint03.pst.cso.att.com [144.154.234.230]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q0UKwOvG009535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jan 2012 15:58:24 -0500 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (gaalpa1msghub9c.itservices.sbc.com [130.8.36.89]) by sflint03.pst.cso.att.com (RSA Interceptor); Mon, 30 Jan 2012 15:59:47 -0500 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([169.254.6.206]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.01.0355.002; Mon, 30 Jan 2012 15:59:47 -0500 From: "STARK, BARBARA H" To: james woodyatt Thread-Topic: [v6ops] PCP server in draft-ietf-v6ops-6204bis Thread-Index: AQHM34Zty/cRV1j9DUSbChwVr26jwZYlUQmQgABcCYD//65DsA== Date: Mon, 30 Jan 2012 20:59:46 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611025BFE@GAALPA1MSGUSR9N.ITServices.sbc.com> References: "29 Jan 2012 09:51:52 PST." <85BE2EBF-C8AC-45E1-BF93-1E3066AD3172@apple.com> <201201301936.q0UJaEft000156@givry.fdupont.fr> <2D09D61DDFA73D4C884805CC7865E611025B49@GAALPA1MSGUSR9N.ITServices.sbc.com> <4A687585-399D-4077-91AC-A1DC4F101E03@apple.com> In-Reply-To: <4A687585-399D-4077-91AC-A1DC4F101E03@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.169.165] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E611025BFEGAALPA1MSGUSR9NIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Cc: IPv6 Operations , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 21:00:04 -0000 --_000_2D09D61DDFA73D4C884805CC7865E611025BFEGAALPA1MSGUSR9NIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The reference to RFC 6092 is in RFC 6204, which was published prior to home= net's creation. Unless the reference to 6092 is truly an error, then we don't need to be di= scussing changes to its recommendation (removal, updates, enhancements) in = 6204bis. It continues as it was. 6204bis has tried to leave LAN elements of= 6204 untouched. They were fully and appropriately discussed with consensus= agreement to include them, at the time of 6204. And so they remain, unless= there is a problem. If you believe that inclusion of 6092 as a "SHOULD" is truly an error, then= I would like to understand why you think that. If there exists proof that = it's harmful (I've heard some people say that having it enabled by default = has caused some problems, so perhaps there is such proof), then maybe we sh= ould reconsider its inclusion. If you're suggesting its removal because the= topic is no longer under the charter of v6ops, then I disagree. We didn't = say that we wanted to pull out LAN elements when doing 6204bis. We said we = didn't want to do anything with them, at all (unless they have proven to be= a true mistake). Removing the reference to 6092 would be inconsistent with= an attempt to make no "LAN functionality" changes to 6204, when creating 6= 204bis. I would only support it if it were shown to be truly harmful. Barbara From: james woodyatt [mailto:jhw@apple.com] Sent: Monday, January 30, 2012 3:17 PM To: STARK, BARBARA H Cc: PCP; IPv6 Operations; draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis On Jan 30, 2012, at 11:58 , STARK, BARBARA H wrote: To come at this from a procedural angle, then... With the advent of the homenet WG, I thought we agreed that we would not ma= ke any attempt to address new additional LAN technology recommendations in = a 6204bis document. We said 6204bis would only try to deal with WAN-side tr= ansition technologies, and other "fix existing 6204 recommendations, becaus= e now we know better" changes. Recommending PCP as a LAN technology is, IMO, a homenet issue. It has no pl= ace in 6204bis. This reasoning applies just as well to the recommendation of RFC 6092 Simpl= e Security, which is about protecting LAN hosts according to local network = policy. If recommending a PCP server is for HOMENET to do, and it has no place in R= FC 6204bis from V6OPS, then recommending RFC 6092 Simple Security neither h= as any place in RFC 6204bis and it should therefore be removed, and a notic= e inserted into RFC 6204bis to explain why the previous document was in err= or and to note that forthcoming documents from HOMENET will address the iss= ue properly. I would very much like to get a better understanding of how you are reasoni= ng on this issue. -- j h woodyatt > --_000_2D09D61DDFA73D4C884805CC7865E611025BFEGAALPA1MSGUSR9NIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The reference to RFC 6092= is in RFC 6204, which was published prior to homenet’s creation.

 <= /p>

Unless the reference to 6= 092 is truly an error, then we don’t need to be discussing changes to= its recommendation (removal, updates, enhancements) in 6204bis. It continues as it was. 6204bis has tried to leave LAN elements of 6204 un= touched. They were fully and appropriately discussed with consensus agreeme= nt to include them, at the time of 6204. And so they remain, unless there i= s a problem.

 <= /p>

If you believe that inclu= sion of 6092 as a “SHOULD” is truly an error, then I would like= to understand why you think that. If there exists proof that it’s ha= rmful (I’ve heard some people say that having it enabled by default has ca= used some problems, so perhaps there is such proof), then maybe we should r= econsider its inclusion. If you’re suggesting its removal because the= topic is no longer under the charter of v6ops, then I disagree. We didn’t say that we wanted to pull out LAN elemen= ts when doing 6204bis. We said we didn’t want to do anything with the= m, at all (unless they have proven to be a true mistake). Removing the refe= rence to 6092 would be inconsistent with an attempt to make no “LAN functionality” changes to 6204, when c= reating 6204bis. I would only support it if it were shown to be truly harmf= ul.

 <= /p>

Barbara=

 <= /p>

From: james wo= odyatt [mailto:jhw@apple.com]
Sent: Monday, January 30, 2012 3:17 PM
To: STARK, BARBARA H
Cc: PCP; IPv6 Operations; draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis

 

On Jan 30, 2012, at 11:58 , STARK, BARBARA H wrote:<= o:p>

 

To c= ome at this from a procedural angle, then...
With the advent of the homenet WG, I thoug= ht we agreed that we would not make any attempt to address new additional L= AN technology recommendations in a 6204bis document. We said 6204bis would = only try to deal with WAN-side transition technologies, and other "fix existing 6204 recommendations, because n= ow we know better" changes.

Recommending PCP as a LAN technology is, I= MO, a homenet issue. It has no place in 6204bis.

 

This reasoning applies just as well to the recommend= ation of RFC 6092 Simple Security, which is about protecting LAN hosts acco= rding to local network policy.

 

If recommending a PCP server is for HOMENET to do, a= nd it has no place in RFC 6204bis from V6OPS, then recommending RFC 6092 Si= mple Security neither has any place in RFC 6204bis and it should therefore = be removed, and a notice inserted into RFC 6204bis to explain why the previous document was in error and to = note that forthcoming documents from HOMENET will address the issue properl= y.

 

I would very much like to get a better understanding= of how you are reasoning on this issue.



 

--

j h = woodyatt <jhw@apple.com><= /span>



 

--_000_2D09D61DDFA73D4C884805CC7865E611025BFEGAALPA1MSGUSR9NIT_-- From fred@cisco.com Mon Jan 30 13:21:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0AA31F0C53 for ; Mon, 30 Jan 2012 13:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.453 X-Spam-Level: X-Spam-Status: No, score=-106.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJ79gNTUtFnM for ; Mon, 30 Jan 2012 13:21:16 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id D4D331F0C4E for ; Mon, 30 Jan 2012 13:21:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=475; q=dns/txt; s=iport; t=1327958476; x=1329168076; h=from:subject:date:message-id:cc:to:mime-version: content-transfer-encoding; bh=ZNMPLd22IO4F/y4zUk6QJxj08l2mapBT1MeXY5E1i9E=; b=RZ0n0sOyqh7dz994rn/zHET7QAY/0NgH+rUQOXJTBvWvecoYLK2AZaPB KFJFshu/XkCxUXSsbSMa2kywPsaOiwfR9LceiPMjKI+MfT7k+Ce5bW6VJ 5sMUUrytzKQDyGfxCEy3YjA1ABD9bUt4YFTU98CbyVqAh+QnIsnJ/o9Ay Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEACwJJ0+rRDoG/2dsb2JhbABDrleBBYILASc/gSIcNaF9AZ4+in4HAgIJBQwGEwEIBQMDCQ0PAQIBgnwFGAILAgVjBRCCdWMEiD+MW4VWjRw X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="27846122" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 30 Jan 2012 21:21:15 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0ULLEKR023711; Mon, 30 Jan 2012 21:21:14 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Mon, 30 Jan 2012 13:21:14 -0800 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Mon, 30 Jan 2012 13:21:14 -0800 From: Fred Baker Date: Mon, 30 Jan 2012 13:21:05 -0800 Message-Id: <504314E8-3B08-44D3-8F51-8BC421BEC462@cisco.com> To: v6ops v6ops WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Ron Bonica Subject: [v6ops] Agenda call X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 21:21:16 -0000 We're starting to plan an agenda for IETF 83. To that end, we need to = know what drafts people would like to discuss. If you have a draft to you would like to discuss, please file it as = draft--v6ops--00.txt, and having done so, post a = note to the list requesting discussion. If you have already filed one, = please send email to the list to provoke discussion. We'll be looking at = the subset of those drafts that folks show interest in.= From jhw@apple.com Mon Jan 30 14:08:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0BA11E80B0; Mon, 30 Jan 2012 14:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.698 X-Spam-Level: X-Spam-Status: No, score=-109.698 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, SARE_BAYES_5x7=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdJ0u+zoiIwO; Mon, 30 Jan 2012 14:08:54 -0800 (PST) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4A41B11E80A2; Mon, 30 Jan 2012 14:08:54 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_y3F4IlJ+dsPZjxsLfK1RxQ)" Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0LYM00KN0TEJPUR1@mail-out.apple.com>; Mon, 30 Jan 2012 14:08:54 -0800 (PST) X-AuditID: 11807134-b7b36ae0000046e8-1d-4f2714f56e96 Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id 8E.80.18152.5F4172F4; Mon, 30 Jan 2012 14:08:53 -0800 (PST) From: james woodyatt In-reply-to: <2D09D61DDFA73D4C884805CC7865E611025BFE@GAALPA1MSGUSR9N.ITServices.sbc.com> Date: Mon, 30 Jan 2012 14:08:53 -0800 Message-id: <30931DE1-9E57-4296-B0FE-FA98F840D78F@apple.com> References: "29 Jan 2012 09:51:52 PST." <85BE2EBF-C8AC-45E1-BF93-1E3066AD3172@apple.com> <201201301936.q0UJaEft000156@givry.fdupont.fr> <2D09D61DDFA73D4C884805CC7865E611025B49@GAALPA1MSGUSR9N.ITServices.sbc.com> <4A687585-399D-4077-91AC-A1DC4F101E03@apple.com> <2D09D61DDFA73D4C884805CC7865E611025BFE@GAALPA1MSGUSR9N.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1251.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUieJDXQferiLq/QfMiU4tJf38yWty8epHF YvKx36wWp4/tZXZg8XjZP4fRY8mSn0weXy5/ZgtgjuKySUnNySxLLdK3S+DKWPllI3vBhMiK yS/UGhg/e3UxcnJICJhIdLw6yQJhi0lcuLeerYuRi0NIYDaTxKTrc5lBEsIC1hJ72x+xgti8 AsYSa269A2rg4GAWSJBYOs0DJMwmoCLx7fJdJpAwp0CExOzdRiBhFgFVib4L/WDjmQVSJTbe vcYOMcVGYtvbt6wQqy4wSXzrXsEEkhARUJdYNW06K8Q98hItX++wTWDkm4Vk8yyEzbPAxmpL LFv4mhnCNpB42vmKFVNcX+LNuzlMCxjZVjEKFqXmJFYamuglFhTkpOol5+duYgSFb0OhyQ7G gz/5DzEKcDAq8fDufK/mL8SaWFZcmXuIUYKDWUmE981qoBBvSmJlVWpRfnxRaU5q8SFGaQ4W JXHeLdbK/kIC6YklqdmpqQWpRTBZJg5OqQZGpjctHo2O79T/iGVZ5iucOm2W6pdkrL/yXeDp iXq5TfuiIj75MC40uhwp7jyhW+R6+9+9k04c+RSh/cKSa1L1ipcc7z42F++fcqyodk+vnJ23 Q3OvmvSFk4KV+bnc++26BI9HmktpXnEKlOLpc44/sNhHlI2pgOFSATPftqLtLEmnD3/vr1Zi Kc5INNRiLipOBAC0dnWcWwIAAA== Cc: IPv6 Operations , PCP , draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 22:08:55 -0000 --Boundary_(ID_y3F4IlJ+dsPZjxsLfK1RxQ) Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable On Jan 30, 2012, at 12:59 , STARK, BARBARA H wrote: > The reference to RFC 6092 is in RFC 6204, which was published prior to = homenet=92s creation. > =20 > Unless the reference to 6092 is truly an error, then we don=92t need = to be discussing changes to its recommendation (removal, updates, = enhancements) in 6204bis. It continues as it was. 6204bis has tried to = leave LAN elements of 6204 untouched. They were fully and appropriately = discussed with consensus agreement to include them, at the time of 6204. = And so they remain, unless there is a problem. > =20 > If you believe that inclusion of 6092 as a =93SHOULD=94 is truly an = error, then I would like to understand why you think that. If there = exists proof that it=92s harmful (I=92ve heard some people say that = having it enabled by default has caused some problems, so perhaps there = is such proof), then maybe we should reconsider its inclusion. If you=92re= suggesting its removal because the topic is no longer under the charter = of v6ops, then I disagree. We didn=92t say that we wanted to pull out = LAN elements when doing 6204bis. We said we didn=92t want to do anything = with them, at all (unless they have proven to be a true mistake). = Removing the reference to 6092 would be inconsistent with an attempt to = make no =93LAN functionality=94 changes to 6204, when creating 6204bis. = I would only support it if it were shown to be truly harmful. If I were to make a technical argument about the harmfulness of RFC = 6092, I would start with a lengthy review of its Security = Considerations, in section 6. I think it's a debatable question of procedure, whether it was an error = at the time for V6OPS to publish RFC 6204 with its S-1 "requirement" to = recommend implementation of RFC 6092. There was a clamor for the timely = publication of a document, and neither HOMENET nor PCP were remotely = close to usable when RFC 6204 was in WGLC. I do think it shouldn't be controversial *now* to say that HOMENET is = the venue where any further IETF recommendations about the = implementation of RFC 6092 in IPv6 CE routers should originate. If you = disagree, then once again, I have to ask for an explanation of your = reasoning. I'm very interested to know. If V6OPS wishes to continue stepping on HOMENET's charter, on the = grounds that it already has its footprints there from before HOMENET was = launched, then I suppose that's fine=97 but, if so, then I don't see why = V6OPS shouldn't also take this opportunity to revise RFC 6204 to = recommend a PCP server to meet REC-48 in RFC 6092. Again, as a purely = technical matter=97 I know, technical matters are so boring=97 IETF has = a standards-track protocol for ""host applications to solicit inbound = traffic without advance knowledge of the addresses of exterior nodes = with which they expect to communicate" as RFC 6092 recommends. We did = not have this protocol when either RFC 6092 or RFC 6204 were ready for = publication, but we do now. I fail to see any technical basis for = leaving this unspecified in RFC 6204bis. Is there one? Alternatively, if this is primarily a procedural dispute, then we could = open RFC6092bis in order to update REC-48 accordingly, then cite the = RFC6092bis in RFC6204bis with a publication in lockstep. Which would = you prefer? -- j h woodyatt --Boundary_(ID_y3F4IlJ+dsPZjxsLfK1RxQ) Content-type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable
On Jan 30, 2012, at 12:59 , STARK, = BARBARA H wrote:

The reference to RFC = 6092 is in RFC 6204, which was published prior to homenet=92s = creation.
If = you believe that inclusion of 6092 as a =93SHOULD=94 is truly an error, = then I would like to understand why you think that. If there exists = proof that it=92s harmful (I=92ve heard some people say that having it = enabled by default has caused some problems, so perhaps there is such = proof), then maybe we should reconsider its inclusion. If you=92re = suggesting its removal because the topic is no longer under the charter = of v6ops, then I disagree. We didn=92t say that we wanted to pull out = LAN elements when doing 6204bis. We said we didn=92t want to do anything = with them, at all (unless they have proven to be a true mistake). = Removing the reference to 6092 would be inconsistent with an attempt to = make no =93LAN functionality=94 changes to 6204, when creating 6204bis. = I would only support it if it were shown to be truly = harmful.

If I = were to make a technical argument about the harmfulness of RFC 6092, I = would start with a lengthy review of its Security Considerations, in = section 6.

I think it's a debatable question of = procedure, whether it was an error at the time for V6OPS to publish RFC = 6204 with its S-1 "requirement" to recommend implementation of RFC 6092. =  There was a clamor for the timely publication of a document, and = neither HOMENET nor PCP were remotely close to usable when RFC 6204 was = in WGLC.

I do think it shouldn't be = controversial *now* to say that HOMENET is the venue where any further = IETF recommendations about the implementation of RFC 6092 in IPv6 CE = routers should originate.  If you disagree, then once again, I have = to ask for an explanation of your reasoning.  I'm very interested = to know.

If V6OPS wishes to continue stepping = on HOMENET's charter, on the grounds that it already has its footprints = there from before HOMENET was launched, then I suppose that's fine=97 = but, if so, then I don't see why V6OPS shouldn't also take this = opportunity to revise RFC 6204 to recommend a PCP server to meet REC-48 = in RFC 6092.  Again, as a purely technical matter=97 I know, = technical matters are so boring=97 IETF has a standards-track protocol = for ""host applications to solicit inbound traffic without advance = knowledge of the addresses of exterior nodes with which they expect to = communicate" as RFC 6092 recommends.  We did not have this protocol = when either RFC 6092 or RFC 6204 were ready for publication, but we do = now.  I fail to see any technical basis for leaving this = unspecified in RFC 6204bis.  Is there = one?

Alternatively, if this is primarily a = procedural dispute, then we could open RFC6092bis in order to update = REC-48 accordingly, then cite the RFC6092bis in RFC6204bis with a = publication in lockstep.  Which would you prefer?


--
j h woodyatt <jhw@apple.com>

= --Boundary_(ID_y3F4IlJ+dsPZjxsLfK1RxQ)-- From rajiva@cisco.com Mon Jan 30 14:26:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFDA11E80B0 for ; Mon, 30 Jan 2012 14:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.057 X-Spam-Level: X-Spam-Status: No, score=-6.057 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1z-w6x2FXkjS for ; Mon, 30 Jan 2012 14:26:15 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 25E4311E80C7 for ; Mon, 30 Jan 2012 14:26:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=8233; q=dns/txt; s=iport; t=1327962371; x=1329171971; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=KAJBzhrNTiZtFYhTLhE2EPrRNgojsmIwNBQEchupwIU=; b=SC7mTQam4JYCNhqafPHLskjv559irgTuV7IwGrHD6UgJuv3VKK8ix6Br 3eNPcvKEIKJ6GuSf2p0QqLNTZEWFYLGeulToaES9Lom6WS7OQH5U4r/sk gYi3LPjXR+m9E2XsiJ7ZYksMWIoytk4XQvw5B04B+ww0yPts+1czbRjH2 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALEXJ0+tJV2a/2dsb2JhbABDrleBBYFyAQEBBAEBAQ8BFAkKNAsMBAIBCBEBAwEBCwYXAQYBJh8DBggBAQQTCBMHh2OaIwGeO4p+KzUMAoQygnVjBIg/n0s X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="54988877" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 30 Jan 2012 22:26:10 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0UMQA9j009480; Mon, 30 Jan 2012 22:26:10 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jan 2012 16:26:10 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Jan 2012 16:26:10 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C073C63FC@XMB-RCD-111.cisco.com> In-Reply-To: <20120127103118kawashimam@mail.jp.nec.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] I-D Action: draft-mawatari-v6ops-464xlat-00.txt Thread-Index: Aczck5zFK3tDAPjOQqmpIfdfhCVcEwC7fXHg References: <067E6CE33034954AAC05C9EC85E2577C073C54B4@XMB-RCD-111.cisco.com> <20120127103118kawashimam@mail.jp.nec.com> From: "Rajiv Asati (rajiva)" To: "Masanobu Kawashima" X-OriginalArrivalTime: 30 Jan 2012 22:26:10.0654 (UTC) FILETIME=[2B05F7E0:01CCDF9E] Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-mawatari-v6ops-464xlat-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 22:26:17 -0000 Masanobu-San, 1. How could the DHCPv4 be used here for v4 address assignment, since CLAT enabled device is supposed to have only IPv6? Does it even make sense to use DHCPv4? Perhaps, specify DHCPv6 (new option, say) usage. I agree with you to adding some explicit language and requirement on this very point, since IPv4 address assignment is key. Also, it would be worth clarifying whether CLAT cares about private IPv4 or public IPv4 assignment or both. I presume the last, suffice to say.=20 =20 2. Agreed. Having DNS-proxy is reasonable. 3. Agreed. Given that the router function (virtual or not) is mandatory on the CLAT enabled device (gateway or mobile device) for this proposal to work, I would urge you to mention that explicitly not only in section 7.4, but also in section 3 where CLAT is defined first. 5. Agreed. It would be better to mention DHCP-PD as the recommended mechanism, while allowing the other mechanism. I would get rid of the word 'auto' from the title, btw. While we agree to IA_PD, is there a need for IA_NA? It would be worth clarifying in that section. On a basic note, How DNS and HTTP be ever useful for ipv6 prefix assignment?=20 Cheers, Rajiv=09 > -----Original Message----- > From: Masanobu Kawashima [mailto:kawashimam@vx.jp.nec.com] > Sent: Thursday, January 26, 2012 8:31 PM > To: Rajiv Asati (rajiva) > Cc: Brian E Carpenter; IPv6 Operations > Subject: RE: [v6ops] I-D Action: draft-mawatari-v6ops-464xlat-00.txt >=20 >=20 > Dear Rajiv, >=20 > Thank you for your comments. >=20 > >1. How is IPv4 address getting assigned to the host? >=20 > The 464XLAT architecture does not have any requirements on how the IPv4 > address is assigned. It can be assigned via static or dhcpv4. We should > add some language that the subnet must be defined in the CLAT to better > define the scope of stateless translation. >=20 > The CLAT can acts just like other home gateways or mobile hotspots that > assign RFC1918 address (such as 192.168.1.x/24) to clients. There is > nothing special about the CLAT in how it assigns the address to a client. >=20 >=20 > >2. Could we not use an existing DHCP option to convey DNS server IPv4 > >address to the CLAT device, which can convey the DNSv4 address the same > >way as IPv4 address is conveyed? If we could, then we would not need DNS > >proxy function on CLAT. >=20 > The focus of this effort is on an IPv6-only access network. We don't see > an architectural benefit of doing 464XLAT translation for each DNS request. > As stated to Brian, the host may have its own choice of DNS servers, > including IPv4 DNS servers that require 464XLAT, but that is not the design > we would like to promote as the ideal case. >=20 >=20 > >3. Section 7.4 requires CLAT device to have router function. What > >happens if it is a typical host device (without any router function)? > > > >~~~~~~~~~ > >7.4. DNS Proxy Implementation > > If a router implement CLAT function, it performs DNS Proxy for IPv4 > > hosts and IPv6 hosts in end-user network. It MUST provide name > > resolution with IPv6 transport. It does not need DNS64 [RFC6147] > >~~~~~~~~~~~~~~~ >=20 > The router function can be virtual. This is the case of the Nokia n900 and > Android, which are really just hosts. >=20 >=20 > >4. In section 8, did you mean to say IPv4 -> IPv6 -> IPv4 translation > >below? :-) > >~~~~~~~~~~~~ > >... > > This 464XLAT architecture has two capabilities. One is a IPv6 -> > > IPv4 -> IPv6 translation for sharing global IPv4 addresses, another > >~~~~~~~~~ >=20 > Yes. It is an error in writing. :-) >=20 >=20 > >5. Section 7.7 (Auto IPv6 Prefix Assignment) could benefit from some > >explicit recommendation (since the current text says source v6 prefix > >assignment is done via DHCPv6-PD or another method, and destination IPv6 > >prefix assignment is via some method). >=20 > It depends on network operator. Why would more explicit help? > We would like to keep the options flexible so that solution can evolve > with different wireline and wireless network capabilities. But, we agree > dhcpv6-pd is good today. We just do not want to exclude other options > without a reason. >=20 > Regards, > Masanobu >=20 >=20 > >Masanobu-san, > > > >This is an interesting discussion and proposal. Few Q -- > > > >1. How is IPv4 address getting assigned to the host? > >2. Could we not use an existing DHCP option to convey DNS server IPv4 > >address to the CLAT device, which can convey the DNSv4 address the same > >way as IPv4 address is conveyed? If we could, then we would not need DNS > >proxy function on CLAT. > >3. Section 7.4 requires CLAT device to have router function. What > >happens if it is a typical host device (without any router function)? > > > >~~~~~~~~~ > >7.4. DNS Proxy Implementation > > If a router implement CLAT function, it performs DNS Proxy for IPv4 > > hosts and IPv6 hosts in end-user network. It MUST provide name > > resolution with IPv6 transport. It does not need DNS64 [RFC6147] > >~~~~~~~~~~~~~~~ > > > >4. In section 8, did you mean to say IPv4 -> IPv6 -> IPv4 translation > >below? :-) > >~~~~~~~~~~~~ > >... > > This 464XLAT architecture has two capabilities. One is a IPv6 -> > > IPv4 -> IPv6 translation for sharing global IPv4 addresses, another > >~~~~~~~~~ > > > >5. Section 7.7 (Auto IPv6 Prefix Assignment) could benefit from some > >explicit recommendation (since the current text says source v6 prefix > >assignment is done via DHCPv6-PD or another method, and destination IPv6 > >prefix assignment is via some method). > > > >Cheers, > >Rajiv > > > > > >> -----Original Message----- > >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > >Of > >> Masanobu Kawashima > >> Sent: Tuesday, January 24, 2012 12:21 PM > >> To: Brian E Carpenter > >> Cc: IPv6 Operations > >> Subject: Re: [v6ops] I-D Action: draft-mawatari-v6ops-464xlat-00.txt > >> > >> > >> Hi Brian, > >> > >> Thank you for your comment. > >> > >> I take your point. However, a CLAT can only learn the address of an > >IPv6 > >> DNS recursive server through DHCPv6 (or other way). The CLAT can not > >easily > >> discover the address of an IPv4 DNS recursive server, and it has to > >perform > >> all DNS resolution over IPv6. > >> > >> The CLAT can pass this IPv6 address to downstream IPv6 hosts, but not > >to > >> downstream IPv4 hosts. As such, the CLAT should implement a DNS proxy. > >> > >> Regards, > >> Masanobu > >> > >> > >> >> 7.4. DNS Proxy Implementation > >> >> > >> >> If a router implement CLAT function, it performs DNS Proxy for > >IPv4 > >> >> hosts and IPv6 hosts in end-user network. > >> > > >> >Why is this necessary? As far as I can see, the client could use any > >> >normal DNS server, because the A and AAAA records it needs are > >completely > >> >standard. > >> > > >> >Regards > >> > Brian Carpenter > >> > > >> >_______________________________________________ > >> >v6ops mailing list > >> >v6ops@ietf.org > >> >https://www.ietf.org/mailman/listinfo/v6ops > >> > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> NEC AccessTechnica, Ltd. > >> Product Development Department > >> Masanobu Kawashima > >> kawashimam@vx.jp.nec.com > >> http://www.necat.co.jp/ > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > NEC AccessTechnica, Ltd. > Product Development Department > Masanobu Kawashima > kawashimam@vx.jp.nec.com > http://www.necat.co.jp/ > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From bs7652@att.com Mon Jan 30 14:37:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD7311E80D1 for ; Mon, 30 Jan 2012 14:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.998 X-Spam-Level: X-Spam-Status: No, score=-105.998 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ech8mrUsEx2U for ; Mon, 30 Jan 2012 14:37:01 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB4F11E80C9 for ; Mon, 30 Jan 2012 14:37:01 -0800 (PST) X-Env-Sender: bs7652@att.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1327963019!13138548!1 X-Originating-IP: [144.160.20.146] X-StarScan-Version: 6.4.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3465 invoked from network); 30 Jan 2012 22:36:59 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-2.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Jan 2012 22:36:59 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q0UMZSxS012993; Mon, 30 Jan 2012 17:35:28 -0500 Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q0UMZMCR012861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jan 2012 17:35:22 -0500 Received: from GAALPA1MSGHUB9F.ITServices.sbc.com (gaalpa1msghub9f.itservices.sbc.com [130.8.36.92]) by sflint04.pst.cso.att.com (RSA Interceptor); Mon, 30 Jan 2012 17:36:47 -0500 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([169.254.6.206]) by GAALPA1MSGHUB9F.ITServices.sbc.com ([130.8.36.92]) with mapi id 14.01.0355.002; Mon, 30 Jan 2012 17:36:47 -0500 From: "STARK, BARBARA H" To: james woodyatt Thread-Topic: [v6ops] PCP server in draft-ietf-v6ops-6204bis Thread-Index: AQHM34Zty/cRV1j9DUSbChwVr26jwZYlUQmQgABcCYD//65DsIAAcPCA//+vz2A= Date: Mon, 30 Jan 2012 22:36:47 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611025D94@GAALPA1MSGUSR9N.ITServices.sbc.com> References: "29 Jan 2012 09:51:52 PST." <85BE2EBF-C8AC-45E1-BF93-1E3066AD3172@apple.com> <201201301936.q0UJaEft000156@givry.fdupont.fr> <2D09D61DDFA73D4C884805CC7865E611025B49@GAALPA1MSGUSR9N.ITServices.sbc.com> <4A687585-399D-4077-91AC-A1DC4F101E03@apple.com> <2D09D61DDFA73D4C884805CC7865E611025BFE@GAALPA1MSGUSR9N.ITServices.sbc.com> <30931DE1-9E57-4296-B0FE-FA98F840D78F@apple.com> In-Reply-To: <30931DE1-9E57-4296-B0FE-FA98F840D78F@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.169.165] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E611025D94GAALPA1MSGUSR9NIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Cc: IPv6 Operations , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 22:37:03 -0000 --_000_2D09D61DDFA73D4C884805CC7865E611025D94GAALPA1MSGUSR9NIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I quite agree that any and all discussions around changes to or further rec= ommendations around 6092 should be held in homenet. That is exactly why I'm= trying to avoid such discussions now in v6ops. I think there should be a v= ery high bar set around changing any of the LAN-side recommendations in 620= 4, as we work on 6204bis. Certainly nothing should be added. But at this po= int, I'm opposed to any modification to those recommendations, without a ve= ry good justification, and without homenet expressing the need for the chan= ge (after having discussed and reached consensus). When those recommendatio= ns were put in 6204, they were in scope for v6ops. Since they are no longer= in v6ops' scope, v6ops needs to just leave them alone. Would you like v6op= s to ask homenet if they want to see any of the language in 6204 changed? I= f so, then I would prefer for there to be a very quick turn-around; and the= re needs to be strong consensus in homenet for a change. Just a couple of v= ocal people shouldn't be considered a consensus. If you think there might b= e consensus to request a change, then perhaps there should be a hum to see = if the majority of homenet feel strongly enough to force a change to any of= the 6204 LAN-side functionality language? I don't really know the proper p= rocedure. Perhaps someone else should say what the proper procedure would b= e. Barbara I do think it shouldn't be controversial *now* to say that HOMENET is the v= enue where any further IETF recommendations about the implementation of RFC= 6092 in IPv6 CE routers should originate. If you disagree, then once agai= n, I have to ask for an explanation of your reasoning. I'm very interested= to know. --_000_2D09D61DDFA73D4C884805CC7865E611025D94GAALPA1MSGUSR9NIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I quite agree that any an= d all discussions around changes to or further recommendations around 6092 = should be held in homenet. That is exactly why I’m trying to avoid such discussions now in v6ops. I think there should be a very hig= h bar set around changing any of the LAN-side recommendations in 6204, as w= e work on 6204bis. Certainly nothing should be added. But at this point, I&= #8217;m opposed to any modification to those recommendations, without a very good justification, and without home= net expressing the need for the change (after having discussed and reached = consensus). When those recommendations were put in 6204, they were in scope= for v6ops. Since they are no longer in v6ops’ scope, v6ops needs to just leave them alone. Would you lik= e v6ops to ask homenet if they want to see any of the language in 6204 chan= ged? If so, then I would prefer for there to be a very quick turn-around; a= nd there needs to be strong consensus in homenet for a change. Just a couple of vocal people shouldn’t be = considered a consensus. If you think there might be consensus to request a = change, then perhaps there should be a hum to see if the majority of homene= t feel strongly enough to force a change to any of the 6204 LAN-side functionality language? I don’t really k= now the proper procedure. Perhaps someone else should say what the proper p= rocedure would be.

Barbara=

 <= /p>

I do think it shouldn't be controversial *now* to sa= y that HOMENET is the venue where any further IETF recommendations about th= e implementation of RFC 6092 in IPv6 CE routers should originate.  If = you disagree, then once again, I have to ask for an explanation of your reasoning.  I'm very interested to kno= w.

--_000_2D09D61DDFA73D4C884805CC7865E611025D94GAALPA1MSGUSR9NIT_-- From jhw@apple.com Mon Jan 30 14:47:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5F121F8747 for ; Mon, 30 Jan 2012 14:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.923 X-Spam-Level: X-Spam-Status: No, score=-109.923 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_BAYES_5x7=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLxUekfFM-iW for ; Mon, 30 Jan 2012 14:47:50 -0800 (PST) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id B707C21F8745 for ; Mon, 30 Jan 2012 14:47:50 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ihKjl6WuyxRiFrBw73Da8g)" Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0LYM00G8UV529SN2@mail-out.apple.com> for v6ops@ietf.org; Mon, 30 Jan 2012 14:47:46 -0800 (PST) X-AuditID: 11807130-b7c1cae000001024-c6-4f271e122778 Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 9E.6D.04132.21E172F4; Mon, 30 Jan 2012 14:47:46 -0800 (PST) From: james woodyatt In-reply-to: <2D09D61DDFA73D4C884805CC7865E611025D94@GAALPA1MSGUSR9N.ITServices.sbc.com> Date: Mon, 30 Jan 2012 14:47:46 -0800 Message-id: <40213FF8-75F6-444F-903F-05DEB4C43E69@apple.com> References: "29 Jan 2012 09:51:52 PST." <85BE2EBF-C8AC-45E1-BF93-1E3066AD3172@apple.com> <201201301936.q0UJaEft000156@givry.fdupont.fr> <2D09D61DDFA73D4C884805CC7865E611025B49@GAALPA1MSGUSR9N.ITServices.sbc.com> <4A687585-399D-4077-91AC-A1DC4F101E03@apple.com> <2D09D61DDFA73D4C884805CC7865E611025BFE@GAALPA1MSGUSR9N.ITServices.sbc.com> <30931DE1-9E57-4296-B0FE-FA98F840D78F@apple.com> <2D09D61DDFA73D4C884805CC7865E611025D94@GAALPA1MSGUSR9N.ITServices.sbc.com> To: draft-ietf-v6ops-6204bis@tools.ietf.org X-Mailer: Apple Mail (2.1251.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRmVeSWpSXmKPExsUieJDXQVdITt3f4PdPXYubVy+yWJw+tpfZ gcljyZKfTB5fLn9mC2CK4rJJSc3JLEst0rdL4MpYPKWDraBDrqJn9wW2BsZuqS5GTg4JAROJ FdtbWCFsMYkL99azdTFycQgJzGaSeDR3JlhCWMBaYm/7IzCbV8BYYs2tdywgNrNAgsSjlz8Y QWw2ARWJb5fvMoHYnAIREi/e3mEDsVkEVCWWTdzC3sXIAVSvIvG/gR9ijI1E/4HjYCVCAmeZ JbYtUwOxRQS0JaYdPQF1j7xEy9c7bBMY+WYh2TwLyWYIW1ti2cLXzBC2gcTTzlesmOL6Em/e zWFawMi2ilGwKDUnsdLQUC+xoCAnVS85P3cTIyhIGwoNdjCu/cl/iFGAg1GJh1fwk5q/EGti WXFl7iFGCQ5mJRHeN6uBQrwpiZVVqUX58UWlOanFhxilOViUxHk3Wyv7CwmkJ5akZqemFqQW wWSZODilGhgTVuTr3hbySuqt/OZZ/uLB5aJpT5dyzP+c5uA8M4uvrvWa1Y2Xy9wXd3hbVpYs lnnqcT1h3cbPoSH+uavMT50tLdWduWzKJ50/bWdqAkRCmovfrkjn/7fAL/L3oa676m335Lx5 PwdEJnF77ktiarnUcnaxM6fSwpNvYiWOGZ48sdX8lgZnyiUlluKMREMt5qLiRADu76wYTgIA AA== Cc: IPv6 Operations Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 22:47:51 -0000 --Boundary_(ID_ihKjl6WuyxRiFrBw73Da8g) Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable everyone=97 I'm addressing the chairs now. I'm still waiting to see a technical basis for recommending a filtering = scheme that blocks unsolicited incoming traffic, and which itself = recommends the implementation of a protocol for "host applications to = solicit inbound traffic without advance knowledge of the addresses of = exterior nodes with which they expect to communicate," with no = accompanying recommendation to implement the forthcoming IETF = standards-track protocol for doing it. Is this a case of procedural matters unduly having precedence over = technical matters? If so, then I'd like to ask that RFC 6204 be held = back so that we can revise RFC 6092 to update REC-48 accordingly and = publish both simultaneously. -- j h woodyatt --Boundary_(ID_ihKjl6WuyxRiFrBw73Da8g) Content-type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable
everyone=97

I'm = addressing the chairs now.

I'm still waiting to = see a technical basis for recommending a filtering scheme that blocks = unsolicited incoming traffic, and which itself recommends the = implementation of a protocol for "host applications to solicit inbound = traffic without advance knowledge of the addresses of exterior nodes = with which they expect to communicate," with no accompanying = recommendation to implement the forthcoming IETF standards-track = protocol for doing it.

Is this a case of = procedural matters unduly having precedence over technical matters? =  If so, then I'd like to ask that RFC 6204 be held back so that we = can revise RFC 6092 to update REC-48 accordingly and publish both = simultaneously.


--
j h woodyatt <jhw@apple.com>

= --Boundary_(ID_ihKjl6WuyxRiFrBw73Da8g)-- From jhw@apple.com Mon Jan 30 14:49:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDC421F8763 for ; Mon, 30 Jan 2012 14:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.638 X-Spam-Level: X-Spam-Status: No, score=-109.638 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, SARE_BAYES_5x7=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEDNvTkIleHQ for ; Mon, 30 Jan 2012 14:49:39 -0800 (PST) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 73AFB21F8769 for ; Mon, 30 Jan 2012 14:49:38 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_DwHuy6dELVEECE9DsAIrqA)" Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0LYM00MSCVEM3FU1@mail-out.apple.com> for v6ops@ietf.org; Mon, 30 Jan 2012 14:49:38 -0800 (PST) X-AuditID: 11807134-b7b36ae0000046e8-2b-4f271e815710 Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id F5.30.18152.18E172F4; Mon, 30 Jan 2012 14:49:38 -0800 (PST) From: james woodyatt Date: Mon, 30 Jan 2012 14:49:37 -0800 References: <40213FF8-75F6-444F-903F-05DEB4C43E69@apple.com> To: "v6ops-chairs@tools.ietf.org Chairs" Message-id: <0592CD97-D04E-428D-A092-003D89D7F6D0@apple.com> X-Mailer: Apple Mail (2.1251.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUieJDXQbdJTt3f4FSgxdvLLxgtTh/by+zA 5LFkyU8mjy+XP7MFMEVx2aSk5mSWpRbp2yVwZRx9WFDwxrFiyxy9BsYGqy5GTg4JAROJnavP skHYYhIX7q0Hsrk4hARmM0ks3b2ZBSTBJqAi8e3yXSYQm1fAWGLNrXdgcWaBBInjJ18wg9jC AjYSm+Z3MHYxcnCwCKhKrGgyATGFgML7r1qAmMxAU/438IOYIgJuEq+3qkLMs5F4fWUuE8QB 8hItX++wTWDknYVk1SwkqyBsbYllC19D2QYSTztfsWKK60u8eTeHaQEj2ypGwaLUnMRKQxO9 xIKCnFS95PzcTYygAGwoNNnBePAn/yFGAQ5GJR7ene/V/IVYE8uKK3MPMUpwMCuJ8L5ZDRTi TUmsrEotyo8vKs1JLT7EKM3BoiTOu8Va2V9IID2xJDU7NbUgtQgmy8TBKdXAGF/fZ+XwwOXs 5xd71nYEqZkmTORW61i9Tf/7zwetb7ZcCLhvWq1o/+7cW+W1057LmU2VaD6ad22miePFSetW drXNsYue0/V44bwUFWmNGReffm6sf1AXnKw017+C7WRYTrS7+vk7S2PuXeb1DfnQIakv9s74 cquY0FrZo8IeF/MXG2x5qtR1U4mlOCPRUIu5qDgRAAGxuec8AgAA Cc: IPv6 Operations Subject: [v6ops] Fwd: PCP server in draft-ietf-v6ops-6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 22:49:40 -0000 --Boundary_(ID_DwHuy6dELVEECE9DsAIrqA) Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable everyone=97 Or I would have been addressing the chairs if I had filled out the = headers correctly. I am now. Begin forwarded message: > From: james woodyatt > Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis > Date: January 30, 2012 14:47:46 PST > To: draft-ietf-v6ops-6204bis@tools.ietf.org > Cc: IPv6 Operations >=20 > everyone=97 >=20 > I'm addressing the chairs now. >=20 > I'm still waiting to see a technical basis for recommending a = filtering scheme that blocks unsolicited incoming traffic, and which = itself recommends the implementation of a protocol for "host = applications to solicit inbound traffic without advance knowledge of the = addresses of exterior nodes with which they expect to communicate," with = no accompanying recommendation to implement the forthcoming IETF = standards-track protocol for doing it. >=20 > Is this a case of procedural matters unduly having precedence over = technical matters? If so, then I'd like to ask that RFC 6204 be held = back so that we can revise RFC 6092 to update REC-48 accordingly and = publish both simultaneously. >=20 >=20 > -- > j h woodyatt >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- j h woodyatt --Boundary_(ID_DwHuy6dELVEECE9DsAIrqA) Content-type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable
From: james woodyatt = <jhw@apple.com>
Subject: = Re: [v6ops] PCP server in = draft-ietf-v6ops-6204bis
Date: January 30, 2012 14:47:46 PST
Cc: IPv6 Operations <v6ops@ietf.org>

=

Is this a case of = procedural matters unduly having precedence over technical matters? =  If so, then I'd like to ask that RFC 6204 be held back so that we = can revise RFC 6092 to update REC-48 accordingly and publish both = simultaneously.


--
j h woodyatt <jhw@apple.com>

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



--
j h woodyatt <jhw@apple.com>

= --Boundary_(ID_DwHuy6dELVEECE9DsAIrqA)-- From cb.list6@gmail.com Mon Jan 30 14:49:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931E921F876F for ; Mon, 30 Jan 2012 14:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1OvrL44kv8Y for ; Mon, 30 Jan 2012 14:49:48 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 52B2A21F876C for ; Mon, 30 Jan 2012 14:49:48 -0800 (PST) Received: by pbdy7 with SMTP id y7so68979pbd.31 for ; Mon, 30 Jan 2012 14:49:48 -0800 (PST) Received-SPF: pass (google.com: domain of cb.list6@gmail.com designates 10.68.216.4 as permitted sender) client-ip=10.68.216.4; Authentication-Results: mr.google.com; spf=pass (google.com: domain of cb.list6@gmail.com designates 10.68.216.4 as permitted sender) smtp.mail=cb.list6@gmail.com; dkim=pass header.i=cb.list6@gmail.com Received: from mr.google.com ([10.68.216.4]) by 10.68.216.4 with SMTP id om4mr33935569pbc.19.1327963788196 (num_hops = 1); Mon, 30 Jan 2012 14:49:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=44QVraK3H9hIXk5vPUQfEeq2HRWsi5h7QvmQ8oWhKAI=; b=epGGETPhBcnAohd1Wbz41EM+H9OuTfaZJxKzycGwYdmKDutSuLfKDY2oT2bE4snkz/ RTIjU4WSAFJT1xYn0NCZppe373YqA2OnxsQkHfaZDWuiDn/Uunqk8ZlFODkvemEW9YGa 227zDIjPmEQMV6CdxWA3PO8VbPFyl51vs+5XI= MIME-Version: 1.0 Received: by 10.68.216.4 with SMTP id om4mr28164606pbc.19.1327963786378; Mon, 30 Jan 2012 14:49:46 -0800 (PST) Received: by 10.143.78.7 with HTTP; Mon, 30 Jan 2012 14:49:46 -0800 (PST) In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C073C63FC@XMB-RCD-111.cisco.com> References: <067E6CE33034954AAC05C9EC85E2577C073C54B4@XMB-RCD-111.cisco.com> <20120127103118kawashimam@mail.jp.nec.com> <067E6CE33034954AAC05C9EC85E2577C073C63FC@XMB-RCD-111.cisco.com> Date: Mon, 30 Jan 2012 14:49:46 -0800 Message-ID: From: Cameron Byrne To: "Rajiv Asati (rajiva)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-mawatari-v6ops-464xlat-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 22:49:49 -0000 Hi Rajiv, On Mon, Jan 30, 2012 at 2:26 PM, Rajiv Asati (rajiva) wr= ote: > Masanobu-San, > > 1. How could the DHCPv4 be used here for v4 address assignment, since > CLAT enabled device is supposed to have only IPv6? Does it even make > sense to use DHCPv4? Perhaps, specify DHCPv6 (new option, say) usage. > The CLAT may be a home gateway or a cell phone. Facing the WAN ISP network, the CLAT interface is only IPv6. Facing the subscriber home network, the CLAT is dual-stack. For IPv6 flows, the CLAT is a basic IPv6 router. For IPv4 flows, the CLAT is does stateless RFC 6145 translation. In this way, the CLAT is a DHCPv4 server for IPv4 clients in the home network. It may also be a DHCPv6 server for subscriber IPv6 clients and a DHCPv6 client of the ISP network. Just like a common home router today, the CLAT will assign RFC1918 space to the home client, but instead of doing NAT44 it will do RFC 6145 protocol translation as described in the draft. Does this answer your question? > I agree with you to adding some explicit language and requirement on > this very point, since IPv4 address assignment is key. Also, it would be > worth clarifying whether CLAT cares about private IPv4 or public IPv4 > assignment or both. I presume the last, suffice to say. > The 464XLAT draft is focused on transition to an IPv6-only ISP access network where IPv4 is highly scarce. So, the explicit assumption is that RFC1918 IPv4 addresses are used behind the CLAT. > 2. Agreed. Having DNS-proxy is reasonable. > ACK > 3. Agreed. Given that the router function (virtual or not) is mandatory > on the CLAT enabled device (gateway or mobile device) for this proposal > to work, I would urge you to mention that explicitly not only in section > 7.4, but also in section 3 where CLAT is defined first. > ACK > 5. Agreed. It would be better to mention DHCP-PD as the recommended > mechanism, while allowing the other mechanism. I would get rid of the > word 'auto' from the title, btw. While we agree to IA_PD, is there a > need for IA_NA? It would be worth clarifying in that section. > > On a basic note, How DNS and HTTP be ever useful for ipv6 prefix > assignment? > I having trouble parsing this last question? Can you explain some more? Thanks again for the useful review and insightful questions. CB > Cheers, > Rajiv > >> -----Original Message----- >> From: Masanobu Kawashima [mailto:kawashimam@vx.jp.nec.com] >> Sent: Thursday, January 26, 2012 8:31 PM >> To: Rajiv Asati (rajiva) >> Cc: Brian E Carpenter; IPv6 Operations >> Subject: RE: [v6ops] I-D Action: draft-mawatari-v6ops-464xlat-00.txt >> >> >> Dear Rajiv, >> >> Thank you for your comments. >> >> >1. How is IPv4 address getting assigned to the host? >> >> The 464XLAT architecture does not have any requirements on how the > IPv4 >> address is assigned. It can be assigned via static or dhcpv4. We > should >> add some language that the subnet must be defined in the CLAT to > better >> define the scope of stateless translation. >> >> The CLAT can acts just like other home gateways or mobile hotspots > that >> assign RFC1918 address (such as 192.168.1.x/24) to clients. There is >> nothing special about the CLAT in how it assigns the address to a > client. >> >> >> >2. Could we not use an existing DHCP option to convey DNS server IPv4 >> >address to the CLAT device, which can convey the DNSv4 address the > same >> >way as IPv4 address is conveyed? If we could, then we would not need > DNS >> >proxy function on CLAT. >> >> The focus of this effort is on an IPv6-only access network. We don't > see >> an architectural benefit of doing 464XLAT translation for each DNS > request. >> As stated to Brian, the host may have its own choice of DNS servers, >> including IPv4 DNS servers that require 464XLAT, but that is not the > design >> we would like to promote as the ideal case. >> >> >> >3. Section 7.4 requires CLAT device to have router function. What >> >happens if it is a typical host device (without any router function)? >> > >> >~~~~~~~~~ >> >7.4. DNS Proxy Implementation >> > =A0 If a router implement CLAT function, it performs DNS Proxy for > IPv4 >> > =A0 hosts and IPv6 hosts in end-user network. =A0It MUST provide name >> > =A0 resolution with IPv6 transport. =A0It does not need DNS64 [RFC6147= ] >> >~~~~~~~~~~~~~~~ >> >> The router function can be virtual. This is the case of the Nokia n900 > and >> Android, which are really just hosts. >> >> >> >4. =A0In section 8, did you mean to say IPv4 -> IPv6 -> IPv4 > translation >> >below? :-) >> >~~~~~~~~~~~~ >> >... >> > =A0 This 464XLAT architecture has two capabilities. =A0One is a IPv6 -= > >> > =A0 IPv4 -> IPv6 translation for sharing global IPv4 addresses, > another >> >~~~~~~~~~ >> >> Yes. It is an error in writing. :-) >> >> >> >5. Section 7.7 (Auto IPv6 Prefix Assignment) could benefit from some >> >explicit recommendation (since the current text says source v6 prefix >> >assignment is done via DHCPv6-PD or another method, and destination > IPv6 >> >prefix assignment is via some method). >> >> It depends on network operator. Why would more explicit help? >> We would like to keep the options flexible so that solution can evolve >> with different wireline and wireless network capabilities. But, we > agree >> dhcpv6-pd is good today. We just do not want to exclude other options >> without a reason. >> >> Regards, >> Masanobu >> >> >> >Masanobu-san, >> > >> >This is an interesting discussion and proposal. Few Q -- >> > >> >1. How is IPv4 address getting assigned to the host? >> >2. Could we not use an existing DHCP option to convey DNS server IPv4 >> >address to the CLAT device, which can convey the DNSv4 address the > same >> >way as IPv4 address is conveyed? If we could, then we would not need > DNS >> >proxy function on CLAT. >> >3. Section 7.4 requires CLAT device to have router function. What >> >happens if it is a typical host device (without any router function)? >> > >> >~~~~~~~~~ >> >7.4. DNS Proxy Implementation >> > =A0 If a router implement CLAT function, it performs DNS Proxy for > IPv4 >> > =A0 hosts and IPv6 hosts in end-user network. =A0It MUST provide name >> > =A0 resolution with IPv6 transport. =A0It does not need DNS64 [RFC6147= ] >> >~~~~~~~~~~~~~~~ >> > >> >4. =A0In section 8, did you mean to say IPv4 -> IPv6 -> IPv4 > translation >> >below? :-) >> >~~~~~~~~~~~~ >> >... >> > =A0 This 464XLAT architecture has two capabilities. =A0One is a IPv6 -= > >> > =A0 IPv4 -> IPv6 translation for sharing global IPv4 addresses, > another >> >~~~~~~~~~ >> > >> >5. Section 7.7 (Auto IPv6 Prefix Assignment) could benefit from some >> >explicit recommendation (since the current text says source v6 prefix >> >assignment is done via DHCPv6-PD or another method, and destination > IPv6 >> >prefix assignment is via some method). >> > >> >Cheers, >> >Rajiv >> > >> > >> >> -----Original Message----- >> >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On > Behalf >> >Of >> >> Masanobu Kawashima >> >> Sent: Tuesday, January 24, 2012 12:21 PM >> >> To: Brian E Carpenter >> >> Cc: IPv6 Operations >> >> Subject: Re: [v6ops] I-D Action: > draft-mawatari-v6ops-464xlat-00.txt >> >> >> >> >> >> Hi Brian, >> >> >> >> Thank you for your comment. >> >> >> >> I take your point. However, a CLAT can only learn the address of an >> >IPv6 >> >> DNS recursive server through DHCPv6 (or other way). The CLAT can > not >> >easily >> >> discover the address of an IPv4 DNS recursive server, and it has to >> >perform >> >> all DNS resolution over IPv6. >> >> >> >> The CLAT can pass this IPv6 address to downstream IPv6 hosts, but > not >> >to >> >> downstream IPv4 hosts. As such, the CLAT should implement a DNS > proxy. >> >> >> >> Regards, >> >> Masanobu >> >> >> >> >> >> >> 7.4. =A0DNS Proxy Implementation >> >> >> >> >> >> =A0 =A0If a router implement CLAT function, it performs DNS Proxy > for >> >IPv4 >> >> >> =A0 =A0hosts and IPv6 hosts in end-user network. >> >> > >> >> >Why is this necessary? As far as I can see, the client could use > any >> >> >normal DNS server, because the A and AAAA records it needs are >> >completely >> >> >standard. >> >> > >> >> >Regards >> >> > =A0 Brian Carpenter >> >> > >> >> >_______________________________________________ >> >> >v6ops mailing list >> >> >v6ops@ietf.org >> >> >https://www.ietf.org/mailman/listinfo/v6ops >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> =A0NEC AccessTechnica, Ltd. >> >> =A0Product Development Department >> >> =A0Masanobu Kawashima >> >> =A0kawashimam@vx.jp.nec.com >> >> =A0http://www.necat.co.jp/ >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> >> >> _______________________________________________ >> >> v6ops mailing list >> >> v6ops@ietf.org >> >> https://www.ietf.org/mailman/listinfo/v6ops >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> =A0NEC AccessTechnica, Ltd. >> =A0Product Development Department >> =A0Masanobu Kawashima >> =A0kawashimam@vx.jp.nec.com >> =A0http://www.necat.co.jp/ >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From rajiva@cisco.com Mon Jan 30 14:59:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72A721F87A9 for ; Mon, 30 Jan 2012 14:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.051 X-Spam-Level: X-Spam-Status: No, score=-8.051 tagged_above=-999 required=5 tests=[AWL=1.948, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6tXQafmzNZJ for ; Mon, 30 Jan 2012 14:59:07 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B637121F8778 for ; Mon, 30 Jan 2012 14:59:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=11858; q=dns/txt; s=iport; t=1327964346; x=1329173946; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=rmj9rmypNzJ3dL7CeXVSMTtSl7VA1YMtgqp1H/i1JTU=; b=LLcejHMR3sQE/l22KO26l624lsKO+B22Ry7HI53LDDvmrtwtvjMWtHe8 1T3QTWK7oJzrm3ZCPec+72CBjNrNKuwjAOxwHTTzZd0IwzGuPmPIHHJxR x1gf5BYNpgVxlVYwqVGDjxmhEODy9aySBMG9JzvDkY2CL9k1lZRXpjxuO c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGYfJ0+tJXG9/2dsb2JhbABDrleBBYFyAQEBAwEBAQEPARQJPgsFBwQCAQgOAwEDAQEBCgYXAQYBIAYfAwYIAQEEEwgTB4daCZojAZ4+in4rNQwChDIpgkxjBIgMM5dgh2s X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="55005101" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 30 Jan 2012 22:59:06 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q0UMx6UE002911; Mon, 30 Jan 2012 22:59:06 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jan 2012 16:59:05 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Jan 2012 16:59:03 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C073C6425@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] I-D Action: draft-mawatari-v6ops-464xlat-00.txt Thread-Index: AczfoXjnlEHO2I8fQVmQ12o3gFhUqQAAFeuA References: <067E6CE33034954AAC05C9EC85E2577C073C54B4@XMB-RCD-111.cisco.com><20120127103118kawashimam@mail.jp.nec.com><067E6CE33034954AAC05C9EC85E2577C073C63FC@XMB-RCD-111.cisco.com> From: "Rajiv Asati (rajiva)" To: "Cameron Byrne" X-OriginalArrivalTime: 30 Jan 2012 22:59:05.0939 (UTC) FILETIME=[C4628A30:01CCDFA2] Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-mawatari-v6ops-464xlat-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 22:59:08 -0000 Hi Cameron, > Just like a common home router today, the CLAT will assign RFC1918 > space to the home client, but instead of doing NAT44 it will do RFC > 6145 protocol translation as described in the draft. >=20 > Does this answer your question? Yes, it does. And thanks for going over the basics. I gather that CLAT has nothing to do with the public IPv4 address, = though PLAT absolutely does. > The 464XLAT draft is focused on transition to an IPv6-only ISP access > network where IPv4 is highly scarce. So, the explicit assumption is > that RFC1918 IPv4 addresses are used behind the CLAT. Acked. > > On a basic note, How DNS and HTTP be ever useful for ipv6 prefix > > assignment? > > >=20 > I having trouble parsing this last question? Can you explain some = more? Sure. Section 7.7 mentions DNS and HTTP for IPv6 prefix assignment, and = I just don't follow that, thinking about DHCP (or even TR-069) being = used for prefix assignment. Why should they be used (and how)? Cheers, Rajiv > -----Original Message----- > From: Cameron Byrne [mailto:cb.list6@gmail.com] > Sent: Monday, January 30, 2012 5:50 PM > To: Rajiv Asati (rajiva) > Cc: Masanobu Kawashima; IPv6 Operations > Subject: Re: [v6ops] I-D Action: draft-mawatari-v6ops-464xlat-00.txt >=20 > Hi Rajiv, >=20 > On Mon, Jan 30, 2012 at 2:26 PM, Rajiv Asati (rajiva) = > wrote: > > Masanobu-San, > > > > 1. How could the DHCPv4 be used here for v4 address assignment, = since > > CLAT enabled device is supposed to have only IPv6? Does it even make > > sense to use DHCPv4? Perhaps, specify DHCPv6 (new option, say) = usage. > > >=20 > The CLAT may be a home gateway or a cell phone. Facing the WAN ISP > network, the CLAT interface is only IPv6. Facing the subscriber home > network, the CLAT is dual-stack. For IPv6 flows, the CLAT is a basic > IPv6 router. For IPv4 flows, the CLAT is does stateless RFC 6145 > translation. >=20 > In this way, the CLAT is a DHCPv4 server for IPv4 clients in the home > network. It may also be a DHCPv6 server for subscriber IPv6 clients > and a DHCPv6 client of the ISP network. >=20 > Just like a common home router today, the CLAT will assign RFC1918 > space to the home client, but instead of doing NAT44 it will do RFC > 6145 protocol translation as described in the draft. >=20 > Does this answer your question? >=20 > > I agree with you to adding some explicit language and requirement on > > this very point, since IPv4 address assignment is key. Also, it = would be > > worth clarifying whether CLAT cares about private IPv4 or public = IPv4 > > assignment or both. I presume the last, suffice to say. > > >=20 > The 464XLAT draft is focused on transition to an IPv6-only ISP access > network where IPv4 is highly scarce. So, the explicit assumption is > that RFC1918 IPv4 addresses are used behind the CLAT. >=20 > > 2. Agreed. Having DNS-proxy is reasonable. > > >=20 > ACK >=20 > > 3. Agreed. Given that the router function (virtual or not) is = mandatory > > on the CLAT enabled device (gateway or mobile device) for this = proposal > > to work, I would urge you to mention that explicitly not only in = section > > 7.4, but also in section 3 where CLAT is defined first. > > >=20 > ACK >=20 > > 5. Agreed. It would be better to mention DHCP-PD as the recommended > > mechanism, while allowing the other mechanism. I would get rid of = the > > word 'auto' from the title, btw. While we agree to IA_PD, is there a > > need for IA_NA? It would be worth clarifying in that section. > > > > On a basic note, How DNS and HTTP be ever useful for ipv6 prefix > > assignment? > > >=20 > I having trouble parsing this last question? Can you explain some = more? >=20 > Thanks again for the useful review and insightful questions. >=20 > CB >=20 > > Cheers, > > Rajiv > > > >> -----Original Message----- > >> From: Masanobu Kawashima [mailto:kawashimam@vx.jp.nec.com] > >> Sent: Thursday, January 26, 2012 8:31 PM > >> To: Rajiv Asati (rajiva) > >> Cc: Brian E Carpenter; IPv6 Operations > >> Subject: RE: [v6ops] I-D Action: = draft-mawatari-v6ops-464xlat-00.txt > >> > >> > >> Dear Rajiv, > >> > >> Thank you for your comments. > >> > >> >1. How is IPv4 address getting assigned to the host? > >> > >> The 464XLAT architecture does not have any requirements on how the > > IPv4 > >> address is assigned. It can be assigned via static or dhcpv4. We > > should > >> add some language that the subnet must be defined in the CLAT to > > better > >> define the scope of stateless translation. > >> > >> The CLAT can acts just like other home gateways or mobile hotspots > > that > >> assign RFC1918 address (such as 192.168.1.x/24) to clients. There = is > >> nothing special about the CLAT in how it assigns the address to a > > client. > >> > >> > >> >2. Could we not use an existing DHCP option to convey DNS server = IPv4 > >> >address to the CLAT device, which can convey the DNSv4 address the > > same > >> >way as IPv4 address is conveyed? If we could, then we would not = need > > DNS > >> >proxy function on CLAT. > >> > >> The focus of this effort is on an IPv6-only access network. We = don't > > see > >> an architectural benefit of doing 464XLAT translation for each DNS > > request. > >> As stated to Brian, the host may have its own choice of DNS = servers, > >> including IPv4 DNS servers that require 464XLAT, but that is not = the > > design > >> we would like to promote as the ideal case. > >> > >> > >> >3. Section 7.4 requires CLAT device to have router function. What > >> >happens if it is a typical host device (without any router = function)? > >> > > >> >~~~~~~~~~ > >> >7.4. DNS Proxy Implementation > >> > =A0 If a router implement CLAT function, it performs DNS Proxy = for > > IPv4 > >> > =A0 hosts and IPv6 hosts in end-user network. =A0It MUST provide = name > >> > =A0 resolution with IPv6 transport. =A0It does not need DNS64 = [RFC6147] > >> >~~~~~~~~~~~~~~~ > >> > >> The router function can be virtual. This is the case of the Nokia = n900 > > and > >> Android, which are really just hosts. > >> > >> > >> >4. =A0In section 8, did you mean to say IPv4 -> IPv6 -> IPv4 > > translation > >> >below? :-) > >> >~~~~~~~~~~~~ > >> >... > >> > =A0 This 464XLAT architecture has two capabilities. =A0One is a = IPv6 -> > >> > =A0 IPv4 -> IPv6 translation for sharing global IPv4 addresses, > > another > >> >~~~~~~~~~ > >> > >> Yes. It is an error in writing. :-) > >> > >> > >> >5. Section 7.7 (Auto IPv6 Prefix Assignment) could benefit from = some > >> >explicit recommendation (since the current text says source v6 = prefix > >> >assignment is done via DHCPv6-PD or another method, and = destination > > IPv6 > >> >prefix assignment is via some method). > >> > >> It depends on network operator. Why would more explicit help? > >> We would like to keep the options flexible so that solution can = evolve > >> with different wireline and wireless network capabilities. But, we > > agree > >> dhcpv6-pd is good today. We just do not want to exclude other = options > >> without a reason. > >> > >> Regards, > >> Masanobu > >> > >> > >> >Masanobu-san, > >> > > >> >This is an interesting discussion and proposal. Few Q -- > >> > > >> >1. How is IPv4 address getting assigned to the host? > >> >2. Could we not use an existing DHCP option to convey DNS server = IPv4 > >> >address to the CLAT device, which can convey the DNSv4 address the > > same > >> >way as IPv4 address is conveyed? If we could, then we would not = need > > DNS > >> >proxy function on CLAT. > >> >3. Section 7.4 requires CLAT device to have router function. What > >> >happens if it is a typical host device (without any router = function)? > >> > > >> >~~~~~~~~~ > >> >7.4. DNS Proxy Implementation > >> > =A0 If a router implement CLAT function, it performs DNS Proxy = for > > IPv4 > >> > =A0 hosts and IPv6 hosts in end-user network. =A0It MUST provide = name > >> > =A0 resolution with IPv6 transport. =A0It does not need DNS64 = [RFC6147] > >> >~~~~~~~~~~~~~~~ > >> > > >> >4. =A0In section 8, did you mean to say IPv4 -> IPv6 -> IPv4 > > translation > >> >below? :-) > >> >~~~~~~~~~~~~ > >> >... > >> > =A0 This 464XLAT architecture has two capabilities. =A0One is a = IPv6 -> > >> > =A0 IPv4 -> IPv6 translation for sharing global IPv4 addresses, > > another > >> >~~~~~~~~~ > >> > > >> >5. Section 7.7 (Auto IPv6 Prefix Assignment) could benefit from = some > >> >explicit recommendation (since the current text says source v6 = prefix > >> >assignment is done via DHCPv6-PD or another method, and = destination > > IPv6 > >> >prefix assignment is via some method). > >> > > >> >Cheers, > >> >Rajiv > >> > > >> > > >> >> -----Original Message----- > >> >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On > > Behalf > >> >Of > >> >> Masanobu Kawashima > >> >> Sent: Tuesday, January 24, 2012 12:21 PM > >> >> To: Brian E Carpenter > >> >> Cc: IPv6 Operations > >> >> Subject: Re: [v6ops] I-D Action: > > draft-mawatari-v6ops-464xlat-00.txt > >> >> > >> >> > >> >> Hi Brian, > >> >> > >> >> Thank you for your comment. > >> >> > >> >> I take your point. However, a CLAT can only learn the address of = an > >> >IPv6 > >> >> DNS recursive server through DHCPv6 (or other way). The CLAT can > > not > >> >easily > >> >> discover the address of an IPv4 DNS recursive server, and it has = to > >> >perform > >> >> all DNS resolution over IPv6. > >> >> > >> >> The CLAT can pass this IPv6 address to downstream IPv6 hosts, = but > > not > >> >to > >> >> downstream IPv4 hosts. As such, the CLAT should implement a DNS > > proxy. > >> >> > >> >> Regards, > >> >> Masanobu > >> >> > >> >> > >> >> >> 7.4. =A0DNS Proxy Implementation > >> >> >> > >> >> >> =A0 =A0If a router implement CLAT function, it performs DNS = Proxy > > for > >> >IPv4 > >> >> >> =A0 =A0hosts and IPv6 hosts in end-user network. > >> >> > > >> >> >Why is this necessary? As far as I can see, the client could = use > > any > >> >> >normal DNS server, because the A and AAAA records it needs are > >> >completely > >> >> >standard. > >> >> > > >> >> >Regards > >> >> > =A0 Brian Carpenter > >> >> > > >> >> >_______________________________________________ > >> >> >v6ops mailing list > >> >> >v6ops@ietf.org > >> >> >https://www.ietf.org/mailman/listinfo/v6ops > >> >> > >> >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> >> =A0NEC AccessTechnica, Ltd. > >> >> =A0Product Development Department > >> >> =A0Masanobu Kawashima > >> >> =A0kawashimam@vx.jp.nec.com > >> >> =A0http://www.necat.co.jp/ > >> >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> >> > >> >> _______________________________________________ > >> >> v6ops mailing list > >> >> v6ops@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/v6ops > >> > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> =A0NEC AccessTechnica, Ltd. > >> =A0Product Development Department > >> =A0Masanobu Kawashima > >> =A0kawashimam@vx.jp.nec.com > >> =A0http://www.necat.co.jp/ > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Mon Jan 30 15:06:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63C0E11E80D1 for ; Mon, 30 Jan 2012 15:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.172 X-Spam-Level: X-Spam-Status: No, score=-3.172 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncRjrXdEaJKX for ; Mon, 30 Jan 2012 15:06:05 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC5121F875B for ; Mon, 30 Jan 2012 15:06:05 -0800 (PST) Received: by pbdy7 with SMTP id y7so80707pbd.31 for ; Mon, 30 Jan 2012 15:06:05 -0800 (PST) Received-SPF: pass (google.com: domain of cb.list6@gmail.com designates 10.68.222.103 as permitted sender) client-ip=10.68.222.103; Authentication-Results: mr.google.com; spf=pass (google.com: domain of cb.list6@gmail.com designates 10.68.222.103 as permitted sender) smtp.mail=cb.list6@gmail.com; dkim=pass header.i=cb.list6@gmail.com Received: from mr.google.com ([10.68.222.103]) by 10.68.222.103 with SMTP id ql7mr56193855pbc.53.1327964765071 (num_hops = 1); Mon, 30 Jan 2012 15:06:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=X5tG2Wq2YQoLhCwbtgOBVcep6VncO6kTe8jLD5jUFOo=; b=hCO4d2wXzjUUVHqE6/4zPjnG3LrYdR3DRiccGdQn/ePo/ggM79AaJF0M/Qnlg0RKG0 sQuzF/ELJIPh+/Q3ZlYu1XbHD1zUYsgnpNqXiIx2TTr4k5zht7qMyBszmvaa3Q6tUpwL PQXqQBOzC2u+Q7oCQWse1UxKhU9+nd6cvor5s= MIME-Version: 1.0 Received: by 10.68.222.103 with SMTP id ql7mr46085515pbc.53.1327964764944; Mon, 30 Jan 2012 15:06:04 -0800 (PST) Received: by 10.143.78.7 with HTTP; Mon, 30 Jan 2012 15:06:04 -0800 (PST) In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C073C6425@XMB-RCD-111.cisco.com> References: <067E6CE33034954AAC05C9EC85E2577C073C54B4@XMB-RCD-111.cisco.com> <20120127103118kawashimam@mail.jp.nec.com> <067E6CE33034954AAC05C9EC85E2577C073C63FC@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C073C6425@XMB-RCD-111.cisco.com> Date: Mon, 30 Jan 2012 15:06:04 -0800 Message-ID: From: Cameron Byrne To: "Rajiv Asati (rajiva)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-mawatari-v6ops-464xlat-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 23:06:06 -0000 On Mon, Jan 30, 2012 at 2:59 PM, Rajiv Asati (rajiva) wr= ote: > Hi Cameron, > >> Just like a common home router today, the CLAT will assign RFC1918 >> space to the home client, but instead of doing NAT44 it will do RFC >> 6145 protocol translation as described in the draft. >> >> Does this answer your question? > > Yes, it does. And thanks for going over the basics. > > I gather that CLAT has nothing to do with the public IPv4 address, though= PLAT absolutely does. > Yes, a main goal is to decouple edge network growth from IPv4 availability and scale. >> The 464XLAT draft is focused on transition to an IPv6-only ISP access >> network where IPv4 is highly scarce. =A0So, the explicit assumption is >> that RFC1918 IPv4 addresses are used behind the CLAT. > > Acked. > >> > On a basic note, How DNS and HTTP be ever useful for ipv6 prefix >> > assignment? >> > >> >> I having trouble parsing this last question? =A0Can you explain some mor= e? > > Sure. Section 7.7 mentions DNS and HTTP for IPv6 prefix assignment, and I= just don't follow that, thinking about DHCP (or even TR-069) being used fo= r prefix assignment. Why should they be used (and how)? > Ah. I am not sure :) If it is confusing, it may be best to simplify that list. The DNS method might overlap with our explicit mentions of draft-ietf-behave-nat64-discovery-heuristic We can simplify this area to avoid confusion. Thanks again! Cameron > Cheers, > Rajiv > > >> -----Original Message----- >> From: Cameron Byrne [mailto:cb.list6@gmail.com] >> Sent: Monday, January 30, 2012 5:50 PM >> To: Rajiv Asati (rajiva) >> Cc: Masanobu Kawashima; IPv6 Operations >> Subject: Re: [v6ops] I-D Action: draft-mawatari-v6ops-464xlat-00.txt >> >> Hi Rajiv, >> >> On Mon, Jan 30, 2012 at 2:26 PM, Rajiv Asati (rajiva) >> wrote: >> > Masanobu-San, >> > >> > 1. How could the DHCPv4 be used here for v4 address assignment, since >> > CLAT enabled device is supposed to have only IPv6? Does it even make >> > sense to use DHCPv4? Perhaps, specify DHCPv6 (new option, say) usage. >> > >> >> The CLAT may be a home gateway or a cell phone. =A0Facing the WAN ISP >> network, the CLAT interface is only IPv6. =A0Facing the subscriber home >> network, the CLAT is dual-stack. =A0For IPv6 flows, the CLAT is a basic >> IPv6 router. =A0For IPv4 flows, the CLAT is does stateless RFC 6145 >> translation. >> >> In this way, the CLAT is a DHCPv4 server for IPv4 clients in the home >> network. It may also be a DHCPv6 server for subscriber IPv6 clients >> and a DHCPv6 client of the ISP network. >> >> Just like a common home router today, the CLAT will assign RFC1918 >> space to the home client, but instead of doing NAT44 it will do RFC >> 6145 protocol translation as described in the draft. >> >> Does this answer your question? >> >> > I agree with you to adding some explicit language and requirement on >> > this very point, since IPv4 address assignment is key. Also, it would = be >> > worth clarifying whether CLAT cares about private IPv4 or public IPv4 >> > assignment or both. I presume the last, suffice to say. >> > >> >> The 464XLAT draft is focused on transition to an IPv6-only ISP access >> network where IPv4 is highly scarce. =A0So, the explicit assumption is >> that RFC1918 IPv4 addresses are used behind the CLAT. >> >> > 2. Agreed. Having DNS-proxy is reasonable. >> > >> >> ACK >> >> > 3. Agreed. Given that the router function (virtual or not) is mandator= y >> > on the CLAT enabled device (gateway or mobile device) for this proposa= l >> > to work, I would urge you to mention that explicitly not only in secti= on >> > 7.4, but also in section 3 where CLAT is defined first. >> > >> >> ACK >> >> > 5. Agreed. It would be better to mention DHCP-PD as the recommended >> > mechanism, while allowing the other mechanism. I would get rid of the >> > word 'auto' from the title, btw. While we agree to IA_PD, is there a >> > need for IA_NA? It would be worth clarifying in that section. >> > >> > On a basic note, How DNS and HTTP be ever useful for ipv6 prefix >> > assignment? >> > >> >> I having trouble parsing this last question? =A0Can you explain some mor= e? >> >> Thanks again for the useful review and insightful questions. >> >> CB >> >> > Cheers, >> > Rajiv >> > >> >> -----Original Message----- >> >> From: Masanobu Kawashima [mailto:kawashimam@vx.jp.nec.com] >> >> Sent: Thursday, January 26, 2012 8:31 PM >> >> To: Rajiv Asati (rajiva) >> >> Cc: Brian E Carpenter; IPv6 Operations >> >> Subject: RE: [v6ops] I-D Action: draft-mawatari-v6ops-464xlat-00.txt >> >> >> >> >> >> Dear Rajiv, >> >> >> >> Thank you for your comments. >> >> >> >> >1. How is IPv4 address getting assigned to the host? >> >> >> >> The 464XLAT architecture does not have any requirements on how the >> > IPv4 >> >> address is assigned. It can be assigned via static or dhcpv4. We >> > should >> >> add some language that the subnet must be defined in the CLAT to >> > better >> >> define the scope of stateless translation. >> >> >> >> The CLAT can acts just like other home gateways or mobile hotspots >> > that >> >> assign RFC1918 address (such as 192.168.1.x/24) to clients. There is >> >> nothing special about the CLAT in how it assigns the address to a >> > client. >> >> >> >> >> >> >2. Could we not use an existing DHCP option to convey DNS server IPv= 4 >> >> >address to the CLAT device, which can convey the DNSv4 address the >> > same >> >> >way as IPv4 address is conveyed? If we could, then we would not need >> > DNS >> >> >proxy function on CLAT. >> >> >> >> The focus of this effort is on an IPv6-only access network. We don't >> > see >> >> an architectural benefit of doing 464XLAT translation for each DNS >> > request. >> >> As stated to Brian, the host may have its own choice of DNS servers, >> >> including IPv4 DNS servers that require 464XLAT, but that is not the >> > design >> >> we would like to promote as the ideal case. >> >> >> >> >> >> >3. Section 7.4 requires CLAT device to have router function. What >> >> >happens if it is a typical host device (without any router function)= ? >> >> > >> >> >~~~~~~~~~ >> >> >7.4. DNS Proxy Implementation >> >> > =A0 If a router implement CLAT function, it performs DNS Proxy for >> > IPv4 >> >> > =A0 hosts and IPv6 hosts in end-user network. =A0It MUST provide na= me >> >> > =A0 resolution with IPv6 transport. =A0It does not need DNS64 [RFC6= 147] >> >> >~~~~~~~~~~~~~~~ >> >> >> >> The router function can be virtual. This is the case of the Nokia n90= 0 >> > and >> >> Android, which are really just hosts. >> >> >> >> >> >> >4. =A0In section 8, did you mean to say IPv4 -> IPv6 -> IPv4 >> > translation >> >> >below? :-) >> >> >~~~~~~~~~~~~ >> >> >... >> >> > =A0 This 464XLAT architecture has two capabilities. =A0One is a IPv= 6 -> >> >> > =A0 IPv4 -> IPv6 translation for sharing global IPv4 addresses, >> > another >> >> >~~~~~~~~~ >> >> >> >> Yes. It is an error in writing. :-) >> >> >> >> >> >> >5. Section 7.7 (Auto IPv6 Prefix Assignment) could benefit from some >> >> >explicit recommendation (since the current text says source v6 prefi= x >> >> >assignment is done via DHCPv6-PD or another method, and destination >> > IPv6 >> >> >prefix assignment is via some method). >> >> >> >> It depends on network operator. Why would more explicit help? >> >> We would like to keep the options flexible so that solution can evolv= e >> >> with different wireline and wireless network capabilities. But, we >> > agree >> >> dhcpv6-pd is good today. We just do not want to exclude other options >> >> without a reason. >> >> >> >> Regards, >> >> Masanobu >> >> >> >> >> >> >Masanobu-san, >> >> > >> >> >This is an interesting discussion and proposal. Few Q -- >> >> > >> >> >1. How is IPv4 address getting assigned to the host? >> >> >2. Could we not use an existing DHCP option to convey DNS server IPv= 4 >> >> >address to the CLAT device, which can convey the DNSv4 address the >> > same >> >> >way as IPv4 address is conveyed? If we could, then we would not need >> > DNS >> >> >proxy function on CLAT. >> >> >3. Section 7.4 requires CLAT device to have router function. What >> >> >happens if it is a typical host device (without any router function)= ? >> >> > >> >> >~~~~~~~~~ >> >> >7.4. DNS Proxy Implementation >> >> > =A0 If a router implement CLAT function, it performs DNS Proxy for >> > IPv4 >> >> > =A0 hosts and IPv6 hosts in end-user network. =A0It MUST provide na= me >> >> > =A0 resolution with IPv6 transport. =A0It does not need DNS64 [RFC6= 147] >> >> >~~~~~~~~~~~~~~~ >> >> > >> >> >4. =A0In section 8, did you mean to say IPv4 -> IPv6 -> IPv4 >> > translation >> >> >below? :-) >> >> >~~~~~~~~~~~~ >> >> >... >> >> > =A0 This 464XLAT architecture has two capabilities. =A0One is a IPv= 6 -> >> >> > =A0 IPv4 -> IPv6 translation for sharing global IPv4 addresses, >> > another >> >> >~~~~~~~~~ >> >> > >> >> >5. Section 7.7 (Auto IPv6 Prefix Assignment) could benefit from some >> >> >explicit recommendation (since the current text says source v6 prefi= x >> >> >assignment is done via DHCPv6-PD or another method, and destination >> > IPv6 >> >> >prefix assignment is via some method). >> >> > >> >> >Cheers, >> >> >Rajiv >> >> > >> >> > >> >> >> -----Original Message----- >> >> >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On >> > Behalf >> >> >Of >> >> >> Masanobu Kawashima >> >> >> Sent: Tuesday, January 24, 2012 12:21 PM >> >> >> To: Brian E Carpenter >> >> >> Cc: IPv6 Operations >> >> >> Subject: Re: [v6ops] I-D Action: >> > draft-mawatari-v6ops-464xlat-00.txt >> >> >> >> >> >> >> >> >> Hi Brian, >> >> >> >> >> >> Thank you for your comment. >> >> >> >> >> >> I take your point. However, a CLAT can only learn the address of a= n >> >> >IPv6 >> >> >> DNS recursive server through DHCPv6 (or other way). The CLAT can >> > not >> >> >easily >> >> >> discover the address of an IPv4 DNS recursive server, and it has t= o >> >> >perform >> >> >> all DNS resolution over IPv6. >> >> >> >> >> >> The CLAT can pass this IPv6 address to downstream IPv6 hosts, but >> > not >> >> >to >> >> >> downstream IPv4 hosts. As such, the CLAT should implement a DNS >> > proxy. >> >> >> >> >> >> Regards, >> >> >> Masanobu >> >> >> >> >> >> >> >> >> >> 7.4. =A0DNS Proxy Implementation >> >> >> >> >> >> >> >> =A0 =A0If a router implement CLAT function, it performs DNS Pro= xy >> > for >> >> >IPv4 >> >> >> >> =A0 =A0hosts and IPv6 hosts in end-user network. >> >> >> > >> >> >> >Why is this necessary? As far as I can see, the client could use >> > any >> >> >> >normal DNS server, because the A and AAAA records it needs are >> >> >completely >> >> >> >standard. >> >> >> > >> >> >> >Regards >> >> >> > =A0 Brian Carpenter >> >> >> > >> >> >> >_______________________________________________ >> >> >> >v6ops mailing list >> >> >> >v6ops@ietf.org >> >> >> >https://www.ietf.org/mailman/listinfo/v6ops >> >> >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> >> =A0NEC AccessTechnica, Ltd. >> >> >> =A0Product Development Department >> >> >> =A0Masanobu Kawashima >> >> >> =A0kawashimam@vx.jp.nec.com >> >> >> =A0http://www.necat.co.jp/ >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> >> >> >> >> _______________________________________________ >> >> >> v6ops mailing list >> >> >> v6ops@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/v6ops >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> =A0NEC AccessTechnica, Ltd. >> >> =A0Product Development Department >> >> =A0Masanobu Kawashima >> >> =A0kawashimam@vx.jp.nec.com >> >> =A0http://www.necat.co.jp/ >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops From dragos.ilie@gmail.com Tue Jan 31 01:50:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4435A21F8737 for ; Tue, 31 Jan 2012 01:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGs9A471CcwJ for ; Tue, 31 Jan 2012 01:50:25 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A7C6D21F852B for ; Tue, 31 Jan 2012 01:50:25 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so3788301vbb.31 for ; Tue, 31 Jan 2012 01:50:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=JH8lvZ/CrFWL3fgfoSvO0/YoFI0Xyg9tV8FC02H5Z/A=; b=oHF4ctCuNRNf3xQ4lNW8QAN1AcUregffLhBqd8lc2xC1s+bWCdKEltuE58+Tbdrv0y 1OZOJWxV1MU7zxonmVImsUJC6vnUpUPNVOHgzXa8h4GZpOwJ0NRplw30b9FP69KSkGmV KAuwPgw7x5sl16GenqhvQBTPeYImEiymyxjgE= MIME-Version: 1.0 Received: by 10.52.30.81 with SMTP id q17mr9727223vdh.115.1328003425203; Tue, 31 Jan 2012 01:50:25 -0800 (PST) Received: by 10.52.21.244 with HTTP; Tue, 31 Jan 2012 01:50:25 -0800 (PST) Date: Tue, 31 Jan 2012 10:50:25 +0100 Message-ID: From: Dragos Ilie To: v6ops@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] Minimum MTU size X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 09:51:42 -0000 Hello! I am trying to find out the underlaying reason to select a 1280 bytes minimum MTU for IPv6 (as opposed to any other value such as 1400 or 1500 bytes). For example, I heard that the reason for selecting a 576-bytes min MTU for IPv4 has to do with packet sizes for DNS and X.25. I would appreciated it if somebody can explain the motivation for the 1280-byte choice in the case of IPv6 or point me to relevant information sources. My apologies if this is the wrong forum for asking this question. Sincerely, Dragos From Francis.Dupont@fdupont.fr Tue Jan 31 02:18:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BCD21F859E for ; Tue, 31 Jan 2012 02:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FDOg0vfudr9 for ; Tue, 31 Jan 2012 02:18:02 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id EE48721F8535 for ; Tue, 31 Jan 2012 02:18:01 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q0VAHxWd053879; Tue, 31 Jan 2012 11:17:59 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201201311017.q0VAHxWd053879@givry.fdupont.fr> From: Francis Dupont To: Dragos Ilie In-reply-to: Your message of Tue, 31 Jan 2012 10:50:25 +0100. Date: Tue, 31 Jan 2012 11:17:59 +0100 Sender: Francis.Dupont@fdupont.fr Cc: v6ops@ietf.org Subject: Re: [v6ops] Minimum MTU size X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 10:18:02 -0000 In your previous mail you wrote: > I am trying to find out the underlaying reason to select a 1280 bytes > minimum MTU for IPv6 (as opposed to any other value such as 1400 or > 1500 bytes). For example, I heard that the reason for selecting a > 576-bytes min MTU for IPv4 has to do with packet sizes for DNS and > X.25. I would appreciated it if somebody can explain the motivation > for the 1280-byte choice in the case of IPv6 or point me to relevant > information sources. => first the min MTU for IPv4 is 68 bytes (maximum sized header + 8), not 576 which is the minimum size for the reassembly (1500 for IPv6). The choice of 1280 was for 1024 of data (aka application payload) and 256 for headers. Regards Francis.Dupont@fdupont.fr From dragos.ilie@gmail.com Tue Jan 31 02:40:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E5221F867D for ; Tue, 31 Jan 2012 02:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWekdSrZp6Fn for ; Tue, 31 Jan 2012 02:40:39 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8843521F8652 for ; Tue, 31 Jan 2012 02:40:39 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so25728vbb.31 for ; Tue, 31 Jan 2012 02:40:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=b6kh2y6tsNM/Exzqy6OCAYfshPYxBRDC8CKS2eYYZPo=; b=EBYujBGY6cOFegsOpC/MT/ohJF5S3Dl8l51c2IHmRzHKOUiFBO0f1IZwmWb2flGj5h NDInF+bkT2+zlaygFx2hlyTKc3Xeee8RuGiFX8xZv6Mp3fD4Wsa6V8cqYDJXTF/tzWT0 DZe3RiMkTDkqZUNM3TU8suV3eFuMPMLO7oESg= MIME-Version: 1.0 Received: by 10.52.24.35 with SMTP id r3mr9931258vdf.81.1328006439092; Tue, 31 Jan 2012 02:40:39 -0800 (PST) Received: by 10.52.21.244 with HTTP; Tue, 31 Jan 2012 02:40:39 -0800 (PST) In-Reply-To: <201201311017.q0VAHxWd053879@givry.fdupont.fr> References: <201201311017.q0VAHxWd053879@givry.fdupont.fr> Date: Tue, 31 Jan 2012 11:40:39 +0100 Message-ID: From: Dragos Ilie To: Francis Dupont Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] Minimum MTU size X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 10:40:40 -0000 Thank you! That is what I was looking for. Regards, Dragos Ilie On Tue, Jan 31, 2012 at 11:17 AM, Francis Dupont wrote: > =A0In your previous mail you wrote: > >> =A0I am trying to find out the underlaying reason to select a 1280 bytes >> =A0minimum MTU for IPv6 (as opposed to any other value such as 1400 or >> =A01500 bytes). For example, I heard that the reason for selecting a >> =A0576-bytes min MTU for IPv4 has to do with packet sizes for DNS and >> =A0X.25. I would appreciated it if somebody can explain the motivation >> =A0for the 1280-byte choice in the case of IPv6 or point me to relevant >> =A0information sources. > > =3D> first the min MTU for IPv4 is 68 bytes (maximum sized header + 8), > not 576 which is the minimum size for the reassembly (1500 for IPv6). > The choice of 1280 was for 1024 of data (aka application payload) and > 256 for headers. > > Regards > > Francis.Dupont@fdupont.fr From ales.vizdal@t-mobile.cz Tue Jan 31 04:07:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A4721F8606 for ; Tue, 31 Jan 2012 04:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HL1dTIYGZjm8 for ; Tue, 31 Jan 2012 04:07:32 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 2B95321F8601 for ; Tue, 31 Jan 2012 04:07:29 -0800 (PST) Received: from srvhk504.rdm.cz (unknown [10.246.143.96]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 0D3AD28580F; Tue, 31 Jan 2012 13:07:28 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::2cec:9ace:94f2:601a]) by srvhk504.rdm.cz ([fe80::744e:351e:b5b:fd01%12]) with mapi; Tue, 31 Jan 2012 13:07:27 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: "STARK, BARBARA H" , Wuyts Carl , Ray Hunter Date: Tue, 31 Jan 2012 13:08:19 +0100 Thread-Topic: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt Thread-Index: AczNOgwqFdWfvcPlShSmwOqFVV6b9QBYC7AAABFgEeAETB+nAA== Message-ID: <1808340F7EC362469DDFFB112B37E2FCC67E2A14F2@SRVHKE02.rdm.cz> References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com><867F4B6A1672E541A94676D556793ACD0CB56952D5@MOPESMBX01.eu.thmulti.com><8FFE15EA-B90E-4553-A776-7C2C5C221852@employees.org><867F4B6A1672E541A94676D556793ACD0CB569536F@MOPESMBX01.eu.thmulti.com><478BBBA2-3D32-4038-A5E4-CD886A417EB8@employees.org><867F4B6A1672E541A94676D556793ACD0CB56953B7@MOPESMBX01.eu.thmulti.com><1E00A66B-B0A3-4FFC-AF0E-ED3A2CACEA60@employees.org><867F4B6A1672E541A94676D556793ACD0CB56953BE@MOPESMBX01.eu.thmulti.com> <750BF7861EBBE048B3E648B4BB6E8F4F21CFE5E5@crexc50p> <4F083E04.5050908@globis.net> <867F4B6A1672E541A94676D556793ACD0CB6819DC3@MOPESMBX01.eu.thmulti.com> <750BF7861EBBE048B3E648B4BB6E8F4F21CFECA1@crexc50p> In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F21CFECA1@crexc50p> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 12:07:33 -0000 Hi, let me comment from a mobile operator perspective. (sorry for re-reposting, email formatting was wrong last time) > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= STARK, BARBARA H > Sent: Monday, January 09, 2012 5:39 PM > To: Wuyts Carl; Ray Hunter > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt > > By actively engaging in the creation of RFC 6204 and 6204bis, the operato= r community engaged in this effort has effectively said that: > 1. Operators who expect 6204(bis)-compliant CE routers to work with their= IPv6 access networks won't do things in their IPv6 access networks that wi= ll cause these CE routers not to work. Operators who do not expect these CE= routers to=20 > work in their access networks may well do things that cause these CE rout= ers not to work in their access networks. It is absolutely true that a 6204= (bis)-compliant CE router cannot be expected to work in an environment wher= e it is not=20 > expected to work. > 2. Operators who expect 6204(bis)-compliant CE routers to establish a nat= ive IPv6 connection with their access networks will send RA. That RA may or= may not have a SLAAC ("A") prefix. This includes operators who do PPP. See= BBF TR-187 > http://www.broadband-forum.org/technical/download/TR-187.pdf.= [Things may change in the future, but that change will have to be coordina= ted.] > 3. Operators who expect 6204(bis)-compliant CE routers to establish a nat= ive IPv6 connection with their IPv6 access networks will have a DHCPv6 serv= er that provides IA_PD and DNS. It may or may not supply IA_NA or other con= fig info. The above listed expectations so far comply with 3GPP networks at the scena= rio setting level. > The above operator expectations are implicit in RFC 6204(bis). > > The requirements tell the CE router that > a) If you don't get an RA or a response to DHCPv6 SOLICIT, then you aren'= t expected to be able to establish an IPv6 connection with this access netw= ork. > b) If you get an "A" prefix in the RA, do SLAAC. If you don't get an "A" = prefix, that's ok. Clearly, the access network doesn't expect you to do SLA= AC if it doesn't send an "A" prefix. If it does send an "A" prefix, then it= does expect you to do > SLAAC. > c) It's OK to always ask for IA_NA. But if M=3D1, then you MUST ask for I= A_NA. If you get an IA_NA offer, take it. If you don't get one, that's ok. = If the access network doesn't offer an IA_NA after you've asked for one (or= if M=3D0), then clearly > it doesn't intend for you to have one. > d) Always ask for IA_PD. If you don't get IA_PD, then you aren't expected= to be able to establish IPv6 connectivity for your LAN. This access networ= k has no intention of supplying your LAN with IPv6 connectivity.=20 > e) If you get IA_PD but no IA_NA and you get RA without "A" prefix, then = take a single address from a /64, and associate it with an interface (not t= he WAN interface) where you can use the address for sending/receiving traff= ic to/from the=20 > LAN/WAN. IMO, the entire rest of the /64 should always be available for u= se in the LAN. The "unnumbered" model should never lock up an entire prefix= . But we don't say that anywhere. So I guess operators can't expect this to= be the case. I > wouldn't be opposed to either stating that the unnumbered= model might lock up a /64 prefix, or requiring that it not lock up a /64 p= refix. But how to not lock up a prefix (if that's required) should be up to= the CE router vendor to implement. The above is actually more or less aligned with 3GPP networks, which is fin= e, except that it does not spell out the exclusion case (as already pointed out on the list earlier, the exclusion case is not 3GPP= specific and could be used in other deployments as well).=20 That means that the delegated prefix in IA_PD might be just half of the res= erved prefix to the subscription, in order for the PGW to be able to do the aggregation of the PDN connection /64 prefix and the d= elegated prefix to a single prefix. So it can work, but for the network to be 'sure' things work right, it has = to waste some address space with the above mentioned work-around. Does the 6204bis design team have a clear view on the OPTION_PD_EXCLUDE as = specified in draft-ietf-dhc-pd-exclude? > It's important to understand that if an operator wants these CE routers t= o work with their access network, then the operator won't do things that wi= ll cause the device not to work. If an operator doesn't want the CE router = to work with their > access network, then you shouldn't expect to be able t= o create requirements that will allow the device to work. Operators should = expect CE routers to request IA_NA, independent of what the operator puts i= n the RA (M bits, "A" flags). I=20 > agree that it's not a good idea for the operator to support both SLAAC an= d IA_NA. And operators know this. Contrary to popular belief, we aren't clu= eless. While these requirements do not preclude stupidity in access network= design,=20 > operators are working hard (and together) to avoid stupid access network = design. And we're working with the CE community to try to make sure that we= express (reasonable) expectations for devices to work with the access netw= orks we > design. Again, you're absolutely correct that the expectations we've expr= essed are not intended to ensure that the devices work on access networks o= f operators that have not been engaged in creation of 6204(bis). But I can = only assume=20 > that such operators have no interest in such interoperability. Otherwise,= they would be here. > Barbara Cheers, Ales =A0=20 From brian.e.carpenter@gmail.com Tue Jan 31 11:55:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC56511E80EB for ; Tue, 31 Jan 2012 11:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.231 X-Spam-Level: X-Spam-Status: No, score=-103.231 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVy6BGh-crFc for ; Tue, 31 Jan 2012 11:55:14 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id A5A6511E80E1 for ; Tue, 31 Jan 2012 11:55:14 -0800 (PST) Received: by eekc41 with SMTP id c41so111432eek.31 for ; Tue, 31 Jan 2012 11:55:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/d6p6dEFyLPX8SDqHqmKAiYZuOeX/xezgnB8sAWgCFY=; b=npt9VMxC8+ZQWcbNPuCaabz2TLMR9GQ0StJUdxPnCXyf15BFY0D5aUhByvpz2I+s4r SoHwL2VkwMifRMB0T9G/UIxMnYj51DltFIg0MmsTaSvvEfaMHN3ZwOvjtecvRzle/TIq 1Ye/Qq7Bp11fsx3v5ErbeIaazzOqQf/ehnt1w= Received: by 10.14.9.222 with SMTP id 70mr1516535eet.28.1328039713831; Tue, 31 Jan 2012 11:55:13 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id t11sm62804243eea.10.2012.01.31.11.55.10 (version=SSLv3 cipher=OTHER); Tue, 31 Jan 2012 11:55:12 -0800 (PST) Message-ID: <4F284715.6050905@gmail.com> Date: Wed, 01 Feb 2012 08:55:01 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dragos Ilie References: <201201311017.q0VAHxWd053879@givry.fdupont.fr> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Minimum MTU size X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 19:55:15 -0000 I think it was noted at the time that this allowed easily for some tunnel header overhead within a 1500 link MTU packet, and was therefore a reasonably efficient value. BTW 576 = 512 + 64, and I'm sure that isn't a coincidence either. Regards Brian Carpenter On 2012-01-31 23:40, Dragos Ilie wrote: > Thank you! That is what I was looking for. > > Regards, > Dragos Ilie > > > > On Tue, Jan 31, 2012 at 11:17 AM, Francis Dupont > wrote: >> In your previous mail you wrote: >> >>> I am trying to find out the underlaying reason to select a 1280 bytes >>> minimum MTU for IPv6 (as opposed to any other value such as 1400 or >>> 1500 bytes). For example, I heard that the reason for selecting a >>> 576-bytes min MTU for IPv4 has to do with packet sizes for DNS and >>> X.25. I would appreciated it if somebody can explain the motivation >>> for the 1280-byte choice in the case of IPv6 or point me to relevant >>> information sources. >> => first the min MTU for IPv4 is 68 bytes (maximum sized header + 8), >> not 576 which is the minimum size for the reassembly (1500 for IPv6). >> The choice of 1280 was for 1024 of data (aka application payload) and >> 256 for headers. >> >> Regards >> >> Francis.Dupont@fdupont.fr > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >