From wesley.george@twcable.com Wed Jun 1 07:48:25 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E985AE06E0 for ; Wed, 1 Jun 2011 07:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.187 X-Spam-Level: X-Spam-Status: No, score=0.187 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Lc7EREWRJ-K for ; Wed, 1 Jun 2011 07:48:24 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 26BBDE0729 for ; Wed, 1 Jun 2011 07:47:55 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.65,303,1304308800"; d="scan'208";a="232474498" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 01 Jun 2011 10:53:43 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.29]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Wed, 1 Jun 2011 10:47:54 -0400 From: "George, Wesley" To: "int-area@ietf.org" Date: Wed, 1 Jun 2011 10:47:52 -0400 Thread-Topic: New Version Notification for draft-george-ipv6-required-02.txt Thread-Index: AcwgaGR4suOrE0QmQSScOXBniSX8hQAAJOXA Message-ID: <34E4F50CAFA10349A41E0756550084FB0660DC20@PRVPEXVS04.corp.twcable.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Howard, Lee" , "cdl@asgaard.org" Subject: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 14:48:25 -0000 QWZ0ZXIgdGhlIGRpc2N1c3Npb24gb2YgdGhpcyBkcmFmdCBpbiBQcmFndWUgYW5kIHdpdGggdGhl IFdHIGNoYWlycyBhbmQgQURzLCB3ZSBoYXZlIHVwZGF0ZWQgaXQgdG8gYWRkcmVzcyBhIGZldyBj b21tZW50cywgYnV0IHByaW1hcmlseSB0byByZW1vdmUgdGhlIGxhbmd1YWdlIGRpcmVjdGluZyBJ RVRGIGFjdGlvbi4gVGhpcyBsaW1pdHMgdGhlIGRyYWZ0IHRvIHNpbXBseSByZXF1aXJpbmcgSVB2 NiBmb3IgSVAtY2FwYWJsZSBkZXZpY2VzLCBhbmQgc2hvdWxkIGFkZHJlc3MgdGhlIGNvbmNlcm4g YWJvdXQgd2hldGhlciBpdCBpbnRlcmZlcmVzIHdpdGggZXhpc3RpbmcgV0cgYWN0aW9ucyBhcyB3 ZWxsIGFzIHRoZSByZWNvbW1lbmRhdGlvbiB0aGF0IG5vcm1hbGx5IElFVEYgYWN0aW9uIGRpcmVj dGlvbnMgYXJlIGRvbmUgdmlhIEJDUCByYXRoZXIgdGhhbiBzdGFuZGFyZHMtdHJhY2sgZG9jdW1l bnRzLg0KDQpXZSB3b3VsZCBsaWtlIHRvIGFzayBmb3IgZm9ybWFsIFdHIGFkb3B0aW9uIG9mIHRo aXMgZHJhZnQsIGFzIHdlbGwgYXMgcmV2aWV3cyB0byBzZWUgaWYgaXQgY2FuIHNvb24gYmUgbWFk ZSByZWFkeSBmb3IgV0dMQyAoYXNzdW1pbmcgV0cgYWRvcHRpb24gaXMgc3VjY2Vzc2Z1bCkuDQpo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nZW9yZ2UtaXB2Ni1yZXF1aXJlZC0wMg0K DQpBbnkgZGlzY3Vzc2lvbiBhYm91dCBJRVRGJ3MgcmVzcG9uc2UgdG8gdGhpcyBkcmFmdCAoaW4g dGVybXMgb2YgaG93IFdHcyBvcGVyYXRlLCB0aGVpciBjaGFydGVycywgZXRjKSB3aWxsIGJlIGlz c3VlZCBpbiBhIHNlcGFyYXRlIEJDUCBkcmFmdC4gUmlnaHQgbm93LCB3ZSB3YW50IHRvIGZvY3Vz IG9uIGdldHRpbmcgdGhpcyBkcmFmdCBvdXQgc28gdGhhdCBpdCBjYW4gcHJvdmlkZSBndWlkYW5j ZSB0byBJUHY2IGltcGxlbWVudG9ycy4NCg0KVGhhbmtzIQ0KDQpXZXMgR2VvcmdlIGFuZCBjby1h dXRob3JzLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQpTZW50OiBX ZWRuZXNkYXksIEp1bmUgMDEsIDIwMTEgMTA6MzAgQU0NClRvOiBHZW9yZ2UsIFdlc2xleQ0KQ2M6 IEhvd2FyZCwgTGVlOyBEb25sZXksIENocmlzIChDYWJsZSBMYWJzKTsgR2VvcmdlLCBXZXNsZXk7 IGNkbEBhc2dhYXJkLm9yZw0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1nZW9yZ2UtaXB2Ni1yZXF1aXJlZC0wMi50eHQNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQs IGRyYWZ0LWdlb3JnZS1pcHY2LXJlcXVpcmVkLTAyLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IFdlc2xleSBHZW9yZ2UgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0 b3J5Lg0KDQpGaWxlbmFtZTogICAgICAgIGRyYWZ0LWdlb3JnZS1pcHY2LXJlcXVpcmVkDQpSZXZp c2lvbjogICAgICAgIDAyDQpUaXRsZTogICAgICAgICAgIElQdjYgU3VwcG9ydCBSZXF1aXJlZCBm b3IgYWxsIElQLWNhcGFibGUgbm9kZXMNCkNyZWF0aW9uIGRhdGU6ICAgMjAxMS0wNi0wMQ0KV0cg SUQ6ICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogNw0K DQpBYnN0cmFjdDoNCiAgIEdpdmVuIHRoZSBnbG9iYWwgbGFjayBvZiBhdmFpbGFibGUgSVB2NCBz cGFjZSwgYW5kIGxpbWl0YXRpb25zIGluDQogICBJUHY0IGV4dGVuc2lvbiBhbmQgdHJhbnNpdGlv biB0ZWNobm9sb2dpZXMsIHRoaXMgZG9jdW1lbnQgZGVwcmVjYXRlcw0KICAgdGhlIGNvbmNlcHQg dGhhdCBhbiBJUC1jYXBhYmxlIG5vZGUgTUFZIHN1cHBvcnQgSVB2NCBfb25seV8sIGFuZA0KICAg cmVkZWZpbmVzIGFuIElQLWNhcGFibGUgbm9kZSBhcyBvbmUgd2hpY2ggc3VwcG9ydHMgZWl0aGVy IElQdjYgX29ubHlfDQogICBvciBJUHY0L0lQdjYgZHVhbC1zdGFjay4gIFRoaXMgZG9jdW1lbnQg dXBkYXRlcyBSRkMxODEyLCAxMTIyIGFuZA0KICAgNDA4NCB0byByZWZsZWN0IHRoZSBjaGFuZ2Ug aW4gcmVxdWlyZW1lbnRzLg0KDQoNCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQpUaGlzIEUt bWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBD YWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlk ZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIg Q2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUg aW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVi eSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcs IG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFj aG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1 bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRo ZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4N Cg== From julien.ietf@gmail.com Wed Jun 1 13:48:19 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31EF3E07A5 for ; Wed, 1 Jun 2011 13:48:19 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hldg4ehmmfT2 for ; Wed, 1 Jun 2011 13:48:18 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C3E17E06D9 for ; Wed, 1 Jun 2011 13:48:17 -0700 (PDT) Received: by bwz13 with SMTP id 13so441553bwz.31 for ; Wed, 01 Jun 2011 13:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Psg98tvdNL1cFhp5p3Qip3f+AhZhUboKYzAiGZFzc3s=; b=LqQc7mLZR4/ZIEE/SHkItmMfDNKK9mUA/RfMOEGyynvN6XqjsDC00EQcH6WJ3n/n56 c0z53H4kR49/yIUkeXMQreUU3OTxSlA1uiWrzqrimrS0xcVLIxwKJAu85fX0BkNghVOZ XRVmCkwgWUHyAQvmsE4+OZvxgSR25HVJXElO4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RRkikZrx5WT5hl7AXsxnjCeLbLhMQykkSMy79gE70RR5sAjqIKpplatzh6ys2YlIq9 jTfNFkOTeiQiz/5cnI49utLMGPx4o0KX1NKRT8iudVCIBtPYYq1L0+a/+2NhIApxEYQL 30D0CitpKMlZqkAjvob8fhcBCrZJQtkYkc+jQ= MIME-Version: 1.0 Received: by 10.204.46.132 with SMTP id j4mr2203881bkf.86.1306961296769; Wed, 01 Jun 2011 13:48:16 -0700 (PDT) Received: by 10.204.61.3 with HTTP; Wed, 1 Jun 2011 13:48:16 -0700 (PDT) In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0660DC20@PRVPEXVS04.corp.twcable.com> References: <34E4F50CAFA10349A41E0756550084FB0660DC20@PRVPEXVS04.corp.twcable.com> Date: Wed, 1 Jun 2011 13:48:16 -0700 Message-ID: From: Julien Laganier To: "George, Wesley" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Howard, Lee" , "int-area@ietf.org" , "cdl@asgaard.org" Subject: Re: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 20:48:19 -0000 Folks, At this point we' d like to ask WG participants whether or not there is interest in adopting this document as intarea WG draft. Please express your opinions on the mailing list. --julien & scott On Wed, Jun 1, 2011 at 7:47 AM, George, Wesley wrote: > After the discussion of this draft in Prague and with the WG chairs and A= Ds, we have updated it to address a few comments, but primarily to remove t= he language directing IETF action. This limits the draft to simply requirin= g IPv6 for IP-capable devices, and should address the concern about whether= it interferes with existing WG actions as well as the recommendation that = normally IETF action directions are done via BCP rather than standards-trac= k documents. > > We would like to ask for formal WG adoption of this draft, as well as rev= iews to see if it can soon be made ready for WGLC (assuming WG adoption is = successful). > http://tools.ietf.org/html/draft-george-ipv6-required-02 > > Any discussion about IETF's response to this draft (in terms of how WGs o= perate, their charters, etc) will be issued in a separate BCP draft. Right = now, we want to focus on getting this draft out so that it can provide guid= ance to IPv6 implementors. > > Thanks! > > Wes George and co-authors. > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, June 01, 2011 10:30 AM > To: George, Wesley > Cc: Howard, Lee; Donley, Chris (Cable Labs); George, Wesley; cdl@asgaard.= org > Subject: New Version Notification for draft-george-ipv6-required-02.txt > > A new version of I-D, draft-george-ipv6-required-02.txt has been successf= ully submitted by Wesley George and posted to the IETF repository. > > Filename: =A0 =A0 =A0 =A0draft-george-ipv6-required > Revision: =A0 =A0 =A0 =A002 > Title: =A0 =A0 =A0 =A0 =A0 IPv6 Support Required for all IP-capable nodes > Creation date: =A0 2011-06-01 > WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission > Number of pages: 7 > > Abstract: > =A0 Given the global lack of available IPv4 space, and limitations in > =A0 IPv4 extension and transition technologies, this document deprecates > =A0 the concept that an IP-capable node MAY support IPv4 _only_, and > =A0 redefines an IP-capable node as one which supports either IPv6 _only_ > =A0 or IPv4/IPv6 dual-stack. =A0This document updates RFC1812, 1122 and > =A0 4084 to reflect the change in requirements. > > > > > The IETF Secretariat > > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or subject to copyr= ight 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 t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately and permanently delete the original and any copy of this E-mail = and any printout. > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > From adurand@juniper.net Wed Jun 1 18:51:36 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA361E070A for ; Wed, 1 Jun 2011 18:51:36 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JSmBWW+PTyi for ; Wed, 1 Jun 2011 18:51:36 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7F814E067B for ; Wed, 1 Jun 2011 18:51:34 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTebsou4u58uUZZlfe4/Kyt2jBlxDr/Xw@postini.com; Wed, 01 Jun 2011 18:51:35 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 1 Jun 2011 18:51:10 -0700 From: Alain Durand To: Julien Laganier Date: Wed, 1 Jun 2011 18:51:08 -0700 Thread-Topic: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt Thread-Index: Acwgx4s3sBL/eCdwRfq+zmsXXMoYfw== Message-ID: <93A6E602-5BD2-4F70-8804-0F46181D9E8F@juniper.net> References: <34E4F50CAFA10349A41E0756550084FB0660DC20@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: "Howard, Lee" , "int-area@ietf.org" , "cdl@asgaard.org" Subject: Re: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 01:51:37 -0000 On Jun 1, 2011, at 4:48 PM, Julien Laganier wrote: > Folks, >=20 > At this point we' d like to ask WG participants whether or not there > is interest in adopting this document as intarea WG draft. Please > express your opinions on the mailing list. >=20 > --julien & scott Julien, I believe the wg should not adopt this document. The core rationale of this document seems to be here: " However, the IPv6 deployment necessary to reduce reliance on IPv4 has been hampered by a lack of ubiquitous hardware and software support throughout the industry. Many vendors, especially in the consumer space have continued to view IPv6 support as optional.? I do not work for one of those "consumer space vendor" that has not done it= s IPv6 homework, but I very often say those same vendors saying: there is no demand... sendi= ng the ball back into the customers court or the ISPs court or the content providers court. At this point, my = argument is that: a) pointing fingers is not going to help. b) The IETF is very good at defining standards. The IETF has very little sa= y in what goes in the actual POs. Then the document goes on requiring that: " Updates [RFC1122 to redefine generic "IP" support to include and require IPv6 for IP-capable nodes and routers." So, If a vendor is building an IPv4 NAT for an IPv4-only provider, it needs= to add IPv6 in there? This is adding unnecessary code and effort that the vendor. Such effort wou= ld have been better spent to do actual useful IPv6 work. Later: " Current and new IP Networking implementations SHOULD support IPv4 and IPv6 coexistence (dual-stack), but MUST NOT require IPv4 for proper and complete function." Nice goal, but in practice, for most devices, we are a very long way from a= n IPv6-only operation. Example: 6PE. Very well understood, very useful to get IPy6 deployed quickl= y in a backbone. Under the proposed text, 6PE could not be standardized. Another example: SNMP. Most backbones, with few exceptions, are dual-stacke= d. On those backbones, SNMP data can be retrieved on IPv4. Yes, doing this over IPv6 is possible, = but is it really necessary? Wouldn't the resources be spent better elsewhere? - Alain.= From ietfc@btconnect.com Thu Jun 2 03:11:54 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9629E07D5 for ; Thu, 2 Jun 2011 03:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IXkqK9uEaz4 for ; Thu, 2 Jun 2011 03:11:53 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr08.btconnect.com [213.123.26.186]) by ietfa.amsl.com (Postfix) with ESMTP id 20B30E077B for ; Thu, 2 Jun 2011 03:11:52 -0700 (PDT) Received: from host217-43-155-221.range217-43.btcentralplus.com (HELO pc6) ([217.43.155.221]) by c2beaomr08.btconnect.com with SMTP id DAI09451; Thu, 02 Jun 2011 11:11:48 +0100 (BST) Message-ID: <002101cc2104$d7ac97a0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Scott Brim" , "Templin, Fred L" References: Date: Thu, 2 Jun 2011 11:09:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4DE761E4.00B7, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.6.2.85417:17:7.586, ip=217.43.155.221, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_BODY_WEBMAIL, __CP_URI_IN_BODY, __SUBJECT_ENDING_IN_LATIN_OR_NUMERALS, BODY_SIZE_5000_5999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, __FRAUD_WEBMAIL, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr08.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0205.4DE761E5.012A,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: Internet Area Subject: Re: [Int-area] Steps to make the IntArea WG more productive X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 10:11:54 -0000 ---- Original Message ----- From: "Scott Brim" To: "Templin, Fred L" Cc: "Internet Area" Sent: Tuesday, May 31, 2011 10:29 PM Subject: Re: [Int-area] Steps to make the IntArea WG more productive Fred: since you already have an RFC, what I am looking for is whether there is a need for agenda time. If nobody on this list -- where the truly interested parties are to be found -- expresses disagreement or confusion, then there is no reason to go over it again. Could those who are interested in this topic please look at the points below and respond by the end of the week, saying whether they have the same understanding as Fred, or they disagree, or they need clarification? Please be as specific as possible. Scott I think that this deserves more time and attention. I tracked the RRG list and the 20 or so possible future architectures that were discussed there and this seemed one of the ones that was more likely to succeed technically. LISP has the manufacturer drive behind it while the recommendation that was produced in the RFC2b - well, to quote "The group did not reach consensus on this recommendation, thus the recommendation reflects the decision of the co-chairs. The group did reach consensus that the overall document should be published." which I do not see as a ringing endorsement. I think that what is wrong with Fred's list is point 1); a technical nicety that slows the reader down from getting to points 2) etc, which are critical:-) Tom Petch ... Scott On Tue, May 31, 2011 at 14:49, Templin, Fred L wrote: > Hi Scott, > > OK. I think there may be insufficient understanding on > the following points (and possibly others): > > 1) IRON is about managing tunnels between mobile clients > and fixed servers. When the tunnel uses security, the > system becomes one of managing mobile VPNs much in the > same way as for MOBIKE: > > http://www.ietf.org/id/draft-templin-ironmike-01.txt > > > IRON goes beyond the basic MOBIKE model to specify how > the servers form a full/partial mesh between themselves > so that clients can be tracked even if they move from > server to server. Clients can be either a mobile router > or a mobile host. An example use case is for mobile or > nomadic devices connecting to a home enterprise network > by locating a nearby VPN gateway, then changing to a new > VPN gateway due to mobility events as necessary. > > 2) IRON is about suppressing routing scaling in the DFZ: > > http://www.rfc-editor.org/rfc/rfc6179.txt > > IRON networks advertise only highly-aggregated prefixes > in the DFZ and delegate more-specific prefixes to IRON > clients. The full/partial mesh of IRON servers provide > the means for maintaining generally shortest path > routing to mobile clients within the overlay network. > > 3) IRON is about route optimization: > > http://www.ietf.org/id/draft-templin-aero-00.txt > > When IRON client A wishes to connect to IRON client B, > A first sends its initial packets through its own > server S(A). S(A) then forwards the packets to B's > server S(B). A is then redirected to S(B) so that > subsequent packets do not need to flow through S(A). > > 4) IRON is about multiple interfaces. Consider an airplane > that connects to the ground via multiple wireless links. > IRON configures a mobile VPN over the multiple available > links such that the VPN connection survives even if the > underlying link states fluctuate. > > 5) IRON is a means for an ISP to provide overlay network > services to its client customers: > > http://www.ietf.org/id/draft-templin-iron-pm-01.txt > > A typical example would be for an ISP to delegate fully > native IPv6 prefixes to client customers, then provide > an overlay network routing system that connects clients > to correspondents both within the ISP's overlay network > as well as within the public Internet. > > Again, this is a partial list but should be sufficient > to initiate discussion. What would you like to see in > terms of next steps? > > Thanks - Fred > fred.l.templin@boeing.com > >> -----Original Message----- >> From: Scott Brim [mailto:scott.brim@gmail.com] >> Sent: Friday, May 27, 2011 3:06 PM >> To: Templin, Fred L >> Cc: Internet Area >> Subject: Re: [Int-area] Steps to make the IntArea WG more productive >> >> Hi Fred. Sorry for being late. I started the week with a 103.8F >> (39.9C) fever. That's all gone but I'm still moving slowly. >> >> > While the IRON architecture has already been published as RFC6179, I >> > do not believe there is yet a sufficiently wide understanding of the >> > technology such that it would qualify under your criterion of "items >> > where proponents are having difficulty explaining concepts in mail, >> > and for which presentation would help". >> >> If I understand correctly, you're saying there was discussion, but the >> discussion didn't hit a wall, a failure of communication, and >> you didn't >> have trouble explaining things. What >> happened? Did it die out? Did people believe they understood the >> points, but you didn't believe? >> >> I suggest that you list the points where you think there is >> insufficient understanding, and we start there. >> >> OK? >> >> ...Scott >> > _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area From scott.brim@gmail.com Thu Jun 2 07:09:06 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19823E06C2 for ; Thu, 2 Jun 2011 07:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.59 X-Spam-Level: X-Spam-Status: No, score=-103.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ip6g-FGNsbFo for ; Thu, 2 Jun 2011 07:09:05 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8B217E0692 for ; Thu, 2 Jun 2011 07:09:05 -0700 (PDT) Received: by iwn39 with SMTP id 39so978257iwn.31 for ; Thu, 02 Jun 2011 07:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to:cc :content-type; bh=BTBDjAoO7sGP8UgHmNlg8OFOCDkiZ5h/yEUxO6Dvetw=; b=o4c4OuUoMdF3xgI8WfPjFABN22aCLJk+4s2fuzn5+ftK2xbrcW4MBPQPcNjVNNYDqN 5akzRPZSiI3Nsmp1hfiLEmxMo5IohbqFx/tyZHgGdKQZyDCZ6UHKyWOKkZUE5SE5KaQ2 RKCqlZJgzaAe3eaDprkbe0VQe75XGWn7PcKhg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type; b=IuJfs6qQkyLOFafw0OYpJXhl3/FBrSKmK9YLNfeCYqNWpuI/FDv8/iykQOjnWNvpVA Nrfi5SY6HXP2l1MC9/7oJCjZSjlK5ESe5UFnbTF/s326t3ZtqpoLUdzaiOWyG1fpZvU9 bYkKTEYVgj432Ox9eqvSNQbnS+rYm60o0eUts= Received: by 10.42.94.138 with SMTP id b10mr1475616icn.511.1307023745120; Thu, 02 Jun 2011 07:09:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.19.130 with HTTP; Thu, 2 Jun 2011 07:08:45 -0700 (PDT) From: Scott Brim Date: Thu, 2 Jun 2011 10:08:45 -0400 Message-ID: To: "t.petch" Content-Type: text/plain; charset=ISO-8859-1 Cc: Internet Area Subject: [Int-area] IRON issue discussion X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 14:09:06 -0000 First, I've changed the subject (but kept the threading). Second, on this specific issue -- discussion of IRON topics to see if there are any that canNOT be clarified on the mailing list, and thus need agenda time -- Tom, you say > I think that what is wrong with Fred's list is point 1); a technical nicety > that slows the reader down from getting to points 2) etc, which are > critical:-) If I understand correctly, you understand IRON, but you think others might have trouble understanding it, and you are suggesting some rewrites? No agenda time needed? If there are in fact points you disagree with or believe need clarifying, could you make them explicit? Thanks ... Scott From wesley.george@twcable.com Thu Jun 2 07:29:18 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C16E07BC for ; Thu, 2 Jun 2011 07:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.057 X-Spam-Level: X-Spam-Status: No, score=0.057 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRff+ryXPE7Q for ; Thu, 2 Jun 2011 07:29:18 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 18112E06F7 for ; Thu, 2 Jun 2011 07:29:17 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.65,309,1304308800"; d="scan'208";a="232954079" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 02 Jun 2011 10:35:17 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.29]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Thu, 2 Jun 2011 10:29:16 -0400 From: "George, Wesley" To: Alain Durand , Julien Laganier Date: Thu, 2 Jun 2011 10:29:13 -0400 Thread-Topic: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt Thread-Index: Acwgx4s3sBL/eCdwRfq+zmsXXMoYfwAWpjpA Message-ID: <34E4F50CAFA10349A41E0756550084FB0660E0DF@PRVPEXVS04.corp.twcable.com> References: <34E4F50CAFA10349A41E0756550084FB0660DC20@PRVPEXVS04.corp.twcable.com> <93A6E602-5BD2-4F70-8804-0F46181D9E8F@juniper.net> In-Reply-To: <93A6E602-5BD2-4F70-8804-0F46181D9E8F@juniper.net> 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: "Howard, Lee" , "int-area@ietf.org" , "cdl@asgaard.org" Subject: Re: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 14:29:19 -0000 -----Original Message----- From: Alain Durand [mailto:adurand@juniper.net] Sent: Wednesday, June 01, 2011 9:51 PM Subject: Re: [Int-area] FW: New Version Notification for draft-george-ipv6-= required-02.txt Julien, I believe the wg should not adopt this document. The core rationale of this document seems to be here: " However, the IPv6 deployment necessary to reduce reliance on IPv4 has been hampered by a lack of ubiquitous hardware and software support throughout the industry. Many vendors, especially in the consumer space have continued to view IPv6 support as optional.? I do not work for one of those "consumer space vendor" that has not done it= s IPv6 homework, but I very often say those same vendors saying: there is no demand... sendi= ng the ball back into the customers court or the ISPs court or the content providers court. WEG> are we really going to try to even partially blame the lack of IPv6 de= ployment on content providers? Chicken, egg, I'd like to introduce you both= to World IPv6 Day. Content providers and ISPs are both taking the necessar= y steps to support IPv6. It may not be on the timeline we'd all like, but i= t's happening. But fat lot of good it does anyone if IPv6 is still not supp= orted in the devices that would need to consume that content. AD> At this point, my argument is that: a) pointing fingers is not going to help. WEG> Alain, if you believe this to be pointing fingers, I'd first refer you= to your comments above about whose court the ball is in, and second, reque= st that you propose text that resolves the issue. However, I don't view a f= rank discussion of the current problem facing wider IPv6 deployment as poin= ting fingers. It's not as if it's a list of offending vendors. AD> b) The IETF is very good at defining standards. The IETF has very littl= e say in what goes in the actual POs. WEG> The problem, as I and others have said repeatedly when discussing this= draft is that the ISPs don't control the POs either. Maybe for the CPE GW,= but not in all cases, and definitely not the customer's TV, internet-capab= le refrigerator, gaming console, AV receiver, Blu-Ray player, etc. And cust= omers have no reason at this point to specifically request IPv6 support whe= n they walk into their local big-box retailer. Even if they did, how will t= hat actually translate upward into a product decision? It's not as if there= 's exit polls asking why you chose one device over another. If the average consumer even knows what IPv6 is, we've failed at making the= transition, because it's not a feature any more than IPv4 is a feature. "I= nternet connectivity" is a feature. Which version of the protocol is being = used is a technical implementation detail of that feature that should be tr= ansparent to the user. The argument that this is a problem of ISPs and cons= umers not putting their money where their mouths are is nonsense. This document is aimed at giving updated guidance to the folks who use IETF= standards as guidelines for their implementations that IPv4 and IPv6 are n= o longer two options that can be chosen independently, because it is simply= not sustainable to expect IPv4 to suffice on its own anymore. It is one (m= issing) part of a growing chorus of folks trying to fix the places where IP= v6 support is lacking, but to have the primary Internet standards body cont= inue to ignore the fact that IPv4 growth is unsustainable and IPv6 is no lo= nger optional is IMHO as bad or worse than those refusing to implement beca= use there is "no demand." We [the IETF] should know better. AD> Then the document goes on requiring that: " Updates [RFC1122 to redefine generic "IP" support to include and require IPv6 for IP-capable nodes and routers." So, If a vendor is building an IPv4 NAT for an IPv4-only provider, it needs= to add IPv6 in there? This is adding unnecessary code and effort that the vendor. Such effort wou= ld have been better spent to do actual useful IPv6 work. WEG> I'm starting to think that you're purposely misinterpreting this docum= ent in order to make it seem like a bad idea, but I'm not sure why that wou= ld be... The IETF isn't the protocol police, and they're not a certification organiz= ation. Ultimately, what a vendor builds for a provider, including what stan= dards they choose to follow, ignore, or tweak is entirely between that vend= or and whomever is writing the checks. Our standards are for guidance. Howe= ver, if any vendor is hanging their long-term business model on being able = to continue providing IPv4-only devices for IPv4-only providers, I'd strong= ly recommend selling their stock, and I don't view this as a valid example = of why the draft is harmful. AD> Later: " Current and new IP Networking implementations SHOULD support IPv4 and IPv6 coexistence (dual-stack), but MUST NOT require IPv4 for proper and complete function." Nice goal, but in practice, for most devices, we are a very long way from a= n IPv6-only operation. WEG> Yet you're maintaining that a document making this the direction that = IETF should head is somehow wrong. How are we ever going to fix it if we do= n't start moving in that direction? AD> Example: 6PE. Very well understood, very useful to get IPy6 deployed qu= ickly in a backbone. Under the proposed text, 6PE could not be standardized. WEG> No, that's simply incorrect. This document no longer makes any recomme= ndations as to how the IETF should apply this to WG charters or protocols a= nd proposed standards. That interpretation remains the IESG's responsibilit= y. The text that I removed after your and others concerns about that being = in a standards document instead of a BCP specifically discussed this, and m= ore importantly, specifically referred to transition technologies being exe= mpt from the directive to stop working on IPv4-only protocol development. I= 'm not opposed to trying to add some clarification here specifically regard= ing transition technologies, but I think you are again exaggerating the iss= ue, and would like to see some other folks weigh in on whether this is inde= ed a problem with the current language. AD> Another example: SNMP. Most backbones, with few exceptions, are dual-st= acked. On those backbones, SNMP data can be retrieved on IPv4. Yes, doing this over IPv6 is possible, = but is it really necessary? WEG> I see nowhere that this document requires *operators* to use IPv6 for = SNMP (or for anything, really). This is a document for implementers aimed a= t providing maximum flexibility as to how the operator chooses to implement= by ensuring that the devices and software support IPv6 as completely as po= ssible. The reality is that single-stack IPv6 networks do exist, and will b= ecome more prevalent as IPv4 exhausts completely. And while an operator may= choose not to use IPv6 for SNMP today, my vendor damn well better have sup= port for it in case I choose to move to a single-stack backbone tomorrow. I= can think of several reasonable cases for moving to IPv6 for management th= at were stymied by exactly these types of erroneous assumptions. That is, d= iscussions that I was part of in, you know, an actual operator network, whe= re we had to figure out a workaround because missing IPv6 support for certa= in features meant that we couldn't do the simplest thing, which was to move= to IPv6 to avoid an IPv4 address constraint. AD> Wouldn't the resources be spent better elsewhere? WEG> Unless you can provide some actual concrete examples, I'm going to vie= w this as a rhetorical question, asked because you don't actually have a le= gitimate problem and are merely trying to spread FUD. If it is as you say a= nd we're a long way from being able to properly run an IPv6-only network, I= 'd say that's one of IETF's larger priorities. We're 16 years in, and you'r= e saying that the protocol still isn't done? That's a pretty long time, eve= n by IETF standards. There don't need to be any additional barriers for IPv= 6 adoption. The existing financial and resource constraints are already mor= e than enough. If "IPv6 still doesn't do X, and I can do that on IPv4, so I= can't move to IPv6" is still a valid excuse, we need to be fixing that. 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 randy@psg.com Thu Jun 2 08:17:01 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35733E06AF for ; Thu, 2 Jun 2011 08:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.49 X-Spam-Level: X-Spam-Status: No, score=-6.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7AiJF156i1Q for ; Thu, 2 Jun 2011 08:17:00 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF6AE067F for ; Thu, 2 Jun 2011 08:17:00 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QS9dr-000KwV-9k for int-area@ietf.org; Thu, 02 Jun 2011 15:17:00 +0000 Date: Thu, 02 Jun 2011 18:16:49 +0300 Message-ID: From: Randy Bush To: int-area@ietf.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: [Int-area] draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 15:17:01 -0000 i have read and support draft-george-ipv6-required randy From ietfc@btconnect.com Thu Jun 2 08:58:57 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527D8E0832 for ; Thu, 2 Jun 2011 08:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.263 X-Spam-Level: X-Spam-Status: No, score=-2.263 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c35hFqXTfk98 for ; Thu, 2 Jun 2011 08:58:56 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr07.btconnect.com [213.123.26.185]) by ietfa.amsl.com (Postfix) with ESMTP id 3553EE082B for ; Thu, 2 Jun 2011 08:58:55 -0700 (PDT) Received: from host217-43-155-221.range217-43.btcentralplus.com (HELO pc6) ([217.43.155.221]) by c2beaomr07.btconnect.com with SMTP id DBY15750; Thu, 02 Jun 2011 16:58:49 +0100 (BST) Message-ID: <00c701cc2135$51d998e0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Scott Brim" References: Date: Thu, 2 Jun 2011 16:56:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4DE7B339.0094, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.6.2.143618:17:7.586, ip=217.43.155.221, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_BODY_WEBMAIL, __URI_NO_WWW, __URI_NO_PATH, __SUBJECT_ENDING_IN_LATIN_OR_NUMERALS, BODY_SIZE_1500_1599, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_2000_LESS, __FRAUD_WEBMAIL, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0202.4DE7B33A.00F3,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: Internet Area Subject: Re: [Int-area] IRON issue discussion X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 15:58:57 -0000 ----- Original Message ----- From: "Scott Brim" To: "t.petch" Cc: "Templin, Fred L" ; "Internet Area" Sent: Thursday, June 02, 2011 4:08 PM > First, I've changed the subject (but kept the threading). > > Second, on this specific issue -- discussion of IRON topics to see if > there are any that canNOT be clarified on the mailing list, and thus > need agenda time -- Tom, you say > > > I think that what is wrong with Fred's list is point 1); a technical nicety > > that slows the reader down from getting to points 2) etc, which are > > critical:-) > > If I understand correctly, you understand IRON, but you think others > might have trouble understanding it, and you are suggesting some > rewrites? No agenda time needed? > > If there are in fact points you disagree with or believe need > clarifying, could you make them explicit? Mangling my metaphors, build a better mouse trap and nothing happens. I believe that this 'mouse trap' deserves a wider hearing than it got on RRG list and agenda time would give it that. I believe I understand it but more discussion would probably throw up some misunderstandings on my part (I always intended to submit a review on the RRG list which is the way to see if I understand it or not but, with hindsight, never gave that work enough priority). I saw three good things on the RRG list and this was one of them (err ... the RRG Recommendation was not:-) Tom Petch > Thanks ... Scott From touch@isi.edu Thu Jun 2 09:07:23 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D83E065B for ; Thu, 2 Jun 2011 09:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.238 X-Spam-Level: X-Spam-Status: No, score=-104.238 tagged_above=-999 required=5 tests=[AWL=1.161, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgCV2gUMuspf for ; Thu, 2 Jun 2011 09:07:22 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8F7E06C2 for ; Thu, 2 Jun 2011 09:07:19 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p52G6wOs020522 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 2 Jun 2011 09:06:59 -0700 (PDT) Message-ID: <4DE7B521.8050301@isi.edu> Date: Thu, 02 Jun 2011 09:06:57 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "t.petch" References: <00c701cc2135$51d998e0$4001a8c0@gateway.2wire.net> In-Reply-To: <00c701cc2135$51d998e0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Internet Area Subject: Re: [Int-area] IRON issue discussion X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 16:07:23 -0000 On 6/2/2011 7:56 AM, t.petch wrote: > Mangling my metaphors, build a better mouse trap and nothing happens. I'd like to jump in here. IRON has some very useful components, many that are well designed and can help others avoid re-inventing the wheel. That's the primary utility to INTAREA, IMO - the whole system seems to compete in the space that the L3VPN groups are playing (among others), and it's not clear there's a single winner in that space (backbone providers will likely continue to want VPN and PPVPN solutions). The larger challenge, IMO, is that the IETF is a place where reinventing the wheel is the norm, if not often the goal ;-( A useful way forward might be a short presentation that highlights the components of IRON, and where each addresses a key issue important to INTAREA. The entire system as a whole may be relevant, but the parts need to be understood and appreciated first, IMO. Joe From warren@kumari.net Thu Jun 2 10:17:53 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCDBE07A2 for ; Thu, 2 Jun 2011 10:17:53 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Og7D2dykDdrh for ; Thu, 2 Jun 2011 10:17:52 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 0C72FE05D3 for ; Thu, 2 Jun 2011 10:17:44 -0700 (PDT) Received: from [172.19.118.214] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id E05D81B41254; Thu, 2 Jun 2011 13:17:42 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0660DC20@PRVPEXVS04.corp.twcable.com> Date: Thu, 2 Jun 2011 13:17:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <63B6E461-79DD-41F7-B3F0-73AA6E0FDA8C@kumari.net> References: <34E4F50CAFA10349A41E0756550084FB0660DC20@PRVPEXVS04.corp.twcable.com> To: "George, Wesley" X-Mailer: Apple Mail (2.1084) Cc: "Howard, Lee" , "int-area@ietf.org" , "cdl@asgaard.org" Subject: Re: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 17:17:53 -0000 On Jun 1, 2011, at 10:47 AM, George, Wesley wrote: > After the discussion of this draft in Prague and with the WG chairs = and ADs, we have updated it to address a few comments, but primarily to = remove the language directing IETF action. This limits the draft to = simply requiring IPv6 for IP-capable devices, and should address the = concern about whether it interferes with existing WG actions as well as = the recommendation that normally IETF action directions are done via BCP = rather than standards-track documents. >=20 > We would like to ask for formal WG adoption of this draft, as well as = reviews to see if it can soon be made ready for WGLC (assuming WG = adoption is successful). I firmly support adoption of this draft.... (I don't necessarily think it is going to change things much, but I = believe that it is worth adopting and giving it try...) W > http://tools.ietf.org/html/draft-george-ipv6-required-02 >=20 > Any discussion about IETF's response to this draft (in terms of how = WGs operate, their charters, etc) will be issued in a separate BCP = draft. Right now, we want to focus on getting this draft out so that it = can provide guidance to IPv6 implementors. >=20 > Thanks! >=20 > Wes George and co-authors. >=20 >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, June 01, 2011 10:30 AM > To: George, Wesley > Cc: Howard, Lee; Donley, Chris (Cable Labs); George, Wesley; = cdl@asgaard.org > Subject: New Version Notification for = draft-george-ipv6-required-02.txt >=20 > A new version of I-D, draft-george-ipv6-required-02.txt has been = successfully submitted by Wesley George and posted to the IETF = repository. >=20 > Filename: draft-george-ipv6-required > Revision: 02 > Title: IPv6 Support Required for all IP-capable nodes > Creation date: 2011-06-01 > WG ID: Individual Submission > Number of pages: 7 >=20 > Abstract: > Given the global lack of available IPv4 space, and limitations in > IPv4 extension and transition technologies, this document deprecates > the concept that an IP-capable node MAY support IPv4 _only_, and > redefines an IP-capable node as one which supports either IPv6 = _only_ > or IPv4/IPv6 dual-stack. This document updates RFC1812, 1122 and > 4084 to reflect the change in requirements. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 > 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. > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area >=20 From bschlies@cisco.com Thu Jun 2 11:02:46 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1E5E07E7 for ; Thu, 2 Jun 2011 11:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.366 X-Spam-Level: X-Spam-Status: No, score=-10.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcHhRoy-8wky for ; Thu, 2 Jun 2011 11:02:46 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE0CE0693 for ; Thu, 2 Jun 2011 11:02:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=1328; q=dns/txt; s=iport; t=1307037766; x=1308247366; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=gFVoSrByVT0OMHTdzcvtb3BChptpzMnjlZWxpozbM1c=; b=XYVNlIc1ZtPb9vqEUdCT+qomW5DLr7CgNlr/xXFCRFOOSWvgCPLpxX1f ZLouH3A6qXFWarq9NbH8Cd5lZxt+SRMPhV8V7RuyqAEkan8+mrrCyVToL ttn1/bBQw9ZDmFGdrilfOGD2KV/K7P1fvFweG1Ntr3Jq6opoY0JZobyPa Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHfP502tJV2Z/2dsb2JhbABTpjp3iHGiTZ1jhiEEhmmJfoROiwA X-IronPort-AV: E=Sophos;i="4.65,310,1304294400"; d="scan'208";a="328863593" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-3.cisco.com with ESMTP; 02 Jun 2011 18:02:45 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p52I2jdg008285; Thu, 2 Jun 2011 18:02:45 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Jun 2011 13:02:44 -0500 Received: from 10.21.122.246 ([10.21.122.246]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([171.70.151.174]) with Microsoft Exchange Server HTTP-DAV ; Thu, 2 Jun 2011 18:02:44 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Thu, 02 Jun 2011 13:04:17 -0500 From: Benson Schliesser To: "George, Wesley" , Alain Durand , Julien Laganier Message-ID: Thread-Topic: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt Thread-Index: Acwgx4s3sBL/eCdwRfq+zmsXXMoYfwAWpjpAAAtWN9k= In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0660E0DF@PRVPEXVS04.corp.twcable.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Jun 2011 18:02:44.0887 (UTC) FILETIME=[4615D270:01CC214F] Cc: "Howard, Lee" , "int-area@ietf.org" , "cdl@asgaard.org" Subject: Re: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 18:02:46 -0000 On 6/2/11 9:29 AM, "George, Wesley" wrote: > AD> b) The IETF is very good at defining standards. The IETF has very little > say in what goes in the actual POs. > > WEG> The problem, as I and others have said repeatedly when discussing this > draft is that the ISPs don't control the POs either. Maybe for the CPE GW, but > not in all cases, and definitely not the customer's TV, internet-capable > refrigerator, gaming console, AV receiver, Blu-Ray player, etc. I find myself largely agreeing with Alain's comments, but also agreeing with the goal of this draft. Call me "undecided" if you wish. I suppose that my fundamental question is this: what, pragmatically, would this draft achieve that existing RFCs do not? After all, an RFC is just an RFC - there is no mandatory compliance, enforcement, etc; support for IETF standards and best-practices is completely voluntary and unaudited (until in one's lab). So, if published, would a vendor simply say "yeah we're compliant with RFC-ipv6-required" along with all the other IPv6 RFCs? Or do you imagine that they'll be forced to stop claiming compliance with 1812, 1122, and 4084? If the market is (or isn't) going to push us to IPv6, what effect do you imagine this draft will have on things? Thanks, -Benson From brian.e.carpenter@gmail.com Thu Jun 2 15:41:31 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B5FE08DF for ; Thu, 2 Jun 2011 15:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.539 X-Spam-Level: X-Spam-Status: No, score=-103.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trHGCvpqLgNw for ; Thu, 2 Jun 2011 15:41:31 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3D75DE08D4 for ; Thu, 2 Jun 2011 15:41:31 -0700 (PDT) Received: by fxm15 with SMTP id 15so1107749fxm.31 for ; Thu, 02 Jun 2011 15:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0yzn4/yaT9R6vzAEPxWfEtF7MzSTXQeFNKn2MY8ZCXE=; b=GF5UlkwuM59bkSPrDZhSMX32gsS8hkFOXpqBmADygy3Y8nveCZ/MRLlIAyr2jehy4D u9V8q3xC7Qx5jYrrno+TlTMmY7yGJ/Pbigy28sD/2eutDtmRaTCcIVJXPwIXtJLnhgDg Nq16RCItQCq/OLKOABzcnbjkSSR5kzLIaOqtU= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=NyYpZfPj+k1Ue3CxVE8UlmkdlPYydmRxrOKwhIX50tyomsZOUI8UN2O2FvOSwjLJYm LEXJm6aNDMvnZwyXFbH/OhFMRmxN4SI0yeidDGMYyZM2Cv6id7LoCuhujjEMJy0v7j8i 9cUl3E8Qj4oRJ+sHhp693zjhWkZbq2qZdKghk= Received: by 10.223.55.200 with SMTP id v8mr1416072fag.82.1307054490366; Thu, 02 Jun 2011 15:41:30 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id x15sm319061fah.22.2011.06.02.15.41.27 (version=SSLv3 cipher=OTHER); Thu, 02 Jun 2011 15:41:29 -0700 (PDT) Message-ID: <4DE8118E.6030703@gmail.com> Date: Fri, 03 Jun 2011 10:41:18 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "int-area@ietf.org" References: <34E4F50CAFA10349A41E0756550084FB0660DC20@PRVPEXVS04.corp.twcable.com> <93A6E602-5BD2-4F70-8804-0F46181D9E8F@juniper.net> <34E4F50CAFA10349A41E0756550084FB0660E0DF@PRVPEXVS04.corp.twcable.com> In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0660E0DF@PRVPEXVS04.corp.twcable.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 22:41:32 -0000 I've seen the counter arguments, but I think this draft, or at least the principle it embodies, is welcome and *long* overdue. We shouldn't be spending any effort on polishing the IPv4 heirloom, except for vital security or operational fixes. Regards Brian Carpenter From adurand@juniper.net Thu Jun 2 16:36:12 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F993E0797 for ; Thu, 2 Jun 2011 16:36:12 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biaa2nPF0aLo for ; Thu, 2 Jun 2011 16:36:11 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 83B46E06CA for ; Thu, 2 Jun 2011 16:36:11 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTegeaXzK20mrvaTuLf1bH8zVLpAIhT7e@postini.com; Thu, 02 Jun 2011 16:36:11 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 2 Jun 2011 16:32:49 -0700 From: Alain Durand To: Brian E Carpenter Date: Thu, 2 Jun 2011 16:32:48 -0700 Thread-Topic: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt Thread-Index: AcwhfWKe18VzCqB8R0yZVTTOCX2onA== Message-ID: <70F27969-2C5D-40A3-BE92-870EEC512C3E@juniper.net> References: <34E4F50CAFA10349A41E0756550084FB0660DC20@PRVPEXVS04.corp.twcable.com> <93A6E602-5BD2-4F70-8804-0F46181D9E8F@juniper.net> <34E4F50CAFA10349A41E0756550084FB0660E0DF@PRVPEXVS04.corp.twcable.com> <4DE8118E.6030703@gmail.com> In-Reply-To: <4DE8118E.6030703@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 Cc: "int-area@ietf.org" Subject: Re: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 23:36:12 -0000 On Jun 2, 2011, at 6:41 PM, Brian E Carpenter wrote: > We shouldn't be spending any effort on polishing the IPv4 heirloom, > except for vital security or operational fixes. Brian, I would have agreed if IPv6 was a direct replacement of IPv4. Unfortunately= , it is not the case. - Alain.= From jared@puck.nether.net Thu Jun 2 16:53:44 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B24E0813 for ; Thu, 2 Jun 2011 16:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqcKhqahlinr for ; Thu, 2 Jun 2011 16:53:44 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id E77B0E07F3 for ; Thu, 2 Jun 2011 16:53:43 -0700 (PDT) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.4/8.12.9) with ESMTP id p52NredT099699 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Jun 2011 19:53:40 -0400 (EDT) (envelope-from jared@puck.nether.net) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: <63B6E461-79DD-41F7-B3F0-73AA6E0FDA8C@kumari.net> Date: Thu, 2 Jun 2011 19:53:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <00840C00-A351-4A81-83F5-8115028856FA@puck.nether.net> References: <34E4F50CAFA10349A41E0756550084FB0660DC20@PRVPEXVS04.corp.twcable.com> <63B6E461-79DD-41F7-B3F0-73AA6E0FDA8C@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Thu, 02 Jun 2011 19:53:41 -0400 (EDT) Cc: "Howard, Lee" , "int-area@ietf.org" , "cdl@asgaard.org" Subject: Re: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 23:53:44 -0000 I support adoption of this draft as well. - Jared Mauch On Jun 2, 2011, at 1:17 PM, Warren Kumari wrote: > I firmly support adoption of this draft.... >=20 > (I don't necessarily think it is going to change things much, but I = believe that it is worth adopting and giving it try...) From wes@mti-systems.com Thu Jun 2 18:30:35 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B41EE071F for ; Thu, 2 Jun 2011 18:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QL3PTD5lhs33 for ; Thu, 2 Jun 2011 18:30:34 -0700 (PDT) Received: from omr13.networksolutionsemail.com (omr13.networksolutionsemail.com [205.178.146.63]) by ietfa.amsl.com (Postfix) with ESMTP id 7A382E0709 for ; Thu, 2 Jun 2011 18:30:34 -0700 (PDT) Received: from cm-omr1 (mail.networksolutionsemail.com [205.178.146.50]) by omr13.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p531UXDj010969 for ; Thu, 2 Jun 2011 21:30:33 -0400 Authentication-Results: cm-omr1 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [174.130.74.141] ([174.130.74.141:6676] helo=[192.168.1.104]) by cm-omr1 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id D7/1F-21922-93938ED4; Thu, 02 Jun 2011 21:30:33 -0400 Message-ID: <4DE83939.2070904@mti-systems.com> Date: Thu, 02 Jun 2011 21:30:33 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: int-area@ietf.org References: <34E4F50CAFA10349A41E0756550084FB0660DC20@PRVPEXVS04.corp.twcable.com> <93A6E602-5BD2-4F70-8804-0F46181D9E8F@juniper.net> <34E4F50CAFA10349A41E0756550084FB0660E0DF@PRVPEXVS04.corp.twcable.com> <4DE8118E.6030703@gmail.com> In-Reply-To: <4DE8118E.6030703@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 01:30:35 -0000 On 6/2/2011 6:41 PM, Brian E Carpenter wrote: > I've seen the counter arguments, but I think this draft, or at least > the principle it embodies, is welcome and *long* overdue. > > We shouldn't be spending any effort on polishing the IPv4 heirloom, > except for vital security or operational fixes. I agree with this 100%. -- Wes Eddy MTI Systems From mohamed.boucadair@orange-ftgroup.com Fri Jun 3 00:46:08 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8573E06B3 for ; Fri, 3 Jun 2011 00:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOFLlQhphzax for ; Fri, 3 Jun 2011 00:46:08 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 0D14DE0665 for ; Fri, 3 Jun 2011 00:46:07 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 6C44022C595; Fri, 3 Jun 2011 09:46:06 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 50A9835C06C; Fri, 3 Jun 2011 09:46:06 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Fri, 3 Jun 2011 09:46:06 +0200 From: To: "int-area@ietf.org" , Julien Laganier , "wesley.george@twcable.com" Date: Fri, 3 Jun 2011 09:46:04 +0200 Thread-Topic: Re: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt Thread-Index: AcwhwkqkCQSwbT6pSFK+qhOn5jU01A== Message-ID: <94C682931C08B048B7A8645303FDC9F33E4E4CC777@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F33E4E4CC777PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.6.3.70316 Subject: Re: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 07:46:08 -0000 --_000_94C682931C08B048B7A8645303FDC9F33E4E4CC777PUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear chairs, all, > Folks, > > At this point we' d like to ask WG participants whether or not there > is interest in adopting this document as intarea WG draft. Please > express your opinions on the mailing list. > > --julien & scott I read this I-D and I support its adoption as a working group document. Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F33E4E4CC777PUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D= ear chairs,=20 all,
 
> Folks,
>
> At th= is point=20 we' d like to ask WG participants whether or not there
> is interest = in=20 adopting this document as intarea WG draft. Please
> express your opi= nions=20 on the mailing list.
>
> --julien & scott
I read=20 this I-D and I support its adoption as a working group=20 document.
 
Cheers,
Med
--_000_94C682931C08B048B7A8645303FDC9F33E4E4CC777PUEXCB1Bnante_-- From edward.jankiewicz@sri.com Fri Jun 3 06:31:56 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD52E075A for ; Fri, 3 Jun 2011 06:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0-pDywree9t for ; Fri, 3 Jun 2011 06:31:56 -0700 (PDT) Received: from mail1.sri.com (mail.SRI.COM [128.18.30.17]) by ietfa.amsl.com (Postfix) with ESMTP id 23518E065D for ; Fri, 3 Jun 2011 06:31:56 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [128.18.209.220] ([unknown] [128.18.70.7]) by mail.sri.com (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPS id <0LM700OOZUX63820@mail.sri.com> for int-area@ietf.org; Fri, 03 Jun 2011 06:31:55 -0700 (PDT) Message-id: <4DE8E2BF.4070404@sri.com> Date: Fri, 03 Jun 2011 09:33:51 -0400 From: Ed Jankiewicz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 To: "int-area@ietf.org" References: <34E4F50CAFA10349A41E0756550084FB0660DC20@PRVPEXVS04.corp.twcable.com> <93A6E602-5BD2-4F70-8804-0F46181D9E8F@juniper.net> <34E4F50CAFA10349A41E0756550084FB0660E0DF@PRVPEXVS04.corp.twcable.com> <4DE8118E.6030703@gmail.com> In-reply-to: <4DE8118E.6030703@gmail.com> Subject: Re: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 13:31:56 -0000 I support advancing this draft and agree that making IPv6 "the new normal" is philosophically a good idea. The effort expended to "polish the heirloom" as Brian put it, has been in good faith by people who have a vested interest in making the best of the current situation (keeping IPv4 working in the face of many more end points than its designers ever planned for) and this will continue as long as IPv6 is not seen as a viable alternative. It will not achieve that until it sees wide deployment and starts to carry a significant slice of the packets. Only then will the energy shift to making IPv6 better rather than keeping IPv4 going. We'll park the heirloom in the garage, and roll it out for special occasions (i.e. there will be a very long tail for IPv4 legacy usage for many situations) but enjoy driving and polishing the shiny new V6 muscle car. Ed J. On 6/2/2011 6:41 PM, Brian E Carpenter wrote: > I've seen the counter arguments, but I think this draft, or at least > the principle it embodies, is welcome and *long* overdue. > > We shouldn't be spending any effort on polishing the IPv4 heirloom, > except for vital security or operational fixes. > > Regards > Brian Carpenter > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From wesley.george@twcable.com Fri Jun 3 10:38:15 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5FAE0692 for ; Fri, 3 Jun 2011 10:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.03 X-Spam-Level: X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfMIQiX7sybJ for ; Fri, 3 Jun 2011 10:38:15 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 30BF5E078A for ; Fri, 3 Jun 2011 10:38:13 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.65,315,1304308800"; d="scan'208";a="220269542" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 03 Jun 2011 13:38:17 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.29]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Fri, 3 Jun 2011 13:38:12 -0400 From: "George, Wesley" To: Benson Schliesser , Alain Durand , Julien Laganier Date: Fri, 3 Jun 2011 13:38:11 -0400 Thread-Topic: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt Thread-Index: Acwgx4s3sBL/eCdwRfq+zmsXXMoYfwAWpjpAAAtWN9kAAAwFgA== Message-ID: <34E4F50CAFA10349A41E0756550084FB067B6B13@PRVPEXVS04.corp.twcable.com> References: <34E4F50CAFA10349A41E0756550084FB0660E0DF@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: "Howard, Lee" , "int-area@ietf.org" , "cdl@asgaard.org" Subject: Re: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 17:38:15 -0000 -----Original Message----- From: Benson Schliesser [mailto:bschlies@cisco.com] Sent: Thursday, June 02, 2011 2:04 PM To: George, Wesley; Alain Durand; Julien Laganier Subject: Re: [Int-area] FW: New Version Notification for draft-george-ipv6-= required-02.txt I find myself largely agreeing with Alain's comments, but also agreeing wit= h the goal of this draft. Call me "undecided" if you wish. I suppose that my fundamental question is this: what, pragmatically, would this draft achieve that existing RFCs do not? After all, an RFC is just an RFC - there is no mandatory compliance, enforcement, etc; support for IETF standards and best-practices is completely voluntary and unaudited (until i= n one's lab). So, if published, would a vendor simply say "yeah we're compliant with RFC-ipv6-required" along with all the other IPv6 RFCs? Or do you imagine that they'll be forced to stop claiming compliance with 1812, 1122, and 4084? If the market is (or isn't) going to push us to IPv6, what effect do you imagine this draft will have on things? WEG> Well, as you've said, compliance with an RFC is often open to interpre= tation. It would be an interesting side-effect that some folks would decide= that some devices would no longer be compliant with the above-referenced R= FCs, but that wasn't specifically the aim of the draft. As I've said, I realize that the IETF is not the protocol police, and we ha= ve little say over what an implementer actually chooses to do. However - we= make recommendations in our standards all day every day with words like MU= ST, SHOULD, etc, and we expect that implementers will mostly follow those r= ecommendations, since they are based on a certain set of rationale, either = experimental or philosophical. I'm having trouble understanding why a recom= mendation/requirement to support IPv6 in "IP-capable" devices is being held= to a higher standard of relevance/impact than, say, deprecating MD5 for se= curing BGP sessions, something that is also still in wide use, but has a kn= own flaw and whose replacement is still not widely supported. There have been prior discussions about simply declaring IPv4 historic and = being done with it, but most folks I talked to agreed that this draft made = sense as a first step on that road. IETF has thus far remained fairly neutr= al about IPv6 vs IPv4 - you can do one, you can do the other, you can do bo= th, we don't care. It has been similar to when we have two or more equally = acceptable, standardized ways of solving the same problem - one is not pref= erred over the other, and each application will have to consider the pros a= nd cons of both options. However, at some point if the second solution is f= ound to have a flaw or something that makes the first a better choice, we o= ften update our guidance to say that one is "considered harmful" or some su= ch, indicating a preference for one solution over another, long before we a= ctually declare the other solution historical. When IPv6 was younger, it ma= de sense to remain neutral - IPv4 exhaustion was something we knew was happ= ening, but we had no idea when or what it would mean, and IPv6 was so narro= wly deployed that requiring it seemed exceptional. Now that we're at the "e= vent horizon", it seems odd to not acknowledge the obvious flaw with IPv4 -= we're out of unique addresses - and recommend an alternative, IPv6. My view is that this really isn't about RFC compliance checklists that you'= d see in an RFP from a company looking for network kit or software. Yes, th= e side effect is that this draft might get added to the list, but I don't t= hink it actually makes any difference on that front. Those same companies a= re perfectly capable of defining (and testing) exactly which parts of IPv6 = they want to have supported in the gear they're looking to purchase. This i= s more about the devices and software that are not normally built to some c= entralized purchasing requirement list, and therefore have no one telling t= hem they must support IPv6. The two goals that I see in this draft is that 1) IETF formally updates the= ir guidance (to anyone who cares about IETF's guidance) that IPv6 is necess= ary and that while it will still have plenty of perfectly acceptable applic= ations, supporting IPv4-only is not sustainable. 2) it updates the document= s that define "IP" (actually IPv4) to refer to the equivalent documents tha= t define IPv6 so that those looking for baseline protocol specs will find I= Pv6 and consider implementing even if they previously didn't even know that= they needed it. There are implementations that happen in a relative vacuum= using IETF standards as a guideline without necessarily being involved in = the IETF process or interacting with people who might say something about I= Pv6. This might help to catch some of those. Hopefully this helps to explain the goal in more pragmatic terms. 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 joelja@bogus.com Sat Jun 4 10:36:51 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5BCE06C3 for ; Sat, 4 Jun 2011 10:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.216 X-Spam-Level: X-Spam-Status: No, score=-102.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptYVF8Rxpe4j for ; Sat, 4 Jun 2011 10:36:51 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id BD486E06A6 for ; Sat, 4 Jun 2011 10:36:50 -0700 (PDT) Received: from [196.200.219.172] ([196.200.219.172]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p54Haemn050527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 4 Jun 2011 17:36:45 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: <00840C00-A351-4A81-83F5-8115028856FA@puck.nether.net> Date: Sat, 4 Jun 2011 10:36:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <34E4F50CAFA10349A41E0756550084FB0660DC20@PRVPEXVS04.corp.twcable.com> <63B6E461-79DD-41F7-B3F0-73AA6E0FDA8C@kumari.net> <00840C00-A351-4A81-83F5-8115028856FA@puck.nether.net> To: Jared Mauch X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 04 Jun 2011 17:36:48 +0000 (UTC) Cc: "Howard, Lee" , "int-area@ietf.org" , "cdl@asgaard.org" Subject: Re: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 17:36:51 -0000 I think it's a little sad that we have to state the painfully obvious = but I support the sentiment unequivocally. joel On Jun 2, 2011, at 4:53 PM, Jared Mauch wrote: > I support adoption of this draft as well. >=20 >=20 > - Jared Mauch >=20 > On Jun 2, 2011, at 1:17 PM, Warren Kumari wrote: >=20 >> I firmly support adoption of this draft.... >>=20 >> (I don't necessarily think it is going to change things much, but I = believe that it is worth adopting and giving it try...) >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area >=20 From bob.hinden@gmail.com Sun Jun 5 18:13:35 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F027E11E809D for ; Sun, 5 Jun 2011 18:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZ8-idTlXxAQ for ; Sun, 5 Jun 2011 18:13:33 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 023F311E8086 for ; Sun, 5 Jun 2011 18:13:32 -0700 (PDT) Received: by pzk5 with SMTP id 5so1780434pzk.31 for ; Sun, 05 Jun 2011 18:13:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=O/zVrJe4re8cc8NYBH+jeoDKlt8GsS3hmzrlcbWcceE=; b=Vv+Werpb/D9UpTWw6S6xPCm3bfEIRIzsVGoOagku4tNYYH9mwTk2R5JrnRVt8qNfcF o8fOKzce9xago6dG90GAaIshWrhsFvv2gN3Ssr9A4QaQUxe50lAaPsJZmTGXk0d0EZDw GsF+RsPy5BMDU+vtnXVWfvMPFvP+tkiPYs/2U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=PBWftgqPphkaMCi9Z1YzyMYrYAtQOOWbhw6VNtkaHYWAYl1ge44YrbNwc0y4iuK3uq EhqnSflyaRx54ed1ADHz1254hP08V9IB09biZ1lyvD9T115ZtWddMbqY4nVsiTxCK6t1 XMmTIFiF36SuSDSpV3RmomZOpFLd2J/Un7Yr4= Received: by 10.68.65.233 with SMTP id a9mr1723720pbt.187.1307322811215; Sun, 05 Jun 2011 18:13:31 -0700 (PDT) Received: from [10.0.0.37] (c-24-130-225-13.hsd1.ca.comcast.net [24.130.225.13]) by mx.google.com with ESMTPS id w2sm3281728pbg.69.2011.06.05.18.13.28 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 05 Jun 2011 18:13:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: Date: Sun, 5 Jun 2011 18:13:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <542E654A-BF30-4D8C-9556-42191188A0D7@gmail.com> References: <34E4F50CAFA10349A41E0756550084FB0660DC20@PRVPEXVS04.corp.twcable.com> <63B6E461-79DD-41F7-B3F0-73AA6E0FDA8C@kumari.net> <00840C00-A351-4A81-83F5-8115028856FA@puck.nether.net> To: Joel Jaeggli X-Mailer: Apple Mail (2.1084) Cc: "Howard, Lee" , "int-area@ietf.org" , "cdl@asgaard.org" Subject: Re: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 01:13:35 -0000 On Jun 4, 2011, at 10:36 AM, Joel Jaeggli wrote: > I think it's a little sad that we have to state the painfully obvious = but I support the sentiment unequivocally. +6 Bob >=20 > joel >=20 > On Jun 2, 2011, at 4:53 PM, Jared Mauch wrote: >=20 >> I support adoption of this draft as well. >>=20 >>=20 >> - Jared Mauch >>=20 >> On Jun 2, 2011, at 1:17 PM, Warren Kumari wrote: >>=20 >>> I firmly support adoption of this draft.... >>>=20 >>> (I don't necessarily think it is going to change things much, but I = believe that it is worth adopting and giving it try...) >>=20 >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area >>=20 >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From warren@kumari.net Sun Jun 5 19:30:11 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7BB11E807F for ; Sun, 5 Jun 2011 19:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vrtAe79l6GF for ; Sun, 5 Jun 2011 19:30:09 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id B003011E807B for ; Sun, 5 Jun 2011 19:30:09 -0700 (PDT) Received: from [192.168.0.235] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 964771B40429; Sun, 5 Jun 2011 22:30:08 -0400 (EDT) References: <34E4F50CAFA10349A41E0756550084FB0660DC20@PRVPEXVS04.corp.twcable.com> <63B6E461-79DD-41F7-B3F0-73AA6E0FDA8C@kumari.net> <00840C00-A351-4A81-83F5-8115028856FA@puck.nether.net> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8C148) Content-Type: text/plain; charset=us-ascii Message-Id: <1257A34E-41C1-474F-BBC8-0BFAFF267E91@kumari.net> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8C148) From: Warren Kumari Date: Sun, 5 Jun 2011 22:30:03 -0400 To: Joel Jaeggli Cc: "Howard, Lee" , "cdl@asgaard.org" , "int-area@ietf.org" Subject: Re: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 02:30:11 -0000 On Jun 4, 2011, at 1:36 PM, Joel Jaeggli wrote: > I think it's a little sad that we have to state the painfully obvious but I= support the sentiment unequivocally. >=20 This is the IETF -- stating the painfully obvious is what we do best... W > joel >=20 > On Jun 2, 2011, at 4:53 PM, Jared Mauch wrote: >=20 >> I support adoption of this draft as well. >>=20 >>=20 >> - Jared Mauch >>=20 >> On Jun 2, 2011, at 1:17 PM, Warren Kumari wrote: >>=20 >>> I firmly support adoption of this draft.... >>>=20 >>> (I don't necessarily think it is going to change things much, but I beli= eve that it is worth adopting and giving it try...) >>=20 >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area >>=20 >=20 From internet-drafts@ietf.org Tue Jun 7 03:12:00 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB2D11E80D4; Tue, 7 Jun 2011 03:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbMBCQtdQ3Sf; Tue, 7 Jun 2011 03:12:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E8211E80BE; Tue, 7 Jun 2011 03:12:00 -0700 (PDT) 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.55 Message-ID: <20110607101200.26136.31205.idtracker@ietfa.amsl.com> Date: Tue, 07 Jun 2011 03:12:00 -0700 Cc: int-area@ietf.org Subject: [Int-area] I-D Action: draft-ietf-intarea-router-alert-considerations-04.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 10:12:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Internet Area Working Group Working G= roup of the IETF. Title : IP Router Alert Considerations and Usage Author(s) : Francois Le Faucheur Filename : draft-ietf-intarea-router-alert-considerations-04.txt Pages : 24 Date : 2011-06-07 The IP Router Alert Option is an IP option that alerts transit routers to more closely examine the contents of an IP packet. RSVP, PGM, IGMP/MLD, MRD and GIST are some of the protocols that make use of the IP Router Alert option. This document discusses security aspects and usage guidelines around the use of the current IP Router Alert option. Specifically, it provides recommendation against using the Router Alert in the end-to-end open Internet as well as identify controlled environments where protocols depending on Router Alert can be used safely. It also provides recommendation about protection approaches for Service Providers. Finally it provides brief guidelines for Router Alert implementation on routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-intarea-router-alert-conside= rations-04.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-intarea-router-alert-consider= ations-04.txt From julien.ietf@gmail.com Wed Jun 8 13:56:38 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7F021F84BD for ; Wed, 8 Jun 2011 13:56:38 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MregW2kaFs+f for ; Wed, 8 Jun 2011 13:56:37 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA2B21F84BF for ; Wed, 8 Jun 2011 13:56:34 -0700 (PDT) Received: by bwz13 with SMTP id 13so892862bwz.31 for ; Wed, 08 Jun 2011 13:56:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=bVQJQNAxvN5rmNL8lVsqbuDuhBN82x6GQH/4n8WO+NU=; b=RzE6p1xE8I0AwCXN4M6CDzRX8tEEY04M10tHCqF+qqXiKwiJitFKYB4diPyrh6wJVC BN5vaSzwMcbkGweEKEr+m7y9PZ3rA3oMORgeFAIU5PwRSADlF71jH+9o25CEggh6AsQV yAuAtffbXbRpmX6mU65DAVAGIFP0vN7uMTj0A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=SB5jR0ktPTYhrEnhDIqUzdOMO+vYgwTTBqQtY2YJGy32+ysS6QAF9dpg4ACBOD+s7T Ymyma8wGvEN5mZBhg9a+0aARAIk5oHwBcxO+aPM3qO2O8FbrOS0gfNzXfw9FbnUbm3DQ CwSdCAYSju5cSsrEp65ijeEKg8a0CpGX2ETT8= MIME-Version: 1.0 Received: by 10.205.82.67 with SMTP id ab3mr1231414bkc.166.1307566591280; Wed, 08 Jun 2011 13:56:31 -0700 (PDT) Received: by 10.204.101.203 with HTTP; Wed, 8 Jun 2011 13:56:30 -0700 (PDT) Date: Wed, 8 Jun 2011 13:56:30 -0700 Message-ID: From: Julien Laganier To: int-area@ietf.org, intarea-chairs@tools.ietf.org, draft-ietf-intarea-router-alert-considerations@tools.ietf.org Content-Type: multipart/mixed; boundary=bcaec554e06c31882804a53992c9 Subject: [Int-area] Publication requested: draft-ietf-intarea-router-alert-considerations-04 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 20:56:38 -0000 --bcaec554e06c31882804a53992c9 Content-Type: text/plain; charset=ISO-8859-1 Secretariat (BCC'd): This message requests publication of draft-ietf-intarea-router-alert-considerations-04. The I-D write-up is attached. --bcaec554e06c31882804a53992c9 Content-Type: text/plain; charset=US-ASCII; name="draft-ietf-intarea-router-alert-considerations-03-writeup.txt" Content-Disposition: attachment; filename="draft-ietf-intarea-router-alert-considerations-03-writeup.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_goorcb6t0 ICAoMS5hKSBXaG8gaXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIGZvciB0aGlzIGRvY3VtZW50PyBI YXMgdGhlDQogICAgICAgIERvY3VtZW50IFNoZXBoZXJkIHBlcnNvbmFsbHkgcmV2aWV3ZWQgdGhp cyB2ZXJzaW9uIG9mIHRoZSANCiAgICAgICAgZG9jdW1lbnQgYW5kLCBpbiBwYXJ0aWN1bGFyLCBk b2VzIGhlIG9yIHNoZSBiZWxpZXZlIHRoaXMgDQogICAgICAgIHZlcnNpb24gaXMgcmVhZHkgZm9y IGZvcndhcmRpbmcgdG8gdGhlIElFU0cgZm9yIHB1YmxpY2F0aW9uPyANCg0KCVRoZSBEb2N1bWVu dCBTaGVwaGVyZCBpcyBKdWxpZW4gTGFnYW5pZXIsIElOVEFSRUEgY28tY2hhaXIuIEhlDQogICAg ICAgIGhhcyBwZXJzb25hbGx5IGRvbmUgYSB0aG9yb3VnaCByZXZpZXcgb2YgdGhlIGRvY3VtZW50 LiBIZQ0KICAgICAgICBiZWxpZXZlIHRoZSBkb2N1bWVudCBpcyByZWFkeSBmb3IgZm9yd2FyZGlu ZyB0byBJRVNHIGZvcg0KICAgICAgICBwdWJsaWNhdGlvbi4NCgkNCiAgKDEuYikgSGFzIHRoZSBk b2N1bWVudCBoYWQgYWRlcXVhdGUgcmV2aWV3IGJvdGggZnJvbSBrZXkgV0cgbWVtYmVycyANCiAg ICAgICAgYW5kIGZyb20ga2V5IG5vbi1XRyBtZW1iZXJzPyBEb2VzIHRoZSBEb2N1bWVudCBTaGVw aGVyZCBoYXZlIA0KICAgICAgICBhbnkgY29uY2VybnMgYWJvdXQgdGhlIGRlcHRoIG9yIGJyZWFk dGggb2YgdGhlIHJldmlld3MgdGhhdCANCiAgICAgICAgaGF2ZSBiZWVuIHBlcmZvcm1lZD8gIA0K DQogICAgICAgIFRoZSBkb2N1bWVudCB3YXMgZ2l2ZW4gYWRlcXVhdGUgcmV2aWV3cy4gVGhlIERv Y3VtZW50IFNoZXBoZXJkIGhhcw0KICAgICAgICBubyBjb25jZXJucyBhYm91dCB0aGUgZGVwdGgg b3IgYnJlYWR0aCBvZiB0aGVzZSByZXZpZXdzLg0KDQogICgxLmMpIERvZXMgdGhlIERvY3VtZW50 IFNoZXBoZXJkIGhhdmUgY29uY2VybnMgdGhhdCB0aGUgZG9jdW1lbnQgDQogICAgICAgIG5lZWRz IG1vcmUgcmV2aWV3IGZyb20gYSBwYXJ0aWN1bGFyIG9yIGJyb2FkZXIgcGVyc3BlY3RpdmUsIA0K ICAgICAgICBlLmcuLCBzZWN1cml0eSwgb3BlcmF0aW9uYWwgY29tcGxleGl0eSwgc29tZW9uZSBm YW1pbGlhciB3aXRoIA0KICAgICAgICBBQUEsIGludGVybmF0aW9uYWxpemF0aW9uIG9yIFhNTD8g DQoNCiAgICAgICAgVGhlIERvY3VtZW50IFNoZXBoZXJkIGhhcyBubyBzdWNoIGNvbmNlcm5zLg0K DQogICgxLmQpIERvZXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIGhhdmUgYW55IHNwZWNpZmljIGNv bmNlcm5zIG9yIA0KICAgICAgICBpc3N1ZXMgd2l0aCB0aGlzIGRvY3VtZW50IHRoYXQgdGhlIFJl c3BvbnNpYmxlIEFyZWEgRGlyZWN0b3INCiAgICAgICAgYW5kL29yIHRoZSBJRVNHIHNob3VsZCBi ZSBhd2FyZSBvZj8gRm9yIGV4YW1wbGUsIHBlcmhhcHMgaGUgDQogICAgICAgIG9yIHNoZSBpcyB1 bmNvbWZvcnRhYmxlIHdpdGggY2VydGFpbiBwYXJ0cyBvZiB0aGUgZG9jdW1lbnQsIG9yIA0KICAg ICAgICBoYXMgY29uY2VybnMgd2hldGhlciB0aGVyZSByZWFsbHkgaXMgYSBuZWVkIGZvciBpdC4g SW4gYW55IA0KICAgICAgICBldmVudCwgaWYgdGhlIFdHIGhhcyBkaXNjdXNzZWQgdGhvc2UgaXNz dWVzIGFuZCBoYXMgaW5kaWNhdGVkIA0KICAgICAgICB0aGF0IGl0IHN0aWxsIHdpc2hlcyB0byBh ZHZhbmNlIHRoZSBkb2N1bWVudCwgZGV0YWlsIHRob3NlIA0KICAgICAgICBjb25jZXJucyBoZXJl LiBIYXMgYW4gSVBSIGRpc2Nsb3N1cmUgcmVsYXRlZCB0byB0aGlzIGRvY3VtZW50IA0KICAgICAg ICBiZWVuIGZpbGVkPyBJZiBzbywgcGxlYXNlIGluY2x1ZGUgYSByZWZlcmVuY2UgdG8gdGhlIA0K ICAgICAgICBkaXNjbG9zdXJlIGFuZCBzdW1tYXJpemUgdGhlIFdHIGRpc2N1c3Npb24gYW5kIGNv bmNsdXNpb24gb24gDQogICAgICAgIHRoaXMgaXNzdWUuIA0KDQogICAgICAgIFRoZSBEb2N1bWVu dCBTaGVwaGVyZCBoYXMgbm8gc3VjaCBjb25jZXJucy4NCg0KICAoMS5lKSBIb3cgc29saWQgaXMg dGhlIFdHIGNvbnNlbnN1cyBiZWhpbmQgdGhpcyBkb2N1bWVudD8gRG9lcyBpdCANCiAgICAgICAg cmVwcmVzZW50IHRoZSBzdHJvbmcgY29uY3VycmVuY2Ugb2YgYSBmZXcgaW5kaXZpZHVhbHMsIHdp dGggDQogICAgICAgIG90aGVycyBiZWluZyBzaWxlbnQsIG9yIGRvZXMgdGhlIFdHIGFzIGEgd2hv bGUgdW5kZXJzdGFuZCBhbmQgDQogICAgICAgIGFncmVlIHdpdGggaXQ/ICAgDQoNCglUaGVyZSBp cyBXRyBjb25zZW5zdXMgYmVoaW5kIHRoaXMgZG9jdW1lbnQuDQoNCiAgKDEuZikgSGFzIGFueW9u ZSB0aHJlYXRlbmVkIGFuIGFwcGVhbCBvciBvdGhlcndpc2UgaW5kaWNhdGVkIGV4dHJlbWUgDQog ICAgICAgIGRpc2NvbnRlbnQ/IElmIHNvLCBwbGVhc2Ugc3VtbWFyaXNlIHRoZSBhcmVhcyBvZiBj b25mbGljdCBpbiANCiAgICAgICAgc2VwYXJhdGUgZW1haWwgbWVzc2FnZXMgdG8gdGhlIFJlc3Bv bnNpYmxlIEFyZWEgRGlyZWN0b3IuIChJdCANCiAgICAgICAgc2hvdWxkIGJlIGluIGEgc2VwYXJh dGUgZW1haWwgYmVjYXVzZSB0aGlzIHF1ZXN0aW9ubmFpcmUgaXMgDQogICAgICAgIGVudGVyZWQg aW50byB0aGUgSUQgVHJhY2tlci4pIA0KDQogICAgICAgIE5vLg0KDQogICgxLmcpIEhhcyB0aGUg RG9jdW1lbnQgU2hlcGhlcmQgcGVyc29uYWxseSB2ZXJpZmllZCB0aGF0IHRoZSANCiAgICAgICAg ZG9jdW1lbnQgc2F0aXNmaWVzIGFsbCBJRCBuaXRzPyAoU2VlIHRoZSBJbnRlcm5ldC1EcmFmdHMg Q2hlY2tsaXN0IA0KICAgICAgICBhbmQgaHR0cDovL3Rvb2xzLmlldGYub3JnL3Rvb2xzL2lkbml0 cy8pLiBCb2lsZXJwbGF0ZSBjaGVja3MgYXJlIA0KICAgICAgICBub3QgZW5vdWdoOyB0aGlzIGNo ZWNrIG5lZWRzIHRvIGJlIHRob3JvdWdoLiBIYXMgdGhlIGRvY3VtZW50IA0KICAgICAgICBtZXQg YWxsIGZvcm1hbCByZXZpZXcgY3JpdGVyaWEgaXQgbmVlZHMgdG8sIHN1Y2ggYXMgdGhlIE1JQiAN CiAgICAgICAgRG9jdG9yLCBtZWRpYSB0eXBlIGFuZCBVUkkgdHlwZSByZXZpZXdzPyANCg0KCVll cy4NCg0KICAoMS5oKSBIYXMgdGhlIGRvY3VtZW50IHNwbGl0IGl0cyByZWZlcmVuY2VzIGludG8g bm9ybWF0aXZlIGFuZCANCiAgICAgICAgaW5mb3JtYXRpdmU/IEFyZSB0aGVyZSBub3JtYXRpdmUg cmVmZXJlbmNlcyB0byBkb2N1bWVudHMgdGhhdCANCiAgICAgICAgYXJlIG5vdCByZWFkeSBmb3Ig YWR2YW5jZW1lbnQgb3IgYXJlIG90aGVyd2lzZSBpbiBhbiB1bmNsZWFyIA0KICAgICAgICBzdGF0 ZT8gSWYgc3VjaCBub3JtYXRpdmUgcmVmZXJlbmNlcyBleGlzdCwgd2hhdCBpcyB0aGUgDQogICAg ICAgIHN0cmF0ZWd5IGZvciB0aGVpciBjb21wbGV0aW9uPyBBcmUgdGhlcmUgbm9ybWF0aXZlIHJl ZmVyZW5jZXMgDQogICAgICAgIHRoYXQgYXJlIGRvd253YXJkIHJlZmVyZW5jZXMsIGFzIGRlc2Ny aWJlZCBpbiBbUkZDMzk2N10/IElmIA0KICAgICAgICBzbywgbGlzdCB0aGVzZSBkb3dud2FyZCBy ZWZlcmVuY2VzIHRvIHN1cHBvcnQgdGhlIEFyZWEgDQogICAgICAgIERpcmVjdG9yIGluIHRoZSBM YXN0IENhbGwgcHJvY2VkdXJlIGZvciB0aGVtIFtSRkMzOTY3XS4gDQoNCglUaGUgZG9jdW1lbnQg aGFzIHNwbGl0IGl0cyByZWZlcmVuY2VzIGludG8gbm9ybWF0aXZlIGFuZA0KICAgICAgICBpbmZv cm1hdGl2ZS4gVGhlcmUgYXJlIG5laXRoZXIgbm9ybWF0aXZlIHJlZmVyZW5jZXMgaW4gYW4gdW5j bGVhcg0KICAgICAgICBzdGF0ZSwgbm9yIGRvd253YXJkIHJlZmVyZW5jZXMuIA0KDQogICgxLmkp IEhhcyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQgdmVyaWZpZWQgdGhhdCB0aGUgZG9jdW1lbnQgSUFO QSANCiAgICAgICAgY29uc2lkZXJhdGlvbiBzZWN0aW9uIGV4aXN0cyBhbmQgaXMgY29uc2lzdGVu dCB3aXRoIHRoZSBib2R5IA0KICAgICAgICBvZiB0aGUgZG9jdW1lbnQ/IElmIHRoZSBkb2N1bWVu dCBzcGVjaWZpZXMgcHJvdG9jb2wgDQogICAgICAgIGV4dGVuc2lvbnMsIGFyZSByZXNlcnZhdGlv bnMgcmVxdWVzdGVkIGluIGFwcHJvcHJpYXRlIElBTkEgDQogICAgICAgIHJlZ2lzdHJpZXM/IEFy ZSB0aGUgSUFOQSByZWdpc3RyaWVzIGNsZWFybHkgaWRlbnRpZmllZD8gSWYgDQogICAgICAgIHRo ZSBkb2N1bWVudCBjcmVhdGVzIGEgbmV3IHJlZ2lzdHJ5LCBkb2VzIGl0IGRlZmluZSB0aGUgDQog ICAgICAgIHByb3Bvc2VkIGluaXRpYWwgY29udGVudHMgb2YgdGhlIHJlZ2lzdHJ5IGFuZCBhbiBh bGxvY2F0aW9uIA0KICAgICAgICBwcm9jZWR1cmUgZm9yIGZ1dHVyZSByZWdpc3RyYXRpb25zPyBE b2VzIGl0IHN1Z2dlc3QgYSANCiAgICAgICAgcmVhc29uYWJsZSBuYW1lIGZvciB0aGUgbmV3IHJl Z2lzdHJ5PyBTZWUgW1JGQzUyMjZdLiBJZiB0aGUgDQogICAgICAgIGRvY3VtZW50IGRlc2NyaWJl cyBhbiBFeHBlcnQgUmV2aWV3IHByb2Nlc3MgaGFzIFNoZXBoZXJkIA0KICAgICAgICBjb25mZXJy ZWQgd2l0aCB0aGUgUmVzcG9uc2libGUgQXJlYSBEaXJlY3RvciBzbyB0aGF0IHRoZSBJRVNHIA0K ICAgICAgICBjYW4gYXBwb2ludCB0aGUgbmVlZGVkIEV4cGVydCBkdXJpbmcgdGhlIElFU0cgRXZh bHVhdGlvbj8gDQoNCiAgICAgICAgVGhlIGRvY3VtZW50IGhhcyBhbiBJQU5BIGNvbnNpZGVyYXRp b25zIHNlY3Rpb25zIHRoYXQgY29ycmVjdGx5DQoJc3RhdGUgdGhhdCB0aGUgZG9jdW1lbnQgZG9l cyBub3QgbmVlZCBJQU5BIGFjdGlvbnMuDQoNCiAgKDEuaikgSGFzIHRoZSBEb2N1bWVudCBTaGVw aGVyZCB2ZXJpZmllZCB0aGF0IHNlY3Rpb25zIG9mIHRoZSANCiAgICAgICAgZG9jdW1lbnQgdGhh dCBhcmUgd3JpdHRlbiBpbiBhIGZvcm1hbCBsYW5ndWFnZSwgc3VjaCBhcyBYTUwgDQogICAgICAg IGNvZGUsIEJORiBydWxlcywgTUlCIGRlZmluaXRpb25zLCBldGMuLCB2YWxpZGF0ZSBjb3JyZWN0 bHkgaW4gDQogICAgICAgIGFuIGF1dG9tYXRlZCBjaGVja2VyPyANCg0KICAgICAgICBUaGVyZSBh cmUgbm8gc3VjaCBzZWN0aW9ucy4NCg0KICAoMS5rKSBUaGUgSUVTRyBhcHByb3ZhbCBhbm5vdW5j ZW1lbnQgaW5jbHVkZXMgYSBEb2N1bWVudCANCiAgICAgICAgQW5ub3VuY2VtZW50IFdyaXRlLVVw LiBQbGVhc2UgcHJvdmlkZSBzdWNoIGEgRG9jdW1lbnQgDQogICAgICAgIEFubm91bmNlbWVudCBX cml0ZS1VcD8gUmVjZW50IGV4YW1wbGVzIGNhbiBiZSBmb3VuZCBpbiB0aGUNCiAgICAgICAgIkFj dGlvbiIgYW5ub3VuY2VtZW50cyBmb3IgYXBwcm92ZWQgZG9jdW1lbnRzLiBUaGUgYXBwcm92YWwg DQogICAgICAgIGFubm91bmNlbWVudCBjb250YWlucyB0aGUgZm9sbG93aW5nIHNlY3Rpb25zOiAN Cg0KICAgICBUZWNobmljYWwgU3VtbWFyeSANCg0KICAgVGhlIElQIFJvdXRlciBBbGVydCBPcHRp b24gaXMgYW4gSVAgb3B0aW9uIHRoYXQgYWxlcnRzIHRyYW5zaXQNCiAgIHJvdXRlcnMgdG8gbW9y ZSBjbG9zZWx5IGV4YW1pbmUgdGhlIGNvbnRlbnRzIG9mIGFuIElQIHBhY2tldC4gIFJTVlAsDQog ICBQR00sIElHTVAvTUxELCBNUkQgYW5kIEdJU1QgYXJlIHNvbWUgb2YgdGhlIHByb3RvY29scyB0 aGF0IG1ha2UgdXNlDQogICBvZiB0aGUgSVAgUm91dGVyIEFsZXJ0IG9wdGlvbi4gIFRoaXMgZG9j dW1lbnQgZGlzY3Vzc2VzIHNlY3VyaXR5DQogICBhc3BlY3RzIGFuZCB1c2FnZSBndWlkZWxpbmVz IGFyb3VuZCB0aGUgdXNlIG9mIHRoZSBjdXJyZW50IElQIFJvdXRlcg0KICAgQWxlcnQgb3B0aW9u LiAgU3BlY2lmaWNhbGx5LCBpdCBwcm92aWRlcyByZWNvbW1lbmRhdGlvbiBhZ2FpbnN0IHVzaW5n DQogICB0aGUgUm91dGVyIEFsZXJ0IGluIHRoZSBlbmQtdG8tZW5kIG9wZW4gSW50ZXJuZXQgYXMg d2VsbCBhcyBpZGVudGlmeQ0KICAgY29udHJvbGxlZCBlbnZpcm9ubWVudHMgd2hlcmUgcHJvdG9j b2xzIGRlcGVuZGluZyBvbiBSb3V0ZXIgQWxlcnQgY2FuDQogICBiZSB1c2VkIHNhZmVseS4gIEl0 IGFsc28gcHJvdmlkZXMgcmVjb21tZW5kYXRpb24gYWJvdXQgcHJvdGVjdGlvbg0KICAgYXBwcm9h Y2hlcyBmb3IgU2VydmljZSBQcm92aWRlcnMuICBGaW5hbGx5IGl0IHByb3ZpZGVzIGJyaWVmDQog ICBndWlkZWxpbmVzIGZvciBSb3V0ZXIgQWxlcnQgaW1wbGVtZW50YXRpb24gb24gcm91dGVycy4N Cg0KICAgICBXb3JraW5nIEdyb3VwIFN1bW1hcnkgDQoNCiAgIFRoZSBub3JtYWwgV0cgcHJvY2Vz cyB3YXMgZm9sbG93ZWQgYW5kIHRoZSBkb2N1bWVudCBhcyBpdCBzdGFuZHMgbm93DQogICByZWZs ZWN0cyBXRyBjb25zZW5zdXMgd2l0aCBub3RoaW5nIHNwZWNpYWwgd29ydGggbWVudGlvbmluZy4N Cg0KICAgICBEb2N1bWVudCBRdWFsaXR5IA0KDQogICBUaGUgZG9jdW1lbnQgd2FzIGdpdmVuIGFk ZXF1YXRlIHJldmlld3MuIFRoZSBEb2N1bWVudCBTaGVwaGVyZCBoYXMNCiAgIG5vIGNvbmNlcm5z IGFib3V0IHRoZSBkZXB0aCBvciBicmVhZHRoIG9mIHRoZXNlIHJldmlld3MuDQo= --bcaec554e06c31882804a53992c9-- From mohamed.boucadair@orange-ftgroup.com Fri Jun 10 04:53:23 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5BD11E8083; Fri, 10 Jun 2011 04:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXXnCCAa-7bz; Fri, 10 Jun 2011 04:53:22 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 1580911E807E; Fri, 10 Jun 2011 04:53:22 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id F2BB12AC415; Fri, 10 Jun 2011 13:53:20 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id CE042C805C; Fri, 10 Jun 2011 13:53:20 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Fri, 10 Jun 2011 13:53:20 +0200 From: To: "behave@ietf.org" , "int-area@ietf.org" , 'Behave Chairs' , "intarea-chairs@tools.ietf.org" Date: Fri, 10 Jun 2011 13:53:18 +0200 Thread-Topic: Analysis of Solution Candidates to Reveal a Host Identifier in Shared Address Deployments I-D Thread-Index: AcwnZP1jDfelOgRuT1G1WudO8+/Z0Q== Message-ID: <94C682931C08B048B7A8645303FDC9F33E5016263D@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F33E5016263DPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.6.10.111214 X-Mailman-Approved-At: Fri, 10 Jun 2011 08:08:32 -0700 Cc: 'Tom Taylor' , "draft-boucadair-intarea-nat-reveal-analysis@tools.ietf.org" , 'ZhangDong' , "fine_sz@huawei.com" , Peter McCann Subject: [Int-area] Analysis of Solution Candidates to Reveal a Host Identifier in Shared Address Deployments I-D X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 11:53:23 -0000 --_000_94C682931C08B048B7A8645303FDC9F33E5016263DPUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, A new version of the draft taking into account the comments received in Pra= gue (INTAREA and BEHAVE meetings) has been submitted: http://www.ietf.org/internet-drafts/draft-boucadair-intarea-nat-reveal-anal= ysis-02.txt In particular, a new sub-section has been introduced to clarify the confusi= ons related to privacy concerns. As stated in the document, the purpose of this document is not to advocate = for the practice to inject a HOST_ID but to analyse to what extent these so= lutions mitigate some of the issues documented in http://tools.ietf.org/htm= l/draft-ietf-intarea-shared-addressing-issues-05 and to identify the side e= ffects and the viability of the proposed solutions. The document focuses on IPv4 address sharing (e.g., NAT44, DS-Lite, NAT64) = but some issues may be valid for IPv6 too (e.g., hosts sharing the same /64= ). We, authors of this document, would like to see this work progress within i= ntarea or behave since these two WG seems to be concerned with these issues= . Guidelines from BEHAVE and INTAREA chairs for the appropriate working to = host this work are more than welcome. Questions, comments, suggestions are welcome. Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F33E5016263DPUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D= ear=20 all,
 
A= new=20 version of the draft taking into account the comments received in Prague=20 (INTAREA and BEHAVE meetings) has been submitted:
<= A=20 href=3D"http://www.ietf.org/internet-drafts/draft-boucadair-intarea-nat-rev= eal-analysis-02.txt">http://www.ietf.org/internet-drafts/draft-boucadair-intarea-nat-r= eveal-analysis-02.txt
 
I= n=20 particular, a new sub-section has been introduced to clarify the confusions= =20 related to privacy concerns.
 
A= s stated in=20 the document, the purpose of this document is not to advocate for the pract= ice=20 to inject a HOST_ID but to analyse to what extent these solutions mitigate = some=20 of the issues documented in http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-iss= ues-05 and=20 to identify the side effects and the viability of the proposed=20 solutions.
 
T= he document=20 focuses on IPv4 address sharing (e.g., NAT44, DS-Lite, NAT64) but some= =20 issues may be valid for IPv6 too (e.g., hosts sharing the same=20 /64). 
 
W= e, authors=20 of this document, would like to see this work progress within intarea or be= have=20 since these two WG seems to be concerned with these issues. Guidelines from= =20 BEHAVE and INTAREA chairs for the appropriate working to host this wor= k are=20 more than welcome.
 
Q= uestions,=20 comments, suggestions are welcome.
 
Cheers,
Med
--_000_94C682931C08B048B7A8645303FDC9F33E5016263DPUEXCB1Bnante_-- From scott.brim@gmail.com Sat Jun 11 16:17:39 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F1B11E8097 for ; Sat, 11 Jun 2011 16:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uavsjPl3OOH for ; Sat, 11 Jun 2011 16:17:38 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D224411E807C for ; Sat, 11 Jun 2011 16:17:38 -0700 (PDT) Received: by iyn15 with SMTP id 15so4087057iyn.31 for ; Sat, 11 Jun 2011 16:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=zYPOiXlRj4wsvj7eJtR6/FIpL39PtH1oCLYwe9P3QLE=; b=fceYQXE/YPyOeKnX5rxnN633Nh3Ubx/9gmK8hZF+xGGlYgZn0VVRkL3uG7wHZAAhf4 PT5lqtc0fOYUKY0SXAprIvPM77bKEhX4b0gd9BH5rK8ujP5PnGiP0WvsowhIpBL5IUkN RABjS/Pb7MP/0+rnQJlkFfHyjI80FbJq0P+K4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=D8q1U9LkwjQz+VA2apMTHoqSQTJ2jaiGAnPs8vjFXee9bQuFZsszhS0JNYDT1gsV1W YY8YzRL9d77G35i4d6ODFYCtJfNQAzrHWfOdWpJRVvRqdlLllt9mK8gjn0YKoIPvFrGo VYMEBE/b4NnI+Q9IUbLvT8VcOJnoA9qT3/srs= Received: by 10.231.203.132 with SMTP id fi4mr3958627ibb.69.1307834258088; Sat, 11 Jun 2011 16:17:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.12.9 with HTTP; Sat, 11 Jun 2011 16:17:18 -0700 (PDT) In-Reply-To: <4DE7B521.8050301@isi.edu> References: <00c701cc2135$51d998e0$4001a8c0@gateway.2wire.net> <4DE7B521.8050301@isi.edu> From: Scott Brim Date: Sat, 11 Jun 2011 19:17:18 -0400 Message-ID: To: Internet Area Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Int-area] IRON issue discussion X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 23:17:39 -0000 Folks, speaking for myself: Regarding IRON, I heard support for discussion but very little actual discussion. It kind of died at the starting gate. Right now I don't see why IRON should have agenda time until there is clear disagreement or confusion. Tom said > Mangling my metaphors, build a better mouse trap and nothing happens. > I believe that this 'mouse trap' deserves a wider hearing than it got on > RRG list and agenda time would give it that. I believe I understand it > but more discussion would probably throw up some misunderstandings > on my part and Joe said > A useful way forward might be a short presentation that highlights > the components of IRON, and where each addresses a key issue > important to INTAREA. The entire system as a whole may be relevant, > but the parts need to be understood and appreciated first, IMO. Both of these wishes could be satisfied by mail from Fred, referring to sections of the already published RFC. No? At least we should try. Scott From Fred.L.Templin@boeing.com Mon Jun 13 18:52:02 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2160621F84D2 for ; Mon, 13 Jun 2011 18:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSzobsq2i9sw for ; Mon, 13 Jun 2011 18:52:01 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id 91B5921F84CF for ; Mon, 13 Jun 2011 18:52:01 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p5E1puv1026131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 13 Jun 2011 18:51:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id p5E0YKrc020774 for ; Mon, 13 Jun 2011 17:34:20 -0700 (PDT) Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p5E0YBQk020564 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 13 Jun 2011 17:34:12 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Mon, 13 Jun 2011 18:51:47 -0700 From: "Templin, Fred L" To: Scott Brim , Internet Area Date: Mon, 13 Jun 2011 18:51:45 -0700 Thread-Topic: [Int-area] IRON issue discussion Thread-Index: AcwojcYD62EaWEV4SkizLaNwbDYWDABp86gg Message-ID: References: <00c701cc2135$51d998e0$4001a8c0@gateway.2wire.net> <4DE7B521.8050301@isi.edu> 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: [Int-area] IRON issue discussion X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 01:52:02 -0000 Hi Scott, Thanks for your message. I will go back and respond to the earlier list messages. Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: int-area-bounces@ietf.org=20 > [mailto:int-area-bounces@ietf.org] On Behalf Of Scott Brim > Sent: Saturday, June 11, 2011 4:17 PM > To: Internet Area > Subject: Re: [Int-area] IRON issue discussion >=20 > Folks, speaking for myself: >=20 > Regarding IRON, I heard support for discussion but very little > actual discussion. It kind of died at the starting gate. =20 > Right now I don't > see why IRON should have agenda time until there is clear disagreement > or confusion. >=20 > Tom said >=20 > > Mangling my metaphors, build a better mouse trap and=20 > nothing happens. > > I believe that this 'mouse trap' deserves a wider hearing=20 > than it got on > > RRG list and agenda time would give it that. I believe I=20 > understand it > > but more discussion would probably throw up some misunderstandings > > on my part >=20 > and Joe said >=20 > > A useful way forward might be a short presentation that highlights > > the components of IRON, and where each addresses a key issue > > important to INTAREA. The entire system as a whole may be relevant, > > but the parts need to be understood and appreciated first, IMO. >=20 > Both of these wishes could be satisfied by mail from Fred, referring > to sections of the already published RFC. No? At least we=20 > should try. >=20 > Scott > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > = From Fred.L.Templin@boeing.com Mon Jun 13 19:12:23 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C0521F8639 for ; Mon, 13 Jun 2011 19:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3rc0TjABDBC for ; Mon, 13 Jun 2011 19:12:22 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id A607021F8638 for ; Mon, 13 Jun 2011 19:12:22 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p5E2CJCf000043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Jun 2011 19:12:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id p5E2CJn3003237; Mon, 13 Jun 2011 19:12:19 -0700 (PDT) Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p5E2CEQq003177 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 13 Jun 2011 19:12:14 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Mon, 13 Jun 2011 19:12:14 -0700 From: "Templin, Fred L" To: "t.petch" , Scott Brim Date: Mon, 13 Jun 2011 19:12:12 -0700 Thread-Topic: IRON issue discussion Thread-Index: AcwhPgLVTV7lNn04S9+GOsk24XjGpwI9/WNg Message-ID: References: <00c701cc2135$51d998e0$4001a8c0@gateway.2wire.net> In-Reply-To: <00c701cc2135$51d998e0$4001a8c0@gateway.2wire.net> 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: Internet Area Subject: Re: [Int-area] IRON issue discussion X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 02:12:24 -0000 Hi Tom, > -----Original Message----- > From: t.petch [mailto:ietfc@btconnect.com]=20 > Sent: Thursday, June 02, 2011 7:57 AM > To: Scott Brim > Cc: Templin, Fred L; Internet Area > Subject: Re: IRON issue discussion >=20 > ----- Original Message ----- > From: "Scott Brim" > To: "t.petch" > Cc: "Templin, Fred L" ; "Internet Area" > > Sent: Thursday, June 02, 2011 4:08 PM >=20 > > First, I've changed the subject (but kept the threading). > > > > Second, on this specific issue -- discussion of IRON topics=20 > to see if > > there are any that canNOT be clarified on the mailing list, and thus > > need agenda time -- Tom, you say > > > > > I think that what is wrong with Fred's list is point 1);=20 > a technical nicety > > > that slows the reader down from getting to points 2) etc,=20 > which are > > > critical:-) > > > > If I understand correctly, you understand IRON, but you think others > > might have trouble understanding it, and you are suggesting some > > rewrites? No agenda time needed? > > > > If there are in fact points you disagree with or believe need > > clarifying, could you make them explicit? >=20 > Mangling my metaphors, build a better mouse trap and nothing happens. > I believe that this 'mouse trap' deserves a wider hearing=20 > than it got on > RRG list and agenda time would give it that. I believe I=20 > understand it > but more discussion would probably throw up some misunderstandings > on my part (I always intended to submit a review on the RRG list which > is the way to see if I understand it or not but, with hindsight, > never gave that work enough priority). Thanks for your note. Let me try a more high-level description of the IRON system and see if it serves to clarify or confuse: The IRON system comprises a virtual overlay network set up by a provider (perhaps an ISP or a hosting service company) with the objective of providing network address/prefix services to client customers. The provider's deployment includes tunnel endpoint servers and relays that connect the virtual overlay network to the rest of the public Internet. The clients can be either routers or hosts, and can be either mobile or fixed. They connect to a nearby IRON server via a either VPN (when security is needed) or a plaintext IP-in-IP tunnel. =20 In this system, the client gets to use a stable IP address or prefix even if it moves between different IRON servers, but the IRON relays only advertise one or a few short IP prefixes into the global Internet routing system. The servers and relays engage in a routing protocol instance (perhaps using iBGP) to track the association of clients with servers. Clients only move to new servers if they travel significant distances; hence the client-to-server mobility can take place over very coarse timescales (tens of seconds or even longer). On the other hand, clients quickly inform their current server of a change in locator address which can happen on very short timescales (seconds or less). Clients can further be redirected to a server that is closer to the final destination as a form of route optimization. That function is now covered in more detail in 'draft-templin-aero'. That's about it in terms of the overall architecture. The part that gets more detailed is how the clients select good servers and quickly inform them of any locator address changes due to mobility or multihoming. This is the part where I saw commonalities with MOBIKE, but there are also commonalities with other tunneling systems like tunnel broker and ISATAP. =20 > I saw three good things on the RRG list and this was one of them > (err ... the RRG Recommendation was not:-) Thanks, and I agree with your assessment! Fred fred.l.templin@boeing.com >=20 > Tom Petch >=20 > > Thanks ... Scott >=20 > = From Fred.L.Templin@boeing.com Mon Jun 13 19:23:01 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E231E11E807C for ; Mon, 13 Jun 2011 19:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wu8aMWSIdc6H for ; Mon, 13 Jun 2011 19:23:01 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id 141A411E8075 for ; Mon, 13 Jun 2011 19:23:01 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p5E2MuEj027337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Jun 2011 19:22:57 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p5E15IdS017872; Mon, 13 Jun 2011 18:05:18 -0700 (PDT) Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p5E15Fc3017834 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 13 Jun 2011 18:05:16 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Mon, 13 Jun 2011 19:22:53 -0700 From: "Templin, Fred L" To: Joe Touch , "t.petch" Date: Mon, 13 Jun 2011 19:22:52 -0700 Thread-Topic: [Int-area] IRON issue discussion Thread-Index: AcwhP2oq1Gz5QP04QgSIyWMlO8H87AI+SLDA Message-ID: References: <00c701cc2135$51d998e0$4001a8c0@gateway.2wire.net> <4DE7B521.8050301@isi.edu> In-Reply-To: <4DE7B521.8050301@isi.edu> 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: Internet Area Subject: Re: [Int-area] IRON issue discussion X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 02:23:02 -0000 Hi Joe,=20 > -----Original Message----- > From: int-area-bounces@ietf.org=20 > [mailto:int-area-bounces@ietf.org] On Behalf Of Joe Touch > Sent: Thursday, June 02, 2011 9:07 AM > To: t.petch > Cc: Internet Area > Subject: Re: [Int-area] IRON issue discussion >=20 >=20 >=20 > On 6/2/2011 7:56 AM, t.petch wrote: > > Mangling my metaphors, build a better mouse trap and=20 > nothing happens. >=20 > I'd like to jump in here. >=20 > IRON has some very useful components, many that are well designed and=20 > can help others avoid re-inventing the wheel. That's the=20 > primary utility=20 > to INTAREA, IMO - the whole system seems to compete in the space that=20 > the L3VPN groups are playing (among others), and it's not=20 > clear there's=20 > a single winner in that space (backbone providers will likely=20 > continue=20 > to want VPN and PPVPN solutions). Thanks for setting this background. Yes, there are commonalities with other tunneling systems, but IRON goes further than some of the others to discuss considerations such as mobility, multi-homing, route optimization and others. It considers both the high level architecture of the system as well as the nuts and bolts that hold it together.=20 > The larger challenge, IMO, is that the IETF is a place where=20 > reinventing=20 > the wheel is the norm, if not often the goal ;-( >=20 > A useful way forward might be a short presentation that=20 > highlights the=20 > components of IRON, and where each addresses a key issue important to=20 > INTAREA. The entire system as a whole may be relevant, but the parts=20 > need to be understood and appreciated first, IMO. There are certainly parts that could be discussed in more detail which I think would be helpful in educating both the community and myself regarding Internetworking aspects of an IRON system. For example: - how the clients discover and connect to nearby servers - how clients inform servers of locator addresses changes - when and how to invoke route optimization - can route optimization be used in the presence of VPN tunnels - many others Even though this work came from the RRG, IMHO these tunnel management issues are more INTAREA-related. Are these the kinds of things that might be worth discussing futher? Thanks - Fred fred.l.templin@boeing.com >=20 > Joe > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > = From touch@isi.edu Mon Jun 13 22:19:24 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C22011E824C for ; Mon, 13 Jun 2011 22:19:24 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q40K+-KwJF4B for ; Mon, 13 Jun 2011 22:19:23 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 48CA111E8259 for ; Mon, 13 Jun 2011 22:19:22 -0700 (PDT) Received: from [128.9.176.218] (c2-vpn06.isi.edu [128.9.176.218]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p5E5Il0I004588 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 13 Jun 2011 22:18:48 -0700 (PDT) Message-ID: <4DF6EF37.60409@isi.edu> Date: Mon, 13 Jun 2011 22:18:47 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Templin, Fred L" References: <00c701cc2135$51d998e0$4001a8c0@gateway.2wire.net> <4DE7B521.8050301@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Internet Area Subject: Re: [Int-area] IRON issue discussion X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 05:19:24 -0000 Hi, Fred (et al.), On 6/13/2011 7:22 PM, Templin, Fred L wrote: > Hi Joe, ... >> A useful way forward might be a short presentation that >> highlights the >> components of IRON, and where each addresses a key issue important to >> INTAREA. The entire system as a whole may be relevant, but the parts >> need to be understood and appreciated first, IMO. > > There are certainly parts that could be discussed in > more detail which I think would be helpful in educating > both the community and myself regarding Internetworking > aspects of an IRON system. For example: > > - how the clients discover and connect to nearby servers > - how clients inform servers of locator addresses changes > - when and how to invoke route optimization > - can route optimization be used in the presence of > VPN tunnels > - many others > > Even though this work came from the RRG, IMHO these tunnel > management issues are more INTAREA-related. Are these the > kinds of things that might be worth discussing futher? I think it would be useful to consider some bite-sized pieces of IRON for presentation to the IntArea. The entire architecture is useful independently, but may be too complex to present at an IETF meeting. Joe From scott.brim@gmail.com Tue Jun 14 07:38:25 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA82B11E80B6 for ; Tue, 14 Jun 2011 07:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcPvetX347r1 for ; Tue, 14 Jun 2011 07:38:25 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 264E111E808D for ; Tue, 14 Jun 2011 07:38:25 -0700 (PDT) Received: by iyn15 with SMTP id 15so6454245iyn.31 for ; Tue, 14 Jun 2011 07:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=clYgaXdDRy1SRyy1If4WzClHRC7eOYSO8Pvg+k+mH5I=; b=ag4J13UvQG1P/pW3c3unGDz9alkufnoHKJf115C60zh6d0i55mKhdm8FGkZJE13Q6E xgUUgFzfif7zpAWHpgqNrPYtfi1g/kH86V3Vr5/8pZ+9vzqzUQeW7sN4WeBwdBIyjmls 1DQK3dEibjgraLstHaxipilRWToNoRTFKoY6I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=G7w5hc82i10RJ3EtHguP7vEhztys/HMNx+CDMm8XQKHgphAAYgO0Hy5gw43owHCUtx nlbjvSvfFTn1qwWBMnxoyB4M2ycmGViNc96jXCMBYqLCHfPH9e08yDtknqmREcelmYdl IIubLHcVC0UJ6nC8rGP4A1DIaAA5OjoRjmel0= Received: by 10.43.62.201 with SMTP id xb9mr7413594icb.428.1308062304329; Tue, 14 Jun 2011 07:38:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.12.9 with HTTP; Tue, 14 Jun 2011 07:38:04 -0700 (PDT) From: Scott Brim Date: Tue, 14 Jun 2011 10:38:04 -0400 Message-ID: To: Internet Area Content-Type: text/plain; charset=ISO-8859-1 Subject: [Int-area] Bringing RRG results into IntArea WG X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 14:38:25 -0000 Since the issue of bringing RRG discussion concepts into the working group came up ... Most of the things that were discussed in the RRG, and other things that impinge on the fundamentals of Internet architecture, have natural WG/RG homes already (e.g. VA -> GROW, SCTP -> TSVWG). Others such as ILNP (the one recommended by the RRG chairs) and IRON do not. The Internet Area WG charter says "The Internet Area receives occasional proposals for the development and publication of RFCs that are not in scope of an existing working group and do not justify the formation of a new working group. The INTAREA WG has a secondary role to serve as the forum for developing such work items in the IETF." So it's fine to bring all sorts of ideas into the INTAREA WG for discussion and refinement ... but the goal of doing so should be to move them toward being deployable and interoperable. We're here to do Real Internet Engineering for Real Needs :-). And as always, the goal of discussion should be to figure out which aspects are unclear and need further work. How does that sound? Scott From K.Fleischhauer@telekom.de Tue Jun 14 09:46:01 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F1311E807F for ; Tue, 14 Jun 2011 09:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucxj7Ek+RazW for ; Tue, 14 Jun 2011 09:45:59 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id F135A11E811E for ; Tue, 14 Jun 2011 09:45:58 -0700 (PDT) Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 14 Jun 2011 18:45:47 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.233]) by he110890 ([10.134.92.131]) with mapi; Tue, 14 Jun 2011 18:45:47 +0200 From: To: Date: Tue, 14 Jun 2011 18:45:46 +0200 Thread-Topic: IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? Thread-Index: AcwqsoIK/oLnwxqOSdCrLK8g7sq3+w== Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 16:46:01 -0000 Hi folks, right in time before the next IETF in Quebec, we would like to come up agai= n with our Internet Draft "On demand IPv4 address provisioning in Dual-Stack PPP deployment" in order to gather further feedback from the WG. During our presentation in Prague I got several remarks and questions and from my understanding there has been some interest in the approach we d= escribe in this I-D. Regarding the questions I want to focus on the following two and will try t= o answer them once more: - Use case: In general we see this mechanism applicable for all Dual-Stack PPP network = scenarios allthrough we focussed our presentation for illustrative reasons = on routed gateways that may be provided by the Access Network provider. In principle as more IPv4 addresses can be saved, as more services are IPv6= enabled (especially those which require always-on connectivity (e.g. VoIP, mail, up= date services)) . The PPP protocol has not to be changed in order to achieve the needed funct= ionality - the described behaviour (of independently releasing and refreshing the IPv4 context within a Dual-Stack PPP session) is already inherently covered by the existing PPP spec and also mentioned a= s requirements for CPEs (see RFC 6204 - WLL-3). - Efficiency of the mechanism: In principle we assume (with ongoing IPv6 deployment) that it is possible t= o save after one year of roll-out of the described mechanism about 3%, after two years about 8%, and after three years up to 13% of the provisioned IPv4 addresses. After 8 years 70% of the IPv4 addresses can be "re-cycled" according to our= model calculations. (You will find more details here: "http://www.ix-konferenz.de/getfoldat.php?vid=3D1638&t=3Dapplication/pdf&th= ema=3DEffizienzabsch=E4tzung" (please copy the whole text between the exclamation marks in the address li= ne of you browser).) We plan to come up with a 01 version of the I-D and would that's why like t= o gather more feedback from the WG regarding the possible open issues (e.g.= what has to be described in more detail, ), unanswered questions or any ot= her useful hints how to progress with this work/I-D. And of course we are also interested in your opinion if this work should be= done within the Intarea WG or if other WGs (PPPEXT?) may be more appropria= te. Thanks and kind regards KARSTEN Fleischhauer From Fred.L.Templin@boeing.com Tue Jun 14 10:50:01 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70AB511E812E for ; Tue, 14 Jun 2011 10:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.374 X-Spam-Level: X-Spam-Status: No, score=-6.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Kr0n1-QuEW4 for ; Tue, 14 Jun 2011 10:50:00 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id CAC4C11E8096 for ; Tue, 14 Jun 2011 10:50:00 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p5EHnrMi022045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 14 Jun 2011 12:49:56 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id p5EGVLTB005041 for ; Tue, 14 Jun 2011 09:31:21 -0700 (PDT) Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p5EGVHZA004879 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 14 Jun 2011 09:31:17 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Tue, 14 Jun 2011 10:49:48 -0700 From: "Templin, Fred L" To: Scott Brim , Internet Area Date: Tue, 14 Jun 2011 10:49:48 -0700 Thread-Topic: [Int-area] Bringing RRG results into IntArea WG Thread-Index: AcwqoL8wzFKznCPqRtqGtkytR7Jm/gAGbe5g Message-ID: References: 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: [Int-area] Bringing RRG results into IntArea WG X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 17:50:01 -0000 Hi Scott,=20 > -----Original Message----- > From: int-area-bounces@ietf.org=20 > [mailto:int-area-bounces@ietf.org] On Behalf Of Scott Brim > Sent: Tuesday, June 14, 2011 7:38 AM > To: Internet Area > Subject: [Int-area] Bringing RRG results into IntArea WG >=20 > Since the issue of bringing RRG discussion concepts into the working > group came up ... >=20 > Most of the things that were discussed in the RRG, and other things > that impinge on the fundamentals of Internet architecture, have > natural WG/RG homes already (e.g. VA -> GROW, SCTP -> TSVWG). Others > such as ILNP (the one recommended by the RRG chairs) and IRON do not. >=20 > The Internet Area WG charter says >=20 > "The Internet Area receives occasional proposals for the development > and publication of RFCs that are not in scope of an existing working > group and do not justify the formation of a new working group. The > INTAREA WG has a secondary role to serve as the forum for developing > such work items in the IETF." >=20 > So it's fine to bring all sorts of ideas into the INTAREA WG for > discussion and refinement ... but the goal of doing so should be to > move them toward being deployable and interoperable. We're here to do > Real Internet Engineering for Real Needs :-). And as always, the goal > of discussion should be to figure out which aspects are unclear and > need further work. How does that sound? I agree. In the case of IRON, the high-level architecture is already published, and people seem to understand it. But, specific details such as how the tunneling between clients and servers is done, the way clients communicate address changes to servers, the way redirection is handled, etc. all need to be discussed and refined. I have several documents on these subjects which I think could be considered under the INTAREA's domain of interest. Can we consider the INTAREA WG as a potential venue? Thanks - Fred fred.l.templin@boeing.com =20 >=20 > Scott > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > = From touch@isi.edu Tue Jun 14 18:37:51 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3A511E8076 for ; Tue, 14 Jun 2011 18:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.417 X-Spam-Level: X-Spam-Status: No, score=-104.417 tagged_above=-999 required=5 tests=[AWL=2.182, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-l8-6O9OwlL for ; Tue, 14 Jun 2011 18:37:51 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id E121D9E805A for ; Tue, 14 Jun 2011 18:37:50 -0700 (PDT) Received: from [192.168.121.117] ([221.148.74.90]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p5F1bI8x014122 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 14 Jun 2011 18:37:29 -0700 (PDT) Message-ID: <4DF80CCE.6070005@isi.edu> Date: Tue, 14 Jun 2011 18:37:18 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Warren Kumari References: <34E4F50CAFA10349A41E0756550084FB0660DC20@PRVPEXVS04.corp.twcable.com> <63B6E461-79DD-41F7-B3F0-73AA6E0FDA8C@kumari.net> In-Reply-To: <63B6E461-79DD-41F7-B3F0-73AA6E0FDA8C@kumari.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "Howard, Lee" , "int-area@ietf.org" , "cdl@asgaard.org" Subject: Re: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 01:37:52 -0000 +1 On 6/2/2011 10:17 AM, Warren Kumari wrote: > > On Jun 1, 2011, at 10:47 AM, George, Wesley wrote: > >> After the discussion of this draft in Prague and with the WG chairs and ADs, we have updated it to address a few comments, but primarily to remove the language directing IETF action. This limits the draft to simply requiring IPv6 for IP-capable devices, and should address the concern about whether it interferes with existing WG actions as well as the recommendation that normally IETF action directions are done via BCP rather than standards-track documents. >> >> We would like to ask for formal WG adoption of this draft, as well as reviews to see if it can soon be made ready for WGLC (assuming WG adoption is successful). > > I firmly support adoption of this draft.... > > (I don't necessarily think it is going to change things much, but I believe that it is worth adopting and giving it try...) > > W > > >> http://tools.ietf.org/html/draft-george-ipv6-required-02 >> >> Any discussion about IETF's response to this draft (in terms of how WGs operate, their charters, etc) will be issued in a separate BCP draft. Right now, we want to focus on getting this draft out so that it can provide guidance to IPv6 implementors. >> >> Thanks! >> >> Wes George and co-authors. >> >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Wednesday, June 01, 2011 10:30 AM >> To: George, Wesley >> Cc: Howard, Lee; Donley, Chris (Cable Labs); George, Wesley; cdl@asgaard.org >> Subject: New Version Notification for draft-george-ipv6-required-02.txt >> >> A new version of I-D, draft-george-ipv6-required-02.txt has been successfully submitted by Wesley George and posted to the IETF repository. >> >> Filename: draft-george-ipv6-required >> Revision: 02 >> Title: IPv6 Support Required for all IP-capable nodes >> Creation date: 2011-06-01 >> WG ID: Individual Submission >> Number of pages: 7 >> >> Abstract: >> Given the global lack of available IPv4 space, and limitations in >> IPv4 extension and transition technologies, this document deprecates >> the concept that an IP-capable node MAY support IPv4 _only_, and >> redefines an IP-capable node as one which supports either IPv6 _only_ >> or IPv4/IPv6 dual-stack. This document updates RFC1812, 1122 and >> 4084 to reflect the change in requirements. >> >> >> >> >> The IETF Secretariat >> >> 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. >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area >> > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From tena@huawei.com Tue Jun 14 23:06:39 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2600011E8082 for ; Tue, 14 Jun 2011 23:06:39 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2wYD5AKyCmL for ; Tue, 14 Jun 2011 23:06:38 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by ietfa.amsl.com (Postfix) with ESMTP id 31E6D11E8078 for ; Tue, 14 Jun 2011 23:06:38 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMT00JMVIAZTD@usaga03-in.huawei.com> for int-area@ietf.org; Wed, 15 Jun 2011 01:06:36 -0500 (CDT) Received: from TingZousc1 ([38.109.210.2]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LMT00K8KIAY4D@usaga03-in.huawei.com> for int-area@ietf.org; Wed, 15 Jun 2011 01:06:35 -0500 (CDT) Date: Wed, 15 Jun 2011 00:06:34 -0600 From: Tina Tsou In-reply-to: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com> To: K.Fleischhauer@telekom.de, int-area@ietf.org Message-id: <015001cc2b22$61a864d0$24f92e70$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: AcwqsoIK/oLnwxqOSdCrLK8g7sq3+wAb0URw References: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com> Cc: draft-yang-v6ops-fast6-pppoe@tools.ietf.org, draft-yang-v6ops-fast6-tools-selection@tools.ietf.org Subject: Re: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 06:06:39 -0000 KARSTEN, You may want to see whether the following drafts are relevant. https://datatracker.ietf.org/doc/draft-yang-v6ops-fast6-pppoe/ https://datatracker.ietf.org/doc/draft-yang-v6ops-fast6-tools-selection/ We keep our promises with one another =96 no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On = Behalf Of K.Fleischhauer@telekom.de Sent: Tuesday, June 14, 2011 10:46 AM To: int-area@ietf.org Subject: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? Hi folks, right in time before the next IETF in Quebec, we would like to come up = again with our Internet Draft "On demand IPv4 address provisioning in Dual-Stack PPP deployment" in order to gather further feedback from the WG. During our presentation in Prague I got several remarks and questions and from my understanding there has been some interest in the approach = we describe in this I-D. Regarding the questions I want to focus on the following two and will = try to answer them once more: - Use case: In general we see this mechanism applicable for all Dual-Stack PPP = network scenarios allthrough we focussed our presentation for illustrative = reasons on routed gateways that may be provided by the Access Network provider. In principle as more IPv4 addresses can be saved, as more services are = IPv6 enabled (especially those which require always-on connectivity (e.g. VoIP, mail, update services)) . The PPP protocol has not to be changed in order to achieve the needed functionality - the described behaviour (of independently releasing and refreshing the IPv4 context within a Dual-Stack PPP session) is already inherently covered by the existing PPP spec and also = mentioned as requirements for CPEs (see RFC 6204 - WLL-3). - Efficiency of the mechanism: In principle we assume (with ongoing IPv6 deployment) that it is = possible to save after one year of roll-out of the described mechanism about 3%, after two years about 8%, and after three years up to 13% of the provisioned IPv4 addresses. After 8 years 70% of the IPv4 addresses can be "re-cycled" according to = our model calculations. (You will find more details here: "http://www.ix-konferenz.de/getfoldat.php?vid=3D1638&t=3Dapplication/pdf&= thema=3DE ffizienzabsch=E4tzung" (please copy the whole text between the exclamation marks in the address line of you browser).) We plan to come up with a 01 version of the I-D and would that's why = like to gather more feedback from the WG regarding the possible open issues = (e.g. what has to be described in more detail, ), unanswered questions or any other useful hints how to progress with this work/I-D. And of course we are also interested in your opinion if this work should = be done within the Intarea WG or if other WGs (PPPEXT?) may be more appropriate. Thanks and kind regards KARSTEN Fleischhauer _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area From bob.hinden@gmail.com Wed Jun 15 00:51:33 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8EBE11E8094 for ; Wed, 15 Jun 2011 00:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyHrHHDBNXCH for ; Wed, 15 Jun 2011 00:51:33 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8732311E8074 for ; Wed, 15 Jun 2011 00:51:32 -0700 (PDT) Received: by wwk4 with SMTP id 4so389443wwk.1 for ; Wed, 15 Jun 2011 00:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=C17txslrCmvK6BigkArWwxtZvWYNHf5KcQLy/yQNR+s=; b=iitotGBS8Ih3FJcXrEwXqZIyZmXWzdxGQ1csDovzZkj1dQC+ZngVjHXmBPTwb2w4GV gyN3T9NvhjtKcHtBucC+T8AYPSLguCSl6Fhq7Z3Ukl5q/v0fDow3gXo00cOfEjf/gZY1 CyiVh21ekuB7R/sodehu5yt7aJ6iGFvNtjGoM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=bUN+eLLcllzUhpOXgrthO089pGuQNcpYS199j1cegrkBI3k9afoL7DhxEmq9zQWCFp k8ZO7Qck3HMbBTqDL/2ViBCTRlr+uIpukXf2Tm5tkN1fVOk/hH3l6akF6M8aRjEvQt5q 1EPuRSQ/83Sp9vP1v8MdPYlvh1Sdu+Qwy34as= Received: by 10.216.245.4 with SMTP id n4mr1774465wer.83.1308124291545; Wed, 15 Jun 2011 00:51:31 -0700 (PDT) Received: from [172.24.249.152] (dyn32-131.checkpoint.com [194.29.32.131]) by mx.google.com with ESMTPS id c17sm134395wbh.29.2011.06.15.00.51.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Jun 2011 00:51:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: Date: Wed, 15 Jun 2011 10:51:25 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00c701cc2135$51d998e0$4001a8c0@gateway.2wire.net> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1084) Cc: Internet Area Subject: Re: [Int-area] IRON issue discussion X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 07:51:33 -0000 Fred, This sounds a lot like Mobile IPv6 with the extension that the client = can change home agents if the client get's too far away from where the = the home agent is. I am sure the details are different, but the = functionality sounds similar. Bob On Jun 14, 2011, at 5:12 AM, Templin, Fred L wrote: > Hi Tom, >=20 >> -----Original Message----- >> From: t.petch [mailto:ietfc@btconnect.com]=20 >> Sent: Thursday, June 02, 2011 7:57 AM >> To: Scott Brim >> Cc: Templin, Fred L; Internet Area >> Subject: Re: IRON issue discussion >>=20 >> ----- Original Message ----- >> From: "Scott Brim" >> To: "t.petch" >> Cc: "Templin, Fred L" ; "Internet Area" >> >> Sent: Thursday, June 02, 2011 4:08 PM >>=20 >>> First, I've changed the subject (but kept the threading). >>>=20 >>> Second, on this specific issue -- discussion of IRON topics=20 >> to see if >>> there are any that canNOT be clarified on the mailing list, and thus >>> need agenda time -- Tom, you say >>>=20 >>>> I think that what is wrong with Fred's list is point 1);=20 >> a technical nicety >>>> that slows the reader down from getting to points 2) etc,=20 >> which are >>>> critical:-) >>>=20 >>> If I understand correctly, you understand IRON, but you think others >>> might have trouble understanding it, and you are suggesting some >>> rewrites? No agenda time needed? >>>=20 >>> If there are in fact points you disagree with or believe need >>> clarifying, could you make them explicit? >>=20 >> Mangling my metaphors, build a better mouse trap and nothing happens. >> I believe that this 'mouse trap' deserves a wider hearing=20 >> than it got on >> RRG list and agenda time would give it that. I believe I=20 >> understand it >> but more discussion would probably throw up some misunderstandings >> on my part (I always intended to submit a review on the RRG list = which >> is the way to see if I understand it or not but, with hindsight, >> never gave that work enough priority). >=20 > Thanks for your note. Let me try a more high-level description > of the IRON system and see if it serves to clarify or confuse: >=20 > The IRON system comprises a virtual overlay network set up > by a provider (perhaps an ISP or a hosting service company) > with the objective of providing network address/prefix > services to client customers. The provider's deployment > includes tunnel endpoint servers and relays that connect > the virtual overlay network to the rest of the public > Internet. The clients can be either routers or hosts, and > can be either mobile or fixed. They connect to a nearby > IRON server via a either VPN (when security is needed) or > a plaintext IP-in-IP tunnel. =20 >=20 > In this system, the client gets to use a stable IP address > or prefix even if it moves between different IRON servers, > but the IRON relays only advertise one or a few short IP > prefixes into the global Internet routing system. The > servers and relays engage in a routing protocol instance > (perhaps using iBGP) to track the association of clients > with servers. >=20 > Clients only move to new servers if they travel significant > distances; hence the client-to-server mobility can take > place over very coarse timescales (tens of seconds or > even longer). On the other hand, clients quickly inform > their current server of a change in locator address which > can happen on very short timescales (seconds or less). > Clients can further be redirected to a server that is > closer to the final destination as a form of route > optimization. That function is now covered in more detail > in 'draft-templin-aero'. >=20 > That's about it in terms of the overall architecture. The > part that gets more detailed is how the clients select good > servers and quickly inform them of any locator address > changes due to mobility or multihoming. This is the part > where I saw commonalities with MOBIKE, but there are also > commonalities with other tunneling systems like tunnel > broker and ISATAP. =20 >=20 >> I saw three good things on the RRG list and this was one of them >> (err ... the RRG Recommendation was not:-) >=20 > Thanks, and I agree with your assessment! >=20 > Fred > fred.l.templin@boeing.com >=20 >>=20 >> Tom Petch >>=20 >>> Thanks ... Scott >>=20 >>=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From gregory.cauchie@orange-ftgroup.com Wed Jun 15 06:17:18 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A3E11E8110 for ; Wed, 15 Jun 2011 06:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ii-jTSNRNiF for ; Wed, 15 Jun 2011 06:17:17 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 316C711E80FC for ; Wed, 15 Jun 2011 06:17:17 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A8D17FC400D; Wed, 15 Jun 2011 15:17:11 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 5DB88FC4001; Wed, 15 Jun 2011 15:17:11 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Jun 2011 15:17:11 +0200 Received: from [10.193.118.30] ([10.193.118.30]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Jun 2011 15:17:10 +0200 Message-ID: <4DF8B0D5.7060705@orange-ftgroup.com> Date: Wed, 15 Jun 2011 15:17:09 +0200 From: =?ISO-8859-1?Q?CAUCHIE_Gr=E9gory?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: K.Fleischhauer@telekom.de References: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090604000407050501010003" X-OriginalArrivalTime: 15 Jun 2011 13:17:10.0711 (UTC) FILETIME=[88B0CC70:01CC2B5E] Cc: int-area@ietf.org Subject: Re: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gregory.cauchie@orange-ftgroup.com List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 13:17:18 -0000 This is a cryptographically signed message in MIME format. --------------ms090604000407050501010003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Karsten, IINM, your basic idea is to allocate an IPv4 public address to one=20 customer only when needed/requested for any IPv4 communication. If so, I = find the idea maybe a bit premature (as today one would observe that the = IPv6 address allocation is not needed everytime for many customers...=20 but this is not what we aim to of course) but very interesting if you=20 can come with an architecture that can request/release the IPv4 address=20 allocation quite instantly. After reading draft-fleischhauer-ipv4-addr-saving-00, section 2.1=20 introduces that: Therefore mechanisms are needed in order to provision and release IPv4 addresses for Dual-Stack PPP sessions dynamically No more details are given there and I think this is this/these=20 mechanisms is/are key point for your proposal. The=20 draft-baker-bmwg-testing-eyeball-happiness introduces in a way the=20 problems an eyeball can face in dual stack environment. I am not saying=20 that this draft totally applies here, but nonetheless care must be taken = in your idea to not disrupt nor introduce unwanted delays in setting the = IPv4 communication. Regards, Gregory Le 14/06/2011 18:45, K.Fleischhauer@telekom.de a =E9crit : > Hi folks, > > right in time before the next IETF in Quebec, we would like to come up = again with our Internet Draft > "On demand IPv4 address provisioning in Dual-Stack PPP deployment" > in order to gather further feedback from the WG. > During our presentation in Prague I got several remarks and questions > and from my understanding there has been some interest in the approach = we describe in this I-D. > Regarding the questions I want to focus on the following two and will t= ry to answer them once more: > > - Use case: > In general we see this mechanism applicable for all Dual-Stack PPP netw= ork scenarios allthrough we focussed our presentation for illustrative re= asons on routed gateways that may be provided by the Access Network provi= der. > In principle as more IPv4 addresses can be saved, as more services are = IPv6 enabled > (especially those which require always-on connectivity (e.g. VoIP, mail= , update services)) . > The PPP protocol has not to be changed in order to achieve the needed f= unctionality - > the described behaviour (of independently releasing and > refreshing the IPv4 context within a Dual-Stack PPP session) > is already inherently covered by the existing PPP spec and also mention= ed as requirements for > CPEs (see RFC 6204 - WLL-3). > > - Efficiency of the mechanism: > In principle we assume (with ongoing IPv6 deployment) that it is possib= le to save > after one year of roll-out of the described mechanism about 3%, > after two years about 8%, > and after three years up to 13% of the provisioned IPv4 addresses. > After 8 years 70% of the IPv4 addresses can be "re-cycled" according to= our model calculations. > (You will find more details here: > "http://www.ix-konferenz.de/getfoldat.php?vid=3D1638&t=3Dapplication/pd= f&thema=3DEffizienzabsch=E4tzung" > (please copy the whole text between the exclamation marks in the addres= s line of you browser).) > > > We plan to come up with a 01 version of the I-D and would that's why li= ke to gather more feedback from the WG regarding the possible open issues= (e.g. what has to be described in more detail, ), unanswered questions o= r any other useful hints how to progress with this work/I-D. > And of course we are also interested in your opinion if this work shoul= d be done within the Intarea WG or if other WGs (PPPEXT?) may be more app= ropriate. > > > Thanks and kind regards > > KARSTEN Fleischhauer > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > --------------ms090604000407050501010003 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOHDCC BIgwggNwoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCRlIxFzAVBgNVBAoT DkZyYW5jZSBUZWxlY29tMRMwEQYDVQQLEwpGVFJELUFzcGljMRcwFQYDVQQDEw5GVFJEIEFD IFJhY2luZTAeFw0wMjEwMDMwNzE1MjBaFw0xMjEwMDIwNzE1MjBaMFwxCzAJBgNVBAYTAkZS MRcwFQYDVQQKEw5GcmFuY2UgVGVsZWNvbTETMBEGA1UECxMKRlRSRC1Bc3BpYzEfMB0GA1UE AxMWRlRSRCBBQyBvcGVyYXRpb25uZWxsZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAPKErrcyQf+tgRGBsiBQKGGnvheMF+E74XARkkDrNnL/oA5w6e96Nj5eF7TdoiE7AIQR vOUrJkI9xP74szDUP/CPBPVxxL0855pyoH/qBcgdVCVWBDKGGroc9A5OeXsKCietb1y4+PV5 JeQVw3e41vqJ06Ut81QYPkZ84uJSIiRNoaZG+dBYBOfP8pL3Gj2jnX53eslfdiXjslMk7icb vcvAuBlzHU/LkLNHZV/iEJGGfj3X8kOMF0e3v1OlAX+TXEYlvA46wnffqVMIgiiFbAHPOBMI qOMOVQXx2SdokRcpAsHtb8LcaLrSseDf/bmzvhkufp6qYoUoNC9s4g48J9ECAwEAAaOCAVsw ggFXMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFKeHuNCL9G/jwcDa7Y604KcQKfzY MHwGA1UdIwR1MHOAFLdJ7pNBIn/ZqJeVJz5kZp6uGD8DoVikVjBUMQswCQYDVQQGEwJGUjEX MBUGA1UEChMORnJhbmNlIFRlbGVjb20xEzARBgNVBAsTCkZUUkQtQXNwaWMxFzAVBgNVBAMT DkZUUkQgQUMgUmFjaW5lggEAMA4GA1UdDwEB/wQEAwIBBjCBgAYDVR0fBHkwdzA/oD2gO4Y5 aHR0cDovL2x1Y2lmZXIucmQuZnJhbmNldGVsZWNvbS5mci9yZXZvcXVlcy9jcmxyYWNpbmUu Y3JsMDSgMqAwhi5odHRwOi8vcGtpLWwucmQuZnJhbmNldGVsZWNvbS5mci9jcmxyYWNpbmUu Y3JsMBEGCWCGSAGG+EIBAQQEAwIABzANBgkqhkiG9w0BAQUFAAOCAQEAto0WYTNPzNN/XrdT 255IwPKbYLZD/YRfQwwcbB4Ff6F9Km+J69KLpZZZx0Z/8rTsjVFc3A2QHTMy4OB2vJ1qPMUO +JlahqhHbun4GHxM0xl9qzGAaveo5xvIMqHYUnnRZ6s8LadQVbkcHxgw4oPkwRGbKoGyT6WE dFhWmn4BOBuwURN/JL4LynTkwHEklDbheEyAVTOrJIbZ88rWAKOoSzDhD+Wu/ZVvbcYuYNev qafJceD1g6rQhaz7O4HnGdmiau3/ayV7ZNDqxnm0Sfli4r4ltTi6GkxmEoT7X1JdKuH0na0Z dYRoqxRopM8uLsFMOHc46GT7HwsNcqXctRpORDCCBKIwggOKoAMCAQICAwCKZTANBgkqhkiG 9w0BAQUFADBcMQswCQYDVQQGEwJGUjEXMBUGA1UEChMORnJhbmNlIFRlbGVjb20xEzARBgNV BAsTCkZUUkQtQXNwaWMxHzAdBgNVBAMTFkZUUkQgQUMgb3BlcmF0aW9ubmVsbGUwHhcNMTAw NzEyMTAzOTI0WhcNMTMwNzExMTAzOTI0WjCBojELMAkGA1UEBhMCRlIxFzAVBgNVBAoTDkZy YW5jZSBUZWxlY29tMRMwEQYDVQQLEwpGVFJELUFTUElDMRgwFgYDVQQDEw9HcmVnb3J5IENB VUNISUUxGDAWBgoJkiaJk/IsZAEBEwhHT0lDNzMwMDExMC8GCSqGSIb3DQEJARYiZ3JlZ29y eS5jYXVjaGllQG9yYW5nZS1mdGdyb3VwLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAt5FjyQyPyGn4d2i7iP9R6e3V+XWkmLUir7VkVtsyG+/2W/tas6gILdx6NKv30sfWQ3+g huBF+Pkhxh9qBy3vjLtKysYX1OYlEi3YRfus6MGAWu1+1updfKwQLZpZD5ctp8CYOXGS9F+S GW3Gf8EB1z+RB6LX2vxNBiN2XUXLz8UCAwEAAaOCAagwggGkMA8GA1UdDwEB/wQFAwMHMAAw EwYDVR0lBAwwCgYIKwYBBQUHAwQwHQYDVR0OBBYEFBAt5fHNt/+8hqAE+aZD4e4TEHOWMGMG A1UdIwRcMFqAFKeHuNCL9G/jwcDa7Y604KcQKfzYoT+BPUM9RlIsTz1GcmFuY2UgVGVsZWNv bSxPVT1GVFJELUFzcGljLENOPUZUUkQgQUMgb3BlcmF0aW9ubmVsbGWCAQEwgZIGA1UdHwSB ijCBhzBHoEWgQ4ZBaHR0cDovL2x1Y2lmZXIucmQuZnJhbmNldGVsZWNvbS5mci9yZXZvcXVl cy9jcmxvcGVyYXRpb25uZWxsZS5jcmwwPKA6oDiGNmh0dHA6Ly9wa2ktbC5yZC5mcmFuY2V0 ZWxlY29tLmZyL2NybG9wZXJhdGlvbm5lbGxlLmNybDARBglghkgBhvhCAQEEBAMCBSAwUAYD VR0RBEkwR4EiZ3JlZ29yeS5jYXVjaGllQG9yYW5nZS1mdGdyb3VwLmNvbYEhZ3JlZ29yeS5j YXVjaGllQGZyYW5jZXRlbGVjb20uY29tMA0GCSqGSIb3DQEBBQUAA4IBAQDEYI80Q1FsKFpy 0P7ugRdyAyrkpi38t0rcktZvM9mL3LL4GYSEn7QeZZdVz/iYiA+eCtQkQQL9HZTV2U+5ehn/ Lhb9AnUfdj9LeF4HuEjsulPiTJdtIJPAyskNPi+Q7RC5prJadXJ48LIQa9OXZF8R9oHs70/P Q/+r6GuAAS3+Ywzx8mS1HKHsMKW/WwrSUnh257UXLF++yfz5g0bjaJrEqDXXVxFBKwP76lYk FS2nDWLNceqtFlt4UlQ2rP112C+gW+qmmidKYZYdxj5KOtV1MB6h0euQrrpfI8Eiiaxlkrtd qyUckSCFke9tgd99FVZcvoPrvCf2SolNot1Dk4ExMIIE5jCCA86gAwIBAgIDAIpkMA0GCSqG SIb3DQEBBQUAMFwxCzAJBgNVBAYTAkZSMRcwFQYDVQQKEw5GcmFuY2UgVGVsZWNvbTETMBEG A1UECxMKRlRSRC1Bc3BpYzEfMB0GA1UEAxMWRlRSRCBBQyBvcGVyYXRpb25uZWxsZTAeFw0x MDA3MTIxMDM5MjRaFw0xMzA3MTExMDM5MjRaMIGiMQswCQYDVQQGEwJGUjEXMBUGA1UEChMO RnJhbmNlIFRlbGVjb20xEzARBgNVBAsTCkZUUkQtQVNQSUMxGDAWBgNVBAMTD0dyZWdvcnkg Q0FVQ0hJRTEYMBYGCgmSJomT8ixkAQETCEdPSUM3MzAwMTEwLwYJKoZIhvcNAQkBFiJncmVn b3J5LmNhdWNoaWVAb3JhbmdlLWZ0Z3JvdXAuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDWbC6qSGTDAlz7mVMPpr6JRIu058v6o2jnKOmqSNoMxMikiqRbXGNXZpaK5muLSWSe nn+teWuIfm4alQNgvSATFF0uvmxqSysTpdAGVsjiHJLzXmrQXK5y6BCSyyT3iixopWPMvUK1 JqhMdGkBvfUtlRdzlSXSsSoVfLUFR2tvcwIDAQABo4IB7DCCAegwDwYDVR0PAQH/BAUDAwfA ADApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcUAgIwHQYDVR0OBBYE FLurIHxEuJvLQPzIXhWcUyrFt+jUMGMGA1UdIwRcMFqAFKeHuNCL9G/jwcDa7Y604KcQKfzY oT+BPUM9RlIsTz1GcmFuY2UgVGVsZWNvbSxPVT1GVFJELUFzcGljLENOPUZUUkQgQUMgb3Bl cmF0aW9ubmVsbGWCAQEwgZIGA1UdHwSBijCBhzBHoEWgQ4ZBaHR0cDovL2x1Y2lmZXIucmQu ZnJhbmNldGVsZWNvbS5mci9yZXZvcXVlcy9jcmxvcGVyYXRpb25uZWxsZS5jcmwwPKA6oDiG Nmh0dHA6Ly9wa2ktbC5yZC5mcmFuY2V0ZWxlY29tLmZyL2NybG9wZXJhdGlvbm5lbGxlLmNy bDARBglghkgBhvhCAQEEBAMCBaAwfgYDVR0RBHcwdaAsBgorBgEEAYI3FAIDoB4MHGdvaWM3 MzAwQHJkLmZyYW5jZXRlbGVjb20uZnKBImdyZWdvcnkuY2F1Y2hpZUBvcmFuZ2UtZnRncm91 cC5jb22BIWdyZWdvcnkuY2F1Y2hpZUBmcmFuY2V0ZWxlY29tLmNvbTANBgkqhkiG9w0BAQUF AAOCAQEAMjStlnSNuwD+8rrhh2x/MUitjMWsaZlkIw1K2TDhxlS8JVF+aY/Cls0fbdcQsw/J zrSFlzHC5cBqHyXvlTtj5cCva0/zlDTBhr+eDuyibyHxBYFvKVM37esX0d1ogl6Iwt1Lh3Yx houNe+5Krpd9NdSUMwX1oO+9VCO8I9cscCHGwTT5Yst8/RFdphZZo2JVVxdLBw6Wn9dNQUf7 Vpx8P1Dt5TRwkU+ByvIOCIGxbBvn8vGng0melSrRrccAKmFI1T5J122ewdaifQRDyd5N6T0a k0el5dKIs1Arxh+UpOpLFIv39VJqwoQ1t2XL7fduu7HBEnEwfoQt+PJnyfDcLTGCArUwggKx AgEBMGMwXDELMAkGA1UEBhMCRlIxFzAVBgNVBAoTDkZyYW5jZSBUZWxlY29tMRMwEQYDVQQL EwpGVFJELUFzcGljMR8wHQYDVQQDExZGVFJEIEFDIG9wZXJhdGlvbm5lbGxlAgMAimQwCQYF Kw4DAhoFAKCCAagwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTEwNjE1MTMxNzA5WjAjBgkqhkiG9w0BCQQxFgQUfhLCZUPkVyCVJ9MSuy0ztz4anjUwXwYJ KoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMHIGCSsGAQQBgjcQBDFl MGMwXDELMAkGA1UEBhMCRlIxFzAVBgNVBAoTDkZyYW5jZSBUZWxlY29tMRMwEQYDVQQLEwpG VFJELUFzcGljMR8wHQYDVQQDExZGVFJEIEFDIG9wZXJhdGlvbm5lbGxlAgMAimUwdAYLKoZI hvcNAQkQAgsxZaBjMFwxCzAJBgNVBAYTAkZSMRcwFQYDVQQKEw5GcmFuY2UgVGVsZWNvbTET MBEGA1UECxMKRlRSRC1Bc3BpYzEfMB0GA1UEAxMWRlRSRCBBQyBvcGVyYXRpb25uZWxsZQID AIplMA0GCSqGSIb3DQEBAQUABIGAMgDGFDbcwnkdH2gwGxXefVIbugNrRCn5ljoSKIFsoHew +HskIERqcyHvBfXuqHydmntJ/1uaCNW8jFGnqn0L/fuJCcPABRjvHx/ubB6wtIRy6LvVBpaR oLNj8geeUbCBbauHDYCS1kZLm+TBOEDpDpftZhqCAPCsCEebKs9lw7sAAAAAAAA= --------------ms090604000407050501010003-- From Fred.L.Templin@boeing.com Wed Jun 15 08:19:00 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E9821F844E for ; Wed, 15 Jun 2011 08:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.119 X-Spam-Level: X-Spam-Status: No, score=-6.119 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7xfFXOGpMIj for ; Wed, 15 Jun 2011 08:18:57 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id 144F821F8451 for ; Wed, 15 Jun 2011 08:18:57 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p5FFIofs008077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Jun 2011 08:18:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id p5FDx20Z006049; Wed, 15 Jun 2011 06:59:03 -0700 (PDT) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p5FDwtDO005841 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 15 Jun 2011 06:58:55 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Wed, 15 Jun 2011 08:18:41 -0700 From: "Templin, Fred L" To: Bob Hinden Date: Wed, 15 Jun 2011 08:18:40 -0700 Thread-Topic: [Int-area] IRON issue discussion Thread-Index: AcwrMQyQ++r1dHKWRY+Ihw/mUoP+bAAPPd8g Message-ID: References: <00c701cc2135$51d998e0$4001a8c0@gateway.2wire.net> 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: Internet Area Subject: Re: [Int-area] IRON issue discussion X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 15:19:01 -0000 Hi Bob,=20 > -----Original Message----- > From: Bob Hinden [mailto:bob.hinden@gmail.com]=20 > Sent: Wednesday, June 15, 2011 12:51 AM > To: Templin, Fred L > Cc: Bob Hinden; t.petch; Scott Brim; Internet Area > Subject: Re: [Int-area] IRON issue discussion >=20 > Fred, >=20 > This sounds a lot like Mobile IPv6 with the extension that=20 > the client can change home agents if the client get's too far=20 > away from where the the home agent is. I am sure the details=20 > are different, but the functionality sounds similar. Yes, the IRON server does act as a mobility anchor point for the client. In some sense, IRON takes the viewpoint that the client is always away from home and needs to be reached via its current server in order to receive inbound traffic. For outbound traffic, however, the client can be redirected to the server of the final destination (assuming the final destination also uses IRON). The client can then move to a new server over a coarse- grained timescale and only if it moves a significant distance away from its current server. On the other hand, the client should quickly inform its current server of any changes in link-layer connectivity within a fine-grained timescale. To sum up, IRON includes a self-contained mobility management system that handles mobile hosts and/or networks without the need for adjunct mechanisms. Thanks - Fred fred.l.templin@boeing.com > Bob >=20 >=20 > On Jun 14, 2011, at 5:12 AM, Templin, Fred L wrote: >=20 > > Hi Tom, > >=20 > >> -----Original Message----- > >> From: t.petch [mailto:ietfc@btconnect.com]=20 > >> Sent: Thursday, June 02, 2011 7:57 AM > >> To: Scott Brim > >> Cc: Templin, Fred L; Internet Area > >> Subject: Re: IRON issue discussion > >>=20 > >> ----- Original Message ----- > >> From: "Scott Brim" > >> To: "t.petch" > >> Cc: "Templin, Fred L" ; "Internet Area" > >> > >> Sent: Thursday, June 02, 2011 4:08 PM > >>=20 > >>> First, I've changed the subject (but kept the threading). > >>>=20 > >>> Second, on this specific issue -- discussion of IRON topics=20 > >> to see if > >>> there are any that canNOT be clarified on the mailing=20 > list, and thus > >>> need agenda time -- Tom, you say > >>>=20 > >>>> I think that what is wrong with Fred's list is point 1);=20 > >> a technical nicety > >>>> that slows the reader down from getting to points 2) etc,=20 > >> which are > >>>> critical:-) > >>>=20 > >>> If I understand correctly, you understand IRON, but you=20 > think others > >>> might have trouble understanding it, and you are suggesting some > >>> rewrites? No agenda time needed? > >>>=20 > >>> If there are in fact points you disagree with or believe need > >>> clarifying, could you make them explicit? > >>=20 > >> Mangling my metaphors, build a better mouse trap and=20 > nothing happens. > >> I believe that this 'mouse trap' deserves a wider hearing=20 > >> than it got on > >> RRG list and agenda time would give it that. I believe I=20 > >> understand it > >> but more discussion would probably throw up some misunderstandings > >> on my part (I always intended to submit a review on the=20 > RRG list which > >> is the way to see if I understand it or not but, with hindsight, > >> never gave that work enough priority). > >=20 > > Thanks for your note. Let me try a more high-level description > > of the IRON system and see if it serves to clarify or confuse: > >=20 > > The IRON system comprises a virtual overlay network set up > > by a provider (perhaps an ISP or a hosting service company) > > with the objective of providing network address/prefix > > services to client customers. The provider's deployment > > includes tunnel endpoint servers and relays that connect > > the virtual overlay network to the rest of the public > > Internet. The clients can be either routers or hosts, and > > can be either mobile or fixed. They connect to a nearby > > IRON server via a either VPN (when security is needed) or > > a plaintext IP-in-IP tunnel. =20 > >=20 > > In this system, the client gets to use a stable IP address > > or prefix even if it moves between different IRON servers, > > but the IRON relays only advertise one or a few short IP > > prefixes into the global Internet routing system. The > > servers and relays engage in a routing protocol instance > > (perhaps using iBGP) to track the association of clients > > with servers. > >=20 > > Clients only move to new servers if they travel significant > > distances; hence the client-to-server mobility can take > > place over very coarse timescales (tens of seconds or > > even longer). On the other hand, clients quickly inform > > their current server of a change in locator address which > > can happen on very short timescales (seconds or less). > > Clients can further be redirected to a server that is > > closer to the final destination as a form of route > > optimization. That function is now covered in more detail > > in 'draft-templin-aero'. > >=20 > > That's about it in terms of the overall architecture. The > > part that gets more detailed is how the clients select good > > servers and quickly inform them of any locator address > > changes due to mobility or multihoming. This is the part > > where I saw commonalities with MOBIKE, but there are also > > commonalities with other tunneling systems like tunnel > > broker and ISATAP. =20 > >=20 > >> I saw three good things on the RRG list and this was one of them > >> (err ... the RRG Recommendation was not:-) > >=20 > > Thanks, and I agree with your assessment! > >=20 > > Fred > > fred.l.templin@boeing.com > >=20 > >>=20 > >> Tom Petch > >>=20 > >>> Thanks ... Scott > >>=20 > >>=20 > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area >=20 > = From julien.ietf@gmail.com Wed Jun 15 09:31:41 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC32A11E811F for ; Wed, 15 Jun 2011 09:31:41 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpdKlXLy6GqO for ; Wed, 15 Jun 2011 09:31:40 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 89E2811E808D for ; Wed, 15 Jun 2011 09:31:40 -0700 (PDT) Received: by bwz13 with SMTP id 13so732632bwz.31 for ; Wed, 15 Jun 2011 09:31:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6Ka0fNpn5yQhJNT5gul8kCZYD0TPmcHfpvL06Ii7K/o=; b=RfFHWSQOI3J/6GpU8pbg5Z+GKu/o/yroraNBH1iWOTuVISSXOKN3tS/jAe30Qf1dTs EIrLbEm7AmKqDLddgUdt7FipiL2RhciqxG1+Q5h3cW2rejoxDvsQZBunN6ZA6WB6USfz WVRHVnJBMhkiMmG53RjumVAean1CqjN3lUCxk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XG4k4+gTdKgDTfZNN4I3Ty76fGra6PbKDyWtZ+/3EMllp6a5TIEwKwFw0lPmssBWHX Q+fX0myHYCC54b8t97s2VOuFVkQ9YwiCGKEPEiaVUmm72uzxKCME0WefvIupQxxUq8Aa 9SQXyXHxnM3nmbkw6gKWr79DljUeI7uw4FoYo= MIME-Version: 1.0 Received: by 10.204.40.199 with SMTP id l7mr730402bke.103.1308155498855; Wed, 15 Jun 2011 09:31:38 -0700 (PDT) Received: by 10.204.123.194 with HTTP; Wed, 15 Jun 2011 09:31:38 -0700 (PDT) In-Reply-To: References: <34E4F50CAFA10349A41E0756550084FB0660DC20@PRVPEXVS04.corp.twcable.com> Date: Wed, 15 Jun 2011 09:31:38 -0700 Message-ID: From: Julien Laganier To: "George, Wesley" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Howard, Lee" , "int-area@ietf.org" , "cdl@asgaard.org" Subject: Re: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 16:31:41 -0000 Folks, At this point the chairs believe that there is rough consensus in the intarea WG to adopt this draft as a WG draft. Authors: Please resubmit the draft as draft-intarea-ipv6-required-00. --julien & scott On Wed, Jun 1, 2011 at 1:48 PM, Julien Laganier wro= te: > Folks, > > At this point we' d like to ask WG participants whether or not there > is interest in adopting this document as intarea WG draft. Please > express your opinions on the mailing list. > > --julien & scott > > On Wed, Jun 1, 2011 at 7:47 AM, George, Wesley > wrote: >> After the discussion of this draft in Prague and with the WG chairs and = ADs, we have updated it to address a few comments, but primarily to remove = the language directing IETF action. This limits the draft to simply requiri= ng IPv6 for IP-capable devices, and should address the concern about whethe= r it interferes with existing WG actions as well as the recommendation that= normally IETF action directions are done via BCP rather than standards-tra= ck documents. >> >> We would like to ask for formal WG adoption of this draft, as well as re= views to see if it can soon be made ready for WGLC (assuming WG adoption is= successful). >> http://tools.ietf.org/html/draft-george-ipv6-required-02 >> >> Any discussion about IETF's response to this draft (in terms of how WGs = operate, their charters, etc) will be issued in a separate BCP draft. Right= now, we want to focus on getting this draft out so that it can provide gui= dance to IPv6 implementors. >> >> Thanks! >> >> Wes George and co-authors. >> >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Wednesday, June 01, 2011 10:30 AM >> To: George, Wesley >> Cc: Howard, Lee; Donley, Chris (Cable Labs); George, Wesley; cdl@asgaard= .org >> Subject: New Version Notification for draft-george-ipv6-required-02.txt >> >> A new version of I-D, draft-george-ipv6-required-02.txt has been success= fully submitted by Wesley George and posted to the IETF repository. >> >> Filename: =A0 =A0 =A0 =A0draft-george-ipv6-required >> Revision: =A0 =A0 =A0 =A002 >> Title: =A0 =A0 =A0 =A0 =A0 IPv6 Support Required for all IP-capable node= s >> Creation date: =A0 2011-06-01 >> WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission >> Number of pages: 7 >> >> Abstract: >> =A0 Given the global lack of available IPv4 space, and limitations in >> =A0 IPv4 extension and transition technologies, this document deprecates >> =A0 the concept that an IP-capable node MAY support IPv4 _only_, and >> =A0 redefines an IP-capable node as one which supports either IPv6 _only= _ >> =A0 or IPv4/IPv6 dual-stack. =A0This document updates RFC1812, 1122 and >> =A0 4084 to reflect the change in requirements. >> >> >> >> >> The IETF Secretariat >> >> This E-mail and any of its attachments may contain Time Warner Cable pro= prietary information, which is privileged, confidential, or subject to copy= right belonging to Time Warner Cable. This E-mail is intended solely for th= e 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 dis= semination, distribution, copying, or action taken in relation to the conte= nts of and attachments to this E-mail is strictly prohibited and may be unl= awful. 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. >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area >> > From dthaler@microsoft.com Wed Jun 15 13:21:35 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9997921F8567 for ; Wed, 15 Jun 2011 13:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.544 X-Spam-Level: X-Spam-Status: No, score=-110.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHidhSxh1ewV for ; Wed, 15 Jun 2011 13:21:34 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 4C82C21F8566 for ; Wed, 15 Jun 2011 13:21:34 -0700 (PDT) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 15 Jun 2011 13:21:28 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.1.289.8; Wed, 15 Jun 2011 13:21:19 -0700 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.165]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0289.008; Wed, 15 Jun 2011 13:21:19 -0700 From: Dave Thaler To: "gregory.cauchie@orange-ftgroup.com" , "K.Fleischhauer@telekom.de" Thread-Topic: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? Thread-Index: AcwqsoIK/oLnwxqOSdCrLK8g7sq3+wA5rICAAAAf0EA= Date: Wed, 15 Jun 2011 20:21:18 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B107CED@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com> <4DF8B0D5.7060705@orange-ftgroup.com> In-Reply-To: <4DF8B0D5.7060705@orange-ftgroup.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "int-area@ietf.org" Subject: Re: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 20:21:35 -0000 Also related is DSTM http://tools.ietf.org/html/draft-bound-dstm-exp-04 -Dave -----Original Message----- From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On Behal= f Of CAUCHIE Gr=E9gory Sent: Wednesday, June 15, 2011 6:17 AM To: K.Fleischhauer@telekom.de Cc: int-area@ietf.org Subject: Re: [Int-area] IETF80 questions regarding "On demand IPv4 address = provisioning in Dual-Stack PPP deployment" - Topic for WG? Hi Karsten, IINM, your basic idea is to allocate an IPv4 public address to one customer= only when needed/requested for any IPv4 communication. If so, I find the i= dea maybe a bit premature (as today one would observe that the IPv6 address allocation is not needed everytime for many customers...=20 but this is not what we aim to of course) but very interesting if you can c= ome with an architecture that can request/release the IPv4 address allocati= on quite instantly. After reading draft-fleischhauer-ipv4-addr-saving-00, section 2.1 introduce= s that: Therefore mechanisms are needed in order to provision and release IPv4 addresses for Dual-Stack PPP sessions dynamically No more details are given there and I think this is this/these mechanisms i= s/are key point for your proposal. The draft-baker-bmwg-testing-eyeball-hap= piness introduces in a way the problems an eyeball can face in dual stack e= nvironment. I am not saying that this draft totally applies here, but nonet= heless care must be taken in your idea to not disrupt nor introduce unwante= d delays in setting the IPv4 communication. Regards, Gregory Le 14/06/2011 18:45, K.Fleischhauer@telekom.de a =E9crit : > Hi folks, > > right in time before the next IETF in Quebec, we would like to come up=20 > again with our Internet Draft "On demand IPv4 address provisioning in Dua= l-Stack PPP deployment" > in order to gather further feedback from the WG. > During our presentation in Prague I got several remarks and questions=20 > and from my understanding there has been some interest in the approach we= describe in this I-D. > Regarding the questions I want to focus on the following two and will try= to answer them once more: > > - Use case: > In general we see this mechanism applicable for all Dual-Stack PPP networ= k scenarios allthrough we focussed our presentation for illustrative reason= s on routed gateways that may be provided by the Access Network provider. > In principle as more IPv4 addresses can be saved, as more services are=20 > IPv6 enabled (especially those which require always-on connectivity (e.g.= VoIP, mail, update services)) . > The PPP protocol has not to be changed in order to achieve the needed=20 > functionality - the described behaviour (of independently releasing=20 > and refreshing the IPv4 context within a Dual-Stack PPP session) is=20 > already inherently covered by the existing PPP spec and also mentioned=20 > as requirements for CPEs (see RFC 6204 - WLL-3). > > - Efficiency of the mechanism: > In principle we assume (with ongoing IPv6 deployment) that it is=20 > possible to save after one year of roll-out of the described mechanism=20 > about 3%, after two years about 8%, and after three years up to 13% of=20 > the provisioned IPv4 addresses. > After 8 years 70% of the IPv4 addresses can be "re-cycled" according to o= ur model calculations. > (You will find more details here: > "http://www.ix-konferenz.de/getfoldat.php?vid=3D1638&t=3Dapplication/pdf&= thema=3DEffizienzabsch=E4tzung" > (please copy the whole text between the exclamation marks in the=20 > address line of you browser).) > > > We plan to come up with a 01 version of the I-D and would that's why like= to gather more feedback from the WG regarding the possible open issues (e.= g. what has to be described in more detail, ), unanswered questions or any = other useful hints how to progress with this work/I-D. > And of course we are also interested in your opinion if this work should = be done within the Intarea WG or if other WGs (PPPEXT?) may be more appropr= iate. > > > Thanks and kind regards > > KARSTEN Fleischhauer > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > From K.Fleischhauer@telekom.de Wed Jun 15 15:06:57 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52E221F851A for ; Wed, 15 Jun 2011 15:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVQLm6Xfa-SB for ; Wed, 15 Jun 2011 15:06:57 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 8382D21F8519 for ; Wed, 15 Jun 2011 15:06:56 -0700 (PDT) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 16 Jun 2011 00:06:51 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.233]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 16 Jun 2011 00:06:51 +0200 From: To: , Date: Thu, 16 Jun 2011 00:06:50 +0200 Thread-Topic: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? Thread-Index: AcwrXrscrYar3en2R/yTWFUN4sJLTQAOCDiA Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADCD2242@HE111648.emea1.cds.t-internal.com> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com> <4DF8B0D5.7060705@orange-ftgroup.com> In-Reply-To: <4DF8B0D5.7060705@orange-ftgroup.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 22:06:58 -0000 Dear Gregory, Thank you very much for your feedback. See my comments below. Best KARSTEN > Hi Karsten, > > IINM, your basic idea is to allocate an IPv4 public address to one > customer only when needed/requested for any IPv4 > communication. You are right. > If so, I find the idea maybe a bit premature (as today one would > observe that the IPv6 address allocation is not needed everytime for many= customers... > but this is not what we aim to of course) but very interesting if you > can come with an architecture that can request/release the > IPv4 address allocation quite instantly. Maybe IPv4 on-demand seems today for somebody a little bit ambitious, but this provides and triggers also an IPv4 exit what we really need beside the IPv4 address efficiency too. > > After reading draft-fleischhauer-ipv4-addr-saving-00, section 2.1 > introduces that: > > Therefore mechanisms are needed in order to provision and > release IPv4 addresses for Dual-Stack PPP sessions dynamically > > No more details are given there and I think this is this/these > mechanisms is/are key point for your proposal. Within the slides of the Prague meeting (http://www.ietf.org/proceedings/80/slides/intarea-3.ppt) we introduced already some basic message flow for supporting this scenario. This will be also part of the version 01 of the ID. > The draft-baker-bmwg-testing-eyeball-happiness introduces in a way the > problems an eyeball can face in dual stack environment. I am > not saying that this draft totally applies here, but nonetheless care > must be taken in your idea to not disrupt nor introduce unwanted delays i= n > setting the IPv4 communication. We expect that once IPv6 is introduced on the network layer a lot of major applications will also be IPv6 enabled. At least we have such a strategy to do this with our services. I think the major content provider will also do this. A typical scenario in the future would be that the customer is always conne= cted with IPv6 and can use here always-on services as voice etc. The IPv4 connectivity parameter can be requested and used on demand. A lot of not always-on connected customers do this already today. Here a complete setup of the whole PPP session is needed, whereas in our scenario just the NCP/IPCP has to be established. So we see here not an increasing of delays etc. In any case this delay would just valid for the first upstream IPv4 packet in a "Dual-Stack cycle". In comparison to other IPv4 address saving approaches where each IPv4 packet need additional tunnelling and/or processing in a CGN this shou= ld be acceptable. Beside my personal doubts regarding the need to implement Happy Eyeballs in a Dual-Stack scenario I see here no major collisions of both scenarios. > > Regards, > > Gregory > > > Le 14/06/2011 18:45, K.Fleischhauer@telekom.de a =E9crit : > > Hi folks, > > > > right in time before the next IETF in Quebec, we would like > to come up again with our Internet Draft > > "On demand IPv4 address provisioning in Dual-Stack PPP deployment" > > in order to gather further feedback from the WG. > > During our presentation in Prague I got several remarks and > questions > > and from my understanding there has been some interest in > the approach we describe in this I-D. > > Regarding the questions I want to focus on the following > two and will try to answer them once more: > > > > - Use case: > > In general we see this mechanism applicable for all > Dual-Stack PPP network scenarios allthrough we focussed our > presentation for illustrative reasons on routed gateways that > may be provided by the Access Network provider. > > In principle as more IPv4 addresses can be saved, as more > services are IPv6 enabled > > (especially those which require always-on connectivity > (e.g. VoIP, mail, update services)) . > > The PPP protocol has not to be changed in order to achieve > the needed functionality - > > the described behaviour (of independently releasing and > > refreshing the IPv4 context within a Dual-Stack PPP session) > > is already inherently covered by the existing PPP spec and > also mentioned as requirements for > > CPEs (see RFC 6204 - WLL-3). > > > > - Efficiency of the mechanism: > > In principle we assume (with ongoing IPv6 deployment) that > it is possible to save > > after one year of roll-out of the described mechanism about 3%, > > after two years about 8%, > > and after three years up to 13% of the provisioned IPv4 addresses. > > After 8 years 70% of the IPv4 addresses can be "re-cycled" > according to our model calculations. > > (You will find more details here: > > > "http://www.ix-konferenz.de/getfoldat.php?vid=3D1638&t=3Dapplicati on/pdf&thema=3DEffizienzabsch=E4tzung" > > (please copy the whole text between the exclamation marks > in the address line of you browser).) > > > > > > We plan to come up with a 01 version of the I-D and would > that's why like to gather more feedback from the WG regarding > the possible open issues (e.g. what has to be described in > more detail, ), unanswered questions or any other useful > hints how to progress with this work/I-D. > > And of course we are also interested in your opinion if > this work should be done within the Intarea WG or if other > WGs (PPPEXT?) may be more appropriate. > > > > > > Thanks and kind regards > > > > KARSTEN Fleischhauer > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > > > > > From gregory.cauchie@orange-ftgroup.com Thu Jun 16 02:16:02 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E7D11E81DF for ; Thu, 16 Jun 2011 02:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3+srbPbncgB for ; Thu, 16 Jun 2011 02:16:01 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 21C7711E81E9 for ; Thu, 16 Jun 2011 02:16:01 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DA4028D0002; Thu, 16 Jun 2011 11:16:42 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id CDC278C0005; Thu, 16 Jun 2011 11:16:42 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Jun 2011 11:15:59 +0200 Received: from [10.193.118.30] ([10.193.118.30]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Jun 2011 11:15:58 +0200 Message-ID: <4DF9C9CE.3010608@orange-ftgroup.com> Date: Thu, 16 Jun 2011 11:15:58 +0200 From: =?ISO-8859-1?Q?CAUCHIE_Gr=E9gory?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: K.Fleischhauer@telekom.de References: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com> <4DF8B0D5.7060705@orange-ftgroup.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADCD2242@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADCD2242@HE111648.emea1.cds.t-internal.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070803010304030605080608" X-OriginalArrivalTime: 16 Jun 2011 09:15:58.0987 (UTC) FILETIME=[0148B5B0:01CC2C06] Cc: int-area@ietf.org Subject: Re: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gregory.cauchie@orange-ftgroup.com List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 09:16:02 -0000 This is a cryptographically signed message in MIME format. --------------ms070803010304030605080608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Karsten, thanks for your answers. I unfortunately did not attend the last intarea = meeting, so your explanations below helped me understand a little bit=20 better the slides. I must say that my intention was not at all to say that I see collisions = or even that I don't see any application of this as I also work for an=20 ISP. On the contrary, my intention was to point that this is a good idea = and one of the requirements I would see is to have an IPv4 address=20 request/release process with IPCP that is not introducing delay in the=20 IPv4 communication. If this is already the case (not saying it is not),=20 then I would suggest to document it as I think it would be of great=20 value for your draft and related discussions. Best regards, Greg Le 16/06/2011 00:06, K.Fleischhauer@telekom.de a =E9crit : > Dear Gregory, > > Thank you very much for your feedback. > > See my comments below. > > Best > > KARSTEN > >> Hi Karsten, >> >> IINM, your basic idea is to allocate an IPv4 public address to one >> customer only when needed/requested for any IPv4 >> communication. > You are right. > >> If so, I find the idea maybe a bit premature (as today one would >> observe that the IPv6 address allocation is not needed everytime for m= any customers... >> but this is not what we aim to of course) but very interesting if you >> can come with an architecture that can request/release the >> IPv4 address allocation quite instantly. > Maybe IPv4 on-demand seems today for somebody a little bit ambitious, > but this provides and triggers also an IPv4 exit > what we really need beside the IPv4 address efficiency too. > >> After reading draft-fleischhauer-ipv4-addr-saving-00, section 2.1 >> introduces that: >> >> Therefore mechanisms are needed in order to provision and >> release IPv4 addresses for Dual-Stack PPP sessions dynamically >> >> No more details are given there and I think this is this/these >> mechanisms is/are key point for your proposal. > Within the slides of the Prague meeting > (http://www.ietf.org/proceedings/80/slides/intarea-3.ppt) > we introduced already some basic message flow for supporting this scena= rio. > This will be also part of the version 01 of the ID. > >> The draft-baker-bmwg-testing-eyeball-happiness introduces in a way the= >> problems an eyeball can face in dual stack environment. I am >> not saying that this draft totally applies here, but nonetheless care >> must be taken in your idea to not disrupt nor introduce unwanted delay= s in >> setting the IPv4 communication. > We expect that once IPv6 is introduced on the network layer > a lot of major applications will also be IPv6 enabled. > At least we have such a strategy to do this with our services. > I think the major content provider will also do this. > A typical scenario in the future would be that the customer is always c= onnected with IPv6 and can use here always-on services as voice etc. > The IPv4 connectivity parameter can be requested and used on demand. > A lot of not always-on connected customers do this already today. > Here a complete setup of the whole PPP session is needed, > whereas in our scenario just the NCP/IPCP has to be established. > So we see here not an increasing of delays etc. > In any case this delay would just valid for the first upstream IPv4 pac= ket > in a "Dual-Stack cycle". > In comparison to other IPv4 address saving approaches where each > IPv4 packet need additional tunnelling and/or processing in a CGN this = should be acceptable. > Beside my personal doubts regarding the need to implement > Happy Eyeballs in a Dual-Stack scenario > I see here no major collisions of both scenarios. > >> Regards, >> >> Gregory >> >> >> Le 14/06/2011 18:45, K.Fleischhauer@telekom.de a =E9crit : >>> Hi folks, >>> >>> right in time before the next IETF in Quebec, we would like >> to come up again with our Internet Draft >>> "On demand IPv4 address provisioning in Dual-Stack PPP deployment" >>> in order to gather further feedback from the WG. >>> During our presentation in Prague I got several remarks and >> questions >>> and from my understanding there has been some interest in >> the approach we describe in this I-D. >>> Regarding the questions I want to focus on the following >> two and will try to answer them once more: >>> - Use case: >>> In general we see this mechanism applicable for all >> Dual-Stack PPP network scenarios allthrough we focussed our >> presentation for illustrative reasons on routed gateways that >> may be provided by the Access Network provider. >>> In principle as more IPv4 addresses can be saved, as more >> services are IPv6 enabled >>> (especially those which require always-on connectivity >> (e.g. VoIP, mail, update services)) . >>> The PPP protocol has not to be changed in order to achieve >> the needed functionality - >>> the described behaviour (of independently releasing and >>> refreshing the IPv4 context within a Dual-Stack PPP session) >>> is already inherently covered by the existing PPP spec and >> also mentioned as requirements for >>> CPEs (see RFC 6204 - WLL-3). >>> >>> - Efficiency of the mechanism: >>> In principle we assume (with ongoing IPv6 deployment) that >> it is possible to save >>> after one year of roll-out of the described mechanism about 3%, >>> after two years about 8%, >>> and after three years up to 13% of the provisioned IPv4 addresses. >>> After 8 years 70% of the IPv4 addresses can be "re-cycled" >> according to our model calculations. >>> (You will find more details here: >>> >> "http://www.ix-konferenz.de/getfoldat.php?vid=3D1638&t=3Dapplicati > on/pdf&thema=3DEffizienzabsch=E4tzung" >>> (please copy the whole text between the exclamation marks >> in the address line of you browser).) >>> >>> We plan to come up with a 01 version of the I-D and would >> that's why like to gather more feedback from the WG regarding >> the possible open issues (e.g. what has to be described in >> more detail, ), unanswered questions or any other useful >> hints how to progress with this work/I-D. >>> And of course we are also interested in your opinion if >> this work should be done within the Intarea WG or if other >> WGs (PPPEXT?) may be more appropriate. >>> >>> Thanks and kind regards >>> >>> KARSTEN Fleischhauer >>> _______________________________________________ >>> Int-area mailing list >>> Int-area@ietf.org >>> https://www.ietf.org/mailman/listinfo/int-area >>> >> >> --------------ms070803010304030605080608 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOHDCC BIgwggNwoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCRlIxFzAVBgNVBAoT DkZyYW5jZSBUZWxlY29tMRMwEQYDVQQLEwpGVFJELUFzcGljMRcwFQYDVQQDEw5GVFJEIEFD IFJhY2luZTAeFw0wMjEwMDMwNzE1MjBaFw0xMjEwMDIwNzE1MjBaMFwxCzAJBgNVBAYTAkZS MRcwFQYDVQQKEw5GcmFuY2UgVGVsZWNvbTETMBEGA1UECxMKRlRSRC1Bc3BpYzEfMB0GA1UE AxMWRlRSRCBBQyBvcGVyYXRpb25uZWxsZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAPKErrcyQf+tgRGBsiBQKGGnvheMF+E74XARkkDrNnL/oA5w6e96Nj5eF7TdoiE7AIQR vOUrJkI9xP74szDUP/CPBPVxxL0855pyoH/qBcgdVCVWBDKGGroc9A5OeXsKCietb1y4+PV5 JeQVw3e41vqJ06Ut81QYPkZ84uJSIiRNoaZG+dBYBOfP8pL3Gj2jnX53eslfdiXjslMk7icb vcvAuBlzHU/LkLNHZV/iEJGGfj3X8kOMF0e3v1OlAX+TXEYlvA46wnffqVMIgiiFbAHPOBMI qOMOVQXx2SdokRcpAsHtb8LcaLrSseDf/bmzvhkufp6qYoUoNC9s4g48J9ECAwEAAaOCAVsw ggFXMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFKeHuNCL9G/jwcDa7Y604KcQKfzY MHwGA1UdIwR1MHOAFLdJ7pNBIn/ZqJeVJz5kZp6uGD8DoVikVjBUMQswCQYDVQQGEwJGUjEX MBUGA1UEChMORnJhbmNlIFRlbGVjb20xEzARBgNVBAsTCkZUUkQtQXNwaWMxFzAVBgNVBAMT DkZUUkQgQUMgUmFjaW5lggEAMA4GA1UdDwEB/wQEAwIBBjCBgAYDVR0fBHkwdzA/oD2gO4Y5 aHR0cDovL2x1Y2lmZXIucmQuZnJhbmNldGVsZWNvbS5mci9yZXZvcXVlcy9jcmxyYWNpbmUu Y3JsMDSgMqAwhi5odHRwOi8vcGtpLWwucmQuZnJhbmNldGVsZWNvbS5mci9jcmxyYWNpbmUu Y3JsMBEGCWCGSAGG+EIBAQQEAwIABzANBgkqhkiG9w0BAQUFAAOCAQEAto0WYTNPzNN/XrdT 255IwPKbYLZD/YRfQwwcbB4Ff6F9Km+J69KLpZZZx0Z/8rTsjVFc3A2QHTMy4OB2vJ1qPMUO +JlahqhHbun4GHxM0xl9qzGAaveo5xvIMqHYUnnRZ6s8LadQVbkcHxgw4oPkwRGbKoGyT6WE dFhWmn4BOBuwURN/JL4LynTkwHEklDbheEyAVTOrJIbZ88rWAKOoSzDhD+Wu/ZVvbcYuYNev qafJceD1g6rQhaz7O4HnGdmiau3/ayV7ZNDqxnm0Sfli4r4ltTi6GkxmEoT7X1JdKuH0na0Z dYRoqxRopM8uLsFMOHc46GT7HwsNcqXctRpORDCCBKIwggOKoAMCAQICAwCKZTANBgkqhkiG 9w0BAQUFADBcMQswCQYDVQQGEwJGUjEXMBUGA1UEChMORnJhbmNlIFRlbGVjb20xEzARBgNV BAsTCkZUUkQtQXNwaWMxHzAdBgNVBAMTFkZUUkQgQUMgb3BlcmF0aW9ubmVsbGUwHhcNMTAw NzEyMTAzOTI0WhcNMTMwNzExMTAzOTI0WjCBojELMAkGA1UEBhMCRlIxFzAVBgNVBAoTDkZy YW5jZSBUZWxlY29tMRMwEQYDVQQLEwpGVFJELUFTUElDMRgwFgYDVQQDEw9HcmVnb3J5IENB VUNISUUxGDAWBgoJkiaJk/IsZAEBEwhHT0lDNzMwMDExMC8GCSqGSIb3DQEJARYiZ3JlZ29y eS5jYXVjaGllQG9yYW5nZS1mdGdyb3VwLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAt5FjyQyPyGn4d2i7iP9R6e3V+XWkmLUir7VkVtsyG+/2W/tas6gILdx6NKv30sfWQ3+g huBF+Pkhxh9qBy3vjLtKysYX1OYlEi3YRfus6MGAWu1+1updfKwQLZpZD5ctp8CYOXGS9F+S GW3Gf8EB1z+RB6LX2vxNBiN2XUXLz8UCAwEAAaOCAagwggGkMA8GA1UdDwEB/wQFAwMHMAAw EwYDVR0lBAwwCgYIKwYBBQUHAwQwHQYDVR0OBBYEFBAt5fHNt/+8hqAE+aZD4e4TEHOWMGMG A1UdIwRcMFqAFKeHuNCL9G/jwcDa7Y604KcQKfzYoT+BPUM9RlIsTz1GcmFuY2UgVGVsZWNv bSxPVT1GVFJELUFzcGljLENOPUZUUkQgQUMgb3BlcmF0aW9ubmVsbGWCAQEwgZIGA1UdHwSB ijCBhzBHoEWgQ4ZBaHR0cDovL2x1Y2lmZXIucmQuZnJhbmNldGVsZWNvbS5mci9yZXZvcXVl cy9jcmxvcGVyYXRpb25uZWxsZS5jcmwwPKA6oDiGNmh0dHA6Ly9wa2ktbC5yZC5mcmFuY2V0 ZWxlY29tLmZyL2NybG9wZXJhdGlvbm5lbGxlLmNybDARBglghkgBhvhCAQEEBAMCBSAwUAYD VR0RBEkwR4EiZ3JlZ29yeS5jYXVjaGllQG9yYW5nZS1mdGdyb3VwLmNvbYEhZ3JlZ29yeS5j YXVjaGllQGZyYW5jZXRlbGVjb20uY29tMA0GCSqGSIb3DQEBBQUAA4IBAQDEYI80Q1FsKFpy 0P7ugRdyAyrkpi38t0rcktZvM9mL3LL4GYSEn7QeZZdVz/iYiA+eCtQkQQL9HZTV2U+5ehn/ Lhb9AnUfdj9LeF4HuEjsulPiTJdtIJPAyskNPi+Q7RC5prJadXJ48LIQa9OXZF8R9oHs70/P Q/+r6GuAAS3+Ywzx8mS1HKHsMKW/WwrSUnh257UXLF++yfz5g0bjaJrEqDXXVxFBKwP76lYk FS2nDWLNceqtFlt4UlQ2rP112C+gW+qmmidKYZYdxj5KOtV1MB6h0euQrrpfI8Eiiaxlkrtd qyUckSCFke9tgd99FVZcvoPrvCf2SolNot1Dk4ExMIIE5jCCA86gAwIBAgIDAIpkMA0GCSqG SIb3DQEBBQUAMFwxCzAJBgNVBAYTAkZSMRcwFQYDVQQKEw5GcmFuY2UgVGVsZWNvbTETMBEG A1UECxMKRlRSRC1Bc3BpYzEfMB0GA1UEAxMWRlRSRCBBQyBvcGVyYXRpb25uZWxsZTAeFw0x MDA3MTIxMDM5MjRaFw0xMzA3MTExMDM5MjRaMIGiMQswCQYDVQQGEwJGUjEXMBUGA1UEChMO RnJhbmNlIFRlbGVjb20xEzARBgNVBAsTCkZUUkQtQVNQSUMxGDAWBgNVBAMTD0dyZWdvcnkg Q0FVQ0hJRTEYMBYGCgmSJomT8ixkAQETCEdPSUM3MzAwMTEwLwYJKoZIhvcNAQkBFiJncmVn b3J5LmNhdWNoaWVAb3JhbmdlLWZ0Z3JvdXAuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDWbC6qSGTDAlz7mVMPpr6JRIu058v6o2jnKOmqSNoMxMikiqRbXGNXZpaK5muLSWSe nn+teWuIfm4alQNgvSATFF0uvmxqSysTpdAGVsjiHJLzXmrQXK5y6BCSyyT3iixopWPMvUK1 JqhMdGkBvfUtlRdzlSXSsSoVfLUFR2tvcwIDAQABo4IB7DCCAegwDwYDVR0PAQH/BAUDAwfA ADApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcUAgIwHQYDVR0OBBYE FLurIHxEuJvLQPzIXhWcUyrFt+jUMGMGA1UdIwRcMFqAFKeHuNCL9G/jwcDa7Y604KcQKfzY oT+BPUM9RlIsTz1GcmFuY2UgVGVsZWNvbSxPVT1GVFJELUFzcGljLENOPUZUUkQgQUMgb3Bl cmF0aW9ubmVsbGWCAQEwgZIGA1UdHwSBijCBhzBHoEWgQ4ZBaHR0cDovL2x1Y2lmZXIucmQu ZnJhbmNldGVsZWNvbS5mci9yZXZvcXVlcy9jcmxvcGVyYXRpb25uZWxsZS5jcmwwPKA6oDiG Nmh0dHA6Ly9wa2ktbC5yZC5mcmFuY2V0ZWxlY29tLmZyL2NybG9wZXJhdGlvbm5lbGxlLmNy bDARBglghkgBhvhCAQEEBAMCBaAwfgYDVR0RBHcwdaAsBgorBgEEAYI3FAIDoB4MHGdvaWM3 MzAwQHJkLmZyYW5jZXRlbGVjb20uZnKBImdyZWdvcnkuY2F1Y2hpZUBvcmFuZ2UtZnRncm91 cC5jb22BIWdyZWdvcnkuY2F1Y2hpZUBmcmFuY2V0ZWxlY29tLmNvbTANBgkqhkiG9w0BAQUF AAOCAQEAMjStlnSNuwD+8rrhh2x/MUitjMWsaZlkIw1K2TDhxlS8JVF+aY/Cls0fbdcQsw/J zrSFlzHC5cBqHyXvlTtj5cCva0/zlDTBhr+eDuyibyHxBYFvKVM37esX0d1ogl6Iwt1Lh3Yx houNe+5Krpd9NdSUMwX1oO+9VCO8I9cscCHGwTT5Yst8/RFdphZZo2JVVxdLBw6Wn9dNQUf7 Vpx8P1Dt5TRwkU+ByvIOCIGxbBvn8vGng0melSrRrccAKmFI1T5J122ewdaifQRDyd5N6T0a k0el5dKIs1Arxh+UpOpLFIv39VJqwoQ1t2XL7fduu7HBEnEwfoQt+PJnyfDcLTGCArUwggKx AgEBMGMwXDELMAkGA1UEBhMCRlIxFzAVBgNVBAoTDkZyYW5jZSBUZWxlY29tMRMwEQYDVQQL EwpGVFJELUFzcGljMR8wHQYDVQQDExZGVFJEIEFDIG9wZXJhdGlvbm5lbGxlAgMAimQwCQYF Kw4DAhoFAKCCAagwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTEwNjE2MDkxNTU4WjAjBgkqhkiG9w0BCQQxFgQURoQtGGOqGwKDzloAhuFyLBpDqjswXwYJ KoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMHIGCSsGAQQBgjcQBDFl MGMwXDELMAkGA1UEBhMCRlIxFzAVBgNVBAoTDkZyYW5jZSBUZWxlY29tMRMwEQYDVQQLEwpG VFJELUFzcGljMR8wHQYDVQQDExZGVFJEIEFDIG9wZXJhdGlvbm5lbGxlAgMAimUwdAYLKoZI hvcNAQkQAgsxZaBjMFwxCzAJBgNVBAYTAkZSMRcwFQYDVQQKEw5GcmFuY2UgVGVsZWNvbTET MBEGA1UECxMKRlRSRC1Bc3BpYzEfMB0GA1UEAxMWRlRSRCBBQyBvcGVyYXRpb25uZWxsZQID AIplMA0GCSqGSIb3DQEBAQUABIGAEtdjzBw/tt94r7k6yW2B8gJFc7zrl5EXq3Zr1m8F0d9R N8XBljpggHLgMGN5kRbHb6FtovAW4GCxSv1JmngRuZHJlnhwgkCSTKlQCD3cEzjLX8R/Psbh dthysPzUr3hKGR+IQGbInv8SH38kLByYFDNvPBq514Ada55xvctMa+YAAAAAAAA= --------------ms070803010304030605080608-- From Olaf.Bonness@telekom.de Fri Jun 17 05:17:48 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE6011E80D3 for ; Fri, 17 Jun 2011 05:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgzQnlLYwNSC for ; Fri, 17 Jun 2011 05:17:46 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 501A011E808B for ; Fri, 17 Jun 2011 05:17:45 -0700 (PDT) Received: from he101251.emea1.cds.t-internal.com ([10.125.92.154]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 17 Jun 2011 14:17:28 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.158]) by HE101251.emea1.cds.t-internal.com ([fe80::e428:2144:dcc5:bcce%15]) with mapi; Fri, 17 Jun 2011 14:17:28 +0200 From: To: Date: Fri, 17 Jun 2011 14:17:28 +0200 Thread-Topic: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? Thread-Index: AcwqsoIK/oLnwxqOSdCrLK8g7sq3+wA5rICAAAAf0EAAU0VAkA== Message-ID: References: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com> <4DF8B0D5.7060705@orange-ftgroup.com> <9B57C850BB53634CACEC56EF4853FF653B107CED@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B107CED@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: int-area@ietf.org Subject: Re: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 12:17:49 -0000 Hi Dave sorry that I couldn't follow you, but how is the expired I-D you mentioned = related to the I-D fleischhauer? There are of course some paralleles in the abstract network scenario but DS= TM is based on top of automatic IPv4-in-IPv6 tunneling / TSP and I-D fleisc= hhauer on PPP. Do you refer to the dynamc IPv4 address provisioning aspects? Thanks and regards Olaf > -----Urspr=FCngliche Nachricht----- > Von: int-area-bounces@ietf.org > [mailto:int-area-bounces@ietf.org] Im Auftrag von Dave Thaler > Gesendet: Mittwoch, 15. Juni 2011 22:21 > An: gregory.cauchie@orange-ftgroup.com; Fleischhauer, Karsten > Cc: int-area@ietf.org > Betreff: Re: [Int-area] IETF80 questions regarding "On demand > IPv4 address provisioning in Dual-Stack PPP deployment" - > Topic for WG? > > Also related is DSTM > http://tools.ietf.org/html/draft-bound-dstm-exp-04 > > -Dave > > -----Original Message----- > From: int-area-bounces@ietf.org > [mailto:int-area-bounces@ietf.org] On Behalf Of CAUCHIE Gr=E9gory > Sent: Wednesday, June 15, 2011 6:17 AM > To: K.Fleischhauer@telekom.de > Cc: int-area@ietf.org > Subject: Re: [Int-area] IETF80 questions regarding "On demand > IPv4 address provisioning in Dual-Stack PPP deployment" - > Topic for WG? > > Hi Karsten, > > IINM, your basic idea is to allocate an IPv4 public address > to one customer only when needed/requested for any IPv4 > communication. If so, I find the idea maybe a bit premature > (as today one would observe that the > IPv6 address allocation is not needed everytime for many customers... > but this is not what we aim to of course) but very > interesting if you can come with an architecture that can > request/release the IPv4 address allocation quite instantly. > > After reading draft-fleischhauer-ipv4-addr-saving-00, section > 2.1 introduces that: > > Therefore mechanisms are needed in order to provision and > release IPv4 addresses for Dual-Stack PPP sessions dynamically > > No more details are given there and I think this is > this/these mechanisms is/are key point for your proposal. The > draft-baker-bmwg-testing-eyeball-happiness introduces in a > way the problems an eyeball can face in dual stack > environment. I am not saying that this draft totally applies > here, but nonetheless care must be taken in your idea to not > disrupt nor introduce unwanted delays in setting the > IPv4 communication. > > Regards, > > Gregory > > > Le 14/06/2011 18:45, K.Fleischhauer@telekom.de a =E9crit : > > Hi folks, > > > > right in time before the next IETF in Quebec, we would like > to come up > > again with our Internet Draft "On demand IPv4 address > provisioning in Dual-Stack PPP deployment" > > in order to gather further feedback from the WG. > > During our presentation in Prague I got several remarks and > questions > > and from my understanding there has been some interest in > the approach we describe in this I-D. > > Regarding the questions I want to focus on the following > two and will try to answer them once more: > > > > - Use case: > > In general we see this mechanism applicable for all > Dual-Stack PPP network scenarios allthrough we focussed our > presentation for illustrative reasons on routed gateways that > may be provided by the Access Network provider. > > In principle as more IPv4 addresses can be saved, as more > services are > > IPv6 enabled (especially those which require always-on > connectivity (e.g. VoIP, mail, update services)) . > > The PPP protocol has not to be changed in order to achieve > the needed > > functionality - the described behaviour (of independently releasing > > and refreshing the IPv4 context within a Dual-Stack PPP session) is > > already inherently covered by the existing PPP spec and > also mentioned > > as requirements for CPEs (see RFC 6204 - WLL-3). > > > > - Efficiency of the mechanism: > > In principle we assume (with ongoing IPv6 deployment) that it is > > possible to save after one year of roll-out of the > described mechanism > > about 3%, after two years about 8%, and after three years > up to 13% of > > the provisioned IPv4 addresses. > > After 8 years 70% of the IPv4 addresses can be "re-cycled" > according to our model calculations. > > (You will find more details here: > > > "http://www.ix-konferenz.de/getfoldat.php?vid=3D1638&t=3Dapplicati on/pdf&thema=3DEffizienzabsch=E4tzung" > > (please copy the whole text between the exclamation marks in the > > address line of you browser).) > > > > > > We plan to come up with a 01 version of the I-D and would > that's why like to gather more feedback from the WG regarding > the possible open issues (e.g. what has to be described in > more detail, ), unanswered questions or any other useful > hints how to progress with this work/I-D. > > And of course we are also interested in your opinion if > this work should be done within the Intarea WG or if other > WGs (PPPEXT?) may be more appropriate. > > > > > > Thanks and kind regards > > > > KARSTEN Fleischhauer > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > > > > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > From mark@townsley.net Fri Jun 17 06:22:13 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED9211E811A; Fri, 17 Jun 2011 06:22:13 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aaf49eQN2prs; Fri, 17 Jun 2011 06:22:12 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAC411E8111; Fri, 17 Jun 2011 06:22:11 -0700 (PDT) Received: by wwe5 with SMTP id 5so289794wwe.13 for ; Fri, 17 Jun 2011 06:22:10 -0700 (PDT) Received: by 10.227.12.15 with SMTP id v15mr2097053wbv.77.1308316930370; Fri, 17 Jun 2011 06:22:10 -0700 (PDT) Received: from ams-townsley-8713.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id ge4sm957658wbb.13.2011.06.17.06.22.07 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Jun 2011 06:22:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Mark Townsley In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com> Date: Fri, 17 Jun 2011 15:22:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <03348BD8-3004-4DE2-978A-0952765B5F86@townsley.net> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com> To: X-Mailer: Apple Mail (2.1084) Cc: pppext@ietf.org, int-area@ietf.org Subject: Re: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 13:22:13 -0000 Technically, this approach is naturally feasible as PPP was designed = back when short-lived connectivity was commonplace. There is one crucial = difference though in that you will be exercising PPP stacks in a way = that is not common by tearing down and bringing up IPCP while not doing = so with LCP. According to all the RFCs this should work just fine, but = my intuition is that some PPP stacks will be forced into new code paths = that have never been exercised in this manner with the expectation of it = being the normal desired behavior. You can surely find a set of clients = where this will work, but it probably will not across the entire gamut = of deployed PPP today.=20 Applications may not be all that forgiving to IPv4 coming and going = either, e.g., I have a popular mail client that has recently taken to = crashing when I switch from wired to wireless and get a different IP = address in the process. Some of the IM connections I keep up recover = quickly to IP changes, others do not. The IETF has a whole WG (DNA) = dedicated to this tricky behavior of an IP address coming and going - = it's not always easy, in particular when the link-layer is not giving = your IP stack any up/down notification, which I believe by definition is = what your proposal requires from the very start. Finally, devices are moving towards a "cloud connected" mode of = operation. In IPv4, there is essentially no end-to-end reachability, so = modern applications are moving toward persistent, long-lived, = connections in order to achieve this. I suspect you'll see a noticeable = uptick in reliance upon such persistent, long-lived, IPv4 connections as = Apple's Lion and iOS 5 software is rolled out later this year. Both have = integration of the free "iCloud" services, and have replaced the USB = cord for device synchronization with a persistent network connection. = It's not just Apple though, the same trend is forming across the = industry.=20 So, my fear is that by the time you have built TDM into IPv4 across your = user base, it will have required at the very least a grand testing = effort and at the same time your users may well have changed their = behavior to make it unworkable anyway. I as much as anyone would hope = that all these new persistent connections would run over IPv6 if = available, but that is of course the exception not the rule for the time = being as well. - Mark On Jun 14, 2011, at 6:45 PM, = wrote: > Hi folks, >=20 > right in time before the next IETF in Quebec, we would like to come up = again with our Internet Draft > "On demand IPv4 address provisioning in Dual-Stack PPP deployment" > in order to gather further feedback from the WG. > During our presentation in Prague I got several remarks and questions > and from my understanding there has been some interest in the approach = we describe in this I-D. > Regarding the questions I want to focus on the following two and will = try to answer them once more: >=20 > - Use case: > In general we see this mechanism applicable for all Dual-Stack PPP = network scenarios allthrough we focussed our presentation for = illustrative reasons on routed gateways that may be provided by the = Access Network provider. > In principle as more IPv4 addresses can be saved, as more services are = IPv6 enabled > (especially those which require always-on connectivity (e.g. VoIP, = mail, update services)) . > The PPP protocol has not to be changed in order to achieve the needed = functionality - > the described behaviour (of independently releasing and > refreshing the IPv4 context within a Dual-Stack PPP session) > is already inherently covered by the existing PPP spec and also = mentioned as requirements for > CPEs (see RFC 6204 - WLL-3). >=20 > - Efficiency of the mechanism: > In principle we assume (with ongoing IPv6 deployment) that it is = possible to save > after one year of roll-out of the described mechanism about 3%, > after two years about 8%, > and after three years up to 13% of the provisioned IPv4 addresses. > After 8 years 70% of the IPv4 addresses can be "re-cycled" according = to our model calculations. > (You will find more details here: > = "http://www.ix-konferenz.de/getfoldat.php?vid=3D1638&t=3Dapplication/pdf&t= hema=3DEffizienzabsch=E4tzung" > (please copy the whole text between the exclamation marks in the = address line of you browser).) >=20 >=20 > We plan to come up with a 01 version of the I-D and would that's why = like to gather more feedback from the WG regarding the possible open = issues (e.g. what has to be described in more detail, ), unanswered = questions or any other useful hints how to progress with this work/I-D. > And of course we are also interested in your opinion if this work = should be done within the Intarea WG or if other WGs (PPPEXT?) may be = more appropriate. >=20 >=20 > Thanks and kind regards >=20 > KARSTEN Fleischhauer > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From cb.list6@gmail.com Fri Jun 17 07:24:42 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8056C11E80B9; Fri, 17 Jun 2011 07:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Urc4U9UZcJ1; Fri, 17 Jun 2011 07:24:41 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3D24811E80A4; Fri, 17 Jun 2011 07:24:40 -0700 (PDT) Received: by wwg11 with SMTP id 11so446340wwg.1 for ; Fri, 17 Jun 2011 07:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tNmDF3RqaVLi2WmzNBEP7q0zSk2L4m4BK2P9t06/WGY=; b=HSb0DhWNFebfm1jSubK4dM2NF2yNkeWNhgAQjsigQVYWx6IGRHgP7Iip6mJoSG4RUm 6nG/9kHGBZ5/16+vaqlm2anuBWNu4Dw/7OtrHstG4HNfl3c/jMfUPOAOxBezooZ1tlzd 72rCgK25LGXpJjcz2BlQpY3NQDww4EqFAZHPw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gFDdq1m1Ve87inMPn2WMOo91xanoobuaz+wzkRoerRxbMWFWfybydtDSApoHInowZX idxoB8wTX7OrkSEmZ5J5NghEwlLUTewA58LYuErgkAXSUVksJ61Ldc/ZDz0u+uM8kXRy 5IUiv1BBgXmQQImYcimQBvp8itDe0AsjlRhTQ= MIME-Version: 1.0 Received: by 10.216.52.193 with SMTP id e43mr2280167wec.40.1308320679285; Fri, 17 Jun 2011 07:24:39 -0700 (PDT) Received: by 10.216.165.82 with HTTP; Fri, 17 Jun 2011 07:24:39 -0700 (PDT) Received: by 10.216.165.82 with HTTP; Fri, 17 Jun 2011 07:24:39 -0700 (PDT) In-Reply-To: <03348BD8-3004-4DE2-978A-0952765B5F86@townsley.net> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com> <03348BD8-3004-4DE2-978A-0952765B5F86@townsley.net> Date: Fri, 17 Jun 2011 07:24:39 -0700 Message-ID: From: Cameron Byrne To: Mark Townsley Content-Type: multipart/alternative; boundary=0016e6dee70f57527f04a5e92512 Cc: pppext@ietf.org, int-area@ietf.org Subject: Re: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 14:24:42 -0000 --0016e6dee70f57527f04a5e92512 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Jun 17, 2011 6:22 AM, "Mark Townsley" wrote: > > > Technically, this approach is naturally feasible as PPP was designed back when short-lived connectivity was commonplace. There is one crucial difference though in that you will be exercising PPP stacks in a way that i= s not common by tearing down and bringing up IPCP while not doing so with LCP= . According to all the RFCs this should work just fine, but my intuition is that some PPP stacks will be forced into new code paths that have never bee= n exercised in this manner with the expectation of it being the normal desire= d behavior. You can surely find a set of clients where this will work, but i= t probably will not across the entire gamut of deployed PPP today. > > Applications may not be all that forgiving to IPv4 coming and going either, e.g., I have a popular mail client that has recently taken to crashing when I switch from wired to wireless and get a different IP addres= s in the process. Some of the IM connections I keep up recover quickly to IP changes, others do not. The IETF has a whole WG (DNA) dedicated to this tricky behavior of an IP address coming and going - it's not always easy, i= n particular when the link-layer is not giving your IP stack any up/down notification, which I believe by definition is what your proposal requires from the very start. > > Finally, devices are moving towards a "cloud connected" mode of operation= . In IPv4, there is essentially no end-to-end reachability, so modern applications are moving toward persistent, long-lived, connections in order to achieve this. I suspect you'll see a noticeable uptick in reliance upon such persistent, long-lived, IPv4 connections as Apple's Lion and iOS 5 software is rolled out later this year. Both have integration of the free "iCloud" services, and have replaced the USB cord for device synchronizatio= n with a persistent network connection. It's not just Apple though, the same trend is forming across the industry. > I believe the motivation is to send a clear signal and path for cloud service providers that ipv6 is the only sustainable way forward. I support this work as legitimate technique to avoid or defer cgn. It is the cloud long lived sessions that pose the most challenge for cgn. I would love for this work to be the foundation for similar work in 3gpp. Granted, a testing effort is always required for any new approach. Cb > So, my fear is that by the time you have built TDM into IPv4 across your user base, it will have required at the very least a grand testing effort and at the same time your users may well have changed their behavior to mak= e it unworkable anyway. I as much as anyone would hope that all these new persistent connections would run over IPv6 if available, but that is of course the exception not the rule for the time being as well. > > - Mark > > > On Jun 14, 2011, at 6:45 PM, < K.Fleischhauer@telekom.de> wrote: > > > Hi folks, > > > > right in time before the next IETF in Quebec, we would like to come up again with our Internet Draft > > "On demand IPv4 address provisioning in Dual-Stack PPP deployment" > > in order to gather further feedback from the WG. > > During our presentation in Prague I got several remarks and questions > > and from my understanding there has been some interest in the approach we describe in this I-D. > > Regarding the questions I want to focus on the following two and will try to answer them once more: > > > > - Use case: > > In general we see this mechanism applicable for all Dual-Stack PPP network scenarios allthrough we focussed our presentation for illustrative reasons on routed gateways that may be provided by the Access Network provider. > > In principle as more IPv4 addresses can be saved, as more services are IPv6 enabled > > (especially those which require always-on connectivity (e.g. VoIP, mail= , update services)) . > > The PPP protocol has not to be changed in order to achieve the needed functionality - > > the described behaviour (of independently releasing and > > refreshing the IPv4 context within a Dual-Stack PPP session) > > is already inherently covered by the existing PPP spec and also mentioned as requirements for > > CPEs (see RFC 6204 - WLL-3). > > > > - Efficiency of the mechanism: > > In principle we assume (with ongoing IPv6 deployment) that it is possible to save > > after one year of roll-out of the described mechanism about 3%, > > after two years about 8%, > > and after three years up to 13% of the provisioned IPv4 addresses. > > After 8 years 70% of the IPv4 addresses can be "re-cycled" according to our model calculations. > > (You will find more details here: > > " http://www.ix-konferenz.de/getfoldat.php?vid=3D1638&t=3Dapplication/pdf&the= ma=3DEffizienzabsch=E4tzung " > > (please copy the whole text between the exclamation marks in the addres= s line of you browser).) > > > > > > We plan to come up with a 01 version of the I-D and would that's why like to gather more feedback from the WG regarding the possible open issues (e.g. what has to be described in more detail, ), unanswered questions or any other useful hints how to progress with this work/I-D. > > And of course we are also interested in your opinion if this work shoul= d be done within the Intarea WG or if other WGs (PPPEXT?) may be more appropriate. > > > > > > Thanks and kind regards > > > > KARSTEN Fleischhauer > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area --0016e6dee70f57527f04a5e92512 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jun 17, 2011 6:22 AM, "Mark Townsley" <mark@townsley.net> wrote:
>
>
> Technically, this approach is naturally feasible as PPP was designed b= ack when short-lived connectivity was commonplace. There is one crucial dif= ference though in that you will be exercising PPP stacks in a way that is n= ot common by tearing down and bringing up IPCP while not doing so with LCP.= According to all the RFCs this should work just fine, but my intuition is = that some PPP stacks will be forced into new code paths that have never bee= n exercised in this manner with the expectation of it being the normal desi= red behavior. =A0You can surely find a set of clients where this will work,= but it probably will not across the entire gamut of deployed PPP today. >
> Applications may not be all that forgiving to IPv4 coming and going ei= ther, e.g., I have a popular mail client that has recently taken to crashin= g when I switch from wired to wireless and get a different IP address in th= e process. Some of the IM connections I keep up recover quickly to IP chang= es, others do not. The IETF has a whole WG (DNA) dedicated to this tricky b= ehavior of an IP address coming and going - it's not always easy, in pa= rticular when the link-layer is not giving your IP stack any up/down notifi= cation, which I believe by definition is what your proposal requires from t= he very start.
>
> Finally, devices are moving towards a "cloud connected" mode= of operation. In IPv4, there is essentially no end-to-end reachability, so= modern applications are moving toward persistent, long-lived, connections = in order to achieve this. =A0I suspect you'll see a noticeable uptick i= n reliance upon such persistent, long-lived, IPv4 connections as Apple'= s Lion and iOS 5 software is rolled out later this year. Both have integrat= ion of the free "iCloud" services, and have replaced the USB cord= for device synchronization with a persistent network connection. It's = not just Apple though, the same trend is forming across the industry.
>

I believe the motivation is to send a clear signal and path for cloud se= rvice providers that ipv6 is the only sustainable way forward.=A0 I support= this work as legitimate technique to avoid or defer cgn.

It is the cloud long lived sessions that pose the most challenge for cgn= .

I would love for this work to be the foundation for similar work in 3gpp= .

Granted, a testing effort is always required for any new approach.

Cb

> So, my fear is that by the time you have built TDM into IPv4 across= your user base, it will have required at the very least a grand testing ef= fort and at the same time your users may well have changed their behavior t= o make it unworkable anyway. I as much as anyone would hope that all these = new persistent connections would run over IPv6 if available, but that is of= course the exception not the rule for the time being as well.
>
> - Mark
>
>
> On Jun 14, 2011, at 6:45 PM, <K.Fleischhauer@telekom.de> <K.Fleischhauer@telekom.de> wrote:
>
> > Hi folks,
> >
> > right in time before the next IETF in Quebec, we would like to co= me up again with our Internet Draft
> > "On demand IPv4 address provisioning in Dual-Stack PPP deplo= yment"
> > in order to gather further feedback from the WG.
> > During our presentation in Prague I got several remarks and quest= ions
> > and from my understanding there has been some interest in the app= roach we describe in this I-D.
> > Regarding the questions I want to focus on the following two and = will try to answer them once more:
> >
> > - Use case:
> > In general we see this mechanism applicable for all Dual-Stack PP= P network scenarios allthrough we focussed our presentation for illustrativ= e reasons on routed gateways that may be provided by the Access Network pro= vider.
> > In principle as more IPv4 addresses can be saved, as more service= s are IPv6 enabled
> > (especially those which require always-on connectivity (e.g. VoIP= , mail, update services)) .
> > The PPP protocol has not to be changed in order to achieve the ne= eded functionality -
> > the described behaviour (of independently releasing and
> > refreshing the IPv4 context within a Dual-Stack PPP session)
> > is already inherently covered by the existing PPP spec and also m= entioned as requirements for
> > CPEs (see RFC 6204 - WLL-3).
> >
> > - Efficiency of the mechanism:
> > In principle we assume (with ongoing IPv6 deployment) that it is = possible to save
> > after one year of roll-out of the described mechanism about 3%, > > after two years about 8%,
> > and after three years up to 13% of the provisioned IPv4 addresses= .
> > After 8 years 70% of the IPv4 addresses can be "re-cycled&qu= ot; according to our model calculations.
> > (You will find more details here:
> > "http://w= ww.ix-konferenz.de/getfoldat.php?vid=3D1638&t=3Dapplication/pdf&the= ma=3DEffizienzabsch=E4tzung"
> > (please copy the whole text between the exclamation marks in the = address line of you browser).)
> >
> >
> > We plan to come up with a 01 version of the I-D and would that= 9;s why like to gather more feedback from the WG regarding the possible ope= n issues (e.g. what has to be described in more detail, ), unanswered quest= ions or any other useful hints how to progress with this work/I-D.
> > And of course we are also interested in your opinion if this work= should be done within the Intarea WG or if other WGs (PPPEXT?) may be more= appropriate.
> >
> >
> > Thanks and kind regards
> >
> > KARSTEN Fleischhauer
> > _______________________________________________
> > Int-area mailing list
> > Int-area@ietf.org
> > https:= //www.ietf.org/mailman/listinfo/int-area
>
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www= .ietf.org/mailman/listinfo/int-area

--0016e6dee70f57527f04a5e92512-- From internet-drafts@ietf.org Fri Jun 17 10:02:53 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA6E9E801E; Fri, 17 Jun 2011 10:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiJ7JUMKIsnQ; Fri, 17 Jun 2011 10:02:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39AD89E800A; Fri, 17 Jun 2011 10:02:53 -0700 (PDT) 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.55 Message-ID: <20110617170253.4849.40984.idtracker@ietfa.amsl.com> Date: Fri, 17 Jun 2011 10:02:53 -0700 Cc: int-area@ietf.org Subject: [Int-area] I-D Action: draft-ietf-intarea-ipv6-required-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 17:02:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Internet Area Working Group Working G= roup of the IETF. Title : IPv6 Support Required for all IP-capable nodes Author(s) : Wesley George Chris Donley Christopher Liljenstolpe Lee Howard Filename : draft-ietf-intarea-ipv6-required-00.txt Pages : 7 Date : 2011-06-17 Given the global lack of available IPv4 space, and limitations in IPv4 extension and transition technologies, this document deprecates the concept that an IP-capable node MAY support IPv4 _only_, and redefines an IP-capable node as one which supports either IPv6 _only_ or IPv4/IPv6 dual-stack. This document updates RFC1812, RFC1122 and RFC4084 to reflect the change in requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-intarea-ipv6-required-00.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-intarea-ipv6-required-00.txt From dthaler@microsoft.com Fri Jun 17 10:04:40 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05999E8007; Fri, 17 Jun 2011 10:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.542 X-Spam-Level: X-Spam-Status: No, score=-110.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9MT-GBihkJX; Fri, 17 Jun 2011 10:04:40 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 43B2E9E8005; Fri, 17 Jun 2011 10:04:40 -0700 (PDT) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 17 Jun 2011 10:04:40 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.1.289.8; Fri, 17 Jun 2011 10:04:39 -0700 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.165]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0289.008; Fri, 17 Jun 2011 10:04:39 -0700 From: Dave Thaler To: Mark Townsley , "K.Fleischhauer@telekom.de" Thread-Topic: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? Thread-Index: AQHMLPGivtoY85X6EUKujJJYVGTXOZTBxJ+A Date: Fri, 17 Jun 2011 17:04:39 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B10EE86@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com> <03348BD8-3004-4DE2-978A-0952765B5F86@townsley.net> In-Reply-To: <03348BD8-3004-4DE2-978A-0952765B5F86@townsley.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.42] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pppext@ietf.org" , "int-area@ietf.org" Subject: Re: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 17:04:40 -0000 Mark Townsley wrote: [...] > Applications may not be all that forgiving to IPv4 coming and going eithe= r, e.g., > I have a popular mail client that has recently taken to crashing when I s= witch > from wired to wireless and get a different IP address in the process. Som= e of > the IM connections I keep up recover quickly to IP changes, others do not= . The > IETF has a whole WG (DNA) dedicated to this tricky behavior of an IP addr= ess > coming and going - it's not always easy, in particular when the link-laye= r is not > giving your IP stack any up/down notification, which I believe by definit= ion is > what your proposal requires from the very start. [...] I'll second the above. This is very problematic for some applications. (Other solutions like DSTM that have on-demand IP addresses have this same = issue.) So any network that deploys such a solution in anything other than=20 a tightly controlled environment where directly connected nodes are restric= ted to a specific set of pre-tested applications, will likely result in many su= pport calls. -Dave From wesley.george@twcable.com Fri Jun 17 10:10:33 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0BA21F8472 for ; Fri, 17 Jun 2011 10:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.087 X-Spam-Level: X-Spam-Status: No, score=-0.087 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptW2BzisDWY1 for ; Fri, 17 Jun 2011 10:10:32 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8DA21F8471 for ; Fri, 17 Jun 2011 10:10:32 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.65,382,1304308800"; d="scan'208";a="239703681" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 17 Jun 2011 13:19:21 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Fri, 17 Jun 2011 13:10:22 -0400 From: "George, Wesley" To: "int-area@ietf.org" Date: Fri, 17 Jun 2011 13:10:21 -0400 Thread-Topic: New Version Notification for draft-ietf-intarea-ipv6-required-00.txt Thread-Index: AcwtEGZnZXQGR8ZiTlK9kp538Q+ZjwAAD/kA Message-ID: <34E4F50CAFA10349A41E0756550084FB089CE3F1@PRVPEXVS04.corp.twcable.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [Int-area] FW: New Version Notification for draft-ietf-intarea-ipv6-required-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 17:10:33 -0000 QXMgcmVxdWVzdGVkLCBuZXcgV0cgdmVyc2lvbiBwb3N0ZWQuDQpodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLWludGFyZWEtaXB2Ni1yZXF1aXJlZC0wMA0KDQpSZWNlaXZlZCBu byBvdGhlciB3b3Jkc21pdGhpbmcgZmVlZGJhY2sgZnJvbSB0aGUgcmV2aWV3IGZvciBXRyBhZG9w dGlvbiwgc28gbm8gY2hhbmdlcyB0byB0aGUgdGV4dCBmcm9tIHZlcnNpb24gLTAyLg0KDQpRdWVz dGlvbjogZG9lcyB0aGlzIG5lZWQgYWRkaXRpb25hbCBkaXNjdXNzaW9uIGluIFF1ZWJlYyAoc2hv dWxkIEkgcmVxdWVzdCBhZ2VuZGEgdGltZSkgb3IgY2FuIGl0IHByb2NlZWQgdG8gV0dMQz8NCg0K VGhhbmtzDQpXZXMgR2VvcmdlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmdd DQpTZW50OiBGcmlkYXksIEp1bmUgMTcsIDIwMTEgMTowMyBQTQ0KVG86IEdlb3JnZSwgV2VzbGV5 DQpDYzogSG93YXJkLCBMZWU7IERvbmxleSwgQ2hyaXMgKENhYmxlIExhYnMpOyBHZW9yZ2UsIFdl c2xleTsgY2RsQGFzZ2FhcmQub3JnDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWlldGYtaW50YXJlYS1pcHY2LXJlcXVpcmVkLTAwLnR4dA0KDQpBIG5ldyB2ZXJz aW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1pbnRhcmVhLWlwdjYtcmVxdWlyZWQtMDAudHh0IGhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgV2VzbGV5IEdlb3JnZSBhbmQgcG9zdGVkIHRv IHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOiAgICAgICAgZHJhZnQtaWV0Zi1pbnRh cmVhLWlwdjYtcmVxdWlyZWQNClJldmlzaW9uOiAgICAgICAgMDANClRpdGxlOiAgICAgICAgICAg SVB2NiBTdXBwb3J0IFJlcXVpcmVkIGZvciBhbGwgSVAtY2FwYWJsZSBub2Rlcw0KQ3JlYXRpb24g ZGF0ZTogICAyMDExLTA2LTE2DQpXRyBJRDogICAgICAgICAgIGludGFyZWENCk51bWJlciBvZiBw YWdlczogNw0KDQpBYnN0cmFjdDoNCiAgIEdpdmVuIHRoZSBnbG9iYWwgbGFjayBvZiBhdmFpbGFi bGUgSVB2NCBzcGFjZSwgYW5kIGxpbWl0YXRpb25zIGluDQogICBJUHY0IGV4dGVuc2lvbiBhbmQg dHJhbnNpdGlvbiB0ZWNobm9sb2dpZXMsIHRoaXMgZG9jdW1lbnQgZGVwcmVjYXRlcw0KICAgdGhl IGNvbmNlcHQgdGhhdCBhbiBJUC1jYXBhYmxlIG5vZGUgTUFZIHN1cHBvcnQgSVB2NCBfb25seV8s IGFuZA0KICAgcmVkZWZpbmVzIGFuIElQLWNhcGFibGUgbm9kZSBhcyBvbmUgd2hpY2ggc3VwcG9y dHMgZWl0aGVyIElQdjYgX29ubHlfDQogICBvciBJUHY0L0lQdjYgZHVhbC1zdGFjay4gIFRoaXMg ZG9jdW1lbnQgdXBkYXRlcyBSRkMxODEyLCBSRkMxMTIyIGFuZA0KICAgUkZDNDA4NCB0byByZWZs ZWN0IHRoZSBjaGFuZ2UgaW4gcmVxdWlyZW1lbnRzLg0KDQoNCg0KDQpUaGUgSUVURiBTZWNyZXRh cmlhdA0KDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp biBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJp dmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcg dG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseSBmb3Ig dGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVz c2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWls LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmli dXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVu dHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0 ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwg aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFu ZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5k IGFueSBwcmludG91dC4NCg== From scott.brim@gmail.com Fri Jun 17 10:14:52 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA6F21F84D1 for ; Fri, 17 Jun 2011 10:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlpaxtW1jJur for ; Fri, 17 Jun 2011 10:14:51 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 245DC21F84CF for ; Fri, 17 Jun 2011 10:14:51 -0700 (PDT) Received: by iyn15 with SMTP id 15so2883917iyn.31 for ; Fri, 17 Jun 2011 10:14:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=fKDPfaGJWNgNJ9R0AbEj60OSKjvFa9FvDOmhxVb9dW8=; b=FchOFhfHJZ5YHe05IY+2pvQQaAYizlQAHlXRbgWeR+WFde/zz1XIKslqULvWAZkVky cT+ey4oB6pEcSYjFma/0vScDmH8x1XodKIQ3+06DF41ljMl0xfnQonrPhWvXetlGPLKX Mp4oa3cKLvAiq+pPmSh2q5hJaoL99SlIrxAtI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=VKPKby7to2kxOLn/+H5cRPwVeWpQpFxs6vaj/yvWoprwUkEHHjpsNxdHMi3Px7DrUK Z1snCE2Y5yHoEEGycBBLcTwp2dBMkJK6IJMJLAE9R6qFqdEnh2wO9NUlk4MAdOBcgv3t 9EDKwHoCJqptr//v5XHUqDP1Xy3An314J9unU= MIME-Version: 1.0 Received: by 10.231.63.67 with SMTP id a3mr2153289ibi.94.1308330890635; Fri, 17 Jun 2011 10:14:50 -0700 (PDT) Received: by 10.231.12.9 with HTTP; Fri, 17 Jun 2011 10:14:49 -0700 (PDT) Received: by 10.231.12.9 with HTTP; Fri, 17 Jun 2011 10:14:49 -0700 (PDT) Date: Fri, 17 Jun 2011 13:14:49 -0400 Message-ID: From: Scott Brim To: Bob Hinden Content-Type: multipart/alternative; boundary=000e0cd57296fc297304a5eb85a2 Cc: Internet Area Subject: Re: [Int-area] IRON issue discussion X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 17:14:52 -0000 --000e0cd57296fc297304a5eb85a2 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 15, 2011 at 03:51, Bob Hinden wrote: > Fred, > > This sounds a lot like Mobile IPv6 with the extension that the client can change home agents if the client get's too far away from where the the home agent is. I am sure the details are different, but the functionality sounds similar. Good point. Fred, please compare and contrast IRON and NEMO. Also: How does path optimization work? --000e0cd57296fc297304a5eb85a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jun 15, 2011 at 03:51, Bob Hinden <bob.hinden@gmail.com> wrote:
> Fred,
>
> This sounds a lot like Mobile IPv6 with the extension that the client = can change home agents if the client get's too far away from where the = the home agent is. =A0I am sure the details are different, but the function= ality sounds similar.

Good point.

Fred, please compare and contrast IRON and NEMO.

Also: How does path optimization work?

--000e0cd57296fc297304a5eb85a2-- From cb.list6@gmail.com Fri Jun 17 10:17:10 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CD921F8542; Fri, 17 Jun 2011 10:17:10 -0700 (PDT) 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.151, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3aribSTuEuQ; Fri, 17 Jun 2011 10:17:09 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0854921F8538; Fri, 17 Jun 2011 10:17:08 -0700 (PDT) Received: by wyb29 with SMTP id 29so2186809wyb.31 for ; Fri, 17 Jun 2011 10:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Bn/gk4qc+BD9ZYIUs/1OJ9miIu+CjrPnPHJpT6lTYI0=; b=nee9ePQLH0Ou069uxAgHJtwR/x6lgcs44I2CkXt0bwxTZIstAvCjaWW6cQ3cvwQlKJ PbfhVF3Kh1j4Us2ubAKvSSaRE8hKOZlAXYCM30DnYI5KY//9zHVxn/xvVlpDU++6qAbC TeJzNzik9KYcFDdy3bkVXMFXKCxcdOnnHBr4s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mFinJa5G9KiqnVpGZUaiznawpxNLEaIdtVLy2E+HorxGMezafqTrnKK5IQqAZ6MsJA COdcORF1rKFnK5f1Th6Py4u5wkhJmxxHikCL6a0JoqK7ugSzE1K7Yl58lrVura5rjiKJ 5OIeEdZ26bkP6t7D7I65QOpl+kswNjUsb6rq0= MIME-Version: 1.0 Received: by 10.217.6.197 with SMTP id y47mr2408192wes.55.1308331028018; Fri, 17 Jun 2011 10:17:08 -0700 (PDT) Received: by 10.216.165.82 with HTTP; Fri, 17 Jun 2011 10:17:07 -0700 (PDT) In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B10EE86@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com> <03348BD8-3004-4DE2-978A-0952765B5F86@townsley.net> <9B57C850BB53634CACEC56EF4853FF653B10EE86@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Date: Fri, 17 Jun 2011 10:17:07 -0700 Message-ID: From: Cameron Byrne To: Dave Thaler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pppext@ietf.org" , "int-area@ietf.org" Subject: Re: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 17:17:10 -0000 On Fri, Jun 17, 2011 at 10:04 AM, Dave Thaler wrote= : > Mark Townsley wrote: > [...] >> Applications may not be all that forgiving to IPv4 coming and going eith= er, e.g., >> I have a popular mail client that has recently taken to crashing when I = switch >> from wired to wireless and get a different IP address in the process. So= me of >> the IM connections I keep up recover quickly to IP changes, others do no= t. The >> IETF has a whole WG (DNA) dedicated to this tricky behavior of an IP add= ress >> coming and going - it's not always easy, in particular when the link-lay= er is not >> giving your IP stack any up/down notification, which I believe by defini= tion is >> what your proposal requires from the very start. > [...] > > I'll second the above. =A0 This is very problematic for some applications= . > (Other solutions like DSTM that have on-demand IP addresses have this sam= e issue.) > > So any network that deploys such a solution in anything other than > a tightly controlled environment where directly connected nodes are restr= icted > to a specific set of pre-tested applications, will likely result in many = support calls. > Is this really different from the dial-on-demand routing that has existed for years and still exist as common backup connectivity technique? I assume that this would be implemented on an Home Gateway which provides consistent addressing to IPv4 hosts within the home, and dial-on-demand type mechanism request the IPv4 address to the home gateway to do NAT44 in the event of an IPv4 stream arrives. Cameron From jshire@hyduke.com Fri Jun 17 10:31:30 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A5911E807B; Fri, 17 Jun 2011 10:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ogngu-WZC5d5; Fri, 17 Jun 2011 10:31:29 -0700 (PDT) Received: from mail.hyduke.net (mail.hyduke.net [67.226.164.185]) by ietfa.amsl.com (Postfix) with ESMTP id 7D09111E8071; Fri, 17 Jun 2011 10:31:29 -0700 (PDT) Received: from HYDSRV6.hyduke.net (192.168.10.44) by nsk1mx02.hyduke.net (192.168.10.49) with Microsoft SMTP Server id 8.1.436.0; Fri, 17 Jun 2011 11:26:30 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Class: urn:content-classes:message Date: Fri, 17 Jun 2011 11:31:27 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <5D359AE112816C46AE85C0494190F973027FCF92@hydsrv6.hyduke.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? Thread-Index: AcwtEmd4PNcU6b92RuKvm2cDC6jKKwAAZfcg References: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com><03348BD8-3004-4DE2-978A-0952765B5F86@townsley.net><9B57C850BB53634CACEC56EF4853FF653B10EE86@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> From: Joshua Shire To: "Cameron Byrne" , "Dave Thaler" X-TM-AS-Product-Ver: SMEX-8.0.0.4125-6.500.1024-18204.004 X-TM-AS-Result: No--18.339600-4.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: pppext@ietf.org, int-area@ietf.org Subject: Re: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 17:31:30 -0000 I'll second this. Most of the new SMB level gateway devices we're seeing = on the market support some type of USB connected 3G/HSPA dial-on demand = system as a backup link. We've implemented it quite extensively with = little to no problems. Josh -----Original Message----- From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On = Behalf Of Cameron Byrne Sent: Friday, June 17, 2011 11:17 AM To: Dave Thaler Cc: pppext@ietf.org; int-area@ietf.org Subject: Re: [Int-area] IETF80 questions regarding "On demand IPv4 = address provisioning in Dual-Stack PPP deployment" - Topic for WG? On Fri, Jun 17, 2011 at 10:04 AM, Dave Thaler = wrote: > Mark Townsley wrote: > [...] >> Applications may not be all that forgiving to IPv4 coming and going = either, e.g., >> I have a popular mail client that has recently taken to crashing when = I switch >> from wired to wireless and get a different IP address in the process. = Some of >> the IM connections I keep up recover quickly to IP changes, others do = not. The >> IETF has a whole WG (DNA) dedicated to this tricky behavior of an IP = address >> coming and going - it's not always easy, in particular when the = link-layer is not >> giving your IP stack any up/down notification, which I believe by = definition is >> what your proposal requires from the very start. > [...] > > I'll second the above. =A0 This is very problematic for some = applications. > (Other solutions like DSTM that have on-demand IP addresses have this = same issue.) > > So any network that deploys such a solution in anything other than > a tightly controlled environment where directly connected nodes are = restricted > to a specific set of pre-tested applications, will likely result in = many support calls. > Is this really different from the dial-on-demand routing that has existed for years and still exist as common backup connectivity technique? I assume that this would be implemented on an Home Gateway which provides consistent addressing to IPv4 hosts within the home, and dial-on-demand type mechanism request the IPv4 address to the home gateway to do NAT44 in the event of an IPv4 stream arrives. Cameron _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area From dthaler@microsoft.com Fri Jun 17 12:00:44 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170C79E805C; Fri, 17 Jun 2011 12:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.544 X-Spam-Level: X-Spam-Status: No, score=-110.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRtDe9lU7QX4; Fri, 17 Jun 2011 12:00:43 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3FC9E808C; Fri, 17 Jun 2011 12:00:29 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 17 Jun 2011 12:00:29 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.289.8; Fri, 17 Jun 2011 12:00:28 -0700 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.165]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0289.008; Fri, 17 Jun 2011 12:00:28 -0700 From: Dave Thaler To: Joshua Shire , Cameron Byrne Thread-Topic: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? Thread-Index: AQHMLRJl9qcFCAZHV0a5gvbXuIaqHpTCQ/mA//+jTkA= Date: Fri, 17 Jun 2011 19:00:28 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B10F936@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com><03348BD8-3004-4DE2-978A-0952765B5F86@townsley.net><9B57C850BB53634CACEC56EF4853FF653B10EE86@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <5D359AE112816C46AE85C0494190F973027FCF92@hydsrv6.hyduke.net> In-Reply-To: <5D359AE112816C46AE85C0494190F973027FCF92@hydsrv6.hyduke.net> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pppext@ietf.org" , "int-area@ietf.org" Subject: Re: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 19:00:44 -0000 Requiring the CPE to be a gateway rather than a host running arbitrary appl= ications is one way to restrict directly connected nodes to a specific set of pre-te= sted applications. -Dave > -----Original Message----- > From: Joshua Shire [mailto:jshire@hyduke.com] > Sent: Friday, June 17, 2011 10:31 AM > To: Cameron Byrne; Dave Thaler > Cc: pppext@ietf.org; int-area@ietf.org > Subject: RE: [Int-area] IETF80 questions regarding "On demand IPv4 addres= s > provisioning in Dual-Stack PPP deployment" - Topic for WG? >=20 > I'll second this. Most of the new SMB level gateway devices we're seeing = on the > market support some type of USB connected 3G/HSPA dial-on demand system > as a backup link. We've implemented it quite extensively with little to n= o > problems. >=20 > Josh >=20 > -----Original Message----- > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On Beh= alf > Of Cameron Byrne > Sent: Friday, June 17, 2011 11:17 AM > To: Dave Thaler > Cc: pppext@ietf.org; int-area@ietf.org > Subject: Re: [Int-area] IETF80 questions regarding "On demand IPv4 addres= s > provisioning in Dual-Stack PPP deployment" - Topic for WG? >=20 > On Fri, Jun 17, 2011 at 10:04 AM, Dave Thaler > wrote: > > Mark Townsley wrote: > > [...] > >> Applications may not be all that forgiving to IPv4 coming and going > >> either, e.g., I have a popular mail client that has recently taken to > >> crashing when I switch from wired to wireless and get a different IP > >> address in the process. Some of the IM connections I keep up recover > >> quickly to IP changes, others do not. The IETF has a whole WG (DNA) > >> dedicated to this tricky behavior of an IP address coming and going - > >> it's not always easy, in particular when the link-layer is not giving > >> your IP stack any up/down notification, which I believe by definition = is what > your proposal requires from the very start. > > [...] > > > > I'll second the above. =A0 This is very problematic for some applicatio= ns. > > (Other solutions like DSTM that have on-demand IP addresses have this > > same issue.) > > > > So any network that deploys such a solution in anything other than a > > tightly controlled environment where directly connected nodes are > > restricted to a specific set of pre-tested applications, will likely re= sult in many > support calls. > > >=20 > Is this really different from the dial-on-demand routing that has existed= for > years and still exist as common backup connectivity technique? >=20 > I assume that this would be implemented on an Home Gateway which provides > consistent addressing to IPv4 hosts within the home, and dial-on-demand t= ype > mechanism request the IPv4 address to the home gateway to do NAT44 in the > event of an IPv4 stream arrives. >=20 >=20 > Cameron > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From vjs@calcite.rhyolite.com Fri Jun 17 14:48:21 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E0511E80EF; Fri, 17 Jun 2011 14:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9ml-apexpDb; Fri, 17 Jun 2011 14:48:20 -0700 (PDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [IPv6:2001:4978:230::3]) by ietfa.amsl.com (Postfix) with ESMTP id 9183211E807F; Fri, 17 Jun 2011 14:48:19 -0700 (PDT) Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.14.4/8.14.4) with ESMTP id p5HLmAB9098514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) env-from ; Fri, 17 Jun 2011 21:48:10 GMT Received: (from vjs@localhost) by calcite.rhyolite.com (8.14.4/8.14.4/Submit) id p5HLm8wt098512; Fri, 17 Jun 2011 21:48:08 GMT Date: Fri, 17 Jun 2011 21:48:08 GMT From: Vernon Schryver Message-Id: <201106172148.p5HLm8wt098512@calcite.rhyolite.com> To: K.Fleischhauer@telekom.de, mark@townsley.net In-Reply-To: <03348BD8-3004-4DE2-978A-0952765B5F86@townsley.net> X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist X-Mailman-Approved-At: Fri, 17 Jun 2011 14:57:33 -0700 Cc: pppext@ietf.org, int-area@ietf.org Subject: Re: [Int-area] [Pppext] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 21:48:21 -0000 > From: Mark Townsley > To: "" > Cc: pppext@ietf.org, int-area@ietf.org > Technically, this approach ... > > The PPP protocol has not to be changed in order to achieve the needed functionality - > > "http://www.ix-konferenz.de/getfoldat.php?vid=1638&t=application/pdf&thema=Effizienzabschätzung" What is the topic or issue? That PDF slide show has plenty of words and pictures justifying and advocating whatever it is talking about, but I don't seem much about concrete mechanisms or changes to PPP code. My guess is that the topic is something about PPP peers killing their IPCP state machines after IP inactivity (presumably ignoring LCP activity as well as other activity such as bridging) and then restarting IPCP on new activity to negotiate potentially new IPv4 addresses. If I've guessed the topic correctly then: - I bet M.Townsley is right and that some PPP implementations treat a broken IPCP state as reason to kill LCP and restart the whole session. - I think M.Townsley has understated the problems in changing IP addresses on running systems. I bet most server programs will not notice that their carefully constructed lists of TCP LISTEN or UDP sockets are kaput because the local IP addresses changed. Of course, any and all existing TCP sessions break when IP addresses change. Besides apparently quiet ssh, ftp, and (secure-)telnet sessions, and so forth, what about cached SMTP and HTTP connections? What about firewalls? - How often is IPCP used today to allocate IP addresses? Isn't DHCP often used even over PPP, especially for the consumer grade Internet services that are most likely to be targets of a scheme like this? - Would this scheme have more or fewer odd side effects and bad boundary cases than the other schemes for dealing with IPv4 address shortages such as "large scale" or "carrier grade NAT"? Besides application hiccups on changing addresses, what happens when all of your users try to be active and so you temporary can't allocate addresses for all of them? > > We plan to come up with a 01 version of the I-D ... > > And of course we are also interested in your opinion if this > > work should be done within the Intarea WG or if other WGs (PPPEXT?) > > may be more appropriate. Given the statement about the protocol itself not changing, how does the PPPEXT working group or the IETF in general have standing to talk about the issue or object to the proposal, whatever it is? Before writing an I-D that would merely try to convince others to write and test code, why not write and test some code before writing an I-D? Successful tests with a few 100 real users would go a long way to answering objections and generating interest in the idea. The idea might sound good if 500 real Windows users behind Lunix-based cable or DSL modems with the modest code implementing this idea have no problems. (What's the name of the commodity consumer router that is frequently and routinely hacked to support new things?) On the other hand, if it is impossible or impractical to write code, get it installed in a small test environment (e.g. a few 100 users), or get positive results from tests, then there's no need to write an I-D or for anyone else or any working group to consider it. If there is no hope of getting a router vendors to implement the idea before an RFC (not just an I-D) is published, then the idea has no hope. By the time an RFC could be approved and published and vendors respond, the IPv4 address shortage will have been solved for years one way or another. Vernon Schryver vjs@rhyolite.com From Fred.L.Templin@boeing.com Fri Jun 17 15:32:50 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E132311E807F for ; Fri, 17 Jun 2011 15:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.398 X-Spam-Level: X-Spam-Status: No, score=-6.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cS9h72d3VSHm for ; Fri, 17 Jun 2011 15:32:50 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id EE5EE11E80EF for ; Fri, 17 Jun 2011 15:32:49 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p5HMWjvZ012139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 Jun 2011 17:32:45 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id p5HMWjE0017208; Fri, 17 Jun 2011 17:32:45 -0500 (CDT) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p5HMWh7m017164 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 17 Jun 2011 17:32:43 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Fri, 17 Jun 2011 15:32:42 -0700 From: "Templin, Fred L" To: Scott Brim , Bob Hinden Date: Fri, 17 Jun 2011 15:32:41 -0700 Thread-Topic: [Int-area] IRON issue discussion Thread-Index: AcwtEhWs31LYMlbbS2ujuNNTaZlhMQAKdokQ Message-ID: References: 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_E1829B60731D1740BB7A0626B4FAF0A65C6A89E0E4XCHNW01Vnwnos_" MIME-Version: 1.0 Cc: Internet Area Subject: Re: [Int-area] IRON issue discussion X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 22:32:51 -0000 --_000_E1829B60731D1740BB7A0626B4FAF0A65C6A89E0E4XCHNW01Vnwnos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Scott, Reading RFC3963 ("Network Mobility (NEMO) Basic Support Protocol"), NEMO is an extension of the MIPv6 protocol whereas IRON is a mobile tunneling system unto itself. The NEMO Mobile Router construct is essentially the same as the IRON client router, although the IRON client can also be a singleton end system. Like NEMO, IRON seeks to support session continuity for nodes in the mobile network, and for the mobile network nodes to be reachable while the IRON client router moves from one Internet attachment point to another. The NEMO Mobile Router forms a bidirectional tunnel with the MIPv6 home agent, and apparently (in the NEMO basic case, at least) all traffic between the MR and correspondents must flow through the HA in both directions. This is where the IRON model offers a significant difference. For IRON, the IRON client forms a bidirectional tunnel with a nearby IRON server. If the client moves far from its current server, it simply forms a bidirectional tunnel with a new IRON server and drops the bidirectional tunnel with the old server. The IRON overlay network dynamically tracks the client-to-server bindings and will update the bindings so that connectivity is preserved across the handover. Furthermore, the bidirectional tunnel is used for all traffic coming from correspondent nodes destined to nodes in the IRON client's mobile network. In the outbound direction, however, the IRON client can form unidirectional tunnels with the IRON server that provides service to the final destination so that path stretch can be greatly reduced. The unidirectional tunnels are established based on route optimization signalling messages informing the IRON client of a more direct path toward the correspondent. Finally, the underlying links over which the IRON tunnels ride can fluctuate (come up, go down, change addresses, etc.) without the fluctuations disrupting the tunnels in any way. As long as there is at least one working underlying link, the tunnels will survive. I hope this helps clarify, Thanks - Fred fred.l.templin@boeing.com ________________________________ From: Scott Brim [mailto:scott.brim@gmail.com] Sent: Friday, June 17, 2011 10:15 AM To: Bob Hinden Cc: Templin, Fred L; t.petch; Internet Area Subject: Re: [Int-area] IRON issue discussion On Wed, Jun 15, 2011 at 03:51, Bob Hinden > wrote: > Fred, > > This sounds a lot like Mobile IPv6 with the extension that the client can= change home agents if the client get's too far away from where the the hom= e agent is. I am sure the details are different, but the functionality sou= nds similar. Good point. Fred, please compare and contrast IRON and NEMO. Also: How does path optimization work? --_000_E1829B60731D1740BB7A0626B4FAF0A65C6A89E0E4XCHNW01Vnwnos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Scott,
 
Reading RFC3963 ("Network Mobility (NEMO) Basic Support=20 Protocol"),
NEMO is an extension of the MIPv6 protocol whereas IRON is a=20 mobile
tunneling system unto itself. The NEMO Mobile Route= r construct=20 is
essentially the same as the IRON client router, althou= gh the=20 IRON
client can also be a singleton end system. Like NEMO, I= RON=20 seeks
to support session continuity for nodes in the mobile network,=20 and
for the mobile network nodes to be reachable while the IRON=20 client
router moves from one Internet attachment point to=20 another.
 
The NEMO Mobile Router forms a bidirectional tunnel with the=20 MIPv6
home agent, and apparently (in the NEMO basic case, at least)=20 all
traffic between the MR and correspondents must flow through=20 the
HA in both directions. This is where the IRON model offers=20 a
significant difference.
 
For IRON, the IRON client forms a bidirectional tunnel with a=20 nearby
IRON server. If the client moves far from its current server, it=20 simply
forms a bidirectional tunnel with a new IRON server and drops=20 the
bidirectional tunnel with the old server. The IRON=20 overlay network
dynamically tracks the client-to-server bindings and will=20 update
the bindings so that connectivity is preserved across the=20 handover.
 
Furthermore, the bidirectional tunnel is used for all traffic=20 coming
from correspondent nodes destined to nodes in the IRON=20 client's
mobile network. In the outbound direction, however, the=20 IRON
client can form unidirectional tunnels with the IRON server=20 that
provides service to the final destination so that path stretch=20 can
be greatly reduced. The unidirectional tunnels are=20 established
based on route optimization signalling messages informing=20 the
IRON client of a more direct path toward the=20 correspondent.
 
Finally, the underlying links over which the IRON tunnels=20 ride
can fluctuate (come up, go down, change addresses, etc.)=20 without
the fluctuations disrupting the tunnels in any way. As long=20 as
there is at least one working underlying link, the tunnels=20 will
survive.
 
I=20 hope this helps clarify,
 
Thanks - Fred
fred.l.templin@boeing.com

From: Scott Brim [mailto:scott.brim@g= mail.com]=20
Sent: Friday, June 17, 2011 10:15 AM
To: Bob=20 Hinden
Cc: Templin, Fred L; t.petch; Internet=20 Area
Subject: Re: [Int-area] IRON issue=20 discussion

On Wed, Jun 15, 2011 at 03:51, Bob Hinden <bob.hinden@gmail.com> wrote:<= BR>>=20 Fred,
>
> This sounds a lot like Mobile IPv6 with the extensi= on=20 that the client can change home agents if the client get's too far away f= rom=20 where the the home agent is.  I am sure the details are different, b= ut=20 the functionality sounds similar.

Good point.

Fred, please compare and contrast IRON and NEMO.

Also: How does path optimization work?

--_000_E1829B60731D1740BB7A0626B4FAF0A65C6A89E0E4XCHNW01Vnwnos_-- From dwing@cisco.com Fri Jun 17 17:29:01 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9FC11E818D for ; Fri, 17 Jun 2011 17:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4RhTEvF7ZsG for ; Fri, 17 Jun 2011 17:29:00 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1756811E818B for ; Fri, 17 Jun 2011 17:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=4433; q=dns/txt; s=iport; t=1308356940; x=1309566540; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=DUHnVIgK5uVdAWbBLchTqWD0QwcLkXQAisEp9wcW99A=; b=CopZ+atZlqh0TfVXX/Leb4lnC/1v2D64/bQ1FSq9xtpcNkO3xqARqI9n YYeKxyrIzTwF3764kX+RM40GBjvgh1eCsioXeAhW5NMWimPwmfWsu+1td bXyPQyWvNwJ7abRWRV49q6Jmhe1rEBMtHYkNKnWXtBC0fVMs1oBS1G9DK A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgAAPfw+02rRDoH/2dsb2JhbABSl1WBZo0kd6ppnXeGJwSHIJpb X-IronPort-AV: E=Sophos;i="4.65,384,1304294400"; d="scan'208";a="340092956" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 18 Jun 2011 00:28:59 +0000 Received: from dwingWS (dhcp-128-107-104-194.cisco.com [128.107.104.194]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5I0SxVw004095; Sat, 18 Jun 2011 00:28:59 GMT From: "Dan Wing" To: , References: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com> Date: Fri, 17 Jun 2011 17:28:59 -0700 Message-ID: <007501cc2d4e$b78fb7d0$26af2770$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwqsoIK/oLnwxqOSdCrLK8g7sq3+wBybesA Content-Language: en-us Subject: Re: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 00:29:01 -0000 This technique causes a round-trip delay when an IPv4 application starts = up, due to the on-demand acquisition of an IPv4 address. This technique is useful in environments where there is no IPv4 address sharing (that is, = with publicly-routable IPv4 addresses). This technique is useful when not = all of the subscribers are needing IPv4 addresses (e.g., they are not connected = to the Internet [powered off], or they are running applications that only = need to use IPv6). This technique requires one publicly-routable IPv4 = address for every IPv4 host that has an active IPv4 session (which seems to have limited usefulness, considering the world has exhausted its IPv4 address space). This technique requires changing the host's IPv4 stack. IPv4 address sharing (with NAPT or with an A+P technique) avoids that round-trip delay, and without changing the host's IPv4 stack. Summary: this seems only useful for 3G/4G, where the host's IPv4 stack = can be changed, and will cause noticeable delays when users launch = applications that need to use IPv4 (delay caused by acquiring an address on demand), = and will be ineffective at its intended goal (avoiding IPv4 address sharing) = if "too many" users need IPv4 addresses (e.g., a popular application is = using IPv4 -- Skype, music streaming, video streaming, instant messaging = server, imap/pop server, etc.). -d > -----Original Message----- > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On > Behalf Of K.Fleischhauer@telekom.de > Sent: Tuesday, June 14, 2011 9:46 AM > To: int-area@ietf.org > Subject: [Int-area] IETF80 questions regarding "On demand IPv4 address > provisioning in Dual-Stack PPP deployment" - Topic for WG? >=20 > Hi folks, >=20 > right in time before the next IETF in Quebec, we would like to come up > again with our Internet Draft > "On demand IPv4 address provisioning in Dual-Stack PPP deployment" > in order to gather further feedback from the WG. > During our presentation in Prague I got several remarks and questions > and from my understanding there has been some interest in the approach > we describe in this I-D. > Regarding the questions I want to focus on the following two and will > try to answer them once more: >=20 > - Use case: > In general we see this mechanism applicable for all Dual-Stack PPP > network scenarios allthrough we focussed our presentation for > illustrative reasons on routed gateways that may be provided by the > Access Network provider. > In principle as more IPv4 addresses can be saved, as more services are > IPv6 enabled > (especially those which require always-on connectivity (e.g. VoIP, > mail, update services)) . > The PPP protocol has not to be changed in order to achieve the needed > functionality - > the described behaviour (of independently releasing and > refreshing the IPv4 context within a Dual-Stack PPP session) > is already inherently covered by the existing PPP spec and also > mentioned as requirements for > CPEs (see RFC 6204 - WLL-3). >=20 > - Efficiency of the mechanism: > In principle we assume (with ongoing IPv6 deployment) that it is > possible to save > after one year of roll-out of the described mechanism about 3%, > after two years about 8%, > and after three years up to 13% of the provisioned IPv4 addresses. > After 8 years 70% of the IPv4 addresses can be "re-cycled" according = to > our model calculations. > (You will find more details here: > "http://www.ix- > = konferenz.de/getfoldat.php?vid=3D1638&t=3Dapplication/pdf&thema=3DEffizie= nzab > sch=E4tzung" > (please copy the whole text between the exclamation marks in the > address line of you browser).) >=20 >=20 > We plan to come up with a 01 version of the I-D and would that's why > like to gather more feedback from the WG regarding the possible open > issues (e.g. what has to be described in more detail, ), unanswered > questions or any other useful hints how to progress with this = work/I-D. > And of course we are also interested in your opinion if this work > should be done within the Intarea WG or if other WGs (PPPEXT?) may be > more appropriate. >=20 >=20 > Thanks and kind regards >=20 > KARSTEN Fleischhauer > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From K.Fleischhauer@telekom.de Sat Jun 18 10:17:32 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D66B11E80CF for ; Sat, 18 Jun 2011 10:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwwgrOBw8m+p for ; Sat, 18 Jun 2011 10:17:31 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 503B611E8084 for ; Sat, 18 Jun 2011 10:17:29 -0700 (PDT) Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 18 Jun 2011 19:17:21 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.233]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Sat, 18 Jun 2011 19:17:21 +0200 From: To: , Date: Sat, 18 Jun 2011 19:17:18 +0200 Thread-Topic: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? Thread-Index: AcwqsoIK/oLnwxqOSdCrLK8g7sq3+wBybesAAFcKEqA= Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADE52C25@HE111648.emea1.cds.t-internal.com> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com> <007501cc2d4e$b78fb7d0$26af2770$@com> In-Reply-To: <007501cc2d4e$b78fb7d0$26af2770$@com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 17:17:32 -0000 Dear Dan, see my comments inline Best KARSTEN > -----Urspr=FCngliche Nachricht----- > Von: Dan Wing [mailto:dwing@cisco.com] > Gesendet: Samstag, 18. Juni 2011 02:29 > An: Fleischhauer, Karsten; int-area@ietf.org > Betreff: RE: [Int-area] IETF80 questions regarding "On demand > IPv4 address provisioning in Dual-Stack PPP deployment" - > Topic for WG? > > This technique causes a round-trip delay when an IPv4 > application starts up, due to the on-demand acquisition of an IPv4 addres= s. The situation in many cases today is, that when "an IPv4 application starts= up" the whole PPP session incl. IPCP has to be established. In the ID scenario just IPCP has to be established, so I see not a disadvan= tage. Nevertheless this round-trip issue is only valid for the first packet of a "Dual-Stack cycle". > This technique is useful in environments where there is no IPv4 address s= haring > (that is, with publicly-routable IPv4 addresses). I think it is also useful in a Home Network scenario with an routed HG and = NAT44@HG. > This technique is useful when not all of > the subscribers are needing IPv4 addresses (e.g., they are > not connected to the Internet [powered off], or they are running applicat= ions > that only need to use IPv6). Ack. And we will pushing the usage of IPv6 to support this scenario. > This technique requires one publicly-routable > IPv4 address for every IPv4 host that has an active IPv4 session (which > seems to have limited usefulness, considering the world has exhausted its > IPv4 address space). I think this will work also in a Home Network scenario with an routed HG an= d NAT44@HG. > This technique requires changing the host's IPv4 stack. This is only valid for the PPP endpoint. Our focus is the Home Network scenario with an routed HG and NAT44@HG. The PPP endpoint is the HG. So just the HG and BNG/BRAS need to be changed. > IPv4 address sharing (with NAPT or with an A+P technique) avoids that > round-trip delay, and without changing the host's IPv4 stack. As already mentioned above the round-trip issue is only valid for the first= packet of a "Dual-Stack cycle". A CGN scenario would cause an additional round-trip d= elay For each IPv4 packet (NAT 44 processing within the carrier network + Packet forwarding via the CGN which will increase the number of hops/links)= . > > Summary: this seems only useful for 3G/4G, where the host's > IPv4 stack can be changed, Our focus is the fixed network PPP access due BBF TR-178 respectively WT-24= 2. But you are right for 3G/4G the general mechanism would also be applicable. > and will cause noticeable delays when users > launch applications that need to use IPv4 (delay caused by acquiring an a= ddress > on demand), We see the delay issue not so critically. > and will be ineffective at its intended goal (avoiding IPv4 > address sharing) if "too many" users need IPv4 addresses (e.g., a popular > application is using IPv4 -- Skype, music streaming, video streaming, ins= tant > messaging server, imap/pop server, etc.). Of course that can happen, when the application remain on IPv4-only. But here I would expect much more problems when at least one NAT444 is in t= he end-to-end path. > -d > > > > > -----Original Message----- > > From: int-area-bounces@ietf.org > [mailto:int-area-bounces@ietf.org] On > > Behalf Of K.Fleischhauer@telekom.de > > Sent: Tuesday, June 14, 2011 9:46 AM > > To: int-area@ietf.org > > Subject: [Int-area] IETF80 questions regarding "On demand > IPv4 address > > provisioning in Dual-Stack PPP deployment" - Topic for WG? > > > > Hi folks, > > > > right in time before the next IETF in Quebec, we would like > to come up > > again with our Internet Draft > > "On demand IPv4 address provisioning in Dual-Stack PPP deployment" > > in order to gather further feedback from the WG. > > During our presentation in Prague I got several remarks and > questions > > and from my understanding there has been some interest in > the approach > > we describe in this I-D. > > Regarding the questions I want to focus on the following > two and will > > try to answer them once more: > > > > - Use case: > > In general we see this mechanism applicable for all Dual-Stack PPP > > network scenarios allthrough we focussed our presentation for > > illustrative reasons on routed gateways that may be provided by the > > Access Network provider. > > In principle as more IPv4 addresses can be saved, as more > services are > > IPv6 enabled > > (especially those which require always-on connectivity (e.g. VoIP, > > mail, update services)) . > > The PPP protocol has not to be changed in order to achieve > the needed > > functionality - > > the described behaviour (of independently releasing and > > refreshing the IPv4 context within a Dual-Stack PPP session) > > is already inherently covered by the existing PPP spec and also > > mentioned as requirements for > > CPEs (see RFC 6204 - WLL-3). > > > > - Efficiency of the mechanism: > > In principle we assume (with ongoing IPv6 deployment) that it is > > possible to save > > after one year of roll-out of the described mechanism about 3%, > > after two years about 8%, > > and after three years up to 13% of the provisioned IPv4 addresses. > > After 8 years 70% of the IPv4 addresses can be "re-cycled" > according to > > our model calculations. > > (You will find more details here: > > "http://www.ix- > > > konferenz.de/getfoldat.php?vid=3D1638&t=3Dapplication/pdf&thema=3DEf fizienzab > > sch=E4tzung" > > (please copy the whole text between the exclamation marks in the > > address line of you browser).) > > > > > > We plan to come up with a 01 version of the I-D and would that's why > > like to gather more feedback from the WG regarding the possible open > > issues (e.g. what has to be described in more detail, ), unanswered > > questions or any other useful hints how to progress with > this work/I-D. > > And of course we are also interested in your opinion if this work > > should be done within the Intarea WG or if other WGs > (PPPEXT?) may be > > more appropriate. > > > > > > Thanks and kind regards > > > > KARSTEN Fleischhauer > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > > From K.Fleischhauer@telekom.de Sun Jun 19 04:07:37 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77AE021F8522; Sun, 19 Jun 2011 04:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xZ1OcquR0w0; Sun, 19 Jun 2011 04:07:34 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 05FC621F8519; Sun, 19 Jun 2011 04:07:33 -0700 (PDT) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 19 Jun 2011 13:07:29 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.233]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Sun, 19 Jun 2011 13:07:29 +0200 From: To: Date: Sun, 19 Jun 2011 13:07:27 +0200 Thread-Topic: [Pppext] [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? Thread-Index: AcwtOErscG1GntjtQNWsiA3dGo/begBLfhow Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADE52C2A@HE111648.emea1.cds.t-internal.com> References: <03348BD8-3004-4DE2-978A-0952765B5F86@townsley.net> <201106172148.p5HLm8wt098512@calcite.rhyolite.com> In-Reply-To: <201106172148.p5HLm8wt098512@calcite.rhyolite.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pppext@ietf.org, int-area@ietf.org Subject: Re: [Int-area] [Pppext] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 11:07:37 -0000 Dear Vernon, See my comments inline. Best KARSTEN > -----Urspr=FCngliche Nachricht----- > Von: Vernon Schryver [mailto:vjs@calcite.rhyolite.com] > Gesendet: Freitag, 17. Juni 2011 23:48 > An: Fleischhauer, Karsten; mark@townsley.net > Cc: int-area@ietf.org; pppext@ietf.org > Betreff: Re: [Pppext] [Int-area] IETF80 questions regarding > "On demand IPv4 address provisioning in Dual-Stack PPP > deployment" - Topic for WG? > > > From: Mark Townsley > > To: "" > > Cc: pppext@ietf.org, int-area@ietf.org > > > Technically, this approach ... > > > > The PPP protocol has not to be changed in order to > achieve the needed functionality - > > > > > "http://www.ix-konferenz.de/getfoldat.php?vid=3D1638&t=3Dapplicati on/pdf&thema=3DEffizienzabsch=E4tzung" > > What is the topic or issue? That PDF slide show has plenty of words > and pictures justifying and advocating whatever it is talking about, > but I don't seem much about concrete mechanisms or changes to > PPP code. > My guess is that the topic is something about PPP peers killing their > IPCP state machines after IP inactivity (presumably ignoring LCP > activity as well as other activity such as bridging) and then > restarting > IPCP on new activity to negotiate potentially new IPv4 addresses. KF: You are right. > > If I've guessed the topic correctly then: > > - I bet M.Townsley is right and that some PPP implementations > treat a broken IPCP state as reason to kill LCP and restart > the whole session. I afraid you would win the bet. Therefore we are thinking it is important to have this ID/RFC to discuss/inform that also implementations are needed and will exists that expect an standard compliant PPP session peer. > > - I think M.Townsley has understated the problems in changing IP > addresses on running systems. I bet most server programs will > not notice that their carefully constructed lists of TCP LISTEN > or UDP sockets are kaput because the local IP addresses changed. > > Of course, any and all existing TCP sessions break when > IP addresses > change. Besides apparently quiet ssh, ftp, and (secure-)telnet > sessions, and so forth, what about cached SMTP and HTTP > connections? > > What about firewalls? That is right. But we would configure an "IPCP idle timer" value (for releasing the IPv4 a= ddress) which is equal to the today used "PPP idle timer" value. So we are expecting no additional problems in this implementations. Nevertheless, when here problems occur we provide at least in the internet = access area IPv6 as an alternative. Applications, services etc. can using IPv6! > - How often is IPCP used today to allocate IP addresses? Isn't DHCP > often used even over PPP, especially for the consumer grade > Internet services that are most likely to be targets of a scheme > like this? We are addressing here PPP and IPCP. Of course a similar use case is possible with DHCP with or without PPP. Maybe here the DHCP/DHCPv6 implementations have here not so many dependenci= es as Mark has reported for IPCP/IPv6CP. I do not know if the description of the same scenario for DHCP/DHCPv6 is ne= eded. In any case I would see this in an additional ID and not in PPPEXT or INTAR= EA. > > - Would this scheme have more or fewer odd side effects and bad > boundary cases than the other schemes for dealing with > IPv4 address > shortages such as "large scale" or "carrier grade NAT"? Besides > application hiccups on changing addresses, what happens when all > of your users try to be active and so you temporary > can't allocate > addresses for all of them? Olaf's calculation of the saving effects is based on statistics. The calculation/configuration of the address pool size in the operational n= etwork Will be done as a result of practical experience that we have already today for IPv4-only PPP usage (usage in the past + trend + reserve). Maybe today the PPP session capacity is a bottleneck, which will change to the size of the IPv4 address pools. But also in a CGN scenario a calculation is needed to optimize the network configuration/usage and costs. An also in this case bottlenecks will exist. > > > > > We plan to come up with a 01 version of the I-D ... > > > > And of course we are also interested in your opinion if this > > > work should be done within the Intarea WG or if other WGs > (PPPEXT?) > > > may be more appropriate. > > Given the statement about the protocol itself not changing, how does > the PPPEXT working group or the IETF in general have standing to talk > about the issue or object to the proposal, whatever it is? As indended status of the ID we proposed in the version 00 "Informational". The final classification will be a result of the discussion within the IETF= . In any case we want to discuss the draft in the IETF community and considering the feedback from all experts in future versions. > Before writing an I-D that would merely try to convince > others to write > and test code, why not write and test some code before writing an I-D? > Successful tests with a few 100 real users would go a long way to > answering objections and generating interest in the idea. The idea > might sound good if 500 real Windows users behind Lunix-based cable > or DSL modems with the modest code implementing this idea have no > problems. (What's the name of the commodity consumer router that is > frequently and routinely hacked to support new things?) > > On the other hand, if it is impossible or impractical to write code, > get it installed in a small test environment (e.g. a few 100 users), > or get positive results from tests, then there's no need to write > an I-D or for anyone else or any working group to consider it. > > If there is no hope of getting a router vendors to implement the > idea before an RFC (not just an I-D) is published, then the idea > has no hope. Before we introducing anything in the network for customer we analyzing, specifying, prototyping, implementing, testing internal and testing external. Because of our experience with PPP we see no need for a customer field tria= l. Currently we or our vendors are in different phases of speciying, prototyping and implementing. But we are thinking that it is not useful to discuss within the IETF commun= ity any project or business plans. > By the time an RFC could be approved and published > and vendors respond, the IPv4 address shortage will have been solved > for years one way or another. We believe that several solutions will be needed to mitigate the IPv4 address shortage. As stated above we are thinking that this solution can be one of them that could also applicable for other ISPs. Because of the relativly few changes in the implementatipons/message flow we are thinking that we will have until end of this year a very stable draf= t. So there is no burden to implement and use and solve the IPv4 address short= age. The IETF ID/RFC processing could be done in parallel. IMHO it is important that on the end the description of the mechanism is av= ailable/published as an IETF Draft or finally RFC. > > Vernon Schryver vjs@rhyolite.com > From K.Fleischhauer@telekom.de Sun Jun 19 04:51:33 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B73711E8094; Sun, 19 Jun 2011 04:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chJy+ySX5iOl; Sun, 19 Jun 2011 04:51:32 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id AFA9711E8072; Sun, 19 Jun 2011 04:51:31 -0700 (PDT) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 19 Jun 2011 13:51:26 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.233]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Sun, 19 Jun 2011 13:51:26 +0200 From: To: Date: Sun, 19 Jun 2011 13:51:24 +0200 Thread-Topic: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? Thread-Index: Acws8ZmPzhgV3W/QTeOu234XVXc9pABgLCcg Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADE52C2B@HE111648.emea1.cds.t-internal.com> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com> <03348BD8-3004-4DE2-978A-0952765B5F86@townsley.net> In-Reply-To: <03348BD8-3004-4DE2-978A-0952765B5F86@townsley.net> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pppext@ietf.org, int-area@ietf.org Subject: Re: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 11:51:33 -0000 Dear Mark, See my comments inline. Best KARSTEN > -----Urspr=FCngliche Nachricht----- > Von: Mark Townsley [mailto:mark@townsley.net] > Gesendet: Freitag, 17. Juni 2011 15:22 > An: Fleischhauer, Karsten > Cc: int-area@ietf.org; pppext@ietf.org > Betreff: Re: [Int-area] IETF80 questions regarding "On demand > IPv4 address provisioning in Dual-Stack PPP deployment" - > Topic for WG? > > > Technically, this approach is naturally feasible as PPP was > designed back when short-lived connectivity was commonplace. > There is one crucial difference though in that you will be > exercising PPP stacks in a way that is not common by tearing > down and bringing up IPCP while not doing so with LCP. > According to all the RFCs this should work just fine, but my > intuition is that some PPP stacks will be forced into new > code paths that have never been exercised in this manner with > the expectation of it being the normal desired behaviour. You > can surely find a set of clients where this will work, but it > probably will not across the entire gamut of deployed PPP today. I share this fear but on the end this as also any other changes in the netw= ork needs testing before launch. On the network PPP peer side you could be "backward compatible". So also non draft "On demand IPv4 address provisioning in Dual-Stack PPP de= ployment" compatible PPP peers will work without problems. Maybe a problem can occur when a draft "On demand IPv4 address provisioning= in Dual-Stack PPP deployment" compliant PPP peers will appear on a network= where this support is missed. Maybe in this case an upgrade is needed. > > Applications may not be all that forgiving to IPv4 coming and > going either, e.g., I have a popular mail client that has > recently taken to crashing when I switch from wired to > wireless and get a different IP address in the process. Some > of the IM connections I keep up recover quickly to IP > changes, others do not. The IETF has a whole WG (DNA) > dedicated to this tricky behaviour of an IP address coming and > going - it's not always easy, in particular when the > link-layer is not giving your IP stack any up/down > notification, which I believe by definition is what your > proposal requires from the very start. In this case a "deactivation" of the feature on the HG would be useful. This could be done maybe due configuration or simply with sending IPv4 requ= ests within the "IPCP idle timer" value. But we would hope that these always-on applications will be move quickly to= IPv6. > > Finally, devices are moving towards a "cloud connected" mode > of operation. In IPv4, there is essentially no end-to-end > reach ability, so modern applications are moving toward > persistent, long-lived, connections in order to achieve this. > I suspect you'll see a noticeable uptick in reliance upon > such persistent, long-lived, IPv4 connections as Apple's Lion > and iOS 5 software is rolled out later this year. Both have > integration of the free "iCloud" services, and have replaced > the USB cord for device synchronization with a persistent > network connection. It's not just Apple though, the same > trend is forming across the industry. That should be considered in our efficiency calculation. As already mentioned we would recommend here the usage of IPv6. This is also valid for other update services (anti-virus, OS, email, etc.). I think the support of NAT444 as "alternative" would not simplify such apps= . > > So, my fear is that by the time you have built TDM into IPv4 > across your user base, it will have required at the very > least a grand testing effort and at the same time your users > may well have changed their behavior to make it unworkable > anyway. I as much as anyone would hope that all these new > persistent connections would run over IPv6 if available, but > that is of course the exception not the rule for the time > being as well. Our estimation of the saving effects is more or less conservative and consi= dering a rather small adaption of IPv6. We will introduce Dual-Stack in the first phase, the address saving in the = second phase. So the IPv6 content provider would have here a small advance to enable thei= r apps. Maybe other ISPs can initially implement the address saving feature (no rev= ision of the Dual-Stack implementation is needed). But these ISPs would be = benefit from the early mover. Surely beside the implementation of the draft also other ISP internal IPv4 = address efficiency measures would be useful und helpful to provide the cust= omer the best IP connectivity as possible. > > - Mark > > > On Jun 14, 2011, at 6:45 PM, > wrote: > > > Hi folks, > > > > right in time before the next IETF in Quebec, we would like > to come up again with our Internet Draft > > "On demand IPv4 address provisioning in Dual-Stack PPP deployment" > > in order to gather further feedback from the WG. > > During our presentation in Prague I got several remarks and > questions > > and from my understanding there has been some interest in > the approach we describe in this I-D. > > Regarding the questions I want to focus on the following > two and will try to answer them once more: > > > > - Use case: > > In general we see this mechanism applicable for all > Dual-Stack PPP network scenarios allthrough we focussed our > presentation for illustrative reasons on routed gateways that > may be provided by the Access Network provider. > > In principle as more IPv4 addresses can be saved, as more > services are IPv6 enabled > > (especially those which require always-on connectivity > (e.g. VoIP, mail, update services)) . > > The PPP protocol has not to be changed in order to achieve > the needed functionality - > > the described behaviour (of independently releasing and > > refreshing the IPv4 context within a Dual-Stack PPP session) > > is already inherently covered by the existing PPP spec and > also mentioned as requirements for > > CPEs (see RFC 6204 - WLL-3). > > > > - Efficiency of the mechanism: > > In principle we assume (with ongoing IPv6 deployment) that > it is possible to save > > after one year of roll-out of the described mechanism about 3%, > > after two years about 8%, > > and after three years up to 13% of the provisioned IPv4 addresses. > > After 8 years 70% of the IPv4 addresses can be "re-cycled" > according to our model calculations. > > (You will find more details here: > > > "http://www.ix-konferenz.de/getfoldat.php?vid=3D1638&t=3Dapplicati on/pdf&thema=3DEffizienzabsch=E4tzung" > > (please copy the whole text between the exclamation marks > in the address line of you browser).) > > > > > > We plan to come up with a 01 version of the I-D and would > that's why like to gather more feedback from the WG regarding > the possible open issues (e.g. what has to be described in > more detail, ), unanswered questions or any other useful > hints how to progress with this work/I-D. > > And of course we are also interested in your opinion if > this work should be done within the Intarea WG or if other > WGs (PPPEXT?) may be more appropriate. > > > > > > Thanks and kind regards > > > > KARSTEN Fleischhauer > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > > From vjs@calcite.rhyolite.com Sun Jun 19 08:45:55 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DFD111E80CA; Sun, 19 Jun 2011 08:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lg2+GvsRrBqN; Sun, 19 Jun 2011 08:45:54 -0700 (PDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [IPv6:2001:4978:230::3]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD1711E8070; Sun, 19 Jun 2011 08:45:54 -0700 (PDT) Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.14.4/8.14.4) with ESMTP id p5JFjmrv042970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) env-from ; Sun, 19 Jun 2011 15:45:48 GMT Received: (from vjs@localhost) by calcite.rhyolite.com (8.14.4/8.14.4/Submit) id p5JFjlWL042969; Sun, 19 Jun 2011 15:45:47 GMT Date: Sun, 19 Jun 2011 15:45:47 GMT From: Vernon Schryver Message-Id: <201106191545.p5JFjlWL042969@calcite.rhyolite.com> To: K.Fleischhauer@telekom.de In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADE52C2A@HE111648.emea1.cds.t-internal.com> X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist X-Mailman-Approved-At: Sun, 19 Jun 2011 11:23:15 -0700 Cc: pppext@ietf.org, int-area@ietf.org Subject: Re: [Int-area] [Pppext] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 15:45:55 -0000 > From: > To: > CC: , , > > My guess is that the topic is something about PPP peers killing their > > IPCP state machines after IP inactivity (presumably ignoring LCP > > activity as well as other activity such as bridging) and then > > restarting > > IPCP on new activity to negotiate potentially new IPv4 addresses. > > KF: You are right. That seems to contradict the later statement that the new IPCP idle timer would have the same value as existing LCP idle timers. > > - I think M.Townsley has understated the problems in changing IP > > addresses on running systems. I bet most server programs will > > Of course, any and all existing TCP sessions break when > > What about firewalls? > > That is right. > But we would configure an "IPCP idle timer" value (for releasing the IPv4 address) > which is equal to the today used "PPP idle timer" value. In that case, I wonder if I understand what is being proposed I think that LCP idle timers are generally reset by IP traffic. So an additional explicit IPCP idle timer would not be needed. See http://www.google.com/search?q=lcp+idle+timer > > - How often is IPCP used today to allocate IP addresses? Isn't DHCP > > often used even over PPP, especially for the consumer grade > We are addressing here PPP and IPCP. I think it is best to consider to entire systems. A PPP mechanism that would almost never be used because other standardized mechanism are and will be used to provide its facilities is inadmissable to a reasonable official standards process. > Of course a similar use case is possible with DHCP with or without PPP. It sounds as if the proposal is a recommendation that Internet services provides who lack IPv4 addresses configure things so that: - IPv4 addresses are not statically assigned on PPP links, - dynamic IPCP IPv4 address assignments do not endure PPP resets, especially those triggered by LCP idle timers, - DHCP lease times be shortened - the de facto standard DHCP features that try to give returning users the same IPv4 addresses be turned off Those ideas seem like common sense (al beit rather obvious) and don't unnecessarily violate layers or introduce distasteful IPCP options like certain proposals outside the PPPEXT working group. > In any case I would see this in an additional ID and not in PPPEXT or INTAREA. Since no point-to-point protocol changes are being proposed and contents of an ID would be obvious operational advice, I don't see a PPP RFC. Perhaps an informational RFC could be justified. It would be better than some informational I-Ds involving vendor-specific IPCP options. > > - Would this scheme have more or fewer odd side effects and bad > > boundary cases than the other schemes for dealing with > > shortages such as "large scale" or "carrier grade NAT"? Besides > Olaf's calculation of the saving effects is based on statistics. > The calculation/configuration of the address pool size in the operational network > Will be done as a result of practical experience that we have already > today for IPv4-only PPP usage (usage in the past + trend + reserve). > Maybe today the PPP session capacity is a bottleneck, > which will change to the size of the IPv4 address pools. > But also in a CGN scenario a calculation is needed to optimize > the network configuration/usage and costs. > An also in this case bottlenecks will exist. I do not see an answer to my question about how this proposal compares with schemes such as LSN or CGN. See http://www.google.com/search?q=IPv4+cgn+OR+lsn Perhaps your informational I-D could say something about that. See also http://www.google.com/search?q=ietf+IPv4+address+shortage+bcp and even http://www.google.com/search?q=ietf+IPv4+address+shortage+ppp > As indended status of the ID we proposed in the version 00 "Informational". I thought informational RFCs do not depend on the let, leave, or hindrance of IETF working groups. Vernon Schryver vjs@rhyolite.com From Olaf.Bonness@telekom.de Mon Jun 20 00:56:54 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CA611E8114; Mon, 20 Jun 2011 00:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROpE1BLqQtyA; Mon, 20 Jun 2011 00:56:53 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 40A6511E80F9; Mon, 20 Jun 2011 00:56:51 -0700 (PDT) Received: from he111527.emea1.cds.t-internal.com ([10.125.90.86]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 20 Jun 2011 09:56:36 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.158]) by HE111527.EMEA1.CDS.T-INTERNAL.COM ([2002:7cd:5a56::7cd:5a56]) with mapi; Mon, 20 Jun 2011 09:56:36 +0200 From: To: , Date: Mon, 20 Jun 2011 09:56:34 +0200 Thread-Topic: [Pppext] [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? Thread-Index: AcwumAHgi1pRnzWpQOKcZAsIRuAf9QAgzzKA Message-ID: References: <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADE52C2A@HE111648.emea1.cds.t-internal.com> <201106191545.p5JFjlWL042969@calcite.rhyolite.com> In-Reply-To: <201106191545.p5JFjlWL042969@calcite.rhyolite.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pppext@ietf.org, int-area@ietf.org Subject: Re: [Int-area] [Pppext] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 07:56:54 -0000 Hi folks, please find my comments inline. Kind regards Olaf > Im Auftrag von Vernon Schryver > Gesendet: Sonntag, 19. Juni 2011 17:46 > An: Fleischhauer, Karsten ... (Some lines deleted) > > > My guess is that the topic is something about PPP peers > killing their > > > IPCP state machines after IP inactivity (presumably ignoring LCP > > > activity as well as other activity such as bridging) and then > > > restarting > > > IPCP on new activity to negotiate potentially new IPv4 addresses. > > > > KF: You are right. > > That seems to contradict the later statement that the new IPCP idle > timer would have the same value as existing LCP idle timers. As far as I understand it Karsten tries to say the following: The IPCP session is released after an timeout interval that is comparable t= o the timeout used in _todays_ LCP implementations. (Thats why this IPCP r= elease will show the same effects to the IPv4 part of the user as todays PP= P release.) The LCP timeout is assumed to be longer and the LCP is usually kept alive b= ecause of the IPCPv6 or bridging or whatever. ... > In that case, I wonder if I understand what is being proposed I think > that LCP idle timers are generally reset by IP traffic. So > an additional > explicit IPCP idle timer would not be needed. See > http://www.google.com/search?q=3Dlcp+idle+timer Hopefully my 3 sentenses above answer this. (BTW it is IMHO not very useful to post Google search requests here. I woul= d prefer to have a real link to a dedicated source in order to find the rig= ht reference and to make sure that I do understand your point.) > > > - How often is IPCP used today to allocate IP addresses? Isn't DHC= P > > > often used even over PPP, especially for the consumer grade Amazingly often PPP is used for that within legacy networks especially if y= ou do not _want_ to implement / run DHCP because of several reasons. > > We are addressing here PPP and IPCP. > > I think it is best to consider to entire systems. A PPP mechanism > that would almost never be used because other standardized mechanism > are and will be used to provide its facilities is inadmissable to a > reasonable official standards process. The proposed mechanism in this I-D is described for scenarios where IPCP i= s used for IPv4 address provisioning in Dual-Stack PPP sessions. The idea i= tself may easily be extended to DHCP based scenarios, 3G and 4G networks - = but this is not part of the mentioned I-D. > It sounds as if the proposal is a recommendation that Internet services > provides who lack IPv4 addresses configure things so that: > - IPv4 addresses are not statically assigned on PPP links, > - dynamic IPCP IPv4 address assignments do not endure PPP resets, > especially those triggered by LCP idle timers, > - DHCP lease times be shortened > - the de facto standard DHCP features that try to give returning > users the same IPv4 addresses be turned off Where did you read these remarks regarding DHCP? > In any case I would see this in an additional ID and not in > PPPEXT or INTAREA. Hmmm additional I-D. Do you mean informational or individual? Or where is "= additional" > Since no point-to-point protocol changes are being proposed > and contents of an ID would be obvious operational advice, I don't see a = PPP RFC. > Perhaps an informational RFC could be justified. It would be better > than some informational I-Ds involving vendor-specific IPCP options. O.k. you are voting for informational. > I do not see an answer to my question about how this proposal compares > with schemes such as LSN or CGN. See > http://www.google.com/search?q=3DIPv4+cgn+OR+lsn > Perhaps your informational I-D could say something about that. Just another nice google search list :). Couly you be more specific what you mean with "compares"? Do you mean compa= rability in terms of efficiency? Regards Olaf > See also > http://www.google.com/search?q=3Dietf+IPv4+address+shortage+bcp > and even > http://www.google.com/search?q=3Dietf+IPv4+address+shortage+ppp :) > > As indended status of the ID we proposed in the version 00 > "Informational". > > I thought informational RFCs do not depend on the let, leave, or > hindrance of IETF working groups. > > > Vernon Schryver vjs@rhyolite.com > _______________________________________________ > Pppext mailing list > Pppext@ietf.org > https://www.ietf.org/mailman/listinfo/pppext > From dwing@cisco.com Tue Jun 21 14:55:12 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91BD21F84A8 for ; Tue, 21 Jun 2011 14:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.274 X-Spam-Level: X-Spam-Status: No, score=-110.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+VIa0yENP3Q for ; Tue, 21 Jun 2011 14:55:10 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 928F021F84A7 for ; Tue, 21 Jun 2011 14:55:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=7660; q=dns/txt; s=iport; t=1308693309; x=1309902909; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=lJhAHm7Z+JZVt0kurjBsG9mvCBcozI0BaUgo6NEBH5g=; b=Aq/SvukgwPE7Mx2vRkhOmwfkC54YUXylJIN2jDBV/+2nvfMMGB+Nacur ehwaUCBKIMo83Q7s/CnghNKJObv5OHjyyzs2bq1WaXkCxNvvEyaqksQDe 4nKyWIwc/741t8BWomi2qVNcFworOhx8ce5WwZ3RkOZloXy8UUUeFty7s o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoAAN8RAU6rRDoI/2dsb2JhbABUl22BZo0ud4hzoWSeIIYqBIcimmo X-IronPort-AV: E=Sophos;i="4.65,402,1304294400"; d="scan'208";a="382619060" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 21 Jun 2011 21:55:09 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5LLt9Au006219; Tue, 21 Jun 2011 21:55:09 GMT From: "Dan Wing" To: , References: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com> <007501cc2d4e$b78fb7d0$26af2770$@com> <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADE52C25@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADE52C25@HE111648.emea1.cds.t-internal.com> Date: Tue, 21 Jun 2011 14:55:08 -0700 Message-ID: <05e301cc305d$e3606960$aa213c20$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwqsoIK/oLnwxqOSdCrLK8g7sq3+wBybesAAFcKEqAAoUpAcA== Content-Language: en-us Subject: Re: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 21:55:12 -0000 > -----Original Message----- > From: K.Fleischhauer@telekom.de [mailto:K.Fleischhauer@telekom.de] > Sent: Saturday, June 18, 2011 10:17 AM > To: dwing@cisco.com; int-area@ietf.org > Subject: AW: [Int-area] IETF80 questions regarding "On demand IPv4 > address provisioning in Dual-Stack PPP deployment" - Topic for WG? >=20 >=20 > Dear Dan, >=20 > see my comments inline >=20 > Best >=20 > KARSTEN >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Dan Wing [mailto:dwing@cisco.com] > > Gesendet: Samstag, 18. Juni 2011 02:29 > > An: Fleischhauer, Karsten; int-area@ietf.org > > Betreff: RE: [Int-area] IETF80 questions regarding "On demand > > IPv4 address provisioning in Dual-Stack PPP deployment" - > > Topic for WG? > > > > This technique causes a round-trip delay when an IPv4 > > application starts up, due to the on-demand acquisition of an IPv4 > address. > The situation in many cases today is, that when "an IPv4 application > starts up" > the whole PPP session incl. IPCP has to be established. > In the ID scenario just IPCP has to be established, so I see not a > disadvantage. > Nevertheless this round-trip issue is only valid for the first packet > of > a "Dual-Stack cycle". >=20 > > This technique is useful in environments where there is no IPv4 > address sharing > > (that is, with publicly-routable IPv4 addresses). > I think it is also useful in a Home Network scenario with an routed HG > and NAT44@HG. >=20 > > This technique is useful when not all of > > the subscribers are needing IPv4 addresses (e.g., they are > > not connected to the Internet [powered off], or they are running > applications > > that only need to use IPv6). > Ack. And we will pushing the usage of IPv6 to support this scenario. >=20 > > This technique requires one publicly-routable > > IPv4 address for every IPv4 host that has an active IPv4 session > (which > > seems to have limited usefulness, considering the world has = exhausted > its > > IPv4 address space). > I think this will work also in a Home Network scenario with an routed > HG and NAT44@HG. >=20 > > This technique requires changing the host's IPv4 stack. > This is only valid for the PPP endpoint. > Our focus is the Home Network scenario with an routed HG and NAT44@HG. > The PPP endpoint is the HG. So just the HG and BNG/BRAS need to be > changed. >=20 > > IPv4 address sharing (with NAPT or with an A+P technique) avoids = that > > round-trip delay, and without changing the host's IPv4 stack. >=20 > As already mentioned above the round-trip issue is only valid for the > first packet of > a "Dual-Stack cycle". A CGN scenario would cause an additional round- > trip delay > For each IPv4 packet (NAT 44 processing within the carrier network + > Packet forwarding via the CGN which will increase the number of > hops/links). How is that "an additional round trip" delay?? Maybe you could share a network diagram or a message flow diagram (ladder diagram) explaining how CGN creates an additional round trip. > > Summary: this seems only useful for 3G/4G, where the host's > > IPv4 stack can be changed, > Our focus is the fixed network PPP access due BBF TR-178 respectively > WT-242. > But you are right for 3G/4G the general mechanism would also be > applicable. >=20 > > and will cause noticeable delays when users > > launch applications that need to use IPv4 (delay caused by acquiring > an address > > on demand), > We see the delay issue not so critically. > > > and will be ineffective at its intended goal (avoiding IPv4 > > address sharing) if "too many" users need IPv4 addresses (e.g., a > popular > > application is using IPv4 -- Skype, music streaming, video = streaming, > instant > > messaging server, imap/pop server, etc.). > Of course that can happen, when the application remain on IPv4-only. > But here I would expect much more problems when at least one NAT444 is > in the end-to-end path. So, after modifying the home gateway to do this, the IPv4 consumption will not go down -- each home gateway that has an IPv4 session will consume an IPv4 address. =20 What's the likely lifetime of such a solution, considering we have already exhausted IPv4 addresses? =20 -d >=20 >=20 > > -d > > > > > > > > > -----Original Message----- > > > From: int-area-bounces@ietf.org > > [mailto:int-area-bounces@ietf.org] On > > > Behalf Of K.Fleischhauer@telekom.de > > > Sent: Tuesday, June 14, 2011 9:46 AM > > > To: int-area@ietf.org > > > Subject: [Int-area] IETF80 questions regarding "On demand > > IPv4 address > > > provisioning in Dual-Stack PPP deployment" - Topic for WG? > > > > > > Hi folks, > > > > > > right in time before the next IETF in Quebec, we would like > > to come up > > > again with our Internet Draft > > > "On demand IPv4 address provisioning in Dual-Stack PPP deployment" > > > in order to gather further feedback from the WG. > > > During our presentation in Prague I got several remarks and > > questions > > > and from my understanding there has been some interest in > > the approach > > > we describe in this I-D. > > > Regarding the questions I want to focus on the following > > two and will > > > try to answer them once more: > > > > > > - Use case: > > > In general we see this mechanism applicable for all Dual-Stack PPP > > > network scenarios allthrough we focussed our presentation for > > > illustrative reasons on routed gateways that may be provided by = the > > > Access Network provider. > > > In principle as more IPv4 addresses can be saved, as more > > services are > > > IPv6 enabled > > > (especially those which require always-on connectivity (e.g. VoIP, > > > mail, update services)) . > > > The PPP protocol has not to be changed in order to achieve > > the needed > > > functionality - > > > the described behaviour (of independently releasing and > > > refreshing the IPv4 context within a Dual-Stack PPP session) > > > is already inherently covered by the existing PPP spec and also > > > mentioned as requirements for > > > CPEs (see RFC 6204 - WLL-3). > > > > > > - Efficiency of the mechanism: > > > In principle we assume (with ongoing IPv6 deployment) that it is > > > possible to save > > > after one year of roll-out of the described mechanism about 3%, > > > after two years about 8%, > > > and after three years up to 13% of the provisioned IPv4 addresses. > > > After 8 years 70% of the IPv4 addresses can be "re-cycled" > > according to > > > our model calculations. > > > (You will find more details here: > > > "http://www.ix- > > > > > konferenz.de/getfoldat.php?vid=3D1638&t=3Dapplication/pdf&thema=3DEf > fizienzab > > > sch=E4tzung" > > > (please copy the whole text between the exclamation marks in the > > > address line of you browser).) > > > > > > > > > We plan to come up with a 01 version of the I-D and would that's > why > > > like to gather more feedback from the WG regarding the possible > open > > > issues (e.g. what has to be described in more detail, ), = unanswered > > > questions or any other useful hints how to progress with > > this work/I-D. > > > And of course we are also interested in your opinion if this work > > > should be done within the Intarea WG or if other WGs > > (PPPEXT?) may be > > > more appropriate. > > > > > > > > > Thanks and kind regards > > > > > > KARSTEN Fleischhauer > > > _______________________________________________ > > > Int-area mailing list > > > Int-area@ietf.org > > > https://www.ietf.org/mailman/listinfo/int-area > > > > From julien.ietf@gmail.com Wed Jun 22 11:22:50 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 215C211E809C for ; Wed, 22 Jun 2011 11:22:50 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGrCS91sDxbn for ; Wed, 22 Jun 2011 11:22:49 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id BD63611E8082 for ; Wed, 22 Jun 2011 11:22:46 -0700 (PDT) Received: by bwz13 with SMTP id 13so1106136bwz.31 for ; Wed, 22 Jun 2011 11:22:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=cDr7wfC1tRgz2q3rwLSaeGBxwon9fqop1HijRSJAS7c=; b=gTZYSDtfpWryqdW98r6DAWMx7TOLuaBICJYiCOjlvhow4vb300yvfRI3jNqip0UwwI dzzeOb2ohGBHQhMWHNnds4Vw9NGWe/ShF3ovL1K9b4eKovA40/54wl0JqxI+AiP1GL6L +OHQpReaOVnALP5zwFA6jzvT0H6I5rKBwyEx8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=t7DE5qRfzCsWgRFHLA9PN+rauhXSjHQxYZn4YY5kB2ZFt1D9B1/sOw/ZT2X0+mUhcE w5e/yS2XpsVLaHXFqdKPR94MZchyQf6OKUVqzRDj8vyUpGmgZpL3bn9yJHsw2n64YQ4o Jja7yCqkyxNSFl+vYHNLLIpZZZjlQFagu4SJg= MIME-Version: 1.0 Received: by 10.204.40.80 with SMTP id j16mr486352bke.107.1308766963247; Wed, 22 Jun 2011 11:22:43 -0700 (PDT) Received: by 10.204.176.77 with HTTP; Wed, 22 Jun 2011 11:22:43 -0700 (PDT) Date: Wed, 22 Jun 2011 11:22:43 -0700 Message-ID: From: Julien Laganier To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: int-area@ietf.org Subject: [Int-area] Fwd: IPv4 ID update draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 18:22:50 -0000 Joe, Because we' re talking about updating a venerable protocol I want to make sure that we get the necessary level of review for this draft before we forward it to IESG for publication as proposed standard. I've asked a number of people to have a look at it, and below is the first review from Erik (Thanks!) --julien ---------- Forwarded message ---------- From: Erik Nordmark Date: Wed, Jun 22, 2011 at 8:49 AM Subject: Re: IPv4 ID update draft To: Julien Laganier On 6/22/11 8:17 AM, Julien Laganier wrote: > > Hi Erik, > > Have you read this draft of Joe: > > http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update-02 > > If so, do you think it is ready for publication? No, I haven't read it. I've sat through numerous presentations around the draft in the intarea WG. I did a quick read. I see text like =A0 This document attempts to address the security considerations =A0 associated with fragmentation in IPv4 [RFC4459]. which is confusing given that RFC 4459 talks about e.g., =A0 router-based =A0 fragment reassembly could easily lead to (reassembly) buffer memory =A0 exhaustion Clearly the id-update shouldn't claim to solve reassembly buffer memory exhaustion, hence I think the above text around the reference to RFC 4459 should be reworded. On network rewrites: Section 6.2 says =A0 For atomic datagrams, because the IPv4 ID field is ignored on =A0 receipt, it can be possible to rewrite the field. Rewriting can be =A0 useful to prevent use of the field as a covert channel, or to enable =A0 more efficient header compression. However, the IPv4 ID field needs =A0 to remain immutable when it is validated by higher layer protocols, =A0 such as IPsec. As a result: =A0 o =A0>> The IPv4 ID field of non-atomic datagrams, or protected atomic =A0 =A0 =A0datagrams MUST NOT change in transit; the IPv4 ID field of =A0 =A0 =A0unprotected atomic datagrams MAY be changed in transit. =A0 Protected datagrams are defined as those whose header fields are =A0 covered by integrity validation, such as IPsec AH [RFC4302]. Section 10 says: =A0 This document thus does not recommend whether atomic IPv4 =A0 datagrams should use nonchanging or changing IDs, but rather allows =A0 those IDs to be modified in transit (as per Sec. 6.2), which can be =A0 used to accommodate more efficient compression as desired. And section 11 says: =A0 When the IPv4 ID is ignored on receipt (e.g., for atomic datagrams), =A0 its value becomes unconstrained; that field then can more easily be =A0 used as a covert channel. For some atomic datagrams - notably those =A0 not protected by IPsec Authentication Header (AH) [RFC4302] - it is =A0 now possible, and may be desirable, to rewrite the IPv4 ID field to =A0 avoid its use as such a channel. I don't see any significant benefits in allowing in-transit modifications of the IP-ID (I'm not talking about the NAT case, which in essence re-originates a datagram with different addresses/ports), and I think we should be careful when tweaking this 20+ year old protocol. Thus I don't think we should allow for in-transit modifications of unprotected datagrams. =A0 Erik From touch@isi.edu Wed Jun 22 13:31:21 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774F721F84AA for ; Wed, 22 Jun 2011 13:31:21 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmIdImOw3VPq for ; Wed, 22 Jun 2011 13:31:20 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id C663C21F84A6 for ; Wed, 22 Jun 2011 13:31:20 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p5MKUDAF011156 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 22 Jun 2011 13:30:16 -0700 (PDT) Message-ID: <4E0250D5.5060701@isi.edu> Date: Wed, 22 Jun 2011 13:30:13 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Julien Laganier References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: int-area@ietf.org Subject: Re: [Int-area] Fwd: IPv4 ID update draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 20:31:21 -0000 Hi, all, To discuss some points below... On 6/22/2011 11:22 AM, Julien Laganier wrote: > Joe, > > Because we' re talking about updating a venerable protocol I want to > make sure that we get the necessary level of review for this draft > before we forward it to IESG for publication as proposed standard. > I've asked a number of people to have a look at it, and below is the > first review from Erik (Thanks!) > > --julien > > ---------- Forwarded message ---------- > From: Erik Nordmark > Date: Wed, Jun 22, 2011 at 8:49 AM > Subject: Re: IPv4 ID update draft > To: Julien Laganier > > > On 6/22/11 8:17 AM, Julien Laganier wrote: >> >> Hi Erik, >> >> Have you read this draft of Joe: >> >> http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update-02 >> >> If so, do you think it is ready for publication? > > No, I haven't read it. > I've sat through numerous presentations around the draft in the intarea WG. > > I did a quick read. > > I see text like > This document attempts to address the security considerations > associated with fragmentation in IPv4 [RFC4459]. > which is confusing given that RFC 4459 talks about e.g., > router-based > fragment reassembly could easily lead to (reassembly) buffer memory > exhaustion > > Clearly the id-update shouldn't claim to solve reassembly buffer > memory exhaustion, hence I think the above text around the reference > to RFC 4459 should be reworded. Will do. I have to look back to find the origin of that particular component... > On network rewrites: > > Section 6.2 says > For atomic datagrams, because the IPv4 ID field is ignored on > receipt, it can be possible to rewrite the field. Rewriting can be > useful to prevent use of the field as a covert channel, or to enable > more efficient header compression. However, the IPv4 ID field needs > to remain immutable when it is validated by higher layer protocols, > such as IPsec. As a result: > > o>> The IPv4 ID field of non-atomic datagrams, or protected atomic > datagrams MUST NOT change in transit; the IPv4 ID field of > unprotected atomic datagrams MAY be changed in transit. > > Protected datagrams are defined as those whose header fields are > covered by integrity validation, such as IPsec AH [RFC4302]. > > Section 10 says: > This document thus does not recommend whether atomic IPv4 > datagrams should use nonchanging or changing IDs, but rather allows > those IDs to be modified in transit (as per Sec. 6.2), which can be > used to accommodate more efficient compression as desired. > > > And section 11 says: > When the IPv4 ID is ignored on receipt (e.g., for atomic datagrams), > its value becomes unconstrained; that field then can more easily be > used as a covert channel. For some atomic datagrams - notably those > not protected by IPsec Authentication Header (AH) [RFC4302] - it is > now possible, and may be desirable, to rewrite the IPv4 ID field to > avoid its use as such a channel. > > I don't see any significant benefits in allowing in-transit > modifications of the IP-ID (I'm not talking about the NAT case, which > in essence re-originates a datagram with different addresses/ports), > and I think we should be careful when tweaking this 20+ year old > protocol. Thus I don't think we should allow for in-transit > modifications of unprotected datagrams. There's actually a very specific reason for allowing in-transit modification - to avoid the assumption that this field can now be used in atomic packets for other E2E messaging -- as others have recently proposed, e.g., in draft-briscoe-intarea-ipv4-id-reuse The goal is to make the ID field something the receiver must ignore, solely to avoid the (often ignored) requirement that the ID be unique within src/dst/prot tuple within 2MSL. IMO, we can't "require" the field to be immutable E2E unless it's protected (e.g., by IPsec or encapsulation and a checksum of some kind). That's the point of "allowing" it to change - which also means it can change out from under anyone who uses it anywhere in the net, which prevents it being used for new mechanisms. Given that context, do you think it's still important and/or feasible to prohibit in-transit mods? Joe > > Erik From julien.ietf@gmail.com Wed Jun 22 16:40:29 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D6E11E80BD for ; Wed, 22 Jun 2011 16:40:29 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24aB7UgkS-tG for ; Wed, 22 Jun 2011 16:40:28 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C429C11E80B3 for ; Wed, 22 Jun 2011 16:40:27 -0700 (PDT) Received: by bwz13 with SMTP id 13so1314346bwz.31 for ; Wed, 22 Jun 2011 16:40:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=md0RmygHVuOHpPvIQA6rFe+hzPaEPUwYRhQYd4g6Wls=; b=jKG0tZL9SDDkuJXPkcqZ5fpF5vEf4ZAP7uuZwXa7qxXg1U4pnnWniTWKoZjNeWFI/B 0ugKUkYQOHJQQMpU+OIjE+hofyN/IGSiPfTuLRJyo9ros8wPKQWFSmmRgARLs25eOmtE jVv16xiuJevHymAKk6OsJp9wFhzlzW3Dw8+0c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=uAYlZ0hLSopbtUEByYMWk8Sw8GS6Qq2oc1rmx6Ib40SHKdffVqzrNZkUDu0mN5IRRS A7vyHKNZcAfOklYkSscXXXsLmInx/rrA9hJfOvlxU3vGLAurvUIH9/pMfvr12HDbvQR+ mCGYX6i9x6le2D1J+AV448gtArJDJkZ2nSZHU= MIME-Version: 1.0 Received: by 10.204.3.196 with SMTP id 4mr218257bko.188.1308786026798; Wed, 22 Jun 2011 16:40:26 -0700 (PDT) Received: by 10.204.176.77 with HTTP; Wed, 22 Jun 2011 16:40:26 -0700 (PDT) In-Reply-To: <4E0250D5.5060701@isi.edu> References: <4E0250D5.5060701@isi.edu> Date: Wed, 22 Jun 2011 16:40:26 -0700 Message-ID: From: Julien Laganier To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: int-area@ietf.org Subject: Re: [Int-area] Fwd: IPv4 ID update draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 23:40:29 -0000 Hi Joe, On Wed, Jun 22, 2011 at 1:30 PM, Joe Touch wrote: > Hi, all, > > To discuss some points below... > > On 6/22/2011 11:22 AM, Julien Laganier wrote: >> >> Joe, >> >> Because we' re talking about updating a venerable protocol I want to >> make sure that we get the necessary level of review for this draft >> before we forward it to IESG for publication as proposed standard. >> I've asked a number of people to have a look at it, and below is the >> first review from Erik (Thanks!) >> >> --julien >> >> ---------- Forwarded message ---------- >> From: Erik Nordmark >> Date: Wed, Jun 22, 2011 at 8:49 AM >> Subject: Re: IPv4 ID update draft >> To: Julien Laganier >> >> >> On 6/22/11 8:17 AM, Julien Laganier wrote: >>> >>> Hi Erik, >>> >>> Have you read this draft of Joe: >>> >>> http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update-02 >>> >>> If so, do you think it is ready for publication? >> >> No, I haven't read it. >> I've sat through numerous presentations around the draft in the intarea >> WG. >> >> I did a quick read. >> >> I see text like >> =A0 This document attempts to address the security considerations >> =A0 associated with fragmentation in IPv4 [RFC4459]. >> which is confusing given that RFC 4459 talks about e.g., >> =A0 router-based >> =A0 fragment reassembly could easily lead to (reassembly) buffer memory >> =A0 exhaustion >> >> Clearly the id-update shouldn't claim to solve reassembly buffer >> memory exhaustion, hence I think the above text around the reference >> to RFC 4459 should be reworded. > > Will do. I have to look back to find the origin of that particular > component... Ok. >> On network rewrites: >> >> Section 6.2 says >> =A0 For atomic datagrams, because the IPv4 ID field is ignored on >> =A0 receipt, it can be possible to rewrite the field. Rewriting can be >> =A0 useful to prevent use of the field as a covert channel, or to enable >> =A0 more efficient header compression. However, the IPv4 ID field needs >> =A0 to remain immutable when it is validated by higher layer protocols, >> =A0 such as IPsec. As a result: >> >> =A0 o>> =A0The IPv4 ID field of non-atomic datagrams, or protected atomi= c >> =A0 =A0 =A0datagrams MUST NOT change in transit; the IPv4 ID field of >> =A0 =A0 =A0unprotected atomic datagrams MAY be changed in transit. >> >> =A0 Protected datagrams are defined as those whose header fields are >> =A0 covered by integrity validation, such as IPsec AH [RFC4302]. >> >> Section 10 says: >> =A0 This document thus does not recommend whether atomic IPv4 >> =A0 datagrams should use nonchanging or changing IDs, but rather allows >> =A0 those IDs to be modified in transit (as per Sec. 6.2), which can be >> =A0 used to accommodate more efficient compression as desired. >> >> >> And section 11 says: >> =A0 When the IPv4 ID is ignored on receipt (e.g., for atomic datagrams), >> =A0 its value becomes unconstrained; that field then can more easily be >> =A0 used as a covert channel. For some atomic datagrams - notably those >> =A0 not protected by IPsec Authentication Header (AH) [RFC4302] - it is >> =A0 now possible, and may be desirable, to rewrite the IPv4 ID field to >> =A0 avoid its use as such a channel. >> >> I don't see any significant benefits in allowing in-transit >> modifications of the IP-ID (I'm not talking about the NAT case, which >> in essence re-originates a datagram with different addresses/ports), >> and I think we should be careful when tweaking this 20+ year old >> protocol. Thus I don't think we should allow for in-transit >> modifications of unprotected datagrams. > > There's actually a very specific reason for allowing in-transit modificat= ion > - to avoid the assumption that this field can now be used in atomic packe= ts > for other E2E messaging -- as others have recently proposed, e.g., in > draft-briscoe-intarea-ipv4-id-reuse I don't think that goal was in-scope for this I-D. Also, since NAT may rewrite the I-D, it seems that the I-D can't be used for that reliably, so maybe the I-D can mention that NATs may rewrites IDs - rather than give blanket permission to intermediaries to rewrite the IDs in unprotected atomic packets. > The goal is to make the ID field something the receiver must ignore, sole= ly > to avoid the (often ignored) requirement that the ID be unique within > src/dst/prot tuple within 2MSL. IMHO the proper way to make the receier ignore the ID is to say MUST ignore, rather than allowing intermediaries to rewrite it.... > IMO, we can't "require" the field to be immutable E2E unless it's protect= ed > (e.g., by IPsec or encapsulation and a checksum of some kind). That's the > point of "allowing" it to change - which also means it can change out fro= m > under anyone who uses it anywhere in the net, which prevents it being use= d > for new mechanisms. Not requiring the field to be immutable doesn' t mean we have to allow it to change... > Given that context, do you think it's still important and/or feasible to > prohibit in-transit mods? It' s not really about prohibiting in-transit mods, since NATs might do that already. It is about not allowing it per this specification. You can stil mention that NATs do rewrite it... --julien From touch@isi.edu Wed Jun 22 17:09:08 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6001B11E809C for ; Wed, 22 Jun 2011 17:09:08 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTvP-SiO1a2P for ; Wed, 22 Jun 2011 17:09:07 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE0F11E8098 for ; Wed, 22 Jun 2011 17:09:07 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p5N08q7v025350 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 22 Jun 2011 17:08:52 -0700 (PDT) Message-ID: <4E028414.8030700@isi.edu> Date: Wed, 22 Jun 2011 17:08:52 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Julien Laganier References: <4E0250D5.5060701@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: int-area@ietf.org Subject: Re: [Int-area] Fwd: IPv4 ID update draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 00:09:08 -0000 On 6/22/2011 4:40 PM, Julien Laganier wrote: > Hi Joe, > > On Wed, Jun 22, 2011 at 1:30 PM, Joe Touch wrote: >> Hi, all, >> >> To discuss some points below... >> >> On 6/22/2011 11:22 AM, Julien Laganier wrote: >>> >>> Joe, >>> >>> Because we' re talking about updating a venerable protocol I want to >>> make sure that we get the necessary level of review for this draft >>> before we forward it to IESG for publication as proposed standard. >>> I've asked a number of people to have a look at it, and below is the >>> first review from Erik (Thanks!) >>> >>> --julien >>> >>> ---------- Forwarded message ---------- >>> From: Erik Nordmark >>> Date: Wed, Jun 22, 2011 at 8:49 AM >>> Subject: Re: IPv4 ID update draft >>> To: Julien Laganier >>> >>> >>> On 6/22/11 8:17 AM, Julien Laganier wrote: >>>> >>>> Hi Erik, >>>> >>>> Have you read this draft of Joe: >>>> >>>> http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update-02 >>>> >>>> If so, do you think it is ready for publication? >>> >>> No, I haven't read it. >>> I've sat through numerous presentations around the draft in the intarea >>> WG. >>> >>> I did a quick read. >>> >>> I see text like >>> This document attempts to address the security considerations >>> associated with fragmentation in IPv4 [RFC4459]. >>> which is confusing given that RFC 4459 talks about e.g., >>> router-based >>> fragment reassembly could easily lead to (reassembly) buffer memory >>> exhaustion >>> >>> Clearly the id-update shouldn't claim to solve reassembly buffer >>> memory exhaustion, hence I think the above text around the reference >>> to RFC 4459 should be reworded. >> >> Will do. I have to look back to find the origin of that particular >> component... > > Ok. > >>> On network rewrites: >>> >>> Section 6.2 says >>> For atomic datagrams, because the IPv4 ID field is ignored on >>> receipt, it can be possible to rewrite the field. Rewriting can be >>> useful to prevent use of the field as a covert channel, or to enable >>> more efficient header compression. However, the IPv4 ID field needs >>> to remain immutable when it is validated by higher layer protocols, >>> such as IPsec. As a result: >>> >>> o>> The IPv4 ID field of non-atomic datagrams, or protected atomic >>> datagrams MUST NOT change in transit; the IPv4 ID field of >>> unprotected atomic datagrams MAY be changed in transit. >>> >>> Protected datagrams are defined as those whose header fields are >>> covered by integrity validation, such as IPsec AH [RFC4302]. >>> >>> Section 10 says: >>> This document thus does not recommend whether atomic IPv4 >>> datagrams should use nonchanging or changing IDs, but rather allows >>> those IDs to be modified in transit (as per Sec. 6.2), which can be >>> used to accommodate more efficient compression as desired. >>> >>> >>> And section 11 says: >>> When the IPv4 ID is ignored on receipt (e.g., for atomic datagrams), >>> its value becomes unconstrained; that field then can more easily be >>> used as a covert channel. For some atomic datagrams - notably those >>> not protected by IPsec Authentication Header (AH) [RFC4302] - it is >>> now possible, and may be desirable, to rewrite the IPv4 ID field to >>> avoid its use as such a channel. >>> >>> I don't see any significant benefits in allowing in-transit >>> modifications of the IP-ID (I'm not talking about the NAT case, which >>> in essence re-originates a datagram with different addresses/ports), >>> and I think we should be careful when tweaking this 20+ year old >>> protocol. Thus I don't think we should allow for in-transit >>> modifications of unprotected datagrams. >> >> There's actually a very specific reason for allowing in-transit modification >> - to avoid the assumption that this field can now be used in atomic packets >> for other E2E messaging -- as others have recently proposed, e.g., in >> draft-briscoe-intarea-ipv4-id-reuse > > I don't think that goal was in-scope for this I-D. This point is mostly unchanged from its original discussion in the pre-WG version of the I-D, FWIW. > Also, since NAT may rewrite the I-D, it seems that the I-D can't be > used for that reliably, so maybe the I-D can mention that NATs may > rewrites IDs - rather than give blanket permission to intermediaries > to rewrite the IDs in unprotected atomic packets. If we don't give blanket permission to change the ID in unprotected atomic packets, isn't that requiring them to be immutable? I.e., we agree that we need to NOT assume that IDs of atomic packets are immutable; isn't that the same as allowing them to be modified in transit? Is there any other way to say "not immutable" than: - an intermediate node MAY rewrite the ID of an atomic packet NATs rewrite src or dst addresses, but also (technically) need to rewrite IDs to be correct w.r.t. current RFC 791 rules - but they don't. I'm not clear that whether a NAT can/does rewrite an ID is useful towards this point. >> The goal is to make the ID field something the receiver must ignore, solely >> to avoid the (often ignored) requirement that the ID be unique within >> src/dst/prot tuple within 2MSL. > > IMHO the proper way to make the receier ignore the ID is to say MUST > ignore, rather than allowing intermediaries to rewrite it.... > >> IMO, we can't "require" the field to be immutable E2E unless it's protected >> (e.g., by IPsec or encapsulation and a checksum of some kind). That's the >> point of "allowing" it to change - which also means it can change out from >> under anyone who uses it anywhere in the net, which prevents it being used >> for new mechanisms. > > Not requiring the field to be immutable doesn' t mean we have to allow > it to change... See above (I.e., I can't see how it doesn't); if you can find a way to express that as a requirement, I'm game. >> Given that context, do you think it's still important and/or feasible to >> prohibit in-transit mods? > > It' s not really about prohibiting in-transit mods, since NATs might > do that already. It is about not allowing it per this specification. > You can stil mention that NATs do rewrite it... Well that would kill the entire discussion on header compression. That's fine if we want to omit that. but if we do say that "ID is not immutable in atomic packets", that opens the door to a very useful optimization for compression that ought to be included IMO. Joe From julien.ietf@gmail.com Wed Jun 22 18:34:27 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB09911E808F for ; Wed, 22 Jun 2011 18:34:27 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqteTYtu2sHJ for ; Wed, 22 Jun 2011 18:34:26 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 40C2411E8080 for ; Wed, 22 Jun 2011 18:34:26 -0700 (PDT) Received: by bwz13 with SMTP id 13so1373041bwz.31 for ; Wed, 22 Jun 2011 18:34:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FZVS9SwaW01llmD3K6Fv4hCOS4Bb0NU3HxBYWKFjhGM=; b=PrqcHgqYQEYrBbZ9qSwTllrRVGJZ6X2I82a77uTMD7aiy9ak8AQr5HT53Te9xoJa7J PIyy558nvaxTbXXcdZtKYqYQ1UjFj7e+/rQBmkXBPBAYDREeUbsFnebMHWFUXD/iQ2he BlsjWyo/83UTSRfWXbvwmshIRNaUFC0bsktF4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qvBBzfVr9AfiZvUyOdsimFVm5JRyl1Op3Q7BXl/BR8qiiJaGudj5Ts62Vc5CcAgXXn TAVBwA58ssmkfjQLjYHiT71xHS4kd3l22m5arsF0cLvQW/B5ibEGpGDqgdvLOHqKRcBV AVYBgr1OD0pfRz8VrwEKNjKkdkU7qDArnnJAA= MIME-Version: 1.0 Received: by 10.204.40.80 with SMTP id j16mr313689bke.107.1308792865273; Wed, 22 Jun 2011 18:34:25 -0700 (PDT) Received: by 10.204.176.77 with HTTP; Wed, 22 Jun 2011 18:34:25 -0700 (PDT) In-Reply-To: <4E028414.8030700@isi.edu> References: <4E0250D5.5060701@isi.edu> <4E028414.8030700@isi.edu> Date: Wed, 22 Jun 2011 18:34:25 -0700 Message-ID: From: Julien Laganier To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: int-area@ietf.org Subject: Re: [Int-area] Fwd: IPv4 ID update draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 01:34:28 -0000 Joe, Cutting thru a bit: On Wed, Jun 22, 2011 at 5:08 PM, Joe Touch wrote: > > > On 6/22/2011 4:40 PM, Julien Laganier wrote: >> >> Hi Joe, >> >> On Wed, Jun 22, 2011 at 1:30 PM, Joe Touch =A0wrote: >>> >>> Hi, all, >>> >>> To discuss some points below... >>> >>> On 6/22/2011 11:22 AM, Julien Laganier wrote: >>>> >>>> Joe, >>>> >>>> Because we' re talking about updating a venerable protocol I want to >>>> make sure that we get the necessary level of review for this draft >>>> before we forward it to IESG for publication as proposed standard. >>>> I've asked a number of people to have a look at it, and below is the >>>> first review from Erik (Thanks!) >>>> >>>> --julien >>>> >>>> ---------- Forwarded message ---------- >>>> From: Erik Nordmark >>>> Date: Wed, Jun 22, 2011 at 8:49 AM >>>> Subject: Re: IPv4 ID update draft >>>> To: Julien Laganier >>>> >>>> >>>> On 6/22/11 8:17 AM, Julien Laganier wrote: >>>>> >>>>> Hi Erik, >>>>> >>>>> Have you read this draft of Joe: >>>>> >>>>> http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update-02 >>>>> >>>>> If so, do you think it is ready for publication? >>>> >>>> No, I haven't read it. >>>> I've sat through numerous presentations around the draft in the intare= a >>>> WG. >>>> >>>> I did a quick read. >>>> >>>> I see text like >>>> =A0 This document attempts to address the security considerations >>>> =A0 associated with fragmentation in IPv4 [RFC4459]. >>>> which is confusing given that RFC 4459 talks about e.g., >>>> =A0 router-based >>>> =A0 fragment reassembly could easily lead to (reassembly) buffer memor= y >>>> =A0 exhaustion >>>> >>>> Clearly the id-update shouldn't claim to solve reassembly buffer >>>> memory exhaustion, hence I think the above text around the reference >>>> to RFC 4459 should be reworded. >>> >>> Will do. I have to look back to find the origin of that particular >>> component... >> >> Ok. >> >>>> On network rewrites: >>>> >>>> Section 6.2 says >>>> =A0 For atomic datagrams, because the IPv4 ID field is ignored on >>>> =A0 receipt, it can be possible to rewrite the field. Rewriting can be >>>> =A0 useful to prevent use of the field as a covert channel, or to enab= le >>>> =A0 more efficient header compression. However, the IPv4 ID field need= s >>>> =A0 to remain immutable when it is validated by higher layer protocols= , >>>> =A0 such as IPsec. As a result: >>>> >>>> =A0 o>> =A0 =A0The IPv4 ID field of non-atomic datagrams, or protected= atomic >>>> =A0 =A0 =A0datagrams MUST NOT change in transit; the IPv4 ID field of >>>> =A0 =A0 =A0unprotected atomic datagrams MAY be changed in transit. >>>> >>>> =A0 Protected datagrams are defined as those whose header fields are >>>> =A0 covered by integrity validation, such as IPsec AH [RFC4302]. >>>> >>>> Section 10 says: >>>> =A0 This document thus does not recommend whether atomic IPv4 >>>> =A0 datagrams should use nonchanging or changing IDs, but rather allow= s >>>> =A0 those IDs to be modified in transit (as per Sec. 6.2), which can b= e >>>> =A0 used to accommodate more efficient compression as desired. >>>> >>>> >>>> And section 11 says: >>>> =A0 When the IPv4 ID is ignored on receipt (e.g., for atomic datagrams= ), >>>> =A0 its value becomes unconstrained; that field then can more easily b= e >>>> =A0 used as a covert channel. For some atomic datagrams - notably thos= e >>>> =A0 not protected by IPsec Authentication Header (AH) [RFC4302] - it i= s >>>> =A0 now possible, and may be desirable, to rewrite the IPv4 ID field t= o >>>> =A0 avoid its use as such a channel. >>>> >>>> I don't see any significant benefits in allowing in-transit >>>> modifications of the IP-ID (I'm not talking about the NAT case, which >>>> in essence re-originates a datagram with different addresses/ports), >>>> and I think we should be careful when tweaking this 20+ year old >>>> protocol. Thus I don't think we should allow for in-transit >>>> modifications of unprotected datagrams. >>> >>> There's actually a very specific reason for allowing in-transit >>> modification >>> - to avoid the assumption that this field can now be used in atomic >>> packets >>> for other E2E messaging -- as others have recently proposed, e.g., in >>> draft-briscoe-intarea-ipv4-id-reuse >> >> I don't think that goal was in-scope for this I-D. > > This point is mostly unchanged from its original discussion in the pre-WG > version of the I-D, FWIW. > >> Also, since NAT may rewrite the I-D, it seems that the I-D can't be >> used for that reliably, so maybe the I-D can mention that NATs may >> rewrites IDs - rather than give blanket permission to intermediaries >> to rewrite the IDs in unprotected atomic packets. > > If we don't give blanket permission to change the ID in unprotected atomi= c > packets, isn't that requiring them to be immutable? > > I.e., we agree that we need to NOT assume that IDs of atomic packets are > immutable; isn't that the same as allowing them to be modified in transit= ? > Is there any other way to say "not immutable" than: > > =A0 =A0 =A0 =A0- an intermediate node MAY rewrite the ID of an atomic pac= ket It seems to me that NOT assuming that IDs of atomic packets are immutable is adequately captured by o >> All devices that examine IPv4 headers MUST ignore the IPv4 ID field of atomic datagrams. no? > NATs rewrite src or dst addresses, but also (technically) need to rewrite > IDs to be correct w.r.t. current RFC 791 rules - but they don't. I'm not > clear that whether a NAT can/does rewrite an ID is useful towards this > point. > >>> The goal is to make the ID field something the receiver must ignore, >>> solely >>> to avoid the (often ignored) requirement that the ID be unique within >>> src/dst/prot tuple within 2MSL. >> >> IMHO the proper way to make the receier ignore the ID is to say MUST >> ignore, rather than allowing intermediaries to rewrite it.... >> >>> IMO, we can't "require" the field to be immutable E2E unless it's >>> protected >>> (e.g., by IPsec or encapsulation and a checksum of some kind). That's t= he >>> point of "allowing" it to change - which also means it can change out >>> from >>> under anyone who uses it anywhere in the net, which prevents it being >>> used >>> for new mechanisms. >> >> Not requiring the field to be immutable doesn' t mean we have to allow >> it to change... > > See above (I.e., I can't see how it doesn't); if you can find a way to > express that as a requirement, I'm game. We don' t require the field to be immutable by making the mutability properties of the field transparent to the receiver that ignores this field in atomic packets... >>> Given that context, do you think it's still important and/or feasible t= o >>> prohibit in-transit mods? >> >> It' s not really about prohibiting in-transit mods, since NATs might >> do that already. It is about not allowing it per this specification. >> You can stil mention that NATs do rewrite it... > > Well that would kill the entire discussion on header compression. That's > fine if we want to omit that. but if we do say that "ID is not immutable = in > atomic packets", that opens the door to a very useful optimization for > compression that ought to be included IMO. I do not think that this draft should update a 20 years old protocol specification with the goal of opening doors to optimization of header compression for that same protocol. I _think_ it was also the sense of Erik's message. --julien From touch@isi.edu Thu Jun 23 11:18:08 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86499E8055 for ; Thu, 23 Jun 2011 11:18:08 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4xNFN-4dvqY for ; Thu, 23 Jun 2011 11:18:08 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 3356D9E8050 for ; Thu, 23 Jun 2011 11:18:08 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p5NIHq9k006024 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 23 Jun 2011 11:17:52 -0700 (PDT) Message-ID: <4E038350.60107@isi.edu> Date: Thu, 23 Jun 2011 11:17:52 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Julien Laganier References: <4E0250D5.5060701@isi.edu> <4E028414.8030700@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: int-area@ietf.org Subject: Re: [Int-area] Fwd: IPv4 ID update draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 18:18:09 -0000 Hi, Julien, On 6/22/2011 6:34 PM, Julien Laganier wrote: > Joe, > > Cutting thru a bit: ... >> I.e., we agree that we need to NOT assume that IDs of atomic packets are >> immutable; isn't that the same as allowing them to be modified in transit? >> Is there any other way to say "not immutable" than: >> >> - an intermediate node MAY rewrite the ID of an atomic packet > > It seems to me that NOT assuming that IDs of atomic packets are > immutable is adequately captured by > > o>> All devices that examine IPv4 headers MUST ignore the IPv4 ID > field of atomic datagrams. Let's say someone comes up with a crypto mechanism that isn't IPsec and isn't encapsulation, but a new IP option (IPsec++, for lack of a better description). Let's say that this new IPsec++ creates a hash that includes the ID field. We'd need to assume that such a mod would violate the above requirement - since it is clearly not "ignoring" that field. Then again, Bob Briscoe's doc would also violate the above requirement as well, since it clearly is examining the field. If that's sufficient, we can use just that. However, I'd note that the *current* use of the ID field does not require that it be immutable. E.g., the field is currently required unique within a src/dst/proto/ID tuple within 2MSL. There are two ways to accomplish that: - enforce uniqueness at the source and assume immutability in-transit - allow mutability in-transit so long as all such changes are coordinated to ensure that once the packets (fragmented or not) arrive at the receiver they follow the uniqueness rule So, technically, if they're ignored, they're mutable, IMO - even if we don't say so. My concern is that mutability is something people *will* disagree on, and that this doc needs to clarify that issue. The obvious clarification is: - if ATOMIC and not protected, then mutable (and ignored) - if not ATOMIC or protected (or both), then non-mutable ... > We don' t require the field to be immutable by making the mutability > properties of the field transparent to the receiver that ignores this > field in atomic packets... I agree, but I'm much more comfortable stating this explicitly if that's where the requirements end up pointing. I've found that derived requirements are not always derived consistently ;-) I.e., if this is a consequence anyway, is there a good reason not to state it? (see below about compression, though) >>>> Given that context, do you think it's still important and/or feasible to >>>> prohibit in-transit mods? >>> >>> It' s not really about prohibiting in-transit mods, since NATs might >>> do that already. It is about not allowing it per this specification. >>> You can stil mention that NATs do rewrite it... >> >> Well that would kill the entire discussion on header compression. That's >> fine if we want to omit that. but if we do say that "ID is not immutable in >> atomic packets", that opens the door to a very useful optimization for >> compression that ought to be included IMO. > > I do not think that this draft should update a 20 years old protocol > specification with the goal of opening doors to optimization of header > compression for that same protocol. I _think_ it was also the sense of > Erik's message. I agree with that - the sole point of this is NOT to enable header compression. It's just the indirect result of "receiver MUST ignore" for atomic unprotected packets as above. However, the impact of these changes on the current header compression algs is useful to discuss, and if it enables an existing mode of compression we should note that (perhaps not encourage changing the ID solely for that purpose, though - let someone else propose that). Would that work? Joe From julien.ietf@gmail.com Thu Jun 23 13:08:07 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919F211E80AC for ; Thu, 23 Jun 2011 13:08:07 -0700 (PDT) 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.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zQMX27t2ueQ for ; Thu, 23 Jun 2011 13:08:06 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 47F4211E8072 for ; Thu, 23 Jun 2011 13:08:06 -0700 (PDT) Received: by bwz13 with SMTP id 13so2102922bwz.31 for ; Thu, 23 Jun 2011 13:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Y5st31lCIxydI3rReembclq2qj6nNncelqidX7e0w2o=; b=eC31ZSGeNiAAHee8EefYOtzHg7C2zPipiCuGswpFi04m31/Hef5XM0uC0ne55ECGpD n6r86ueMhqnDu3/3nShojHPRmChJxwcLn2ZYaEIcjVo3DyhWWyeDVy3Mtoex3RImkqDh NYgiywFG3a+zK4PU7dpBd/TsYnkmPbBYcbOJI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=gl8ynpTDFX9zOe0C7QlQtHk1YYipX8YP9fss0QzFkd6UIpdX7dc2XzXFsga7NnGEVw VfoWSXAEJPN4BsE48bmffQW1LF98EkwMNhd2Cby0jnZM/Ng9pl6jvHEcHWPNa4H3LQha YChDdAKU9TUrdacTQbCC9ZLO/+yWaMa4vR35w= MIME-Version: 1.0 Received: by 10.204.40.80 with SMTP id j16mr1275073bke.107.1308859685080; Thu, 23 Jun 2011 13:08:05 -0700 (PDT) Received: by 10.204.176.77 with HTTP; Thu, 23 Jun 2011 13:08:05 -0700 (PDT) In-Reply-To: <4E038350.60107@isi.edu> References: <4E0250D5.5060701@isi.edu> <4E028414.8030700@isi.edu> <4E038350.60107@isi.edu> Date: Thu, 23 Jun 2011 13:08:05 -0700 Message-ID: From: Julien Laganier To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: int-area@ietf.org Subject: Re: [Int-area] Fwd: IPv4 ID update draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 20:08:07 -0000 Hi Joe, On Thu, Jun 23, 2011 at 11:17 AM, Joe Touch wrote: > Hi, Julien, > > On 6/22/2011 6:34 PM, Julien Laganier wrote: >> >> Joe, >> >> Cutting thru a bit: > > ... >>> >>> I.e., we agree that we need to NOT assume that IDs of atomic packets ar= e >>> immutable; isn't that the same as allowing them to be modified in >>> transit? >>> Is there any other way to say "not immutable" than: >>> >>> =A0 =A0 =A0 =A0- an intermediate node MAY rewrite the ID of an atomic p= acket >> >> It seems to me that NOT assuming that IDs of atomic packets are >> immutable is adequately captured by >> >> =A0 =A0o>> =A0All devices that examine IPv4 headers MUST ignore the IPv4= ID >> =A0 =A0 =A0 field of atomic datagrams. > > Let's say someone comes up with a crypto mechanism that isn't IPsec and > isn't encapsulation, but a new IP option (IPsec++, for lack of a better > description). Let's say that this new IPsec++ creates a hash that include= s > the ID field. > > We'd need to assume that such a mod would violate the above requirement - > since it is clearly not "ignoring" that field. I am a bit confused... Are you arguing against the above requirement? It isn't from me and is already in the draft... > Then again, Bob Briscoe's doc would also violate the above requirement as > well, since it clearly is examining the field. Yes, and to the extent that we have consensus to update 791with the above requirements it would be Bob's doc's issue... > If that's sufficient, we can use just that. However, I'd note that the > *current* use of the ID field does not require that it be immutable. ... neither does the above requirement. > E.g., the field is currently required unique within a src/dst/proto/ID tu= ple > within 2MSL. There are two ways to accomplish that: > > =A0 =A0 =A0 =A0- enforce uniqueness at the source and assume immutability > =A0 =A0 =A0 =A0in-transit > > =A0 =A0 =A0 =A0- allow mutability in-transit so long as all such changes = are > =A0 =A0 =A0 =A0coordinated to ensure that once the packets (fragmented or= not) > =A0 =A0 =A0 =A0arrive at the receiver they follow the uniqueness rule The latter being unenforceable given that in-transit packets might not all get along the same path, thus you're left with the former, no? > So, technically, if they're ignored, they're mutable, IMO - even if we do= n't > say so. Technically, if they're ignored, they're ignored. It would follow that there would be no problem caused by a receiving entity assuming the ID is unique, neither if there existed an intermediary node that modified the ID in transit. That however is different from our specification authorizing intermediate node to modify the ID in transit... > My concern is that mutability is something people *will* disagree on, and > that this doc needs to clarify that issue. The obvious clarification is: > =A0 =A0 =A0 =A0- if ATOMIC and not protected, then mutable (and ignored) > =A0 =A0 =A0 =A0- if not ATOMIC or protected (or both), then non-mutable And by taking no stance on the mutability of IDs in atomic packets people would not have to agree or disagree, intermediary nodes wouldn't feel it's OK to change the ID, yet the requirement that the field be ignored on the receiving end would prevent implementations to rely on the supposed uniqueness of the ID, which I thought was out intent... >> We don' t require the field to be immutable by making the mutability >> properties of the field transparent to the receiver that ignores this >> field in atomic packets... > > I agree, but I'm much more comfortable stating this explicitly if that's > where the requirements end up pointing. I've found that derived requireme= nts > are not always derived consistently ;-) Good that you agree. It also appears that some people (including, but not limited to Erik, myself, and Jari, if I am not mistaken) are much more comfortable not changing IPv4 properties unless we have to, e.g., there's potential harm. > I.e., if this is a consequence anyway, is there a good reason not to stat= e > it? (see below about compression, though) See above. There might be things that breaks when the ID of atomic packets is changed by intermediary nodes. Thus we don't want to authorize change of ID in atomic packets. >>>>> Given that context, do you think it's still important and/or feasible= to >>>>> prohibit in-transit mods? >>>> >>>> It' s not really about prohibiting in-transit mods, since NATs might >>>> do that already. It is about not allowing it per this specification. >>>> You can stil mention that NATs do rewrite it... >>> >>> Well that would kill the entire discussion on header compression. That'= s >>> fine if we want to omit that. but if we do say that "ID is not immutabl= e >>> in >>> atomic packets", that opens the door to a very useful optimization for >>> compression that ought to be included IMO. >> >> I do not think that this draft should update a 20 years old protocol >> specification with the goal of opening doors to optimization of header >> compression for that same protocol. I _think_ it was also the sense of >> Erik's message. > > I agree with that - the sole point of this is NOT to enable header > compression. It's just the indirect result of "receiver MUST ignore" for > atomic unprotected packets as above. No. Receiver ignoring the ID in atomic packets doen't result in the ID being mutable. Receiver ignoring the ID in atomic packets results in the consequences of the ID being mutable being benign -- in nodes that implement the recommendation. Thus it's not a valid reason to allow the ID to be mutable -- because there might still be nodes that do not ignore the ID in atomic packets... > However, the impact of these changes on the current header compression al= gs > is useful to discuss, and if it enables an existing mode of compression w= e > should note that (perhaps not encourage changing the ID solely for that > purpose, though - let someone else propose that). > > Would that work? Let's keep the header compression out of this discussion, I am finding this issue is complex enough as is... --julien From touch@isi.edu Thu Jun 23 13:29:31 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8984F21F849D for ; Thu, 23 Jun 2011 13:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6dF0yZX9tzb for ; Thu, 23 Jun 2011 13:29:30 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id A00BC21F8444 for ; Thu, 23 Jun 2011 13:29:30 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p5NKSkNC021003 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 23 Jun 2011 13:28:46 -0700 (PDT) Message-ID: <4E03A1FE.8030204@isi.edu> Date: Thu, 23 Jun 2011 13:28:46 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Julien Laganier References: <4E0250D5.5060701@isi.edu> <4E028414.8030700@isi.edu> <4E038350.60107@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: int-area@ietf.org Subject: Re: [Int-area] Fwd: IPv4 ID update draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 20:29:31 -0000 Hi, Julien, On 6/23/2011 1:08 PM, Julien Laganier wrote: > Hi Joe, > > On Thu, Jun 23, 2011 at 11:17 AM, Joe Touch wrote: >> Hi, Julien, >> >> On 6/22/2011 6:34 PM, Julien Laganier wrote: >>> >>> Joe, >>> >>> Cutting thru a bit: >> >> ... >>>> >>>> I.e., we agree that we need to NOT assume that IDs of atomic packets are >>>> immutable; isn't that the same as allowing them to be modified in >>>> transit? >>>> Is there any other way to say "not immutable" than: >>>> >>>> - an intermediate node MAY rewrite the ID of an atomic packet >>> >>> It seems to me that NOT assuming that IDs of atomic packets are >>> immutable is adequately captured by >>> >>> o>> All devices that examine IPv4 headers MUST ignore the IPv4 ID >>> field of atomic datagrams. >> >> Let's say someone comes up with a crypto mechanism that isn't IPsec and >> isn't encapsulation, but a new IP option (IPsec++, for lack of a better >> description). Let's say that this new IPsec++ creates a hash that includes >> the ID field. >> >> We'd need to assume that such a mod would violate the above requirement - >> since it is clearly not "ignoring" that field. > > I am a bit confused... Are you arguing against the above requirement? > It isn't from me and is already in the draft... I'm arguing that the above requirement may not be explicit enough, i.e., that someone reading *just* the above would conclude that IPsec++ would fail if it used the ID field. >> Then again, Bob Briscoe's doc would also violate the above requirement as >> well, since it clearly is examining the field. > > Yes, and to the extent that we have consensus to update 791with the > above requirements it would be Bob's doc's issue... > >> If that's sufficient, we can use just that. However, I'd note that the >> *current* use of the ID field does not require that it be immutable. > > ... neither does the above requirement. > >> E.g., the field is currently required unique within a src/dst/proto/ID tuple >> within 2MSL. There are two ways to accomplish that: >> >> - enforce uniqueness at the source and assume immutability >> in-transit >> >> - allow mutability in-transit so long as all such changes are >> coordinated to ensure that once the packets (fragmented or not) >> arrive at the receiver they follow the uniqueness rule > > The latter being unenforceable given that in-transit packets might not > all get along the same path, thus you're left with the former, no? The latter is enforceable within a terminus routing domain. It might not be practical, agreed. >> So, technically, if they're ignored, they're mutable, IMO - even if we don't >> say so. > > Technically, if they're ignored, they're ignored. It would follow that > there would be no problem caused by a receiving entity assuming the ID > is unique, neither if there existed an intermediary node that modified > the ID in transit. That however is different from our specification > authorizing intermediate node to modify the ID in transit... > >> My concern is that mutability is something people *will* disagree on, and >> that this doc needs to clarify that issue. The obvious clarification is: >> - if ATOMIC and not protected, then mutable (and ignored) >> - if not ATOMIC or protected (or both), then non-mutable > > And by taking no stance on the mutability of IDs in atomic packets > people would not have to agree or disagree, intermediary nodes > wouldn't feel it's OK to change the ID, yet the requirement that the > field be ignored on the receiving end would prevent implementations to > rely on the supposed uniqueness of the ID, which I thought was out > intent... > >>> We don' t require the field to be immutable by making the mutability >>> properties of the field transparent to the receiver that ignores this >>> field in atomic packets... >> >> I agree, but I'm much more comfortable stating this explicitly if that's >> where the requirements end up pointing. I've found that derived requirements >> are not always derived consistently ;-) > > Good that you agree. > > It also appears that some people (including, but not limited to Erik, > myself, and Jari, if I am not mistaken) are much more comfortable not > changing IPv4 properties unless we have to, e.g., there's potential > harm. > >> I.e., if this is a consequence anyway, is there a good reason not to state >> it? (see below about compression, though) > > See above. There might be things that breaks when the ID of atomic > packets is changed by intermediary nodes. What could possibly break if it must be ignored by everyone who looks at it? My concern is that I don't think there is such a thing - or ever can be, if the original "must be ignored" actually holds. > Thus we don't want to > authorize change of ID in atomic packets. My conclusion is that if there clearly can't be anything that cares, then there can't be an impact to adding the "MAY change" rule. If not having the "MAY change" rule bothers you because something would break, then we indeed have a problem - we have an instance of something that is supposed to ignore the ID that clearly isn't. >>>>>> Given that context, do you think it's still important and/or feasible to >>>>>> prohibit in-transit mods? >>>>> >>>>> It' s not really about prohibiting in-transit mods, since NATs might >>>>> do that already. It is about not allowing it per this specification. >>>>> You can stil mention that NATs do rewrite it... >>>> >>>> Well that would kill the entire discussion on header compression. That's >>>> fine if we want to omit that. but if we do say that "ID is not immutable >>>> in >>>> atomic packets", that opens the door to a very useful optimization for >>>> compression that ought to be included IMO. >>> >>> I do not think that this draft should update a 20 years old protocol >>> specification with the goal of opening doors to optimization of header >>> compression for that same protocol. I _think_ it was also the sense of >>> Erik's message. >> >> I agree with that - the sole point of this is NOT to enable header >> compression. It's just the indirect result of "receiver MUST ignore" for >> atomic unprotected packets as above. > > No. > > Receiver ignoring the ID in atomic packets doen't result in the ID > being mutable. > > Receiver ignoring the ID in atomic packets results in the consequences > of the ID being mutable being benign -- in nodes that implement the > recommendation. > > Thus it's not a valid reason to allow the ID to be mutable -- because > there might still be nodes that do not ignore the ID in atomic > packets... They would be in violation of the first requirement "that they ignore the ID". So if you're going for backward compatibility, you want "SHOULD NOT modify the ID", but then you enable things that continue to look at the ID. So, correct me if I'm wrong: - you're OK with everyone "MUST ignore the ID" of unprotected atomic packets - you don't want any other requirements that are derivative that would affect anyone violating this requirement (e.g., "transits MAY modify") I'd really like to hear from others in the WG on this point; it doesn't make sense to me to have a requirement and deliberately allow it to be ignored. >> However, the impact of these changes on the current header compression algs >> is useful to discuss, and if it enables an existing mode of compression we >> should note that (perhaps not encourage changing the ID solely for that >> purpose, though - let someone else propose that). >> >> Would that work? > > Let's keep the header compression out of this discussion, I am finding > this issue is complex enough as is... Sure... Joe From julien.ietf@gmail.com Thu Jun 23 14:11:14 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFFE011E819D for ; Thu, 23 Jun 2011 14:11:14 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZbN0cIweszK for ; Thu, 23 Jun 2011 14:11:13 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6495A11E80AC for ; Thu, 23 Jun 2011 14:11:12 -0700 (PDT) Received: by bwz13 with SMTP id 13so2142307bwz.31 for ; Thu, 23 Jun 2011 14:11:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mH9r2swtROGFH3PgKHrcIqRwOKpGu7kgkR+WvOu2G4E=; b=rqyWJC4nlm7HJHy3o9jPIWJNJsq91/6j0TnGNjKa+xj7Hf5NDyuTleVyO0fKEmgyeD DpfjpPY5JUUFdnd6ftvTiC0fPvXKR6QaXXCsM8UV9QqNgVeSudJJxDVoKJtI8tm1vabh 7alBCACVihnABpfyx1Wtbl0pamXa5OEoMkWU8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=D9JTU4s+KRAhX8Ql2z+p3xc3RtruM2C2q545bqpAWgy+x6qHsmRAmB/Cu6jYFGjv/Y FgTRKoVBZ8Yt1+t8RLdURHVO8a4v8ADF2px9XUDSHAOnHAB+fyy6S34blBuEwdCNgTtB FSDBaRBH94cXoiiVuxQ7Ul9Z810ZsQUqOvPD0= MIME-Version: 1.0 Received: by 10.204.40.80 with SMTP id j16mr1317864bke.107.1308863471920; Thu, 23 Jun 2011 14:11:11 -0700 (PDT) Received: by 10.204.176.77 with HTTP; Thu, 23 Jun 2011 14:11:11 -0700 (PDT) In-Reply-To: <4E03A1FE.8030204@isi.edu> References: <4E0250D5.5060701@isi.edu> <4E028414.8030700@isi.edu> <4E038350.60107@isi.edu> <4E03A1FE.8030204@isi.edu> Date: Thu, 23 Jun 2011 14:11:11 -0700 Message-ID: From: Julien Laganier To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: int-area@ietf.org Subject: Re: [Int-area] Fwd: IPv4 ID update draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 21:11:15 -0000 Hi Joe, On Thu, Jun 23, 2011 at 1:28 PM, Joe Touch wrote: > > On 6/23/2011 1:08 PM, Julien Laganier wrote: >> >> On Thu, Jun 23, 2011 at 11:17 AM, Joe Touch =A0wrote: >>> >>> On 6/22/2011 6:34 PM, Julien Laganier wrote: >>> ... >>>>> >>>>> I.e., we agree that we need to NOT assume that IDs of atomic packets >>>>> are >>>>> immutable; isn't that the same as allowing them to be modified in >>>>> transit? >>>>> Is there any other way to say "not immutable" than: >>>>> >>>>> =A0 =A0 =A0 =A0- an intermediate node MAY rewrite the ID of an atomic= packet >>>> >>>> It seems to me that NOT assuming that IDs of atomic packets are >>>> immutable is adequately captured by >>>> >>>> =A0 =A0o>> =A0 =A0All devices that examine IPv4 headers MUST ignore th= e IPv4 ID >>>> =A0 =A0 =A0 field of atomic datagrams. >>> >>> Let's say someone comes up with a crypto mechanism that isn't IPsec and >>> isn't encapsulation, but a new IP option (IPsec++, for lack of a better >>> description). Let's say that this new IPsec++ creates a hash that >>> includes >>> the ID field. >>> >>> We'd need to assume that such a mod would violate the above requirement= - >>> since it is clearly not "ignoring" that field. >> >> I am a bit confused... Are you arguing against the above requirement? >> It isn't from me and is already in the draft... > > I'm arguing that the above requirement may not be explicit enough, i.e., > that someone reading *just* the above would conclude that IPsec++ would f= ail > if it used the ID field. It might well be the case, I am not familiar enough with the IPsec++ specification and deployments to offer a definitive conclusion... As to the requirement not being enough, I'd argue that we don't want to let the perfect be the enemy of the good. The status quo here is to do nothing. If we have a requirement that says ignore on the receiving end, we're removing some issues, aren't we? On the other hand, there are been concerns in this draft going too far in modifying a 20 years old deployed and running protocols, including allowing in-flight modification of the ID. These concerns would be addressed by eliminating the allowance (MAY) given to do so... So that is better than the status quo which is the default mode of operatio= n... >>> Then again, Bob Briscoe's doc would also violate the above requirement = as >>> well, since it clearly is examining the field. >> >> Yes, and to the extent that we have consensus to update 791with the >> above requirements it would be Bob's doc's issue... >> >>> If that's sufficient, we can use just that. However, I'd note that the >>> *current* use of the ID field does not require that it be immutable. >> >> ... neither does the above requirement. >> >>> E.g., the field is currently required unique within a src/dst/proto/ID >>> tuple >>> within 2MSL. There are two ways to accomplish that: >>> >>> =A0 =A0 =A0 =A0- enforce uniqueness at the source and assume immutabili= ty >>> =A0 =A0 =A0 =A0in-transit >>> >>> =A0 =A0 =A0 =A0- allow mutability in-transit so long as all such change= s are >>> =A0 =A0 =A0 =A0coordinated to ensure that once the packets (fragmented = or not) >>> =A0 =A0 =A0 =A0arrive at the receiver they follow the uniqueness rule >> >> The latter being unenforceable given that in-transit packets might not >> all get along the same path, thus you're left with the former, no? > > The latter is enforceable within a terminus routing domain. It might not = be > practical, agreed. Right. >>> So, technically, if they're ignored, they're mutable, IMO - even if we >>> don't >>> say so. >> >> Technically, if they're ignored, they're ignored. It would follow that >> there would be no problem caused by a receiving entity assuming the ID >> is unique, neither if there existed an intermediary node that modified >> the ID in transit. That however is different from our specification >> authorizing intermediate node to modify the ID in transit... >> >>> My concern is that mutability is something people *will* disagree on, a= nd >>> that this doc needs to clarify that issue. The obvious clarification is= : >>> =A0 =A0 =A0 =A0- if ATOMIC and not protected, then mutable (and ignored= ) >>> =A0 =A0 =A0 =A0- if not ATOMIC or protected (or both), then non-mutable >> >> And by taking no stance on the mutability of IDs in atomic packets >> people would not have to agree or disagree, intermediary nodes >> wouldn't feel it's OK to change the ID, yet the requirement that the >> field be ignored on the receiving end would prevent implementations to >> rely on the supposed uniqueness of the ID, which I thought was out >> intent... >> >>>> We don' t require the field to be immutable by making the mutability >>>> properties of the field transparent to the receiver that ignores this >>>> field in atomic packets... >>> >>> I agree, but I'm much more comfortable stating this explicitly if that'= s >>> where the requirements end up pointing. I've found that derived >>> requirements >>> are not always derived consistently ;-) >> >> Good that you agree. >> >> It also appears that some people (including, but not limited to Erik, >> myself, and Jari, if I am not mistaken) are much more comfortable not >> changing IPv4 properties unless we have to, e.g., there's potential >> harm. >> >>> I.e., if this is a consequence anyway, is there a good reason not to >>> state >>> it? (see below about compression, though) >> >> See above. There might be things that breaks when the ID of atomic >> packets is changed by intermediary =A0nodes. > > What could possibly break if it must be ignored by everyone who looks at = it? t would be ignored by receiver that follows that update to RFC 791, not necessarily by all nodes in the installed legacy base. Thus if it were modified in transit by a node that felt compelled to so by this update to RFC 791, but the packet was ultimately received by a node who didn't know it had to ignore that we could have problems. > My concern is that I don't think there is such a thing - or ever can be, = if > the original "must be ignored" actually holds. See above. >> Thus we don't want to >> authorize change of ID in atomic packets. > > My conclusion is that if there clearly can't be anything that cares, then > there can't be an impact to adding the "MAY change" rule. There can't be an impact on receiver that follows this update. That ain't true for receivers that do not. > If not having the "MAY change" rule bothers you because something would > break, then we indeed have a problem - we have an instance of something t= hat > is supposed to ignore the ID that clearly isn't. See above. It's also not only me that is bothered, Erik originally expressed the concern and I agreed. >>>>>>> Given that context, do you think it's still important and/or feasib= le >>>>>>> to >>>>>>> prohibit in-transit mods? >>>>>> >>>>>> It' s not really about prohibiting in-transit mods, since NATs might >>>>>> do that already. It is about not allowing it per this specification. >>>>>> You can stil mention that NATs do rewrite it... >>>>> >>>>> Well that would kill the entire discussion on header compression. >>>>> That's >>>>> fine if we want to omit that. but if we do say that "ID is not >>>>> immutable >>>>> in >>>>> atomic packets", that opens the door to a very useful optimization fo= r >>>>> compression that ought to be included IMO. >>>> >>>> I do not think that this draft should update a 20 years old protocol >>>> specification with the goal of opening doors to optimization of header >>>> compression for that same protocol. I _think_ it was also the sense of >>>> Erik's message. >>> >>> I agree with that - the sole point of this is NOT to enable header >>> compression. It's just the indirect result of "receiver MUST ignore" fo= r >>> atomic unprotected packets as above. >> >> No. >> >> Receiver ignoring the ID in atomic packets doen't result in the ID >> being mutable. >> >> Receiver ignoring the ID in atomic packets results in the consequences >> of the ID being mutable being benign -- in nodes that implement the >> recommendation. >> >> Thus it's not a valid reason to allow the ID to be mutable -- because >> there might still be nodes that do not ignore the ID in atomic >> packets... > > They would be in violation of the first requirement "that they ignore the > ID". > > So if you're going for backward compatibility, you want "SHOULD NOT modif= y > the ID", but then you enable things that continue to look at the ID. I do not want to change the behavior of IPv4 w.r.t. to the ID unless I am solving an issue. What issue are you solving by having a MAY modify? > So, correct me if I'm wrong: > > =A0 =A0 =A0 =A0- you're OK with everyone "MUST ignore the ID" of unprotec= ted > =A0 =A0 =A0 =A0atomic packets > > =A0 =A0 =A0 =A0- you don't want any other requirements that are derivativ= e that > =A0 =A0 =A0 =A0would affect anyone violating this requirement (e.g., > =A0 =A0 =A0 =A0"transits MAY modify") As discussed earlier I disagree they are derivative. Is your intent with MAY modify to negatively affect implemetation that do not observe the first requirement MUST ignore the ID? That doesn't seem desirable, at all. > I'd really like to hear from others in the WG on this point; it doesn't m= ake > sense to me to have a requirement and deliberately allow it to be ignored= . For now what you have from this WG is feedback that allowing the ID to be changed isn't desirable. >>> However, the impact of these changes on the current header compression >>> algs >>> is useful to discuss, and if it enables an existing mode of compression >>> we >>> should note that (perhaps not encourage changing the ID solely for that >>> purpose, though - let someone else propose that). >>> >>> Would that work? >> >> Let's keep the header compression out of this discussion, I am finding >> this issue is complex enough as is... > > Sure... > > Joe --julien From K.Fleischhauer@telekom.de Thu Jun 23 14:53:11 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB42521F84BC for ; Thu, 23 Jun 2011 14:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pm0QPtk4lc6t for ; Thu, 23 Jun 2011 14:53:10 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id CF13921F8451 for ; Thu, 23 Jun 2011 14:53:08 -0700 (PDT) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 23 Jun 2011 23:53:03 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.233]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Thu, 23 Jun 2011 23:53:03 +0200 From: To: , Date: Thu, 23 Jun 2011 23:53:02 +0200 Thread-Topic: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? Thread-Index: AcwqsoIK/oLnwxqOSdCrLK8g7sq3+wBybesAAFcKEqAAoUpAcABjsdiw Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADFF0E1A@HE111648.emea1.cds.t-internal.com> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com> <007501cc2d4e$b78fb7d0$26af2770$@com> <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADE52C25@HE111648.emea1.cds.t-internal.com> <05e301cc305d$e3606960$aa213c20$@com> In-Reply-To: <05e301cc305d$e3606960$aa213c20$@com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 21:53:11 -0000 > -----Urspr=FCngliche Nachricht----- > Von: Dan Wing [mailto:dwing@cisco.com] > Gesendet: Dienstag, 21. Juni 2011 23:55 > An: Fleischhauer, Karsten; int-area@ietf.org > Betreff: RE: [Int-area] IETF80 questions regarding "On demand > IPv4 address provisioning in Dual-Stack PPP deployment" - > Topic for WG? > > > -----Original Message----- > > From: K.Fleischhauer@telekom.de [mailto:K.Fleischhauer@telekom.de] > > Sent: Saturday, June 18, 2011 10:17 AM > > To: dwing@cisco.com; int-area@ietf.org > > Subject: AW: [Int-area] IETF80 questions regarding "On demand IPv4 > > address provisioning in Dual-Stack PPP deployment" - Topic for WG? > > > > > > Dear Dan, > > > > see my comments inline > > > > Best > > > > KARSTEN > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: Dan Wing [mailto:dwing@cisco.com] > > > Gesendet: Samstag, 18. Juni 2011 02:29 > > > An: Fleischhauer, Karsten; int-area@ietf.org > > > Betreff: RE: [Int-area] IETF80 questions regarding "On demand > > > IPv4 address provisioning in Dual-Stack PPP deployment" - > > > Topic for WG? > > > > > > This technique causes a round-trip delay when an IPv4 > > > application starts up, due to the on-demand acquisition of an IPv4 > > address. > > The situation in many cases today is, that when "an IPv4 application > > starts up" > > the whole PPP session incl. IPCP has to be established. > > In the ID scenario just IPCP has to be established, so I see not a > > disadvantage. > > Nevertheless this round-trip issue is only valid for the > first packet > > of > > a "Dual-Stack cycle". > > > > > This technique is useful in environments where there is no IPv4 > > address sharing > > > (that is, with publicly-routable IPv4 addresses). > > I think it is also useful in a Home Network scenario with > an routed HG > > and NAT44@HG. > > > > > This technique is useful when not all of > > > the subscribers are needing IPv4 addresses (e.g., they are > > > not connected to the Internet [powered off], or they are running > > applications > > > that only need to use IPv6). > > Ack. And we will pushing the usage of IPv6 to support this scenario. > > > > > This technique requires one publicly-routable > > > IPv4 address for every IPv4 host that has an active IPv4 session > > (which > > > seems to have limited usefulness, considering the world > has exhausted > > its > > > IPv4 address space). > > I think this will work also in a Home Network scenario with > an routed > > HG and NAT44@HG. > > > > > This technique requires changing the host's IPv4 stack. > > This is only valid for the PPP endpoint. > > Our focus is the Home Network scenario with an routed HG > and NAT44@HG. > > The PPP endpoint is the HG. So just the HG and BNG/BRAS need to be > > changed. > > > > > IPv4 address sharing (with NAPT or with an A+P technique) > avoids that > > > round-trip delay, and without changing the host's IPv4 stack. > > > > As already mentioned above the round-trip issue is only > valid for the > > first packet of > > a "Dual-Stack cycle". A CGN scenario would cause an > additional round- > > trip delay > > For each IPv4 packet (NAT 44 processing within the carrier network + > > Packet forwarding via the CGN which will increase the number of > > hops/links). > > How is that "an additional round trip" delay?? > > Maybe you could share a network diagram or a message flow diagram > (ladder diagram) explaining how CGN creates an additional round > trip. This depends of the deployment scenario. But it should be clear that in a centralized CGN deployment an additional d= elay has to be expected. That is at least my interpretation of draft-ietf-intarea-shared-addressing-issues-05 chapter 7. Geo-location and Geo-proximity -> "... Viewed from the content provider, a subscriber behind a CGN geolocates to wherever the prefix of the CGN appears to be; very often that will be in a different city than the subscriber. ..." Maybe it would be worth to add the mentioning of an additional delay in the shared-addressing-issues ID. > > > > Summary: this seems only useful for 3G/4G, where the host's > > > IPv4 stack can be changed, > > Our focus is the fixed network PPP access due BBF TR-178 > respectively > > WT-242. > > But you are right for 3G/4G the general mechanism would also be > > applicable. > > > > > and will cause noticeable delays when users > > > launch applications that need to use IPv4 (delay caused > by acquiring > > an address > > > on demand), > > We see the delay issue not so critically. > > > > > and will be ineffective at its intended goal (avoiding IPv4 > > > address sharing) if "too many" users need IPv4 addresses (e.g., a > > popular > > > application is using IPv4 -- Skype, music streaming, > video streaming, > > instant > > > messaging server, imap/pop server, etc.). > > Of course that can happen, when the application remain on IPv4-only. > > But here I would expect much more problems when at least > one NAT444 is > > in the end-to-end path. > > So, after modifying the home gateway to do this, the IPv4 consumption > will not go down -- each home gateway that has an IPv4 session will > consume an IPv4 address. We expect that once IPv6 is introduced, the usage of IPv4 will starting to = decrease Within 1-2 years. So also the IPv4 address consumption should decrease. > > What's the likely lifetime of such a solution, considering we have > already exhausted IPv4 addresses? We hope to have this implemented before the address exhaustion in Europe oc= cur. So we see in a saturated market for fixed Internet Access good chances to b= e successful. > > -d > > > > > > > > > -d > > > > > > > > > > > > > -----Original Message----- > > > > From: int-area-bounces@ietf.org > > > [mailto:int-area-bounces@ietf.org] On > > > > Behalf Of K.Fleischhauer@telekom.de > > > > Sent: Tuesday, June 14, 2011 9:46 AM > > > > To: int-area@ietf.org > > > > Subject: [Int-area] IETF80 questions regarding "On demand > > > IPv4 address > > > > provisioning in Dual-Stack PPP deployment" - Topic for WG? > > > > > > > > Hi folks, > > > > > > > > right in time before the next IETF in Quebec, we would like > > > to come up > > > > again with our Internet Draft > > > > "On demand IPv4 address provisioning in Dual-Stack PPP > deployment" > > > > in order to gather further feedback from the WG. > > > > During our presentation in Prague I got several remarks and > > > questions > > > > and from my understanding there has been some interest in > > > the approach > > > > we describe in this I-D. > > > > Regarding the questions I want to focus on the following > > > two and will > > > > try to answer them once more: > > > > > > > > - Use case: > > > > In general we see this mechanism applicable for all > Dual-Stack PPP > > > > network scenarios allthrough we focussed our presentation for > > > > illustrative reasons on routed gateways that may be > provided by the > > > > Access Network provider. > > > > In principle as more IPv4 addresses can be saved, as more > > > services are > > > > IPv6 enabled > > > > (especially those which require always-on connectivity > (e.g. VoIP, > > > > mail, update services)) . > > > > The PPP protocol has not to be changed in order to achieve > > > the needed > > > > functionality - > > > > the described behaviour (of independently releasing and > > > > refreshing the IPv4 context within a Dual-Stack PPP session) > > > > is already inherently covered by the existing PPP spec and also > > > > mentioned as requirements for > > > > CPEs (see RFC 6204 - WLL-3). > > > > > > > > - Efficiency of the mechanism: > > > > In principle we assume (with ongoing IPv6 deployment) that it is > > > > possible to save > > > > after one year of roll-out of the described mechanism about 3%, > > > > after two years about 8%, > > > > and after three years up to 13% of the provisioned IPv4 > addresses. > > > > After 8 years 70% of the IPv4 addresses can be "re-cycled" > > > according to > > > > our model calculations. > > > > (You will find more details here: > > > > "http://www.ix- > > > > > > > konferenz.de/getfoldat.php?vid=3D1638&t=3Dapplication/pdf&thema=3DEf > > fizienzab > > > > sch=E4tzung" > > > > (please copy the whole text between the exclamation marks in the > > > > address line of you browser).) > > > > > > > > > > > > We plan to come up with a 01 version of the I-D and would that's > > why > > > > like to gather more feedback from the WG regarding the possible > > open > > > > issues (e.g. what has to be described in more detail, > ), unanswered > > > > questions or any other useful hints how to progress with > > > this work/I-D. > > > > And of course we are also interested in your opinion if > this work > > > > should be done within the Intarea WG or if other WGs > > > (PPPEXT?) may be > > > > more appropriate. > > > > > > > > > > > > Thanks and kind regards > > > > > > > > KARSTEN Fleischhauer > > > > _______________________________________________ > > > > Int-area mailing list > > > > Int-area@ietf.org > > > > https://www.ietf.org/mailman/listinfo/int-area > > > > > > > > From touch@isi.edu Thu Jun 23 15:09:29 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73EE022800D for ; Thu, 23 Jun 2011 15:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.885 X-Spam-Level: X-Spam-Status: No, score=-102.885 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMofqXMTMNJo for ; Thu, 23 Jun 2011 15:09:29 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 91221228005 for ; Thu, 23 Jun 2011 15:09:24 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p5NM8Qq2020934 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 23 Jun 2011 15:08:26 -0700 (PDT) Message-ID: <4E03B95A.3080807@isi.edu> Date: Thu, 23 Jun 2011 15:08:26 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Julien Laganier References: <4E0250D5.5060701@isi.edu> <4E028414.8030700@isi.edu> <4E038350.60107@isi.edu> <4E03A1FE.8030204@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: int-area@ietf.org Subject: Re: [Int-area] Fwd: IPv4 ID update draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 22:09:29 -0000 Hi, Julien (et al.), Cutting this down a bit (actually a lot), On 6/23/2011 2:11 PM, Julien Laganier wrote: ... >> I'm arguing that the above requirement may not be explicit enough, i.e., >> that someone reading *just* the above would conclude that IPsec++ would fail >> if it used the ID field. > > It might well be the case, I am not familiar enough with the IPsec++ > specification and deployments to offer a definitive conclusion... To clarify for the benefit of others on the list as well, there is no IPsec++ - I created it as an example for the discussion only... > As to the requirement not being enough, I'd argue that we don't want > to let the perfect be the enemy of the good. The status quo here is to > do nothing. Fair enough. I will update the draft accordingly, and remove or at least discuss differently the header compression issue. Joe From dwing@cisco.com Thu Jun 23 15:16:50 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D5E11E819D for ; Thu, 23 Jun 2011 15:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.399 X-Spam-Level: X-Spam-Status: No, score=-110.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHl0UmdAXDJc for ; Thu, 23 Jun 2011 15:16:49 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 077C611E8084 for ; Thu, 23 Jun 2011 15:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=12240; q=dns/txt; s=iport; t=1308867409; x=1310077009; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=EanFhoKzTEW3thKYRzSrzS3PaUL3K+Rjcotu1ATyFgs=; b=VybbHTPoaNCwzLRRdn7/s+NHsxkFoSGbwXz28giUwEcHshLrCH5z3Ija fC9KGFAPw9pDgDipTeInTK3BZA8NGv+jyisjR2U2b+pg38Wgm2xMde2pl dZUeXJzEuugdofinthPCKfyCKS0zxTsqrTaZTos27QgqNCYH8qJu62l7v I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAPq6A06rRDoJ/2dsb2JhbABSmA+BZ403d4hzpCmdeIYtBIcmmno X-IronPort-AV: E=Sophos;i="4.65,415,1304294400"; d="scan'208";a="721021555" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 23 Jun 2011 22:16:38 +0000 Received: from dwingWS (dhcp-128-107-104-36.cisco.com [128.107.104.36]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5NMGcL0013643; Thu, 23 Jun 2011 22:16:38 GMT From: "Dan Wing" To: , References: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com> <007501cc2d4e$b78fb7d0$26af2770$@com> <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADE52C25@HE111648.emea1.cds.t-internal.com> <05e301cc305d$e3606960$aa213c20$@com> <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADFF0E1A@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADFF0E1A@HE111648.emea1.cds.t-internal.com> Date: Thu, 23 Jun 2011 15:16:38 -0700 Message-ID: <00de01cc31f3$38e09cc0$aaa1d640$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwqsoIK/oLnwxqOSdCrLK8g7sq3+wBybesAAFcKEqAAoUpAcABjsdiwAAEor5A= Content-Language: en-us Subject: Re: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 22:16:50 -0000 > -----Original Message----- > From: K.Fleischhauer@telekom.de [mailto:K.Fleischhauer@telekom.de] > Sent: Thursday, June 23, 2011 2:53 PM > To: dwing@cisco.com; int-area@ietf.org > Subject: AW: [Int-area] IETF80 questions regarding "On demand IPv4 > address provisioning in Dual-Stack PPP deployment" - Topic for WG? >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Dan Wing [mailto:dwing@cisco.com] > > Gesendet: Dienstag, 21. Juni 2011 23:55 > > An: Fleischhauer, Karsten; int-area@ietf.org > > Betreff: RE: [Int-area] IETF80 questions regarding "On demand > > IPv4 address provisioning in Dual-Stack PPP deployment" - > > Topic for WG? > > > > > -----Original Message----- > > > From: K.Fleischhauer@telekom.de [mailto:K.Fleischhauer@telekom.de] > > > Sent: Saturday, June 18, 2011 10:17 AM > > > To: dwing@cisco.com; int-area@ietf.org > > > Subject: AW: [Int-area] IETF80 questions regarding "On demand IPv4 > > > address provisioning in Dual-Stack PPP deployment" - Topic for WG? > > > > > > > > > Dear Dan, > > > > > > see my comments inline > > > > > > Best > > > > > > KARSTEN > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > Von: Dan Wing [mailto:dwing@cisco.com] > > > > Gesendet: Samstag, 18. Juni 2011 02:29 > > > > An: Fleischhauer, Karsten; int-area@ietf.org > > > > Betreff: RE: [Int-area] IETF80 questions regarding "On demand > > > > IPv4 address provisioning in Dual-Stack PPP deployment" - > > > > Topic for WG? > > > > > > > > This technique causes a round-trip delay when an IPv4 > > > > application starts up, due to the on-demand acquisition of an > IPv4 > > > address. > > > The situation in many cases today is, that when "an IPv4 > application > > > starts up" > > > the whole PPP session incl. IPCP has to be established. > > > In the ID scenario just IPCP has to be established, so I see not a > > > disadvantage. > > > Nevertheless this round-trip issue is only valid for the > > first packet > > > of > > > a "Dual-Stack cycle". > > > > > > > This technique is useful in environments where there is no IPv4 > > > address sharing > > > > (that is, with publicly-routable IPv4 addresses). > > > I think it is also useful in a Home Network scenario with > > an routed HG > > > and NAT44@HG. > > > > > > > This technique is useful when not all of > > > > the subscribers are needing IPv4 addresses (e.g., they are > > > > not connected to the Internet [powered off], or they are running > > > applications > > > > that only need to use IPv6). > > > Ack. And we will pushing the usage of IPv6 to support this > scenario. > > > > > > > This technique requires one publicly-routable > > > > IPv4 address for every IPv4 host that has an active IPv4 session > > > (which > > > > seems to have limited usefulness, considering the world > > has exhausted > > > its > > > > IPv4 address space). > > > I think this will work also in a Home Network scenario with > > an routed > > > HG and NAT44@HG. > > > > > > > This technique requires changing the host's IPv4 stack. > > > This is only valid for the PPP endpoint. > > > Our focus is the Home Network scenario with an routed HG > > and NAT44@HG. > > > The PPP endpoint is the HG. So just the HG and BNG/BRAS need to be > > > changed. > > > > > > > IPv4 address sharing (with NAPT or with an A+P technique) > > avoids that > > > > round-trip delay, and without changing the host's IPv4 stack. > > > > > > As already mentioned above the round-trip issue is only > > valid for the > > > first packet of > > > a "Dual-Stack cycle". A CGN scenario would cause an > > additional round- > > > trip delay > > > For each IPv4 packet (NAT 44 processing within the carrier network > + > > > Packet forwarding via the CGN which will increase the number of > > > hops/links). > > > > How is that "an additional round trip" delay?? > > > > Maybe you could share a network diagram or a message flow diagram > > (ladder diagram) explaining how CGN creates an additional round > > trip. > > This depends of the deployment scenario. I am not aware of any sort of NAT deployment that adds a round trip to the CGN. > But it should be clear that in a centralized CGN deployment an > additional delay has to be expected. That is at least my = interpretation > of > draft-ietf-intarea-shared-addressing-issues-05 > chapter 7. Geo-location and Geo-proximity > -> "... > Viewed from the content provider, a > subscriber behind a CGN geolocates to wherever the prefix of the = CGN > appears to be; very often that will be in a different city than the > subscriber. > ..." > Maybe it would be worth to add the mentioning of an additional delay > in the shared-addressing-issues ID. It is true that deploying a CGN in a far-away place adds propagation=20 delay. But propagation delay is also added by forcing routing to a far-away location with route preferences or tunnels. Propagation delay is propagation delay, and to avoid it requires distributing (rather than centralizing) routers, CGNs, and tunnel termination devices. =20 Most vendors have tiny delays for the NAT processing itself=20 (microseconds). However, the geolocation problem you quoted above also exists with=20 the mechanism scheme you are proposing. For example, a certain IP address, e.g., 161.44.1.1, would be "loaned" to someone in Berlin on Monday morning, and then "loaned" to someone else in Frankfurt=20 on Monday afternoon. To prevent the geolocation problem, only certain subnets would be loaned in each city (e.g., 161.44.1.0/24 is Frankfurt, 161.44.2.0/24 is Berlin, etc.). The same exact thing can be done with a *single* CGN located in one city -- the CGN can assign 161.44.1.0/24 to users from Frankfurt, 161.44.2.0/24 to users from Berlin, etc. Which is how location is handled today, anyway, in the absence of CGN and the absence of address borrowing. >=20 > > > > > > Summary: this seems only useful for 3G/4G, where the host's > > > > IPv4 stack can be changed, > > > Our focus is the fixed network PPP access due BBF TR-178 > > respectively > > > WT-242. > > > But you are right for 3G/4G the general mechanism would also be > > > applicable. > > > > > > > and will cause noticeable delays when users > > > > launch applications that need to use IPv4 (delay caused > > by acquiring > > > an address > > > > on demand), > > > We see the delay issue not so critically. > > > > > > > and will be ineffective at its intended goal (avoiding IPv4 > > > > address sharing) if "too many" users need IPv4 addresses (e.g., = a > > > popular > > > > application is using IPv4 -- Skype, music streaming, > > video streaming, > > > instant > > > > messaging server, imap/pop server, etc.). > > > Of course that can happen, when the application remain on IPv4- > only. > > > But here I would expect much more problems when at least > > one NAT444 is > > > in the end-to-end path. > > > > So, after modifying the home gateway to do this, the IPv4 = consumption > > will not go down -- each home gateway that has an IPv4 session will > > consume an IPv4 address. > > We expect that once IPv6 is introduced, the usage of IPv4 will = starting > to decrease > Within 1-2 years. So also the IPv4 address consumption should = decrease. Yes, I believe we all expect it to decrease. But if it doesn't, where does this leave the engineering IETF would have expended on this additional transition technology. For example, what if = Skype continues to grow but still requires an IPv4 connection. What if Yahoo IM, AOL IM, Microsoft IM, or other popular services with long-lived=20 connections (IM) or frequent connections (IMAP, DNS) don't have clients=20 and servers that support IPv6. My point is that loaning an IPv4 address is only suitable if the demand long-lived and frequent IPv4 connections really _does_ diminish for that specific community of users. If it does not diminish for that specific community of users, the effort is for naught. > > What's the likely lifetime of such a solution, considering we have > > already exhausted IPv4 addresses? > We hope to have this implemented before the address exhaustion in > Europe occur. > So we see in a saturated market for fixed Internet Access good chances > to be successful. -d >=20 >=20 > > > > -d > > > > > > > > > > > > > > -d > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: int-area-bounces@ietf.org > > > > [mailto:int-area-bounces@ietf.org] On > > > > > Behalf Of K.Fleischhauer@telekom.de > > > > > Sent: Tuesday, June 14, 2011 9:46 AM > > > > > To: int-area@ietf.org > > > > > Subject: [Int-area] IETF80 questions regarding "On demand > > > > IPv4 address > > > > > provisioning in Dual-Stack PPP deployment" - Topic for WG? > > > > > > > > > > Hi folks, > > > > > > > > > > right in time before the next IETF in Quebec, we would like > > > > to come up > > > > > again with our Internet Draft > > > > > "On demand IPv4 address provisioning in Dual-Stack PPP > > deployment" > > > > > in order to gather further feedback from the WG. > > > > > During our presentation in Prague I got several remarks and > > > > questions > > > > > and from my understanding there has been some interest in > > > > the approach > > > > > we describe in this I-D. > > > > > Regarding the questions I want to focus on the following > > > > two and will > > > > > try to answer them once more: > > > > > > > > > > - Use case: > > > > > In general we see this mechanism applicable for all > > Dual-Stack PPP > > > > > network scenarios allthrough we focussed our presentation for > > > > > illustrative reasons on routed gateways that may be > > provided by the > > > > > Access Network provider. > > > > > In principle as more IPv4 addresses can be saved, as more > > > > services are > > > > > IPv6 enabled > > > > > (especially those which require always-on connectivity > > (e.g. VoIP, > > > > > mail, update services)) . > > > > > The PPP protocol has not to be changed in order to achieve > > > > the needed > > > > > functionality - > > > > > the described behaviour (of independently releasing and > > > > > refreshing the IPv4 context within a Dual-Stack PPP session) > > > > > is already inherently covered by the existing PPP spec and = also > > > > > mentioned as requirements for > > > > > CPEs (see RFC 6204 - WLL-3). > > > > > > > > > > - Efficiency of the mechanism: > > > > > In principle we assume (with ongoing IPv6 deployment) that it > is > > > > > possible to save > > > > > after one year of roll-out of the described mechanism about = 3%, > > > > > after two years about 8%, > > > > > and after three years up to 13% of the provisioned IPv4 > > addresses. > > > > > After 8 years 70% of the IPv4 addresses can be "re-cycled" > > > > according to > > > > > our model calculations. > > > > > (You will find more details here: > > > > > "http://www.ix- > > > > > > > > > = konferenz.de/getfoldat.php?vid=3D1638&t=3Dapplication/pdf&thema=3DEf > > > fizienzab > > > > > sch=E4tzung" > > > > > (please copy the whole text between the exclamation marks in > the > > > > > address line of you browser).) > > > > > > > > > > > > > > > We plan to come up with a 01 version of the I-D and would > that's > > > why > > > > > like to gather more feedback from the WG regarding the = possible > > > open > > > > > issues (e.g. what has to be described in more detail, > > ), unanswered > > > > > questions or any other useful hints how to progress with > > > > this work/I-D. > > > > > And of course we are also interested in your opinion if > > this work > > > > > should be done within the Intarea WG or if other WGs > > > > (PPPEXT?) may be > > > > > more appropriate. > > > > > > > > > > > > > > > Thanks and kind regards > > > > > > > > > > KARSTEN Fleischhauer > > > > > _______________________________________________ > > > > > Int-area mailing list > > > > > Int-area@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/int-area > > > > > > > > > > > > From julien.ietf@gmail.com Thu Jun 23 15:39:19 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F7A11E8084 for ; Thu, 23 Jun 2011 15:39:19 -0700 (PDT) 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.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0N+jUeV0Yc2 for ; Thu, 23 Jun 2011 15:39:19 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0066211E8078 for ; Thu, 23 Jun 2011 15:39:18 -0700 (PDT) Received: by bwz13 with SMTP id 13so2186718bwz.31 for ; Thu, 23 Jun 2011 15:39:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=Y3h7/kVwoLPyVqhUQJNmuxQHVvlUD7iCN43bN37dls4=; b=bwsY/cosopjB2yldLbOhuj6keizj9CJ4wUUNl+Gf84M8yUSoLBveHXMSnDq2aY/M6U p94Scb4rwUT5mpbNdz7XVZMxwPEymBtbrjXlJUXgK2TcBMfhZcyXEWRg4To+ADyYnU5I +N3zCTy6yyf1UDyds/2Ln5jTGQIjFTbepiHtk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=cuuQF5PPfDBGCyarT0axSGTKTCwRBWVlir+Ku2NFA8Yq7sX1vm5tirk17YPKxmnlQK rQ3ozhuvm0j5OJwCkAvCEKGZ9dbpiDjkIlVyk6rtbMG3LcW9gDTDWPcmgeNRxwe4tlAI 1F3ou6vs9UPGTYRhXfCzcC9/JZjP5YDgvFOL0= MIME-Version: 1.0 Received: by 10.204.31.231 with SMTP id z39mr1300358bkc.134.1308868757808; Thu, 23 Jun 2011 15:39:17 -0700 (PDT) Received: by 10.204.176.77 with HTTP; Thu, 23 Jun 2011 15:39:17 -0700 (PDT) Date: Thu, 23 Jun 2011 15:39:17 -0700 Message-ID: From: Julien Laganier To: int-area@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Int-area] WGLC for http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required-00 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 22:39:20 -0000 Folks, We are hereby issuing a 2 weeks WGLC of the document "IPv6 Support Required for all IP-capable nodes" available at http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required-00 Abstract Given the global lack of available IPv4 space, and limitations in IPv4 extension and transition technologies, this document deprecates the concept that an IP-capable node MAY support IPv4 _only_, and redefines an IP-capable node as one which supports either IPv6 _only_ or IPv4/IPv6 dual-stack. This document updates RFC1812, RFC1122 and RFC4084 to reflect the change in requirements. This is a short, two and a quarter pages long, draft that received significant support from participants to this WG. Please review the draft and raise WGLC comments you might have before we can request publication. This WGLC will conclude on 2010-07-07 5:00 PM PDT. Thank you for your support, --julien & scott From fred@cisco.com Thu Jun 23 17:52:34 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1445711E80A2 for ; Thu, 23 Jun 2011 17:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.723 X-Spam-Level: X-Spam-Status: No, score=-110.723 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdCzPvROnzJV for ; Thu, 23 Jun 2011 17:52:32 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1134911E8081 for ; Thu, 23 Jun 2011 17:52:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=4278; q=dns/txt; s=iport; t=1308876752; x=1310086352; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=lcGMwBarOT0lr5Jch9BTNhHdG71oVtu42YgoHrbBZiU=; b=AxE0NhGMxXEtTaK9tm+6/IbDIjGKdpjYqrYr4XdkBAF8BnO/ycXzncZq 4FSayQ+Ke/v6HMKyBT9J55to18yfNeXtxlBZF4DurxSOscww6up+qlV23 s1jJXgCFsCk1nkQ5GQ9NqM9gXJY7nuPxPXKJoA+xkfldmDZcefoiVwNH/ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADreA06rRDoI/2dsb2JhbABSpy93iHOkXp19hi0EhyWKT4Rmi0o X-IronPort-AV: E=Sophos;i="4.65,416,1304294400"; d="scan'208";a="345869772" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 24 Jun 2011 00:52:31 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5O0qVX2010026; Fri, 24 Jun 2011 00:52:31 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Thu, 23 Jun 2011 17:52:31 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Thu, 23 Jun 2011 17:52:31 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Thu, 23 Jun 2011 17:52:22 -0700 Message-Id: References: To: Julien Laganier X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: int-area@ietf.org Subject: Re: [Int-area] WGLC for http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required-00 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 00:52:34 -0000 > 2. Requirements and Recommendation >=20 >=20 > This draft updates the following documents: >=20 > Updates [RFC1812] to note that IP nodes SHOULD no longer support = IPv4 > only. This is to ensure that those using it as a guideline for IP > implementations use the other informative references in this = document > as a guideline for proper IPv6 implementations. When what became RFC 1812 was written, it was called "requirements for = IP Routers". We changed that to "IPv4 Routers" in the context of the = fact that we were working on several variations on IPng. I worry about = trying to backdate IPv6 issues into the document; it is itself dated, = and while the observations made there are good things to consider in an = IPv6 network, probably are due careful consideration before invoking = from a "requirements" perspective.=20 I agree that routers SHOULD no longer be limited to IPv4. When RFC 1812 = was written, they weren't limited to IPv4 either - they routinely ran = DECnet, OSI, AppleTalk, and IPX to name a few. Personally, I would prefer that this document not confuse itself by = trying to update RFC 1812, but simply assert that IP nodes SHOULD = support IPv6 and MAY support IPv4. For the present, anyone with a = business plan will understand that "MAY" applies at some point in the = future. > Updates [RFC1122] to redefine generic "IP" support to include and > require IPv6 for IP-capable nodes and routers. Same concern with RFC 1122. For example, for IPv6 support, section 2 = needs updating to mention, beside ARP, Neighbor Discovery. And do we = agree that in an IPv6 network The packet send interface between the IP and link layers MUST include the 5-bit TOS field (see Section 3.2.1.6). ? How about the various references in section 3.1? Personally, I would prefer that this document not confuse itself by = trying to update RFC 1122, but simply assert that IP nodes SHOULD = support IPv6 and MAY support IPv4. For the present, anyone with a = business plan will understand that "MAY" applies at some point in the = future. > Updates [RFC4084] to move "Version Support" from Section 4, > "Additional Terminology" to Section 2, "General Terminology." This > is to reflect the idea that version support is now critical to > defining the types of IP service, especially with respect to Full > Internet Connectivity. >=20 > =46rom a practical perspective, the requirements proposed by this = draft > mean that: >=20 > New IP implementations MUST support IPv6. Paragraph 2 of section 2 says "SHOULD". Pick one? > Current IP implementations SHOULD support IPv6. If they don't and are current, this is demanding a change; any change to = said implementations is a new implementation. Hmmm? > IPv6 support MUST be equivalent or better in quality and > functionality when compared to IPv4 support in an IP > implementation. >=20 > Helpful informative references can be found in [RFC4294], soon = to > be updated by [I-D.ietf-6man-node-req-bis] and in [RFC6204] This section says that it is "requirements". Rather than discussing = "Helpful informative references", I'd suggest calling them "Node = Requirements" > Current and new IP Networking implementations SHOULD support = IPv4 > and IPv6 coexistence (dual-stack), but MUST NOT require IPv4 for > proper and complete function. >=20 > It is expected that many existing devices and implementations = will > not be able to support IPv6 for one or more valid technical > reasons, but for maximum flexibility and compatibility, a best > effort SHOULD be made to update existing hardware and software = to > enable IPv6 support. I'm afraid that in many cases that is a vendor marketing decision. Yes, = I'd like to see every non-IPv6 implementation upgraded. To the extent = that they have hardware limitations (forwarding ASICs, filtering ASICs, = memory, SAVI, ...), I wouldn't be amazed to find vendors saying they = would rather obsolete older equipment than upgrade those issues. I think = the IETF would do well to stay out of that morass.= From Olaf.Bonness@telekom.de Fri Jun 24 00:58:02 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72FEF11E8090 for ; Fri, 24 Jun 2011 00:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62X1OvgiPp68 for ; Fri, 24 Jun 2011 00:58:01 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id 9B66E11E8070 for ; Fri, 24 Jun 2011 00:58:01 -0700 (PDT) Received: from he101250.emea1.cds.t-internal.com ([10.125.92.153]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 24 Jun 2011 09:57:51 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.158]) by HE101250.emea1.cds.t-internal.com ([fe80::e439:4046:12e2:e37%15]) with mapi; Fri, 24 Jun 2011 09:57:51 +0200 From: To: Date: Fri, 24 Jun 2011 09:57:51 +0200 Thread-Topic: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? Thread-Index: AcwqsoIK/oLnwxqOSdCrLK8g7sq3+wBybesAAFcKEqAAoUpAcABjsdiwAAEor5AAFE8ZQA== Message-ID: References: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com> <007501cc2d4e$b78fb7d0$26af2770$@com> <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADE52C25@HE111648.emea1.cds.t-internal.com> <05e301cc305d$e3606960$aa213c20$@com> <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADFF0E1A@HE111648.emea1.cds.t-internal.com> <00de01cc31f3$38e09cc0$aaa1d640$@com> In-Reply-To: <00de01cc31f3$38e09cc0$aaa1d640$@com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: int-area@ietf.org Subject: Re: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 07:58:02 -0000 > > Karsten Fleischhauer wrote: > > We expect that once IPv6 is introduced, the usage of IPv4 > will starting > > to decrease > > Within 1-2 years. So also the IPv4 address consumption > should decrease. > > Dan Wing wrote > Yes, I believe we all expect it to decrease. > > But if it doesn't, where does this leave the engineering IETF > would have > expended on this additional transition technology. For > example, what if > Skype continues to grow but still requires an IPv4 > connection. What if > Yahoo > IM, AOL IM, Microsoft IM, or other popular services with long-lived > connections (IM) or frequent connections (IMAP, DNS) don't > have clients > and servers that support IPv6. > I don't think that this "What would be ... when ... " guessing is the appro= ch we should take here. In the long run all the named applications will run on top of IPv6. The que= stion is of course when will this happen and what is the gain that could be= reached with "Dynamic IPv4 Address Provisioning" in the meantime. The gain= will (in worst case e.g. when Skype stays resistent against IPv6 support f= or a long time in the future) of course not be as high as wanted. But even = in that case the mechanism will be helpful and useful. Olaf From wesley.george@twcable.com Fri Jun 24 12:05:38 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AD011E80AC for ; Fri, 24 Jun 2011 12:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.237 X-Spam-Level: X-Spam-Status: No, score=-0.237 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nFt7yUqKdQp for ; Fri, 24 Jun 2011 12:05:37 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9F311E8076 for ; Fri, 24 Jun 2011 12:05:37 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.65,421,1304308800"; d="scan'208";a="242344010" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 24 Jun 2011 15:04:41 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Fri, 24 Jun 2011 15:05:36 -0400 From: "George, Wesley" To: Fred Baker , Julien Laganier Date: Fri, 24 Jun 2011 15:05:35 -0400 Thread-Topic: [Int-area] WGLC for http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required-00 Thread-Index: AcwyCQgHxTB+YiPHRQOrr9x2WSnfBQAks6aw Message-ID: <34E4F50CAFA10349A41E0756550084FB0A6154E0@PRVPEXVS04.corp.twcable.com> References: 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: "int-area@ietf.org" Subject: Re: [Int-area] WGLC for http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required-00 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 19:05:38 -0000 Fred, thanks for the review, some comments below inline, marked with WEG> Thanks, Wes -----Original Message----- From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On Behal= f Of Fred Baker Sent: Thursday, June 23, 2011 8:52 PM To: Julien Laganier Cc: int-area@ietf.org Subject: Re: [Int-area] WGLC for http://tools.ietf.org/html/draft-ietf-inta= rea-ipv6-required-00 > 2. Requirements and Recommendation > > > This draft updates the following documents: > > Updates [RFC1812] to note that IP nodes SHOULD no longer support IPv4 > only. This is to ensure that those using it as a guideline for IP > implementations use the other informative references in this document > as a guideline for proper IPv6 implementations. When what became RFC 1812 was written, it was called "requirements for IP R= outers". We changed that to "IPv4 Routers" in the context of the fact that = we were working on several variations on IPng. I worry about trying to back= date IPv6 issues into the document; it is itself dated, and while the obser= vations made there are good things to consider in an IPv6 network, probably= are due careful consideration before invoking from a "requirements" perspe= ctive. I agree that routers SHOULD no longer be limited to IPv4. When RFC 1812 was= written, they weren't limited to IPv4 either - they routinely ran DECnet, = OSI, AppleTalk, and IPX to name a few. Personally, I would prefer that this document not confuse itself by trying = to update RFC 1812, but simply assert that IP nodes SHOULD support IPv6 and= MAY support IPv4. For the present, anyone with a business plan will unders= tand that "MAY" applies at some point in the future. WEG> I don't believe that the document is confused. The idea in linking to = RFC1812 as an updated document is to ensure that those looking up RFCs rela= ted to basic requirements for IP routers find that this document exists and= through it discover that there are now companion requirements defined for = IPv6 routers that this document cites as informative references. > Updates [RFC1122] to redefine generic "IP" support to include and > require IPv6 for IP-capable nodes and routers. Same concern with RFC 1122. For example, for IPv6 support, section 2 needs = updating to mention, beside ARP, Neighbor Discovery. And do we agree that i= n an IPv6 network The packet send interface between the IP and link layers MUST include the 5-bit TOS field (see Section 3.2.1.6).? How about the various references in section 3.1? Personally, I would prefer that this document not confuse itself by trying = to update RFC 1122, but simply assert that IP nodes SHOULD support IPv6 and= MAY support IPv4. For the present, anyone with a business plan will unders= tand that "MAY" applies at some point in the future. WEG> This document is not meant to replace existing standards defining IPv6= , but to reference them. There is no need to reinvent the wheel by rewritin= g 1122 to include full IPv6 support when companion documents that cover tha= t information already exists. Again, this is meant to be a trail of bread c= rumbs to point to the appropriate resources for those looking for guideline= s on how to build an IP device. That said, for both of the above concerns, if the consensus is that those r= eferences should be removed in order for the draft to get past WGLC, we'll = do that. I'd like to hear from additional folks in the WG about this. > Updates [RFC4084] to move "Version Support" from Section 4, > "Additional Terminology" to Section 2, "General Terminology." This > is to reflect the idea that version support is now critical to > defining the types of IP service, especially with respect to Full > Internet Connectivity. > > From a practical perspective, the requirements proposed by this draft > mean that: > > New IP implementations MUST support IPv6. Paragraph 2 of section 2 says "SHOULD". Pick one? WEG> The first occurrence is not making the distinction between new vs curr= ent, and staying more generic, hence the SHOULD. > Current IP implementations SHOULD support IPv6. If they don't and are current, this is demanding a change; any change to sa= id implementations is a new implementation. Hmmm? WEG> I think that this is stretching a bit, and I'm not sure what you're re= commending here. By the strictest definition, yes, the IPv6 implementation = will likely be new. However, the entire implementation is not new. I don't = know of any implementer who will rewrite otherwise functional code that isn= 't critical to making the new feature work. You don't say that you have a b= rand new house because you added a room and a patio to an existing structur= e... > IPv6 support MUST be equivalent or better in quality and > functionality when compared to IPv4 support in an IP > implementation. > > Helpful informative references can be found in [RFC4294], soon to > be updated by [I-D.ietf-6man-node-req-bis] and in [RFC6204] This section says that it is "requirements". Rather than discussing "Helpfu= l informative references", I'd suggest calling them "Node Requirements" WEG> Ack, will re-word. > Current and new IP Networking implementations SHOULD support IPv4 > and IPv6 coexistence (dual-stack), but MUST NOT require IPv4 for > proper and complete function. > > It is expected that many existing devices and implementations will > not be able to support IPv6 for one or more valid technical > reasons, but for maximum flexibility and compatibility, a best > effort SHOULD be made to update existing hardware and software to > enable IPv6 support. I'm afraid that in many cases that is a vendor marketing decision. Yes, I'd= like to see every non-IPv6 implementation upgraded. To the extent that the= y have hardware limitations (forwarding ASICs, filtering ASICs, memory, SAV= I, ...), I wouldn't be amazed to find vendors saying they would rather obso= lete older equipment than upgrade those issues. I think the IETF would do w= ell to stay out of that morass. WEG> We already know that the vendors' general view is "backporting IPv6 is= hard, let's go shopping..." This was specifically worded to concede that i= t's not practical to simply demand that everything be updated and that ther= e are legitimate limitations to where IPv6 can and cannot be supported, but= still recommend that it be done where that's not the case. Therefore the a= uthors believe that it keeps IETF out of that morass pretty effectively. Pl= ease be clearer as to what specifically you feel the above text is not cove= ring and I'll be happy to try to incorporate those changes. 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 Jun 24 12:21:00 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D64E11E80BE for ; Fri, 24 Jun 2011 12:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.714 X-Spam-Level: X-Spam-Status: No, score=-110.714 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ee+sANfkSZQ for ; Fri, 24 Jun 2011 12:20:58 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id D650911E8084 for ; Fri, 24 Jun 2011 12:20:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1885; q=dns/txt; s=iport; t=1308943258; x=1310152858; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=wrXLaD4dYxTWUOdnNY8U2YKLif4wU9a9t9k8PR8CWSc=; b=aby8QGFDnCSi+GKrTruCvgGmQZcaLdkGKqKGWoQ8s07e+/qHNaEl5Ikh pf+hLOFLnTuYxuYVDdcQC9dB1VTnF6nyVIi/z3TgFWoSc/sMHeESF2JzO uvX/hLGSx/fCpC4WKYPqPsOFdRaskT9X27ixHUNOXz1blba1Bnffb0/LT M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFDjBE6rRDoI/2dsb2JhbABTpz93iHOjI4wNkW+GLQSHKYpShGiLSg X-IronPort-AV: E=Sophos;i="4.65,421,1304294400"; d="scan'208";a="385801601" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 24 Jun 2011 19:20:39 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5OJKc6i019259; Fri, 24 Jun 2011 19:20:38 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Fri, 24 Jun 2011 12:20:39 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Fri, 24 Jun 2011 12:20:39 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0A6154E0@PRVPEXVS04.corp.twcable.com> Date: Fri, 24 Jun 2011 12:20:29 -0700 Message-Id: References: <34E4F50CAFA10349A41E0756550084FB0A6154E0@PRVPEXVS04.corp.twcable.com> To: "George, Wesley" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Julien Laganier , "int-area@ietf.org" Subject: Re: [Int-area] WGLC for http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required-00 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 19:21:00 -0000 On Jun 24, 2011, at 12:05 PM, George, Wesley wrote: >> Current IP implementations SHOULD support IPv6. >=20 > If they don't and are current, this is demanding a change; any change = to said implementations is a new implementation. Hmmm? > WEG> I think that this is stretching a bit, and I'm not sure what = you're recommending here. By the strictest definition, yes, the IPv6 = implementation will likely be new. However, the entire implementation is = not new. I don't know of any implementer who will rewrite otherwise = functional code that isn't critical to making the new feature work. You = don't say that you have a brand new house because you added a room and a = patio to an existing structure... Well, no, but you might well say that you have a new room etc. In = something that is IPv4-only and adds IPv6, it isn't sufficient to "add = IPv6"; the psuedoheader changes sneak up stack, and the application API = has to change to accommodate IPv6 in some way. This is actually fairly = analogous to adding a room; the wall that used to be there is no longer = there or is changed, and as a result various other parts of the house = need work as well. I will argue that the IPv6 component of this changed = system is new. My biggest point in the email is to tease what you intend ("listen guys, = I want IPv6 support; get off the dime") apart from the mechanisms you = choose. Your fundamental point is, I think, a good one. The problem with = updating RFCs 1122 and 1812 is that (having some experience with both) = you can't hand-wave updates to them. You are in essence asking the = reader to reinterpret remarks made about IPv4 in an IPv6 context, and = they don't necessarily have obvious interpretations. So I personally would prefer that the message be simplified. "listen guys, I want IPv6 support; get off the dime"= From tena@huawei.com Fri Jun 24 13:20:03 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6157F21F85D2 for ; Fri, 24 Jun 2011 13:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyHj7PpjdDh6 for ; Fri, 24 Jun 2011 13:20:01 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id C83BF21F85CC for ; Fri, 24 Jun 2011 13:20:01 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNB00D9P9TCR0@usaga04-in.huawei.com> for int-area@ietf.org; Fri, 24 Jun 2011 15:20:00 -0500 (CDT) Received: from TingZousc1 ([10.193.34.119]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LNB002C59TBAZ@usaga04-in.huawei.com> for int-area@ietf.org; Fri, 24 Jun 2011 15:20:00 -0500 (CDT) Date: Fri, 24 Jun 2011 13:20:02 -0700 From: Tina Tsou In-reply-to: To: 'Fred Baker' , "'George, Wesley'" Message-id: <007501cc32ac$19acf1f0$4d06d5d0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acwyo+DUBdUu3klpTYCGhUJjr8tG1gAB+Kxg References: <34E4F50CAFA10349A41E0756550084FB0A6154E0@PRVPEXVS04.corp.twcable.com> Cc: 'Julien Laganier' , int-area@ietf.org Subject: Re: [Int-area] WGLC for http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required-00 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 20:20:03 -0000 Hi, This is a significant I-D, which will lead IPv6-related work become the *only* work in IP standardization, not IPv4-specific work anymore, eventually. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On Behalf Of Fred Baker Sent: Friday, June 24, 2011 12:20 PM To: George, Wesley Cc: Julien Laganier; int-area@ietf.org Subject: Re: [Int-area] WGLC for http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required-00 On Jun 24, 2011, at 12:05 PM, George, Wesley wrote: >> Current IP implementations SHOULD support IPv6. > > If they don't and are current, this is demanding a change; any change to said implementations is a new implementation. Hmmm? > WEG> I think that this is stretching a bit, and I'm not sure what you're recommending here. By the strictest definition, yes, the IPv6 implementation will likely be new. However, the entire implementation is not new. I don't know of any implementer who will rewrite otherwise functional code that isn't critical to making the new feature work. You don't say that you have a brand new house because you added a room and a patio to an existing structure... Well, no, but you might well say that you have a new room etc. In something that is IPv4-only and adds IPv6, it isn't sufficient to "add IPv6"; the psuedoheader changes sneak up stack, and the application API has to change to accommodate IPv6 in some way. This is actually fairly analogous to adding a room; the wall that used to be there is no longer there or is changed, and as a result various other parts of the house need work as well. I will argue that the IPv6 component of this changed system is new. My biggest point in the email is to tease what you intend ("listen guys, I want IPv6 support; get off the dime") apart from the mechanisms you choose. Your fundamental point is, I think, a good one. The problem with updating RFCs 1122 and 1812 is that (having some experience with both) you can't hand-wave updates to them. You are in essence asking the reader to reinterpret remarks made about IPv4 in an IPv6 context, and they don't necessarily have obvious interpretations. So I personally would prefer that the message be simplified. "listen guys, I want IPv6 support; get off the dime" _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area From julien.ietf@gmail.com Fri Jun 24 14:35:06 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2766211E8185 for ; Fri, 24 Jun 2011 14:35:06 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9cwsPkKJUIb for ; Fri, 24 Jun 2011 14:35:05 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2324811E8190 for ; Fri, 24 Jun 2011 14:35:04 -0700 (PDT) Received: by bwb17 with SMTP id 17so140207bwb.31 for ; Fri, 24 Jun 2011 14:35:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=UtnKREr16MLXnv5HmYbgZvXUBf+LK5fXyKjFtc6FvnI=; b=uxj2PJWiwRP5IMnT8GmNOZyeL2XU2GCcNqp/jiQ2SikPuiYffAmUfobLS+nANH+fK4 w0fwdXMW07EdqWeijj+FhVsXhqPEgsr58WTwE+PptitJGLHzM2pY48z3nfWtZJT3OzzE DZ1ZKxgv9Ox2YE592prxzByzjU6AVOiQNWUNE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Y8Lfz0Z1a9PubLERHofhR29jJksP8W487eEEbdu1feo9buFVcOSaVhlHMfPmR0fvEA sPegzoKkwdUv2iHVblTszSHHOnf/CcSvNEyXAdidKgOI9YpxJzp1JICYpD4/nQcKC5qM 3l2PD4BSK9WxW0k2AskgpuYGBskLXyGTrrmyU= MIME-Version: 1.0 Received: by 10.204.42.129 with SMTP id s1mr2213642bke.213.1308951303924; Fri, 24 Jun 2011 14:35:03 -0700 (PDT) Received: by 10.204.71.78 with HTTP; Fri, 24 Jun 2011 14:35:03 -0700 (PDT) In-Reply-To: <20110624183513.7035311E81A8@ietfa.amsl.com> References: <20110624183513.7035311E81A8@ietfa.amsl.com> Date: Fri, 24 Jun 2011 14:35:03 -0700 Message-ID: From: Julien Laganier To: int-area@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Int-area] Fwd: Please help the Nomcom X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 21:35:06 -0000 FYI ---------- Forwarded message ---------- From: NomCom Chair Date: Fri, Jun 24, 2011 at 11:35 AM Subject: Please help the Nomcom To: Working Group Chairs Hi WG chairs, =A0We have had a good response to the first call for volunteers but the rate at which new volunteers are coming in is slowing down. The Nomcom process is best served by a large pool of volunteers drawn from a wide spectrum of IETF attendees. Where else would we find this wide spectrum if not in the WG mailing lists. I would really appreciate it if you can forward the message onto your working group mailing lists. The latest volunteer status and the second call for volunteers can be found at https://datatracker.ietf.org/ann/nomcom/2964/ Thanks in advance for your help. Suresh Krishnan Nomcom Chair 2011-2012 Email: nomcom-chair@ietf.org, suresh.krishnan@ericsson.com From internet-drafts@ietf.org Mon Jun 27 08:13:20 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1AA11E810D; Mon, 27 Jun 2011 08:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.415 X-Spam-Level: X-Spam-Status: No, score=-102.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHvjtdI-arRr; Mon, 27 Jun 2011 08:13:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0894611E8112; Mon, 27 Jun 2011 08:12:45 -0700 (PDT) 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.55 Message-ID: <20110627151240.15775.59538.idtracker@ietfa.amsl.com> Date: Mon, 27 Jun 2011 08:12:40 -0700 Cc: int-area@ietf.org Subject: [Int-area] I-D Action: draft-ietf-intarea-router-alert-considerations-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 15:13:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Internet Area Working Group Working G= roup of the IETF. Title : IP Router Alert Considerations and Usage Author(s) : Francois Le Faucheur Filename : draft-ietf-intarea-router-alert-considerations-05.txt Pages : 24 Date : 2011-06-27 The IP Router Alert Option is an IP option that alerts transit routers to more closely examine the contents of an IP packet. Resource reSerVation Protocol (RSVP), Pragmatic General Multicast (PGM), Internet Group Management Protocol (IGMP), Multicast Listener Discovery (MLD), Multicast Router Discovery (MRD) and General Internet Signalling Transport (GIST) are some of the protocols that make use of the IP Router Alert option. This document discusses security aspects and usage guidelines around the use of the current IP Router Alert option. Specifically, it provides recommendation against using the Router Alert in the end-to-end open Internet as well as identify controlled environments where protocols depending on Router Alert can be used safely. It also provides recommendation about protection approaches for Service Providers. Finally it provides brief guidelines for Router Alert implementation on routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-intarea-router-alert-conside= rations-05.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-intarea-router-alert-consider= ations-05.txt From wesley.george@twcable.com Mon Jun 27 08:37:14 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A70321F862D for ; Mon, 27 Jun 2011 08:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xgwInDTCyat for ; Mon, 27 Jun 2011 08:37:13 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 9541F21F8626 for ; Mon, 27 Jun 2011 08:37:13 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.65,432,1304308800"; d="scan'208";a="243000112" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 27 Jun 2011 11:36:03 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Mon, 27 Jun 2011 11:37:04 -0400 From: "George, Wesley" To: Fred Baker Date: Mon, 27 Jun 2011 11:37:02 -0400 Thread-Topic: [Int-area] WGLC for http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required-00 Thread-Index: Acwyo9nenjozJ5xIT1+rA+fYEPY1HgCOcapw Message-ID: <34E4F50CAFA10349A41E0756550084FB0A61580A@PRVPEXVS04.corp.twcable.com> References: <34E4F50CAFA10349A41E0756550084FB0A6154E0@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: Julien Laganier , "int-area@ietf.org" Subject: Re: [Int-area] WGLC for http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required-00 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 15:37:14 -0000 -----Original Message----- From: Fred Baker [mailto:fred@cisco.com] Sent: Friday, June 24, 2011 3:20 PM To: George, Wesley Cc: Julien Laganier; int-area@ietf.org Subject: Re: [Int-area] WGLC for http://tools.ietf.org/html/draft-ietf-inta= rea-ipv6-required-00 My biggest point in the email is to tease what you intend ("listen guys, I = want IPv6 support; get off the dime") apart from the mechanisms you choose.= Your fundamental point is, I think, a good one. The problem with updating = RFCs 1122 and 1812 is that (having some experience with both) you can't han= d-wave updates to them. You are in essence asking the reader to reinterpret= remarks made about IPv4 in an IPv6 context, and they don't necessarily hav= e obvious interpretations. So I personally would prefer that the message be simplified. "listen guys, I want IPv6 support; get off the dime" WEG> and if there's consensus that removing the updated RFCs list is the be= st way to proceed, than that is what we shall do. The authors (and I assume= those who recommended other RFCs to list as being updated by this draft) w= ere under the impression that there was precedent for updating a draft in t= his way, essentially saying "this is no longer complete, you need to look a= t these other standards too." My preference would have been for IPv6 RFCs (= such as 1183/2460, etc) to update the equivalent IPv4 RFCs, but that predat= es my involvement in IETF. Looking at it now, I think it'd be more confusin= g to issue -bis versions of those documents to make that the case, and so t= he easiest path to that was to update the correct docs with a bridge draft = of sorts that then includes forward references to the correct RFCs or to ot= her drafts/RFCs that include the much more complete set of references (such= as the node-req-bis and 6204). I'm also open to recommendations for more substantive changes in the "updat= es RFC xxxx" language in this document to clarify and remove the potential = confusion or reduce the level of handwaving in the current language to addr= ess your point about the less than obvious interpretation of the recommende= d updates. While I don't want this to end up addressing updates in a sectio= n-by-section manner in the referenced RFCs, I think a couple of sentences c= larifying how this "update" should be interpreted would be appropriate. 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 julien.ietf@gmail.com Mon Jun 27 09:52:17 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A5921F86CA for ; Mon, 27 Jun 2011 09:52:17 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9Z5gafxkxat for ; Mon, 27 Jun 2011 09:52:17 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id BF74021F86C8 for ; Mon, 27 Jun 2011 09:52:13 -0700 (PDT) Received: by bwb17 with SMTP id 17so1735234bwb.31 for ; Mon, 27 Jun 2011 09:52:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=ejRag6/44pg9Wsja/dT64xZ2pDx6wIyjOgTih3db/d0=; b=HUhPhFU8pCKJlzr0djzOyrFQgQfEOdYra6vhiGW2miv0Q1Tahs9FQam+82n5WvKO51 DyUYCRrnLGzooR4n/YnvaRXHr2D8XbSY7+H0RLWMEvsmu2hl7KoqQQDgjb3eBfouHf0t +1uByjKJpAr1xYx1nVGwj2vSUYoDIVctUInUY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=Bgc54eLUhhR5VgC5yRC+E3lv9HtSr3+P4UD5SuqfhCpGftMI3mRqkPw0oEopo/fS7y u6XODiN3BAryb8/MvfQ2RawlP9fePBrZ3IGVubhN7822MA1Cpp/v5Fe6d8JLFZuPYhhD CgnD9FdKegGl3bmm1bsP/pv0lbo/TxWUeoW6I= MIME-Version: 1.0 Received: by 10.204.40.2 with SMTP id i2mr444845bke.159.1309193531480; Mon, 27 Jun 2011 09:52:11 -0700 (PDT) Received: by 10.204.71.78 with HTTP; Mon, 27 Jun 2011 09:52:11 -0700 (PDT) Date: Mon, 27 Jun 2011 09:52:11 -0700 Message-ID: From: Julien Laganier To: int-area@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: int-ads@tools.ietf.org Subject: [Int-area] intarea status update before IETF-81 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 16:52:17 -0000 Folks, at this point we do not have anything on our plate that would require face to face discussion thus the INTAREA WG will not meet in Quebec. Please see below the status for our current WG drafts: Active: - draft-ietf-intarea-ipv4-id-update => requested expert reviews, document shepherd working on-list with Joe to resolve issues that have been brought up. - draft-ietf-intarea-ipv6-required => currently in WGLC IESG Processing: - draft-ietf-intarea-router-alert-considerations => publication requested, currently resolving comments from sponsoring AD RFC-Editor's Queue: - draft-ietf-intarea-server-logging-recommendations => in EDIT state. - draft-ietf-intarea-shared-addressing-issues => in AUTH48, awaiting final approval from ADs. Expired: draft-ietf-intarea-tunnels => no activity. Below is the status of email discussions regarding non-WG drafts: - draft-fleischhauer-ipv4-addr-saving-00 => currently ongoing discussion regarding the usefulness of the proposal. No conclusion yet. --julien & scott From rdroms.ietf@gmail.com Mon Jun 27 12:46:14 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7A611E815D for ; Mon, 27 Jun 2011 12:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ECKHSH+Fjh4 for ; Mon, 27 Jun 2011 12:46:13 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 65DAF11E815C for ; Mon, 27 Jun 2011 12:46:13 -0700 (PDT) Received: by vws12 with SMTP id 12so5058592vws.31 for ; Mon, 27 Jun 2011 12:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=YMKbfeutErcZnW1+w6f0KmTr17tDYUCPcT7fS4mY6DM=; b=nC+oAVO+fzfo0ez1cgkB/7DCgsIU9/ss0wEwRLdC/fs+Xp3p0HP/QkxxYxs9R3dgiB HYu0m9gfFnucRHpObm1/VqWqWR0JXEcXDslaTYqVDhh3AkywTov0zR71qpiG2YlPcHkf iljGndyyumTTh3eDc/BQgkyTmAP23lnYrQhsI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=WbyLLPugNClyOJfPyuBfKzJMfBD/lBKb2x/i+k/of8mJYd92UelFPonMAuQXhSozWn R3dxrOpFIHnXPUysbGElCoqNXd3Nu24ZjCW2dPKUrSLjrxkEmUNv7/L7koEbzxqOF6qd nj1nul5UNvzzxXj5pLtqpIGxdc1n7kjQRh8d0= Received: by 10.52.160.194 with SMTP id xm2mr223682vdb.221.1309203972354; Mon, 27 Jun 2011 12:46:12 -0700 (PDT) Received: from bxb-rdroms-8718.cisco.com (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id bh17sm1632137vdc.3.2011.06.27.12.46.09 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Jun 2011 12:46:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: Date: Mon, 27 Jun 2011 15:46:08 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: To: Julien Laganier X-Mailer: Apple Mail (2.1084) Cc: int-area@ietf.org, int-ads@tools.ietf.org Subject: Re: [Int-area] intarea status update before IETF-81 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 19:46:14 -0000 Thanks... - Ralph On Jun 27, 2011, at 12:52 PM 6/27/11, Julien Laganier wrote: > Folks, > > at this point we do not have anything on our plate that would require > face to face discussion thus the INTAREA WG will not meet in Quebec. > > Please see below the status for our current WG drafts: > > Active: > > - draft-ietf-intarea-ipv4-id-update => requested expert reviews, > document shepherd working on-list with Joe to resolve issues that have > been brought up. > - draft-ietf-intarea-ipv6-required => currently in WGLC > > IESG Processing: > > - draft-ietf-intarea-router-alert-considerations => publication > requested, currently resolving comments from sponsoring AD > > RFC-Editor's Queue: > > - draft-ietf-intarea-server-logging-recommendations => in EDIT state. > - draft-ietf-intarea-shared-addressing-issues => in AUTH48, awaiting > final approval from ADs. > > Expired: > draft-ietf-intarea-tunnels => no activity. > > Below is the status of email discussions regarding non-WG drafts: > > - draft-fleischhauer-ipv4-addr-saving-00 => currently ongoing > discussion regarding the usefulness of the proposal. No conclusion > yet. > > --julien & scott From bschlies@cisco.com Mon Jun 27 14:06:13 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB8421F8611 for ; Mon, 27 Jun 2011 14:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsy9H0Z-2HrM for ; Mon, 27 Jun 2011 14:06:13 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7D121F8610 for ; Mon, 27 Jun 2011 14:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=1170; q=dns/txt; s=iport; t=1309208773; x=1310418373; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=9H9nFN/S7d1JHWrSCfqq+PVtn1uiMjbbyUerJ6C3tmc=; b=ktnvkOczZxqP+haK3mLUGKjtFXspyE+WgE4MYwQwy07dMrFmzyww6pM6 ClQwHp1OlfN9POXzL8/623oUW9OhAin8Pm4i7B6C6TMe7ary9IoVXz0Py xcaPFCzz/mZMNFn483+R256GhxeO1aHjAzUak726+AfA/KQyC5BG8cPGF E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFHwCE6tJV2b/2dsb2JhbABSpzN3qwWeGoYwBIcsileEd4RAhwI X-IronPort-AV: E=Sophos;i="4.65,434,1304294400"; d="scan'208";a="470822500" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-1.cisco.com with ESMTP; 27 Jun 2011 21:06:12 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5RL6Cwa002892; Mon, 27 Jun 2011 21:06:12 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Jun 2011 16:06:12 -0500 Received: from 10.21.125.90 ([10.21.125.90]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([128.107.191.87]) with Microsoft Exchange Server HTTP-DAV ; Mon, 27 Jun 2011 21:06:11 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Mon, 27 Jun 2011 16:08:35 -0500 From: Benson Schliesser To: Julien Laganier , Message-ID: Thread-Topic: [Int-area] WGLC for http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required-00 Thread-Index: Acw1DmBlI7DvUICbp0igzWVE2F5EmQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Jun 2011 21:06:12.0493 (UTC) FILETIME=[0B74F3D0:01CC350E] Cc: draft-ietf-intarea-ipv6-required@tools.ietf.org Subject: Re: [Int-area] WGLC for http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required-00 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 21:06:13 -0000 On 6/23/11 5:39 PM, "Julien Laganier" wrote: > We are hereby issuing a 2 weeks WGLC of the document "IPv6 Support > Required for all IP-capable nodes" available at > http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required-00 Overall I support the spirit of this draft. There is no doubt in my mind that IPv6 is needed, is trending up in deployment, and must therefore be a basic capability of a modern router. I do share some of Fred's concern about "updating" old documents. Specifically, I'm wary both of legitimate confusion interpreting other IETF documents and of semantic games that might result. I'm also skeptical of any IETF document that attempts to set "policy" rather than define a standard. This draft seems to be somewhat vague in a number of ways, appearing more as a policy statement rather than concrete definition of requirements. Thus it is my hope that this draft evolves or leads to a future document, such as a consolidated dual-stack router requirements document, which specifies detailed requirements (with references) that can be objectively evaluated as a standard. Cheers, -Benson From jshire@hyduke.com Mon Jun 27 14:58:28 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED56F21F86EC for ; Mon, 27 Jun 2011 14:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1OU8+nrkm7F for ; Mon, 27 Jun 2011 14:58:28 -0700 (PDT) Received: from mail.hyduke.net (mail.hyduke.net [67.226.164.185]) by ietfa.amsl.com (Postfix) with ESMTP id E969621F86E8 for ; Mon, 27 Jun 2011 14:58:24 -0700 (PDT) Received: from HYDSRV6.hyduke.net (192.168.10.44) by nsk1mx02.hyduke.net (192.168.10.49) with Microsoft SMTP Server id 8.1.436.0; Mon, 27 Jun 2011 15:52:55 -0600 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 27 Jun 2011 15:58:22 -0600 Message-ID: <5D359AE112816C46AE85C0494190F9730285A39A@hydsrv6.hyduke.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] WGLC for http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required-00 Thread-Index: Acw1DmBlI7DvUICbp0igzWVE2F5EmQABdU1g References: From: Joshua Shire To: "Benson Schliesser" , "Julien Laganier" , X-TM-AS-Product-Ver: SMEX-8.0.0.4125-6.500.1024-18224.005 X-TM-AS-Result: No--9.354200-4.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: draft-ietf-intarea-ipv6-required@tools.ietf.org Subject: Re: [Int-area] WGLC for http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required-00 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 21:58:29 -0000 " IPv6 support MUST be equivalent or better in quality and functionality when compared to IPv4 support in an IP implementation." >From a business prospective, it would be very beneficial to be able to pick up a piece of kit and know that all of its features are fully implemented in both 6 and 4 (as opposed to seeing something listed on a spec sheet, buying because of it, trying to get it working, then calling in to tech support only to have them tell you that this feature hasn't been implemented in ipv6 yet and isn't planned until Q3 next year). Thanks, Joshua -----Original Message----- From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On Behalf Of Benson Schliesser Sent: Monday, June 27, 2011 3:09 PM To: Julien Laganier; int-area@ietf.org Cc: draft-ietf-intarea-ipv6-required@tools.ietf.org Subject: Re: [Int-area] WGLC for http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required-00 On 6/23/11 5:39 PM, "Julien Laganier" wrote: > We are hereby issuing a 2 weeks WGLC of the document "IPv6 Support > Required for all IP-capable nodes" available at > http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required-00 Overall I support the spirit of this draft. There is no doubt in my mind that IPv6 is needed, is trending up in deployment, and must therefore be a basic capability of a modern router. I do share some of Fred's concern about "updating" old documents. Specifically, I'm wary both of legitimate confusion interpreting other IETF documents and of semantic games that might result. I'm also skeptical of any IETF document that attempts to set "policy" rather than define a standard. This draft seems to be somewhat vague in a number of ways, appearing more as a policy statement rather than concrete definition of requirements. Thus it is my hope that this draft evolves or leads to a future document, such as a consolidated dual-stack router requirements document, which specifies detailed requirements (with references) that can be objectively evaluated as a standard. Cheers, -Benson _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area From heard@pobox.com Mon Jun 27 21:00:17 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A8E21F8640 for ; Mon, 27 Jun 2011 21:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBmsMHgi07Co for ; Mon, 27 Jun 2011 21:00:16 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6C121F863D for ; Mon, 27 Jun 2011 21:00:16 -0700 (PDT) Received: (qmail 32097 invoked from network); 27 Jun 2011 21:00:15 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 27 Jun 2011 21:00:15 -0700 Date: Mon, 27 Jun 2011 21:00:15 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: INT-AREA WG In-Reply-To: Message-ID: References: <4DE8118E.6030703@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [Int-area] IPv4 ID update draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 04:00:17 -0000 >>>>> On Wed, 22 Jun 2011, Julien Laganier wrote: Julien> Because we' re talking about updating a venerable protocol I Julien> want to make sure that we get the necessary level of review Julien> for this draft before we forward it to IESG for publication Julien> as proposed standard. I've asked a number of people to have Julien> a look at it, and below is the first review from Erik Julien> (Thanks!) Here is an unsolicited review of the draft in question (draft-ietf-intarea-ipv4-id-update-02) from an outsider. I agree with the specification changes made in Section 6.1, which disallow the use of the IPv4 ID field for purposes other than fragmentation and reassembly. I agree that these changes will have little, if any, impact on fielded implementations, and may indeed help to mitigate actual operational problems documented in RFC 4963, "IPv4 Reassembly Errors at High Data Rates." However, I do NOT agree with Section 6.2, and I believe that the changes proposed in that section should be dropped, or at the very least, better justification needs to be provided for making these non-backward compatible to a nearly 30 year old protocol. In particular: - The proposed ban on overlapping IPv4 fragments is ill-motivated. Section 6.2 cites RFC 4963 to support the assertion that overlapping fragments are a security hazard, but I was not able to find any discussion of overlapping fragments in that RFC. This subject _is_ discussed in RFC 1858 and RFC 3128, but the hazards discussed those RFCs result in middlebox packet filtering failures and can be addressed by localized changes to the middleboxes, without making a global change to IPv4. If there is any literature that documents a security hazard from overlapping fragments in a properly implemented system that defers header processing until a complete IP datagram is fully reassembled, I have not been able to find it. Indeed, it should be noted that overlapping fragments are in principle legitimately possible if a non-atomic datagram is duplicated within the network and the duplicates are then fragmented in different ways. - The proposed ban on reusing the same ID when retransmitting an identical datagram is ill-motivated because in this case repetition does not lead to the type of reassembly errors documented in RFC 4963. The errors discussed in RFC 4963 arise when different non-atomic datagrams have the same ID. - The proposed change to allow the ID field of non-atomic datagrams to be changed in transit is ill-motivated. Erik Nordmark's review (and the dubsequent discussion) has already dealt with this point at length. Recently (albeit another context) Brian E Carpenter wrote: Brian> We shouldn't be spending any effort on polishing the IPv4 Brian> heirloom, except for vital security or operational fixes. I agree with the changes proposed in Section 6.1 because they provide fixes for a documented operational issue. I disagree with the changes in Section 6.2 because they amount to unnecessary (and probably even harmful) polishing of the IPv4 heirloom. Thanks and regards, Mike Heard P.S. One nit: the next-to-last paragraph of Section 4 states: "The IPv4 ID field can also be used to validate payloads of ICMP responses as matching the originally transmitted datagram at a host [RFC4963]." I was not able to find any such discussion in RFC 4963, and I think the reference should either be corrected or dropped. From Fred.L.Templin@boeing.com Tue Jun 28 10:04:14 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCA111E80F4 for ; Tue, 28 Jun 2011 10:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHnrLYr00+f3 for ; Tue, 28 Jun 2011 10:04:13 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9B45611E80C3 for ; Tue, 28 Jun 2011 10:04:13 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p5SH44YM013890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Jun 2011 10:04:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id p5SH44A3015011; Tue, 28 Jun 2011 10:04:04 -0700 (PDT) Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p5SH42dc014929 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 28 Jun 2011 10:04:02 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Tue, 28 Jun 2011 10:03:55 -0700 From: "Templin, Fred L" To: Julien Laganier , "int-area@ietf.org" Date: Tue, 28 Jun 2011 10:03:54 -0700 Thread-Topic: [Int-area] intarea status update before IETF-81 Thread-Index: Acw06pae0nNLrfGvTV2lvD+rrIMk/QAyX45w Message-ID: References: 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: "int-ads@tools.ietf.org" Subject: Re: [Int-area] intarea status update before IETF-81 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 17:04:14 -0000 Julien & Scott, At the last meeting, there was a scheduled timeslot for IRON, but earlier presentations ran over and we ran out of time. I would therefore assume that the missed timeslot for IRON should carry over to this meeting, hence there is something on our plate. Since IRON represents a proposed major way forward for the Internet, it would also seem that face to face discussion is necessary. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: int-area-bounces@ietf.org=20 > [mailto:int-area-bounces@ietf.org] On Behalf Of Julien Laganier > Sent: Monday, June 27, 2011 9:52 AM > To: int-area@ietf.org > Cc: int-ads@tools.ietf.org > Subject: [Int-area] intarea status update before IETF-81 >=20 > Folks, >=20 > at this point we do not have anything on our plate that would require > face to face discussion thus the INTAREA WG will not meet in Quebec. >=20 > Please see below the status for our current WG drafts: >=20 > Active: >=20 > - draft-ietf-intarea-ipv4-id-update =3D> requested expert reviews, > document shepherd working on-list with Joe to resolve issues that have > been brought up. > - draft-ietf-intarea-ipv6-required =3D> currently in WGLC >=20 > IESG Processing: >=20 > - draft-ietf-intarea-router-alert-considerations =3D> publication > requested, currently resolving comments from sponsoring AD >=20 > RFC-Editor's Queue: >=20 > - draft-ietf-intarea-server-logging-recommendations =3D> in EDIT state. > - draft-ietf-intarea-shared-addressing-issues =3D> in AUTH48, awaiting > final approval from ADs. >=20 > Expired: > draft-ietf-intarea-tunnels =3D> no activity. >=20 > Below is the status of email discussions regarding non-WG drafts: >=20 > - draft-fleischhauer-ipv4-addr-saving-00 =3D> currently ongoing > discussion regarding the usefulness of the proposal. No conclusion > yet. >=20 > --julien & scott > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > = From wesley.george@twcable.com Tue Jun 28 10:09:42 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC3E21F8698 for ; Tue, 28 Jun 2011 10:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.363 X-Spam-Level: X-Spam-Status: No, score=-0.363 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teYB0ZpKt6BG for ; Tue, 28 Jun 2011 10:09:42 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id A777321F8696 for ; Tue, 28 Jun 2011 10:09:37 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.65,437,1304308800"; d="scan'208";a="243520604" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 28 Jun 2011 13:08:34 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Tue, 28 Jun 2011 13:09:36 -0400 From: "George, Wesley" To: Benson Schliesser , Julien Laganier , "int-area@ietf.org" Date: Tue, 28 Jun 2011 13:09:36 -0400 Thread-Topic: [Int-area] WGLC for http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required-00 Thread-Index: Acw1DmBlI7DvUICbp0igzWVE2F5EmQAftlhw Message-ID: <34E4F50CAFA10349A41E0756550084FB0A7F859B@PRVPEXVS04.corp.twcable.com> References: 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: "draft-ietf-intarea-ipv6-required@tools.ietf.org" Subject: Re: [Int-area] WGLC for http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required-00 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 17:09:42 -0000 -----Original Message----- From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On Behal= f Of Benson Schliesser Sent: Monday, June 27, 2011 5:09 PM To: Julien Laganier; int-area@ietf.org Cc: draft-ietf-intarea-ipv6-required@tools.ietf.org Subject: Re: [Int-area] WGLC for http://tools.ietf.org/html/draft-ietf-inta= rea-ipv6-required-00 Overall I support the spirit of this draft. There is no doubt in my mind that IPv6 is needed, is trending up in deployment, and must therefore be a basic capability of a modern router. WEG> Thanks I do share some of Fred's concern about "updating" old documents. Specifically, I'm wary both of legitimate confusion interpreting other IETF documents and of semantic games that might result. WEG> I think that the old document updates are important, but I'd like to t= ry to address this concern if I can. I'd be happy to discuss changes to the= existing text that better clarifies it in order to eliminate confusion and= semantic games. I'm also skeptical of any IETF document that attempts to set "policy" rathe= r than define a standard. This draft seems to be somewhat vague in a number of ways, appearing more as a policy statement rather than concrete definition of requirements. WEG> Well, the only policy an IETF document can really set is IETF policy. = The policy statement (what IETF should do/change/not do within their protoc= ol work) has been removed from this version per feedback we received in Pra= gue that such things are not appropriate within a standards-track document.= I and my fellow authors view what remains in this document as technical gu= idance for implementers. Technical guidance need not always be in the form = of a protocol definition. In much the same way as IETF says "considered har= mful" or "not recommended" or any of the other things we say before we trul= y declare something historic when a given implementation has been supersede= d by something else, we are providing technical guidance that IPv4-only dev= ices are not generally a good technical solution due to the exhaustion of I= Pv4. Regarding vagueness, again, I'm open to text suggestions to address, but we= did purposely keep this a bit less specific because there is no way to kno= w every possible use case, every possible exception, and everyone realizes = that all IETF standards are open to interpretation during implementation no= matter how ironclad the requirements are. Also, since the IETF is not a ce= rtification organization, the onus is on each person writing the checks to = do their own testing to verify that what they're buying does what they want= it to do. Thus it is my hope that this draft evolves or leads to a future document, such as a consolidated dual-stack router requirements document, which specifies detailed requirements (with references) that can be objectively evaluated as a standard. WEG> If enough people believe that to be necessary, it'll get written. Howe= ver it likely won't be by me. The technical standards for both IPv4 and IPv= 6 are already well-defined separately. The appropriate detailed IPv6 requir= ements and standards (unless you have additional recommendations that you b= elieve to be missing) are identified by this document via the documents tha= t it references and in turn, their references, especially omnibus documents= like node-req-bis and 6204, which have multiple pages of normative and inf= ormative references related to IPv6 implementation details. I simply don't = see the need to repackage those technical standards in a slightly different= format to make the suggested dual-stack router requirements document. That said, your private comment to the authors leads me to interpret your c= omments slightly differently, that this document should map IPv4 features a= nd functions to IPv6 features and functions in order to more clearly define= "equivalent or better in quality and functionality" between the two protoc= ols. There was considerable debate about this, where we started getting int= o whether we should say anything about NAT66, whether a direct 1:1 mapping = between IPv4 functions and IPv6 functions is really necessary, etc. The lan= guage used was a result of that discussion. At least by my interpretation, = the WG specifically did not want to get into that level of detail in this d= ocument. I suppose that it might make sense to expect that drafts which define a giv= en IPv6 feature should identify the IPv4 feature that it is analogous to/re= places/eliminates the need for, and I would be willing to incorporate that = recommendation into a BCP document that speaks to IETF policy in this area = if people believe that would be helpful. Thanks again for the feedback, 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 scott.brim@gmail.com Tue Jun 28 10:43:41 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38BE011E8117 for ; Tue, 28 Jun 2011 10:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsUZcsZAcHMi for ; Tue, 28 Jun 2011 10:43:40 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A547211E80FD for ; Tue, 28 Jun 2011 10:43:40 -0700 (PDT) Received: by iye7 with SMTP id 7so461015iye.31 for ; Tue, 28 Jun 2011 10:43:40 -0700 (PDT) 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=rxLW2FoKkyNEheDulagtXHslIpa9aC7tdiweNYYd/5g=; b=quO0qH+sxanYhEUriFvQ/iQhyAUG0rT+y4UebOn5d1bcILtF/45JrdgpfWkVWUGYdq Ivb89x6S36ICSU0qnXlCzNKF/26El6ZVgYOXTwEcUeuXGxQikm2RRdHMukHIdYYQzDr1 054mdHdGDYDvsUg8rZ00jPLEsG9+NfQggBR70= MIME-Version: 1.0 Received: by 10.42.246.131 with SMTP id ly3mr9675239icb.495.1309283019943; Tue, 28 Jun 2011 10:43:39 -0700 (PDT) Received: by 10.231.15.198 with HTTP; Tue, 28 Jun 2011 10:43:39 -0700 (PDT) In-Reply-To: References: Date: Tue, 28 Jun 2011 13:43:39 -0400 Message-ID: From: Scott Brim To: "Templin, Fred L" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Julien Laganier , "int-area@ietf.org" , "int-ads@tools.ietf.org" Subject: [Int-area] intarea status update before IETF-81 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 17:43:41 -0000 On Tuesday, June 28, 2011, Templin, Fred L wrot= e: > At the last meeting, there was a scheduled timeslot for > IRON, but earlier presentations ran over and we ran out > of time. I would therefore assume that the missed timeslot > for IRON should carry over to this meeting, hence there is > something on our plate. The confusion about strategy at the last meeting was what prompted us to propose new ways of deciding when face-to-face time should be used. =A0IRON was one of the main topics targeted for discussion on the mailing list to see if f2f time was warranted. > Since IRON represents a proposed > major way forward for the Internet, it would also seem > that face to face discussion is necessary. Except that discussion was solicited on the list and kind of fizzled. I injected what I said about NEMO in hopes that someone else would pick it up and respond somehow, but no one did. In general, either people understand it, or it's not urgent to them. If topics aren't urgent for people, then imho giving them face-to-face time isn't urgent either. Another thing: I will not be in Qu=E9bec and there is a good chance Julien won't be, so having a meeting will require an AD to invest precious time in chairing it. Someone else such as you could chair it, but then why have it be a WG meeting? You want a way forward for IRON. You need to drum up support and get collaborators. I suggest, instead of using up IETF money on an approach that only a few have expressed any interest in, that you invite people out to talk about next steps, issues, promote collaboration, etc. Who is implementing? What platforms? If you don't have enough implementors, tactically what can you do to get more? When can you do an interoperability test? And so on. Create some multi-stakeholder enthusiasm and a group that will provide support for it in the IETF. How does that sound? Scott From jnc@mercury.lcs.mit.edu Tue Jun 28 11:28:20 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF3C11E8149 for ; Tue, 28 Jun 2011 11:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVDmQJP+wHxs for ; Tue, 28 Jun 2011 11:28:20 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 4215811E8152 for ; Tue, 28 Jun 2011 11:28:20 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 439F118C129; Tue, 28 Jun 2011 14:28:19 -0400 (EDT) To: int-area@ietf.org Message-Id: <20110628182819.439F118C129@mercury.lcs.mit.edu> Date: Tue, 28 Jun 2011 14:28:19 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [Int-area] intarea status update before IETF-81 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 18:28:20 -0000 > From: Scott Brim > You want a way forward for IRON. You need to drum up support and get > collaborators. Agreed. Trying to make the IETF the dog doesn't work - it needs to be the tail, as any number of things which haven't been widely taken up have shown. Noel From Fred.L.Templin@boeing.com Tue Jun 28 16:01:53 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8547B11E80F2 for ; Tue, 28 Jun 2011 16:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwSmq5ZLoC56 for ; Tue, 28 Jun 2011 16:01:53 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id DB27E11E80C4 for ; Tue, 28 Jun 2011 16:01:52 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p5SN1nOk026125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Jun 2011 16:01:50 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p5SN1mD5014804; Tue, 28 Jun 2011 18:01:48 -0500 (CDT) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p5SN1m0X014772 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 28 Jun 2011 18:01:48 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Tue, 28 Jun 2011 16:01:40 -0700 From: "Templin, Fred L" To: Noel Chiappa , "int-area@ietf.org" Date: Tue, 28 Jun 2011 16:01:38 -0700 Thread-Topic: [Int-area] intarea status update before IETF-81 Thread-Index: Acw1wSYDQFacGaMgTOmcv8UpbxKU0wAJaCzQ Message-ID: References: <20110628182819.439F118C129@mercury.lcs.mit.edu> In-Reply-To: <20110628182819.439F118C129@mercury.lcs.mit.edu> 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: [Int-area] intarea status update before IETF-81 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 23:01:53 -0000 Noel,=20 > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 > Sent: Tuesday, June 28, 2011 11:28 AM > To: int-area@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: [Int-area] intarea status update before IETF-81 >=20 > > From: Scott Brim > =20 > > You want a way forward for IRON. You need to drum up=20 > support and get > > collaborators.=20 >=20 > Agreed. Trying to make the IETF the dog doesn't work - it=20 > needs to be the > tail, Maybe, but it seems like the IETF should at least know which dog is doing the wagging - and whether that is even the best dog to be attached to or whether there is a better dog. Thanks - Fred fred.l.templin@boeing.com > as any number of things which haven't been widely taken up have > shown. >=20 > Noel > = From scott.brim@gmail.com Tue Jun 28 16:33:07 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0CAD1F0C36 for ; Tue, 28 Jun 2011 16:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6nkhue+p66r for ; Tue, 28 Jun 2011 16:33:07 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 228951F0C35 for ; Tue, 28 Jun 2011 16:33:07 -0700 (PDT) Received: by iwn39 with SMTP id 39so761640iwn.31 for ; Tue, 28 Jun 2011 16:33:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=WIhdkBCBL/IJQB9atTjp6KKGZkDCWND96k0AxZltwSA=; b=SmiPZZu1+8KVYqTpgS1hYAILs5jwaufCjFK+MHTDv/G0SuQGKsuWHZ1HdPVk7zzQmn U1ebpb/utOWcVxYyVBMq3BgW7TeNNXQPY4u/8Pf0xRlcj/SXdRjAEWiTMn8+lSrjkIma j4zGRL3wgYiMPGrUSoCSbVEKlCTAN5us6VjPw= MIME-Version: 1.0 Received: by 10.231.63.67 with SMTP id a3mr120597ibi.94.1309303986338; Tue, 28 Jun 2011 16:33:06 -0700 (PDT) Received: by 10.231.15.198 with HTTP; Tue, 28 Jun 2011 16:33:06 -0700 (PDT) Received: by 10.231.15.198 with HTTP; Tue, 28 Jun 2011 16:33:06 -0700 (PDT) Date: Tue, 28 Jun 2011 19:33:06 -0400 Message-ID: From: Scott Brim To: "Templin, Fred L" Content-Type: multipart/alternative; boundary=000e0cd57296023cc504a6ce172f Cc: "int-area@ietf.org" , Noel Chiappa Subject: Re: [Int-area] intarea status update before IETF-81 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 23:33:07 -0000 --000e0cd57296023cc504a6ce172f Content-Type: text/plain; charset=ISO-8859-1 On Jun 28, 2011 7:02 PM, "Templin, Fred L" wrote: > > Noel, > > > -----Original Message----- > > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu] > > Sent: Tuesday, June 28, 2011 11:28 AM > > To: int-area@ietf.org > > Cc: jnc@mercury.lcs.mit.edu > > Subject: Re: [Int-area] intarea status update before IETF-81 > > > > > From: Scott Brim > > > > > You want a way forward for IRON. You need to drum up > > support and get > > > collaborators. > > > > Agreed. Trying to make the IETF the dog doesn't work - it > > needs to be the > > tail, > > Maybe, but it seems like the IETF should at least know > which dog is doing the wagging - and whether that is > even the best dog to be attached to or whether there > is a better dog. We could repeat what RRG tried to do but if we start from where we are now we would take the same amount of time with no guarantee that we would get better results. What does a WG have that an RG does not? Dave Clark said "if it has to work when you're done it's engineering, not research." I think the main asset of a WG is applicability requirements to measure against. If you could get three operators to say they would deploy your approach right away if they could, that would be great. If you're trying to get "the IETF" to proclaim what's best for the Internet we won't be able to reach a conclusion. Imho. --000e0cd57296023cc504a6ce172f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jun 28, 2011 7:02 PM, "Templin, Fred L" <Fred.L.Templin@boeing.com> wrote:
>
> Noel,
>
> > -----Original Message-----
> > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]
> > Sent: Tuesday, June 28, 2011 11:28 AM
> > To: int-area@ietf.org > > Cc: jnc@mercury.lcs.mi= t.edu
> > Subject: Re: [Int-area] intarea status update before IETF-81
> >
> > =A0 =A0 > From: Scott Brim <scott.brim@gmail.com>
> >
> > =A0 =A0 > You want a way forward for IRON. You need to drum up=
> > support and get
> > =A0 =A0 > collaborators.
> >
> > Agreed. Trying to make the IETF the dog doesn't work - it
> > needs to be the
> > tail,
>
> Maybe, but it seems like the IETF should at least know
> which dog is doing the wagging - and whether that is
> even the best dog to be attached to or whether there
> is a better dog.

We could repeat what RRG tried to do but if we start from where we are n= ow we would take the same amount of time with no guarantee that we would ge= t better results.=A0 What does a WG have that an RG does not? Dave Clark sa= id "if it has to work when you're done it's engineering, not r= esearch." I think the main asset of a WG is applicability requirements= to measure against. If you could get three operators to say they would dep= loy your approach right away if they could, that would be great. If you'= ;re trying to get "the IETF" to proclaim what's best for the = Internet we won't be able to reach a conclusion. Imho.

--000e0cd57296023cc504a6ce172f-- From wwwrun@rfc-editor.org Tue Jun 28 15:35:11 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D954111E818C; Tue, 28 Jun 2011 15:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.34 X-Spam-Level: X-Spam-Status: No, score=-102.34 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkbNN4EriS4z; Tue, 28 Jun 2011 15:35:11 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 6A73611E818A; Tue, 28 Jun 2011 15:35:11 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4D18698C522; Tue, 28 Jun 2011 15:35:11 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110628223511.4D18698C522@rfc-editor.org> Date: Tue, 28 Jun 2011 15:35:11 -0700 (PDT) X-Mailman-Approved-At: Tue, 28 Jun 2011 16:44:23 -0700 Cc: int-area@ietf.org, rfc-editor@rfc-editor.org Subject: [Int-area] RFC 6269 on Issues with IP Address Sharing X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 22:35:12 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6269 Title: Issues with IP Address Sharing Author: M. Ford, Ed., M. Boucadair, A. Durand, P. Levis, P. Roberts Status: Informational Stream: IETF Date: June 2011 Mailbox: ford@isoc.org, mohamed.boucadair@orange-ftgroup.com, adurand@juniper.net, pierre.levis@orange-ftgroup.com, roberts@isoc.org Pages: 29 Characters: 71660 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-intarea-shared-addressing-issues-05.txt URL: http://www.rfc-editor.org/rfc/rfc6269.txt The completion of IPv4 address allocations from IANA and the Regional Internet Registries (RIRs) is causing service providers around the world to question how they will continue providing IPv4 connectivity service to their subscribers when there are no longer sufficient IPv4 addresses to allocate them one per subscriber. Several possible solutions to this problem are now emerging based around the idea of shared IPv4 addressing. These solutions give rise to a number of issues, and this memo identifies those common to all such address sharing approaches. Such issues include application failures, additional service monitoring complexity, new security vulnerabilities, and so on. Solution-specific discussions are out of scope. Deploying IPv6 is the only perennial way to ease pressure on the public IPv4 address pool without the need for address sharing mechanisms that give rise to the issues identified herein. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Area Working Group 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 joelja@bogus.com Tue Jun 28 23:17:38 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3245B22800F for ; Tue, 28 Jun 2011 23:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G79rhplU6qIx for ; Tue, 28 Jun 2011 23:17:37 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 75CB422800E for ; Tue, 28 Jun 2011 23:17:37 -0700 (PDT) Received: from [192.168.1.171] (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 p5T6HWv6018638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 29 Jun 2011 06:17:33 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: Date: Tue, 28 Jun 2011 23:17:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <86F4C5C9-4E16-423B-80E8-4DF13D8BBA8F@bogus.com> References: <20110628182819.439F118C129@mercury.lcs.mit.edu> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 29 Jun 2011 06:17:34 +0000 (UTC) Cc: "int-area@ietf.org" , Noel Chiappa Subject: Re: [Int-area] intarea status update before IETF-81 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 06:17:38 -0000 On Jun 28, 2011, at 4:01 PM, Templin, Fred L wrote: > Noel,=20 >=20 >> -----Original Message----- >> From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 >> Sent: Tuesday, June 28, 2011 11:28 AM >> To: int-area@ietf.org >> Cc: jnc@mercury.lcs.mit.edu >> Subject: Re: [Int-area] intarea status update before IETF-81 >>=20 >>> From: Scott Brim >>=20 >>> You want a way forward for IRON. You need to drum up=20 >> support and get >>> collaborators.=20 >>=20 >> Agreed. Trying to make the IETF the dog doesn't work - it=20 >> needs to be the >> tail, >=20 > Maybe, but it seems like the IETF should at least know > which dog is doing the wagging - and whether that is > even the best dog to be attached to or whether there > is a better dog. I would rather not be witness to a beauty contest between shim6/hip lisp = and iron... we have plenty of ideas yet a thousand flowers have not bloomed from = them, on the other hand overlay networks flourish on the internet, = mostly at or above the transport. To my mind, I don't think the incentives or economic mechanics that = might preclude the deployment of an overlay which replicates lower layer = functionality but does not except at the margins provide incremental = benifits to early adopters are a worthwhile topic for the int area. Implementation and utilization really strike me as the next logical step = for something that's come out of the IRTF. > Thanks - Fred > fred.l.templin@boeing.com > enfit >> as any number of things which haven't been widely taken up have >> shown. >>=20 >> Noel >>=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area >=20 From iesg-secretary@ietf.org Wed Jun 29 07:07:59 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34DA011E808E; Wed, 29 Jun 2011 07:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.363 X-Spam-Level: X-Spam-Status: No, score=-102.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxSVnNb3u81C; Wed, 29 Jun 2011 07:07:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDBE111E8076; Wed, 29 Jun 2011 07:07:58 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110629140758.14503.57842.idtracker@ietfa.amsl.com> Date: Wed, 29 Jun 2011 07:07:58 -0700 Cc: int-area@ietf.org Subject: [Int-area] Last Call: (IP Router Alert Considerations and Usage) to BCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 14:07:59 -0000 The IESG has received a request from the Internet Area Working Group WG (intarea) to consider the following document: - 'IP Router Alert Considerations and Usage' as a BCP 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 2011-07-13. 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 The IP Router Alert Option is an IP option that alerts transit routers to more closely examine the contents of an IP packet. Resource reSerVation Protocol (RSVP), Pragmatic General Multicast (PGM), Internet Group Management Protocol (IGMP), Multicast Listener Discovery (MLD), Multicast Router Discovery (MRD) and General Internet Signalling Transport (GIST) are some of the protocols that make use of the IP Router Alert option. This document discusses security aspects and usage guidelines around the use of the current IP Router Alert option. Specifically, it provides recommendation against using the Router Alert in the end-to-end open Internet as well as identify controlled environments where protocols depending on Router Alert can be used safely. It also provides recommendation about protection approaches for Service Providers. Finally it provides brief guidelines for Router Alert implementation on routers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-intarea-router-alert-considerations/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-intarea-router-alert-considerations/ No IPR declarations have been submitted directly on this I-D. From Fred.L.Templin@boeing.com Wed Jun 29 09:56:50 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAD49E804A for ; Wed, 29 Jun 2011 09:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5moGxVU+B78c for ; Wed, 29 Jun 2011 09:56:48 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id E96969E800B for ; Wed, 29 Jun 2011 09:56:47 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p5TGuhoV007481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Jun 2011 09:56:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id p5TGuhEL015581; Wed, 29 Jun 2011 11:56:43 -0500 (CDT) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p5TGufbO015513 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 29 Jun 2011 11:56:41 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Wed, 29 Jun 2011 09:56:32 -0700 From: "Templin, Fred L" To: Scott Brim Date: Wed, 29 Jun 2011 09:56:30 -0700 Thread-Topic: [Int-area] intarea status update before IETF-81 Thread-Index: Acw167k5JW7OkXQySLuHXn5bUkV0VwAjVIdw Message-ID: References: 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_E1829B60731D1740BB7A0626B4FAF0A65C6B1369DFXCHNW01Vnwnos_" MIME-Version: 1.0 Cc: "int-area@ietf.org" , Noel Chiappa Subject: Re: [Int-area] intarea status update before IETF-81 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 16:56:50 -0000 --_000_E1829B60731D1740BB7A0626B4FAF0A65C6B1369DFXCHNW01Vnwnos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Scott, ________________________________ From: Scott Brim [mailto:scott.brim@gmail.com] Sent: Tuesday, June 28, 2011 4:33 PM To: Templin, Fred L Cc: int-area@ietf.org; Noel Chiappa Subject: Re: [Int-area] intarea status update before IETF-81 On Jun 28, 2011 7:02 PM, "Templin, Fred L" > wrote: > > Noel, > > > -----Original Message----- > > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu] > > Sent: Tuesday, June 28, 2011 11:28 AM > > To: int-area@ietf.org > > Cc: jnc@mercury.lcs.mit.edu > > Subject: Re: [Int-area] intarea status update before IETF-81 > > > > > From: Scott Brim > > > > > > You want a way forward for IRON. You need to drum up > > support and get > > > collaborators. > > > > Agreed. Trying to make the IETF the dog doesn't work - it > > needs to be the > > tail, > > Maybe, but it seems like the IETF should at least know > which dog is doing the wagging - and whether that is > even the best dog to be attached to or whether there > is a better dog. We could repeat what RRG tried to do but if we start from where we are now = we would take the same amount of time with no guarantee that we would get b= etter results. No, I'm not looking for a repeat of the RRG experience. What came out of th= e RRG was that two solution alternatives were developed within the framewor= k of the group, while a third cut out of the process early in the game to g= o off and do their own thing. But, cutting out early doesn't necessarily me= an that the solution was the best. What does a WG have that an RG does not? Workers? Or, at least a community of engineers with interest in practical m= atters. Dave Clark said "if it has to work when you're done it's engineering, not = research." My job title is "research Engineer", but I spell it with a little 'r' and a= big 'E'. I don't get involved with work that I'm not convinced can be appl= ied in operational practice. I develop prototype code to test the concepts,= however I no longer work for a major host/router manufacturer and hence ha= ve no direct path into shipping implementations. As with anyone else, my ca= pabilities are finite - hence, I need to have workers who are willing to he= lp come on board. And, what better place to find workers than in a working = group? I think the main asset of a WG is applicability requirements to measure ag= ainst. I have published three documents that talk about use-case scenarios (RFC613= 9, draft-templin-iron-pm, and draft-templin-ironmike). I am fairly sure the= re would be something in those which most operators can identify with. If you could get three operators to say they would deploy your approach ri= ght away if they could, that would be great. If you're trying to get "the I= ETF" to proclaim what's best for the Internet we won't be able to reach a c= onclusion. Imho. I agree that it would be great to have the operators come alongside this wo= rk and at least give it a closer look. The operators might want to also ask= whether they can form their own opinions on what solutions are best suited= to their needs or whether they need to defer to vendors who are pushing so= lutions that may or may not be well suited. Thanks - Fred --_000_E1829B60731D1740BB7A0626B4FAF0A65C6B1369DFXCHNW01Vnwnos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Scott,

From: Scott Brim [mailto:scott.brim@g= mail.com]=20
Sent: Tuesday, June 28, 2011 4:33 PM
To: Templin, Fr= ed=20 L
Cc: int-area@ietf.org; Noel Chiappa
Subject: Re:=20 [Int-area] intarea status update before IETF-81


On Jun 28, 2011 7:02 PM, "Templin, Fred L" <Fred.L.Templin@boeing.com&g= t;=20 wrote:
>
> Noel,
>
> > -----Original=20 Message-----
> > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]
&= gt;=20 > Sent: Tuesday, June 28, 2011 11:28 AM
> > To: int-area@ietf.org
> > Cc: = jnc@mercury.lcs.mit.edu
&g= t; >=20 Subject: Re: [Int-area] intarea status update before IETF-81
>=20 >
> >     > From: Scott Brim <scott.brim@gmail.com>
>= =20 >
> >     > You want a way forward for IRON. You= need=20 to drum up
> > support and get
> >     >=20 collaborators.
> >
> > Agreed. Trying to make the IETF = the=20 dog doesn't work - it
> > needs to be the
> >=20 tail,
>
> Maybe, but it seems like the IETF should at least=20 know
> which dog is doing the wagging - and whether that is
>= even=20 the best dog to be attached to or whether there
> is a better dog.<= /P>

We could repeat what RRG tried to do but if we start from where we are= now=20 we would take the same amount of time with no guarantee that we would get= =20 better results.  

N= o, I'm not=20 looking for a repeat of the RRG experience. What came out of the RRG was=20 that two solution alternatives were developed within the framework of = the=20 group, while a third cut out of the process early in the game to go off and= do=20 their own thing. But, cutting out early doesn't necessarily mean that the=20 solution was the best.

What does a WG have that an RG does not? 

W= orkers? Or,=20 at least a community of engineers with interest in practical=20 matters.

 Dave Clark said "if it h= as to=20 work when you're done it's engineering, not research." 

M= y job title=20 is "research Engineer", but I spell it with a little 'r' and a big 'E'. I d= on't=20 get involved with work that I'm not convinced can be applied in operational= =20 practice. I develop prototype code to test the concepts, however I no longe= r=20 work for a major host/router manufacturer and hence have no direct path int= o=20 shipping implementations. As with anyone else, my capabilities are finite -= =20 hence, I need to have workers who are willing to help come on board. And, w= hat=20 better place to find workers than in a working group?

 I think the main asset o= f a WG=20 is applicability requirements to measure against. 

I= =20 have published three documents that talk about use-case scenarios (RFC= 6139,=20 draft-templin-iron-pm, and draft-templin-ironmike). I am fairly sure there = would=20 be something in those which most operators can identify=20 with. 

 If you could get three=20 operators to say they would deploy your approach right away if they could= ,=20 that would be great. If you're trying to get "the IETF" to proclaim what'= s=20 best for the Internet we won't be able to reach a conclusion. Imho. 

I= agree that=20 it would be great to have the operators come alongside this work and a= t=20 least give it a closer look. The operators might want to also ask whether t= hey=20 can form their own opinions on what solutions are best suited to their= =20 needs or whether they need to defer to vendors who are pushing solutio= ns=20 that may or may not be well suited.

T= hanks -=20 Fred

--_000_E1829B60731D1740BB7A0626B4FAF0A65C6B1369DFXCHNW01Vnwnos_-- From Fred.L.Templin@boeing.com Wed Jun 29 10:07:31 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C512C9E8073 for ; Wed, 29 Jun 2011 10:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhF0FcHzMRvU for ; Wed, 29 Jun 2011 10:07:31 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id F3D849E8060 for ; Wed, 29 Jun 2011 10:07:30 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p5TH7IQY029286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Jun 2011 12:07:21 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p5TH7IIB012290; Wed, 29 Jun 2011 12:07:18 -0500 (CDT) Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p5TH7IoO012264 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 29 Jun 2011 12:07:18 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Wed, 29 Jun 2011 10:07:09 -0700 From: "Templin, Fred L" To: Joel Jaeggli Date: Wed, 29 Jun 2011 10:07:07 -0700 Thread-Topic: [Int-area] intarea status update before IETF-81 Thread-Index: Acw2JDkma91SVACIT/meXQkVo53iuAAWazLQ Message-ID: References: <20110628182819.439F118C129@mercury.lcs.mit.edu> <86F4C5C9-4E16-423B-80E8-4DF13D8BBA8F@bogus.com> In-Reply-To: <86F4C5C9-4E16-423B-80E8-4DF13D8BBA8F@bogus.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: "int-area@ietf.org" , Noel Chiappa Subject: Re: [Int-area] intarea status update before IETF-81 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 17:07:31 -0000 Hi Joel,=20 > -----Original Message----- > From: Joel Jaeggli [mailto:joelja@bogus.com]=20 > Sent: Tuesday, June 28, 2011 11:18 PM > To: Templin, Fred L > Cc: Noel Chiappa; int-area@ietf.org > Subject: Re: [Int-area] intarea status update before IETF-81 >=20 >=20 > On Jun 28, 2011, at 4:01 PM, Templin, Fred L wrote: >=20 > > Noel,=20 > >=20 > >> -----Original Message----- > >> From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 > >> Sent: Tuesday, June 28, 2011 11:28 AM > >> To: int-area@ietf.org > >> Cc: jnc@mercury.lcs.mit.edu > >> Subject: Re: [Int-area] intarea status update before IETF-81 > >>=20 > >>> From: Scott Brim > >>=20 > >>> You want a way forward for IRON. You need to drum up=20 > >> support and get > >>> collaborators.=20 > >>=20 > >> Agreed. Trying to make the IETF the dog doesn't work - it=20 > >> needs to be the > >> tail, > >=20 > > Maybe, but it seems like the IETF should at least know > > which dog is doing the wagging - and whether that is > > even the best dog to be attached to or whether there > > is a better dog. >=20 > I would rather not be witness to a beauty contest between=20 > shim6/hip lisp and iron... Would you rather that what might be a better overall solution be marginalized and forgotten simply because it was coordinated by an individual contributer rather than pushed by a major vendor? > we have plenty of ideas yet a thousand flowers have not=20 > bloomed from them, on the other hand overlay networks=20 > flourish on the internet, mostly at or above the transport. >=20 > To my mind, I don't think the incentives or economic=20 > mechanics that might preclude the deployment of an overlay=20 > which replicates lower layer functionality but does not=20 > except at the margins provide incremental benifits to early=20 > adopters are a worthwhile topic for the int area. IRON is not just about incentives or economic mechanics, but moreover concerns a major new architectural approach to scalable addressing, mobility, multihoming, traffic engineering, etc. Those topics seem like they should be of interest to the intarea. =20 > Implementation and utilization really strike me as the next=20 > logical step for something that's come out of the IRTF. Great; let's do it. I have some prototype code, but I need to have interested contributers come on board. Thanks - Fred =20 > > Thanks - Fred > > fred.l.templin@boeing.com > > enfit > >> as any number of things which haven't been widely taken up have > >> shown. > >>=20 > >> Noel > >>=20 > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > >=20 >=20 > = From xiaohong.deng@orange-ftgroup.com Thu Jun 30 02:34:27 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3757621F87B9; Thu, 30 Jun 2011 02:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.364 X-Spam-Level: X-Spam-Status: No, score=-1.364 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVeWkcWTMsuU; Thu, 30 Jun 2011 02:34:26 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1717621F87C7; Thu, 30 Jun 2011 02:34:26 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C5A266D8002; Thu, 30 Jun 2011 11:35:42 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id B467B6C8003; Thu, 30 Jun 2011 11:35:42 +0200 (CEST) Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Jun 2011 11:34:27 +0200 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_01CC3708.E42D7332" Date: Thu, 30 Jun 2011 17:34:21 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC01869035@ch-mailsrv.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New draft: draft-deng-v6ops-aplusp-experiment-results Thread-Index: Acw3COQMj0ZpjySmRQmqNcMWb4Scmw== From: To: , X-OriginalArrivalTime: 30 Jun 2011 09:34:27.0435 (UTC) FILETIME=[E7C0F3B0:01CC3708] Cc: mayan@bupt.edu.cn, zhaoqin.bupt@gmail.com, huangxh@buptnet.edu.cn, lan.wang@orange-ftgroup.com, tao.zheng@orange-ftgroup.com Subject: [Int-area] New draft: draft-deng-v6ops-aplusp-experiment-results X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 09:34:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC3708.E42D7332 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, =20 A new draft: draft-deng-v6ops-aplusp-experiment-results-00 has been posted, at http://tools.ietf.org/html/draft-deng-v6ops-aplusp-experiment-results-00 =20 The Abstract of this I-D: =20 This memo describes an implementation of A+P in a provider's IPv6- only network. It provides details of the implementation, network elements, configurations and test results as well. Besides traditional port range A+P, a scattered port sets flavor of A+P is also implemented and verified for the sake of distributing incoming ports among customers in a more discrete way. The test results consist of the application compatibility test, UPnP extension for A+P, port usage and BitTorrent behavior with A+P. =20 This memo focuses on the IPv6 flavor of A+P. =20 Your comments are more than welcomed. =20 Regards, Xiaohong opensource A+P: http://opensourceaplusp.weebly.com/ =20 ------_=_NextPart_001_01CC3708.E42D7332 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

A new draft:=20 draft-deng-v6ops-aplusp-experiment-results-00 has been posted,=20 at

http://tools.ietf.org/html/draft-deng-v6ops-aplusp-experiment-re= sults-00

 

The Abstract of this=20 I-D:

 

 =20 This memo describes an implementation of A+P in a provider's=20 IPv6-

 =20 only network. It provides details of the implementation,=20 network

 =20 elements, configurations and test results as well.=20 Besides

 =20 traditional port range A+P, a scattered port sets flavor of A+P=20 is

 =20 also implemented and verified for the sake of distributing=20 incoming

 =20 ports among customers in a more discrete way. The test=20 results

 =20 consist of the application compatibility test, UPnP extension for = A+P,

 =20 port usage and BitTorrent behavior with=20 A+P.

 

 =20 This memo focuses on the IPv6 flavor of = A+P.

 

Your comments are more than=20 welcomed.

 

Regards,

Xiaohong

opensource = A+P: http://opensourceaplusp.weeb= ly.com/
 
------_=_NextPart_001_01CC3708.E42D7332-- From wwwrun@rfc-editor.org Thu Jun 30 12:47:05 2011 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80BC611E82AB; Thu, 30 Jun 2011 12:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQwmA-zCA1fR; Thu, 30 Jun 2011 12:47:05 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 0502011E809D; Thu, 30 Jun 2011 12:46:56 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id F12E898C535; Thu, 30 Jun 2011 12:46:55 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110630194655.F12E898C535@rfc-editor.org> Date: Thu, 30 Jun 2011 12:46:55 -0700 (PDT) Cc: int-area@ietf.org, rfc-editor@rfc-editor.org Subject: [Int-area] BCP 162, RFC 6302 on Logging Recommendations for Internet-Facing Servers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 19:47:05 -0000 A new Request for Comments is now available in online RFC libraries. BCP 162 RFC 6302 Title: Logging Recommendations for Internet-Facing Servers Author: A. Durand, I. Gashinsky, D. Lee, S. Sheppard Status: Best Current Practice Stream: IETF Date: June 2011 Mailbox: adurand@juniper.net, igor@yahoo-inc.com, donn@fb.com, Scott.Sheppard@att.com Pages: 5 Characters: 10039 See Also: BCP0162 I-D Tag: draft-ietf-intarea-server-logging-recommendations-04.txt URL: http://www.rfc-editor.org/rfc/rfc6302.txt In the wake of IPv4 exhaustion and deployment of IP address sharing techniques, this document recommends that Internet-facing servers log port number and accurate timestamps in addition to the incoming IP address. This memo documents an Internet Best Current Practice. This document is a product of the Internet Area Working Group Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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