From jari.arkko@piuha.net Wed Jan 5 13:25:17 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15EEC3A6D0B; Wed, 5 Jan 2011 13:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1E-nXdNzNoiq; Wed, 5 Jan 2011 13:25:16 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 249863A6B8E; Wed, 5 Jan 2011 13:25:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 4A15E2CC45; Wed, 5 Jan 2011 23:27:22 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPfHuIdN6rwF; Wed, 5 Jan 2011 23:27:21 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 6C53F2CC2F; Wed, 5 Jan 2011 23:27:20 +0200 (EET) Message-ID: <4D24E236.3030108@piuha.net> Date: Wed, 05 Jan 2011 22:27:18 +0100 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Internet Area , "int-chairs@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Int-area] time to act on IETF-80 BOFs X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 21:25:17 -0000 Just as a reminder, if any of you are thinking of proposing new IETF work: the deadline for BOF proposals for the next meeting is January 31st. But if you have something in mind, please talk to your ADs as soon as possible. More information at http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF80 Jari From Wesley.E.George@sprint.com Fri Jan 7 10:50:41 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D04BE3A6935; Fri, 7 Jan 2011 10:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.98 X-Spam-Level: X-Spam-Status: No, score=-4.98 tagged_above=-999 required=5 tests=[AWL=1.019, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2bfaobSBRsX; Fri, 7 Jan 2011 10:50:40 -0800 (PST) Received: from TX2EHSOBE009.bigfish.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by core3.amsl.com (Postfix) with ESMTP id 9C2393A67A1; Fri, 7 Jan 2011 10:50:40 -0800 (PST) Received: from mail113-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.8; Fri, 7 Jan 2011 18:52:46 +0000 Received: from mail113-tx2 (localhost.localdomain [127.0.0.1]) by mail113-tx2-R.bigfish.com (Postfix) with ESMTP id D6820658340; Fri, 7 Jan 2011 18:52:46 +0000 (UTC) X-SpamScore: -42 X-BigFish: VS-42(zz936eK542N1370I4015L9371Pzz1202hzz8275bh8275dh1033ILz2fh2a8h668h34h62h) X-Spam-TCS-SCL: 1:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:plsasdm1.corp.sprint.com; RD:smtpls1.sprint.com; EFVD:NLI Received: from mail113-tx2 (localhost.localdomain [127.0.0.1]) by mail113-tx2 (MessageSwitch) id 1294426366598892_4969; Fri, 7 Jan 2011 18:52:46 +0000 (UTC) Received: from TX2EHSMHS007.bigfish.com (unknown [10.9.14.241]) by mail113-tx2.bigfish.com (Postfix) with ESMTP id 8DEAC3F0050; Fri, 7 Jan 2011 18:52:46 +0000 (UTC) Received: from plsasdm1.corp.sprint.com (144.230.168.25) by TX2EHSMHS007.bigfish.com (10.9.99.107) with Microsoft SMTP Server (TLS) id 14.1.225.8; Fri, 7 Jan 2011 18:52:45 +0000 Received: from PLSWEH02.ad.sprint.com (PLSWEH02.corp.sprint.com [144.226.242.131]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p07IqWoe016105 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Jan 2011 12:52:43 -0600 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PLSWEH02.ad.sprint.com ([2002:90e2:f283::90e2:f283]) with mapi id 14.01.0255.000; Fri, 7 Jan 2011 12:52:34 -0600 From: "George, Wes E [NTK]" To: "int-area@ietf.org" , "v6ops@ietf.org" Thread-Topic: IP-capable nodes must support IPv6 - new draft-george-ipv6-required Thread-Index: AQHLrpjrZ6ocuhICBkqv8r6Er4RibpPF1QWA Date: Fri, 7 Jan 2011 18:52:33 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.53.29] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00A3_01CBAE72.20256EE0" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Cc: "Howard, Lee" , Chris Donley , Christopher LILJENSTOLPE Subject: [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 18:50:42 -0000 ------=_NextPart_000_00A3_01CBAE72.20256EE0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit As a direct result of discussions after Beijing about the hotly-contested draft regarding IANA allocating a new shared IPv4 address space, the authors of this draft realized that the root problem is actually the lack of IPv6 support in existing devices, which is adding a barrier to wider deployment in many networks. This is being made worse due to two things: lack of interest by vendors in back-porting true IPv6 support into devices that are software-upgradeable and could otherwise support it, and the fact that some vendors are still churning out devices which do not support IPv6 even as we stare down the imminent exhaustion of the IANA free IPv4 pool. This draft attempts to address this problem by updating the definition of an "IP-capable" node to require support for IPv6. The authors are fully aware that this is not going to solve the problem of legacy installed-base, nor is it going to prevent people from continuing to release hardware that is IPv4-only. However, we believe that the IETF is overdue to acknowledge that IPv6 will be a requirement going forward, and not just optional. We'd appreciate your support in adopting this as an int-area draft, or possibly a v6ops draft. We'd be happy to discuss the draft in either meeting at IETF 80 if the WG chair feels that it is appropriate. Thanks, Wes George -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Friday, January 07, 2011 1:28 PM To: George, Wes E [NTK] Cc: C.Donley@cablelabs.com; cdl@asgaard.org; lee.howard@twcable.com Subject: New Version Notification for draft-george-ipv6-required-00 A new version of I-D, draft-george-ipv6-required-00.txt has been successfully submitted by Wesley George and posted to the IETF repository. https://datatracker.ietf.org/doc/draft-george-ipv6-required/ Filename: draft-george-ipv6-required Revision: 00 Title: IPv6 Support Required for all IP-capable nodes Creation_date: 2011-01-06 WG ID: Independent 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 and 1122 to reflect the change in requirements. The IETF Secretariat. ------=_NextPart_000_00A3_01CBAE72.20256EE0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXHjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggarMIIFk6ADAgECAgo8 FVeJAAAAAZIPMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMDgwNTAxMTczNzE0WhcNMTEwNTAx MTczNzE0WjCBzzETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxEDAOBgNVBAsTB01hbmFn ZWQxGzAZBgNVBAsTElN0YW5kYXJkLVRlY2huaWNhbDEbMBkGA1UEAxMSV2VzbGV5IEUgR2Vvcmdl IElWMSkwJwYJKoZIhvcNAQkBFhpXZXNsZXkuRS5HZW9yZ2VAc3ByaW50LmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEArxfUh9TugEcsXY4OefFQTrGuaTRenLcZg0KCxZlTY7P9wMRCYd8p GJljwH1x4qn0Ejjyz+uX5UL8Biia13BSWRgiq7QYLKTZNKwEpBbeOf9lK/LrPsbFOgat/Zh/lPmx YzxeikU42X3KhyVSCmWdQhmWRu5kfUzsejaGWH9AyuUCAwEAAaOCA2EwggNdMAsGA1UdDwQEAwIF oDA2BgkqhkiG9w0BCQ8EKTAnMA0GCCqGSIb3DQMCAgE4MA0GCCqGSIb3DQMEAgE4MAcGBSsOAwIH MB0GA1UdDgQWBBTFSbrzJuajBSX9B63Y9r2TlgbU5DA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3 FQiBkugshNficv2LB4Xs/liCno8icYbjvkqEsfZAAgFkAgECMB8GA1UdIwQYMBaAFAGPJVAshjSb wX6QH9mINbU/rwuJMIIBXgYDVR0fBIIBVTCCAVEwggFNoIIBSaCCAUWGgeNsZGFwOi8vL0NOPVNw cmludCUyME5leHRlbCUyMEVudGVycHJpc2UlMjBJc3N1aW5nJTIwMSUyMEF1dGhvcml0eSxDTj1Q UEtJV0MwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1hZCxEQz1zcHJpbnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlv bkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYraHR0cDovL2NybC5z cHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNybIYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdDMDEvUFBLSVdDMDEuY3JsMIGFBggrBgEFBQcBAQR5MHcwNwYIKwYBBQUHMAKGK2h0 dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwPAYIKwYBBQUHMAKGMGh0 dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNydDApBgNVHSUEIjAg BggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AX DBV3ZWcwMjIxQGFkLnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQBYdUj2FTmOVS0X2fF+OYWXu9QoS6JWB8exD8kBPWVh28UilosoFwpVs2Ux K+V9NE1SC4QXDfwcjyMMV6WfXfy1foT6YAOcLt1z91ALCbTPlr1mazbAnOL6AzoTnq5V+TjvJvdN IYROS6PJC/YU5+w/NannnhC1zNFOtmxZZcrz50uRU8Q4mgITpxcnJXKUtKNaFTEhhtnP+hMVXYW0 eUyG7xjDTCyqsO5jcyI0IKJkNW1NXaKjHfmlAAiL5HVNl7cYL5uce6orHQQPMTSGRmTKCNjx7Yaz EHAorZUGmCTuihdhPDq+tOhGrIDE4XuiDxj+OVU6JXM5nsiKTjU968o4MYIDLTCCAykCAQEwgYYw eDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT 8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1 dGhvcml0eQIKPBVXiQAAAAGSDzAJBgUrDgMCGgUAoIIB/DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTAxMDcxODUyMjlaMCMGCSqGSIb3DQEJBDEWBBSBJzqi61IO vFGA4d/VOc54eNDm9TBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG 9w0CBTCBlwYJKwYBBAGCNxAEMYGJMIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wgZkGCyqGSIb3DQEJ EAILMYGJoIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJpbnQx EjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNlIElz c3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wDQYJKoZIhvcNAQEBBQAEgYCqQ4N8/g1fPi8n k0DPVVlatskIu+seW98hpdf3TAYUpkQ5FwUaDTMh186lMm4ICgJjfHOjAbTIZjeX/wEdkAsaz/cb mZnRr4v0at1dbAQtEcfy3u9TrNrebInBHmSMHja1B5YKttMjkO0R2txttgS9wCuGRv1LVR/gG34o LklHTgAAAAAAAA== ------=_NextPart_000_00A3_01CBAE72.20256EE0-- From edward.jankiewicz@sri.com Fri Jan 7 12:11:35 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0579B3A696E for ; Fri, 7 Jan 2011 12:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uD2reUDzXLKW for ; Fri, 7 Jan 2011 12:11:34 -0800 (PST) Received: from mail1.sri.com (newmail.SRI.COM [128.18.30.17]) by core3.amsl.com (Postfix) with ESMTP id 905773A696F for ; Fri, 7 Jan 2011 12:08:58 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_jV0643zSWG4M26I2ysTYGw)" Received: from [192.168.1.144] ([unknown] [68.81.23.64]) by mail.sri.com (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LEO00M0P5EETF90@mail.sri.com> for int-area@ietf.org; Fri, 07 Jan 2011 12:11:02 -0800 (PST) Message-id: <4D277357.2050109@sri.com> Date: Fri, 07 Jan 2011 15:11:03 -0500 From: Ed Jankiewicz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 To: int-area@ietf.org, IPv6 Operations References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> In-reply-to: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 20:11:35 -0000 This is a multi-part message in MIME format. --Boundary_(ID_jV0643zSWG4M26I2ysTYGw) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT I agree so strenuously that I half-jokiningly would like to be listed as a coauthor, and I bet there are a number of other folks on these lists that would feel the same way. Perhaps a better suggestion would be to include an appendix with the name and affiliation of everyone who is willing to sign-on to ratify this recommendation. I've been working with a government client supporting a mandate that said that every IP product US DoD buys MUST be IPv6 capable, which resulted in significant attention from vendors. Strong words from above definitely trigger action. I believe a strong statement from IETF at this time is appropriate. Take away the excuse that "nothing ever said IPv6 was a MUST". I'd like to see this on the agenda for Intarea or v6ops or both in Prague. Ed Jankiewicz, speaking without any hats on, except perhaps my IPv6 propeller beanie. On 1/7/2011 1:52 PM, George, Wes E [NTK] wrote: > As a direct result of discussions after Beijing about the hotly-contested > draft regarding IANA allocating a new shared IPv4 address space, the authors > of this draft realized that the root problem is actually the lack of IPv6 > support in existing devices, which is adding a barrier to wider deployment in > many networks. This is being made worse due to two things: lack of interest by > vendors in back-porting true IPv6 support into devices that are > software-upgradeable and could otherwise support it, and the fact that some > vendors are still churning out devices which do not support IPv6 even as we > stare down the imminent exhaustion of the IANA free IPv4 pool. This draft > attempts to address this problem by updating the definition of an "IP-capable" > node to require support for IPv6. > > The authors are fully aware that this is not going to solve the problem of > legacy installed-base, nor is it going to prevent people from continuing to > release hardware that is IPv4-only. However, we believe that the IETF is > overdue to acknowledge that IPv6 will be a requirement going forward, and not > just optional. > > We'd appreciate your support in adopting this as an int-area draft, or > possibly a v6ops draft. > > We'd be happy to discuss the draft in either meeting at IETF 80 if the WG > chair feels that it is appropriate. > > Thanks, > Wes George > > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Friday, January 07, 2011 1:28 PM > To: George, Wes E [NTK] > Cc: C.Donley@cablelabs.com; cdl@asgaard.org; lee.howard@twcable.com > Subject: New Version Notification for draft-george-ipv6-required-00 > > > A new version of I-D, draft-george-ipv6-required-00.txt has been successfully > submitted by Wesley George and posted to the IETF repository. > > https://datatracker.ietf.org/doc/draft-george-ipv6-required/ > > Filename: draft-george-ipv6-required > Revision: 00 > Title: IPv6 Support Required for all IP-capable nodes > Creation_date: 2011-01-06 > WG ID: Independent 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 and 1122 to > reflect the change in requirements. > > > > The IETF Secretariat. > > > > > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area 732-389-1003 or ed.jankiewicz@sri.com --Boundary_(ID_jV0643zSWG4M26I2ysTYGw) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 8BIT I agree so strenuously that I half-jokiningly would like to be listed as a coauthor, and I bet there are a number of other folks on these lists that would feel the same way.  Perhaps a better suggestion would be to include an appendix with the name and affiliation of everyone who is willing to sign-on to ratify this recommendation.

I've been working with a government client supporting a mandate that said that every IP product US DoD buys MUST be IPv6 capable, which resulted in significant attention from vendors.  Strong words from above definitely trigger action.

I believe a strong statement from IETF at this time is appropriate.  Take away the excuse that "nothing ever said IPv6 was a MUST".   I'd like to see this on the agenda for Intarea or v6ops or both in Prague.

Ed Jankiewicz, speaking without any hats on, except perhaps my IPv6 propeller beanie. 

On 1/7/2011 1:52 PM, George, Wes E [NTK] wrote: 
As a direct result of discussions after Beijing about the hotly-contested 
draft regarding IANA allocating a new shared IPv4 address space, the authors 
of this draft realized that the root problem is actually the lack of IPv6 
support in existing devices, which is adding a barrier to wider deployment in 
many networks. This is being made worse due to two things: lack of interest by 
vendors in back-porting true IPv6 support into devices that are 
software-upgradeable and could otherwise support it, and the fact that some 
vendors are still churning out devices which do not support IPv6 even as we 
stare down the imminent exhaustion of the IANA free IPv4 pool. This draft 
attempts to address this problem by updating the definition of an "IP-capable" 
node to require support for IPv6.

The authors are fully aware that this is not going to solve the problem of 
legacy installed-base, nor is it going to prevent people from continuing to 
release hardware that is IPv4-only. However, we believe that the IETF is 
overdue to acknowledge that IPv6 will be a requirement going forward, and not 
just optional.

We'd appreciate your support in adopting this as an int-area draft, or 
possibly a v6ops draft.

We'd be happy to discuss the draft in either meeting at IETF 80 if the WG 
chair feels that it is appropriate.

Thanks,
Wes George


-----Original Message-----
From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]
Sent: Friday, January 07, 2011 1:28 PM
To: George, Wes E [NTK]
Cc: C.Donley@cablelabs.com; cdl@asgaard.org; lee.howard@twcable.com
Subject: New Version Notification for draft-george-ipv6-required-00


A new version of I-D, draft-george-ipv6-required-00.txt has been successfully 
submitted by Wesley George and posted to the IETF repository.

https://datatracker.ietf.org/doc/draft-george-ipv6-required/

Filename:	 draft-george-ipv6-required
Revision:	 00
Title:		 IPv6 Support Required for all IP-capable nodes
Creation_date:	 2011-01-06
WG ID:		 Independent 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 and 1122 to
reflect the change in requirements.



The IETF Secretariat.





_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area


732-389-1003 or  ed.jankiewicz@sri.com
--Boundary_(ID_jV0643zSWG4M26I2ysTYGw)-- From touch@isi.edu Fri Jan 7 12:57:57 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ACA93A6947 for ; Fri, 7 Jan 2011 12:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCsvR57wAMYU for ; Fri, 7 Jan 2011 12:57:56 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 9A19B3A6946 for ; Fri, 7 Jan 2011 12:57:56 -0800 (PST) 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 p07KxG3D014161 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 7 Jan 2011 12:59:16 -0800 (PST) Message-ID: <4D277EA5.9080304@isi.edu> Date: Fri, 07 Jan 2011 12:59:17 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ed Jankiewicz References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> In-Reply-To: <4D277357.2050109@sri.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Operations , int-area@ietf.org Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 20:57:57 -0000 IMO, IPv6 support, or IPv6-capable, isn't going to cut it. The IETF doesn't have an enforcement or validation arm, like Underwriter's Lab does, e.g. If it did, the correct recommendation, IMO, would be: - IPv6 MUST be enabled by default - all advertized/claimed IP capabilities MUST be enabled by default using IPv6 I.e., whatever the device supports in IP, it MUST be ready and available in a default configuration for IPv6. Joe From fred@cisco.com Fri Jan 7 13:07:42 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B44183A6958 for ; Fri, 7 Jan 2011 13:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdKyp-yvA6JI for ; Fri, 7 Jan 2011 13:07:41 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 28F2A3A6948 for ; Fri, 7 Jan 2011 13:07:41 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPcPJ02rR7Ht/2dsb2JhbACkK3OjCZd7hUwEhGeGIoMeiBE Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 07 Jan 2011 21:09:47 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p07L9ghj025183; Fri, 7 Jan 2011 21:09:47 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Fri, 07 Jan 2011 13:09:47 -0800 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Fri, 07 Jan 2011 13:09:47 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <4D277EA5.9080304@isi.edu> Date: Fri, 7 Jan 2011 13:09:30 -0800 Message-Id: References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , int-area@ietf.org Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 21:07:42 -0000 On Jan 7, 2011, at 12:59 PM, Joe Touch wrote: > IMO, IPv6 support, or IPv6-capable, isn't going to cut it. >=20 > The IETF doesn't have an enforcement or validation arm, like = Underwriter's Lab does, e.g. If it did, the correct recommendation, IMO, = would be: >=20 > - IPv6 MUST be enabled by default > - all advertized/claimed IP capabilities MUST be enabled by default = using IPv6 >=20 > I.e., whatever the device supports in IP, it MUST be ready and = available in a default configuration for IPv6. I'm very sympathetic to your viewpoint, but on equipment I'm familiar = with it poses a few problems. For example, telling me that I have to = support IPv6 routing in all my IP routing protocols, and if they run on = IP they have to be able to run on IPv6, makes sense. Did you want all of = my routing protocols on, on all interfaces, by default? If not, which, = and why did you make that choice? Yes, we have IPv6 ACLs. Which ACL did = you want on by default? And so on. And then there is the principle of least surprise. Any idea what happens = when one of my customers finds something running on my equipment in his = network that he didn't plan on being there? I'll give you a hint: PSIRT = winds up making comments... For hosts, such as Linux/MacOSX/Windows, yes I would recommend that IPv6 = be on by default in an RFC-specified configuration. Not sure I want that = for the infrastructure. > Joe >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From fred@cisco.com Fri Jan 7 13:14:10 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE5C03A6948; Fri, 7 Jan 2011 13:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.451 X-Spam-Level: X-Spam-Status: No, score=-110.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaehjoLP9xhv; Fri, 7 Jan 2011 13:14:09 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E54B23A68C5; Fri, 7 Jan 2011 13:14:09 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJoRJ02rR7H+/2dsb2JhbACkK3OjBpd9hUwEhGeGIoMeiBE Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 07 Jan 2011 21:16:16 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p07LGBdD017534; Fri, 7 Jan 2011 21:16:16 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Fri, 07 Jan 2011 13:16:16 -0800 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Fri, 07 Jan 2011 13:16:16 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <4D277EA5.9080304@isi.edu> Date: Fri, 7 Jan 2011 13:16:02 -0800 Message-Id: <4F35055C-659C-4757-AC2C-F99932EB09FD@cisco.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops , Internet Area Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 21:14:10 -0000 It looks like Ed, when he reformatted his reply to remove the draft = authors, managed to change v6ops@ietf.org to v6ops@ops.ietf.org. The old = address no longer works... Anyhow, my comment to Joe's response to Ed's response... On Jan 7, 2011, at 12:59 PM, Joe Touch wrote: > IMO, IPv6 support, or IPv6-capable, isn't going to cut it. >=20 > The IETF doesn't have an enforcement or validation arm, like = Underwriter's Lab does, e.g. If it did, the correct recommendation, IMO, = would be: >=20 > - IPv6 MUST be enabled by default > - all advertized/claimed IP capabilities MUST be enabled by default = using IPv6 >=20 > I.e., whatever the device supports in IP, it MUST be ready and = available in a default configuration for IPv6. I'm very sympathetic to your viewpoint, but on equipment I'm familiar = with it poses a few problems. For example, telling me that I have to = support IPv6 routing in all my IP routing protocols, and if they run on = IP they have to be able to run on IPv6, makes sense. Did you want all of = my routing protocols on, on all interfaces, by default? If not, which, = and why did you make that choice? Yes, we have IPv6 ACLs. Which ACL did = you want on by default? And so on. And then there is the principle of least surprise. Any idea what happens = when one of my customers finds something running on my equipment in his = network that he didn't plan on being there? I'll give you a hint: PSIRT = winds up making comments... For hosts, such as Linux/MacOSX/Windows, yes I would recommend that IPv6 = be on by default in an RFC-specified configuration. Not sure I want that = for the infrastructure. > Joe >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From Wesley.E.George@sprint.com Fri Jan 7 13:17:51 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F25243A695C; Fri, 7 Jan 2011 13:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.81 X-Spam-Level: X-Spam-Status: No, score=-3.81 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igOSuToL6gw5; Fri, 7 Jan 2011 13:17:51 -0800 (PST) Received: from DB3EHSOBE001.bigfish.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by core3.amsl.com (Postfix) with ESMTP id 056993A6974; Fri, 7 Jan 2011 13:17:48 -0800 (PST) Received: from mail45-db3-R.bigfish.com (10.3.81.250) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.8; Fri, 7 Jan 2011 21:19:55 +0000 Received: from mail45-db3 (localhost.localdomain [127.0.0.1]) by mail45-db3-R.bigfish.com (Postfix) with ESMTP id 6958D1068545; Fri, 7 Jan 2011 21:25:45 +0000 (UTC) X-SpamScore: -40 X-BigFish: VS-40(zz542N1432N9371Pzz1202hzz8275dh1033ILz2fh2a8h668h34h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:pdaasdm2.corp.sprint.com; RD:smtpda2.sprint.com; EFVD:NLI Received: from mail45-db3 (localhost.localdomain [127.0.0.1]) by mail45-db3 (MessageSwitch) id 1294435545171702_27030; Fri, 7 Jan 2011 21:25:45 +0000 (UTC) Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.244]) by mail45-db3.bigfish.com (Postfix) with ESMTP id 1AFA04A804D; Fri, 7 Jan 2011 21:25:45 +0000 (UTC) Received: from pdaasdm2.corp.sprint.com (144.229.32.57) by DB3EHSMHS005.bigfish.com (10.3.87.105) with Microsoft SMTP Server (TLS) id 14.1.225.8; Fri, 7 Jan 2011 21:19:53 +0000 Received: from PLSWEH01.ad.sprint.com (PLSWEH01.corp.sprint.com [144.226.242.129]) by pdaasdm2.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p07LD3ZI027075 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Jan 2011 15:13:05 -0600 Received: from PDAWEH04.ad.sprint.com (144.226.111.59) by PLSWEH01.ad.sprint.com (144.226.242.129) with Microsoft SMTP Server (TLS) id 14.1.255.0; Fri, 7 Jan 2011 15:19:49 -0600 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PDAWEH04.ad.sprint.com ([2002:90e2:6f3b::90e2:6f3b]) with mapi id 14.01.0255.000; Fri, 7 Jan 2011 15:19:48 -0600 From: "George, Wes E [NTK]" To: Joe Touch , Ed Jankiewicz Thread-Topic: [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required Thread-Index: AQHLrq3iI6Iy3pLjcUWdTPLcKiedQ5PGAa2A Date: Fri, 7 Jan 2011 21:19:47 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E049E93@PLSWM12A.ad.sprint.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> In-Reply-To: <4D277EA5.9080304@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.53.29] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00E5_01CBAE86.B346BF80" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Cc: "v6ops@ietf.org" , "int-area@ietf.org" Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 21:17:52 -0000 ------=_NextPart_000_00E5_01CBAE86.B346BF80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On > Behalf Of Joe Touch > Sent: Friday, January 07, 2011 3:59 PM > Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new draft- > george-ipv6-required > > > - IPv6 MUST be enabled by default > - all advertized/claimed IP capabilities MUST be enabled by default > using IPv6 > > I.e., whatever the device supports in IP, it MUST be ready and > available > in a default configuration for IPv6. [WES] That "default" keyword is one third-rail that I'd rather not touch. I understand the idea - if the (non-technical) customer must do something to enable it, it may as well not be there... But ultimately this is meant to be a generic doc that refers you to other docs that cover the more specifics about what should and should not be on by default, etc. And those subtending documents is where specifics like that should be covered. I'm open to discussion on adding something like your second statement clarifying that IPv6 support translates to feature parity between IPv4 and IPv6, but I hesitate to add too much complexity. Propose text? Wes ------=_NextPart_000_00E5_01CBAE86.B346BF80 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXHjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggarMIIFk6ADAgECAgo8 FVeJAAAAAZIPMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMDgwNTAxMTczNzE0WhcNMTEwNTAx MTczNzE0WjCBzzETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxEDAOBgNVBAsTB01hbmFn ZWQxGzAZBgNVBAsTElN0YW5kYXJkLVRlY2huaWNhbDEbMBkGA1UEAxMSV2VzbGV5IEUgR2Vvcmdl IElWMSkwJwYJKoZIhvcNAQkBFhpXZXNsZXkuRS5HZW9yZ2VAc3ByaW50LmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEArxfUh9TugEcsXY4OefFQTrGuaTRenLcZg0KCxZlTY7P9wMRCYd8p GJljwH1x4qn0Ejjyz+uX5UL8Biia13BSWRgiq7QYLKTZNKwEpBbeOf9lK/LrPsbFOgat/Zh/lPmx YzxeikU42X3KhyVSCmWdQhmWRu5kfUzsejaGWH9AyuUCAwEAAaOCA2EwggNdMAsGA1UdDwQEAwIF oDA2BgkqhkiG9w0BCQ8EKTAnMA0GCCqGSIb3DQMCAgE4MA0GCCqGSIb3DQMEAgE4MAcGBSsOAwIH MB0GA1UdDgQWBBTFSbrzJuajBSX9B63Y9r2TlgbU5DA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3 FQiBkugshNficv2LB4Xs/liCno8icYbjvkqEsfZAAgFkAgECMB8GA1UdIwQYMBaAFAGPJVAshjSb wX6QH9mINbU/rwuJMIIBXgYDVR0fBIIBVTCCAVEwggFNoIIBSaCCAUWGgeNsZGFwOi8vL0NOPVNw cmludCUyME5leHRlbCUyMEVudGVycHJpc2UlMjBJc3N1aW5nJTIwMSUyMEF1dGhvcml0eSxDTj1Q UEtJV0MwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1hZCxEQz1zcHJpbnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlv bkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYraHR0cDovL2NybC5z cHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNybIYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdDMDEvUFBLSVdDMDEuY3JsMIGFBggrBgEFBQcBAQR5MHcwNwYIKwYBBQUHMAKGK2h0 dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwPAYIKwYBBQUHMAKGMGh0 dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNydDApBgNVHSUEIjAg BggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AX DBV3ZWcwMjIxQGFkLnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQBYdUj2FTmOVS0X2fF+OYWXu9QoS6JWB8exD8kBPWVh28UilosoFwpVs2Ux K+V9NE1SC4QXDfwcjyMMV6WfXfy1foT6YAOcLt1z91ALCbTPlr1mazbAnOL6AzoTnq5V+TjvJvdN IYROS6PJC/YU5+w/NannnhC1zNFOtmxZZcrz50uRU8Q4mgITpxcnJXKUtKNaFTEhhtnP+hMVXYW0 eUyG7xjDTCyqsO5jcyI0IKJkNW1NXaKjHfmlAAiL5HVNl7cYL5uce6orHQQPMTSGRmTKCNjx7Yaz EHAorZUGmCTuihdhPDq+tOhGrIDE4XuiDxj+OVU6JXM5nsiKTjU968o4MYIDLTCCAykCAQEwgYYw eDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT 8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1 dGhvcml0eQIKPBVXiQAAAAGSDzAJBgUrDgMCGgUAoIIB/DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTAxMDcyMTE5NDZaMCMGCSqGSIb3DQEJBDEWBBQHSIGJPuiZ fWL/KyuDb4G7s31HwDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG 9w0CBTCBlwYJKwYBBAGCNxAEMYGJMIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wgZkGCyqGSIb3DQEJ EAILMYGJoIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJpbnQx EjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNlIElz c3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wDQYJKoZIhvcNAQEBBQAEgYAWPlGnDD7Sx5DC Ndgw8RmSpimwo+dp0TPinzuDHYPRx/PPa0vggJe9tpce7xZP9Dn1us4zD9TbfYpT5d198vZHHnpu sWWVbWzi4ovUxEVWePeVmnkGHTtH71jUCCJu2vhe1W9FmMcpSIVv8ssNDBFJ+WivupVfvmKn1+xa 29fqpgAAAAAAAA== ------=_NextPart_000_00E5_01CBAE86.B346BF80-- From touch@isi.edu Fri Jan 7 13:32:21 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3105F3A6935; Fri, 7 Jan 2011 13:32:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzA9R0FKm4mV; Fri, 7 Jan 2011 13:32:19 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 2D8BF3A698A; Fri, 7 Jan 2011 13:28:58 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p07LRjPE016127 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 7 Jan 2011 13:27:45 -0800 (PST) Message-ID: <4D278551.5070608@isi.edu> Date: Fri, 07 Jan 2011 13:27:45 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "George, Wes E [NTK]" References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <54E900DC635DAB4DB7A6D799B3C4CD8E049E93@PLSWM12A.ad.sprint.com> In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E049E93@PLSWM12A.ad.sprint.com> 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: "v6ops@ietf.org" , "int-area@ietf.org" Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 21:32:21 -0000 On 1/7/2011 1:19 PM, George, Wes E [NTK] wrote: >> -----Original Message----- >> From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On >> Behalf Of Joe Touch >> Sent: Friday, January 07, 2011 3:59 PM >> Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new draft- >> george-ipv6-required >> >> >> - IPv6 MUST be enabled by default >> - all advertized/claimed IP capabilities MUST be enabled by default >> using IPv6 >> >> I.e., whatever the device supports in IP, it MUST be ready and >> available >> in a default configuration for IPv6. > > [WES] That "default" keyword is one third-rail that I'd rather not touch. I > understand the idea - if the (non-technical) customer must do something to > enable it, it may as well not be there... But ultimately this is meant to be > a generic doc that refers you to other docs that cover the more specifics > about what should and should not be on by default, etc. And those subtending > documents is where specifics like that should be covered. > > I'm open to discussion on adding something like your second statement > clarifying that IPv6 support translates to feature parity between IPv4 and > IPv6, but I hesitate to add too much complexity. Propose text? The basic idea is that: - capabilities supported for IPv4 MUST be supported for IPv6 - defaults enabled for IPv4 MUST be enabled for IPv6 not sure whether this is "instead of for IPv4", or just in addition Joe From touch@isi.edu Fri Jan 7 13:32:26 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BB3E3A6969; Fri, 7 Jan 2011 13:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Df2xE7XR-76e; Fri, 7 Jan 2011 13:32:24 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 686363A6996; Fri, 7 Jan 2011 13:29:05 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p07LQH66016009 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 7 Jan 2011 13:26:17 -0800 (PST) Message-ID: <4D2784F9.8000502@isi.edu> Date: Fri, 07 Jan 2011 13:26:17 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fred Baker References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4F35055C-659C-4757-AC2C-F99932EB09FD@cisco.com> In-Reply-To: <4F35055C-659C-4757-AC2C-F99932EB09FD@cisco.com> 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: v6ops v6ops , Internet Area Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 21:32:26 -0000 On 1/7/2011 1:16 PM, Fred Baker wrote: > It looks like Ed, when he reformatted his reply to remove the draft authors, managed to change v6ops@ietf.org to v6ops@ops.ietf.org. The old address no longer works... > > Anyhow, my comment to Joe's response to Ed's response... > > On Jan 7, 2011, at 12:59 PM, Joe Touch wrote: > >> IMO, IPv6 support, or IPv6-capable, isn't going to cut it. >> >> The IETF doesn't have an enforcement or validation arm, like Underwriter's Lab does, e.g. If it did, the correct recommendation, IMO, would be: >> >> - IPv6 MUST be enabled by default >> - all advertized/claimed IP capabilities MUST be enabled by default using IPv6 >> >> I.e., whatever the device supports in IP, it MUST be ready and available in a default configuration for IPv6. > > I'm very sympathetic to your viewpoint, but on equipment I'm > familiar with it poses a few problems. For example, telling me that I > have to support IPv6 routing in all my IP routing protocols, and if > they run on IP they have to be able to run on IPv6, makes sense. Did > you want all of my routing protocols on, on all interfaces, by > default? If not, which, and why did you make that choice? Yes, we > have IPv6 ACLs. Which ACL did you want on by default? And so on. Basically, if it's on by default for IPv4, it MUST be on by default for IPv6. I appreciate that not everything is on by default, esp in routers. > And then there is the principle of least surprise. Any idea what > happens when one of my customers finds something running on my equipment > in his network that he didn't plan on being there? I'll give you a hint: > PSIRT winds up making comments... See above; the idea is just to bring IPv6 to the level that people currently enjoy support for Ipv4, not to force them into it per se. > For hosts, such as Linux/MacOSX/Windows, yes I would recommend that > IPv6 be on by default in an RFC-specified configuration. Not sure I > want that for the infrastructure. At least one significant problem with deployment is IPv6 support for network management and monitoring tools. If that's not available from the start - when purchased - the equipment is unlikely to ever be used for IPv6. Regardless, I proposed what I think is a more useful metric. Yes, there are some nuances (i.e., what does "on by default" mean), but the general intent is: don't claim a capability works for IP unless it works for IPv6 out of the box Joe From matthew@matthew.at Fri Jan 7 13:42:36 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44F993A69AA for ; Fri, 7 Jan 2011 13:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHZbSR1nfrZ7 for ; Fri, 7 Jan 2011 13:42:35 -0800 (PST) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by core3.amsl.com (Postfix) with ESMTP id 6C06C3A6955 for ; Fri, 7 Jan 2011 13:38:24 -0800 (PST) Received: from [10.10.155.2] (unknown [10.10.155.2]) by where.matthew.at (Postfix) with ESMTP id 1C33114805E; Fri, 7 Jan 2011 13:40:05 -0800 (PST) Message-ID: <4D278833.8090208@matthew.at> Date: Fri, 07 Jan 2011 13:40:03 -0800 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Joe Touch References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> In-Reply-To: <4D277EA5.9080304@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , int-area@ietf.org Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: matthew@matthew.at List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 21:42:36 -0000 On 1/7/2011 12:59 PM, Joe Touch wrote: > > I.e., whatever the device supports in IP, it MUST be ready and > available in a default configuration for IPv6. Like NAT? Matthew Kaufman From touch@isi.edu Fri Jan 7 13:44:42 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE0423A68F7 for ; Fri, 7 Jan 2011 13:44:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfmLni7VNQ3t for ; Fri, 7 Jan 2011 13:44:42 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 4671D3A6832 for ; Fri, 7 Jan 2011 13:44:37 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p07LkM3C019420 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 7 Jan 2011 13:46:22 -0800 (PST) Message-ID: <4D2789AF.1050903@isi.edu> Date: Fri, 07 Jan 2011 13:46:23 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: matthew@matthew.at References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> In-Reply-To: <4D278833.8090208@matthew.at> 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: IPv6 Operations , int-area@ietf.org Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 21:44:42 -0000 On 1/7/2011 1:40 PM, Matthew Kaufman wrote: > On 1/7/2011 12:59 PM, Joe Touch wrote: >> >> I.e., whatever the device supports in IP, it MUST be ready and >> available in a default configuration for IPv6. > > Like NAT? Well, if you have a device that NATs, and it only supports it for IPv4, and that's a behavior you want (for privacy or other reasons), then yes, it should support it for IPv6. Sure, I'd hope that if IPv6 were ubiquitous that less people would buy/use NATs, but I don't want the existence of IPv4-only NATs to inhibit that ubiquity. Joe From matthew@matthew.at Fri Jan 7 13:49:33 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94F463A694E; Fri, 7 Jan 2011 13:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+YB+45Ji41P; Fri, 7 Jan 2011 13:49:32 -0800 (PST) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by core3.amsl.com (Postfix) with ESMTP id 9067C3A6948; Fri, 7 Jan 2011 13:49:29 -0800 (PST) Received: from [10.10.155.2] (unknown [10.10.155.2]) by where.matthew.at (Postfix) with ESMTP id 7CDB425010D; Fri, 7 Jan 2011 13:51:36 -0800 (PST) Message-ID: <4D278AE7.4080502@matthew.at> Date: Fri, 07 Jan 2011 13:51:35 -0800 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Joe Touch References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> In-Reply-To: <4D2789AF.1050903@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , int-area@ietf.org Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: matthew@matthew.at List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 21:49:33 -0000 On 1/7/2011 1:46 PM, Joe Touch wrote: > > > On 1/7/2011 1:40 PM, Matthew Kaufman wrote: >> On 1/7/2011 12:59 PM, Joe Touch wrote: >>> >>> I.e., whatever the device supports in IP, it MUST be ready and >>> available in a default configuration for IPv6. >> >> Like NAT? > > Well, if you have a device that NATs, and it only supports it for > IPv4, and that's a behavior you want (for privacy or other reasons), > then yes, it should support it for IPv6. > > Sure, I'd hope that if IPv6 were ubiquitous that less people would > buy/use NATs, but I don't want the existence of IPv4-only NATs to > inhibit that ubiquity. > > Joe Ok. So just to verify, if a box that is sold today that does NAT44 out-of-the-box (I have one here on my desk, does DHCP client on the "WAN" port and serves DHCP for RFC1918 space for the "LAN" switch ports when first powered up) wants to comply with this it would need to also do NAT66 (with DHCPv6 serving ULA space on the "LAN" side, I guess...) when initially powered up? Matthew Kaufman From touch@isi.edu Fri Jan 7 13:52:37 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F6513A6961; Fri, 7 Jan 2011 13:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9fH1Xx+nCAA; Fri, 7 Jan 2011 13:52:36 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 9B2B23A6948; Fri, 7 Jan 2011 13:52:36 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p07LsRWl020749 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 7 Jan 2011 13:54:29 -0800 (PST) Message-ID: <4D278B93.8050903@isi.edu> Date: Fri, 07 Jan 2011 13:54:27 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: matthew@matthew.at References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> In-Reply-To: <4D278AE7.4080502@matthew.at> 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: IPv6 Operations , int-area@ietf.org Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 21:52:37 -0000 On 1/7/2011 1:51 PM, Matthew Kaufman wrote: > Ok. So just to verify, if a box that is sold today that does NAT44 > out-of-the-box (I have one here on my desk, does DHCP client on the > "WAN" port and serves DHCP for RFC1918 space for the "LAN" switch ports > when first powered up) wants to comply with this it would need to also > do NAT66 (with DHCPv6 serving ULA space on the "LAN" side, I guess...) > when initially powered up? IMO, yes. Joe From brian.e.carpenter@gmail.com Fri Jan 7 14:37:47 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD33E3A6987; Fri, 7 Jan 2011 14:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.444 X-Spam-Level: X-Spam-Status: No, score=-103.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0qS9TDY6lYB; Fri, 7 Jan 2011 14:37:45 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 3C3413A6948; Fri, 7 Jan 2011 14:37:44 -0800 (PST) Received: by vws7 with SMTP id 7so7106934vws.31 for ; Fri, 07 Jan 2011 14:39:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=q4HiF/0F8eyLwfx84b8WX+8mZeGRtijEFGL0G3VjUps=; b=v+hk2ybduezB9gunkvWekXRX80x+x8modUQBVpaXv4bKVqugmZGYpvZXAkzkRlLRhB 8rpZtsHkpeOthHioEOyKyPYlV0TpseNRmzzQVptCyIu3/b97Za1T44Jy6OWIuOiQcLru SEVcC1LmPDcyFPx4mOmOMYB25Oyd9+b0RduX8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=nfA6/akJUJJV6W6MeOm3n4u6hOi2HhkqlZD+Bd412o5DokgkMNzgTdi283VnKOwbWR WZiqwFx9LLT8WEJZzbvi/14eTvlNkG285bY0IKzIzMpqg/6VKGgZhATcPlp0fcOZa95W o9dge3r5A5FD6o4nasuvQBQsYZmjYcbmWMgPI= Received: by 10.220.184.66 with SMTP id cj2mr7580310vcb.140.1294439990811; Fri, 07 Jan 2011 14:39:50 -0800 (PST) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id fl9sm10014028vbb.0.2011.01.07.14.39.48 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 14:39:50 -0800 (PST) Message-ID: <4D27962F.9030005@gmail.com> Date: Sat, 08 Jan 2011 11:39:43 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joe Touch References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> In-Reply-To: <4D278B93.8050903@isi.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , int-area@ietf.org Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 22:37:48 -0000 On 2011-01-08 10:54, Joe Touch wrote: > > > On 1/7/2011 1:51 PM, Matthew Kaufman wrote: >> Ok. So just to verify, if a box that is sold today that does NAT44 >> out-of-the-box (I have one here on my desk, does DHCP client on the >> "WAN" port and serves DHCP for RFC1918 space for the "LAN" switch ports >> when first powered up) wants to comply with this it would need to also >> do NAT66 (with DHCPv6 serving ULA space on the "LAN" side, I guess...) >> when initially powered up? > > IMO, yes. IMO, no. See RFC 4864, draft-ietf-v6ops-cpe-simple-security, and many related discussions. Brian From dragoniz3r@gmail.com Fri Jan 7 14:40:08 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 605323A6992; Fri, 7 Jan 2011 14:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQafWKG7rksD; Fri, 7 Jan 2011 14:40:07 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id EDB883A6985; Fri, 7 Jan 2011 14:40:06 -0800 (PST) Received: by wwa36 with SMTP id 36so17954611wwa.13 for ; Fri, 07 Jan 2011 14:42:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=annqkEjHZL9vrW4C1KLkTeU5HAqD6gP5QFk9yz9eTQ0=; b=nT8vBhAIL6ggSm+Dl939yq2MB+iar2j1v24x/wlf6HnUevbXGK+91gNN5Dxj66DQNg f0qx9WlvJqfSNDtgtNEPu76p+HZJbVwoSbWyg+ANyMsJzG6dwvAIAg8mfeTWe3SxNEgx NnvcoKK1qChumUD/E/qQrjMOqyg3fv615720k= 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=ctxnnFLzFJA7IVpSyNts31OMIBOuOZI83q27BRSeJSUusBsByv/bi5nRM17aqRfTYZ lD07WpWIYnZXDLtla6OQ0UUYpFOYF0pQRyjyD2hEFJ1IO48kb88l6UqJwjxU0K/jTxAd AldFICdaJSPBdZgy5TVsuCIY3Idv+yqnrHw5I= MIME-Version: 1.0 Received: by 10.227.129.9 with SMTP id m9mr16403675wbs.1.1294440133215; Fri, 07 Jan 2011 14:42:13 -0800 (PST) Received: by 10.216.244.131 with HTTP; Fri, 7 Jan 2011 14:42:13 -0800 (PST) In-Reply-To: <4D278B93.8050903@isi.edu> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> Date: Fri, 7 Jan 2011 17:42:13 -0500 Message-ID: From: Josh Rambo To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , int-area@ietf.org Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 22:40:08 -0000 On Fri, Jan 7, 2011 at 4:54 PM, Joe Touch wrote: > > > On 1/7/2011 1:51 PM, Matthew Kaufman wrote: >> >> Ok. So just to verify, if a box that is sold today that does NAT44 >> out-of-the-box (I have one here on my desk, does DHCP client on the >> "WAN" port and serves DHCP for RFC1918 space for the "LAN" switch ports >> when first powered up) wants to comply with this it would need to also >> do NAT66 (with DHCPv6 serving ULA space on the "LAN" side, I guess...) >> when initially powered up? > > IMO, yes. That seems at odds with the goal of end-to-end transparency on the Internet= . If it boots up with NAT66 out of the box, then it requires user interventio= n to=A0remove that NAT66. You'd end up with NAT66 on every residential gatewa= y in the world. From touch@isi.edu Fri Jan 7 14:40:10 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCD0E28C13D; Fri, 7 Jan 2011 14:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qas-BbkDuY8X; Fri, 7 Jan 2011 14:40:09 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id DE1C63A6935; Fri, 7 Jan 2011 14:40:09 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p07Mg7Tp027819 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 7 Jan 2011 14:42:07 -0800 (PST) Message-ID: <4D2796BF.1030700@isi.edu> Date: Fri, 07 Jan 2011 14:42:07 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Brian E Carpenter References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> In-Reply-To: <4D27962F.9030005@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Operations , int-area@ietf.org Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 22:40:10 -0000 On 1/7/2011 2:39 PM, Brian E Carpenter wrote: > On 2011-01-08 10:54, Joe Touch wrote: >> >> >> On 1/7/2011 1:51 PM, Matthew Kaufman wrote: >>> Ok. So just to verify, if a box that is sold today that does NAT44 >>> out-of-the-box (I have one here on my desk, does DHCP client on the >>> "WAN" port and serves DHCP for RFC1918 space for the "LAN" switch ports >>> when first powered up) wants to comply with this it would need to also >>> do NAT66 (with DHCPv6 serving ULA space on the "LAN" side, I guess...) >>> when initially powered up? >> >> IMO, yes. > > IMO, no. See RFC 4864, draft-ietf-v6ops-cpe-simple-security, > and many related discussions. You're arguing against the need for 6-to-6 NAT. That's not my point at all. If it works for v6, it needs to work for v6. Period. Anything less than that *has been* and will continue to be used as a reason not to enable v6. Je From touch@isi.edu Fri Jan 7 14:42:22 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E6133A69A2; Fri, 7 Jan 2011 14:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQjc31VEWFGb; Fri, 7 Jan 2011 14:42:21 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 7F7653A6992; Fri, 7 Jan 2011 14:41:47 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p07MhYF8027999 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 7 Jan 2011 14:43:34 -0800 (PST) Message-ID: <4D279717.1050602@isi.edu> Date: Fri, 07 Jan 2011 14:43:35 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Brian E Carpenter References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> In-Reply-To: <4D27962F.9030005@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Operations , int-area@ietf.org Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 22:42:22 -0000 On 1/7/2011 2:39 PM, Brian E Carpenter wrote: > On 2011-01-08 10:54, Joe Touch wrote: >> >> >> On 1/7/2011 1:51 PM, Matthew Kaufman wrote: >>> Ok. So just to verify, if a box that is sold today that does NAT44 >>> out-of-the-box (I have one here on my desk, does DHCP client on the >>> "WAN" port and serves DHCP for RFC1918 space for the "LAN" switch ports >>> when first powered up) wants to comply with this it would need to also >>> do NAT66 (with DHCPv6 serving ULA space on the "LAN" side, I guess...) >>> when initially powered up? >> >> IMO, yes. > > IMO, no. See RFC 4864, draft-ietf-v6ops-cpe-simple-security, > and many related discussions. PS - these docs also ignore a valid reason for a NAT - which is to be a "single IP address front end to a set of back-end IP-capable devices". Such devices are important when a cluster of devices is intended to act as a single device on the Internet, and a NAT can be an effective way to implement that front-end. Joe From touch@isi.edu Fri Jan 7 14:45:42 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D90A28C0E3; Fri, 7 Jan 2011 14:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdXg4GnSur6h; Fri, 7 Jan 2011 14:45:41 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 5226128B797; Fri, 7 Jan 2011 14:45:41 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p07Mj6H8028509 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 7 Jan 2011 14:45:06 -0800 (PST) Message-ID: <4D279773.30102@isi.edu> Date: Fri, 07 Jan 2011 14:45:07 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Josh Rambo References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@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: IPv6 Operations , int-area@ietf.org Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 22:45:42 -0000 On 1/7/2011 2:42 PM, Josh Rambo wrote: > On Fri, Jan 7, 2011 at 4:54 PM, Joe Touch wrote: >> >> >> On 1/7/2011 1:51 PM, Matthew Kaufman wrote: >>> >>> Ok. So just to verify, if a box that is sold today that does NAT44 >>> out-of-the-box (I have one here on my desk, does DHCP client on the >>> "WAN" port and serves DHCP for RFC1918 space for the "LAN" switch ports >>> when first powered up) wants to comply with this it would need to also >>> do NAT66 (with DHCPv6 serving ULA space on the "LAN" side, I guess...) >>> when initially powered up? >> >> IMO, yes. > > That seems at odds with the goal of end-to-end transparency on the Internet. > If it boots up with NAT66 out of the box, then it requires user intervention > to remove that NAT66. You'd end up with NAT66 on every residential gateway > in the world. Again, you're arguing against NAT. That's not what I'm suggesting. If you really can make the case that a capability needs to be enabled for IPv4, but should never be enabled for V6, then *maybe* - but, again, that *will* be used as an excuse not to adopt the device in a V6 environment, IMO. If the box is a NAT, it's a NAT. If that's not what you want to sell, then don't include a NAT. Joe From dragoniz3r@gmail.com Fri Jan 7 14:46:53 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 969193A6935; Fri, 7 Jan 2011 14:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urE8pL6RJUTw; Fri, 7 Jan 2011 14:46:52 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id 625B028B797; Fri, 7 Jan 2011 14:46:52 -0800 (PST) Received: by wwi17 with SMTP id 17so946874wwi.1 for ; Fri, 07 Jan 2011 14:48:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ymLODk/MkYHOKqIna2e9zuUhJQb8P/EzFKUud2W6k0Y=; b=jvzpTAchuWYb90Kkq2V4pXRlamcgaDf7bdKrhHLD2Nd5+apx3HsbNmWepxkpUkd8M7 ioMFPRDZ4msEPT3WYq2poiLU4i6Afd72d9Gm+QOug9bBl2L6wgHBaJ1EzQZZTyoUu9tc FiVsKSNSwojP4tH/WQUDxsUFbJbCPXJ7l8cSk= 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=Yb5/dOFvrHb1FvCGSqCOcIJCOvoQQ+x5Wv2d+Vf7fWFbsNpP54DcCoLCP9m0EF0mEG JiYEN26sP/uo2gW5T8dcVeEBjnfXPMjvxEN0ad69AY7KGFzX/hTo/ULLlk4hXmTA1Kqk 4zo/9KIgKWcrEO6jMGoZOGCtuqvBv9ie6MLvM= MIME-Version: 1.0 Received: by 10.227.146.130 with SMTP id h2mr106140wbv.117.1294440475462; Fri, 07 Jan 2011 14:47:55 -0800 (PST) Received: by 10.216.244.131 with HTTP; Fri, 7 Jan 2011 14:47:55 -0800 (PST) In-Reply-To: <4D279773.30102@isi.edu> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D279773.30102@isi.edu> Date: Fri, 7 Jan 2011 17:47:55 -0500 Message-ID: From: Josh Rambo To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Operations , int-area@ietf.org Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 22:46:53 -0000 On Fri, Jan 7, 2011 at 5:45 PM, Joe Touch wrote: > > > On 1/7/2011 2:42 PM, Josh Rambo wrote: >> That seems at odds with the goal of end-to-end transparency on the >> Internet. >> If it boots up with NAT66 out of the box, then it requires user >> intervention >> to remove that NAT66. You'd end up with NAT66 on every residential gateway >> in the world. > > Again, you're arguing against NAT. That's not what I'm suggesting. > > If you really can make the case that a capability needs to be enabled for > IPv4, but should never be enabled for V6, then *maybe* - but, again, that > *will* be used as an excuse not to adopt the device in a V6 environment, > IMO. > > If the box is a NAT, it's a NAT. If that's not what you want to sell, then > don't include a NAT. I'm arguing that there are some features of v4 that are not appropriate to enable by default in v6. NAT is one of those features. A home, residential gateway is a gateway. That is it's true purpose. It's not a NAT box, it just has to perform that function to operate in the limited v4 address space. So, the true function of a gateway should be to be a gateway, which doesn't involve a NAT66. Just because v4 needs it by default doesn't mean v6 does or should. From rajiva@cisco.com Fri Jan 7 14:51:50 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3895F28C12E; Fri, 7 Jan 2011 14:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.193 X-Spam-Level: X-Spam-Status: No, score=-10.193 tagged_above=-999 required=5 tests=[AWL=0.406, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBL1TAdgPyoD; Fri, 7 Jan 2011 14:51:49 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B887428C127; Fri, 7 Jan 2011 14:51:48 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABsoJ02tJXG9/2dsb2JhbACkMHOjMpd/hUwEhGeJRogL Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rtp-iport-2.cisco.com with ESMTP; 07 Jan 2011 22:53:55 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p07MrsbK016083; Fri, 7 Jan 2011 22:53:54 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Jan 2011 16:53:54 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Jan 2011 16:53:52 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C03D201B9@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] IP-capable nodes must support IPv6 - newdraft-george-ipv6-required Thread-Index: AcuuvUgvIz7V8uGRRWuj+VcqmEIoCwAAEMpg References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com><4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu><4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu><4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu><4D279773.30102@isi.edu> From: "Rajiv Asati (rajiva)" To: "Josh Rambo" , "Joe Touch" X-OriginalArrivalTime: 07 Jan 2011 22:53:54.0663 (UTC) FILETIME=[C2929770:01CBAEBD] Cc: IPv6 Operations , int-area@ietf.org Subject: Re: [Int-area] IP-capable nodes must support IPv6 - newdraft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 22:51:50 -0000 It is imperative that the draft specify what basic IPv6 functionalities must be supported on every node. =20 I agree that there isn't any need for 1:1 mapping of IPv4 and IPv6 functionalities to be supported and/or enabled on the node. Cheers, Rajiv > -----Original Message----- > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On > Behalf Of Josh Rambo > Sent: Friday, January 07, 2011 5:48 PM > To: Joe Touch > Cc: IPv6 Operations; int-area@ietf.org > Subject: Re: [Int-area] IP-capable nodes must support IPv6 - newdraft- > george-ipv6-required >=20 > On Fri, Jan 7, 2011 at 5:45 PM, Joe Touch wrote: > > > > > > On 1/7/2011 2:42 PM, Josh Rambo wrote: > >> That seems at odds with the goal of end-to-end transparency on the > >> Internet. > >> If it boots up with NAT66 out of the box, then it requires user > >> intervention > >> to remove that NAT66. You'd end up with NAT66 on every residential > gateway > >> in the world. > > > > Again, you're arguing against NAT. That's not what I'm suggesting. > > > > If you really can make the case that a capability needs to be enabled > for > > IPv4, but should never be enabled for V6, then *maybe* - but, again, > that > > *will* be used as an excuse not to adopt the device in a V6 > environment, > > IMO. > > > > If the box is a NAT, it's a NAT. If that's not what you want to sell, > then > > don't include a NAT. >=20 > I'm arguing that there are some features of v4 that are not appropriate > to > enable by default in v6. NAT is one of those features. A home, > residential > gateway is a gateway. That is it's true purpose. It's not a NAT box, it > just > has to perform that function to operate in the limited v4 address > space. > So, the true function of a gateway should be to be a gateway, which > doesn't involve a NAT66. > Just because v4 needs it by default doesn't mean v6 does or should. > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From touch@isi.edu Fri Jan 7 14:53:56 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0CBD3A697E; Fri, 7 Jan 2011 14:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zHau3Y-G9LO; Fri, 7 Jan 2011 14:53:55 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 6E8FF3A6985; Fri, 7 Jan 2011 14:53:41 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p07MtgMv000417 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 7 Jan 2011 14:55:42 -0800 (PST) Message-ID: <4D2799EF.2070504@isi.edu> Date: Fri, 07 Jan 2011 14:55:43 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Josh Rambo References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D279773.30102@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: IPv6 Operations , int-area@ietf.org Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 22:53:56 -0000 On 1/7/2011 2:47 PM, Josh Rambo wrote: > On Fri, Jan 7, 2011 at 5:45 PM, Joe Touch wrote: >> >> >> On 1/7/2011 2:42 PM, Josh Rambo wrote: >>> That seems at odds with the goal of end-to-end transparency on the >>> Internet. >>> If it boots up with NAT66 out of the box, then it requires user >>> intervention >>> to remove that NAT66. You'd end up with NAT66 on every residential gateway >>> in the world. >> >> Again, you're arguing against NAT. That's not what I'm suggesting. >> >> If you really can make the case that a capability needs to be enabled for >> IPv4, but should never be enabled for V6, then *maybe* - but, again, that >> *will* be used as an excuse not to adopt the device in a V6 environment, >> IMO. >> >> If the box is a NAT, it's a NAT. If that's not what you want to sell, then >> don't include a NAT. > > I'm arguing that there are some features of v4 that are not appropriate to > enable by default in v6. NAT is one of those features. A home, residential > gateway is a gateway. That is it's true purpose. It's not a NAT box, it just > has to perform that function to operate in the limited v4 address space. That's one viewpoint; in that case, then the NAT would not need to support IPv6. However, some places expect the NAT for various reasons: - limits incoming connections (disrupting use of home net connections for business uses, or as a way to block viruses - not a great way, but it's one reason it's on even when not necessary) - enables better tracking of customer behavior (need to track only one IP address) - no need to run DHCP back to the CO (no impact on CO DHCP when users add/remove devices inside their house) - protect intra-house networking (again, not the best way to do this, but also can make it easier to prevent leakage of LAN-intended protocols into the CO, without requiring CO equipment to filter) > So, the true function of a gateway should be to be a gateway, which > doesn't involve a NAT66. > Just because v4 needs it by default doesn't mean v6 does or should. Understood. Caveats do apply. But the overall point is still valid - in general - with few, specific, and *deliberate* exceptions, if it works for IPv4, it ought to work for IPv6 too. Right now, e.g., many devices work fine to transit IPv6, but their net mgt needs IPv4. That's insufficient, IMO, to claim "IPv6" on a box. Joe From touch@isi.edu Fri Jan 7 14:57:01 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D33728C179; Fri, 7 Jan 2011 14:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VU+UBDiqvZ3i; Fri, 7 Jan 2011 14:57:01 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id E15C728C176; Fri, 7 Jan 2011 14:57:00 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p07MwP06000772 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 7 Jan 2011 14:58:25 -0800 (PST) Message-ID: <4D279A91.2040300@isi.edu> Date: Fri, 07 Jan 2011 14:58:25 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Rajiv Asati (rajiva)" References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com><4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu><4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu><4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu><4D279773.30102@isi.edu> <067E6CE33034954AAC05C9EC85E2577C03D201B9@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C03D201B9@XMB-RCD-111.cisco.com> 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, IPv6 Operations Subject: Re: [Int-area] IP-capable nodes must support IPv6 - newdraft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 22:57:01 -0000 On 1/7/2011 2:53 PM, Rajiv Asati (rajiva) wrote: > It is imperative that the draft specify what basic IPv6 functionalities > must be supported on every node. I'm not sure what that means, though. Nobody would *require* a router to support a GUI for management, but, IMO, if the GUI supplied works only for IPv4, it's a killer. Yes, there ought to be a list of IPv6 requirements, ala RFCs 1122, 1123, and 1812 (and their supplementary RFCs). But there's a broader issue - the point that "if IPv4 is supported better, in any way, than IPv6, on a device, then there is incentive to not use IPv6". Joe From rajiva@cisco.com Fri Jan 7 15:19:30 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D56603A69BF; Fri, 7 Jan 2011 15:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.26 X-Spam-Level: X-Spam-Status: No, score=-10.26 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZLAbkOVOvAh; Fri, 7 Jan 2011 15:19:29 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4604228B56A; Fri, 7 Jan 2011 15:17:21 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALstJ02tJXG//2dsb2JhbACkM3OjTJd+hUwEhGeJRogL Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rtp-iport-1.cisco.com with ESMTP; 07 Jan 2011 23:19:27 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p07NJR2t004210; Fri, 7 Jan 2011 23:19:27 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Jan 2011 17:19:27 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Jan 2011 17:19:25 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C03D201D0@XMB-RCD-111.cisco.com> In-Reply-To: <4D279A91.2040300@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] IP-capable nodes must support IPv6 - newdraft-george-ipv6-required Thread-Index: Acuuvn4iydAPseQ4RmSPGhg/38uBdQAAmU8g References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com><4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu><4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu><4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu><4D279773.30102@isi.edu> <067E6CE33034954AAC05C9EC85E2577C03D201B9@XMB-RCD-111.cisco.com> <4D279A91.2040300@isi.edu> From: "Rajiv Asati (rajiva)" To: "Joe Touch" X-OriginalArrivalTime: 07 Jan 2011 23:19:27.0370 (UTC) FILETIME=[54231EA0:01CBAEC1] Cc: int-area@ietf.org, IPv6 Operations Subject: Re: [Int-area] IP-capable nodes must support IPv6 - newdraft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 23:19:31 -0000 Joe, > Yes, there ought to be a list of IPv6 requirements, ala RFCs 1122, > 1123, and 1812 (and their supplementary RFCs).=20 Ditto. I am sure that we could come up with few more. > But there's a broader issue - > the point that "if IPv4 is supported better, in any way, than IPv6, on > a device, then there is incentive to not use IPv6". This broader issue in conjunction with all that exists on an IPv4 gateway may not be needed on an IPv6 gateway, warrants the set of MUST and SHOULD/MAY IPv6 features. That was the intent of my suggestion. =09 Cheers, Rajiv > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Friday, January 07, 2011 5:58 PM > To: Rajiv Asati (rajiva) > Cc: Josh Rambo; IPv6 Operations; int-area@ietf.org > Subject: Re: [Int-area] IP-capable nodes must support IPv6 - newdraft- > george-ipv6-required >=20 >=20 >=20 > On 1/7/2011 2:53 PM, Rajiv Asati (rajiva) wrote: > > It is imperative that the draft specify what basic IPv6 > functionalities > > must be supported on every node. >=20 > I'm not sure what that means, though. Nobody would *require* a router > to > support a GUI for management, but, IMO, if the GUI supplied works only > for IPv4, it's a killer. >=20 > Yes, there ought to be a list of IPv6 requirements, ala RFCs 1122, > 1123, > and 1812 (and their supplementary RFCs). But there's a broader issue - > the point that "if IPv4 is supported better, in any way, than IPv6, on > a > device, then there is incentive to not use IPv6". >=20 > Joe From brian.e.carpenter@gmail.com Fri Jan 7 15:21:22 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2AD628C11F; Fri, 7 Jan 2011 15:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.446 X-Spam-Level: X-Spam-Status: No, score=-103.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5vJHMHSPQ1D; Fri, 7 Jan 2011 15:21:22 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 98F5B3A6995; Fri, 7 Jan 2011 15:18:40 -0800 (PST) Received: by vws7 with SMTP id 7so7118141vws.31 for ; Fri, 07 Jan 2011 15:20:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=r6FhRfmsok4UUkIwTiE6HzpCJbvxgbq6r0J6hAQKm7M=; b=GDeJ5J3vzcq0cHAYR0sh5qErBPMze0tn+RktEwYomT4vvI2yyxOdmvekp0ok6mg0Ri TgnNfCQcp7a8EjnjVY4EpUX4LkKo01K9hkE/9dWGJo77SlTqs0nm/emsbPo0k9mh16oi fDgE5+Bt4K2wB2R6qt1Znyk0h+Xtwf8QJjQnM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=m1/nDufk0VCuXeFp8ljCCdpHOpoW/i+3BMsL6gHmRci89Fo7JmMdkIaow1MoSWRLX1 7FWXbkiechJ+9Y2kzdO9CLAgcHTDZRtGqrdyQAydmi5hH4h0SZTjOasc4BvmssX3Tumx cg/RbFyYWJQGiYw1gOuJETGNt7rtQ+2uQ0LQ4= Received: by 10.220.201.1 with SMTP id ey1mr7803914vcb.61.1294442446971; Fri, 07 Jan 2011 15:20:46 -0800 (PST) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id bq5sm5873571vcb.32.2011.01.07.15.20.43 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 15:20:45 -0800 (PST) Message-ID: <4D279FC7.3000904@gmail.com> Date: Sat, 08 Jan 2011 12:20:39 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joe Touch References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> <4D279717.1050602@isi.edu> In-Reply-To: <4D279717.1050602@isi.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , int-area@ietf.org Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 23:21:23 -0000 > PS - these docs also ignore a valid reason for a NAT - which is to be a > "single IP address front end to a set of back-end IP-capable devices". > Such devices are important when a cluster of devices is intended to act > as a single device on the Internet, and a NAT can be an effective way to > implement that front-end. Yes, that's the one described in US patent 5371852. I don't think the IETF has strayed into that territory. Brian From fernando.gont.netbook.win@gmail.com Fri Jan 7 19:27:22 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFED53A6987; Fri, 7 Jan 2011 19:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.931 X-Spam-Level: X-Spam-Status: No, score=-2.931 tagged_above=-999 required=5 tests=[AWL=0.668, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id We5WY8LSgw2N; Fri, 7 Jan 2011 19:27:01 -0800 (PST) Received: from mail-yx0-f194.google.com (mail-yx0-f194.google.com [209.85.213.194]) by core3.amsl.com (Postfix) with ESMTP id E54633A695C; Fri, 7 Jan 2011 19:26:54 -0800 (PST) Received: by yxd5 with SMTP id 5so3968264yxd.1 for ; Fri, 07 Jan 2011 19:29:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=mIQ1/GBTO0haJ1kcr0+sVPIXqFc1BngWLsblw2OZHYw=; b=Y9doJBH41gmlb9EpLaicrberwZ1EB7I3kk5zhpS5fjMmNqT6Qp9/v4IlepppIGooq+ gIVfpjrbCNz4kb1Qa3cYaM8B5q+cKZPgx52hw+wqszfvXQWZdV5okBk3DKkjvSc0Q9BM 1qNzpzQ7voracOKcd7NgF5MI2tznP9t8VeNGE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=E4GFiHFzV4OGIhnJLE91E66ZafFJNBxcmODB5vzj0Zc5mLT6YjS4Aj5Bi+pPMerh4a i0klqxRwmKM+/TCcClk6+ZttyiHnbqygc4jJJxB8MmdhVsVjH8+w601QbJ7vlVNEC3z/ BMRmBBn10E5xgKBjMo2hS5uLhXodfmtZ3oAK4= Received: by 10.150.202.7 with SMTP id z7mr23933416ybf.436.1294457339716; Fri, 07 Jan 2011 19:28:59 -0800 (PST) Received: from [192.168.123.100] ([190.48.240.140]) by mx.google.com with ESMTPS id v4sm850696ybe.17.2011.01.07.19.28.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 19:28:58 -0800 (PST) Sender: Fernando Gont Message-ID: <4D27D9EB.4010209@gont.com.ar> Date: Sat, 08 Jan 2011 00:28:43 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Josh Rambo References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , int-area@ietf.org Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 03:27:23 -0000 On 07/01/2011 07:42 p.m., Josh Rambo wrote: > That seems at odds with the goal of end-to-end transparency on the Internet. > If it boots up with NAT66 out of the box, then it requires user intervention > to remove that NAT66. You'd end up with NAT66 on every residential gateway > in the world. End-to-end transparency in the sense that every node will be reachable from every node? -- IMHO, forget about it (see slide 13 of: http://www.gont.com.ar/talks/lacnog2010/fgont-lacnog2010-ipv6-security.pdf) Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From edward.jankiewicz@sri.com Fri Jan 7 21:01:37 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25A743A698A; Fri, 7 Jan 2011 21:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.842 X-Spam-Level: X-Spam-Status: No, score=-1.842 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovVNa9wZZGyR; Fri, 7 Jan 2011 21:01:36 -0800 (PST) Received: from mail1.sri.com (newmail.SRI.COM [128.18.30.17]) by core3.amsl.com (Postfix) with ESMTP id 58CB33A6985; Fri, 7 Jan 2011 21:01:36 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [192.168.1.144] ([unknown] [68.81.23.64]) by mail.sri.com (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LEO009F9G641440@mail.sri.com>; Fri, 07 Jan 2011 16:03:42 -0800 (PST) Message-id: <4D27A9DB.9020302@sri.com> Date: Fri, 07 Jan 2011 19:03:39 -0500 From: Ed Jankiewicz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 To: "Rajiv Asati (rajiva)" References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D279773.30102@isi.edu> <067E6CE33034954AAC05C9EC85E2577C03D201B9@XMB-RCD-111.cisco.com> <4D279A91.2040300@isi.edu> <067E6CE33034954AAC05C9EC85E2577C03D201D0@XMB-RCD-111.cisco.com> In-reply-to: <067E6CE33034954AAC05C9EC85E2577C03D201D0@XMB-RCD-111.cisco.com> Cc: IPv6 Operations , int-area@ietf.org Subject: Re: [Int-area] IP-capable nodes must support IPv6 - newdraft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 05:01:37 -0000 there is a list of IPv6 requirements in RFC 4294, although it is only Informational, and is currently being replaced by draft-6man-node-req-bis (in process). It was not intended to be an absolute statement of the IPv6 requirements, so it may not completely satisfy the need for a standards track analog to RFC 1122 et al. I think we should be careful not to let this degenerate into yet another "tastes great/less filling" debate on NAT, but when we aim for IPv6 parity with IPv4 features we could distinguish between the standards for internetworking embodied in IPv4 and the things that were added on in non-standard ways. On 1/7/2011 6:19 PM, Rajiv Asati (rajiva) wrote: > Joe, > >> Yes, there ought to be a list of IPv6 requirements, ala RFCs 1122, >> 1123, and 1812 (and their supplementary RFCs). > Ditto. I am sure that we could come up with few more. > >> But there's a broader issue - >> the point that "if IPv4 is supported better, in any way, than IPv6, on >> a device, then there is incentive to not use IPv6". > This broader issue in conjunction with all that exists on an IPv4 > gateway may not be needed on an IPv6 gateway, warrants the set of MUST > and SHOULD/MAY IPv6 features. That was the intent of my suggestion. > > Cheers, > Rajiv > > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Friday, January 07, 2011 5:58 PM >> To: Rajiv Asati (rajiva) >> Cc: Josh Rambo; IPv6 Operations; int-area@ietf.org >> Subject: Re: [Int-area] IP-capable nodes must support IPv6 - newdraft- >> george-ipv6-required >> >> >> >> On 1/7/2011 2:53 PM, Rajiv Asati (rajiva) wrote: >>> It is imperative that the draft specify what basic IPv6 >> functionalities >>> must be supported on every node. >> I'm not sure what that means, though. Nobody would *require* a router >> to >> support a GUI for management, but, IMO, if the GUI supplied works only >> for IPv4, it's a killer. >> >> Yes, there ought to be a list of IPv6 requirements, ala RFCs 1122, >> 1123, >> and 1812 (and their supplementary RFCs). But there's a broader issue - >> the point that "if IPv4 is supported better, in any way, than IPv6, on >> a >> device, then there is incentive to not use IPv6". >> >> Joe > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or ed.jankiewicz@sri.com From randy@psg.com Sat Jan 8 02:54:08 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65EB63A69CD; Sat, 8 Jan 2011 02:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vPkEgueYwS0; Sat, 8 Jan 2011 02:53:32 -0800 (PST) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id 2E11E3A69CB; Sat, 8 Jan 2011 02:53:29 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PbWRA-000HtI-EJ; Sat, 08 Jan 2011 10:54:20 +0000 Date: Sat, 08 Jan 2011 19:54:19 +0900 Message-ID: From: Randy Bush To: Wes George In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Ops WG , int-area@ietf.org Subject: Re: [Int-area] [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 10:54:08 -0000 > We'd appreciate your support in adopting this as an int-area draft, or > possibly a v6ops draft. i support this being adopted some place so it can be discussed and move forward randy From lee@asgard.org Sat Jan 8 07:30:20 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30DE43A6984 for ; Sat, 8 Jan 2011 07:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0H0fGAVadB7 for ; Sat, 8 Jan 2011 07:30:19 -0800 (PST) Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com [205.178.146.59]) by core3.amsl.com (Postfix) with ESMTP id 48C123A6934 for ; Sat, 8 Jan 2011 07:30:18 -0800 (PST) Received: from cm-omr10 (mail.networksolutionsemail.com [205.178.146.50]) by omr9.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p08FWQQM027920 for ; Sat, 8 Jan 2011 10:32:26 -0500 Authentication-Results: cm-omr10 smtp.user=lee@asgard.org; auth=pass (LOGIN) X-Authenticated-UID: lee@asgard.org Received: from [96.255.55.40] ([96.255.55.40:1596] helo=HDC00027112) by cm-omr10 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 57/AB-09637-ADE782D4; Sat, 08 Jan 2011 10:12:26 -0500 From: "Lee Howard" To: "'Joe Touch'" , "'Rajiv Asati \(rajiva\)'" References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com><4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu><4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu><4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu><4D279773.30102@isi.edu> <067E6CE33034954AAC05C9EC85E2577C03D201B9@XMB-RCD-111.cisco.com> <4D279A91.2040300@isi.edu> In-Reply-To: <4D279A91.2040300@isi.edu> Date: Sat, 8 Jan 2011 10:12:23 -0500 Message-ID: <000201cbaf46$742a93b0$5c7fbb10$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuuxEXqmQLPo0NsRA6Mzbv1ltrjvAAgBEig Content-Language: en-us Cc: 'IPv6 Operations' , int-area@ietf.org Subject: Re: [Int-area] IP-capable nodes must support IPv6 - newdraft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 15:30:20 -0000 > > On 1/7/2011 2:53 PM, Rajiv Asati (rajiva) wrote: > > It is imperative that the draft specify what basic IPv6 functionalities > > must be supported on every node. > > I'm not sure what that means, though. Nobody would *require* a router to > support a GUI for management, but, IMO, if the GUI supplied works only > for IPv4, it's a killer. > > Yes, there ought to be a list of IPv6 requirements, ala RFCs 1122, 1123, > and 1812 (and their supplementary RFCs). See rfc4294, IPv6 Node Requirements, and draft-ietf-v6ops-cpe-router, Basic Requirements for IPv6 Customer Edge Routers, both of which are cited in draft-george. Including requirements by reference is the right way to go, here. If there are additional requirements, they should be in separate drafts updating those requirements documents. > But there's a broader issue - > the point that "if IPv4 is supported better, in any way, than IPv6, on a > device, then there is incentive to not use IPv6". If IPv6 isn't supported at all, it doesn't matter what the incentive is. I believe there is consensus that NAT66 should not be defined, or on by default (I don't see it in the BEHAVE charter, for instance). Therefore, requiring NAT66 is equivalent to prohibiting IPv6. Lee From fernando.gont.netbook.win@gmail.com Sat Jan 8 11:38:55 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1BC23A6814; Sat, 8 Jan 2011 11:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.027 X-Spam-Level: X-Spam-Status: No, score=-3.027 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eleornPtidc1; Sat, 8 Jan 2011 11:38:55 -0800 (PST) Received: from mail-yw0-f66.google.com (mail-yw0-f66.google.com [209.85.213.66]) by core3.amsl.com (Postfix) with ESMTP id 5B55F3A6813; Sat, 8 Jan 2011 11:38:54 -0800 (PST) Received: by ywi6 with SMTP id 6so4047929ywi.1 for ; Sat, 08 Jan 2011 11:41:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=B1f5GvnzvC6+CBHarPTu8IQjtZ0OKPg8kUG+h2lSW8g=; b=SjhI/FcoHtowblp6vPzLb2GczWKF1FXQSTZO8Dv8HKu0gZ9gzuE4aG7RSnBQTvl7Fd 7LL/my9rBjHpzPBezaRn9A5T1ijPO1Ec+BMRDpcpJOAg/iowx827akjRoi8jka+7ihMQ ljqwyQW8/6nXBg3fTbHcEcQnAcAVoy1OHH9Xk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=ZcWQs74I0VgJGg7D8t5OE6yApVqYWCDAuKNPPYVB0Mlkbb4bwcpPuopfEIjncyIFB+ ICtV4GgSx0tFEYB1cxr/sqC+6mxTbe4GirtGhdmknyaXdn2SyUxnpLY1Su9FhtMYeiZq Ri3XbRwDE6Ew6j494BYMI4RK8HxYUBPkAowus= Received: by 10.91.83.18 with SMTP id k18mr4622283agl.79.1294515662551; Sat, 08 Jan 2011 11:41:02 -0800 (PST) Received: from [192.168.0.127] (61-128-17-190.fibertel.com.ar [190.17.128.61]) by mx.google.com with ESMTPS id z12sm3825655anp.19.2011.01.08.11.40.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 08 Jan 2011 11:41:01 -0800 (PST) Sender: Fernando Gont Message-ID: <4D27D7A6.8040506@gont.com.ar> Date: Sat, 08 Jan 2011 00:19:02 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Joe Touch References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> <4D279717.1050602@isi.edu> In-Reply-To: <4D279717.1050602@isi.edu> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , int-area@ietf.org Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 19:38:55 -0000 On 07/01/2011 07:43 p.m., Joe Touch wrote: >> IMO, no. See RFC 4864, draft-ietf-v6ops-cpe-simple-security, >> and many related discussions. > > PS - these docs also ignore a valid reason for a NAT - which is to be a > "single IP address front end to a set of back-end IP-capable devices". > Such devices are important when a cluster of devices is intended to act > as a single device on the Internet, and a NAT can be an effective way to > implement that front-end. ... and don't forget about "renumbering". Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From joelja@bogus.com Sat Jan 8 12:35:31 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB9603A682A; Sat, 8 Jan 2011 12:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XznzUHkrvKBw; Sat, 8 Jan 2011 12:35:30 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 0CCB03A6820; Sat, 8 Jan 2011 12:35:29 -0800 (PST) Received: from joelja-mac.local ([216.9.106.63]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p08KbRNk088580 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 8 Jan 2011 20:37:30 GMT (envelope-from joelja@bogus.com) Message-ID: <4D28CB08.2070805@bogus.com> Date: Sat, 08 Jan 2011 12:37:28 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fernando Gont References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> <4D279717.1050602@isi.edu> <4D27D7A6.8040506@gont.com.ar> In-Reply-To: <4D27D7A6.8040506@gont.com.ar> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , int-area@ietf.org Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 20:35:32 -0000 On 1/7/11 7:19 PM, Fernando Gont wrote: > On 07/01/2011 07:43 p.m., Joe Touch wrote: > >>> IMO, no. See RFC 4864, draft-ietf-v6ops-cpe-simple-security, >>> and many related discussions. >> >> PS - these docs also ignore a valid reason for a NAT - which is to be a >> "single IP address front end to a set of back-end IP-capable devices". >> Such devices are important when a cluster of devices is intended to act >> as a single device on the Internet, and a NAT can be an effective way to >> implement that front-end. Oddly enough load-balancers that support ipv6 support nat66 and nat64... 1 to 1 and 1 to n dnat are basic and essential functions of service abstraction. joel > ... and don't forget about "renumbering". > > Thanks, From ipng@69706e6720323030352d30312d31340a.nosense.org Sat Jan 8 16:07:55 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CBC628C14F; Sat, 8 Jan 2011 16:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.281 X-Spam-Level: X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8suTef+x9sZV; Sat, 8 Jan 2011 16:07:54 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id B243E28C120; Sat, 8 Jan 2011 16:07:53 -0800 (PST) Received: from 182-239-157-145.ip.adam.com.au ([182.239.157.145] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Pbir7-0001EJ-BD; Sun, 09 Jan 2011 10:39:57 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 872F03B31E; Sun, 9 Jan 2011 10:39:56 +1030 (CST) Date: Sun, 9 Jan 2011 10:39:56 +1030 From: Mark Smith To: Joe Touch Message-ID: <20110109103956.383b2284@opy.nosense.org> In-Reply-To: <4D279717.1050602@isi.edu> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> <4D279717.1050602@isi.edu> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , int-area@ietf.org Subject: Re: [Int-area] [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 00:07:55 -0000 On Fri, 07 Jan 2011 14:43:35 -0800 Joe Touch wrote: > > > On 1/7/2011 2:39 PM, Brian E Carpenter wrote: > > On 2011-01-08 10:54, Joe Touch wrote: > >> > >> > >> On 1/7/2011 1:51 PM, Matthew Kaufman wrote: > >>> Ok. So just to verify, if a box that is sold today that does NAT44 > >>> out-of-the-box (I have one here on my desk, does DHCP client on the > >>> "WAN" port and serves DHCP for RFC1918 space for the "LAN" switch ports > >>> when first powered up) wants to comply with this it would need to also > >>> do NAT66 (with DHCPv6 serving ULA space on the "LAN" side, I guess...) > >>> when initially powered up? > >> > >> IMO, yes. > > > > IMO, no. See RFC 4864, draft-ietf-v6ops-cpe-simple-security, > > and many related discussions. > > PS - these docs also ignore a valid reason for a NAT - which is to be a > "single IP address front end to a set of back-end IP-capable devices". > Such devices are important when a cluster of devices is intended to act > as a single device on the Internet, and a NAT can be an effective way to > implement that front-end. > It sounds like you're adopting the "Law of the instrument" regarding NAT - "It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail." NAT may have been the only tool in IPv4 for these problems, because there wasn't enough address space to solve them any other way. That constraint doesn't exist in IPv6, so other solutions which don't have the limitations NAT creates may now be possible. If you just blindly assume NAT is the only way to solve these problems, how will you discover better ones? > Joe > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From remi.despres@free.fr Mon Jan 10 00:28:02 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C2EC28C0F5; Mon, 10 Jan 2011 00:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.427 X-Spam-Level: X-Spam-Status: No, score=-1.427 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpwQH+DcG5fZ; Mon, 10 Jan 2011 00:28:01 -0800 (PST) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.22]) by core3.amsl.com (Postfix) with ESMTP id 5915A28C0DF; Mon, 10 Jan 2011 00:28:01 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2301.sfr.fr (SMTP Server) with ESMTP id 6244070015A1; Mon, 10 Jan 2011 09:30:13 +0100 (CET) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2301.sfr.fr (SMTP Server) with ESMTP id EC3C070016CB; Mon, 10 Jan 2011 09:30:12 +0100 (CET) X-SFR-UUID: 20110110083012967.EC3C070016CB@msfrf2301.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4D27D9EB.4010209@gont.com.ar> Date: Mon, 10 Jan 2011 09:30:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> To: Fernando Gont , Josh Rambo X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations , Internet Area Subject: [Int-area] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 08:28:02 -0000 Le 8 janv. 2011 =E0 04:28, Fernando Gont a =E9crit : > On 07/01/2011 07:42 p.m., Josh Rambo wrote: >> That seems at odds with the goal of end-to-end transparency on the = Internet. >> If it boots up with NAT66 out of the box, then it requires user = intervention >> to remove that NAT66. You'd end up with NAT66 on every residential = gateway >> in the world. >=20 > End-to-end transparency in the sense that every node will be reachable > from every node? The e2e transparency that IPv4 had lost, and IPv6 restores, is ADDRESS = transparency: source and destination addresses seen by a destination are = the same as those set by the source.=20 - This is needed in particular for Header Authentication of IPsec. - Also, it permits a host to advertise its source address in the DNS and = in referrals. It is preserved between two hosts using ULA's in a common customer site. It should remain possible between hosts in two independent customer = sites. =20 Restricting reachability, where needed, is Firewall's function. Firewalls DON'T NEED to sacrifice in address transparency do do what = they have to do.=20 Regards, RD=20 From ipng@69706e6720323030352d30312d31340a.nosense.org Mon Jan 10 00:43:40 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDE1828C0F2; Mon, 10 Jan 2011 00:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.133 X-Spam-Level: X-Spam-Status: No, score=-1.133 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4wXq20jN72A; Mon, 10 Jan 2011 00:43:40 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id C321928C0DF; Mon, 10 Jan 2011 00:43:39 -0800 (PST) Received: from 182-239-157-145.ip.adam.com.au ([182.239.157.145] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1PcDNg-0000o4-Ru; Mon, 10 Jan 2011 19:15:36 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 1712E3B335; Mon, 10 Jan 2011 19:15:36 +1030 (CST) Date: Mon, 10 Jan 2011 19:15:35 +1030 From: Mark Smith To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= Message-ID: <20110110191535.3c32bc4b@opy.nosense.org> In-Reply-To: <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Internet Area , IPv6 Operations Subject: Re: [Int-area] [v6ops] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 08:43:41 -0000 On Mon, 10 Jan 2011 09:30:12 +0100 R=C3=A9mi Despr=C3=A9s wrote: >=20 > Le 8 janv. 2011 =C3=A0 04:28, Fernando Gont a =C3=A9crit : > > On 07/01/2011 07:42 p.m., Josh Rambo wrote: > >> That seems at odds with the goal of end-to-end transparency on the Int= ernet. > >> If it boots up with NAT66 out of the box, then it requires user interv= ention > >> to remove that NAT66. You'd end up with NAT66 on every residential gat= eway > >> in the world. > >=20 > > End-to-end transparency in the sense that every node will be reachable > > from every node? >=20 > The e2e transparency that IPv4 had lost, and IPv6 restores, is ADDRESS tr= ansparency: source and destination addresses seen by a destination are the = same as those set by the source.=20 > - This is needed in particular for Header Authentication of IPsec. > - Also, it permits a host to advertise its source address in the DNS and = in referrals. >=20 > It is preserved between two hosts using ULA's in a common customer site. > It should remain possible between hosts in two independent customer sites. > =20 > Restricting reachability, where needed, is Firewall's function. And can also be a host's decision and function. It actually has to be if there is no assurance of existence or confidence in the operation of a network located upstream firewall - and as more and more multi-homed mobile hosts become popular (a.k.a. smartphones, laptops, tablets, netbooks - everybody has got at least one of those haven't they?) - assurance of or confidence in an upstream firewall is naturally going to become reduced over time. > Firewalls DON'T NEED to sacrifice in address transparency do do what they= have to do.=20 >=20 > Regards, > RD=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From gvandeve@cisco.com Mon Jan 10 02:31:46 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5F173A695B; Mon, 10 Jan 2011 02:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.747 X-Spam-Level: X-Spam-Status: No, score=-9.747 tagged_above=-999 required=5 tests=[AWL=0.852, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQlcXup5eelk; Mon, 10 Jan 2011 02:31:45 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id E58F53A694F; Mon, 10 Jan 2011 02:31:45 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAO9uKk2rR7H+/2dsb2JhbACkPnOkBZdRhUwEjjCICw Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 10 Jan 2011 10:33:59 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0AAXgvf005500; Mon, 10 Jan 2011 10:33:59 GMT Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Jan 2011 11:33:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Jan 2011 11:33:56 +0100 Message-ID: <4269EA985EACD24987D82DAE2FEC62E502DF203B@XMB-AMS-101.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C03D201D0@XMB-RCD-111.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] [Int-area] IP-capable nodes must support IPv6 -newdraft-george-ipv6-required Thread-Index: Acuuvn4iydAPseQ4RmSPGhg/38uBdQAAmU8gAHwiuuA= References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com><4D277357.2050109@sri.com><4D277EA5.9080304@isi.edu><4D278833.8090208@matthew.at><4D2789AF.1050903@isi.edu><4D278AE7.4080502@matthew.at><4D278B93.8050903@isi.edu><4D279773.30102@isi.edu><067E6CE33034954AAC05C9EC85E2577C03D201B9@XMB-RCD-111.cisco.com><4D279A91.2040300@isi.edu> <067E6CE33034954AAC05C9EC85E2577C03D201D0@XMB-RCD-111.cisco.com> From: "Gunter Van de Velde (gvandeve)" To: "Rajiv Asati (rajiva)" , "Joe Touch" X-OriginalArrivalTime: 10 Jan 2011 10:33:57.0661 (UTC) FILETIME=[E322F4D0:01CBB0B1] Cc: IPv6 Operations , int-area@ietf.org Subject: Re: [Int-area] [v6ops] IP-capable nodes must support IPv6 -newdraft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 10:31:47 -0000 <>start snip<> > the point that "if IPv4 is supported better, in any way, than IPv6, on > a device, then there is incentive to not use IPv6". This broader issue in conjunction with all that exists on an IPv4 gateway may not be needed on an IPv6 gateway, warrants the set of MUST and SHOULD/MAY IPv6 features. That was the intent of my suggestion. <>end snip<> I am interested to understand 'how' you want to quantify the IPv6 vs IPv4 service experience. G/ -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Rajiv Asati (rajiva) Sent: zaterdag 8 januari 2011 0:19 To: Joe Touch Cc: int-area@ietf.org; IPv6 Operations Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 -newdraft-george-ipv6-required Joe, > Yes, there ought to be a list of IPv6 requirements, ala RFCs 1122, > 1123, and 1812 (and their supplementary RFCs).=20 Ditto. I am sure that we could come up with few more. > But there's a broader issue - > the point that "if IPv4 is supported better, in any way, than IPv6, on > a device, then there is incentive to not use IPv6". This broader issue in conjunction with all that exists on an IPv4 gateway may not be needed on an IPv6 gateway, warrants the set of MUST and SHOULD/MAY IPv6 features. That was the intent of my suggestion. =09 Cheers, Rajiv From remi.despres@free.fr Mon Jan 10 05:15:18 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D065E28C15E; Mon, 10 Jan 2011 05:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.432 X-Spam-Level: X-Spam-Status: No, score=-1.432 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSJ9ta-lGpuu; Mon, 10 Jan 2011 05:15:18 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by core3.amsl.com (Postfix) with ESMTP id 0A6CE3A698A; Mon, 10 Jan 2011 05:15:18 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2404.sfr.fr (SMTP Server) with ESMTP id 226D5700008C; Mon, 10 Jan 2011 14:17:31 +0100 (CET) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2404.sfr.fr (SMTP Server) with ESMTP id AB5CA7000086; Mon, 10 Jan 2011 14:17:30 +0100 (CET) X-SFR-UUID: 20110110131730702.AB5CA7000086@msfrf2404.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 10 Jan 2011 14:17:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <20110110191535.3c32bc4b@opy.nosense.org> To: carlos@lacnic.net X-Mailer: Apple Mail (2.1082) Cc: Mark Smith , IPv6 Operations , Internet Area Subject: Re: [Int-area] [v6ops] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 13:15:18 -0000 Le 10 janv. 2011 =E0 13:04, Carlos Martinez-Cagnazzo a =E9crit : > We already have that today with IPv4, not at protocol level, but any > operating system can operate a packet filter. Having host-based > firewalls also does not mean that we have to sacrifice address > transparency. Right. > On Mon, Jan 10, 2011 at 6:45 AM, Mark Smith > wrote: >> On Mon, 10 Jan 2011 09:30:12 +0100 >> R=E9mi Despr=E9s wrote: >>> ... >>> Restricting reachability, where needed, is Firewall's function. >>=20 >> And can also be a host's decision and function. It actually has to be = if >> there is no assurance of existence or confidence in the operation of = a >> network located upstream firewall=20 Agreed: hosts already restrict reachability by themselves, and this is a = must-have function. (Note that, this being done by their integrated firewall, it still is a = "firewall" function ;-).)=20 Regards, RD From Wesley.E.George@sprint.com Mon Jan 10 07:47:31 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C95093A67ED; Mon, 10 Jan 2011 07:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.804 X-Spam-Level: X-Spam-Status: No, score=-3.804 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtsQZ8a5mmld; Mon, 10 Jan 2011 07:47:30 -0800 (PST) Received: from DB3EHSOBE005.bigfish.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by core3.amsl.com (Postfix) with ESMTP id 39DF83A682A; Mon, 10 Jan 2011 07:47:30 -0800 (PST) Received: from mail47-db3-R.bigfish.com (10.3.81.247) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.8; Mon, 10 Jan 2011 15:49:43 +0000 Received: from mail47-db3 (localhost.localdomain [127.0.0.1]) by mail47-db3-R.bigfish.com (Postfix) with ESMTP id 4D72B17A0105; Mon, 10 Jan 2011 15:49:43 +0000 (UTC) X-SpamScore: -60 X-BigFish: VS-60(zz542N1418M1432N1455M1447R9371Pzz1202hzz8275dh1033ILz2fh2a8h668h34h) X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:pdaasdm2.corp.sprint.com; RD:smtpda2.sprint.com; EFVD:NLI Received: from mail47-db3 (localhost.localdomain [127.0.0.1]) by mail47-db3 (MessageSwitch) id 1294674582965328_5400; Mon, 10 Jan 2011 15:49:42 +0000 (UTC) Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.247]) by mail47-db3.bigfish.com (Postfix) with ESMTP id E6CB14E8001; Mon, 10 Jan 2011 15:49:42 +0000 (UTC) Received: from pdaasdm2.corp.sprint.com (144.229.32.57) by DB3EHSMHS005.bigfish.com (10.3.87.105) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 10 Jan 2011 15:49:41 +0000 Received: from PLSWEH02.ad.sprint.com (PLSWEH02.corp.sprint.com [144.226.242.131]) by pdaasdm2.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p0AFgjOf028090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Jan 2011 09:42:48 -0600 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PLSWEH02.ad.sprint.com ([2002:90e2:f283::90e2:f283]) with mapi id 14.01.0255.000; Mon, 10 Jan 2011 09:49:34 -0600 From: "George, Wes E [NTK]" To: "Rajiv Asati (rajiva)" , Joe Touch Thread-Topic: [Int-area] IP-capable nodes must support IPv6 -newdraft-george-ipv6-required Thread-Index: AQHLrr3OZ1PupmJS+kufkXHyVXljfpPGg+GAgAAF3oCAA8NuYA== Date: Mon, 10 Jan 2011 15:49:33 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E04B86A@PLSWM12A.ad.sprint.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com><4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu><4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu><4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu><4D279773.30102@isi.edu> <067E6CE33034954AAC05C9EC85E2577C03D201B9@XMB-RCD-111.cisco.com> <4D279A91.2040300@isi.edu> <067E6CE33034954AAC05C9EC85E2577C03D201D0@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C03D201D0@XMB-RCD-111.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.27] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_004F_01CBB0B4.10AFF540" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Cc: IPv6 Operations , "int-area@ietf.org" Subject: Re: [Int-area] IP-capable nodes must support IPv6 -newdraft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 15:47:32 -0000 ------=_NextPart_000_004F_01CBB0B4.10AFF540 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On > Behalf Of Rajiv Asati (rajiva) > Sent: Friday, January 07, 2011 6:19 PM > Subject: Re: [Int-area] IP-capable nodes must support IPv6 - newdraft- > george-ipv6-required > > > Yes, there ought to be a list of IPv6 requirements, ala RFCs 1122, > > 1123, and 1812 (and their supplementary RFCs). > > Ditto. I am sure that we could come up with few more. > [WES] I think that those lists already exist for IPv6, but not always in exactly the same form as the IPv4 specs you reference above. I assume that the IPv6 specifications aren't listed as updates to the above IPv4 RFCs because IPv6 was considered optional, not a direct replacement for IPv4. I wasn't about to go so far as to deprecate the appropriate IPv4 spec in favor of the IPv6 one... baby steps :-) Either way, this draft is meant to be a generic update informing those who are considering putting an IP stack on their device, whether dumb or smart, simple or complex, that they need to stop considering IPv6 optional. We intentionally kept it generic so that it could be adopted more quickly - the sooner we correct the lack of IPv6 support in devices and software, the better off we are. That said, it may be helpful to write a draft comparing IPv4 and IPv6 for feature parity to identify future work items for IETF and point to the appropriate RFCs where equivalent features exist, but I view that as complimentary to this draft, not part of it. I agree that the more specific information about what we mean by "support IPv6" should be made available, but as references, not text in the draft itself. The draft already references ietf-v6ops-ipv6-cpe-router, and RFC 4294, which I've been informed will soon be replaced by a BIS version (currently draft-ietf-6man-node-req-bis). I will update that reference in the next version of the draft. The draft also formally updates 1812 and 1122. I can add 1123 to that list of updated drafts if there is consensus that it should be added. Brian Carpenter also recommended (offlist) that we might want to consider adding RFC4084 to the update list, specifically, moving "Version" from section 4 (additional terminology) to section 2 (general terminology). What are your thoughts on that? What else is missing as a reference? Keep in mind that the existing referenced drafts and RFCs have multiple normative and informative references of their own which we didn't see the need to duplicate here. Thanks for the support thus far. Wes George ------=_NextPart_000_004F_01CBB0B4.10AFF540 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXHjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggarMIIFk6ADAgECAgo8 FVeJAAAAAZIPMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMDgwNTAxMTczNzE0WhcNMTEwNTAx MTczNzE0WjCBzzETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxEDAOBgNVBAsTB01hbmFn ZWQxGzAZBgNVBAsTElN0YW5kYXJkLVRlY2huaWNhbDEbMBkGA1UEAxMSV2VzbGV5IEUgR2Vvcmdl IElWMSkwJwYJKoZIhvcNAQkBFhpXZXNsZXkuRS5HZW9yZ2VAc3ByaW50LmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEArxfUh9TugEcsXY4OefFQTrGuaTRenLcZg0KCxZlTY7P9wMRCYd8p GJljwH1x4qn0Ejjyz+uX5UL8Biia13BSWRgiq7QYLKTZNKwEpBbeOf9lK/LrPsbFOgat/Zh/lPmx YzxeikU42X3KhyVSCmWdQhmWRu5kfUzsejaGWH9AyuUCAwEAAaOCA2EwggNdMAsGA1UdDwQEAwIF oDA2BgkqhkiG9w0BCQ8EKTAnMA0GCCqGSIb3DQMCAgE4MA0GCCqGSIb3DQMEAgE4MAcGBSsOAwIH MB0GA1UdDgQWBBTFSbrzJuajBSX9B63Y9r2TlgbU5DA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3 FQiBkugshNficv2LB4Xs/liCno8icYbjvkqEsfZAAgFkAgECMB8GA1UdIwQYMBaAFAGPJVAshjSb wX6QH9mINbU/rwuJMIIBXgYDVR0fBIIBVTCCAVEwggFNoIIBSaCCAUWGgeNsZGFwOi8vL0NOPVNw cmludCUyME5leHRlbCUyMEVudGVycHJpc2UlMjBJc3N1aW5nJTIwMSUyMEF1dGhvcml0eSxDTj1Q UEtJV0MwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1hZCxEQz1zcHJpbnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlv bkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYraHR0cDovL2NybC5z cHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNybIYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdDMDEvUFBLSVdDMDEuY3JsMIGFBggrBgEFBQcBAQR5MHcwNwYIKwYBBQUHMAKGK2h0 dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwPAYIKwYBBQUHMAKGMGh0 dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNydDApBgNVHSUEIjAg BggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AX DBV3ZWcwMjIxQGFkLnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQBYdUj2FTmOVS0X2fF+OYWXu9QoS6JWB8exD8kBPWVh28UilosoFwpVs2Ux K+V9NE1SC4QXDfwcjyMMV6WfXfy1foT6YAOcLt1z91ALCbTPlr1mazbAnOL6AzoTnq5V+TjvJvdN IYROS6PJC/YU5+w/NannnhC1zNFOtmxZZcrz50uRU8Q4mgITpxcnJXKUtKNaFTEhhtnP+hMVXYW0 eUyG7xjDTCyqsO5jcyI0IKJkNW1NXaKjHfmlAAiL5HVNl7cYL5uce6orHQQPMTSGRmTKCNjx7Yaz EHAorZUGmCTuihdhPDq+tOhGrIDE4XuiDxj+OVU6JXM5nsiKTjU968o4MYIDLTCCAykCAQEwgYYw eDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT 8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1 dGhvcml0eQIKPBVXiQAAAAGSDzAJBgUrDgMCGgUAoIIB/DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTAxMTAxNTQ5MzNaMCMGCSqGSIb3DQEJBDEWBBTfLywac5aA tFdEuI3PHZBSrlqyUjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG 9w0CBTCBlwYJKwYBBAGCNxAEMYGJMIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wgZkGCyqGSIb3DQEJ EAILMYGJoIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJpbnQx EjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNlIElz c3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wDQYJKoZIhvcNAQEBBQAEgYAporoOQFLGC/dW 16DgJmB9tRMSA8Bnog4TJnMnRfcuJElj5fSas0oLrq1Y9xtZbZsiGqOQJhnY+1O2U/IyjoKRKgT1 y6lup1rbzIn0L4xH9AzJH8qE9XymyojS2vAOYDEpksWq29fH821rgnwdzetXqa6++iLa2vJzsYaJ XzksAQAAAAAAAA== ------=_NextPart_000_004F_01CBB0B4.10AFF540-- From Wesley.E.George@sprint.com Mon Jan 10 08:27:34 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E38B3A6803 for ; Mon, 10 Jan 2011 08:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.334 X-Spam-Level: X-Spam-Status: No, score=-6.334 tagged_above=-999 required=5 tests=[AWL=2.265, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFjaIgsOfocF for ; Mon, 10 Jan 2011 08:27:31 -0800 (PST) Received: from TX2EHSOBE002.bigfish.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by core3.amsl.com (Postfix) with ESMTP id 42CFF3A67ED for ; Mon, 10 Jan 2011 08:27:31 -0800 (PST) Received: from mail147-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.8; Mon, 10 Jan 2011 16:29:45 +0000 Received: from mail147-tx2 (localhost.localdomain [127.0.0.1]) by mail147-tx2-R.bigfish.com (Postfix) with ESMTP id BD3E518D888F; Mon, 10 Jan 2011 16:29:44 +0000 (UTC) X-SpamScore: -28 X-BigFish: VS-28(zz9371Pzz1202hzz8275dh1033ILz2fh2a8h668h34h62h) X-Spam-TCS-SCL: 1:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:plsasdm2.corp.sprint.com; RD:smtpls2.sprint.com; EFVD:NLI Received: from mail147-tx2 (localhost.localdomain [127.0.0.1]) by mail147-tx2 (MessageSwitch) id 1294676984415888_24710; Mon, 10 Jan 2011 16:29:44 +0000 (UTC) Received: from TX2EHSMHS040.bigfish.com (unknown [10.9.14.241]) by mail147-tx2.bigfish.com (Postfix) with ESMTP id 549B1158055; Mon, 10 Jan 2011 16:29:44 +0000 (UTC) Received: from plsasdm2.corp.sprint.com (144.230.168.26) by TX2EHSMHS040.bigfish.com (10.9.99.140) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 10 Jan 2011 16:29:42 +0000 Received: from PDAWEH03.ad.sprint.com (PDAWEH03.corp.sprint.com [144.226.110.91]) by plsasdm2.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p0AGTcCq010554 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Jan 2011 10:29:39 -0600 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PDAWEH03.ad.sprint.com ([fe80::ad53:3472:c852:cd45%11]) with mapi id 14.01.0255.000; Mon, 10 Jan 2011 10:29:38 -0600 From: "George, Wes E [NTK]" To: Ed Jankiewicz , "int-area@ietf.org" , IPv6 Operations Thread-Topic: draft-george-ipv6-required Thread-Index: AQHLrqerYk4QAUe6mEeJTO3wutdLi5PKX+QA Date: Mon, 10 Jan 2011 16:29:36 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E04B941@PLSWM12A.ad.sprint.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> In-Reply-To: <4D277357.2050109@sri.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.27] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_005C_01CBB0B9.A8183C30" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Subject: [Int-area] draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 16:27:34 -0000 ------=_NextPart_000_005C_01CBB0B9.A8183C30 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Shortened the subject line a bit From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On Behalf Of Ed Jankiewicz Sent: Friday, January 07, 2011 3:11 PM To: int-area@ietf.org; IPv6 Operations Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required >I agree so strenuously that I half-jokiningly would like to be listed as a >coauthor, and I bet there are a >number of other folks on these lists that >would feel the same way. Perhaps a better suggestion would be to >include an >appendix with the name and affiliation of everyone who is willing to sign-on >to ratify this >recommendation. [WES] If I'm interpreting this right, this would sort of be like a petition with lots of signatures, or one of those open letters to the $government_functionary signed by lots of "important people" you see published in full-page newspaper ads? I assume that this is generally a way of more concretely documenting support for this proposal beyond the IETF's standard rough consensus in a WG meeting or on-list. I'm open to this, but is there any precedent for it? Do we want to set a precedent that if we *really* mean something, we take steps to more thoroughly document that support within a draft? Those in support can already have their support immortalized in the pages of the email list archives complete with their choice of editorialization... And regarding affiliation - IETF typically shies away from making a big deal of affiliation, since most of its members are not really authorized to represent the company that pays the bills in any official public capacity. Yes, they are representatives of that company, but they are mostly speaking for themselves with the interests of their company informing those comments - it's not like there's a way to get every email and comment at the mic approved by PR first :-) An IAB statement of support would perhaps be a good way to add weight to this recommendation, but I'm content to start with statements of support for WG adoption and advancement to RFC status and see where it goes from there. Wes George ------=_NextPart_000_005C_01CBB0B9.A8183C30 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXHjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggarMIIFk6ADAgECAgo8 FVeJAAAAAZIPMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMDgwNTAxMTczNzE0WhcNMTEwNTAx MTczNzE0WjCBzzETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxEDAOBgNVBAsTB01hbmFn ZWQxGzAZBgNVBAsTElN0YW5kYXJkLVRlY2huaWNhbDEbMBkGA1UEAxMSV2VzbGV5IEUgR2Vvcmdl IElWMSkwJwYJKoZIhvcNAQkBFhpXZXNsZXkuRS5HZW9yZ2VAc3ByaW50LmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEArxfUh9TugEcsXY4OefFQTrGuaTRenLcZg0KCxZlTY7P9wMRCYd8p GJljwH1x4qn0Ejjyz+uX5UL8Biia13BSWRgiq7QYLKTZNKwEpBbeOf9lK/LrPsbFOgat/Zh/lPmx YzxeikU42X3KhyVSCmWdQhmWRu5kfUzsejaGWH9AyuUCAwEAAaOCA2EwggNdMAsGA1UdDwQEAwIF oDA2BgkqhkiG9w0BCQ8EKTAnMA0GCCqGSIb3DQMCAgE4MA0GCCqGSIb3DQMEAgE4MAcGBSsOAwIH MB0GA1UdDgQWBBTFSbrzJuajBSX9B63Y9r2TlgbU5DA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3 FQiBkugshNficv2LB4Xs/liCno8icYbjvkqEsfZAAgFkAgECMB8GA1UdIwQYMBaAFAGPJVAshjSb wX6QH9mINbU/rwuJMIIBXgYDVR0fBIIBVTCCAVEwggFNoIIBSaCCAUWGgeNsZGFwOi8vL0NOPVNw cmludCUyME5leHRlbCUyMEVudGVycHJpc2UlMjBJc3N1aW5nJTIwMSUyMEF1dGhvcml0eSxDTj1Q UEtJV0MwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1hZCxEQz1zcHJpbnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlv bkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYraHR0cDovL2NybC5z cHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNybIYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdDMDEvUFBLSVdDMDEuY3JsMIGFBggrBgEFBQcBAQR5MHcwNwYIKwYBBQUHMAKGK2h0 dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwPAYIKwYBBQUHMAKGMGh0 dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNydDApBgNVHSUEIjAg BggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AX DBV3ZWcwMjIxQGFkLnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQBYdUj2FTmOVS0X2fF+OYWXu9QoS6JWB8exD8kBPWVh28UilosoFwpVs2Ux K+V9NE1SC4QXDfwcjyMMV6WfXfy1foT6YAOcLt1z91ALCbTPlr1mazbAnOL6AzoTnq5V+TjvJvdN IYROS6PJC/YU5+w/NannnhC1zNFOtmxZZcrz50uRU8Q4mgITpxcnJXKUtKNaFTEhhtnP+hMVXYW0 eUyG7xjDTCyqsO5jcyI0IKJkNW1NXaKjHfmlAAiL5HVNl7cYL5uce6orHQQPMTSGRmTKCNjx7Yaz EHAorZUGmCTuihdhPDq+tOhGrIDE4XuiDxj+OVU6JXM5nsiKTjU968o4MYIDLTCCAykCAQEwgYYw eDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT 8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1 dGhvcml0eQIKPBVXiQAAAAGSDzAJBgUrDgMCGgUAoIIB/DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTAxMTAxNjI5MzRaMCMGCSqGSIb3DQEJBDEWBBSLiCARcl7H UI06zltAlaewk0Ci7TBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG 9w0CBTCBlwYJKwYBBAGCNxAEMYGJMIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wgZkGCyqGSIb3DQEJ EAILMYGJoIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJpbnQx EjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNlIElz c3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wDQYJKoZIhvcNAQEBBQAEgYBqsCRHnTJWUQOE /3pSzfTOq45ixViZHftL+j51mvCmoUCWAO+VFEBIulj4SgZI6IzMgmntnQh0cTSwu4oDDafFSu1f Q+RvEQqhSIlxbV/AGsbOhapbaMrksOQkNoIXz+UMv1oGrD6ONrsZK6RFQ1S0riAHfKJxMYfX02dh +7+kFwAAAAAAAA== ------=_NextPart_000_005C_01CBB0B9.A8183C30-- From fernando.gont.netbook.win@gmail.com Mon Jan 10 08:49:59 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E6823A6B07; Mon, 10 Jan 2011 08:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zz5Wvs-u7-Z6; Mon, 10 Jan 2011 08:49:58 -0800 (PST) Received: from mail-yx0-f194.google.com (mail-yx0-f194.google.com [209.85.213.194]) by core3.amsl.com (Postfix) with ESMTP id 2BFC43A67FA; Mon, 10 Jan 2011 08:49:58 -0800 (PST) Received: by yxd5 with SMTP id 5so4314720yxd.1 for ; Mon, 10 Jan 2011 08:52:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=UqpVGxSF20tFrAa65IWWKUFo1iAJCo3YfxdGdCaT41Q=; b=CK3Kex7pL2+wg89UFh/ifaRQ253r0VjWTSONEMxN2AoTtMSBNgwJhuMztGot9Vl830 lxRqdHztdTk30sBwZOOAaXwBe7orOFwA7zz2pl5ZQvPXejvDYNdsZavnQnFZhSaswQgv xO0cEMabVgQy8XaRmZHPUbz23FXytRQ4g3R+Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=BqDHgr0nmEPiMkLDu+KCpeSheBABiEeO6jrvAtYKu+fJb8mZBwZhXiF5COtX7T12kv B48oF9L+tmE3UcCrU/CAUU3GFUSBwz05zKkGen0BJjXJfZeVrgGnNGbBd4lCiMiu6kTH tcuN6LMTUAUOamWEMf2zx13TnYbmnUA1AZiUI= Received: by 10.151.45.21 with SMTP id x21mr27942374ybj.429.1294678331789; Mon, 10 Jan 2011 08:52:11 -0800 (PST) Received: from [192.168.2.4] (138-83-231-201.fibertel.com.ar [201.231.83.138]) by mx.google.com with ESMTPS id r6sm2258719yba.23.2011.01.10.08.51.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 08:52:10 -0800 (PST) Sender: Fernando Gont Message-ID: <4D2B3928.8050508@gont.com.ar> Date: Mon, 10 Jan 2011 13:51:52 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> In-Reply-To: <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Internet Area , IPv6 Operations Subject: Re: [Int-area] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 16:49:59 -0000 Hi, Remi, On 10/01/2011 05:30 a.m., Rémi Després wrote: >> End-to-end transparency in the sense that every node will be >> reachable from every node? > > The e2e transparency that IPv4 had lost, and IPv6 restores, is > ADDRESS transparency: source and destination addresses seen by a > destination are the same as those set by the source. IPv6 restores this to the extent that NAT66 is not deployed. My take is that NAT66 *will* be deployed. -- So, I don't think you can rely IPv6 on restoring "address transparency". > - This is needed > in particular for Header Authentication of IPsec. But you can still use UDP encapsulation. > - Also, it permits > a host to advertise its source address in the DNS and in referrals. Firstly, using network addresses in the application layer is generally a bad idea, and one would hope that we have already learnt that lesson. Secondly, for the an address published in the DNS to be useful, it needs to be reachable (that's why you advertise the address in the DNS after all, right?). And for it to be reachable, the stateful firewall tht's in fron of the host (or within the host), needs to have state for that "incoming connection". -- In general, there won't be such state, *or* the firewall would need to be smart enough to understand the application protocol to create such state before it's needed (so, again, forget about the "dumb network"). Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@isi.edu Mon Jan 10 09:45:29 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E197C28C101; Mon, 10 Jan 2011 09:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BU9YGFsxRurK; Mon, 10 Jan 2011 09:45:29 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id E4A9028C0FF; Mon, 10 Jan 2011 09:45:28 -0800 (PST) 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 p0AHl47n026672 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 10 Jan 2011 09:47:05 -0800 (PST) Message-ID: <4D2B4618.6050703@isi.edu> Date: Mon, 10 Jan 2011 09:47:04 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mark Smith References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> <4D279717.1050602@isi.edu> <20110109103956.383b2284@opy.nosense.org> In-Reply-To: <20110109103956.383b2284@opy.nosense.org> 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: IPv6 Operations , int-area@ietf.org Subject: Re: [Int-area] [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 17:45:30 -0000 On 1/8/2011 4:09 PM, Mark Smith wrote: ... > It sounds like you're adopting the "Law of the instrument" regarding > NAT - > > "It is tempting, if the only tool you have is a hammer, to treat > everything as if it were a nail." Maslow's law is not the motivation. I'm simply making a few observations: 1) anything a device supports for IPv4 that it cannot support for IPv6 will be taken as an excuse not to migrate to IPv6 2) it's better to remove that hurdle than to debate every capability. 3) NATs are useful even where addresses are plentiful Joe From behcetsarikaya@yahoo.com Mon Jan 10 10:03:40 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BC393A69CC for ; Mon, 10 Jan 2011 10:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+2SRM162D0z for ; Mon, 10 Jan 2011 10:03:39 -0800 (PST) Received: from nm22-vm0.bullet.mail.sp2.yahoo.com (nm22-vm0.bullet.mail.sp2.yahoo.com [98.139.91.222]) by core3.amsl.com (Postfix) with SMTP id B45973A684C for ; Mon, 10 Jan 2011 10:03:38 -0800 (PST) Received: from [98.139.91.65] by nm22.bullet.mail.sp2.yahoo.com with NNFMP; 10 Jan 2011 18:05:51 -0000 Received: from [98.139.91.54] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 10 Jan 2011 18:05:51 -0000 Received: from [127.0.0.1] by omp1054.mail.sp2.yahoo.com with NNFMP; 10 Jan 2011 18:05:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 666182.5997.bm@omp1054.mail.sp2.yahoo.com Received: (qmail 56530 invoked by uid 60001); 10 Jan 2011 18:05:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1294682751; bh=BMPb4pV4hPB9TlWDx3KAtYkxVx6xcKzHJdd/PUxi6BI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=e7VYz4yrfJRX8wVXq4Z5yGTHf5EcQfHeXb0YplNEWTWuJ3TrPv6pP6O1XxhdvBVGKWes9xh4NYPC02XsyoGDEjUUlWubKgWd9BIwJ1y2z6AEJrO8yjZH23wsv4hyIiZQyoWDzLDIRBhSxbVUT0wLyl8qiU/LRPcU1ZD7xm/B+Xs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=hgsHw/g8RLww/tKSISvtHpYKL+5126Tn2W6VmAQzOyXD26mbiXPQFjxh64bL4G1Vrfw+DMV+PDFg6NdZI2rLyI98lKPkGWCIcy7SrhFbfP6IRf7PeEibtQ+Y7mUBI1zbminr128WhWhqlbxjdPVZhCgg+XM8ALZnm2mnKS3dL8s=; Message-ID: <201912.52088.qm@web111414.mail.gq1.yahoo.com> X-YMail-OSG: E.iFFEsVM1l6CF01.MS7l4zDLZfyngOkmn375GvVh4XquVt A_84ugOO88WMK4rAa8tnVKnQQbj1OtOsfCrwNr_oOndkpDokUtfkcvhTbyQ3 MXNAPm73QvC0gFdvvq2JNAMVTgfihMSlyHKMP3_Nx3pT3JRBKJiOv9.1oK.n fexEb9QWO8IPNoPZXDatAAPQloVI.mf2NI2Dtigv06hFw2R053XOSOtuDrsy C3VDBl.9Mg_NxAemQjl9DVI63Jv1yUMBNWCH.BcYtfWjiu0eZtq2nH12cHqr vqFvhxGACie4wfh4jvuXWCuPlT7O0fTH4J6D.T915wz2q2nmmJ7z0lxugRyc rxk6gwSCE6oObRpzRL9vvEhtAlEAXEBRBvw1jy9RyoThrAmWjj0h8hNwy1xb X.OFUeFJmHP8T Received: from [206.16.17.212] by web111414.mail.gq1.yahoo.com via HTTP; Mon, 10 Jan 2011 10:05:51 PST X-Mailer: YahooMailRC/553 YahooMailWebService/0.8.107.285259 References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> Date: Mon, 10 Jan 2011 10:05:51 -0800 (PST) From: Behcet Sarikaya To: Fernando Gont , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4D2B3928.8050508@gont.com.ar> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , Internet Area Subject: Re: [Int-area] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 18:03:40 -0000 =0A=0A> Hi, Remi,=0A> =0A> On 10/01/2011 05:30 a.m., R=E9mi Despr=E9s wrote= :=0A> =0A> >> End-to-end transparency in the sense that every node will be= =0A> >> reachable from every node?=0A> > =0A> > The e2e transparency that = IPv4 had lost, and IPv6 restores, is=0A> > ADDRESS transparency: source an= d destination addresses seen by a=0A> > destination are the same as those = set by the source. =0A> =0A> IPv6 restores this to the extent that NAT66 is= not deployed. My take is=0A> that NAT66 *will* be deployed. -- So, I don'= t think you can rely IPv6 on=0A> restoring "address transparency".=0A=0A+1= .=0A=0AWe can only reply on public IPv4 address depletion. Period.=0A=0A> = =0A> =0A> > - This is needed=0A> > in particular for Header Authentication= of IPsec. =0A> =0A> But you can still use UDP encapsulation.=0A> =0A> =0A= > =0A> > - Also, it permits=0A> > a host to advertise its source address i= n the DNS and in referrals.=0A> =0A> Firstly, using network addresses in t= he application layer is generally a=0A> bad idea, and one would hope that = we have already learnt that lesson.=0A> =0A> Secondly, for the an address = published in the DNS to be useful, it needs=0A> to be reachable (that's wh= y you advertise the address in the DNS after=0A> all, right?). And for it t= o be reachable, the stateful firewall tht's in=0A> fron of the host (or wi= thin the host), needs to have state for that=0A> "incoming connection". --= In general, there won't be such state, *or*=0A> the firewall would need t= o be smart enough to understand the application=0A> protocol to create suc= h state before it's needed (so, again, forget=0A> about the "dumb network"= ).=0A> =0A> Thanks,=0A> -- =0A> Fernando Gont=0A> e-mail: fernando@gont.com= .ar || fgont@acm.org=0A> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96= EE A9EF D076 FFF1=0A> =0A> =0A> =0A> =0A> ________________________________= _______________=0A> Int-area mailing list=0A> Int-area@ietf.org=0A> https:= //www.ietf.org/mailman/listinfo/int-area=0A> =0A=0A=0A From edward.jankiewicz@sri.com Mon Jan 10 10:34:10 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B499F3A6A67; Mon, 10 Jan 2011 10:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.957 X-Spam-Level: X-Spam-Status: No, score=-1.957 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_27=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZYmbcV8kA8X; Mon, 10 Jan 2011 10:34:09 -0800 (PST) Received: from mail1.sri.com (srimail.SRI.COM [128.18.30.17]) by core3.amsl.com (Postfix) with ESMTP id C62E13A69CC; Mon, 10 Jan 2011 10:34:09 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [192.168.1.144] ([unknown] [68.81.23.64]) by mail.sri.com (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LET007NUL0LQJ80@mail.sri.com>; Mon, 10 Jan 2011 10:36:22 -0800 (PST) Message-id: <4D2B51A8.3050405@sri.com> Date: Mon, 10 Jan 2011 13:36:24 -0500 From: Ed Jankiewicz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 To: "George, Wes E [NTK]" References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <54E900DC635DAB4DB7A6D799B3C4CD8E04B941@PLSWM12A.ad.sprint.com> In-reply-to: <54E900DC635DAB4DB7A6D799B3C4CD8E04B941@PLSWM12A.ad.sprint.com> Cc: IPv6 Ops WG , "int-area@ietf.org" Subject: Re: [Int-area] draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 18:34:10 -0000 upon reflection, I agree that it would be unnecessary and inappropriate to generate a petition within IETF. The process is built on consensus, not name-checking. Suffice it to say I support this work being discussed within Intarea and v6ops, including time on the agenda in Prague, and eventual adoption as a WG or IAB publication. I also agree with a previous comment that this draft should be kept very simple with a small number of essential references, e.g. to the IPv6 Node Requirements (as revised). That is the current best definition of what is "required" for IPv6. If it is insufficient as is, and needs to be replaced by a standards track definition, that would take some effort, and that can be discussed as well. I would prefer that we publish the current RFC 4294 update draft before we open that can of worms. The question of parity is very complex and difficult to define. The concerns that some things are not directly comparable, or that there are things that have become accepted in IPv4 that some don't want to replicate in IPv6, versus the sense that the lack of any feature (standard or not) will be a disincentive to IPv6 adoption - it's not clear how these can be reconciled. On 1/10/2011 11:29 AM, George, Wes E [NTK] wrote: > Shortened the subject line a bit > > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On Behalf > Of Ed Jankiewicz > Sent: Friday, January 07, 2011 3:11 PM > To: int-area@ietf.org; IPv6 Operations > Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new > draft-george-ipv6-required > >> I agree so strenuously that I half-jokiningly would like to be listed as a >> coauthor, and I bet there are a>number of other folks on these lists that >> would feel the same way. Perhaps a better suggestion would be to>include an >> appendix with the name and affiliation of everyone who is willing to sign-on >> to ratify this>recommendation. > [WES] If I'm interpreting this right, this would sort of be like a petition > with lots of signatures, or one of those open letters to the > $government_functionary signed by lots of "important people" you see published > in full-page newspaper ads? I assume that this is generally a way of more > concretely documenting support for this proposal beyond the IETF's standard > rough consensus in a WG meeting or on-list. > I'm open to this, but is there any precedent for it? Do we want to set a > precedent that if we *really* mean something, we take steps to more thoroughly > document that support within a draft? Those in support can already have their > support immortalized in the pages of the email list archives complete with > their choice of editorialization... > And regarding affiliation - IETF typically shies away from making a big deal > of affiliation, since most of its members are not really authorized to > represent the company that pays the bills in any official public capacity. > Yes, they are representatives of that company, but they are mostly speaking > for themselves with the interests of their company informing those comments - > it's not like there's a way to get every email and comment at the mic approved > by PR first :-) > > An IAB statement of support would perhaps be a good way to add weight to this > recommendation, but I'm content to start with statements of support for WG > adoption and advancement to RFC status and see where it goes from there. > > Wes George -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or ed.jankiewicz@sri.com From rajiva@cisco.com Mon Jan 10 10:46:32 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20D343A69C5; Mon, 10 Jan 2011 10:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.309 X-Spam-Level: X-Spam-Status: No, score=-10.309 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYxDmtaDZsGT; Mon, 10 Jan 2011 10:46:31 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id EDF523A6B04; Mon, 10 Jan 2011 10:46:30 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEDjKk2tJV2Z/2dsb2JhbACkR3OjC5guhUwEhGeJSYgL Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-2.cisco.com with ESMTP; 10 Jan 2011 18:48:44 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p0AImi3W031186; Mon, 10 Jan 2011 18:48:44 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Jan 2011 12:48:44 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Jan 2011 12:48:40 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C03D205F0@XMB-RCD-111.cisco.com> In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E502DF203B@XMB-AMS-101.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] [Int-area] IP-capable nodes must support IPv6 -newdraft-george-ipv6-required Thread-Index: Acuuvn4iydAPseQ4RmSPGhg/38uBdQAAmU8gAHwiuuAAEVzPoA== References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com><4D277357.2050109@sri.com><4D277EA5.9080304@isi.edu><4D278833.8090208@matthew.at><4D2789AF.1050903@isi.edu><4D278AE7.4080502@matthew.at><4D278B93.8050903@isi.edu><4D279773.30102@isi.edu><067E6CE33034954AAC05C9EC85E2577C03D201B9@XMB-RCD-111.cisco.com><4D279A91.2040300@isi.edu> <067E6CE33034954AAC05C9EC85E2577C03D201D0@XMB-RCD-111.cisco.com> <4269EA985EACD24987D82DAE2FEC62E502DF203B@XMB-AMS-101.cisco.com> From: "Rajiv Asati (rajiva)" To: "Gunter Van de Velde (gvandeve)" , "Joe Touch" X-OriginalArrivalTime: 10 Jan 2011 18:48:44.0467 (UTC) FILETIME=[01DA1030:01CBB0F7] Cc: IPv6 Operations , int-area@ietf.org Subject: Re: [Int-area] [v6ops] IP-capable nodes must support IPv6 -newdraft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 18:46:32 -0000 Hi Gunter, Good question. Are you intending to suggest that this draft should consider the IPv6 vs. Ipv4 service experience while making the recommendation? Cheers, Rajiv > -----Original Message----- > From: Gunter Van de Velde (gvandeve) > Sent: Monday, January 10, 2011 5:34 AM > To: Rajiv Asati (rajiva); Joe Touch > Cc: int-area@ietf.org; IPv6 Operations > Subject: RE: [v6ops] [Int-area] IP-capable nodes must support IPv6 - > newdraft-george-ipv6-required >=20 > <>start snip<> > > the point that "if IPv4 is supported better, in any way, than IPv6, > on > > a device, then there is incentive to not use IPv6". > This broader issue in conjunction with all that exists on an IPv4 > gateway may not be needed on an IPv6 gateway, warrants the set of MUST > and SHOULD/MAY IPv6 features. That was the intent of my suggestion. > <>end snip<> >=20 > I am interested to understand 'how' you want to quantify the IPv6 vs > IPv4 service experience. >=20 > G/ >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Rajiv Asati (rajiva) > Sent: zaterdag 8 januari 2011 0:19 > To: Joe Touch > Cc: int-area@ietf.org; IPv6 Operations > Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 - > newdraft-george-ipv6-required >=20 > Joe, >=20 > > Yes, there ought to be a list of IPv6 requirements, ala RFCs 1122, > > 1123, and 1812 (and their supplementary RFCs). >=20 > Ditto. I am sure that we could come up with few more. >=20 > > But there's a broader issue - > > the point that "if IPv4 is supported better, in any way, than IPv6, > on > > a device, then there is incentive to not use IPv6". >=20 > This broader issue in conjunction with all that exists on an IPv4 > gateway may not be needed on an IPv6 gateway, warrants the set of MUST > and SHOULD/MAY IPv6 features. That was the intent of my suggestion. >=20 > Cheers, > Rajiv From lee@asgard.org Mon Jan 10 10:46:42 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2959828C0F4 for ; Mon, 10 Jan 2011 10:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkdltPgQ5EA2 for ; Mon, 10 Jan 2011 10:46:41 -0800 (PST) Received: from omr4.networksolutionsemail.com (omr4.networksolutionsemail.com [205.178.146.54]) by core3.amsl.com (Postfix) with ESMTP id 8CB4D28C0E4 for ; Mon, 10 Jan 2011 10:46:39 -0800 (PST) Received: from cm-omr2 (mail.networksolutionsemail.com [205.178.146.50]) by omr4.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p0AImqnD007346 for ; Mon, 10 Jan 2011 13:48:53 -0500 Authentication-Results: cm-omr2 smtp.user=lee@asgard.org; auth=pass (LOGIN) X-Authenticated-UID: lee@asgard.org Received: from [204.235.115.167] ([204.235.115.167:51707] helo=HDC00027112) by cm-omr2 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 1E/F7-06971-4945B2D4; Mon, 10 Jan 2011 13:48:52 -0500 From: "Lee Howard" To: "'Joe Touch'" , "'Mark Smith'" References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> <4D279717.1050602@isi.edu> <20110109103956.383b2284@opy.nosense.org> <4D2B4618.6050703@isi.edu> In-Reply-To: <4D2B4618.6050703@isi.edu> Date: Mon, 10 Jan 2011 13:48:47 -0500 Message-ID: <001101cbb0f7$06cc8af0$1465a0d0$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acuw7roI0HzxOeq1R2GrYHnU5guCwAABVUCg Content-Language: en-us Cc: 'IPv6 Operations' , int-area@ietf.org Subject: Re: [Int-area] [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 18:46:42 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Joe Touch > I'm simply making a few observations: > > 1) anything a device supports for IPv4 that it cannot support for IPv6 > will be taken as an excuse not to migrate to IPv6 > 2) it's better to remove that hurdle than to debate every capability. > 3) NATs are useful even where addresses are plentiful This sounds like a WG chartering debate, rather than a debate about whether all IP-capable devices SHOULD support IPv6. It sounds like your support for draft-george-ipv6-required is dependent on rechartering BEHAVE, defining NAT66, and updating draft-ietf-v6ops-cpe-router to require NAT66. In other words, you will not support the statement, "IPv6 is required in IP-capable devices" until that statement specifically includes feature parity, and explicitly includes NAT66. Is that right? Lee From rajiva@cisco.com Mon Jan 10 10:51:22 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C57083A6B0D; Mon, 10 Jan 2011 10:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.345 X-Spam-Level: X-Spam-Status: No, score=-10.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Un+86P5Ikdn; Mon, 10 Jan 2011 10:51:21 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 30D983A6B08; Mon, 10 Jan 2011 10:51:21 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFzkKk2tJXG9/2dsb2JhbACkR3OjDZgugnSCWASEZ4lJiAs Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rtp-iport-2.cisco.com with ESMTP; 10 Jan 2011 18:53:35 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p0AIrYLq022982; Mon, 10 Jan 2011 18:53:34 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Jan 2011 12:53:34 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Jan 2011 12:53:33 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C03D205FD@XMB-RCD-111.cisco.com> In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E04B86A@PLSWM12A.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] IP-capable nodes must support IPv6 -newdraft-george-ipv6-required Thread-Index: AQHLrr3OZ1PupmJS+kufkXHyVXljfpPGg+GAgAAF3oCAA8NuYIAAQ14g References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com><4D277357.2050109@sri.com><4D277EA5.9080304@isi.edu><4D278833.8090208@matthew.at><4D2789AF.1050903@isi.edu><4D278AE7.4080502@matthew.at><4D278B93.8050903@isi.edu><4D279773.30102@isi.edu><067E6CE33034954AAC05C9EC85E2577C03D201B9@XMB-RCD-111.cisco.com><4D279A91.2040300@isi.edu> <067E6CE33034954AAC05C9EC85E2577C03D201D0@XMB-RCD-111.cisco.com> <54E900DC635DAB4DB7A6D799B3C4CD8E04B86A@PLSWM12A.ad.sprint.com> From: "Rajiv Asati (rajiva)" To: "George, Wes E [NTK]" , "Joe Touch" X-OriginalArrivalTime: 10 Jan 2011 18:53:34.0704 (UTC) FILETIME=[AED8B700:01CBB0F7] Cc: IPv6 Operations , int-area@ietf.org Subject: Re: [Int-area] IP-capable nodes must support IPv6 -newdraft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 18:51:22 -0000 Wes, > sooner we correct the lack of IPv6 support in devices and software, the > better off we are. +1 > That said, it may be helpful to write a draft comparing IPv4 and IPv6 > for=09 > feature parity to identify future work items for IETF and point to the > appropriate RFCs where equivalent features exist, but I view that as > complimentary to this draft, not part of it. That's reasonable as long as we add appropriate references. > I agree that the more specific information about what we mean by > "support > IPv6" should be made available, but as references, not text in the > draft itself. +1 > The draft also formally updates 1812 and 1122. I can add 1123 to that > list > of updated drafts if there is consensus that it should be added. > Brian Carpenter also recommended (offlist) that we might want to > consider > adding RFC4084 to the update list, specifically, moving "Version" from > section 4 (additional terminology) to section 2 (general terminology). > What are your thoughts on that? +1 > What else is missing as a reference? Keep in mind that the existing > referenced drafts and RFCs have multiple normative and informative > references of their own which we didn't see the need to duplicate here. Indeed. Cheers, Rajiv > -----Original Message----- > From: George, Wes E [NTK] [mailto:Wesley.E.George@sprint.com] > Sent: Monday, January 10, 2011 10:50 AM > To: Rajiv Asati (rajiva); Joe Touch > Cc: int-area@ietf.org; IPv6 Operations > Subject: RE: [Int-area] IP-capable nodes must support IPv6 -newdraft- > george-ipv6-required >=20 > > -----Original Message----- > > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On > > Behalf Of Rajiv Asati (rajiva) > > Sent: Friday, January 07, 2011 6:19 PM > > Subject: Re: [Int-area] IP-capable nodes must support IPv6 - > newdraft- > > george-ipv6-required > > > > > Yes, there ought to be a list of IPv6 requirements, ala RFCs 1122, > > > 1123, and 1812 (and their supplementary RFCs). > > > > Ditto. I am sure that we could come up with few more. > > > [WES] I think that those lists already exist for IPv6, but not always > in > exactly the same form as the IPv4 specs you reference above. I assume > that > the IPv6 specifications aren't listed as updates to the above IPv4 RFCs > because IPv6 was considered optional, not a direct replacement for > IPv4. I > wasn't about to go so far as to deprecate the appropriate IPv4 spec in > favor > of the IPv6 one... baby steps :-) > Either way, this draft is meant to be a generic update informing those > who > are considering putting an IP stack on their device, whether dumb or > smart, > simple or complex, that they need to stop considering IPv6 optional. We > intentionally kept it generic so that it could be adopted more quickly > - the > sooner we correct the lack of IPv6 support in devices and software, the > better off we are. >=20 > That said, it may be helpful to write a draft comparing IPv4 and IPv6 > for=09 > feature parity to identify future work items for IETF and point to the > appropriate RFCs where equivalent features exist, but I view that as > complimentary to this draft, not part of it. >=20 > I agree that the more specific information about what we mean by > "support > IPv6" should be made available, but as references, not text in the > draft > itself. > The draft already references ietf-v6ops-ipv6-cpe-router, and RFC 4294, > which > I've been informed will soon be replaced by a BIS version (currently > draft-ietf-6man-node-req-bis). I will update that reference in the next > version of the draft. > The draft also formally updates 1812 and 1122. I can add 1123 to that > list > of updated drafts if there is consensus that it should be added. > Brian Carpenter also recommended (offlist) that we might want to > consider > adding RFC4084 to the update list, specifically, moving "Version" from > section 4 (additional terminology) to section 2 (general terminology). > What > are your thoughts on that? >=20 > What else is missing as a reference? Keep in mind that the existing > referenced drafts and RFCs have multiple normative and informative > references of their own which we didn't see the need to duplicate here. >=20 > Thanks for the support thus far. >=20 > Wes George From touch@isi.edu Mon Jan 10 11:01:21 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 612B828C0CE; Mon, 10 Jan 2011 11:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKItpUcaTj32; Mon, 10 Jan 2011 11:01:20 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 6E1723A6B0E; Mon, 10 Jan 2011 11:01:20 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p0AJ2rd1020377 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 10 Jan 2011 11:02:53 -0800 (PST) Message-ID: <4D2B57DD.5030908@isi.edu> Date: Mon, 10 Jan 2011 11:02:53 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Lee Howard References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> <4D279717.1050602@isi.edu> <20110109103956.383b2284@opy.nosense.org> <4D2B4618.6050703@isi.edu> <001101cbb0f7$06cc8af0$1465a0d0$@org> In-Reply-To: <001101cbb0f7$06cc8af0$1465a0d0$@org> 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: 'Mark Smith' , 'IPv6 Operations' , int-area@ietf.org Subject: Re: [Int-area] [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 19:01:21 -0000 On 1/10/2011 10:48 AM, Lee Howard wrote: >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Joe Touch >> I'm simply making a few observations: >> >> 1) anything a device supports for IPv4 that it cannot support for IPv6 >> will be taken as an excuse not to migrate to IPv6 >> 2) it's better to remove that hurdle than to debate every capability. >> 3) NATs are useful even where addresses are plentiful > > This sounds like a WG chartering debate, rather than a debate about whether > all IP-capable devices SHOULD support IPv6. > It sounds like your support for draft-george-ipv6-required is dependent on > rechartering BEHAVE, defining NAT66, and updating > draft-ietf-v6ops-cpe-router > to require NAT66. In other words, you will not support the statement, "IPv6 > > is required in IP-capable devices" until that statement specifically > includes > feature parity, and explicitly includes NAT66. > Is that right? I support the idea that new devices should be IPv6 capable. I recognize the irrelevance of such an assertion. IMO, if we can't assert that "new devices need to support IPv6 as much as they support IPv4", there's simply no point. We'll be where we are now. Many organizations won't buy a device without the IPV6 label, but since most such devices have services that won't run on v6, v6 isn't enabled. I.e., what's the point, unless we say "support IPv6 at least as well as IPv4"? Joe From ipng@69706e6720323030352d30312d31340a.nosense.org Mon Jan 10 12:41:29 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B97EA3A63C9; Mon, 10 Jan 2011 12:41:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.267 X-Spam-Level: X-Spam-Status: No, score=-1.267 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkhKobd-nyKK; Mon, 10 Jan 2011 12:41:29 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id A474B3A635F; Mon, 10 Jan 2011 12:41:28 -0800 (PST) Received: from 182-239-157-145.ip.adam.com.au ([182.239.157.145] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1PcOaP-0004Ik-KA; Tue, 11 Jan 2011 07:13:29 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 355A03B31E; Tue, 11 Jan 2011 07:13:29 +1030 (CST) Date: Tue, 11 Jan 2011 07:13:29 +1030 From: Mark Smith To: Fernando Gont Message-ID: <20110111071329.109df03f@opy.nosense.org> In-Reply-To: <4D2B3928.8050508@gont.com.ar> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= , IPv6 Operations , Internet Area Subject: Re: [Int-area] [v6ops] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 20:41:29 -0000 On Mon, 10 Jan 2011 13:51:52 -0300 Fernando Gont wrote: > Hi, Remi, >=20 > On 10/01/2011 05:30 a.m., R=C3=A9mi Despr=C3=A9s wrote: >=20 > >> End-to-end transparency in the sense that every node will be > >> reachable from every node? > >=20 > > The e2e transparency that IPv4 had lost, and IPv6 restores, is > > ADDRESS transparency: source and destination addresses seen by a > > destination are the same as those set by the source.=20 >=20 > IPv6 restores this to the extent that NAT66 is not deployed. My take is > that NAT66 *will* be deployed.=20 How do you know? What evidence do you have? >-- So, I don't think you can rely IPv6 on > restoring "address transparency". >=20 >=20 > > - This is needed > > in particular for Header Authentication of IPsec.=20 >=20 > But you can still use UDP encapsulation. >=20 UDP encapsulation of IPsec is a work around, specifically to get around the problems of lack of IPv4 address transparency i.e. NAT. It isn't an acceptable answer when NAT doesn't need to exist. >=20 >=20 > > - Also, it permits > > a host to advertise its source address in the DNS and in referrals. >=20 > Firstly, using network addresses in the application layer is generally a > bad idea, and one would hope that we have already learnt that lesson. >=20 > Secondly, for the an address published in the DNS to be useful, it needs > to be reachable (that's why you advertise the address in the DNS after > all, right?). And for it to be reachable, the stateful firewall tht's in > fron of the host (or within the host), needs to have state for that > "incoming connection". -- In general, there won't be such state, *or* > the firewall would need to be smart enough to understand the application > protocol to create such state before it's needed (so, again, forget > about the "dumb network"). >=20 > Thanks, > --=20 > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From lee@asgard.org Mon Jan 10 12:47:51 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0CCC3A6405 for ; Mon, 10 Jan 2011 12:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKYxmXqC+kDm for ; Mon, 10 Jan 2011 12:47:50 -0800 (PST) Received: from omr10.networksolutionsemail.com (omr10.networksolutionsemail.com [205.178.146.60]) by core3.amsl.com (Postfix) with ESMTP id 6F1FD3A659B for ; Mon, 10 Jan 2011 12:47:48 -0800 (PST) Received: from cm-omr2 (mail.networksolutionsemail.com [205.178.146.50]) by omr10.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p0AKo0lZ002726 for ; Mon, 10 Jan 2011 15:50:02 -0500 Authentication-Results: cm-omr2 smtp.user=lee@asgard.org; auth=pass (LOGIN) X-Authenticated-UID: lee@asgard.org Received: from [204.235.115.167] ([204.235.115.167:46150] helo=HDC00027112) by cm-omr2 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 23/95-06971-6F07B2D4; Mon, 10 Jan 2011 15:50:00 -0500 From: "Lee Howard" To: "'Joe Touch'" References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> <4D279717.1050602@isi.edu> <20110109103956.383b2284@opy.nosense.org> <4D2B4618.6050703@isi.edu> <001101cbb0f7$06cc8af0$1465a0d0$@org> <4D2B57DD.5030908@isi.edu> In-Reply-To: <4D2B57DD.5030908@isi.edu> Date: Mon, 10 Jan 2011 15:49:51 -0500 Message-ID: <000001cbb107$f27a2650$d76e72f0$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acuw+RQOmfUdFdP+QbyFYQHwa/cI+QADJNBQ Content-Language: en-us Cc: 'IPv6 Operations' , int-area@ietf.org Subject: Re: [Int-area] [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 20:47:51 -0000 > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > > This sounds like a WG chartering debate, rather than a debate about whether > > all IP-capable devices SHOULD support IPv6. > > It sounds like your support for draft-george-ipv6-required is dependent on > > rechartering BEHAVE, defining NAT66, and updating > > draft-ietf-v6ops-cpe-router > > to require NAT66. In other words, you will not support the statement, "IPv6 > > > > is required in IP-capable devices" until that statement specifically > > includes > > feature parity, and explicitly includes NAT66. > > Is that right? > > I support the idea that new devices should be IPv6 capable. > > I recognize the irrelevance of such an assertion. IMO, if we can't > assert that "new devices need to support IPv6 as much as they support > IPv4", there's simply no point. We'll be where we are now. Many > organizations won't buy a device without the IPV6 label, but since most > such devices have services that won't run on v6, v6 isn't enabled. This document is targeted at node implementors, not deployers. If specific operators have a need for specific features, they may specify those features to their vendors, or bring them to the IETF for definition. IPv6 is not operator-specific, though; all new implementations must support IPv6. > I.e., what's the point, unless we say "support IPv6 at least as well as > IPv4"? I could live with that statement. What I can't accept is that IPv6 must not be required until everything in IPv6 works the same as in IPv4. Does this language cover the case where a vendor can't implement a feature because the IETF hasn't defined it yet? 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. If that language doesn't work, but you agree with the intended statement in the draft, can you propose language that does not make the draft dependent on publication of a NAT66 RFC? Lee From fernando.gont.netbook.win@gmail.com Mon Jan 10 12:49:08 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D0323A672F; Mon, 10 Jan 2011 12:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4DyinO8YDHZ; Mon, 10 Jan 2011 12:49:07 -0800 (PST) Received: from mail-gx0-f194.google.com (mail-gx0-f194.google.com [209.85.161.194]) by core3.amsl.com (Postfix) with ESMTP id 315503A67C0; Mon, 10 Jan 2011 12:48:37 -0800 (PST) Received: by gxk1 with SMTP id 1so4531931gxk.1 for ; Mon, 10 Jan 2011 12:50:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=fCoyZ+Qo00fN107iIl1kQlSDHHKfGHKZNKH3q9glNjw=; b=nj1/ndTjLStZl4ODXjUpZvUN3mX0ZT+NgDP+LPh7ii1a4w2Xl46NW8sJ14nCUFmEBT Ub9m5fmthX48U2h3Njlr/xmyJd1i0I1EVLzRLZk0BPzStEhWMwuTT8Bpl9JH2yrxhx2P 7NQM2W9uOo9wstIhXz4+n7QAahT0IWSehGP40= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=msF6X7n5PWKFuplObMpM6FvTMDzAlY+DWXlNKGphTmLp5EpNhA06jzGlDgzxr6wuG4 SUA0S3eh2Z/jnWCKRbJShTAYFMAIVnHVW1dS5ICBhCLI2VxZYx2HRyN1Iz/iyazqQVQm FDwhiUjI7t5DQKIfYLV5E6Opvd5s7ha1tUonw= Received: by 10.151.154.15 with SMTP id g15mr29675121ybo.87.1294692651214; Mon, 10 Jan 2011 12:50:51 -0800 (PST) Received: from [192.168.2.4] (138-83-231-201.fibertel.com.ar [201.231.83.138]) by mx.google.com with ESMTPS id k1sm14932320ybj.0.2011.01.10.12.50.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 12:50:49 -0800 (PST) Sender: Fernando Gont Message-ID: <4D2B711F.9000705@gont.com.ar> Date: Mon, 10 Jan 2011 17:50:39 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Mark Smith References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> In-Reply-To: <20110111071329.109df03f@opy.nosense.org> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= , IPv6 Operations , Internet Area Subject: Re: [Int-area] [v6ops] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 20:49:08 -0000 On 10/01/2011 05:43 p.m., Mark Smith wrote: >>> The e2e transparency that IPv4 had lost, and IPv6 restores, is >>> ADDRESS transparency: source and destination addresses seen by a >>> destination are the same as those set by the source. >> >> IPv6 restores this to the extent that NAT66 is not deployed. My take is >> that NAT66 *will* be deployed. > > How do you know? What evidence do you have? Talking to vendors, some operators, etc. Google for "ipv6 nat" or the like, and you'll see some of the people that are publicly interested in this feature. >> -- So, I don't think you can rely IPv6 on >> restoring "address transparency". >> >>> - This is needed >>> in particular for Header Authentication of IPsec. >> >> But you can still use UDP encapsulation. > > UDP encapsulation of IPsec is a work around, specifically to get around > the problems of lack of IPv4 address transparency i.e. NAT. It isn't an > acceptable answer when NAT doesn't need to exist. You're assuming that the only motivation to have NATs is address exhaustion -- but IMO, it isn't. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From ipng@69706e6720323030352d30312d31340a.nosense.org Mon Jan 10 13:13:06 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B9DA3A67DA; Mon, 10 Jan 2011 13:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.27 X-Spam-Level: X-Spam-Status: No, score=-1.27 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIGGluYKuI9Z; Mon, 10 Jan 2011 13:13:05 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id E32843A67EF; Mon, 10 Jan 2011 13:13:04 -0800 (PST) Received: from 182-239-157-145.ip.adam.com.au ([182.239.157.145] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1PcP56-0005oX-Ia; Tue, 11 Jan 2011 07:45:12 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 0D0703B31E; Tue, 11 Jan 2011 07:45:12 +1030 (CST) Date: Tue, 11 Jan 2011 07:45:11 +1030 From: Mark Smith To: "George, Wes E [NTK]" Message-ID: <20110111074511.022d29bf@opy.nosense.org> In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "Howard, Lee" , Christopher, "v6ops@ietf.org" , "int-area@ietf.org" , LILJENSTOLPE Subject: Re: [Int-area] [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 21:13:06 -0000 On Fri, 7 Jan 2011 18:52:33 +0000 "George, Wes E [NTK]" wrote: > As a direct result of discussions after Beijing about the hotly-contested > draft regarding IANA allocating a new shared IPv4 address space, the authors > of this draft realized that the root problem is actually the lack of IPv6 > support in existing devices, which is adding a barrier to wider deployment in > many networks. This is being made worse due to two things: lack of interest by > vendors in back-porting true IPv6 support into devices that are > software-upgradeable and could otherwise support it, and the fact that some > vendors are still churning out devices which do not support IPv6 even as we > stare down the imminent exhaustion of the IANA free IPv4 pool. This draft > attempts to address this problem by updating the definition of an "IP-capable" > node to require support for IPv6. > I don't think I really agree with the root cause. IPv6 doesn't exist in equipment because customers, or representatives of customers (e.g ISPs for CPE) haven't made it a "must have", and refused to buy the equipment when it doesn't support IPv6. Making it a requirement in an IETF document still won't make it happen unless customers demand compliance with that IETF document. They haven't done that with the group of IPv6 RFCs, so I don't see why a single RFC going to be any different. My recent experience has been that a CPE vendor, once they know that you require IPv6 support, starts caring not about whether to implement it or not, but what specific requirements you have. For example, our recent focus has just been basic IPv6 connectivity i.e. so the CPE can connect customers to the IPv6 Internet. Out of the blue, the vendor asked us if we considered SIP over IPv6 for the ATA inside the CPE to be a must have or not. They wouldn't be thinking about that level of feature implementation detail if we hadn't made "IPv6" a fundamental requirement. I've also seen rapid improvement in an IPv6 implementation over a six week period once the vendor realised that they were going to miss out on 100s if not 1000s of CPE sales. (It's very impressive when you report a bug on one day and you've got firmware fresh out of the compiler a day or two later that addresses it). > The authors are fully aware that this is not going to solve the problem of > legacy installed-base, nor is it going to prevent people from continuing to > release hardware that is IPv4-only. However, we believe that the IETF is > overdue to acknowledge that IPv6 will be a requirement going forward, and not > just optional. > I think a different and better approach would be to officially deprecate IPv4, declaring it obsolete. That doesn't mean people can't use it, but it is the IETF saying that it is past it's used-by date, and people should be using IPv6 in preference. I think if the inventors/maintainers of IPv4 were to say people should try to avoid using IPv4, people will pay more attention than continuing to think that it is fine to use IPv4, and IPv6 is an optional feature they can compromise on if they need to. There is a bit of psychology in that - people generally don't like choosing to use obsolete technologies (social proof), and also place significant value on when somebody says "I invented it, but don't use it anymore, you'll have problems." (authority) Regards, Mark. > We'd appreciate your support in adopting this as an int-area draft, or > possibly a v6ops draft. > > We'd be happy to discuss the draft in either meeting at IETF 80 if the WG > chair feels that it is appropriate. > > Thanks, > Wes George > > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Friday, January 07, 2011 1:28 PM > To: George, Wes E [NTK] > Cc: C.Donley@cablelabs.com; cdl@asgaard.org; lee.howard@twcable.com > Subject: New Version Notification for draft-george-ipv6-required-00 > > > A new version of I-D, draft-george-ipv6-required-00.txt has been successfully > submitted by Wesley George and posted to the IETF repository. > > https://datatracker.ietf.org/doc/draft-george-ipv6-required/ > > Filename: draft-george-ipv6-required > Revision: 00 > Title: IPv6 Support Required for all IP-capable nodes > Creation_date: 2011-01-06 > WG ID: Independent 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 and 1122 to > reflect the change in requirements. > > > > The IETF Secretariat. > > > From brian.e.carpenter@gmail.com Mon Jan 10 13:43:30 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35CDE3A6840; Mon, 10 Jan 2011 13:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.108 X-Spam-Level: X-Spam-Status: No, score=-103.108 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSSkjdM8Rk6L; Mon, 10 Jan 2011 13:43:29 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 078473A6841; Mon, 10 Jan 2011 13:43:28 -0800 (PST) Received: by fxm9 with SMTP id 9so19631358fxm.31 for ; Mon, 10 Jan 2011 13:45:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=k6Gwa89mdCEoiIWHBtbC51tptznzM9gVqAE6WFOwE6w=; b=sncz/grnJQ2Bt1siuhU0B1ZWH25gkYi2lXJppvu1muROWvuAjcl+4i9SgxWpbBdYb/ NmYQL5fEJTflcV2zbwOULREXkvLi76t/wRltrZBThQyodTxmq/EeBzUu4cw587U58tBj 8QAHf/u0oULidW1FVJLp5oECblelPi07nAtys= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=szW5GZwUnIqR911nL7adu+IcRaiXxM1Xa6VxYiH6BpiNV80kKqs2o6lnYORHpqQyg+ OGNzPpDooavwoCNvPriq8b8U2loOMOzmLIa41LNF7DpFuVXkhGzP0K1P0pkr6ajIpDOu RUcvoh8BL5n+mBoPuDCREaVZC5nXgCxcKvbkk= Received: by 10.223.95.203 with SMTP id e11mr1246988fan.60.1294695943235; Mon, 10 Jan 2011 13:45:43 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id r24sm7163487fax.3.2011.01.10.13.45.39 (version=SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 13:45:42 -0800 (PST) Message-ID: <4D2B7E00.6020106@gmail.com> Date: Tue, 11 Jan 2011 10:45:36 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> In-Reply-To: <4D2B3928.8050508@gont.com.ar> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= , IPv6 Operations , Internet Area Subject: Re: [Int-area] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 21:43:30 -0000 On 2011-01-11 05:51, Fernando Gont wrote: > Hi, Remi, >=20 > On 10/01/2011 05:30 a.m., R=C3=A9mi Despr=C3=A9s wrote: >=20 >>> End-to-end transparency in the sense that every node will be >>> reachable from every node? >> The e2e transparency that IPv4 had lost, and IPv6 restores, is >> ADDRESS transparency: source and destination addresses seen by a >> destination are the same as those set by the source.=20 >=20 > IPv6 restores this to the extent that NAT66 is not deployed. My take is= > that NAT66 *will* be deployed. -- So, I don't think you can rely IPv6 o= n > restoring "address transparency". IPv4 intrinsically destroys address transparency by not having enough addresses. The good news is that IPv6 doesn't have this property. So although some vendors and users will ignore this good news for reasons of their own, e2e address+port transparency remains available and will in due time be seen as desirable. Patience is needed, though; it will probably be many years before this perception filters through everywhere and NAT66 becomes a curiosity of history. Brian From sthaug@nethelp.no Mon Jan 10 13:45:25 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B98423A6804 for ; Mon, 10 Jan 2011 13:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuznpuvEOD0I for ; Mon, 10 Jan 2011 13:45:24 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by core3.amsl.com (Postfix) with SMTP id A18F63A679C for ; Mon, 10 Jan 2011 13:45:22 -0800 (PST) Received: (qmail 42957 invoked from network); 10 Jan 2011 21:47:35 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 10 Jan 2011 21:47:35 -0000 Date: Mon, 10 Jan 2011 22:47:35 +0100 (CET) Message-Id: <20110110.224735.41641090.sthaug@nethelp.no> To: fernando@gont.com.ar From: sthaug@nethelp.no In-Reply-To: <4D2B711F.9000705@gont.com.ar> References: <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ipng@69706e6720323030352d30312d31340a.nosense.org, v6ops@ietf.org, int-area@ietf.org Subject: Re: [Int-area] [v6ops] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 21:45:25 -0000 > > UDP encapsulation of IPsec is a work around, specifically to get around > > the problems of lack of IPv4 address transparency i.e. NAT. It isn't an > > acceptable answer when NAT doesn't need to exist. > > You're assuming that the only motivation to have NATs is address > exhaustion -- but IMO, it isn't. Provider independence is a huge motivation. People have it with IPv4 and NAT today, at least to some degree - and don't see why they should be tied to a specific provider's PA space, *or* have to jump through hoops, to get IPv6 PI space. Thus the desire for IPv6 stateless NAT. [If you don't think IPv6 PI space requires jumping through hoops - consider http://www.ripe.net/ripe/policies/proposals/2006-01.html which is the RIPE requirements for PI space. Note that I'm *not* saying these requirements are bad - I'm just saying they are more than a lot of companies, used to IPv4 NAT, will be willing to deal with...] Steinar Haug, Nethelp consulting, sthaug@nethelp.no From ipng@69706e6720323030352d30312d31340a.nosense.org Mon Jan 10 13:48:17 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C22E43A6856; Mon, 10 Jan 2011 13:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.272 X-Spam-Level: X-Spam-Status: No, score=-1.272 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enQigBuzN0Y7; Mon, 10 Jan 2011 13:48:16 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id A1B603A6859; Mon, 10 Jan 2011 13:48:14 -0800 (PST) Received: from 182-239-157-145.ip.adam.com.au ([182.239.157.145] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1PcPdC-0008Ld-4W; Tue, 11 Jan 2011 08:20:26 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 765993B31E; Tue, 11 Jan 2011 08:20:23 +1030 (CST) Date: Tue, 11 Jan 2011 08:20:23 +1030 From: Mark Smith To: "Lee Howard" Message-ID: <20110111082023.209f0497@opy.nosense.org> In-Reply-To: <000001cbb107$f27a2650$d76e72f0$@org> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> <4D279717.1050602@isi.edu> <20110109103956.383b2284@opy.nosense.org> <4D2B4618.6050703@isi.edu> <001101cbb0f7$06cc8af0$1465a0d0$@org> <4D2B57DD.5030908@isi.edu> <000001cbb107$f27a2650$d76e72f0$@org> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: 'IPv6 Operations' , int-area@ietf.org Subject: Re: [Int-area] [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 21:48:17 -0000 On Mon, 10 Jan 2011 15:49:51 -0500 "Lee Howard" wrote: > > > > -----Original Message----- > > From: Joe Touch [mailto:touch@isi.edu] > > > This sounds like a WG chartering debate, rather than a debate about > whether > > > all IP-capable devices SHOULD support IPv6. > > > It sounds like your support for draft-george-ipv6-required is dependent > on > > > rechartering BEHAVE, defining NAT66, and updating > > > draft-ietf-v6ops-cpe-router > > > to require NAT66. In other words, you will not support the statement, > "IPv6 > > > > > > is required in IP-capable devices" until that statement specifically > > > includes > > > feature parity, and explicitly includes NAT66. > > > Is that right? > > > > I support the idea that new devices should be IPv6 capable. > > > > I recognize the irrelevance of such an assertion. IMO, if we can't > > assert that "new devices need to support IPv6 as much as they support > > IPv4", there's simply no point. We'll be where we are now. Many > > organizations won't buy a device without the IPV6 label, but since most > > such devices have services that won't run on v6, v6 isn't enabled. > > This document is targeted at node implementors, not deployers. > If specific operators have a need for specific features, they may specify > those features to their vendors, or bring them to the IETF for > definition. IPv6 is not operator-specific, though; all new implementations > must support IPv6. > > > I.e., what's the point, unless we say "support IPv6 at least as well as > > IPv4"? > > I could live with that statement. What I can't accept is that IPv6 must > not be required until everything in IPv6 works the same as in IPv4. I agree, and I think the following post a few months ago was very insightful regarding requiring complete IPv4/IPv6 parity - http://lists.cluenet.de/pipermail/ipv6-ops/2010-June/003650.html > Does this language cover the case where a vendor can't implement a > feature because the IETF hasn't defined it yet? > 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. > > If that language doesn't work, but you agree with the intended > statement in the draft, can you propose language that does not > make the draft dependent on publication of a NAT66 RFC? > > Lee > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From touch@isi.edu Mon Jan 10 13:59:29 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 341A93A67A2; Mon, 10 Jan 2011 13:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKxJxAXnwtJy; Mon, 10 Jan 2011 13:59:28 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 3305A3A6820; Mon, 10 Jan 2011 13:59:28 -0800 (PST) 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 p0AM1Tck017435 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 10 Jan 2011 14:01:29 -0800 (PST) Message-ID: <4D2B81B8.70008@isi.edu> Date: Mon, 10 Jan 2011 14:01:28 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Lee Howard References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> <4D279717.1050602@isi.edu> <20110109103956.383b2284@opy.nosense.org> <4D2B4618.6050703@isi.edu> <001101cbb0f7$06cc8af0$1465a0d0$@org> <4D2B57DD.5030908@isi.edu> <000001cbb107$f27a2650$d76e72f0$@org> In-Reply-To: <000001cbb107$f27a2650$d76e72f0$@org> 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: 'IPv6 Operations' , int-area@ietf.org Subject: Re: [Int-area] [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 21:59:29 -0000 Hi, Lee, On 1/10/2011 12:49 PM, Lee Howard wrote: ... >> I.e., what's the point, unless we say "support IPv6 at least as well as >> IPv4"? > > I could live with that statement. What I can't accept is that IPv6 must > not be required until everything in IPv6 works the same as in IPv4. AOK; I don't want to get hung up on specifics. Again, the point is that "support IPv6 at least as well as IPv4" is better than "support IPv6". > Does this language cover the case where a vendor can't implement a > feature because the IETF hasn't defined it yet? Well, if there are such features, then they're clearly going to be an issue. That needs to be fixed. Sure, you can't expect an implementation to support IPv6 for protocols that have no IPv6 variant yet. That means we have work to do before we ought to be jumping up and down expecting everyone to use IPv6, though. > 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 don't like this language. It was true for Windows and MacOS previous to the 2005 IPv6 IETF test, and we saw how that worked out (not). IMO, you shouldn't be able to claim IPv6 just by "best effort". There is no SHOULD, enable or support. There is only "do". I.e., either a system supports IPv6 - for all IP communications - or not. That might be sufficient, if you want different language: "A system that supports IPv6 MUST support IPv6 for all IP communications in the absence of any other version of IP communications (including IPv4). That system MUST provide IPv6 communications services to the same or greater extent than are available for IPv4." and "All new systems SHOULD support IPv6 as per above. All existing systems SHOULD support IPv6 as per above as soon as possible" > If that language doesn't work, but you agree with the intended > statement in the draft, can you propose language that does not > make the draft dependent on publication of a NAT66 RFC? That's one you want to exclude. I'm sure there are others that other people want to exclude. Any that are excluded *will* (IMO) be an excuse for not using IPv6. I would prefer to ensure that IPv6 has the same or greater services than IPv4, and separately state that: "Note that not all IPv4 services are recommended or even defined in an IPv6-only environment. To the extent that such services are not meaningful (e.g., NAT66 solely for address space extension), they are not required by the above." Joe From lee@asgard.org Mon Jan 10 16:41:28 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58FE83A6837 for ; Mon, 10 Jan 2011 16:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6dIga4w6roO for ; Mon, 10 Jan 2011 16:41:27 -0800 (PST) Received: from omr4.networksolutionsemail.com (omr4.networksolutionsemail.com [205.178.146.54]) by core3.amsl.com (Postfix) with ESMTP id 37B423A6828 for ; Mon, 10 Jan 2011 16:41:27 -0800 (PST) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr4.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p0B0hgdF017922 for ; Mon, 10 Jan 2011 19:43:42 -0500 Authentication-Results: cm-omr14 smtp.user=lee@asgard.org; auth=pass (LOGIN) X-Authenticated-UID: lee@asgard.org Received: from [204.235.115.167] ([204.235.115.167:63440] helo=HDC00027112) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 32/8D-03534-DB7AB2D4; Mon, 10 Jan 2011 19:43:42 -0500 From: "Lee Howard" To: "'Joe Touch'" References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> <4D279717.1050602@isi.edu> <20110109103956.383b2284@opy.nosense.org> <4D2B4618.6050703@isi.edu> <001101cbb0f7$06cc8af0$1465a0d0$@org> <4D2B57DD.5030908@isi.edu> <000001cbb107$f27a2650$d76e72f0$@org> <4D2B81B8.70008@isi.edu> In-Reply-To: <4D2B81B8.70008@isi.edu> Date: Mon, 10 Jan 2011 19:43:41 -0500 Message-ID: <000001cbb128$9826d100$c8747300$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuxEfcx4/VuoFNNTUyOdRIqnLR0DAAEy5qA Content-Language: en-us Cc: 'IPv6 Operations' , int-area@ietf.org Subject: Re: [Int-area] [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 00:41:28 -0000 > > Does this language cover the case where a vendor can't implement a > > feature because the IETF hasn't defined it yet? > > Well, if there are such features, then they're clearly going to be an > issue. That needs to be fixed. Well, again in the case of NAT66 (which you haven't argued is a bad example), it isn't needed in the home gateway. Can we not require IPv6 in the home gateway, because NAT66 is not supported? > Sure, you can't expect an implementation to support IPv6 for protocols > that have no IPv6 variant yet. That means we have work to do before we > ought to be jumping up and down expecting everyone to use IPv6, though. You argued that NAT66 was required for presenting a cluster a single address (like a load balancer), just like in IPv4. Can you point me to the RFC defining that behavior? > > 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 don't like this language. It was true for Windows and MacOS previous > to the 2005 IPv6 IETF test, and we saw how that worked out (not). > > IMO, you shouldn't be able to claim IPv6 just by "best effort". There is > no SHOULD, enable or support. There is only "do". I.e., either a system > supports IPv6 - for all IP communications - or not. > > That might be sufficient, if you want different language: > > "A system that supports IPv6 MUST support IPv6 for all > IP communications in the absence of any other version of IP > communications (including IPv4). That system MUST provide > IPv6 communications services to the same or greater > extent than are available for IPv4." We could take this off-list if we're getting too detailed in wordsmithing. Is this not the equivalent of, "IP networking implementations MUST NOT require IPv4 for proper and complete function."? If an implementation is missing required functionality, then it does not have "proper and complete function." If it's missing unrequired functionality, there's no reason to require it. > > and > "All new systems SHOULD support IPv6 as per above. > All existing systems SHOULD support IPv6 as per above > as soon as possible" Not MUST for new systems? > > If that language doesn't work, but you agree with the intended > > statement in the draft, can you propose language that does not > > make the draft dependent on publication of a NAT66 RFC? > > That's one you want to exclude. I'm sure there are others that other > people want to exclude. Any that are excluded *will* (IMO) be an excuse > for not using IPv6. Yes, people can find excuses. Ignorance can be fixed (only stupidity is forever). For clueful people to withhold support for IPv6 because ignorant people think they want ponies doesn't make sense to me. > I would prefer to ensure that IPv6 has the same or greater services than > IPv4, and separately state that: > > "Note that not all IPv4 services are recommended or even defined > in an IPv6-only environment. To the extent that such services > are not meaningful (e.g., NAT66 solely for address space > extension), they are not required by the above." Sounds like a disclaimer. Maybe more wordsmithing, but on this one I understand the intent. Lee > Joe From touch@isi.edu Mon Jan 10 16:47:32 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC7463A684D; Mon, 10 Jan 2011 16:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoRm9OqffBuv; Mon, 10 Jan 2011 16:47:32 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id E94583A67ED; Mon, 10 Jan 2011 16:47:31 -0800 (PST) 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 p0B0nWHe022158 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 10 Jan 2011 16:49:32 -0800 (PST) Message-ID: <4D2BA91A.8040804@isi.edu> Date: Mon, 10 Jan 2011 16:49:30 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Lee Howard References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> <4D279717.1050602@isi.edu> <20110109103956.383b2284@opy.nosense.org> <4D2B4618.6050703@isi.edu> <001101cbb0f7$06cc8af0$1465a0d0$@org> <4D2B57DD.5030908@isi.edu> <000001cbb107$f27a2650$d76e72f0$@org> <4D2B81B8.70008@isi.edu> <000001cbb128$9826d100$c8747300$@org> In-Reply-To: <000001cbb128$9826d100$c8747300$@org> 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: 'IPv6 Operations' , int-area@ietf.org Subject: Re: [Int-area] [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 00:47:33 -0000 On 1/10/2011 4:43 PM, Lee Howard wrote: >>> Does this language cover the case where a vendor can't implement a >>> feature because the IETF hasn't defined it yet? >> >> Well, if there are such features, then they're clearly going to be an >> issue. That needs to be fixed. > > Well, again in the case of NAT66 (which you haven't argued is a bad > example), it isn't needed in the home gateway. Can we not require IPv6 > in the home gateway, because NAT66 is not supported? > >> Sure, you can't expect an implementation to support IPv6 for protocols >> that have no IPv6 variant yet. That means we have work to do before we >> ought to be jumping up and down expecting everyone to use IPv6, though. > > You argued that NAT66 was required for presenting a cluster a single > address (like a load balancer), just like in IPv4. Can you point me to the > RFC defining that behavior? That's what it does. Any of the NAT doc defines that behavior. ... >> That might be sufficient, if you want different language: >> >> "A system that supports IPv6 MUST support IPv6 for all >> IP communications in the absence of any other version of IP >> communications (including IPv4). That system MUST provide >> IPv6 communications services to the same or greater >> extent than are available for IPv4." > > We could take this off-list if we're getting too detailed in wordsmithing. > Is this not the equivalent of, "IP networking implementations > MUST NOT require IPv4 for proper and complete function."? That's better. > If an implementation is missing required functionality, then it > does not have "proper and complete function." > If it's missing unrequired functionality, there's no reason to require > it. Agreed. The definition of complete would then be in the eye of the beholder (or consumer)... >> and >> "All new systems SHOULD support IPv6 as per above. >> All existing systems SHOULD support IPv6 as per above >> as soon as possible" > > Not MUST for new systems? Sure, if you prefer. ... >> I would prefer to ensure that IPv6 has the same or greater services than >> IPv4, and separately state that: >> >> "Note that not all IPv4 services are recommended or even defined >> in an IPv6-only environment. To the extent that such services >> are not meaningful (e.g., NAT66 solely for address space >> extension), they are not required by the above." > > Sounds like a disclaimer. Maybe more wordsmithing, but on this > one I understand the intent. You might not need that given the variant you suggested; there's enough wiggle room in "proper" and "complete" being something undefined by the IETF anyway. Joe From brian.e.carpenter@gmail.com Mon Jan 10 17:45:31 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 775093A6901; Mon, 10 Jan 2011 17:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.425 X-Spam-Level: X-Spam-Status: No, score=-103.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPGiYAco41Eq; Mon, 10 Jan 2011 17:45:30 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 787493A68FF; Mon, 10 Jan 2011 17:45:30 -0800 (PST) Received: by vws7 with SMTP id 7so8161693vws.31 for ; Mon, 10 Jan 2011 17:47:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=QtXCOwIgtFy6mqWbeq2wpaF8+oqKjxZP4ZwN0joo9Yk=; b=et/KEmC+1n9140iSC5MsAkK4GDqIKDBhltBFqWcbQlOCvRPQhf1GZDh1xU8ptotP6R LjHmqQPdjaXqkOoVOh4P8wnIe6beT6C3CxiAO+mzCmYtQWjA6lLy4SRWVrBiTqKItUGM 7tU5bb9s9urFx1z9mV+zGLbm3zKQnp3ZCHAr0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=byK7ooV4jt6Lo+uRxyylE6y9K91AzrOGN9MrjnotTjYBQOR2eBHRGmqt+nxaw73lwL CulC6462J7JtSTBSyRMU2ceVxgK3K+X56RbIOU1P2j//GVyurh+Lkg4aJPuH8ijuot8X s58AM75trywmaY27yY/IsOchyMAwu1LZFjkSw= Received: by 10.220.175.135 with SMTP id ba7mr8926768vcb.79.1294710465266; Mon, 10 Jan 2011 17:47:45 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id k39sm6556884vcr.2.2011.01.10.17.47.42 (version=SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 17:47:44 -0800 (PST) Message-ID: <4D2BB6C6.3050104@gmail.com> Date: Tue, 11 Jan 2011 14:47:50 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joe Touch References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> <4D279717.1050602@isi.edu> <20110109103956.383b2284@opy.nosense.org> <4D2B4618.6050703@isi.edu> <001101cbb0f7$06cc8af0$1465a0d0$@org> <4D2B57DD.5030908@isi.edu> <000001cbb107$f27a2650$d76e72f0$@org> <4D2B81B8.70008@isi.edu> <000001cbb128$9826d100$c8747300$@org> <4D2BA91A.8040804@isi.edu> In-Reply-To: <4D2BA91A.8040804@isi.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: int-area@ietf.org, 'IPv6 Operations' Subject: Re: [Int-area] [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 01:45:31 -0000 On 2011-01-11 13:49, Joe Touch wrote: > > > On 1/10/2011 4:43 PM, Lee Howard wrote: >>>> Does this language cover the case where a vendor can't implement a >>>> feature because the IETF hasn't defined it yet? >>> >>> Well, if there are such features, then they're clearly going to be an >>> issue. That needs to be fixed. >> >> Well, again in the case of NAT66 (which you haven't argued is a bad >> example), it isn't needed in the home gateway. Can we not require IPv6 >> in the home gateway, because NAT66 is not supported? >> >>> Sure, you can't expect an implementation to support IPv6 for protocols >>> that have no IPv6 variant yet. That means we have work to do before we >>> ought to be jumping up and down expecting everyone to use IPv6, though. >> >> You argued that NAT66 was required for presenting a cluster a single >> address (like a load balancer), just like in IPv4. Can you point me >> to the >> RFC defining that behavior? > > That's what it does. Any of the NAT doc defines that behavior. I don't think so, if you're trying to load-balance traffic to and from Port 80. Stateful NAPT can't do this. And as I already said, such usage is patented. https://datatracker.ietf.org/ipr/208/ Brian From fred@cisco.com Mon Jan 10 21:13:02 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 146BB28C260; Mon, 10 Jan 2011 21:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.458 X-Spam-Level: X-Spam-Status: No, score=-110.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCyQHf9FWpID; Mon, 10 Jan 2011 21:13:01 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 5736228C20D; Mon, 10 Jan 2011 21:13:01 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKt1K02rR7Ht/2dsb2JhbACkOHOiS5hwhUwEhGeGI4Mg Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 11 Jan 2011 05:15:17 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0B5FBM0014792; Tue, 11 Jan 2011 05:15:16 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Mon, 10 Jan 2011 21:15:17 -0800 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Mon, 10 Jan 2011 21:15:17 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <000001cbb128$9826d100$c8747300$@org> Date: Mon, 10 Jan 2011 21:15:01 -0800 Message-Id: References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27962F.9030005@gmail.com> <4D279717.1050602@isi.edu> <20110109103956.383b2284@opy.nosense.org> <4D2B4618.6050703@isi.edu> <001101cbb0f7$06cc8af0$1465a0d0$@org> <4D2B57DD.5030908@isi.edu> <000001cbb107$f27a2650$d76e72f0$@org> <4D2B81B8.70008@isi.edu> <000001cbb128$9826d100$c8747300$@org> To: "Lee Howard" X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: 'IPv6 Operations' , int-area@ietf.org Subject: Re: [Int-area] [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 05:13:02 -0000 On Jan 10, 2011, at 4:43 PM, Lee Howard wrote: > You argued that NAT66 was required for presenting a cluster a single > address (like a load balancer), just like in IPv4. Can you point me = to the > RFC defining that behavior? I can show you an internet draft. It doesn't use a single address; it is = prefix translation. But it does have the unfortunate term "nat66" in its = moniker. http://tools.ietf.org/html/draft-mrw-nat66 "IPv6-to-IPv6 Network Prefix Translation", Margaret Wasserman, Fred Baker, 4-Jan-11= From ipng@69706e6720323030352d30312d31340a.nosense.org Tue Jan 11 00:56:34 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4AB23A6A1D; Tue, 11 Jan 2011 00:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.574 X-Spam-Level: X-Spam-Status: No, score=-1.574 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8g5sB4C48TA; Tue, 11 Jan 2011 00:56:33 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id 859203A63EB; Tue, 11 Jan 2011 00:56:33 -0800 (PST) Received: from 182-239-157-145.ip.adam.com.au ([182.239.157.145] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Pca3u-00017I-Ng; Tue, 11 Jan 2011 19:28:42 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 78A9A3B335; Tue, 11 Jan 2011 19:28:41 +1030 (CST) Date: Tue, 11 Jan 2011 19:28:41 +1030 From: Mark Smith To: "Howard, Lee" Message-ID: <20110111192841.1022911e@opy.nosense.org> In-Reply-To: References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <20110111074511.022d29bf@opy.nosense.org> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "int-area@ietf.org" , "v6ops@ietf.org" , LILJENSTOLPE , Christopher Subject: Re: [Int-area] [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 08:56:34 -0000 Hi Lee, On Mon, 10 Jan 2011 19:59:33 -0500 "Howard, Lee" wrote: > > -----Original Message----- > > From: Mark Smith [mailto:ipng@69706e6720323030352d30312d31340a.nosense.org] > > Sent: Monday, January 10, 2011 4:15 PM > > I don't think I really agree with the root cause. IPv6 doesn't exist in > > equipment because customers, or representatives of customers (e.g ISPs > > for CPE) haven't made it a "must have", and refused to buy the equipment > > when it doesn't support IPv6. > > What about ISPs who don't buy CPE? > Retail stores in the U.S. make a lot of money selling gateways to retail > customers. Consumers get more choice of what gateway they want to > buy. Surely we don't expect consumers to provide CPE requirements? > That's why we wrote cpe-router. I'm all for that draft, and want to see it published as soon as it can be. The shame if it is though that it wasn't written and published 5 or more years ago. Right when we need to be deploying (or trying to convince customers to buy and deploy) IPv6 capable residential CPE at a rapid pace, only months before IANA run out of IPv4 addresses, and probably no more than 12 to 18 months before ISPs run out of IPv4 addresses, very little of it exists. LSN/CGN might stretch the deployment period we have available, but I think it is going to get really ugly operationally behind the scenes at ISPs. > > > I think a different and better approach would be to officially deprecate > > IPv4, declaring it obsolete. > > I've been thinking about writing that draft (it sounds really good on the > last day of IETF, over beers). > > After the recent thread on "Old transport-layer protocols to Historic" > I'm confused about what the right word would be. The list of > dependent RFCs would be long, and it might make an interesting career > for someone to submit new drafts to obsolete all of the then-deprecated > drafts. > > But I'll write it if you want. > I think there would be a lot of symbolic value in it. If people don't have an interest in the details, symbolic gestures, without resorting to FUD, can be effective in influencing people's buying choices. Regards, Mark. From remi.despres@free.fr Tue Jan 11 02:52:09 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9586728C114; Tue, 11 Jan 2011 02:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.136 X-Spam-Level: X-Spam-Status: No, score=-0.136 tagged_above=-999 required=5 tests=[AWL=-0.787, BAYES_50=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Qzd3BLd2OFs; Tue, 11 Jan 2011 02:52:09 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by core3.amsl.com (Postfix) with ESMTP id D0F0B28C275; Tue, 11 Jan 2011 02:52:07 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2118.sfr.fr (SMTP Server) with ESMTP id DE1167000342; Tue, 11 Jan 2011 11:54:23 +0100 (CET) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2118.sfr.fr (SMTP Server) with ESMTP id AD1277000339; Tue, 11 Jan 2011 11:54:23 +0100 (CET) X-SFR-UUID: 20110111105423708.AD1277000339@msfrf2118.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4D2B3928.8050508@gont.com.ar> Date: Tue, 11 Jan 2011 11:54:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5F9EDE1C-BA6C-4DB0-8756-F725B318F4BE@free.fr> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1082) Cc: Internet Area , IPv6 Operations Subject: Re: [Int-area] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 10:52:09 -0000 Le 10 janv. 2011 =E0 17:51, Fernando Gont a =E9crit : > ... My take is that NAT66 *will* be deployed. For clarification, which NAT66 do you have in mind? - stateful NAPTv6? - stateless NPTv6? - both? > -- So, I don't think you can rely IPv6 on > restoring "address transparency". IMHO, at least some customers will insist on having address = transparency. These customers will need ways to avoid NAT66's (but, of course, without = having to sacrifice any FW function for this). Regards, RD From remi.despres@free.fr Tue Jan 11 03:15:43 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0146728C100; Tue, 11 Jan 2011 03:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bu-nJZskeK4C; Tue, 11 Jan 2011 03:15:42 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by core3.amsl.com (Postfix) with ESMTP id 1CF0F28C26F; Tue, 11 Jan 2011 03:15:42 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2118.sfr.fr (SMTP Server) with ESMTP id 35C0B7000342; Tue, 11 Jan 2011 12:17:58 +0100 (CET) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2118.sfr.fr (SMTP Server) with ESMTP id B94557000340; Tue, 11 Jan 2011 12:17:57 +0100 (CET) X-SFR-UUID: 20110111111757758.B94557000340@msfrf2118.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20110110.224735.41641090.sthaug@nethelp.no> Date: Tue, 11 Jan 2011 12:17:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <20110110.224735.41641090.sthaug@nethelp.no> To: Steinar Haug X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org, int-area@ietf.org Subject: Re: [Int-area] [v6ops] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 11:15:43 -0000 Le 10 janv. 2011 =E0 22:47, sthaug@nethelp.no a =E9crit : >>> UDP encapsulation of IPsec is a work around, specifically to get = around >>> the problems of lack of IPv4 address transparency i.e. NAT. It isn't = an >>> acceptable answer when NAT doesn't need to exist. >>=20 >> You're assuming that the only motivation to have NATs is address >> exhaustion -- but IMO, it isn't. >=20 > Provider independence is a huge motivation. Agreed. That's why, IMHO, it should be more useful to look for solutions that = combine provider independence with address transparency, than accepting = without effort to sacrifice address transparency for provider = independence. Although I know some readers don't like my repeating that I worked on = such a solution, this is IMHO relevant to the point being discussed. Ref: www.ietf.org/id/draft-despres-softwire-sam-01, in particular sec. = 3.3. (As this draft is about to expire, I should work in some future on a = revised version.)=20 Regards, RD From Wesley.E.George@sprint.com Tue Jan 11 06:35:22 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C857028C183; Tue, 11 Jan 2011 06:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.393 X-Spam-Level: X-Spam-Status: No, score=-5.393 tagged_above=-999 required=5 tests=[AWL=1.206, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBkyMDNoAL0V; Tue, 11 Jan 2011 06:35:19 -0800 (PST) Received: from TX2EHSOBE009.bigfish.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by core3.amsl.com (Postfix) with ESMTP id 91E8228C179; Tue, 11 Jan 2011 06:35:19 -0800 (PST) Received: from mail84-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.8; Tue, 11 Jan 2011 14:37:36 +0000 Received: from mail84-tx2 (localhost.localdomain [127.0.0.1]) by mail84-tx2-R.bigfish.com (Postfix) with ESMTP id 26ED91C061E; Tue, 11 Jan 2011 14:37:36 +0000 (UTC) X-SpamScore: -13 X-BigFish: VS-13(zz542N1432N10d1Izz1202hzzz2fh2a8h668h34h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:plsasdm1.corp.sprint.com; RD:smtpls1.sprint.com; EFVD:NLI Received: from mail84-tx2 (localhost.localdomain [127.0.0.1]) by mail84-tx2 (MessageSwitch) id 1294756655679573_24718; Tue, 11 Jan 2011 14:37:35 +0000 (UTC) Received: from TX2EHSMHS004.bigfish.com (unknown [10.9.14.250]) by mail84-tx2.bigfish.com (Postfix) with ESMTP id 8149FEE8057; Tue, 11 Jan 2011 14:37:35 +0000 (UTC) Received: from plsasdm1.corp.sprint.com (144.230.168.25) by TX2EHSMHS004.bigfish.com (10.9.99.104) with Microsoft SMTP Server (TLS) id 14.1.225.8; Tue, 11 Jan 2011 14:37:34 +0000 Received: from PLSWEH05.ad.sprint.com (PLSWEH05.corp.sprint.com [144.226.251.23]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p0BEbQ9H029769 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Jan 2011 08:37:32 -0600 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PLSWEH05.ad.sprint.com ([2002:90e2:fb17::90e2:fb17]) with mapi id 14.01.0255.000; Tue, 11 Jan 2011 08:37:32 -0600 From: "George, Wes E [NTK]" To: "Howard, Lee" , Mark Smith Thread-Topic: [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required Thread-Index: AcuxC3/rsWoU8AoNQcqSpDOWTI/8EAAHejXgABr1PnA= Date: Tue, 11 Jan 2011 14:37:31 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E04C472@PLSWM12A.ad.sprint.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <20110111074511.022d29bf@opy.nosense.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.53.23] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0020_01CBB173.2A9A1ED0" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Cc: "v6ops@ietf.org" , "int-area@ietf.org" , Christopher LILJENSTOLPE Subject: Re: [Int-area] [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 14:35:23 -0000 ------=_NextPart_000_0020_01CBB173.2A9A1ED0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > > -----Original Message----- > > From: Mark Smith > > I don't think I really agree with the root cause. IPv6 doesn't exist in > > equipment because customers, or representatives of customers (e.g ISPs > > for CPE) haven't made it a "must have", and refused to buy the > > equipment when it doesn't support IPv6. > > -----Original Message----- > From: Howard, Lee [mailto:lee.howard@twcable.com] > What about ISPs who don't buy CPE? > Retail stores in the U.S. make a lot of money selling gateways to > retail > customers. Consumers get more choice of what gateway they want to > buy. Surely we don't expect consumers to provide CPE requirements? > That's why we wrote cpe-router. [WES] Let's not forget that this is not just about residential gateways. We have TVs that connect to one or more streaming-video and social media services, appliances that talk either to the smart grid, or your home energy monitor, or a website, or all of the above; nevermind things like gaming consoles, standalone streaming media boxes, eReaders with Wifi... should I go on? If you could find someone at $consumer_electronics_manufacturer of any of the above products that we could provide those requirements to (who would actually...you know... listen to us and do something about it), I know of several representatives from large cable companies that represent a large fraction of their consumer base who would *love* to make IPv6 a must-have and explain to them how badly their product might potentially function behind NAT444. ARIN has been trying at places like CES, and ISOC has also tried to reach out to representatives of these industries, both with what I would consider to be only marginal success thus far. > > > I think a different and better approach would be to officially > > deprecate IPv4, declaring it obsolete. > > I've been thinking about writing that draft (it sounds really good on > the last day of IETF, over beers). > > After the recent thread on "Old transport-layer protocols to Historic" > I'm confused about what the right word would be. [WES] We started out that way with this draft, actually. But as Lee says, we couldn't determine whether deprecate or historic was the right choice, and we realized that honestly it's not that simple. I expect that we'll get much wider support for "IPv6 is required for devices that want to call themselves IP-capable" than for IPv4 deprecation when IPv4 is still the dominant protocol in use. This is at least partially because there are plenty of places where IPv4 will *never* go away or won't go away until the device using it is retired, where it is functioning acceptably and there is no issue with a lack of IPv4 addresses because that application isn't growing. Will those IPv4-only networks start becoming islands connected by IPv6 with ALG at some point? Likely, but if they're completely closed networks, we probably can't say that IPv4 isn't acceptable. My view is that the deprecation/historic discussion is one to have once we've reached critical mass on IPv6, or at least when we've exhausted the RIR free pools. Either way, this is a multistep process. The first step is to make sure that those manufacturers who don't have a clueful and influential customer providing them requirements understand that they need to stop grunting out widgets that don't understand IPv6, and to help apply pressure to those who are on the fence. We aren't going to be able to force them to do anything, only provide guidance, but I would hope that the IETF has some influence here. However, I imagine your average consumer is going to be a lot angrier when we tell them that the shiny new internet-connected device that they just got for $winter_gift-giving_holiday 2010 is basically obsolete, or at best functioning in a degraded fashion, due to a problem that we've known about for many years. The vendor of said device shares some blame for being short-sighted, greedy or both, especially if they don't update their software-updatable devices with an IPv6 stack, but I still don't know how IETF is going to answer the question as to why we didn't require IPv6 sooner. Wes George ------=_NextPart_000_0020_01CBB173.2A9A1ED0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXHjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggarMIIFk6ADAgECAgo8 FVeJAAAAAZIPMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMDgwNTAxMTczNzE0WhcNMTEwNTAx MTczNzE0WjCBzzETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxEDAOBgNVBAsTB01hbmFn ZWQxGzAZBgNVBAsTElN0YW5kYXJkLVRlY2huaWNhbDEbMBkGA1UEAxMSV2VzbGV5IEUgR2Vvcmdl IElWMSkwJwYJKoZIhvcNAQkBFhpXZXNsZXkuRS5HZW9yZ2VAc3ByaW50LmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEArxfUh9TugEcsXY4OefFQTrGuaTRenLcZg0KCxZlTY7P9wMRCYd8p GJljwH1x4qn0Ejjyz+uX5UL8Biia13BSWRgiq7QYLKTZNKwEpBbeOf9lK/LrPsbFOgat/Zh/lPmx YzxeikU42X3KhyVSCmWdQhmWRu5kfUzsejaGWH9AyuUCAwEAAaOCA2EwggNdMAsGA1UdDwQEAwIF oDA2BgkqhkiG9w0BCQ8EKTAnMA0GCCqGSIb3DQMCAgE4MA0GCCqGSIb3DQMEAgE4MAcGBSsOAwIH MB0GA1UdDgQWBBTFSbrzJuajBSX9B63Y9r2TlgbU5DA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3 FQiBkugshNficv2LB4Xs/liCno8icYbjvkqEsfZAAgFkAgECMB8GA1UdIwQYMBaAFAGPJVAshjSb wX6QH9mINbU/rwuJMIIBXgYDVR0fBIIBVTCCAVEwggFNoIIBSaCCAUWGgeNsZGFwOi8vL0NOPVNw cmludCUyME5leHRlbCUyMEVudGVycHJpc2UlMjBJc3N1aW5nJTIwMSUyMEF1dGhvcml0eSxDTj1Q UEtJV0MwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1hZCxEQz1zcHJpbnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlv bkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYraHR0cDovL2NybC5z cHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNybIYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdDMDEvUFBLSVdDMDEuY3JsMIGFBggrBgEFBQcBAQR5MHcwNwYIKwYBBQUHMAKGK2h0 dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwPAYIKwYBBQUHMAKGMGh0 dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNydDApBgNVHSUEIjAg BggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AX DBV3ZWcwMjIxQGFkLnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQBYdUj2FTmOVS0X2fF+OYWXu9QoS6JWB8exD8kBPWVh28UilosoFwpVs2Ux K+V9NE1SC4QXDfwcjyMMV6WfXfy1foT6YAOcLt1z91ALCbTPlr1mazbAnOL6AzoTnq5V+TjvJvdN IYROS6PJC/YU5+w/NannnhC1zNFOtmxZZcrz50uRU8Q4mgITpxcnJXKUtKNaFTEhhtnP+hMVXYW0 eUyG7xjDTCyqsO5jcyI0IKJkNW1NXaKjHfmlAAiL5HVNl7cYL5uce6orHQQPMTSGRmTKCNjx7Yaz EHAorZUGmCTuihdhPDq+tOhGrIDE4XuiDxj+OVU6JXM5nsiKTjU968o4MYIDLTCCAykCAQEwgYYw eDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT 8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1 dGhvcml0eQIKPBVXiQAAAAGSDzAJBgUrDgMCGgUAoIIB/DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTAxMTExNDM3MzBaMCMGCSqGSIb3DQEJBDEWBBTGou7slZ03 Iue0+7/L1ss2QpNuWzBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG 9w0CBTCBlwYJKwYBBAGCNxAEMYGJMIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wgZkGCyqGSIb3DQEJ EAILMYGJoIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJpbnQx EjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNlIElz c3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wDQYJKoZIhvcNAQEBBQAEgYBKUj3noPXis+vB RLqPsscIRK30xWPGdjxfywK2vk4/sDPhzCjwEUDzWB9lb1GGtVRWVjim5Emo1RmFYOIKnwh+StM5 2ljXMODn9vVkaT8rJhaPwcJ4ucAOeAFZLMS59ltYiNx03iDFlwv58kSZGXoUFnJDwSV21E4eEjlP DPYF5wAAAAAAAA== ------=_NextPart_000_0020_01CBB173.2A9A1ED0-- From jnc@mercury.lcs.mit.edu Tue Jan 11 08:44:58 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EE173A67FD; Tue, 11 Jan 2011 08:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.504 X-Spam-Level: X-Spam-Status: No, score=-6.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v53vBBTASsO6; Tue, 11 Jan 2011 08:44:57 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id A13383A6A1F; Tue, 11 Jan 2011 08:44:57 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id CA1956BE595; Tue, 11 Jan 2011 11:47:13 -0500 (EST) To: int-area@ietf.org, v6ops@ietf.org Message-Id: <20110111164713.CA1956BE595@mercury.lcs.mit.edu> Date: Tue, 11 Jan 2011 11:47:13 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [Int-area] [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 16:44:58 -0000 > From: "George, Wes E [NTK]" > I imagine your average consumer is going to be a lot angrier when we > tell them that the shiny new internet-connected device that they just > got for $winter_gift-giving_holiday 2010 is basically obsolete .. due to > a problem that we've known about for many years. The vendor of said > device shares some blame for being short-sighted, greedy or both .. but > I still don't know how IETF is going to answer the question as to why we > didn't require IPv6 sooner. The IETF is not the Protocol Police. All it can do is design stuff, put it out there, try and make sure everyone knows about it, and hope people use it. If there is more than a minute handful of people involved in the networking world who doesn't know what IPv6 is, I would be totally astonished. So the IETF has done what it can. If manufacturers aren't doing it (whether because they don't think their customers have any use for it, or whatever), that's their informed (to whatever degree) choice. People aren't children, you can't order them around like 5-year olds to eat their broccoli. Noel From remi.despres@free.fr Tue Jan 11 09:42:35 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89C7E3A6A5E; Tue, 11 Jan 2011 09:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkMjntnZDSt2; Tue, 11 Jan 2011 09:42:34 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by core3.amsl.com (Postfix) with ESMTP id A41B33A6A60; Tue, 11 Jan 2011 09:42:34 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2416.sfr.fr (SMTP Server) with ESMTP id 8A8CA70000A2; Tue, 11 Jan 2011 18:44:51 +0100 (CET) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2416.sfr.fr (SMTP Server) with ESMTP id 400A5700009D; Tue, 11 Jan 2011 18:44:51 +0100 (CET) X-SFR-UUID: 20110111174451262.400A5700009D@msfrf2416.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20110111164713.CA1956BE595@mercury.lcs.mit.edu> Date: Tue, 11 Jan 2011 18:44:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <28944986-243F-4C19-A998-4BCE3DED0496@free.fr> References: <20110111164713.CA1956BE595@mercury.lcs.mit.edu> To: Noel Chiappa X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org, int-area@ietf.org Subject: Re: [Int-area] [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 17:42:35 -0000 +1 What IETF must provide is specifications of what is meant by IPv6, = ICMPv6, SLAAC, IPsec, ... Then, vendors that claim they support any of these know what they are = committed to. But they remain free to decide what they support. RD Le 11 janv. 2011 =E0 17:47, Noel Chiappa a =E9crit : >> From: "George, Wes E [NTK]" >=20 >> I imagine your average consumer is going to be a lot angrier when we >> tell them that the shiny new internet-connected device that they just >> got for $winter_gift-giving_holiday 2010 is basically obsolete .. due = to >> a problem that we've known about for many years. The vendor of said >> device shares some blame for being short-sighted, greedy or both .. = but >> I still don't know how IETF is going to answer the question as to why = we >> didn't require IPv6 sooner. >=20 > The IETF is not the Protocol Police. All it can do is design stuff, = put it out > there, try and make sure everyone knows about it, and hope people use = it. If > there is more than a minute handful of people involved in the = networking world > who doesn't know what IPv6 is, I would be totally astonished. So the = IETF has > done what it can. >=20 > If manufacturers aren't doing it (whether because they don't think = their > customers have any use for it, or whatever), that's their informed (to > whatever degree) choice. People aren't children, you can't order them = around > like 5-year olds to eat their broccoli. >=20 > Noel > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Wesley.E.George@sprint.com Tue Jan 11 09:54:41 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 830713A681A; Tue, 11 Jan 2011 09:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.954 X-Spam-Level: X-Spam-Status: No, score=-4.954 tagged_above=-999 required=5 tests=[AWL=0.645, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsTskKG+d6nC; Tue, 11 Jan 2011 09:54:40 -0800 (PST) Received: from DB3EHSOBE003.bigfish.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by core3.amsl.com (Postfix) with ESMTP id DF3DF3A6A76; Tue, 11 Jan 2011 09:54:39 -0800 (PST) Received: from mail3-db3-R.bigfish.com (10.3.81.242) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.8; Tue, 11 Jan 2011 17:56:56 +0000 Received: from mail3-db3 (localhost.localdomain [127.0.0.1]) by mail3-db3-R.bigfish.com (Postfix) with ESMTP id 8EBAA290360; Tue, 11 Jan 2011 17:56:56 +0000 (UTC) X-SpamScore: -21 X-BigFish: VS-21(zz542N1432N9371P10d1Izz1202hzzz2fh2a8h668h34h) X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:plsasdm1.corp.sprint.com; RD:smtpls1.sprint.com; EFVD:NLI Received: from mail3-db3 (localhost.localdomain [127.0.0.1]) by mail3-db3 (MessageSwitch) id 1294768616220330_31571; Tue, 11 Jan 2011 17:56:56 +0000 (UTC) Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.248]) by mail3-db3.bigfish.com (Postfix) with ESMTP id 331AE18A804B; Tue, 11 Jan 2011 17:56:56 +0000 (UTC) Received: from plsasdm1.corp.sprint.com (144.230.168.25) by DB3EHSMHS005.bigfish.com (10.3.87.105) with Microsoft SMTP Server (TLS) id 14.1.225.8; Tue, 11 Jan 2011 17:56:53 +0000 Received: from PLSWEH02.ad.sprint.com (PLSWEH02.corp.sprint.com [144.226.242.131]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p0BHudjn028626 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Jan 2011 11:56:51 -0600 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PLSWEH02.ad.sprint.com ([2002:90e2:f283::90e2:f283]) with mapi id 14.01.0255.000; Tue, 11 Jan 2011 11:56:45 -0600 From: "George, Wes E [NTK]" To: Noel Chiappa , "int-area@ietf.org" , "v6ops@ietf.org" Thread-Topic: [Int-area] [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required Thread-Index: AQHLsa85dhvAbzlInEG5ONA6M5aa2ZPL/W5g Date: Tue, 11 Jan 2011 17:56:44 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E04C8CD@PLSWM12A.ad.sprint.com> References: <20110111164713.CA1956BE595@mercury.lcs.mit.edu> In-Reply-To: <20110111164713.CA1956BE595@mercury.lcs.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.53.23] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0088_01CBB18E.FCE1A5F0" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Subject: Re: [Int-area] [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 17:54:41 -0000 ------=_NextPart_000_0088_01CBB18E.FCE1A5F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu] > Sent: Tuesday, January 11, 2011 11:47 AM > > The IETF is not the Protocol Police. All it can do is design stuff, put > it out > there, try and make sure everyone knows about it, and hope people use > it. [WES] There's no enforcement being proposed here. It's a guideline just like anything else that IETF (or any of the myriad standards bodies that we might name) generates. However, plenty of companies cite RFCs and drafts as shorthand for the features and services that they want to have work on a device or network specification with the full expectation that they'll be updated as necessary to remain current. Updating them to reflect changes and evolution is part of what we do at IETF. Distilling this down, you're basically saying "you can lead a horse to water, but you can't make him drink." I'm merely recommending that we be a bit more forceful in our leadership to the water, instead of being neutral on the question of whether you should implement IPv6 on your device or software. > If there is more than a minute handful of people involved in the > networking world > who doesn't know what IPv6 is, I would be totally astonished. So the > IETF has > done what it can. [WES] The degree of IPv6 awareness varies vastly by area of focus. There are plenty of folks who refer to IETF standards or need to know about IPv6 that are not within the networking world (and its little bubble of IPv6 cognoscenti) per se. And even if the networking folks understand that it's necessary, sometimes things like "it's an IETF standard, we need to do it to comply with the standard" is enough to push a justification through the business folks who probably don't. > > If manufacturers aren't doing it (whether because they don't think > their > customers have any use for it, or whatever), that's their informed (to > whatever degree) choice. People aren't children, you can't order them > around > like 5-year olds to eat their broccoli. [WES] Yet we generate standards all day long with words like MUST that we expect the same manufacturers to follow to the letter. This argument can be made about any standard we generate! So is IETF's collective opinion relevant or not? I am under no illusion that adoption of this draft will *solve* the lack of IPv6 support in consumer electronics (or anywhere else), and I am fully aware that businesses will make their own decisions. That doesn't remove IETF from any responsibility to make a recommendation as to the current reality, which is that IPv4 *only* isn't going to keep working indefinitely, at least not in exactly the same way that it did before IANA exhaustion. I as an operator am asking for them to do so in order to make my job (trying to keep my customers' service functional) easier. This means trying to give me some help in the space where there are lots of devices that I don't have any control over, even if it's just a nudge in the right direction. Wes George ------=_NextPart_000_0088_01CBB18E.FCE1A5F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXHjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggarMIIFk6ADAgECAgo8 FVeJAAAAAZIPMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMDgwNTAxMTczNzE0WhcNMTEwNTAx MTczNzE0WjCBzzETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxEDAOBgNVBAsTB01hbmFn ZWQxGzAZBgNVBAsTElN0YW5kYXJkLVRlY2huaWNhbDEbMBkGA1UEAxMSV2VzbGV5IEUgR2Vvcmdl IElWMSkwJwYJKoZIhvcNAQkBFhpXZXNsZXkuRS5HZW9yZ2VAc3ByaW50LmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEArxfUh9TugEcsXY4OefFQTrGuaTRenLcZg0KCxZlTY7P9wMRCYd8p GJljwH1x4qn0Ejjyz+uX5UL8Biia13BSWRgiq7QYLKTZNKwEpBbeOf9lK/LrPsbFOgat/Zh/lPmx YzxeikU42X3KhyVSCmWdQhmWRu5kfUzsejaGWH9AyuUCAwEAAaOCA2EwggNdMAsGA1UdDwQEAwIF oDA2BgkqhkiG9w0BCQ8EKTAnMA0GCCqGSIb3DQMCAgE4MA0GCCqGSIb3DQMEAgE4MAcGBSsOAwIH MB0GA1UdDgQWBBTFSbrzJuajBSX9B63Y9r2TlgbU5DA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3 FQiBkugshNficv2LB4Xs/liCno8icYbjvkqEsfZAAgFkAgECMB8GA1UdIwQYMBaAFAGPJVAshjSb wX6QH9mINbU/rwuJMIIBXgYDVR0fBIIBVTCCAVEwggFNoIIBSaCCAUWGgeNsZGFwOi8vL0NOPVNw cmludCUyME5leHRlbCUyMEVudGVycHJpc2UlMjBJc3N1aW5nJTIwMSUyMEF1dGhvcml0eSxDTj1Q UEtJV0MwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1hZCxEQz1zcHJpbnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlv bkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYraHR0cDovL2NybC5z cHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNybIYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdDMDEvUFBLSVdDMDEuY3JsMIGFBggrBgEFBQcBAQR5MHcwNwYIKwYBBQUHMAKGK2h0 dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwPAYIKwYBBQUHMAKGMGh0 dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNydDApBgNVHSUEIjAg BggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AX DBV3ZWcwMjIxQGFkLnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQBYdUj2FTmOVS0X2fF+OYWXu9QoS6JWB8exD8kBPWVh28UilosoFwpVs2Ux K+V9NE1SC4QXDfwcjyMMV6WfXfy1foT6YAOcLt1z91ALCbTPlr1mazbAnOL6AzoTnq5V+TjvJvdN IYROS6PJC/YU5+w/NannnhC1zNFOtmxZZcrz50uRU8Q4mgITpxcnJXKUtKNaFTEhhtnP+hMVXYW0 eUyG7xjDTCyqsO5jcyI0IKJkNW1NXaKjHfmlAAiL5HVNl7cYL5uce6orHQQPMTSGRmTKCNjx7Yaz EHAorZUGmCTuihdhPDq+tOhGrIDE4XuiDxj+OVU6JXM5nsiKTjU968o4MYIDLTCCAykCAQEwgYYw eDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT 8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1 dGhvcml0eQIKPBVXiQAAAAGSDzAJBgUrDgMCGgUAoIIB/DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTAxMTExNzU2MzlaMCMGCSqGSIb3DQEJBDEWBBSNSUi3W6mp dSQnZnuB80n0F4sGIzBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG 9w0CBTCBlwYJKwYBBAGCNxAEMYGJMIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wgZkGCyqGSIb3DQEJ EAILMYGJoIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJpbnQx EjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNlIElz c3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wDQYJKoZIhvcNAQEBBQAEgYBc0oN3Ou55y+95 Zh5uoUTb95TlBtJ/tObVrcFroAkSDx7Xx+X0uakVSQAnVVsjdAd69XqtN7LcSpOUyTq40fGktS54 LMKU4DGyP/d5s+l/SbAkis+dWkHP8V5EfWmUahKZ+mNDfGAPea3xqdIg6gPO++pdULSuZNx5vZp+ Bl5wxwAAAAAAAA== ------=_NextPart_000_0088_01CBB18E.FCE1A5F0-- From brian.e.carpenter@gmail.com Tue Jan 11 12:28:45 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C32E728C2E2; Tue, 11 Jan 2011 12:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.984 X-Spam-Level: X-Spam-Status: No, score=-102.984 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLYCttBqbz8j; Tue, 11 Jan 2011 12:28:45 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 7C68828C113; Tue, 11 Jan 2011 12:28:44 -0800 (PST) Received: by ewy8 with SMTP id 8so9754615ewy.31 for ; Tue, 11 Jan 2011 12:31:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=L773aZhHUY+bkM1SdL9ryPibA1myaptS6kQNSHKk33I=; b=WjM/Y0i6TKev+urLRKYM9uQt9qUiWJ3d/EZi0v5EKP4k+2yRSDb83d7MYPUhone3Wg XAO5GY7GuGmGQ6Jc27xI67fPkd9nGb1LxQfkO8Oq0n1yTsnL6fRqiwauBV6+re4x7hg8 v0iGwBPEA7jbdHc3J3woQ1nMZUSfF0uyFB1LM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=tVhzXdRbhp5NGV+97z0Z9EiXiYNA9uk9JBue9XZnXMI07nYzXeE+qn1+gxtOVTN0Qh 4TamwzAngOkdFfqBeqRmbt2G7E7hxFXTuRcTGUP/a9HJlDKLG0ThcGG2dIPFvjqgTyoJ kds/kP9nMa+aZMTq0LZQUMb1i9bkaMHo7+amA= Received: by 10.223.81.70 with SMTP id w6mr71909fak.62.1294777861241; Tue, 11 Jan 2011 12:31:01 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id b7sm4671251faa.42.2011.01.11.12.30.57 (version=SSLv3 cipher=RC4-MD5); Tue, 11 Jan 2011 12:31:00 -0800 (PST) Message-ID: <4D2CBDFE.30902@gmail.com> Date: Wed, 12 Jan 2011 09:30:54 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= References: <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <20110110.224735.41641090.sthaug@nethelp.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, int-area@ietf.org, Steinar Haug Subject: Re: [Int-area] [v6ops] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 20:28:45 -0000 On 2011-01-12 00:17, R=C3=A9mi Despr=C3=A9s wrote: > Le 10 janv. 2011 =C3=A0 22:47, sthaug@nethelp.no a =C3=A9crit : >=20 >>>> UDP encapsulation of IPsec is a work around, specifically to get aro= und >>>> the problems of lack of IPv4 address transparency i.e. NAT. It isn't= an >>>> acceptable answer when NAT doesn't need to exist. >>> You're assuming that the only motivation to have NATs is address >>> exhaustion -- but IMO, it isn't. >> Provider independence is a huge motivation. >=20 > Agreed. >=20 > That's why, IMHO, it should be more useful to look for solutions that c= ombine provider independence with address transparency, than accepting wi= thout effort to sacrifice address transparency for provider independence.= Indeed; we already have one of those standardised, which also has the pro= perty of protecting BGP4 scalability: RFC 5533, RFC 5534 and RFC 5535. The LISP WG is standardising another solution with those properties, that doesn't even require the user site to operate multiple prefixes. Brian > Although I know some readers don't like my repeating that I worked on s= uch a solution, this is IMHO relevant to the point being discussed. > Ref: www.ietf.org/id/draft-despres-softwire-sam-01, in particular sec. = 3.3. > (As this draft is about to expire, I should work in some future on a re= vised version.)=20 >=20 > Regards, > RD >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From remi.despres@free.fr Wed Jan 12 02:16:39 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E4D73A6A12 for ; Wed, 12 Jan 2011 02:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.431 X-Spam-Level: X-Spam-Status: No, score=-1.431 tagged_above=-999 required=5 tests=[AWL=0.518, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KST5UZtnFheT for ; Wed, 12 Jan 2011 02:16:38 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by core3.amsl.com (Postfix) with ESMTP id 48E633A6A01 for ; Wed, 12 Jan 2011 02:16:38 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2203.sfr.fr (SMTP Server) with ESMTP id D89F370000BD; Wed, 12 Jan 2011 11:18:56 +0100 (CET) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2203.sfr.fr (SMTP Server) with ESMTP id 8003E70000AF; Wed, 12 Jan 2011 11:18:56 +0100 (CET) X-SFR-UUID: 20110112101856524.8003E70000AF@msfrf2203.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4D2CBDFE.30902@gmail.com> Date: Wed, 12 Jan 2011 11:18:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2342BA4A-F973-46AF-82C8-4E1C20CA8692@free.fr> References: <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <20110110.224735.41641090.sthaug@nethelp.no> <4D2CBDFE.30902@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1082) Cc: Internet Area Subject: [Int-area] e2e Address transparency - PI site routing - Multi-CPE multihoming X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 10:16:39 -0000 Brian, Here is a good opportunity to clarify an important point, on which I = hope we can converge. The problem I worked on is how to combine: - "e2e address transparency" (hosts know their own global addresses, and = use them) - "PI site routing" (e.g., in IPv6, ULA-only intra-site routing to = avoid renumbering problems) - "Multi-CPE Multihoming" (the most complete multihoming model). - "Per-site incremental deployment" (a site can use the solution = independently from what is done anywhere else). - LISP is off-scope because it doesn't permit per-site incremental = deployment. This problem has two complementary sub-problems: . "Source-address selection" (how does a host select a particular e2e = source address for an outgoing packet)? . "Outgoing-CPE control" (the source address being selected, how to = ensure that the packet goes via the right CPE)? - Solutions for "source-address selection" do exist (SHIM6, SCTP, = draft-ietf-v6ops-multihoming-without-nat66). - AFAIK, a solution for "outgoing-CPE control" in the above context = still has to be specified=20 The key I briefly described for this "outgoing-CPE selection", in sec = 3.3 of draft-despres-softwire-sam-01), is that: - For customer-site traversal, hosts encapsulate e2e packets in local = packets (IPv6/IPv6). - Hosts address these local packets to the right CPE's by using a = correspondence list between local CPE addresses and global IPv6 = prefixes. Unless this is proved to be useless, I plan to pursue in this direction, = with whoever is interested in making positive contributions.=20 Best regards, RD Le 11 janv. 2011 =E0 21:30, Brian E Carpenter a =E9crit : >> ... it should be more useful to look for solutions that combine = provider independence with address transparency, than accepting without = effort to sacrifice address transparency for provider independence. >=20 > Indeed; we already have one of those standardised, which also has the = property > of protecting BGP4 scalability: RFC 5533, RFC 5534 and RFC 5535. (RFC 5533 and RFC 5534 are about SHIM6, and RFC 5535 is about securing = multihoming address sets. None of these addresses the "outgoing-CPE = control" issue).=20 From alberto@it.uc3m.es Wed Jan 12 02:50:10 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D90433A6A0B for ; Wed, 12 Jan 2011 02:50:10 -0800 (PST) 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.001, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gue5HQemTkG2 for ; Wed, 12 Jan 2011 02:50:09 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 418373A69F8 for ; Wed, 12 Jan 2011 02:50:09 -0800 (PST) X-uc3m-safe: yes Received: from BOMBO (bombo.it.uc3m.es [163.117.139.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 99916717620; Wed, 12 Jan 2011 11:52:22 +0100 (CET) From: =?iso-8859-1?Q?Alberto_Garc=EDa?= To: =?iso-8859-1?Q?'R=E9mi_Despr=E9s'?= , "'Brian E Carpenter'" References: <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <20110110.224735.41641090.sthaug@nethelp.no> <4D2CBDFE.30902@gmail.com> <2342BA4A-F973-46AF-82C8-4E1C20CA8692@free.fr> In-Reply-To: <2342BA4A-F973-46AF-82C8-4E1C20CA8692@free.fr> Date: Wed, 12 Jan 2011 11:52:27 +0100 Message-ID: <00b301cbb246$cda664c0$68f32e40$@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMhn4q8uYHvnBDp9zrife7XVQz1mAKusRbRAlZMqQEBocqoAAHlQTP7Akebk6MB9DzhhZC7CnzA Content-Language: es X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17888.006 Cc: 'Internet Area' Subject: Re: [Int-area] e2e Address transparency - PI site routing - Multi-CPE multihoming X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 10:50:10 -0000 Hi, The requirements you state remind me the Proxy Shim6 proposal (http://tools.ietf.org/id/draft-bagnulo-pshim6-02.txt). There is also a paper on the subject at http://e-archivo.uc3m.es/bitstream/10016/2846/1/P-SHIM6.pdf The abstract of the paper says: "The P-SHIM6 architecture provides ISP independence to IPv6 sites = without compromising scalability. This architecture is based on a middle-box, = the P-SHIM6, which manages the SHIM6 protocol exchange on behalf of the = nodes of a site, which are configured with provider independent addresses. = Incoming and outgoing packets are processed by the P-SHIM6 box, which can assign different locators to a given communication, either when it is started, = or dynamically after the communication has been established. As a = consequence, changes required for provider portability are minimized, and = fine-grained Traffic Engineering can be enforced at the P-SHIM6 box, in addition to = the fault tolerance support provided by SHIM6." Regards, Alberto | -----Mensaje original----- | De: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] En | nombre de R=E9mi Despr=E9s | Enviado el: mi=E9rcoles, 12 de enero de 2011 11:19 | Para: Brian E Carpenter | CC: Internet Area | Asunto: [Int-area] e2e Address transparency - PI site routing - = Multi-CPE | multihoming | =20 | Brian, | =20 | Here is a good opportunity to clarify an important point, on which I = hope we | can converge. | =20 | The problem I worked on is how to combine: | - "e2e address transparency" (hosts know their own global addresses, = and | use them) | - "PI site routing" (e.g., in IPv6, ULA-only intra-site routing to = avoid | renumbering problems) | - "Multi-CPE Multihoming" (the most complete multihoming model). | - "Per-site incremental deployment" (a site can use the solution | independently from what is done anywhere else). | =20 | - LISP is off-scope because it doesn't permit per-site incremental | deployment. | =20 | This problem has two complementary sub-problems: | . "Source-address selection" (how does a host select a particular e2e source | address for an outgoing packet)? | . "Outgoing-CPE control" (the source address being selected, how to ensure | that the packet goes via the right CPE)? | - Solutions for "source-address selection" do exist (SHIM6, SCTP, draft-ietf- | v6ops-multihoming-without-nat66). | - AFAIK, a solution for "outgoing-CPE control" in the above context = still has | to be specified | =20 | The key I briefly described for this "outgoing-CPE selection", in sec = 3.3 of | draft-despres-softwire-sam-01), is that: | - For customer-site traversal, hosts encapsulate e2e packets in local packets | (IPv6/IPv6). | - Hosts address these local packets to the right CPE's by using a | correspondence list between local CPE addresses and global IPv6 = prefixes. | =20 | Unless this is proved to be useless, I plan to pursue in this = direction, with | whoever is interested in making positive contributions. | =20 | Best regards, | RD | =20 | =20 | =20 | Le 11 janv. 2011 =E0 21:30, Brian E Carpenter a =E9crit : | >> ... it should be more useful to look for solutions that combine provider | independence with address transparency, than accepting without effort = to | sacrifice address transparency for provider independence. | > | > Indeed; we already have one of those standardised, which also has = the | > property of protecting BGP4 scalability: RFC 5533, RFC 5534 and RFC 5535. | =20 | (RFC 5533 and RFC 5534 are about SHIM6, and RFC 5535 is about = securing | multihoming address sets. None of these addresses the "outgoing-CPE | control" issue). | =20 | =20 | _______________________________________________ | Int-area mailing list | Int-area@ietf.org | https://www.ietf.org/mailman/listinfo/int-area From remi.despres@free.fr Wed Jan 12 08:18:26 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A15228C131 for ; Wed, 12 Jan 2011 08:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJ5eJX8IwEYY for ; Wed, 12 Jan 2011 08:18:24 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by core3.amsl.com (Postfix) with ESMTP id 5CC213A6A4B for ; Wed, 12 Jan 2011 08:18:24 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2419.sfr.fr (SMTP Server) with ESMTP id 86A6A7000497; Wed, 12 Jan 2011 17:20:43 +0100 (CET) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2419.sfr.fr (SMTP Server) with ESMTP id 339317000480; Wed, 12 Jan 2011 17:20:43 +0100 (CET) X-SFR-UUID: 20110112162043211.339317000480@msfrf2419.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <00b301cbb246$cda664c0$68f32e40$@it.uc3m.es> Date: Wed, 12 Jan 2011 17:20:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <48F6E98D-0626-4498-8C62-9E51FA1FA637@free.fr> References: <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <20110110.224735.41641090.sthaug@nethelp.no> <4D2CBDFE.30902@gmail.com> <2342BA4A-F973-46AF-82C8-4E1C20CA8692@free.fr> <00b301cbb246$cda664c0$68f32e40$@it.uc3m.es> To: =?iso-8859-1?Q?Alberto_Garc=EDa?= X-Mailer: Apple Mail (2.1082) Cc: 'Internet Area' Subject: Re: [Int-area] e2e Address transparency - PI site routing - Multi-CPE multihoming X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 16:18:26 -0000 Alberto, Thank you for this interesting reference I hadn't noticed. It did share the objective of combining of "PI site routing" with = "Multi-CPE multihoming", but was NOT concerned with "e2e address = transparency". Besides: =20 - It needed a middle-box between all hosts and CPE's - It needed a new DNS RR type. Both have to be avoided in the solution I look for. Kind regards, RD Le 12 janv. 2011 =E0 11:52, Alberto Garc=EDa a =E9crit : > Hi, > The requirements you state remind me the Proxy Shim6 proposal > (http://tools.ietf.org/id/draft-bagnulo-pshim6-02.txt). There is also = a > paper on the subject at > http://e-archivo.uc3m.es/bitstream/10016/2846/1/P-SHIM6.pdf > The abstract of the paper says: > "The P-SHIM6 architecture provides ISP independence to IPv6 sites = without > compromising scalability. > This architecture is based on a middle-box, the > P-SHIM6, which manages the SHIM6 protocol exchange on behalf of the = nodes of > a site, which are configured with provider independent addresses. = Incoming > and outgoing packets are processed by the P-SHIM6 box, which can = assign > different locators to a given communication, either when it is = started, or > dynamically after the communication has been established. As a = consequence, > changes required for provider portability are minimized, and = fine-grained > Traffic Engineering can be enforced at the P-SHIM6 box, in addition to = the > fault tolerance support provided by SHIM6." >=20 > Regards, > Alberto >=20 > | -----Mensaje original----- > | De: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] En > | nombre de R=E9mi Despr=E9s > | Enviado el: mi=E9rcoles, 12 de enero de 2011 11:19 > | Para: Brian E Carpenter > | CC: Internet Area > | Asunto: [Int-area] e2e Address transparency - PI site routing - = Multi-CPE > | multihoming > | =20 > | Brian, > | =20 > | Here is a good opportunity to clarify an important point, on which = I hope > we > | can converge. > | =20 > | The problem I worked on is how to combine: > | - "e2e address transparency" (hosts know their own global = addresses, and > | use them) > | - "PI site routing" (e.g., in IPv6, ULA-only intra-site routing to = avoid > | renumbering problems) > | - "Multi-CPE Multihoming" (the most complete multihoming model). > | - "Per-site incremental deployment" (a site can use the solution > | independently from what is done anywhere else). > | =20 > | - LISP is off-scope because it doesn't permit per-site incremental > | deployment. > | =20 > | This problem has two complementary sub-problems: > | . "Source-address selection" (how does a host select a particular = e2e > source > | address for an outgoing packet)? > | . "Outgoing-CPE control" (the source address being selected, how to > ensure > | that the packet goes via the right CPE)? > | - Solutions for "source-address selection" do exist (SHIM6, SCTP, > draft-ietf- > | v6ops-multihoming-without-nat66). > | - AFAIK, a solution for "outgoing-CPE control" in the above context = still > has > | to be specified > | =20 > | The key I briefly described for this "outgoing-CPE selection", in = sec 3.3 > of > | draft-despres-softwire-sam-01), is that: > | - For customer-site traversal, hosts encapsulate e2e packets in = local > packets > | (IPv6/IPv6). > | - Hosts address these local packets to the right CPE's by using a > | correspondence list between local CPE addresses and global IPv6 = prefixes. > | =20 > | Unless this is proved to be useless, I plan to pursue in this = direction, > with > | whoever is interested in making positive contributions. > | =20 > | Best regards, > | RD > | =20 > | =20 > | =20 > | Le 11 janv. 2011 =E0 21:30, Brian E Carpenter a =E9crit : > | >> ... it should be more useful to look for solutions that combine > provider > | independence with address transparency, than accepting without = effort to > | sacrifice address transparency for provider independence. > | > > | > Indeed; we already have one of those standardised, which also has = the > | > property of protecting BGP4 scalability: RFC 5533, RFC 5534 and = RFC > 5535. > | =20 > | (RFC 5533 and RFC 5534 are about SHIM6, and RFC 5535 is about = securing > | multihoming address sets. None of these addresses the "outgoing-CPE > | control" issue). > | =20 > | =20 > | _______________________________________________ > | Int-area mailing list > | Int-area@ietf.org > | https://www.ietf.org/mailman/listinfo/int-area >=20 From brian.e.carpenter@gmail.com Wed Jan 12 13:22:05 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35EE23A67AA for ; Wed, 12 Jan 2011 13:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.283 X-Spam-Level: X-Spam-Status: No, score=-103.283 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErJT7PFO6i7y for ; Wed, 12 Jan 2011 13:22:03 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 612063A6774 for ; Wed, 12 Jan 2011 13:22:03 -0800 (PST) Received: by fxm9 with SMTP id 9so1078682fxm.31 for ; Wed, 12 Jan 2011 13:24:23 -0800 (PST) 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:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GWz46clnIm7x9ZYnH8emG7ngrclEbBGOOHLXOfC7W2w=; b=UJTaW/jlzt5SR5y8WX+RtLmqKISl52vT9FR9xMpktEHXRjMJ+RIL8HX0x7qz0dGVmH 5ZEEWfUUalQA9ULmKgRFLkcrw5cWVr9qg+XRompLPrMV8MgUhh/SQSUwa2FnnLri5Szn B5X9KbeCK3oMkt6LjMsghtBjufO39FvpkHDp8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=lfFZ1Xlx8ZcMhoVDQ+ysTTvsVc7fbjXVnlGOfPFb7UgVSYFQJv+lHSb3dSBJFtbQom W+AG4hxWMpO8ziJ0QY3eLC6EVrCB+dLwad4SJdB3rDsTrAVIJ9T2Y79hNjJZgxHlev3S hHsnqwDJJRRm6UQM6+pADtTEYWiHpNYsttjW8= Received: by 10.223.110.77 with SMTP id m13mr1509714fap.86.1294867463378; Wed, 12 Jan 2011 13:24:23 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 21sm406992fav.17.2011.01.12.13.24.18 (version=SSLv3 cipher=RC4-MD5); Wed, 12 Jan 2011 13:24:21 -0800 (PST) Message-ID: <4D2E1BE9.6010000@gmail.com> Date: Thu, 13 Jan 2011 10:23:53 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= References: <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <20110110.224735.41641090.sthaug@nethelp.no> <4D2CBDFE.30902@gmail.com> <2342BA4A-F973-46AF-82C8-4E1C20CA8692@free.fr> <00b301cbb246$cda664c0$68f32e40$@it.uc3m.es> <48F6E98D-0626-4498-8C62-9E51FA1FA637@free.fr> In-Reply-To: <48F6E98D-0626-4498-8C62-9E51FA1FA637@free.fr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: 'Internet Area' Subject: Re: [Int-area] e2e Address transparency - PI site routing - Multi-CPE multihoming X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 21:22:05 -0000 I hate to have to say this, but the reason that NAT44 became popular for quite a number of large (typically multinational) enterprise networks was as the easiest solution to the multi-exit problem. These companies didn't regard NAT as a security feature; they had firewalls for that. And they didn't *want* to lose address transparency; that was considered an acceptable side-effect of gaining a solution to the multi-exit multi-homing problem. Also look in your time machine for "Ingress filtering compatibility for IPv6 multihomed sites" draft-huitema-multi6-ingress-filtering-00 Regards Brian Carpenter On 2011-01-13 05:20, R=C3=A9mi Despr=C3=A9s wrote: > Alberto, >=20 > Thank you for this interesting reference I hadn't noticed. >=20 > It did share the objective of combining of "PI site routing" with "Mult= i-CPE multihoming", but was NOT concerned with "e2e address transparency"= =2E >=20 > Besides: =20 > - It needed a middle-box between all hosts and CPE's > - It needed a new DNS RR type. > Both have to be avoided in the solution I look for. >=20 > Kind regards, > RD >=20 >=20 >=20 > Le 12 janv. 2011 =C3=A0 11:52, Alberto Garc=C3=ADa a =C3=A9crit : >=20 >> Hi, >> The requirements you state remind me the Proxy Shim6 proposal >> (http://tools.ietf.org/id/draft-bagnulo-pshim6-02.txt). There is also = a >> paper on the subject at >> http://e-archivo.uc3m.es/bitstream/10016/2846/1/P-SHIM6.pdf >> The abstract of the paper says: >> "The P-SHIM6 architecture provides ISP independence to IPv6 sites with= out >> compromising scalability. >=20 >> This architecture is based on a middle-box, the >> P-SHIM6, which manages the SHIM6 protocol exchange on behalf of the no= des of >> a site, which are configured with provider independent addresses. Inc= oming >> and outgoing packets are processed by the P-SHIM6 box, which can assig= n >> different locators to a given communication, either when it is started= , or >> dynamically after the communication has been established. As a consequ= ence, >> changes required for provider portability are minimized, and fine-grai= ned >> Traffic Engineering can be enforced at the P-SHIM6 box, in addition to= the >> fault tolerance support provided by SHIM6." >> >> Regards, >> Alberto >> >> | -----Mensaje original----- >> | De: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] En= >> | nombre de R=C3=A9mi Despr=C3=A9s >> | Enviado el: mi=C3=A9rcoles, 12 de enero de 2011 11:19 >> | Para: Brian E Carpenter >> | CC: Internet Area >> | Asunto: [Int-area] e2e Address transparency - PI site routing - Mul= ti-CPE >> | multihoming >> | =20 >> | Brian, >> | =20 >> | Here is a good opportunity to clarify an important point, on which = I hope >> we >> | can converge. >> | =20 >> | The problem I worked on is how to combine: >> | - "e2e address transparency" (hosts know their own global addresses= , and >> | use them) >> | - "PI site routing" (e.g., in IPv6, ULA-only intra-site routing to= avoid >> | renumbering problems) >> | - "Multi-CPE Multihoming" (the most complete multihoming model). >> | - "Per-site incremental deployment" (a site can use the solution >> | independently from what is done anywhere else). >> | =20 >> | - LISP is off-scope because it doesn't permit per-site incremental >> | deployment. >> | =20 >> | This problem has two complementary sub-problems: >> | . "Source-address selection" (how does a host select a particular e= 2e >> source >> | address for an outgoing packet)? >> | . "Outgoing-CPE control" (the source address being selected, how to= >> ensure >> | that the packet goes via the right CPE)? >> | - Solutions for "source-address selection" do exist (SHIM6, SCTP, >> draft-ietf- >> | v6ops-multihoming-without-nat66). >> | - AFAIK, a solution for "outgoing-CPE control" in the above context= still >> has >> | to be specified >> | =20 >> | The key I briefly described for this "outgoing-CPE selection", in s= ec 3.3 >> of >> | draft-despres-softwire-sam-01), is that: >> | - For customer-site traversal, hosts encapsulate e2e packets in loc= al >> packets >> | (IPv6/IPv6). >> | - Hosts address these local packets to the right CPE's by using a >> | correspondence list between local CPE addresses and global IPv6 pre= fixes. >> | =20 >> | Unless this is proved to be useless, I plan to pursue in this direc= tion, >> with >> | whoever is interested in making positive contributions. >> | =20 >> | Best regards, >> | RD >> | =20 >> | =20 >> | =20 >> | Le 11 janv. 2011 =C3=A0 21:30, Brian E Carpenter a =C3=A9crit : >> | >> ... it should be more useful to look for solutions that combine >> provider >> | independence with address transparency, than accepting without effo= rt to >> | sacrifice address transparency for provider independence. >> | > >> | > Indeed; we already have one of those standardised, which also has= the >> | > property of protecting BGP4 scalability: RFC 5533, RFC 5534 and R= FC >> 5535. >> | =20 >> | (RFC 5533 and RFC 5534 are about SHIM6, and RFC 5535 is about secur= ing >> | multihoming address sets. None of these addresses the "outgoing-CPE= >> | control" issue). >> | =20 >> | =20 >> | _______________________________________________ >> | Int-area mailing list >> | Int-area@ietf.org >> | https://www.ietf.org/mailman/listinfo/int-area >> >=20 >=20 >=20 From remi.despres@free.fr Thu Jan 13 00:39:22 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15E733A69B2 for ; Thu, 13 Jan 2011 00:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.433 X-Spam-Level: X-Spam-Status: No, score=-1.433 tagged_above=-999 required=5 tests=[AWL=0.516, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWJZCJvl46wB for ; Thu, 13 Jan 2011 00:39:20 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by core3.amsl.com (Postfix) with ESMTP id 2BB903A69AE for ; Thu, 13 Jan 2011 00:39:20 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2216.sfr.fr (SMTP Server) with ESMTP id 3949A7000097; Thu, 13 Jan 2011 09:41:41 +0100 (CET) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2216.sfr.fr (SMTP Server) with ESMTP id A85CA700008F; Thu, 13 Jan 2011 09:41:40 +0100 (CET) X-SFR-UUID: 20110113084140689.A85CA700008F@msfrf2216.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4D2E1BE9.6010000@gmail.com> Date: Thu, 13 Jan 2011 09:41:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <31727DDE-AC4A-41E9-89D2-2941B3AE9C21@free.fr> References: <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <20110110.224735.41641090.sthaug@nethelp.no> <4D2CBDFE.30902@gmail.com> <2342BA4A-F973-46AF-82C8-4E1C20CA8692@free.fr> <00b301cbb246$cda664c0$68f32e40$@it.uc3m.es> <48F6E98D-0626-4498-8C62-9E51FA1FA637@free.fr> <4D2E1BE9.6010000@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1082) Cc: 'Internet Area' Subject: Re: [Int-area] e2e Address transparency - PI site routing - Multi-CPE multihoming X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 08:39:22 -0000 Thank you, Brian, for this other interesting reference I hadn't noticed. Le 12 janv. 2011 =E0 22:23, Brian E Carpenter a =E9crit : > I hate to have to say this, but the reason that NAT44 became popular = for > quite a number of large (typically multinational) enterprise networks > was as the easiest solution to the multi-exit problem. I agree, but, in my understanding: - only for outgoing connectivity - without TCP continuity in case of failure an ISP access being used. =3D> incompatible with SHIM6 or SCTP, whose functions include incoming = connectivity and TCP continuity. > These companies > didn't regard NAT as a security feature; they had firewalls for that. > And they didn't *want* to lose address transparency; that was = considered > an acceptable side-effect of gaining a solution to the multi-exit > multi-homing problem. That's why, IMHO, an IPv6 solution that avoids this side-effect is worth = working on. Regards, RD=20 >=20 > Also look in your time machine for > "Ingress filtering compatibility for IPv6 multihomed sites" > draft-huitema-multi6-ingress-filtering-00 >=20 > Regards > Brian Carpenter >=20 > On 2011-01-13 05:20, R=E9mi Despr=E9s wrote: >> Alberto, >>=20 >> Thank you for this interesting reference I hadn't noticed. >>=20 >> It did share the objective of combining of "PI site routing" with = "Multi-CPE multihoming", but was NOT concerned with "e2e address = transparency". >>=20 >> Besides: =20 >> - It needed a middle-box between all hosts and CPE's >> - It needed a new DNS RR type. >> Both have to be avoided in the solution I look for. >>=20 >> Kind regards, >> RD >>=20 >>=20 >>=20 >> Le 12 janv. 2011 =E0 11:52, Alberto Garc=EDa a =E9crit : >>=20 >>> Hi, >>> The requirements you state remind me the Proxy Shim6 proposal >>> (http://tools.ietf.org/id/draft-bagnulo-pshim6-02.txt). There is = also a >>> paper on the subject at >>> http://e-archivo.uc3m.es/bitstream/10016/2846/1/P-SHIM6.pdf >>> The abstract of the paper says: >>> "The P-SHIM6 architecture provides ISP independence to IPv6 sites = without >>> compromising scalability. >>=20 >>> This architecture is based on a middle-box, the >>> P-SHIM6, which manages the SHIM6 protocol exchange on behalf of the = nodes of >>> a site, which are configured with provider independent addresses. = Incoming >>> and outgoing packets are processed by the P-SHIM6 box, which can = assign >>> different locators to a given communication, either when it is = started, or >>> dynamically after the communication has been established. As a = consequence, >>> changes required for provider portability are minimized, and = fine-grained >>> Traffic Engineering can be enforced at the P-SHIM6 box, in addition = to the >>> fault tolerance support provided by SHIM6." >>>=20 >>> Regards, >>> Alberto >>>=20 >>> | -----Mensaje original----- >>> | De: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] = En >>> | nombre de R=E9mi Despr=E9s >>> | Enviado el: mi=E9rcoles, 12 de enero de 2011 11:19 >>> | Para: Brian E Carpenter >>> | CC: Internet Area >>> | Asunto: [Int-area] e2e Address transparency - PI site routing - = Multi-CPE >>> | multihoming >>> | =20 >>> | Brian, >>> | =20 >>> | Here is a good opportunity to clarify an important point, on = which I hope >>> we >>> | can converge. >>> | =20 >>> | The problem I worked on is how to combine: >>> | - "e2e address transparency" (hosts know their own global = addresses, and >>> | use them) >>> | - "PI site routing" (e.g., in IPv6, ULA-only intra-site routing = to avoid >>> | renumbering problems) >>> | - "Multi-CPE Multihoming" (the most complete multihoming model). >>> | - "Per-site incremental deployment" (a site can use the solution >>> | independently from what is done anywhere else). >>> | =20 >>> | - LISP is off-scope because it doesn't permit per-site = incremental >>> | deployment. >>> | =20 >>> | This problem has two complementary sub-problems: >>> | . "Source-address selection" (how does a host select a particular = e2e >>> source >>> | address for an outgoing packet)? >>> | . "Outgoing-CPE control" (the source address being selected, how = to >>> ensure >>> | that the packet goes via the right CPE)? >>> | - Solutions for "source-address selection" do exist (SHIM6, SCTP, >>> draft-ietf- >>> | v6ops-multihoming-without-nat66). >>> | - AFAIK, a solution for "outgoing-CPE control" in the above = context still >>> has >>> | to be specified >>> | =20 >>> | The key I briefly described for this "outgoing-CPE selection", in = sec 3.3 >>> of >>> | draft-despres-softwire-sam-01), is that: >>> | - For customer-site traversal, hosts encapsulate e2e packets in = local >>> packets >>> | (IPv6/IPv6). >>> | - Hosts address these local packets to the right CPE's by using a >>> | correspondence list between local CPE addresses and global IPv6 = prefixes. >>> | =20 >>> | Unless this is proved to be useless, I plan to pursue in this = direction, >>> with >>> | whoever is interested in making positive contributions. >>> | =20 >>> | Best regards, >>> | RD >>> | =20 >>> | =20 >>> | =20 >>> | Le 11 janv. 2011 =E0 21:30, Brian E Carpenter a =E9crit : >>> | >> ... it should be more useful to look for solutions that = combine >>> provider >>> | independence with address transparency, than accepting without = effort to >>> | sacrifice address transparency for provider independence. >>> | > >>> | > Indeed; we already have one of those standardised, which also = has the >>> | > property of protecting BGP4 scalability: RFC 5533, RFC 5534 and = RFC >>> 5535. >>> | =20 >>> | (RFC 5533 and RFC 5534 are about SHIM6, and RFC 5535 is about = securing >>> | multihoming address sets. None of these addresses the = "outgoing-CPE >>> | control" issue). >>> | =20 >>> | =20 >>> | _______________________________________________ >>> | Int-area mailing list >>> | Int-area@ietf.org >>> | https://www.ietf.org/mailman/listinfo/int-area >>>=20 >>=20 >>=20 >>=20 >=20 From lear@cisco.com Thu Jan 13 01:16:18 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B6BA3A69EF for ; Thu, 13 Jan 2011 01:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.042 X-Spam-Level: X-Spam-Status: No, score=-110.042 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0FgkS7Lelmz for ; Thu, 13 Jan 2011 01:16:18 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id AE6EF3A69EA for ; Thu, 13 Jan 2011 01:16:17 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEEABdSLk2Q/khLgWdsb2JhbACECKA+FQEBFiIko1mKVY4UgSGDN3QEixA Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 13 Jan 2011 09:18:39 +0000 Received: from dhcp-10-55-87-53.cisco.com (dhcp-10-55-87-53.cisco.com [10.55.87.53]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p0D9IcYa019265; Thu, 13 Jan 2011 09:18:39 GMT Message-ID: <4D2EC373.3090906@cisco.com> Date: Thu, 13 Jan 2011 10:18:43 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= References: <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <20110110.224735.41641090.sthaug@nethelp.no> <4D2CBDFE.30902@gmail.com> <2342BA4A-F973-46AF-82C8-4E1C20CA8692@free.fr> In-Reply-To: <2342BA4A-F973-46AF-82C8-4E1C20CA8692@free.fr> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Internet Area Subject: Re: [Int-area] e2e Address transparency - PI site routing - Multi-CPE multihoming X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 09:16:18 -0000 On 1/12/11 11:18 AM, Rémi Després wrote: > - LISP is off-scope because it doesn't permit per-site incremental deployment. Really?! I think you ought to tell that to the sites that deployed it. From remi.despres@free.fr Thu Jan 13 02:18:50 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BA093A6B72 for ; Thu, 13 Jan 2011 02:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.693 X-Spam-Level: X-Spam-Status: No, score=-0.693 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_05=-1.11, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kb+eBLC8fqia for ; Thu, 13 Jan 2011 02:18:49 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by core3.amsl.com (Postfix) with ESMTP id 4DE3F3A6B70 for ; Thu, 13 Jan 2011 02:18:49 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2404.sfr.fr (SMTP Server) with ESMTP id 7D0D97000091; Thu, 13 Jan 2011 11:21:10 +0100 (CET) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2404.sfr.fr (SMTP Server) with ESMTP id 4565A7000088; Thu, 13 Jan 2011 11:21:09 +0100 (CET) X-SFR-UUID: 20110113102110284.4565A7000088@msfrf2404.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4D2EC373.3090906@cisco.com> Date: Thu, 13 Jan 2011 11:21:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <20110110.224735.41641090.sthaug@nethelp.no> <4D2CBDFE.30902@gmail.com> <2342BA4A-F973-46AF-82C8-4E1C20CA8692@free.fr> <4D2EC373.3090906@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.1082) Cc: Internet Area Subject: Re: [Int-area] e2e Address transparency - PI site routing - Multi-CPE multihoming X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 10:18:50 -0000 Le 13 janv. 2011 =E0 10:18, Eliot Lear a =E9crit : > On 1/12/11 11:18 AM, R=E9mi Despr=E9s wrote: >> - LISP is off-scope because it doesn't permit per-site incremental = deployment. >=20 > Really?! I think you ought to tell that to the sites that deployed = it. Let me be more precise on what I meant: I know that "incremental deployability" is among LISP goals. But the one I called "per-site", is such that a SINGLE customer site = that uses the solution has immediately its benefits, independently of = what others do. For this, tunnels of the approach I propose are *within* customer sites, = while those of LISP are across the Internet core, and need coordination = across it.=20 LISP benefits exist between two sites ONLY if both have LISP-capable = tunnel routers on their paths to the Internet core. With this clarification, do we understand each other? Regards, RD=20 From Fred.L.Templin@boeing.com Thu Jan 13 08:58:04 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A4BE3A6BB9 for ; Thu, 13 Jan 2011 08:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.32 X-Spam-Level: X-Spam-Status: No, score=-6.32 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17xK3Q6KxBFB for ; Thu, 13 Jan 2011 08:58:03 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 60CF43A6B15 for ; Thu, 13 Jan 2011 08:58:03 -0800 (PST) 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 p0DH0NUO029846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Jan 2011 11:00:23 -0600 (CST) 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 p0DH0LJR026486; Thu, 13 Jan 2011 11:00:21 -0600 (CST) Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p0DH0Elb025755 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 13 Jan 2011 11:00:18 -0600 (CST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Thu, 13 Jan 2011 09:00:16 -0800 From: "Templin, Fred L" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , Eliot Lear Date: Thu, 13 Jan 2011 09:00:15 -0800 Thread-Topic: [Int-area] e2e Address transparency - PI site routing -Multi-CPE multihoming Thread-Index: AcuzC5xjecPolGDmT4WCsNzMKectiAAN0dig Message-ID: References: <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nose nse.org> <4D2B711F.9000705@gont.com.ar> <20110110.224735.41641090.sthaug@ne thelp.no> <4D2CBDFE.30902@gm ail.com><2342BA4A-F973-46AF-82C8-4E1C20CA8692@free.fr><4D2EC373.3090906@cisco.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Internet Area Subject: Re: [Int-area] e2e Address transparency - PI site routing -Multi-CPE multihoming X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 16:58:04 -0000 I haven't been following this closely, but it seems that IRON should also be included in the discussion. It is IMHO better than LISP in many ways, and provides benefits whether both sites are IRON-capable or only one site is IRON-capable. 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 R=E9mi Despr=E9s > Sent: Thursday, January 13, 2011 2:21 AM > To: Eliot Lear > Cc: Internet Area > Subject: Re: [Int-area] e2e Address transparency - PI site=20 > routing -Multi-CPE multihoming >=20 >=20 > Le 13 janv. 2011 =E0 10:18, Eliot Lear a =E9crit : > > On 1/12/11 11:18 AM, R=E9mi Despr=E9s wrote: > >> - LISP is off-scope because it doesn't permit per-site=20 > incremental deployment. > >=20 > > Really?! I think you ought to tell that to the sites that=20 > deployed it. >=20 > Let me be more precise on what I meant: >=20 > I know that "incremental deployability" is among LISP goals. > But the one I called "per-site", is such that a SINGLE=20 > customer site that uses the solution has immediately its=20 > benefits, independently of what others do. >=20 > For this, tunnels of the approach I propose are *within*=20 > customer sites, while those of LISP are across the Internet=20 > core, and need coordination across it.=20 > LISP benefits exist between two sites ONLY if both have=20 > LISP-capable tunnel routers on their paths to the Internet core. >=20 > With this clarification, do we understand each other? >=20 > Regards, > RD=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > = From lee.howard@twcable.com Mon Jan 10 16:57:22 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8348A3A6835; Mon, 10 Jan 2011 16:57:22 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5SLpD16dV3k; Mon, 10 Jan 2011 16:57:20 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by core3.amsl.com (Postfix) with ESMTP id 04C763A67D6; Mon, 10 Jan 2011 16:57:19 -0800 (PST) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.60,303,1291611600"; d="scan'208";a="165994861" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 10 Jan 2011 19:59:46 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Mon, 10 Jan 2011 19:59:34 -0500 From: "Howard, Lee" To: Mark Smith , "George, Wes E [NTK]" Date: Mon, 10 Jan 2011 19:59:33 -0500 Thread-Topic: [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required Thread-Index: AcuxC3/rsWoU8AoNQcqSpDOWTI/8EAAHejXg Message-ID: References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <20110111074511.022d29bf@opy.nosense.org> In-Reply-To: <20110111074511.022d29bf@opy.nosense.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 13 Jan 2011 09:42:18 -0800 Cc: "v6ops@ietf.org" , "int-area@ietf.org" , Christopher LILJENSTOLPE Subject: Re: [Int-area] [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 00:57:23 -0000 > -----Original Message----- > From: Mark Smith [mailto:ipng@69706e6720323030352d30312d31340a.nosense.or= g] > Sent: Monday, January 10, 2011 4:15 PM > I don't think I really agree with the root cause. IPv6 doesn't exist in > equipment because customers, or representatives of customers (e.g ISPs > for CPE) haven't made it a "must have", and refused to buy the equipment > when it doesn't support IPv6.=20 What about ISPs who don't buy CPE? =20 Retail stores in the U.S. make a lot of money selling gateways to retail customers. Consumers get more choice of what gateway they want to buy. Surely we don't expect consumers to provide CPE requirements? That's why we wrote cpe-router. > I think a different and better approach would be to officially deprecate > IPv4, declaring it obsolete.=20 I've been thinking about writing that draft (it sounds really good on the last day of IETF, over beers). =20 After the recent thread on "Old transport-layer protocols to Historic" I'm confused about what the right word would be. The list of=20 dependent RFCs would be long, and it might make an interesting career for someone to submit new drafts to obsolete all of the then-deprecated drafts. But I'll write it if you want. Lee From cb.list6@gmail.com Tue Jan 11 08:12:47 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17A4228C2BF; Tue, 11 Jan 2011 08:12:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.935 X-Spam-Level: X-Spam-Status: No, score=-2.935 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SK5fA0p+C8ON; Tue, 11 Jan 2011 08:12:45 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 5A2F93A6A4E; Tue, 11 Jan 2011 08:12:45 -0800 (PST) Received: by qwi2 with SMTP id 2so5452622qwi.31 for ; Tue, 11 Jan 2011 08:15:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:received :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=of4Xq2XgjRPfVlAFLkgpRePF1D2mDrGrsiwc3U9+yvs=; b=NkSmIp1CBBGuEOdECkD6Ww+6FSYbnOYbZHs5qwifJg2efEumfuvKpcqTEO4cisJC4Y Mn4u+qRnnCVElxlzqI+pKnAvxmQd1hvmOiExVD/Cir29DAw6iEmnDzD4Bj9KTgEcl/cr eh7aJv73nfq2BBLjZUdQNciOUao59uy9ByjJg= 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=i5I5PHEbE4D3EjKdDHpqUF07PxC0tNdkRUzE7IAPsCI6MAQtKE3jqU6VquIqlDpmjw G4K9EvH9AmwYyL3MaK45/5Usv9HGjvakd0JX8Cq0QCZio4ff+5oL/efOuFQ99uTuqreF PBZz5WieyUZob6m/aTtxqAMLLf0PTJ8Fivtyw= MIME-Version: 1.0 Received: by 10.229.96.83 with SMTP id g19mr25689960qcn.106.1294762501880; Tue, 11 Jan 2011 08:15:01 -0800 (PST) Received: by 10.229.224.79 with HTTP; Tue, 11 Jan 2011 08:15:01 -0800 (PST) Received: by 10.229.224.79 with HTTP; Tue, 11 Jan 2011 08:15:01 -0800 (PST) In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E04C472@PLSWM12A.ad.sprint.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <20110111074511.022d29bf@opy.nosense.org> <54E900DC635DAB4DB7A6D799B3C4CD8E04C472@PLSWM12A.ad.sprint.com> Date: Tue, 11 Jan 2011 08:15:01 -0800 Message-ID: From: Cameron Byrne To: "George, Wes E [NTK]" Content-Type: multipart/alternative; boundary=001636aa2b8efe3c700499946245 X-Mailman-Approved-At: Thu, 13 Jan 2011 09:42:18 -0800 Cc: "Howard, Lee" , Mark Smith , "v6ops@ietf.org" , "int-area@ietf.org" , Christopher LILJENSTOLPE Subject: Re: [Int-area] [v6ops] IP-capable nodes must support IPv6 - new draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 16:12:47 -0000 --001636aa2b8efe3c700499946245 Content-Type: text/plain; charset=ISO-8859-1 On Jan 11, 2011 6:37 AM, "George, Wes E [NTK]" wrote: > > > > -----Original Message----- > > > From: Mark Smith > > > I don't think I really agree with the root cause. IPv6 doesn't exist in > > > equipment because customers, or representatives of customers (e.g ISPs > > > for CPE) haven't made it a "must have", and refused to buy the > > > equipment when it doesn't support IPv6. > > > > -----Original Message----- > > From: Howard, Lee [mailto:lee.howard@twcable.com] > > What about ISPs who don't buy CPE? > > Retail stores in the U.S. make a lot of money selling gateways to > > retail > > customers. Consumers get more choice of what gateway they want to > > buy. Surely we don't expect consumers to provide CPE requirements? > > That's why we wrote cpe-router. > > [WES] Let's not forget that this is not just about residential gateways. We > have TVs that connect to one or more streaming-video and social media > services, appliances that talk either to the smart grid, or your home energy > monitor, or a website, or all of the above; nevermind things like gaming > consoles, standalone streaming media boxes, eReaders with Wifi... should I > go on? > If you could find someone at $consumer_electronics_manufacturer of any of > the above products that we could provide those requirements to (who would > actually...you know... listen to us and do something about it), I know of > several representatives from large cable companies that represent a large > fraction of their consumer base who would *love* to make IPv6 a must-have > and explain to them how badly their product might potentially function > behind NAT444. ARIN has been trying at places like CES, and ISOC has also > tried to reach out to representatives of these industries, both with what I > would consider to be only marginal success thus far. > > > > > I think a different and better approach would be to officially > > > deprecate IPv4, declaring it obsolete. > > > > I've been thinking about writing that draft (it sounds really good on > > the last day of IETF, over beers). > > > > After the recent thread on "Old transport-layer protocols to Historic" > > I'm confused about what the right word would be. > > [WES] We started out that way with this draft, actually. But as Lee says, we > couldn't determine whether deprecate or historic was the right choice, and > we realized that honestly it's not that simple. I expect that we'll get much > wider support for "IPv6 is required for devices that want to call themselves > IP-capable" than for IPv4 deprecation when IPv4 is still the dominant > protocol in use. This is at least partially because there are plenty of > places where IPv4 will *never* go away or won't go away until the device > using it is retired, where it is functioning acceptably and there is no > issue with a lack of IPv4 addresses because that application isn't growing. > Will those IPv4-only networks start becoming islands connected by IPv6 with > ALG at some point? Likely, but if they're completely closed networks, we > probably can't say that IPv4 isn't acceptable. My view is that the > deprecation/historic discussion is one to have once we've reached critical > mass on IPv6, or at least when we've exhausted the RIR free pools. > +1 for having something to reference in time for rir exhaust. The people living in a hole will really start panicking at that point and having clear guidance that ipv4 is dead will really help in creating order from the impending chaos. Cb > Either way, this is a multistep process. The first step is to make sure that > those manufacturers who don't have a clueful and influential customer > providing them requirements understand that they need to stop grunting out > widgets that don't understand IPv6, and to help apply pressure to those who > are on the fence. We aren't going to be able to force them to do anything, > only provide guidance, but I would hope that the IETF has some influence > here. However, I imagine your average consumer is going to be a lot angrier > when we tell them that the shiny new internet-connected device that they > just got for $winter_gift-giving_holiday 2010 is basically obsolete, or at > best functioning in a degraded fashion, due to a problem that we've known > about for many years. The vendor of said device shares some blame for being > short-sighted, greedy or both, especially if they don't update their > software-updatable devices with an IPv6 stack, but I still don't know how > IETF is going to answer the question as to why we didn't require IPv6 > sooner. > > Wes George > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001636aa2b8efe3c700499946245 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jan 11, 2011 6:37 AM, "George, Wes E [NTK]" <Wesley.E.George@sprint.com> wrote: >
> =A0> > -----Original Message-----
> > > From: Mark Smith
> > > I don't think I really agree with the root cause. IPv6 d= oesn't exist in
> > > equipment because customers, or representatives of customers= (e.g ISPs
> > > for CPE) haven't made it a "must have", and re= fused to buy the
> > > equipment when it doesn't support IPv6.
> >
> > -----Original Message-----
> > From: Howard, Lee [mailto:lee.howard@twcable.com]
> > What about ISPs who don't buy CPE?
> > Retail stores in the U.S. make a lot of money selling gateways to=
> > retail
> > customers. =A0Consumers get more choice of what gateway they want= to
> > buy. =A0Surely we don't expect consumers to provide CPE requi= rements?
> > That's why we wrote cpe-router.
>
> [WES] Let's not forget that this is not just about residential gat= eways. We
> have TVs that connect to one or more streaming-video and social media<= br> > services, appliances that talk either to the smart grid, or your home = energy
> monitor, or a website, or all of the above; nevermind things like gami= ng
> consoles, standalone streaming media boxes, eReaders with Wifi... shou= ld I
> go on?
> If you could find someone at $consumer_electronics_manufacturer of any= of
> the above products that we could provide those requirements to (who wo= uld
> actually...you know... listen to us and do something about it), I know= of
> several representatives from large cable companies that represent a la= rge
> fraction of their consumer base who would *love* to make IPv6 a must-h= ave
> and explain to them how badly their product might potentially function=
> behind NAT444. ARIN has been trying at places like CES, and ISOC has a= lso
> tried to reach out to representatives of these industries, both with w= hat I
> would consider to be only marginal success thus far.
> >
> > > I think a different and better approach would be to official= ly
> > > deprecate IPv4, declaring it obsolete.
> >
> > I've been thinking about writing that draft (it sounds really= good on
> > the last day of IETF, over beers).
> >
> > After the recent thread on "Old transport-layer protocols to= Historic"
> > I'm confused about what the right word would be.
>
> [WES] We started out that way with this draft, actually. But as Lee sa= ys, we
> couldn't determine whether deprecate or historic was the right cho= ice, and
> we realized that honestly it's not that simple. I expect that we&#= 39;ll get much
> wider support for "IPv6 is required for devices that want to call= themselves
> IP-capable" than for IPv4 deprecation when IPv4 is still the domi= nant
> protocol in use. This is at least partially because there are plenty o= f
> places where IPv4 will *never* go away or won't go away until the = device
> using it is retired, where it is functioning acceptably and there is n= o
> issue with a lack of IPv4 addresses because that application isn't= growing.
> Will those IPv4-only networks start becoming islands connected by IPv6= with
> ALG at some point? Likely, but if they're completely closed networ= ks, we
> probably can't say that IPv4 isn't acceptable. My view is that= the
> deprecation/historic discussion is one to have once we've reached = critical
> mass on IPv6, or at least when we've exhausted the RIR free pools.=
>

+1 for having something to reference in time for rir exhaust.

The people living in a hole will really start panicking at that point an= d having clear guidance that ipv4 is dead will really help in creating orde= r from the impending chaos.

Cb
> Either way, this is a multistep process. The first step is to make sur= e that
> those manufacturers who don't have a clueful and influential custo= mer
> providing them requirements understand that they need to stop grunting= out
> widgets that don't understand IPv6, and to help apply pressure to = those who
> are on the fence. We aren't going to be able to force them to do a= nything,
> only provide guidance, but I would hope that the IETF has some influen= ce
> here. However, I imagine your average consumer is going to be a lot an= grier
> when we tell them that the shiny new internet-connected device that th= ey
> just got for $winter_gift-giving_holiday 2010 is basically obsolete, o= r at
> best functioning in a degraded fashion, due to a problem that we'v= e known
> about for many years. The vendor of said device shares some blame for = being
> short-sighted, greedy or both, especially if they don't update the= ir
> software-updatable devices with an IPv6 stack, but I still don't k= now how
> IETF is going to answer the question as to why we didn't require I= Pv6
> sooner.
>
> Wes George
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
>

--001636aa2b8efe3c700499946245-- From brian.e.carpenter@gmail.com Thu Jan 13 11:16:11 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 511B53A684B for ; Thu, 13 Jan 2011 11:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.297 X-Spam-Level: X-Spam-Status: No, score=-103.297 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmnKChT8APBt for ; Thu, 13 Jan 2011 11:16:09 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 6EAC43A6BC9 for ; Thu, 13 Jan 2011 11:16:09 -0800 (PST) Received: by eyd10 with SMTP id 10so1112130eyd.31 for ; Thu, 13 Jan 2011 11:18:32 -0800 (PST) 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:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8U8hICp0+XIH5+LtYsxuZpltzqPB1Elvpa22aCczKP8=; b=a3wQzE8kS20B8/du6I7jSxypva8r5wveK9/r5G2gj8L5SLUCM3mI0nLangFPrI0eWY 5lmOKjMhijjJd372XyfgYyFPdLoRDmgeGBWdELnLLTyB3q4uGywo4vEIcbV/v0Ejx3aX U3+eeNDA6oNk3crVR4TMrtYSg2rI/8tYneZbw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=P71zK9Lc5fNLDC/70rvV5Oj6ezNtx+4U2nNMRB4diWZnleh14+we9va0w/k90D7NPB UQG+C88WYHHaoNiJ+FFr5QTA+2ok1Krraogva0e0FVFBc0TK0Phs6cooDLt7NkYmlpmK NFHNVN5G44V8isnYTFIWGuQn5DRbXpLswMUkM= Received: by 10.223.71.197 with SMTP id i5mr2681587faj.127.1294946312018; Thu, 13 Jan 2011 11:18:32 -0800 (PST) Received: from [10.1.1.3] ([121.98.190.33]) by mx.google.com with ESMTPS id z1sm190083fau.21.2011.01.13.11.18.27 (version=SSLv3 cipher=RC4-MD5); Thu, 13 Jan 2011 11:18:30 -0800 (PST) Message-ID: <4D2F4FF9.9070100@gmail.com> Date: Fri, 14 Jan 2011 08:18:17 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= References: <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <20110110.224735.41641090.sthaug@nethelp.no> <4D2CBDFE.30902@gmail.com> <2342BA4A-F973-46AF-82C8-4E1C20CA8692@free.fr> <00b301cbb246$cda664c0$68f32e40$@it.uc3m.es> <48F6E98D-0626-4498-8C62-9E51FA1FA637@free.fr> <4D2E1BE9.6010000@gmail.com> <31727DDE-AC4A-41E9-89D2-2941B3AE9C21@free.fr> In-Reply-To: <31727DDE-AC4A-41E9-89D2-2941B3AE9C21@free.fr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: 'Internet Area' Subject: Re: [Int-area] e2e Address transparency - PI site routing - Multi-CPE multihoming X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 19:16:11 -0000 On 2011-01-13 21:41, R=C3=A9mi Despr=C3=A9s wrote: > Thank you, Brian, for this other interesting reference I hadn't noticed= =2E >=20 >=20 > Le 12 janv. 2011 =C3=A0 22:23, Brian E Carpenter a =C3=A9crit : >=20 >> I hate to have to say this, but the reason that NAT44 became popular f= or >> quite a number of large (typically multinational) enterprise networks >> was as the easiest solution to the multi-exit problem. >=20 > I agree, but, in my understanding: > - only for outgoing connectivity Yes, i.e. connections initiated from the inside. Such companies normally have their public-facing servers outside the main border, in a "demilitarized zone". > - without TCP continuity in case of failure an ISP access being used. Correct. This was IMHO the big requirement introduced by RFC 3582. I thought it was a mistake at the time, but I was only the WG Chair and the consensus was to make it a requirement. > =3D> incompatible with SHIM6 or SCTP, whose functions include incoming = connectivity and TCP continuity. The incompatibility is exactly as discussed in the Huitema draft I mentioned, and possibly solved by proxy shim6. >> These companies >> didn't regard NAT as a security feature; they had firewalls for that. >> And they didn't *want* to lose address transparency; that was consider= ed >> an acceptable side-effect of gaining a solution to the multi-exit >> multi-homing problem. >=20 > That's why, IMHO, an IPv6 solution that avoids this side-effect is wort= h working on. Yes. Brian >=20 > Regards, > RD=20 >=20 >=20 >> Also look in your time machine for >> "Ingress filtering compatibility for IPv6 multihomed sites" >> draft-huitema-multi6-ingress-filtering-00 >> >> Regards >> Brian Carpenter >> >> On 2011-01-13 05:20, R=C3=A9mi Despr=C3=A9s wrote: >>> Alberto, >>> >>> Thank you for this interesting reference I hadn't noticed. >>> >>> It did share the objective of combining of "PI site routing" with "Mu= lti-CPE multihoming", but was NOT concerned with "e2e address transparenc= y". >>> >>> Besides: =20 >>> - It needed a middle-box between all hosts and CPE's >>> - It needed a new DNS RR type. >>> Both have to be avoided in the solution I look for. >>> >>> Kind regards, >>> RD >>> >>> >>> >>> Le 12 janv. 2011 =C3=A0 11:52, Alberto Garc=C3=ADa a =C3=A9crit : >>> >>>> Hi, >>>> The requirements you state remind me the Proxy Shim6 proposal >>>> (http://tools.ietf.org/id/draft-bagnulo-pshim6-02.txt). There is als= o a >>>> paper on the subject at >>>> http://e-archivo.uc3m.es/bitstream/10016/2846/1/P-SHIM6.pdf >>>> The abstract of the paper says: >>>> "The P-SHIM6 architecture provides ISP independence to IPv6 sites wi= thout >>>> compromising scalability. >>>> This architecture is based on a middle-box, the >>>> P-SHIM6, which manages the SHIM6 protocol exchange on behalf of the = nodes of >>>> a site, which are configured with provider independent addresses. I= ncoming >>>> and outgoing packets are processed by the P-SHIM6 box, which can ass= ign >>>> different locators to a given communication, either when it is start= ed, or >>>> dynamically after the communication has been established. As a conse= quence, >>>> changes required for provider portability are minimized, and fine-gr= ained >>>> Traffic Engineering can be enforced at the P-SHIM6 box, in addition = to the >>>> fault tolerance support provided by SHIM6." >>>> >>>> Regards, >>>> Alberto >>>> >>>> | -----Mensaje original----- >>>> | De: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] = En >>>> | nombre de R=C3=A9mi Despr=C3=A9s >>>> | Enviado el: mi=C3=A9rcoles, 12 de enero de 2011 11:19 >>>> | Para: Brian E Carpenter >>>> | CC: Internet Area >>>> | Asunto: [Int-area] e2e Address transparency - PI site routing - M= ulti-CPE >>>> | multihoming >>>> | =20 >>>> | Brian, >>>> | =20 >>>> | Here is a good opportunity to clarify an important point, on whic= h I hope >>>> we >>>> | can converge. >>>> | =20 >>>> | The problem I worked on is how to combine: >>>> | - "e2e address transparency" (hosts know their own global address= es, and >>>> | use them) >>>> | - "PI site routing" (e.g., in IPv6, ULA-only intra-site routing = to avoid >>>> | renumbering problems) >>>> | - "Multi-CPE Multihoming" (the most complete multihoming model). >>>> | - "Per-site incremental deployment" (a site can use the solution >>>> | independently from what is done anywhere else). >>>> | =20 >>>> | - LISP is off-scope because it doesn't permit per-site incrementa= l >>>> | deployment. >>>> | =20 >>>> | This problem has two complementary sub-problems: >>>> | . "Source-address selection" (how does a host select a particular= e2e >>>> source >>>> | address for an outgoing packet)? >>>> | . "Outgoing-CPE control" (the source address being selected, how = to >>>> ensure >>>> | that the packet goes via the right CPE)? >>>> | - Solutions for "source-address selection" do exist (SHIM6, SCTP,= >>>> draft-ietf- >>>> | v6ops-multihoming-without-nat66). >>>> | - AFAIK, a solution for "outgoing-CPE control" in the above conte= xt still >>>> has >>>> | to be specified >>>> | =20 >>>> | The key I briefly described for this "outgoing-CPE selection", in= sec 3.3 >>>> of >>>> | draft-despres-softwire-sam-01), is that: >>>> | - For customer-site traversal, hosts encapsulate e2e packets in l= ocal >>>> packets >>>> | (IPv6/IPv6). >>>> | - Hosts address these local packets to the right CPE's by using a= >>>> | correspondence list between local CPE addresses and global IPv6 p= refixes. >>>> | =20 >>>> | Unless this is proved to be useless, I plan to pursue in this dir= ection, >>>> with >>>> | whoever is interested in making positive contributions. >>>> | =20 >>>> | Best regards, >>>> | RD >>>> | =20 >>>> | =20 >>>> | =20 >>>> | Le 11 janv. 2011 =C3=A0 21:30, Brian E Carpenter a =C3=A9crit : >>>> | >> ... it should be more useful to look for solutions that combin= e >>>> provider >>>> | independence with address transparency, than accepting without ef= fort to >>>> | sacrifice address transparency for provider independence. >>>> | > >>>> | > Indeed; we already have one of those standardised, which also h= as the >>>> | > property of protecting BGP4 scalability: RFC 5533, RFC 5534 and= RFC >>>> 5535. >>>> | =20 >>>> | (RFC 5533 and RFC 5534 are about SHIM6, and RFC 5535 is about sec= uring >>>> | multihoming address sets. None of these addresses the "outgoing-C= PE >>>> | control" issue). >>>> | =20 >>>> | =20 >>>> | _______________________________________________ >>>> | Int-area mailing list >>>> | Int-area@ietf.org >>>> | https://www.ietf.org/mailman/listinfo/int-area >>>> >>> >>> >=20 >=20 >=20 From evnikita2@gmail.com Sat Jan 15 22:25:49 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D52F3A6CF8 for ; Sat, 15 Jan 2011 22:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.242 X-Spam-Level: X-Spam-Status: No, score=-3.242 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyfgj6ut5MXz for ; Sat, 15 Jan 2011 22:25:46 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 2408E3A6B22 for ; Sat, 15 Jan 2011 22:25:45 -0800 (PST) Received: by fxm9 with SMTP id 9so5011859fxm.31 for ; Sat, 15 Jan 2011 22:28:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=rcBpgLvrDw5gcWYQgs6dH0hSi5TIZWwDG7plSLJM6zQ=; b=AYkkRkt3zx0ZyCNV97ZFoucJoYoI0RuBMrgXkIlX7pM5Is52DE269ZHqMfod4jxed6 TqTSXKqTDFDHVaUZGat/b+rMKnDH9n2QUVcdeWtHh/WBAfvbfL+xifiYgKa+fBpiQt1N uHOXZ4Wsc1x3uCs0Nl+gqRzemPUE7PL8im5Xc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; b=XUi01wd+d7iuGhzIrETtXAxpmljg4yCXz63t5StbNRV2pCh9IHU7flh5S61dQZN9Tr Wu46AzmPA3g/XJdQasCVcZWHMZ75g9HVe7r6QEVDkpS0lrJL3kewEV79zWbKRtQyYU60 m6ylFGnqFUhbri6U1Abplz5cW+M80ujmn6ua4= Received: by 10.223.115.75 with SMTP id h11mr1508048faq.119.1295159295411; Sat, 15 Jan 2011 22:28:15 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id y1sm1115348fak.39.2011.01.15.22.28.13 (version=SSLv3 cipher=RC4-MD5); Sat, 15 Jan 2011 22:28:13 -0800 (PST) Message-ID: <4D329011.5010105@gmail.com> Date: Sun, 16 Jan 2011 08:28:33 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: int-area@ietf.org References: <4D328C0D.40902@gmail.com> In-Reply-To: <4D328C0D.40902@gmail.com> Content-Type: multipart/alternative; boundary="------------040508000607040303060309" Subject: Re: [Int-area] EIP and IP version number assignments X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 06:25:49 -0000 This is a multi-part message in MIME format. --------------040508000607040303060309 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello all, I'd like to ask an advice about one my idea that, I think, it in the scope of intarea WG. So, while looking trough the IP version numbers registry, I noticed that there is no mentioning the EIP (http://tools.ietf.org/html/rfc1385) there (http://www.iana.org/assignments/version-numbers/version-numbers.xhtml) in spite of being an alternative version of IP. So I propose that there should be created a document that will assign the IP version number to EIP, that. in accordance with RFC 2780, should be Standards Track doc. So I am asking whether there is an interest (and maybe consensus) of community regarding this problem. All the best, Mykyta Yevstifeyev --------------040508000607040303060309 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hello all,

I'd like to ask an advice about one my idea that, I think, it in the scope of intarea WG.

So, while looking trough the IP version numbers registry, I noticed that there is no mentioning the EIP (http://tools.ietf.org/html/rfc1385) there (http://www.iana.org/assignments/version-numbers/version-numbers.xhtml) in spite of being an alternative version of IP.  So I propose that there should be created a document that will assign the IP version number to EIP, that. in accordance with RFC 2780, should be Standards Track doc.

So I am asking whether there is an interest (and maybe consensus) of community regarding this problem.

All the best,
Mykyta Yevstifeyev

--------------040508000607040303060309-- From joelja@bogus.com Sun Jan 16 06:12:07 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ADFF3A6C5D; Sun, 16 Jan 2011 06:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_27=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSlPoNqtVaNg; Sun, 16 Jan 2011 06:12:06 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 56BED3A6BD7; Sun, 16 Jan 2011 06:12:05 -0800 (PST) Received: from joelja-mac.local (62-50-219-60.client.stsn.net [62.50.219.60]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p0GEETot091797 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 16 Jan 2011 14:14:32 GMT (envelope-from joelja@bogus.com) Message-ID: <4D32D58A.8020605@bogus.com> Date: Sun, 16 Jan 2011 12:24:58 +0100 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ed Jankiewicz References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <54E900DC635DAB4DB7A6D799B3C4CD8E04B941@PLSWM12A.ad.sprint.com> <4D2B51A8.3050405@sri.com> In-Reply-To: <4D2B51A8.3050405@sri.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "int-area@ietf.org" , IPv6 Ops WG Subject: Re: [Int-area] draft-george-ipv6-required X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 14:12:07 -0000 On 1/10/11 7:36 PM, Ed Jankiewicz wrote: > upon reflection, I agree that it would be unnecessary and inappropriate > to generate a petition within IETF. The process is built on consensus, > not name-checking. > > Suffice it to say I support this work being discussed within Intarea and > v6ops, including time on the agenda in Prague, and eventual adoption as > a WG or IAB publication. > > I also agree with a previous comment that this draft should be kept very > simple with a small number of essential references, e.g. to the IPv6 > Node Requirements (as revised). That is the current best definition of > what is "required" for IPv6. If it is insufficient as is, and needs to > be replaced by a standards track definition, that would take some > effort, and that can be discussed as well. I would prefer that we > publish the current RFC 4294 update draft before we open that can of worms. > > The question of parity is very complex and difficult to define. more to the point consensus on what constitutes is a discussion that's pretty easy to rathole. A statement that is simplistic and open to interpretation may not achieve all that you want at the same time the resulting statement may be more readily achievable and we have documents like for example the cpe drafts to addresses. Idealy this document is: 1. discussed now both here and the int-area. 2. presented in prague 3. accepted as a wg document where we deem appropiate 4. last called > The > concerns that some things are not directly comparable, or that there are > things that have become accepted in IPv4 that some don't want to > replicate in IPv6, versus the sense that the lack of any feature > (standard or not) will be a disincentive to IPv6 adoption - it's not > clear how these can be reconciled. > > On 1/10/2011 11:29 AM, George, Wes E [NTK] wrote: >> Shortened the subject line a bit >> >> From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On >> Behalf >> Of Ed Jankiewicz >> Sent: Friday, January 07, 2011 3:11 PM >> To: int-area@ietf.org; IPv6 Operations >> Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new >> draft-george-ipv6-required >> >>> I agree so strenuously that I half-jokiningly would like to be listed >>> as a >>> coauthor, and I bet there are a>number of other folks on these lists >>> that >>> would feel the same way. Perhaps a better suggestion would be >>> to>include an >>> appendix with the name and affiliation of everyone who is willing to >>> sign-on >>> to ratify this>recommendation. >> [WES] If I'm interpreting this right, this would sort of be like a >> petition >> with lots of signatures, or one of those open letters to the >> $government_functionary signed by lots of "important people" you see >> published >> in full-page newspaper ads? I assume that this is generally a way of more >> concretely documenting support for this proposal beyond the IETF's >> standard >> rough consensus in a WG meeting or on-list. >> I'm open to this, but is there any precedent for it? Do we want to set a >> precedent that if we *really* mean something, we take steps to more >> thoroughly >> document that support within a draft? Those in support can already >> have their >> support immortalized in the pages of the email list archives complete >> with >> their choice of editorialization... >> And regarding affiliation - IETF typically shies away from making a >> big deal >> of affiliation, since most of its members are not really authorized to >> represent the company that pays the bills in any official public >> capacity. >> Yes, they are representatives of that company, but they are mostly >> speaking >> for themselves with the interests of their company informing those >> comments - >> it's not like there's a way to get every email and comment at the mic >> approved >> by PR first :-) >> >> An IAB statement of support would perhaps be a good way to add weight >> to this >> recommendation, but I'm content to start with statements of support >> for WG >> adoption and advancement to RFC status and see where it goes from there. >> >> Wes George > From joelja@bogus.com Sun Jan 16 06:12:40 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56ECC3A6C5E; Sun, 16 Jan 2011 06:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBSuUkSWHUPM; Sun, 16 Jan 2011 06:12:39 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 252BE3A6D43; Sun, 16 Jan 2011 06:12:38 -0800 (PST) Received: from joelja-mac.local (62-50-219-60.client.stsn.net [62.50.219.60]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p0GEEkfO091804 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 16 Jan 2011 14:14:50 GMT (envelope-from joelja@bogus.com) Message-ID: <4D32E673.8010409@bogus.com> Date: Sun, 16 Jan 2011 13:37:07 +0100 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fernando Gont References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> In-Reply-To: <4D2B711F.9000705@gont.com.ar> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Mark Smith , =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= , IPv6 Operations , Internet Area Subject: Re: [Int-area] [v6ops] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 14:12:40 -0000 On 1/10/11 9:50 PM, Fernando Gont wrote: > On 10/01/2011 05:43 p.m., Mark Smith wrote: > >>>> The e2e transparency that IPv4 had lost, and IPv6 restores, is >>>> ADDRESS transparency: source and destination addresses seen by a >>>> destination are the same as those set by the source. >>> >>> IPv6 restores this to the extent that NAT66 is not deployed. My take is >>> that NAT66 *will* be deployed. >> >> How do you know? What evidence do you have? > > Talking to vendors, some operators, etc. > > Google for "ipv6 nat" or the like, and you'll see some of the people > that are publicly interested in this feature. It's a basic and necessary feature of ipv6-supporting loadbalancer devices. Given that header rewriting, and state-tracking are basic firewall functions for v4 and v6 you really aren't very far conceptually or implementation-wise from a nat66 feature. The question is what's it a point solution for. If the problem is, "you gave me one ip address and i need more than that" something is badly wrong. > > >>> -- So, I don't think you can rely IPv6 on >>> restoring "address transparency". >>> >>>> - This is needed >>>> in particular for Header Authentication of IPsec. >>> >>> But you can still use UDP encapsulation. >> >> UDP encapsulation of IPsec is a work around, specifically to get around >> the problems of lack of IPv4 address transparency i.e. NAT. It isn't an >> acceptable answer when NAT doesn't need to exist. > > You're assuming that the only motivation to have NATs is address > exhaustion -- but IMO, it isn't. > > Thanks, From ipng@69706e6720323030352d30312d31340a.nosense.org Sun Jan 16 12:50:45 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20EDC3A6E5A; Sun, 16 Jan 2011 12:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CWA7FzKy6il; Sun, 16 Jan 2011 12:50:43 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id 4726B3A6E60; Sun, 16 Jan 2011 12:50:43 -0800 (PST) Received: from 182-239-146-82.ip.adam.com.au ([182.239.146.82] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1PeZav-0004Fv-FK; Mon, 17 Jan 2011 07:23:01 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id AEF603B31E; Mon, 17 Jan 2011 07:23:00 +1030 (CST) Date: Mon, 17 Jan 2011 07:22:58 +1030 From: Mark Smith To: Joel Jaeggli Message-ID: <20110117072258.35fe843d@opy.nosense.org> In-Reply-To: <4D32E673.8010409@bogus.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= , IPv6 Operations , Internet Area Subject: Re: [Int-area] [v6ops] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 20:50:45 -0000 On Sun, 16 Jan 2011 13:37:07 +0100 Joel Jaeggli wrote: > On 1/10/11 9:50 PM, Fernando Gont wrote: > > On 10/01/2011 05:43 p.m., Mark Smith wrote: > > > >>>> The e2e transparency that IPv4 had lost, and IPv6 restores, is > >>>> ADDRESS transparency: source and destination addresses seen by a > >>>> destination are the same as those set by the source. > >>> > >>> IPv6 restores this to the extent that NAT66 is not deployed. My take is > >>> that NAT66 *will* be deployed. > >> > >> How do you know? What evidence do you have? > > > > Talking to vendors, some operators, etc. > > > > Google for "ipv6 nat" or the like, and you'll see some of the people > > that are publicly interested in this feature. > > It's a basic and necessary feature of ipv6-supporting loadbalancer devices. > I don't think that is necessarily the case either. A group of hosts with the same downstream address (the global one announced in DNS), and a router-type device (i.e. isn't assigned the global address announced in DNS) spreading traffic across them such that the same session landed on the same downstream host would provide "load balancing" without NAT - effectively a more advanced version of anycast where all hosts are active, and there is more intelligence in the selection of to which anycast host the traffic is sent by the upstream router, spreading the load. > Given that header rewriting, and state-tracking are basic firewall > functions for v4 and v6 you really aren't very far conceptually or > implementation-wise from a nat66 feature. > > The question is what's it a point solution for. If the problem is, "you > gave me one ip address and i need more than that" something is badly wrong. > > > > > > >>> -- So, I don't think you can rely IPv6 on > >>> restoring "address transparency". > >>> > >>>> - This is needed > >>>> in particular for Header Authentication of IPsec. > >>> > >>> But you can still use UDP encapsulation. > >> > >> UDP encapsulation of IPsec is a work around, specifically to get around > >> the problems of lack of IPv4 address transparency i.e. NAT. It isn't an > >> acceptable answer when NAT doesn't need to exist. > > > > You're assuming that the only motivation to have NATs is address > > exhaustion -- but IMO, it isn't. > > > > Thanks, > From evnikita2@gmail.com Mon Jan 17 01:17:03 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0D2428C0F4 for ; Mon, 17 Jan 2011 01:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.04 X-Spam-Level: X-Spam-Status: No, score=-4.04 tagged_above=-999 required=5 tests=[AWL=-0.441, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+ziQ10-+SHa for ; Mon, 17 Jan 2011 01:17:02 -0800 (PST) Received: from mail-yi0-f42.google.com (mail-yi0-f42.google.com [209.85.218.42]) by core3.amsl.com (Postfix) with ESMTP id 96FE528C0F3 for ; Mon, 17 Jan 2011 01:17:02 -0800 (PST) Received: by yia28 with SMTP id 28so2578398yia.15 for ; Mon, 17 Jan 2011 01:19:36 -0800 (PST) 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=WfhddUB9pzxoEzpwiwPHrcgpfHOeIHuPs2V3mQii15s=; b=i+2I2qxqAYnHoVEnTZWVo1ykcwbGsBIien0STVYw5b0xk395IZnNrNUFJwVXspQn/U GVFhWmz8P5+qscQMdIMjyQzlgFiVCeXvqrIyw5jToZQGvMba6OdU0rVLuI9t3D/rqbGd hUxo2HQ7Mq0pmyHwVH+6mnR/iRMU+i+JVV6Uk= 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=gW0YOx2ezJw5upNDrhBPBWWSCqxqMeO7DlRdR//rt8NI8sU5lzIwawAoItkwfGyyIZ r8G4h2XUlwfvqXTDlHm31DFYIgoDH2f7JD+YFHocjb5admHaUiYZVjvsfRiRkPMDx906 WdMf4rKriTB79gDi5tF7HObV1lx0M1obnh9L4= MIME-Version: 1.0 Received: by 10.150.185.2 with SMTP id i2mr3907553ybf.155.1295255974776; Mon, 17 Jan 2011 01:19:34 -0800 (PST) Received: by 10.150.53.6 with HTTP; Mon, 17 Jan 2011 01:19:34 -0800 (PST) In-Reply-To: <4D3293AF.3050107@joelhalpern.com> References: <4D328C0D.40902@gmail.com> <4D329011.5010105@gmail.com> <4D3293AF.3050107@joelhalpern.com> Date: Mon, 17 Jan 2011 11:19:34 +0200 Message-ID: From: Mykyta Yevstifeyev To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Cc: "int-area@ietf.org" Subject: Re: [Int-area] EIP and IP version number assignments X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 09:17:03 -0000 Joel, Let me cite RFC 1385: Version: 4 bits The Version field is identical to that of IP. This field is set purely for compatibility with IP hosts. It is not checked by EIP hosts. This says that the definition of the field can be found in IP specification. Despite EIP makes no use of this field it should be formally specified. Even if te protocol is not used. Moreover, there are many entries in the registry mentioned that identify 'never-used' protocols. But if there is such RFC, defining this protocol, even if it is useless, we should define the apprpriate entry for it. It is the history of the Internet, and we should respect it. Mykyta 2011/1/16, Joel M. Halpern : > Why would you bother? > EIP is not used. > Also, there is no version number to list for it. EIP frames used > version number 4, according to the RFC. > > So there appears to be no value in such a registration, and nothing to > register. > > Yours, > Joel M. Halpern > > On 1/16/2011 1:28 AM, Mykyta Yevstifeyev wrote: >> Hello all, >> >> I'd like to ask an advice about one my idea that, I think, it in the >> scope of intarea WG. >> >> So, while looking trough the IP version numbers registry, I noticed that >> there is no mentioning the EIP (http://tools.ietf.org/html/rfc1385) >> there >> (http://www.iana.org/assignments/version-numbers/version-numbers.xhtml) >> in spite of being an alternative version of IP. So I propose that there >> should be created a document that will assign the IP version number to >> EIP, that. in accordance with RFC 2780, should be Standards Track doc. >> >> So I am asking whether there is an interest (and maybe consensus) of >> community regarding this problem. >> >> All the best, >> Mykyta Yevstifeyev >> >> >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area > From remi.despres@free.fr Mon Jan 17 08:23:13 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 039313A6F51; Mon, 17 Jan 2011 08:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.16 X-Spam-Level: X-Spam-Status: No, score=0.16 tagged_above=-999 required=5 tests=[AWL=-1.091, BAYES_50=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYfEgydFYZ7U; Mon, 17 Jan 2011 08:23:12 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by core3.amsl.com (Postfix) with ESMTP id D45CE3A6E4D; Mon, 17 Jan 2011 08:23:11 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2102.sfr.fr (SMTP Server) with ESMTP id AFE31700009C; Mon, 17 Jan 2011 17:25:45 +0100 (CET) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2102.sfr.fr (SMTP Server) with ESMTP id 0E79E700008E; Mon, 17 Jan 2011 17:25:44 +0100 (CET) X-SFR-UUID: 20110117162545593.0E79E700008E@msfrf2102.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4D34549F.4020601@brightok.net> Date: Mon, 17 Jan 2011 17:25:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Cc: Mark Smith , IPv6 Operations , Internet Area Subject: Re: [Int-area] [v6ops] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 16:23:13 -0000 Le 17 janv. 2011 =E0 15:39, Jack Bates a =E9crit : > On 1/16/2011 2:52 PM, Mark Smith wrote: >>> It's a basic and necessary feature of ipv6-supporting loadbalancer = devices. >>> > >> I don't think that is necessarily the case either. A group of hosts >> with the same downstream address (the global one announced in DNS), = and >> a router-type device (i.e. isn't assigned the global address = announced >> in DNS) spreading traffic across them such that the same session = landed >> on the same downstream host would provide "load balancing" without = NAT - >> effectively a more advanced version of anycast where all hosts are >> active, and there is more intelligence in the selection of to which >> anycast host the traffic is sent by the upstream router, spreading = the >> load. >=20 > Current methods commonly used are NAT and DSR. v6 implementations of = traditional devices have been using NAT only, and still working on DSR = support. A quick search shows IPVS (linux) for IPv6 with both NAT and DR = support. >=20 > By strictest definition, NAT66 has been implemented and deployed = already. For clarification, could you be more specific: - NAT66 according to which specification? - where (for example)? >=20 > It is not so much NAT66 which is the danger, but where it is deployed. = Having NAT66 in CPE for residential users would be extremely bad. Full agreement. > Special use cases, or environments where the breaking of = communications (certain corporate firewalls), should be considered = completely acceptable. IPv6 gives us the ability to not REQUIRE NAT66, = but > it does not remove the market demand for NAT66, This demand you see may not remain when: - It is better understood that: . Firewalls can filter restrict reachability as efficiently without = NATs as with them. . Privacy can be achieved by other means than NATs and can be lost even = across NATs. . More complete multihoming support is made available without NATs than = feasible across NATs=20 BTW, is this demand you see for (stateful) NAPTv6 or for (stateless) = NPTv6 (being noted that the latter doesn't improve privacy)? Regards, RD =20 > though it does lessen it. >=20 >=20 > Jack >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jbates@brightok.net Mon Jan 17 06:37:04 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9A223A6F37; Mon, 17 Jan 2011 06:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.776 X-Spam-Level: X-Spam-Status: No, score=-0.776 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkTi4vcMCFpa; Mon, 17 Jan 2011 06:37:04 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id DC7383A6E62; Mon, 17 Jan 2011 06:37:03 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p0HEdRTe008684; Mon, 17 Jan 2011 08:39:27 -0600 (CST) Message-ID: <4D34549F.4020601@brightok.net> Date: Mon, 17 Jan 2011 08:39:27 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mark Smith References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> In-Reply-To: <20110117072258.35fe843d@opy.nosense.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 17 Jan 2011 09:08:47 -0800 Cc: IPv6 Operations , Internet Area Subject: Re: [Int-area] [v6ops] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 14:37:04 -0000 On 1/16/2011 2:52 PM, Mark Smith wrote: >> It's a basic and necessary feature of ipv6-supporting loadbalancer devices. >> > > I don't think that is necessarily the case either. A group of hosts > with the same downstream address (the global one announced in DNS), and > a router-type device (i.e. isn't assigned the global address announced > in DNS) spreading traffic across them such that the same session landed > on the same downstream host would provide "load balancing" without NAT - > effectively a more advanced version of anycast where all hosts are > active, and there is more intelligence in the selection of to which > anycast host the traffic is sent by the upstream router, spreading the > load. Current methods commonly used are NAT and DSR. v6 implementations of traditional devices have been using NAT only, and still working on DSR support. A quick search shows IPVS (linux) for IPv6 with both NAT and DR support. By strictest definition, NAT66 has been implemented and deployed already. It is not so much NAT66 which is the danger, but where it is deployed. Having NAT66 in CPE for residential users would be extremely bad. Special use cases, or environments where the breaking of communications (certain corporate firewalls), should be considered completely acceptable. IPv6 gives us the ability to not REQUIRE NAT66, but it does not remove the market demand for NAT66, though it does lessen it. Jack From jbates@brightok.net Mon Jan 17 08:47:19 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5751E28C112; Mon, 17 Jan 2011 08:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.371 X-Spam-Level: X-Spam-Status: No, score=-1.371 tagged_above=-999 required=5 tests=[AWL=0.595, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ED0itwM3Pd3p; Mon, 17 Jan 2011 08:47:18 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 8C42828C0F6; Mon, 17 Jan 2011 08:47:18 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p0HGnhlp015195; Mon, 17 Jan 2011 10:49:43 -0600 (CST) Message-ID: <4D347327.9040501@brightok.net> Date: Mon, 17 Jan 2011 10:49:43 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> In-Reply-To: <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 17 Jan 2011 09:08:47 -0800 Cc: Mark Smith , IPv6 Operations , Internet Area Subject: Re: [Int-area] [v6ops] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 16:47:19 -0000 On 1/17/2011 10:25 AM, Rémi Després wrote: >> Current methods commonly used are NAT and DSR. v6 implementations of traditional devices have been using NAT only, and still working on DSR support. A quick search shows IPVS (linux) for IPv6 with both NAT and DR support. >> >> By strictest definition, NAT66 has been implemented and deployed already. > > For clarification, could you be more specific: > - NAT66 according to which specification? > - where (for example)? I thought this was answered. It's deployed by load balancers which use NAT. >> it does not remove the market demand for NAT66, > > This demand you see may not remain when: > - It is better understood that: > . Firewalls can filter restrict reachability as efficiently without NATs as with them. > . Privacy can be achieved by other means than NATs and can be lost even across NATs. > . More complete multihoming support is made available without NATs than feasible across NATs > I agree, but I suspect the demand will remain for a long time, though at a much smaller market pressure than we've had in v4. Operations community still argues over NAPT uses within a firewall over state-only firewalls. Discussion with a variety of corporate admins has also shown a split between those who welcome global addressing internally (open educational networks) and those who wish to continue utilizing NAPT (draconian corporate admins). > BTW, is this demand you see for (stateful) NAPTv6 or for (stateless) NPTv6 (being noted that the latter doesn't improve privacy)? NAPTv6 in corporate and load balancers. Jack Bates From remi.despres@free.fr Mon Jan 17 09:24:29 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE36628C1A2; Mon, 17 Jan 2011 09:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.131 X-Spam-Level: X-Spam-Status: No, score=-0.131 tagged_above=-999 required=5 tests=[AWL=-0.782, BAYES_50=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PDYBr1EBrJC; Mon, 17 Jan 2011 09:24:29 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by core3.amsl.com (Postfix) with ESMTP id C342428C199; Mon, 17 Jan 2011 09:24:28 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2102.sfr.fr (SMTP Server) with ESMTP id CBF0C7000091; Mon, 17 Jan 2011 18:27:02 +0100 (CET) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2102.sfr.fr (SMTP Server) with ESMTP id 727807000092; Mon, 17 Jan 2011 18:27:02 +0100 (CET) X-SFR-UUID: 20110117172702468.727807000092@msfrf2102.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4D347327.9040501@brightok.net> Date: Mon, 17 Jan 2011 18:27:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Cc: Mark Smith , IPv6 Operations , Internet Area Subject: Re: [Int-area] [v6ops] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 17:24:30 -0000 Le 17 janv. 2011 =E0 17:49, Jack Bates a =E9crit : > On 1/17/2011 10:25 AM, R=E9mi Despr=E9s wrote: >>> Current methods commonly used are NAT and DSR. v6 implementations of = traditional devices have been using NAT only, and still working on DSR = support. A quick search shows IPVS (linux) for IPv6 with both NAT and DR = support. >>>=20 >>> By strictest definition, NAT66 has been implemented and deployed = already. >>=20 >> For clarification, could you be more specific: >> - NAT66 according to which specification? >> - where (for example)? >=20 > I thought this was answered. It's deployed by load balancers which use = NAT. - An informational document on such a deployment would IMHO be useful. - =46rom your answer below, one can derive that the NAT66 spec you refer = to is NAPTv6 (for which there is so far no draft), and not = draft-mrw-nat66 (the only draft so far that specifies a NAT66). =20 =20 >>> it does not remove the market demand for NAT66, >> ... >> BTW, is this demand you see for (stateful) NAPTv6 or for (stateless) = NPTv6 (being noted that the latter doesn't improve privacy)? >=20 > NAPTv6 in corporate and load balancers. Thanks. IMHO, a lot of confusion will be avoided if "NAPTv6" is used rather than = "NAT66" when what is meant is NAPTv6. Regards, RD From evnikita2@gmail.com Mon Jan 17 09:46:26 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 531AB28C1C5 for ; Mon, 17 Jan 2011 09:46:26 -0800 (PST) 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=[AWL=-0.626, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apwxJyl4-x2x for ; Mon, 17 Jan 2011 09:46:25 -0800 (PST) Received: from mail-fx0-f66.google.com (mail-fx0-f66.google.com [209.85.161.66]) by core3.amsl.com (Postfix) with ESMTP id C7E2528C1A2 for ; Mon, 17 Jan 2011 09:46:24 -0800 (PST) Received: by fxm14 with SMTP id 14so2513632fxm.1 for ; Mon, 17 Jan 2011 09:48:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=d/9ByRpsZe7Byo8V1y4r4l7s/X7S9qXAWQ+tiFJtbag=; b=OmFy5NKgk+GeS7HIcqAjWixebEHH1Os7a2IEhbiapVDV0N8JnmEDbxmL68GyOVAR3n GFeQrqGv3MlVlvvysB4gsuLIWvSfUsPavagOPs3ZeQ41yJXoUz32JHJlVoGoiYBreL13 t7FG+KDCxiLGVQS+WpXOjcDL5LUc+YdJN8sOQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=SjLSgsd5W1DrcM9oB8yGg1CvHgaXsK37wCruwtas0ZVjA+hdxD/fZzi6gia7gSaBr0 fsQugeTqbKP9wy4WrHQrfj8Z2lZxahkfAbEM2i0WsqPphJv6wv7iiiIIGsPtNPKaj7/u uobeEQUbUU1ShjduUKcUphK1PyXxhuMkQ6aag= Received: by 10.204.73.9 with SMTP id o9mr2377420bkj.191.1295286536922; Mon, 17 Jan 2011 09:48:56 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id q18sm2192065bka.3.2011.01.17.09.48.53 (version=SSLv3 cipher=RC4-MD5); Mon, 17 Jan 2011 09:48:56 -0800 (PST) Message-ID: <4D34811A.7050000@gmail.com> Date: Mon, 17 Jan 2011 19:49:14 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Joel M. Halpern" References: <4D328C0D.40902@gmail.com> <4D329011.5010105@gmail.com> <4D3293AF.3050107@joelhalpern.com> <4D3460EC.1050503@joelhalpern.com> In-Reply-To: <4D3460EC.1050503@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "int-area@ietf.org" Subject: Re: [Int-area] EIP and IP version number assignments X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 17:46:26 -0000 17.01.2011 17:31, Joel M. Halpern wrote: > Given that it is using the same value as is currently assigned (i.e. > it was using version number 4), recording it in the registry would be > actively misleading. > It would lead people to expect that they could see IPv4 packets with > this protocol. They won't. It would lead people to think it was > legitimate to generate, in production contexts, packets for this > protocol using an IP version number of 4. That is not what the > experimental RFC says. > > I can not imagine any researcher in the world being helped by adding > such a registry entry, and I can easily imagine some junior > researchers being confused by it. > > What problem are you trying to solve here? > Accuracy as a theoretical good is fine. But you are asking for > practical action. And as a practical action, this is a negative, not > a positive. Maybe not only accuracy. Let's assume that this protocol is used somewhere. If it carries the values 4 for Version, this will lead to misunderstanding what the packet entity is by many systems (first of all, middle-boxes). Not registering the version number to EIP was a mistake made during the creation of appropriate registry. And I'm trying to correct it. Mykyta > > Yours, > Joel M. Halpern > > On 1/17/2011 4:19 AM, Mykyta Yevstifeyev wrote: >> Joel, >> >> Let me cite RFC 1385: >> >> Version: 4 bits >> >> The Version field is identical to that of IP. This field is set >> purely for compatibility with IP hosts. It is not checked by EIP >> hosts. >> >> This says that the definition of the field can be found in IP >> specification. Despite EIP makes no use of this field it should be >> formally specified. Even if te protocol is not used. Moreover, there >> are many entries in the registry mentioned that identify 'never-used' >> protocols. But if there is such RFC, defining this protocol, even if >> it is useless, we should define the apprpriate entry for it. It is >> the history of the Internet, and we should respect it. >> >> Mykyta >> >> >> 2011/1/16, Joel M. Halpern: >>> Why would you bother? >>> EIP is not used. >>> Also, there is no version number to list for it. EIP frames used >>> version number 4, according to the RFC. >>> >>> So there appears to be no value in such a registration, and nothing to >>> register. >>> >>> Yours, >>> Joel M. Halpern >>> >>> On 1/16/2011 1:28 AM, Mykyta Yevstifeyev wrote: >>>> Hello all, >>>> >>>> I'd like to ask an advice about one my idea that, I think, it in the >>>> scope of intarea WG. >>>> >>>> So, while looking trough the IP version numbers registry, I noticed >>>> that >>>> there is no mentioning the EIP (http://tools.ietf.org/html/rfc1385) >>>> there >>>> (http://www.iana.org/assignments/version-numbers/version-numbers.xhtml) >>>> >>>> in spite of being an alternative version of IP. So I propose that >>>> there >>>> should be created a document that will assign the IP version number to >>>> EIP, that. in accordance with RFC 2780, should be Standards Track doc. >>>> >>>> So I am asking whether there is an interest (and maybe consensus) of >>>> community regarding this problem. >>>> >>>> All the best, >>>> Mykyta Yevstifeyev >>>> >>>> >>>> >>>> _______________________________________________ >>>> Int-area mailing list >>>> Int-area@ietf.org >>>> https://www.ietf.org/mailman/listinfo/int-area >>> >> > From fred@cisco.com Mon Jan 17 09:52:13 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA74028C1E7; Mon, 17 Jan 2011 09:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.313 X-Spam-Level: X-Spam-Status: No, score=-110.313 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cy1qoiO+cB8e; Mon, 17 Jan 2011 09:52:10 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 7999D28C1A2; Mon, 17 Jan 2011 09:52:06 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAH8RNE2rR7Hu/2dsb2JhbACkU3OoQZkfhVAEhHCGL4Mk Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 17 Jan 2011 17:54:41 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0HHsaOQ018286; Mon, 17 Jan 2011 17:54:40 GMT Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Mon, 17 Jan 2011 09:54:41 -0800 X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Mon, 17 Jan 2011 09:54:41 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: Date: Mon, 17 Jan 2011 09:54:26 -0800 Message-Id: <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Mark Smith , IPv6 Operations , Internet Area , Jack Bates Subject: Re: [Int-area] [v6ops] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 17:52:13 -0000 On Jan 17, 2011, at 9:27 AM, R=E9mi Despr=E9s wrote: >=20 > Le 17 janv. 2011 =E0 17:49, Jack Bates a =E9crit : >=20 >> On 1/17/2011 10:25 AM, R=E9mi Despr=E9s wrote: >>>> Current methods commonly used are NAT and DSR. v6 implementations = of traditional devices have been using NAT only, and still working on = DSR support. A quick search shows IPVS (linux) for IPv6 with both NAT = and DR support. >>>>=20 >>>> By strictest definition, NAT66 has been implemented and deployed = already. >>>=20 >>> For clarification, could you be more specific: >>> - NAT66 according to which specification? >>> - where (for example)? >>=20 >> I thought this was answered. It's deployed by load balancers which = use NAT. >=20 > - An informational document on such a deployment would IMHO be useful. There's not much to write. It is pretty much standard practice.=20 Case 1: it's literally a NAT; it redirects TCP sessions sent to a common = address to one of a number of servers. How it measures server load = varies; the server may inform it of what it considers its load to be (a = server with a few CPUs might get "loaded" more quickly than one with = many CPUs), the NAT box may try to keep a roughly equal number of TCP = sessions to each of several servers, or the NAT box might try to = maintain roughly equal traffic flow from each of several servers, = redirecting new sessions to whichever server currently has the lowest = load.=20 Case 2: It's an application layer gateway that uses NAT technology to = accomplish its goals. The most common case is HTTP. The ALG may operate = by maintaining a pool of open TCP sessions with each of a set of (or = several discrete sets of) servers, or it may open up new sessions as = needed. In any event, it terminates an incoming HTTP session and goes = through an on/off pattern - it collects a "GET", determines which server = to send that to, obtains (opens or allocates) a TCP session to the = server, forwards the "GET" to the server, and uses NAT techniques to = maintain traffic flow between the server and the client. When the server = terminates the session, it does *not* pass that along; it instead awaits = the next GET. Note that different GET targets may be sent to different = servers or pools of servers. > - =46rom your answer below, one can derive that the NAT66 spec you = refer to is NAPTv6 (for which there is so far no draft), and not = draft-mrw-nat66 (the only draft so far that specifies a NAT66). It could be, but it doesn't have to be. It is solving a different = problem. It is doing data center load balancing, which 6man is very = carefully avoiding looking at in its load balancing draft. >>>> it does not remove the market demand for NAT66, >>> ... >>> BTW, is this demand you see for (stateful) NAPTv6 or for (stateless) = NPTv6 (being noted that the latter doesn't improve privacy)? >>=20 >> NAPTv6 in corporate and load balancers. >=20 > Thanks. > IMHO, a lot of confusion will be avoided if "NAPTv6" is used rather = than "NAT66" when what is meant is NAPTv6. >=20 > Regards, > RD >=20 >=20 >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From evnikita2@gmail.com Mon Jan 17 10:01:43 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66FBA28C205 for ; Mon, 17 Jan 2011 10:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=-0.607, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xqcP1RRCHzp for ; Mon, 17 Jan 2011 10:01:42 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id C219728C1F6 for ; Mon, 17 Jan 2011 10:01:41 -0800 (PST) Received: by fxm9 with SMTP id 9so6935244fxm.31 for ; Mon, 17 Jan 2011 10:04:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NOMAatYnI2HcEHza4bWDPr+NR0INHbk9zGxJxtKDH7M=; b=WnjYbigdjr8jr0rGEKhE2wLym1bBqkGiyCXwYu/31ipibzl4XaE78L2S+KOaARRdob CGSIDi2hkhqB9rCdkz4w2LIdh6okgUa+9Et3u2KFQqclNdDhAuz/dtRnqpZQfQtBVcp9 MG+UTreU3Y9nH0ytEJqKC8aX5JkN4zMqNwdHg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=IzlZzYCOGWUrEKh91VrZR2yBGoY4Qw5bEPQSx7N9o2WHHeWipzLfXgIl4FtC+KjIFE brvwaebSTLKG8p/YK1f7TAwe+p3w+eeQhqZF19Yy/t3RNwL9hZcz+TviSTwcS6C7hZoy pAAXbI65gxpmH5OAQz27+R6ftF36l1wl6m63I= Received: by 10.223.78.138 with SMTP id l10mr5555107fak.17.1295287452805; Mon, 17 Jan 2011 10:04:12 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id a2sm1764260faw.46.2011.01.17.10.04.11 (version=SSLv3 cipher=RC4-MD5); Mon, 17 Jan 2011 10:04:11 -0800 (PST) Message-ID: <4D3484AE.9070808@gmail.com> Date: Mon, 17 Jan 2011 20:04:30 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Joel M. Halpern" References: <4D328C0D.40902@gmail.com> <4D329011.5010105@gmail.com> <4D3293AF.3050107@joelhalpern.com> <4D3460EC.1050503@joelhalpern.com> <4D34811A.7050000@gmail.com> <4D34822C.1030706@joelhalpern.com> In-Reply-To: <4D34822C.1030706@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "int-area@ietf.org" Subject: Re: [Int-area] EIP and IP version number assignments X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 18:01:43 -0000 17.01.2011 19:53, Joel M. Halpern wrote: > Registering this value will not actually avoid the problem of confusion. > In the VERY unlikely case that this is being used somewhere, the > version number is still confusing (the initial design choices was, in > hindsight, a mistake.) In spite of this, even though it is not expected to be used anywhere, this protocol *exists* as well as other alternative versions of IP, such as TP/IX or PIP, that are very unlikely used too, but are supplied with IP version number. If the spec and protocols exists et al, the appropriate value in the registry should be requested for it. All the best, Mykyta Yevstifeyev > > Secondarily, the protocol is so rare that no firewall or packet > processing vendor is going to bother to put this in their product. > > Yours, > Joel > > On 1/17/2011 12:49 PM, Mykyta Yevstifeyev wrote: >> 17.01.2011 17:31, Joel M. Halpern wrote: >>> Given that it is using the same value as is currently assigned (i.e. >>> it was using version number 4), recording it in the registry would be >>> actively misleading. >>> It would lead people to expect that they could see IPv4 packets with >>> this protocol. They won't. It would lead people to think it was >>> legitimate to generate, in production contexts, packets for this >>> protocol using an IP version number of 4. That is not what the >>> experimental RFC says. >>> >>> I can not imagine any researcher in the world being helped by adding >>> such a registry entry, and I can easily imagine some junior >>> researchers being confused by it. >>> >>> What problem are you trying to solve here? >>> Accuracy as a theoretical good is fine. But you are asking for >>> practical action. And as a practical action, this is a negative, not a >>> positive. >> Maybe not only accuracy. Let's assume that this protocol is used >> somewhere. If it carries the values 4 for Version, this will lead to >> misunderstanding what the packet entity is by many systems (first of >> all, middle-boxes). Not registering the version number to EIP was a >> mistake made during the creation of appropriate registry. And I'm trying >> to correct it. >> >> Mykyta >>> >>> Yours, >>> Joel M. Halpern >>> >>> On 1/17/2011 4:19 AM, Mykyta Yevstifeyev wrote: >>>> Joel, >>>> >>>> Let me cite RFC 1385: >>>> >>>> Version: 4 bits >>>> >>>> The Version field is identical to that of IP. This field is set >>>> purely for compatibility with IP hosts. It is not checked by EIP >>>> hosts. >>>> >>>> This says that the definition of the field can be found in IP >>>> specification. Despite EIP makes no use of this field it should be >>>> formally specified. Even if te protocol is not used. Moreover, there >>>> are many entries in the registry mentioned that identify 'never-used' >>>> protocols. But if there is such RFC, defining this protocol, even if >>>> it is useless, we should define the apprpriate entry for it. It is >>>> the history of the Internet, and we should respect it. >>>> >>>> Mykyta >>>> >>>> >>>> 2011/1/16, Joel M. Halpern: >>>>> Why would you bother? >>>>> EIP is not used. >>>>> Also, there is no version number to list for it. EIP frames used >>>>> version number 4, according to the RFC. >>>>> >>>>> So there appears to be no value in such a registration, and >>>>> nothing to >>>>> register. >>>>> >>>>> Yours, >>>>> Joel M. Halpern >>>>> >>>>> On 1/16/2011 1:28 AM, Mykyta Yevstifeyev wrote: >>>>>> Hello all, >>>>>> >>>>>> I'd like to ask an advice about one my idea that, I think, it in the >>>>>> scope of intarea WG. >>>>>> >>>>>> So, while looking trough the IP version numbers registry, I noticed >>>>>> that >>>>>> there is no mentioning the EIP (http://tools.ietf.org/html/rfc1385) >>>>>> there >>>>>> (http://www.iana.org/assignments/version-numbers/version-numbers.xhtml) >>>>>> >>>>>> >>>>>> in spite of being an alternative version of IP. So I propose that >>>>>> there >>>>>> should be created a document that will assign the IP version >>>>>> number to >>>>>> EIP, that. in accordance with RFC 2780, should be Standards Track >>>>>> doc. >>>>>> >>>>>> So I am asking whether there is an interest (and maybe consensus) of >>>>>> community regarding this problem. >>>>>> >>>>>> All the best, >>>>>> Mykyta Yevstifeyev >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Int-area mailing list >>>>>> Int-area@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/int-area >>>>> >>>> >>> >> >> > From ipng@69706e6720323030352d30312d31340a.nosense.org Mon Jan 17 12:19:47 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBAF828C132; Mon, 17 Jan 2011 12:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUiyDYB-8Vk7; Mon, 17 Jan 2011 12:19:47 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id CE41C3A6F51; Mon, 17 Jan 2011 12:19:46 -0800 (PST) Received: from 182-239-146-82.ip.adam.com.au ([182.239.146.82] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Pevai-0007Lt-MG; Tue, 18 Jan 2011 06:52:16 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id A4DCF3B31E; Tue, 18 Jan 2011 06:52:15 +1030 (CST) Date: Tue, 18 Jan 2011 06:52:15 +1030 From: Mark Smith To: Jack Bates Message-ID: <20110118065215.14f55f5a@opy.nosense.org> In-Reply-To: <4D34549F.4020601@brightok.net> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Internet Area Subject: Re: [Int-area] [v6ops] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 20:19:48 -0000 On Mon, 17 Jan 2011 08:39:27 -0600 Jack Bates wrote: > On 1/16/2011 2:52 PM, Mark Smith wrote: > >> It's a basic and necessary feature of ipv6-supporting loadbalancer devices. > >> > > > I don't think that is necessarily the case either. A group of hosts > > with the same downstream address (the global one announced in DNS), and > > a router-type device (i.e. isn't assigned the global address announced > > in DNS) spreading traffic across them such that the same session landed > > on the same downstream host would provide "load balancing" without NAT - > > effectively a more advanced version of anycast where all hosts are > > active, and there is more intelligence in the selection of to which > > anycast host the traffic is sent by the upstream router, spreading the > > load. > > Current methods commonly used are NAT and DSR. v6 implementations of > traditional devices have been using NAT only, and still working on DSR > support. A quick search shows IPVS (linux) for IPv6 with both NAT and DR > support. > I think that is unfortunate and a missed opportunity. However, I suspect these people haven't been on the other side of those sorts of devices very often, trying to troubleshoot problems through them. They might then appreciate how useful end-to-end transparency between the actual communicating end-nodes is after trying to do that a dozen or so times. > By strictest definition, NAT66 has been implemented and deployed already. > > It is not so much NAT66 which is the danger, but where it is deployed. > Having NAT66 in CPE for residential users would be extremely bad. > Special use cases, or environments where the breaking of communications > (certain corporate firewalls), should be considered completely > acceptable. IPv6 gives us the ability to not REQUIRE NAT66, but it does > not remove the market demand for NAT66, though it does lessen it. > > > Jack > From jari.arkko@piuha.net Mon Jan 17 23:45:12 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B29BD3A6E77 for ; Mon, 17 Jan 2011 23:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNjgo+HwxO0E for ; Mon, 17 Jan 2011 23:45:10 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 6E88E3A6E86 for ; Mon, 17 Jan 2011 23:45:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 407FA2CC2F; Tue, 18 Jan 2011 09:47:45 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDX2wGrU0n4l; Tue, 18 Jan 2011 09:47:44 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 6AABF2CC2D; Tue, 18 Jan 2011 09:47:44 +0200 (EET) Message-ID: <4D35459F.6030500@piuha.net> Date: Tue, 18 Jan 2011 09:47:43 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Internet Area , draft-ietf-intarea-shared-addressing-issues@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Int-area] AD review of draft-ietf-intarea-shared-addressing-issues X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 07:45:13 -0000 I have reviewed this draft. This document is important and describes well the different issues associated with address sharing. I have asked for the IETF last call to be initiated. However, I did have a number of smaller issues that I hope you will correct during the last call. The main issue I had was about what the document said about IKE NAT traversal, but there were a few other issues and some editorial issues as well. > The completion of IPv4 address allocations from IANA and the 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. Solution- > specific discussions are out of scope. This text is the abstract. Later in the introduction you note that growing IPv6 use is the ultimate solution for reducing pressure on address sharing. I think it would be nice to see one sentence about the same thing here in the abstract as well. > In current deployments, one important and widely used feature of many > CPE devices is the ability to open incoming ports (port forwarding) > either manually, or with a protocol such as UPnP IGD. Reference and explanation of the UPnP IGD acronym is needed. > If a CGN is > present, the port must also be open in the CGN. opened? > In current deployments, one important and widely used feature of many > CPE devices is the ability to open incoming ports (port forwarding) > either manually, or with a protocol such as UPnP IGD. If a CGN is > present, the port must also be open in the CGN. The situation may be > alleviated somewhat if the CGN architecture is composed of only one > NAT level (no NAT in the CPE) as for DS-Lite, although a service > provider operating this solution will still be required to offer some > means for configuring incoming ports by their subscribers. This may > be either via a UPnP or NAT-PMP relay over a tunnelled direct > connection between the CPE and CGN, or a web interface to configure > the incoming port mapping on the CGN. I think this text could be improved. You need to make different points here. One point is that when the NAT moves from a CPE to a CGN device, the service provider has less incentives and even technical possibilities to proivde the port opening capability. Another point is that if two devices (the home gw and the CGN) need to co-operate in order to do this, then a new protocol is needed. > o Applications that do not use any port (e.g., ICMP) - where address > sharing solutions map subscribers to (private) IP addresses on a > one-to-one basis this will not be an issue, otherwise such > applications will require special handling - see Section 9 for > more discussion of this; > I'm not sure I understand this. First off, Section 9 clearly states that special handling is required anyway. In addition, the nature of the mapping (one to one or something else) does not seem to impact the handling of ICMP, because no matter what the mapping is, it won't be used by that special handling code as an incoming ICMP uses just public addresses. > For CGNs, subscribers will be dependent on the > set of ALGs that their service provider makes available. A > service provider-based NAT may, or may not, support NAT-traversal > for IKE [RFC3947 ] for example. This seems incorrect. IKE runs on UDP, and RFC 3947 is about endpoints working through NATs. The RFC even specifically mandates a change of the IKE port number in order to avoid some older NATs that might "help" IKE by doing something that ends up being harmful. In general, the draft seems to assume that ALGs are required. I think it would be fairer to say that they are required in some cases, and in many other cases end-to-end protocol mechanisms have developed to work around lack of ALGs, to the point of it being preferable to avoid any support in the NAT. > 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, and > sometimes in a different country, than the subscriber. Do we have evidence of real-life commercial ISP service with the NAT and the subscriber in different countries? I would think that is unlikely... just say "... in a different city than the subscriber". > here balancing > is achieved by deterministically routing traffic from specific source > IP addresses to specific servers, sudden imbalances in load may be > experienced as address sharing is enabled for some of those source IP > addresses. I think that sudden changes due to enabling address sharing is a rather theoretical problem. Its not like a subscriber's address is suddenly used by a CGN. More likely, CGN address pools are taken from address space that is currently unused or at least not recently used, and that growth in the traffic from a CGN happens gradually, as more subscribers get added to it. Jari From remi.despres@free.fr Tue Jan 18 02:48:27 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08A963A6F7C; Tue, 18 Jan 2011 02:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.425 X-Spam-Level: X-Spam-Status: No, score=-1.425 tagged_above=-999 required=5 tests=[AWL=0.524, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFXXlqNBohDy; Tue, 18 Jan 2011 02:48:26 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.83]) by core3.amsl.com (Postfix) with ESMTP id D7B523A6F6B; Tue, 18 Jan 2011 02:48:25 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2413.sfr.fr (SMTP Server) with ESMTP id 949B8700008D; Tue, 18 Jan 2011 11:51:01 +0100 (CET) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2413.sfr.fr (SMTP Server) with ESMTP id 02EBC7000088; Tue, 18 Jan 2011 11:51:00 +0100 (CET) X-SFR-UUID: 20110118105101120.02EBC7000088@msfrf2413.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> Date: Tue, 18 Jan 2011 11:50:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1082) Cc: Mark Smith , IPv6 Operations , Internet Area , Jack Bates Subject: Re: [Int-area] [v6ops] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 10:48:27 -0000 Fred. That's very much clarifying. Thank you. More comments in line. Le 17 janv. 2011 =E0 18:54, Fred Baker a =E9crit : > On Jan 17, 2011, at 9:27 AM, R=E9mi Despr=E9s wrote : > ... >>>>> By strictest definition, NAT66 has been implemented and deployed = already. >>>>=20 >>>> For clarification, could you be more specific: >>>> - NAT66 according to which specification? >>>> - where (for example)? >>>=20 >>> I thought this was answered. It's deployed by load balancers which = use NAT. >>=20 >> - An informational document on such a deployment would IMHO be = useful. >=20 > There's not much to write. It is pretty much standard practice.=20 >=20 > Case 1: it's literally a NAT; it redirects TCP sessions sent to a = common address to one of a number of servers. How it measures server = load varies; the server may inform it of what it considers its load to = be (a server with a few CPUs might get "loaded" more quickly than one = with many CPUs), the NAT box may try to keep a roughly equal number of = TCP sessions to each of several servers, or the NAT box might try to = maintain roughly equal traffic flow from each of several servers, = redirecting new sessions to whichever server currently has the lowest = load.=20 >=20 > Case 2: It's an application layer gateway that uses NAT technology to = accomplish its goals. The most common case is HTTP. The ALG may operate = by maintaining a pool of open TCP sessions with each of a set of (or = several discrete sets of) servers, or it may open up new sessions as = needed. In any event, it terminates an incoming HTTP session and goes = through an on/off pattern - it collects a "GET", determines which server = to send that to, obtains (opens or allocates) a TCP session to the = server, forwards the "GET" to the server, and uses NAT techniques to = maintain traffic flow between the server and the client. When the server = terminates the session, it does *not* pass that along; it instead awaits = the next GET. Note that different GET targets may be sent to different = servers or pools of servers. It's now clear that: (a) These scenarios differ from classical NAT scenarios (incoming = connections are THE subject, rather than having to be blocked).=20 (b) These NATs, to exercise their load-balancing function, do 1:n = mappings.=20 >> - =46rom your answer below, one can derive that the NAT66 spec you = refer to is NAPTv6 (for which there is so far no draft), and not = draft-mrw-nat66 (the only draft so far that specifies a NAT66). >=20 > It could be, but it doesn't have to be. In my understanding, because NAT mappings of *web-server load balancing* = need to be 1:n (point (b) above), this excludes in IPv6 that the NAT be = an NPTv6. (NPTv6 is inherently 1:1.) Contrary to what I wrote, this point isn't a matter of preference. It's = simply a technical obligation. > It is solving a different problem. > It is doing data center load balancing, which 6man is very carefully = avoiding looking at in its load balancing draft. That's, I guess, where I was confused. The conclusion then seems to be that: - So far, the *data-center load balancing* application isn't described = in any RFC, or even in any draft, but does exist and, in IPv6, uses some = NAT66. - For this application, which inherently needs 1:n mappings, the NAT66 = cannot be NPTv6. - If tunneling between the load balancer and servers would be used = instead of NAT66, load balancing would be achieved without sacrificing = e2e address transparency but this isn't the deployed approach. Regards, RD =20 From ford@isoc.org Tue Jan 18 04:06:17 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A38553A6F6B for ; Tue, 18 Jan 2011 04:06:17 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lm7qJu4qoxAL for ; Tue, 18 Jan 2011 04:06:16 -0800 (PST) Received: from smtp131.iad.emailsrvr.com (smtp131.iad.emailsrvr.com [207.97.245.131]) by core3.amsl.com (Postfix) with ESMTP id 5BC623A6ED4 for ; Tue, 18 Jan 2011 04:06:16 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp43.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 3B94A2D04F0; Tue, 18 Jan 2011 07:08:53 -0500 (EST) X-Virus-Scanned: OK Received: by smtp43.relay.iad1a.emailsrvr.com (Authenticated sender: ford-AT-isoc.org) with ESMTPSA id 4852E2D04C9; Tue, 18 Jan 2011 07:08:52 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Matthew Ford In-Reply-To: <4D35459F.6030500@piuha.net> Date: Tue, 18 Jan 2011 12:08:50 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D35459F.6030500@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1082) Cc: draft-ietf-intarea-shared-addressing-issues@tools.ietf.org, Internet Area Subject: Re: [Int-area] AD review of draft-ietf-intarea-shared-addressing-issues X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 12:06:17 -0000 Jari, Thanks for the review. Some responses inline below: On 18 Jan 2011, at 07:47, Jari Arkko wrote: >> The completion of IPv4 address allocations from IANA and the 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. Solution- >> specific discussions are out of scope. >=20 > This text is the abstract. Later in the introduction you note that = growing IPv6 use is the ultimate solution for reducing pressure on = address sharing. I think it would be nice to see one sentence about the = same thing here in the abstract as well. >=20 Agreed. >> In current deployments, one important and widely used feature of many >> CPE devices is the ability to open incoming ports (port forwarding) >> either manually, or with a protocol such as UPnP IGD.=20 >=20 > Reference and explanation of the UPnP IGD acronym is needed. >=20 Yes. >> If a CGN is >> present, the port must also be open in the CGN. =20 >=20 > opened? >=20 OK. >> In current deployments, one important and widely used feature of many >> CPE devices is the ability to open incoming ports (port forwarding) >> either manually, or with a protocol such as UPnP IGD. If a CGN is >> present, the port must also be open in the CGN. The situation may be >> alleviated somewhat if the CGN architecture is composed of only one >> NAT level (no NAT in the CPE) as for DS-Lite, although a service >> provider operating this solution will still be required to offer some >> means for configuring incoming ports by their subscribers. This may >> be either via a UPnP or NAT-PMP relay over a tunnelled direct >> connection between the CPE and CGN, or a web interface to configure >> the incoming port mapping on the CGN.=20 >=20 > I think this text could be improved. You need to make different points = here. One point is that when the NAT moves from a CPE to a CGN device, = the service provider has less incentives and even technical = possibilities to proivde the port opening capability. Another point is = that if two devices (the home gw and the CGN) need to co-operate in = order to do this, then a new protocol is needed. Sure, is this clearer? "In current deployments, one important and widely used feature of many CPE devices is the ability to open incoming ports (port forwarding) either manually, or with a protocol such as Universal Plug and Play Internet Gateway Device (UPnP IGD) [ref]. If a CGN is present, the=20 port must also be opened in the CGN. CGN makes subscribers dependent=20 on their service provider for this functionality. If the CPE and the CGN are required to co-operate in order for port = forwarding=20 functionality to work, protocol development will be required to provide = an automated=20 solution. If the CGN architecture is composed of only one NAT level (no = NAT in the CPE) as for DS-Lite, the service provider will still be required to = offer some=20 means for configuring incoming ports by their subscribers. This may be either via a UPnP or NAT-PMP relay over a tunnelled direct connection between the CPE and CGN, or a web interface to configure the incoming port mapping on the CGN." >=20 >> o Applications that do not use any port (e.g., ICMP) - where address >> sharing solutions map subscribers to (private) IP addresses on a >> one-to-one basis this will not be an issue, otherwise such >> applications will require special handling - see Section 9 = for >> more discussion of this; >> =20 >=20 > I'm not sure I understand this. First off, Section 9 clearly states = that special handling is required anyway. In addition, the nature of the = mapping (one to one or something else) does not seem to impact the = handling of ICMP, because no matter what the mapping is, it won't be = used by that special handling code as an incoming ICMP uses just public = addresses. >=20 You're right. It is sufficient to say 'Applications that do not use any = port (e.g., ICMP) - will require special handling - see Section 9...' >> For CGNs, subscribers will be dependent on the >> set of ALGs that their service provider makes available. A >> service provider-based NAT may, or may not, support NAT-traversal >> for IKE [RFC3947 ] for example.=20= >=20 > This seems incorrect. IKE runs on UDP, and RFC 3947 is about endpoints = working through NATs. The RFC even specifically mandates a change of the = IKE port number in order to avoid some older NATs that might "help" IKE = by doing something that ends up being harmful. Yes, I agree, bad example. >=20 > In general, the draft seems to assume that ALGs are required. I think = it would be fairer to say that they are required in some cases, and in = many other cases end-to-end protocol mechanisms have developed to work = around lack of ALGs, to the point of it being preferable to avoid any = support in the NAT. >=20 I'll add some text to the second bullet in Section 6 on p.12 and the = first bullet in Section 6 on p.13 to clarify this. >> 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, and >> sometimes in a different country, than the subscriber. >=20 > Do we have evidence of real-life commercial ISP service with the NAT = and the subscriber in different countries? I would think that is = unlikely... just say "... in a different city than the subscriber". I'm not aware of any concrete example, so you're proposed edit is fine = for me. >=20 >> here balancing >> is achieved by deterministically routing traffic from specific = source >> IP addresses to specific servers, sudden imbalances in load may be >> experienced as address sharing is enabled for some of those source = IP >> addresses.=20 >=20 > I think that sudden changes due to enabling address sharing is a = rather theoretical problem. Its not like a subscriber's address is = suddenly used by a CGN. More likely, CGN address pools are taken from = address space that is currently unused or at least not recently used, = and that growth in the traffic from a CGN happens gradually, as more = subscribers get added to it. >=20 Fair enough - I'll try to wordsmith a little to reflect your comment. Thanks again for the review, Mat From jari.arkko@piuha.net Tue Jan 18 04:25:26 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 633713A6E74 for ; Tue, 18 Jan 2011 04:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0W5evBRqRzE for ; Tue, 18 Jan 2011 04:25:25 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id B69E63A6E7B for ; Tue, 18 Jan 2011 04:25:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A8F072CC3A; Tue, 18 Jan 2011 14:28:00 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hewAZRQrWyxp; Tue, 18 Jan 2011 14:27:59 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id B83B62CC2D; Tue, 18 Jan 2011 14:27:59 +0200 (EET) Message-ID: <4D35874F.8090903@piuha.net> Date: Tue, 18 Jan 2011 14:27:59 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Matthew Ford References: <4D35459F.6030500@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-intarea-shared-addressing-issues@tools.ietf.org, Internet Area Subject: Re: [Int-area] AD review of draft-ietf-intarea-shared-addressing-issues X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 12:25:26 -0000 Matthew, >>> In current deployments, one important and widely used feature of many >>> CPE devices is the ability to open incoming ports (port forwarding) >>> either manually, or with a protocol such as UPnP IGD. If a CGN is >>> present, the port must also be open in the CGN. The situation may be >>> alleviated somewhat if the CGN architecture is composed of only one >>> NAT level (no NAT in the CPE) as for DS-Lite, although a service >>> provider operating this solution will still be required to offer some >>> means for configuring incoming ports by their subscribers. This may >>> be either via a UPnP or NAT-PMP relay over a tunnelled direct >>> connection between the CPE and CGN, or a web interface to configure >>> the incoming port mapping on the CGN. >>> >> I think this text could be improved. You need to make different points here. One point is that when the NAT moves from a CPE to a CGN device, the service provider has less incentives and even technical possibilities to proivde the port opening capability. Another point is that if two devices (the home gw and the CGN) need to co-operate in order to do this, then a new protocol is needed. >> > > Sure, is this clearer? > > "In current deployments, one important and widely used feature of many > CPE devices is the ability to open incoming ports (port forwarding) > either manually, or with a protocol such as Universal Plug and Play > Internet Gateway Device (UPnP IGD) [ref]. If a CGN is present, the > port must also be opened in the CGN. CGN makes subscribers dependent > on their service provider for this functionality. > > If the CPE and the CGN are required to co-operate in order for port forwarding > functionality to work, protocol development will be required to provide an automated > solution. If the CGN architecture is composed of only one NAT level (no NAT in > the CPE) as for DS-Lite, the service provider will still be required to offer some > means for configuring incoming ports by their subscribers. This may > be either via a UPnP or NAT-PMP relay over a tunnelled direct > connection between the CPE and CGN, or a web interface to configure > the incoming port mapping on the CGN." > Much better. Thanks. >>> o Applications that do not use any port (e.g., ICMP) - where address >>> sharing solutions map subscribers to (private) IP addresses on a >>> one-to-one basis this will not be an issue, otherwise such >>> applications will require special handling - see Section 9 for >>> more discussion of this; >>> >>> >> I'm not sure I understand this. First off, Section 9 clearly states that special handling is required anyway. In addition, the nature of the mapping (one to one or something else) does not seem to impact the handling of ICMP, because no matter what the mapping is, it won't be used by that special handling code as an incoming ICMP uses just public addresses. >> >> > > You're right. It is sufficient to say 'Applications that do not use any port (e.g., ICMP) - will require special handling - see Section 9...' > OK > >>> For CGNs, subscribers will be dependent on the >>> set of ALGs that their service provider makes available. A >>> service provider-based NAT may, or may not, support NAT-traversal >>> for IKE [RFC3947 ] for example. >>> >> This seems incorrect. IKE runs on UDP, and RFC 3947 is about endpoints working through NATs. The RFC even specifically mandates a change of the IKE port number in order to avoid some older NATs that might "help" IKE by doing something that ends up being harmful. >> > > Yes, I agree, bad example. > OK >> In general, the draft seems to assume that ALGs are required. I think it would be fairer to say that they are required in some cases, and in many other cases end-to-end protocol mechanisms have developed to work around lack of ALGs, to the point of it being preferable to avoid any support in the NAT. >> >> > > I'll add some text to the second bullet in Section 6 on p.12 and the first bullet in Section 6 on p.13 to clarify this. > Good. >>> 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, and >>> sometimes in a different country, than the subscriber. >>> >> Do we have evidence of real-life commercial ISP service with the NAT and the subscriber in different countries? I would think that is unlikely... just say "... in a different city than the subscriber". >> > > I'm not aware of any concrete example, so you're proposed edit is fine for me. > OK >>> here balancing >>> is achieved by deterministically routing traffic from specific source >>> IP addresses to specific servers, sudden imbalances in load may be >>> experienced as address sharing is enabled for some of those source IP >>> addresses. >>> >> I think that sudden changes due to enabling address sharing is a rather theoretical problem. Its not like a subscriber's address is suddenly used by a CGN. More likely, CGN address pools are taken from address space that is currently unused or at least not recently used, and that growth in the traffic from a CGN happens gradually, as more subscribers get added to it. >> >> > > Fair enough - I'll try to wordsmith a little to reflect your comment. > > Thanks again for the review, > Thanks for a very quick reply. Jari From ipng@69706e6720323030352d30312d31340a.nosense.org Tue Jan 18 04:31:30 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6F553A6ED0; Tue, 18 Jan 2011 04:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.486 X-Spam-Level: X-Spam-Status: No, score=-1.486 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+e-p7dZw0rR; Tue, 18 Jan 2011 04:31:29 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id 4C58A3A6F2F; Tue, 18 Jan 2011 04:31:29 -0800 (PST) Received: from 182-239-146-82.ip.adam.com.au ([182.239.146.82] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1PfAl4-0001Ez-AT; Tue, 18 Jan 2011 23:03:58 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 7B2143B335; Tue, 18 Jan 2011 23:03:57 +1030 (CST) Date: Tue, 18 Jan 2011 23:03:57 +1030 From: Mark Smith To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= Message-ID: <20110118230357.49ec2b52@opy.nosense.org> In-Reply-To: References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Operations , IPv6, Internet Area , Jack Bates Subject: Re: [Int-area] [v6ops] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 12:31:30 -0000 On Tue, 18 Jan 2011 11:50:55 +0100 R=C3=A9mi Despr=C3=A9s wrote: > Fred. > That's very much clarifying. > Thank you. >=20 > More comments in line. >=20 > Le 17 janv. 2011 =C3=A0 18:54, Fred Baker a =C3=A9crit : > > On Jan 17, 2011, at 9:27 AM, R=C3=A9mi Despr=C3=A9s wrote : > > ... > >>>>> By strictest definition, NAT66 has been implemented and deployed al= ready. > >>>>=20 > >>>> For clarification, could you be more specific: > >>>> - NAT66 according to which specification? > >>>> - where (for example)? > >>>=20 > >>> I thought this was answered. It's deployed by load balancers which us= e NAT. > >>=20 > >> - An informational document on such a deployment would IMHO be useful. > >=20 > > There's not much to write. It is pretty much standard practice.=20 > >=20 > > Case 1: it's literally a NAT; it redirects TCP sessions sent to a commo= n address to one of a number of servers. How it measures server load varies= ; the server may inform it of what it considers its load to be (a server wi= th a few CPUs might get "loaded" more quickly than one with many CPUs), the= NAT box may try to keep a roughly equal number of TCP sessions to each of = several servers, or the NAT box might try to maintain roughly equal traffic= flow from each of several servers, redirecting new sessions to whichever s= erver currently has the lowest load.=20 > >=20 > > Case 2: It's an application layer gateway that uses NAT technology to a= ccomplish its goals. The most common case is HTTP. The ALG may operate by m= aintaining a pool of open TCP sessions with each of a set of (or several di= screte sets of) servers, or it may open up new sessions as needed. In any e= vent, it terminates an incoming HTTP session and goes through an on/off pat= tern - it collects a "GET", determines which server to send that to, obtain= s (opens or allocates) a TCP session to the server, forwards the "GET" to t= he server, and uses NAT techniques to maintain traffic flow between the ser= ver and the client. When the server terminates the session, it does *not* p= ass that along; it instead awaits the next GET. Note that different GET tar= gets may be sent to different servers or pools of servers. >=20 > It's now clear that: > (a) These scenarios differ from classical NAT scenarios (incoming connect= ions are THE subject, rather than having to be blocked).=20 > (b) These NATs, to exercise their load-balancing function, do 1:n mapping= s.=20 >=20 > >> - From your answer below, one can derive that the NAT66 spec you refer= to is NAPTv6 (for which there is so far no draft), and not draft-mrw-nat66= (the only draft so far that specifies a NAT66). > >=20 > > It could be, but it doesn't have to be. >=20 > In my understanding, because NAT mappings of *web-server load balancing* = need to be 1:n I don't think NAPT is necessary to achieve that.=20 The fundamental goal of (web-)server "load balancing" is to represent externally a number of internal hosts as though they were a single host with a single address. Anycast achieves sharing a single address among multiple hosts, with the difference being that the load is sent to the host that the routing protocol determines is closest to the traffic source. "load balancing" can be achieved with a few fairly minor architectural modifications - place all the hosts effectively equidistant from the client(s), and have an upstream forwarding device (likely the hop directly before the hosts) use candidate destination host load as the metric to select one of the paths towards one of the hosts for new connections, and ensure all latter traffic for the same session/connection follows the same path towards the same previously selected host. This isn't functionally much different to per-session packet load balancing routers perform today when there are multiple FIB entries for the same destination out different interfaces. > (point (b) above), this excludes in IPv6 that the NAT be an NPTv6. > (NPTv6 is inherently 1:1.) > Contrary to what I wrote, this point isn't a matter of preference. It's s= imply a technical obligation. >=20 > > It is solving a different problem. > > It is doing data center load balancing, which 6man is very carefully av= oiding looking at in its load balancing draft. >=20 > That's, I guess, where I was confused. >=20 > The conclusion then seems to be that: > - So far, the *data-center load balancing* application isn't described in= any RFC, or even in any draft, but does exist and, in IPv6, uses some NAT6= 6. > - For this application, which inherently needs 1:n mappings, the NAT66 ca= nnot be NPTv6. > - If tunneling between the load balancer and servers would be used instea= d of NAT66, load balancing would be achieved without sacrificing e2e addres= s transparency but this isn't the deployed approach. >=20 I don't think tunnelling is necessary between the load balancer and the servers. All that is required is to be able to have the upstream forwarding device uniquely distinguish between the hosts despite them sharing the same IP address. Separate outbound interfaces directly attached to hosts, or separate destination link layer addresses that aren't determined via resolution of the load balanced anycast address would be adequate. (Tunnels is really just a form of the separate outbound interface method.) One method to achieve the separate destination link layer address method would be to have the load balanced anycast address configured on a loopback interface within the servers, and have the servers forward traffic between their external interface and the loopback (and make sure proxy-arp is off). The upstream load balancing forwarding device would use (load-balancing) routes with the hosts' external interface addresses as the next hops. Regards, Mark. From jbates@brightok.net Tue Jan 18 05:34:01 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 458D43A6FE6; Tue, 18 Jan 2011 05:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jozv85H27ccp; Tue, 18 Jan 2011 05:34:00 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id 6EC513A6FB6; Tue, 18 Jan 2011 05:34:00 -0800 (PST) Received: from [192.168.1.122] ([69.8.25.3]) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p0IDaRL9003705; Tue, 18 Jan 2011 07:36:27 -0600 (CST) Message-ID: <4D359757.5030409@brightok.net> Date: Tue, 18 Jan 2011 07:36:23 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mark Smith References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> <20110118230357.49ec2b52@opy.nosense.org> In-Reply-To: <20110118230357.49ec2b52@opy.nosense.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= , IPv6 Operations , Internet Area Subject: Re: [Int-area] [v6ops] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 13:34:01 -0000 On 1/18/2011 6:33 AM, Mark Smith wrote: > > I don't think NAPT is necessary to achieve that. > It's not. There is also DSR (Direct Server Return). However, neither is technically address transparent, as anycasting is anything but transparent in this case. > and ensure all latter > traffic for the same session/connection follows the same path towards > the same previously selected host. With some applications, it's also necessary to forward all traffic from the original sender towards the same selected host. This is usually optimized by only considering hosts with existing open mappings, so it doesn't utilize more memory than your method. One common application which needs this is imap. Depending on the web application and cross server session management, it also may require it. > One method to achieve the separate destination link layer address > method would be to have the load balanced anycast address > configured on a loopback interface within the servers, and have the > servers forward traffic between their external interface and the > loopback (and make sure proxy-arp is off). The upstream load balancing > forwarding device would use (load-balancing) routes with the hosts' > external interface addresses as the next hops. > There is no arp in v6. However, you've described DSR as it currently is. Jack (no coffee yet, so while it makes sense to me, forgive any mistakes) From iesg-secretary@ietf.org Tue Jan 18 07:04:46 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A73F28C151; Tue, 18 Jan 2011 07:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+n4zjRyw7+9; Tue, 18 Jan 2011 07:04:45 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 378EC3A6FFA; Tue, 18 Jan 2011 07:04:45 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110118150445.13842.1912.idtracker@localhost> Date: Tue, 18 Jan 2011 07:04:45 -0800 Cc: int-area@ietf.org Subject: [Int-area] Last Call: (Issues with IP Address Sharing) to Informational RFC X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 15:04:46 -0000 The IESG has received a request from the Internet Area Working Group WG (intarea) to consider the following document: - 'Issues with IP Address Sharing' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-02-01. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-intarea-shared-addressing-issues/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-intarea-shared-addressing-issues/ No IPR declarations have been submitted directly on this I-D. From fred@cisco.com Tue Jan 18 10:15:38 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95C6C3A7075; Tue, 18 Jan 2011 10:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.313 X-Spam-Level: X-Spam-Status: No, score=-110.313 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZ+svzHjh1tD; Tue, 18 Jan 2011 10:15:37 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id D9E8B3A6FE2; Tue, 18 Jan 2011 10:15:37 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOpnNU2rR7Ht/2dsb2JhbACkVHOoNZoJhVAEhG+GL4Mk Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 18 Jan 2011 18:18:15 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0IIIAdb017620; Tue, 18 Jan 2011 18:18:15 GMT Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Tue, 18 Jan 2011 10:18:15 -0800 X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Tue, 18 Jan 2011 10:18:15 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: Date: Tue, 18 Jan 2011 10:18:00 -0800 Message-Id: <936466CA-1532-4634-A13C-A29BCA71E829@cisco.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Mark Smith , IPv6 Operations , Internet Area , Jack Bates Subject: Re: [Int-area] [v6ops] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 18:15:38 -0000 On Jan 18, 2011, at 2:50 AM, R=E9mi Despr=E9s wrote: > (a) These scenarios differ from classical NAT scenarios (incoming = connections are THE subject, rather than having to be blocked).=20 Well, they differ from NAT scenarios that the IETF has considered. I = would object to the assertion that what you're calling a "traditional = NAT" has as its primary function to block sessions. A Network Address = Translator, in any usage, has as it primary function the translation of = network layer addresses. What you're pointing out is that any stateful = NAT (as opposed to that described in SIIT for example) has a "translated = from" and a "translated to" side and an algorithm by which it creates = its translation state. What you're calling a "traditional NAT" = translates "from" in "inside" domain and doesn't change the "outside" = destination address. A load balancer - which is in no sense a new use of = NAT technology, its just one the IETF hasn't focused on - translates = "from" the great wide world, and the algorithm by which it creates = translation state is more complex. > (b) These NATs, to exercise their load-balancing function, do 1:n = mappings.=20 That is certainly one way to do it. What I have tried to point out is = that there is a class of widely-used products that do.= From ipng@69706e6720323030352d30312d31340a.nosense.org Tue Jan 18 12:53:23 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CCA628C142; Tue, 18 Jan 2011 12:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.342 X-Spam-Level: X-Spam-Status: No, score=-1.342 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_BAYES_5x7=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDl1z3c38MeE; Tue, 18 Jan 2011 12:53:17 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id 1870528C156; Tue, 18 Jan 2011 12:53:17 -0800 (PST) Received: from 182-239-146-82.ip.adam.com.au ([182.239.146.82] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1PfIaX-0005Gt-5S; Wed, 19 Jan 2011 07:25:37 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 7A6F03B31E; Wed, 19 Jan 2011 07:25:36 +1030 (CST) Date: Wed, 19 Jan 2011 07:25:36 +1030 From: Mark Smith To: Jack Bates Message-ID: <20110119072536.6a5c150b@opy.nosense.org> In-Reply-To: <4D359757.5030409@brightok.net> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> <20110118230357.49ec2b52@opy.nosense.org> <4D359757.5030409@brightok.net> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= , IPv6 Operations , Internet Area Subject: Re: [Int-area] [v6ops] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 20:53:23 -0000 Hi Jack, On Tue, 18 Jan 2011 07:36:23 -0600 Jack Bates wrote: > On 1/18/2011 6:33 AM, Mark Smith wrote: > > > > I don't think NAPT is necessary to achieve that. > > > It's not. There is also DSR (Direct Server Return). However, neither is > technically address transparent, as anycasting is anything but > transparent in this case. The e2e transparency being talked about is that packets travel between the communication end-points without the end-point identifiers or the payloads being modified i.e. at the layer 3 devices between the end-points packets are conventionally forwarded rather than being both modified and forwarded. There are issues with anycast, mainly because anycast doesn't absolutely uniquely identify one (or both) of the communication end-points. That is no worse than NAT based load balancing. What is better with "anycast LB" is that there is no interference with the packets as they traverse the network. That interference has been the origin of some of the faults I've had to troubleshoot involving NAT based load balancers. My fundamental personal preference would be for people to deploy proper clustered operating systems (i.e. single system image) for their applications such that the server is truely one single system and end-point from the network's point of view, and there is no need to resort to networking tricks within the network to try to simulate that for external clients. That would mean no NAT and no anycast. I realise that may be an ideal, however the closer to that ideal the solutions are the less complexity and unconventional behaviour I as a networking person has to deal with. > > and ensure all latter > > traffic for the same session/connection follows the same path towards > > the same previously selected host. > With some applications, it's also necessary to forward all traffic from > the original sender towards the same selected host. This is usually > optimized by only considering hosts with existing open mappings, so it > doesn't utilize more memory than your method. One common application > which needs this is imap. Depending on the web application and cross > server session management, it also may require it. > > > One method to achieve the separate destination link layer address > > method would be to have the load balanced anycast address > > configured on a loopback interface within the servers, and have the > > servers forward traffic between their external interface and the > > loopback (and make sure proxy-arp is off). The upstream load balancing > > forwarding device would use (load-balancing) routes with the hosts' > > external interface addresses as the next hops. > > > > There is no arp in v6. Sure - proxy-arp was rush used word, I should have used proxy-neighbor discovery. > However, you've described DSR as it currently is. > If DSR is what is described at this web page, then not quite - http://lbwiki.com/index.php/DSR If the load balancer acts more like a router, and the router above it announces the best path towards the anycast LB address, then there is no need for the anycast LB address to be configured on the load balancing router itself. That might sound like a me being pedantic about the difference, however routers already forward packets in the way I'm describing (the difference is the policy applied to forwarding decisions), and therefore makes the networking component simper and more conventional. Regards, Mark. From jbates@brightok.net Tue Jan 18 13:14:05 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A3253A6F58; Tue, 18 Jan 2011 13:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.741 X-Spam-Level: X-Spam-Status: No, score=-1.741 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_BAYES_5x7=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBj7Po84RZkW; Tue, 18 Jan 2011 13:14:04 -0800 (PST) Received: from deimos.brightok.net (mail2.brightok.net [69.8.2.27]) by core3.amsl.com (Postfix) with ESMTP id 58F253A6E7B; Tue, 18 Jan 2011 13:14:03 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by deimos.brightok.net (8.13.6/8.13.6) with ESMTP id p0ILGVmJ001864; Tue, 18 Jan 2011 15:16:31 -0600 (CST) Message-ID: <4D36032E.7020006@brightok.net> Date: Tue, 18 Jan 2011 15:16:30 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mark Smith References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> <20110118230357.49ec2b52@opy.nosense.org> <4D359757.5030409@brightok.net> <20110119072536.6a5c150b@opy.nosense.org> In-Reply-To: <20110119072536.6a5c150b@opy.nosense.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= , IPv6 Operations , Internet Area Subject: Re: [Int-area] [v6ops] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 21:14:05 -0000 On 1/18/2011 2:55 PM, Mark Smith wrote: > My fundamental personal preference would be for people to deploy proper > clustered operating systems (i.e. single system image) for their > applications such that the server is truely one single system and > end-point from the network's point of view, and there is no need to > resort to networking tricks within the network to try to simulate that > for external clients. That would mean no NAT and no anycast. I realise > that may be an ideal, however the closer to that ideal the solutions > are the less complexity and unconventional behaviour I as a networking > person has to deal with. While I agree, I've yet to see a cost effective clustering mechanism for proper load distribution for simple things such as http/smtp/imap. This may be my own ignorance of current clustering functionality. > If the load balancer acts more like a router, and the router above it > announces the best path towards the anycast LB address, then there is > no need for the anycast LB address to be configured on the load > balancing router itself. That might sound like a me being pedantic > about the difference, however routers already forward packets in the > way I'm describing (the difference is the policy applied to forwarding > decisions), and therefore makes the networking component simper and more > conventional. I believe you are talking about my original mechanism for load balancing, which was to utilize routing protocols on the servers to announce to the router that a server was available. In general principle, it was effective, but only on a per flow basis (standard flow based balancing of routers insured that a connection held to a single server so long as it was active). I didn't see any options in current routers to support utilizing a single path for all packets from a source (required for when current state is only stored on one server and not shared by all servers). This last part was the deciding point for me to shift to DSR with a specialized load balancer. That being said, there are several things that NAT can do, which DSR cannot. This is one reason NAT is still often deployed over DSR in load balancing hardware. This has been magnified with the introduction of IPv6 to large scale production networks, where there is a need to run mixed environments supporting v6->v6 v6->v4 v4->v6 v4->v4 depending on the systems supported and the IP protocols used both public and internal. Jack From ek@google.com Tue Jan 18 16:44:43 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 137A83A7069 for ; Tue, 18 Jan 2011 16:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.65 X-Spam-Level: X-Spam-Status: No, score=-105.65 tagged_above=-999 required=5 tests=[AWL=-2.673, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlzJiyYEXNlE for ; Tue, 18 Jan 2011 16:44:42 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 853E63A6F78 for ; Tue, 18 Jan 2011 16:44:41 -0800 (PST) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id p0J0lI2E009709 for ; Tue, 18 Jan 2011 16:47:18 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1295398039; bh=yKLngDS8L0v525ztj7m6TDbsK+w=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=kJjmN5lOByQtMs30Ymzom0LMRh4XVR0/xumYxhAJPpUWtl6WL+Vl1pGZ5Wntt3GM3 jtULpLiN+fYNz/RdQs44Q== Received: from qyk12 (qyk12.prod.google.com [10.241.83.140]) by kpbe18.cbf.corp.google.com with ESMTP id p0J0lGpF002897 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 18 Jan 2011 16:47:17 -0800 Received: by qyk12 with SMTP id 12so271987qyk.5 for ; Tue, 18 Jan 2011 16:47:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IFGfe+DmQcS0Q2ghQXBpcTfDCGtA1Vy848YO3d3hVUg=; b=VM/lLrzEppI700Fj0BOlBKRCdApjCV5yIkQJWxk2+/qS9+ZvUA8ENj0RPGiC7zxWyq MKs3Zs63+wjJBeJjfpLA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=n+cGZ1PNiUiXlJuHXCluJKWtcfOumXhj5JutIt0sWEJDhHd04y+tyQBS1wg2FMA600 qiJJBbAxs4QTQd65HgdQ== MIME-Version: 1.0 Received: by 10.229.97.68 with SMTP id k4mr40353qcn.29.1295398036647; Tue, 18 Jan 2011 16:47:16 -0800 (PST) Received: by 10.229.106.201 with HTTP; Tue, 18 Jan 2011 16:47:16 -0800 (PST) In-Reply-To: <4D36032E.7020006@brightok.net> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> <20110118230357.49ec2b52@opy.nosense.org> <4D359757.5030409@brightok.net> <20110119072536.6a5c150b@opy.nosense.org> <4D36032E.7020006@brightok.net> Date: Wed, 19 Jan 2011 09:47:16 +0900 Message-ID: From: Erik Kline To: Jack Bates Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Mailman-Approved-At: Tue, 18 Jan 2011 16:55:26 -0800 Cc: Mark Smith , IPv6 Operations , Internet Area Subject: Re: [Int-area] [v6ops] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 00:44:43 -0000 > I believe you are talking about my original mechanism for load balancing, > which was to utilize routing protocols on the servers to announce to the > router that a server was available. In general principle, it was effective, > but only on a per flow basis (standard flow based balancing of routers > insured that a connection held to a single server so long as it was active). > I didn't see any options in current routers to support utilizing a single > path for all packets from a source (required for when current state is only > stored on one server and not shared by all servers). This last part was the > deciding point for me to shift to DSR with a specialized load balancer. Depending on the architecture, ECMP may help. From fred@cisco.com Tue Jan 18 20:02:25 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3799E28C121; Tue, 18 Jan 2011 20:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.463 X-Spam-Level: X-Spam-Status: No, score=-110.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzbgK6jA5Rnj; Tue, 18 Jan 2011 20:02:24 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 2C4D028C101; Tue, 18 Jan 2011 20:02:24 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAH/xNU2rR7Hu/2dsb2JhbACkQnOnMZo+hVAEhG+GL4Mk Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 19 Jan 2011 04:05:03 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0J44wtd025547; Wed, 19 Jan 2011 04:05:02 GMT Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Tue, 18 Jan 2011 20:05:03 -0800 X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Tue, 18 Jan 2011 20:05:03 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <4D36032E.7020006@brightok.net> Date: Tue, 18 Jan 2011 20:04:48 -0800 Message-Id: <0CA5348B-CB45-41CE-B7A7-BBA4A1EA9DE9@cisco.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> <20110118230357.49ec2b52@opy.nosense.org> <4D359757.5030409@brightok.net> <20110119072536.6a5c150b@opy.nosense.org> <4D36032E.7020006@brightok.net> To: Jack Bates X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Mark Smith , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , IPv6 Operations , Internet Area Subject: Re: [Int-area] [v6ops] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 04:02:25 -0000 On Jan 18, 2011, at 1:16 PM, Jack Bates wrote: > I didn't see any options in current routers to support utilizing a = single path for all packets from a source (required for when current = state is only stored on one server and not shared by all servers).=20 This confuses me. Let me give you two references, both found via Google. = http://www.juniper.net/techpubs/software/erx/erx50x/swconfig-routing-vol1/= html/ip-config11.html search for the word "hash". "Hashed - uses hashing of source and destination addresses to determine = which of the available paths in the ECMP set to use" = http://www.cisco.com/en/US/tech/tk827/tk831/technologies_tech_note09186a00= 80094806.shtml (for some reason, if you look at Google you would think we only do this = for IBGP or only for multicast; it applies to all routing protocols as = it is an attribute of CEF) "The session-to-path assignment is done using a hash function that takes = the source and destination IP addresses and, in recent releases of Cisco = IOS, a unique hash ID that randomizes the assignment across the = end-to-end path." I imagine you could find similar statements from any IP router vendor = out there. If your destination address (the address of the system you are routing = towards) is constant (the sessions are all with the same server = address), then any hash of the source and destination address should = come up with the same number for all sessions from any given source = address. Barring a change in routing, that would send them all down the = same path. Did I miss something?= From ek@google.com Tue Jan 18 20:09:12 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FD2528C119 for ; Tue, 18 Jan 2011 20:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.909 X-Spam-Level: X-Spam-Status: No, score=-105.909 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rC-9tRdWmfn2 for ; Tue, 18 Jan 2011 20:09:11 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 9C1EC28C12B for ; Tue, 18 Jan 2011 20:09:11 -0800 (PST) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id p0J4BnpH005999 for ; Tue, 18 Jan 2011 20:11:50 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1295410310; bh=dNH8NTCiUBrM25dVqY+Waf8AeIQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=UOmOvCj0wmO4kEE5iWf4mhVwTXE2lPd8pGo7hq6DUd2g8Denik5HD1Sh6NVXPmIOb UnKx6oraCUALwD65aocrA== Received: from qwi2 (qwi2.prod.google.com [10.241.195.2]) by hpaq3.eem.corp.google.com with ESMTP id p0J4Bl4i022875 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 18 Jan 2011 20:11:48 -0800 Received: by qwi2 with SMTP id 2so402162qwi.31 for ; Tue, 18 Jan 2011 20:11:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=x0bZeF1Fu1W7ZII06ubL4nWkosBcbdN6gzOAEeO7vhU=; b=JQsTtye/f2+uz30bRe3cxaqrdEFIOwmTIeIJkLrlBT8Ts6s3yj4kghYmI4B0dXlgdW tazby1yTWdC36/8MNHJw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=e7D3gPu4PzCEJw1cPYTzZDUSQFF0Wvn8XHhGaVGUE1o4ohvfQcTaGNIzJ2qKm18BPY lEBl7wM0+1d+j649Oo1A== MIME-Version: 1.0 Received: by 10.229.82.14 with SMTP id z14mr165425qck.257.1295410307044; Tue, 18 Jan 2011 20:11:47 -0800 (PST) Received: by 10.229.106.201 with HTTP; Tue, 18 Jan 2011 20:11:46 -0800 (PST) In-Reply-To: <0CA5348B-CB45-41CE-B7A7-BBA4A1EA9DE9@cisco.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> <20110118230357.49ec2b52@opy.nosense.org> <4D359757.5030409@brightok.net> <20110119072536.6a5c150b@opy.nosense.org> <4D36032E.7020006@brightok.net> <0CA5348B-CB45-41CE-B7A7-BBA4A1EA9DE9@cisco.com> Date: Wed, 19 Jan 2011 13:11:46 +0900 Message-ID: From: Erik Kline To: Fred Baker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: IPv6 Operations , Internet Area , Jack Bates Subject: Re: [Int-area] [v6ops] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 04:09:12 -0000 On 19 January 2011 13:04, Fred Baker wrote: > > On Jan 18, 2011, at 1:16 PM, Jack Bates wrote: > >> I didn't see any options in current routers to support utilizing a singl= e path for all packets from a source (required for when current state is on= ly stored on one server and not shared by all servers). > > This confuses me. Let me give you two references, both found via Google. > > http://www.juniper.net/techpubs/software/erx/erx50x/swconfig-routing-vol1= /html/ip-config11.html > search for the word "hash". > "Hashed - uses hashing of source and destination addresses to determine w= hich of the available paths in the ECMP set to use" > > http://www.cisco.com/en/US/tech/tk827/tk831/technologies_tech_note09186a0= 080094806.shtml > (for some reason, if you look at Google you would think we only do this f= or IBGP or only for multicast; it applies to all routing protocols as it is= an attribute of CEF) > "The session-to-path assignment is done using a hash function that takes = the source and destination IP addresses and, in recent releases of Cisco IO= S, a unique hash ID that randomizes the assignment across the end-to-end pa= th." > > I imagine you could find similar statements from any IP router vendor out= there. > > If your destination address (the address of the system you are routing to= wards) is constant (the sessions are all with the same server address), the= n any hash of the source and destination address should come up with the sa= me number for all sessions from any given source address. Barring a change = in routing, that would send them all down the same path. > > Did I miss something? There are load balancing systems that (IIRC) work pretty much exactly this = way. From fred@cisco.com Tue Jan 18 21:03:05 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 539C53A7084; Tue, 18 Jan 2011 21:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.464 X-Spam-Level: X-Spam-Status: No, score=-110.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7BAycTZxNf7; Tue, 18 Jan 2011 21:03:04 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 102263A6F5F; Tue, 18 Jan 2011 21:03:04 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAI//NU2rR7Hu/2dsb2JhbACkQnOnKZo9hVAEhG+GL4Mk Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 19 Jan 2011 05:05:42 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0J55WiS006987; Wed, 19 Jan 2011 05:05:42 GMT Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Tue, 18 Jan 2011 21:05:42 -0800 X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Tue, 18 Jan 2011 21:05:42 -0800 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: Date: Tue, 18 Jan 2011 21:05:21 -0800 Message-Id: <91B76858-C7AA-403D-AFB0-171B56F457CB@cisco.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> <20110118230357.49ec2b52@opy.nosense.org> <4D359757.5030409@brightok.net> <20110119072536.6a5c150b@opy.nosense.org> <4D36032E.7020006@brightok.net> <0CA5348B-CB45-41CE-B7A7-BBA 4A1EA9DE9@cisco.com> To: Erik Kline X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , Internet Area , Jack Bates Subject: Re: [Int-area] [v6ops] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 05:03:05 -0000 On Jan 18, 2011, at 8:11 PM, Erik Kline wrote: > On 19 January 2011 13:04, Fred Baker wrote: >>=20 >> On Jan 18, 2011, at 1:16 PM, Jack Bates wrote: >>=20 >>> I didn't see any options in current routers to support utilizing a = single path for all packets from a source (required for when current = state is only stored on one server and not shared by all servers). >>=20 >> This confuses me. Let me give you two references, both found via = Google. >>=20 >> = http://www.juniper.net/techpubs/software/erx/erx50x/swconfig-routing-vol1/= html/ip-config11.html >> search for the word "hash". >> "Hashed - uses hashing of source and destination addresses to = determine which of the available paths in the ECMP set to use" >>=20 >> = http://www.cisco.com/en/US/tech/tk827/tk831/technologies_tech_note09186a00= 80094806.shtml >> (for some reason, if you look at Google you would think we only do = this for IBGP or only for multicast; it applies to all routing protocols = as it is an attribute of CEF) >> "The session-to-path assignment is done using a hash function that = takes the source and destination IP addresses and, in recent releases of = Cisco IOS, a unique hash ID that randomizes the assignment across the = end-to-end path." >>=20 >> I imagine you could find similar statements from any IP router vendor = out there. >>=20 >> If your destination address (the address of the system you are = routing towards) is constant (the sessions are all with the same server = address), then any hash of the source and destination address should = come up with the same number for all sessions from any given source = address. Barring a change in routing, that would send them all down the = same path. >>=20 >> Did I miss something? >=20 > There are load balancing systems that (IIRC) work pretty much exactly = this way. Um. Yes. That's what these web pages describe...= From joelja@bogus.com Tue Jan 18 21:20:36 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DC9D3A6EEB; Tue, 18 Jan 2011 21:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.911 X-Spam-Level: X-Spam-Status: No, score=-101.911 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+oGJQ55IBTb; Tue, 18 Jan 2011 21:20:35 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 9EC7C3A6E40; Tue, 18 Jan 2011 21:20:34 -0800 (PST) Received: from joelja-mac.lan (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 p0J5N8Ru094710 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 19 Jan 2011 05:23:09 GMT (envelope-from joelja@bogus.com) Message-ID: <4D36753C.8070407@bogus.com> Date: Tue, 18 Jan 2011 21:23:08 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fred Baker References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> <20110118230357.49ec2b52@opy.nosense.org> <4D359757.5030409@brightok.net> <20110119072536.6a5c150b@opy.nosense.org> <4D36032E.7020006@brightok.net> <0CA5348B-CB45-41CE-B7A7-BBA4A1EA9DE9@cisco.com> In-Reply-To: <0CA5348B-CB45-41CE-B7A7-BBA4A1EA9DE9@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Internet Area , Jack Bates Subject: Re: [Int-area] [v6ops] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 05:20:36 -0000 On 1/18/11 8:04 PM, Fred Baker wrote: > > On Jan 18, 2011, at 1:16 PM, Jack Bates wrote: > >> I didn't see any options in current routers to support utilizing a >> single path for all packets from a source (required for when >> current state is only stored on one server and not shared by all >> servers). stateless layer 3 load balancer is what one is is looking for. in a former life we used one (built on an off the self l3 ethernet switch asic as the front-end for a cluster of firewalls). one such example of a product specfically for this purpose is: http://www.bladenetwork.net/iFlow.html > This confuses me. Let me give you two references, both found via > Google. > > http://www.juniper.net/techpubs/software/erx/erx50x/swconfig-routing-vol1/html/ip-config11.html > > search for the word "hash". > "Hashed - uses hashing of source and destination addresses to > determine which of the available paths in the ECMP set to use" > > http://www.cisco.com/en/US/tech/tk827/tk831/technologies_tech_note09186a0080094806.shtml > > (for some reason, if you look at Google you would think we only do this for IBGP or only for multicast; it applies to all routing protocols as it is an attribute of CEF) > "The session-to-path assignment is done using a hash function that > takes the source and destination IP addresses and, in recent releases > of Cisco IOS, a unique hash ID that randomizes the assignment across > the end-to-end path." > > I imagine you could find similar statements from any IP router vendor > out there. > > If your destination address (the address of the system you are > routing towards) is constant (the sessions are all with the same > server address), then any hash of the source and destination address > should come up with the same number for all sessions from any given > source address. Barring a change in routing, that would send them all > down the same path. > > Did I miss something? > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From magnus.westerlund@ericsson.com Wed Jan 19 00:28:00 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C11023A70DF; Wed, 19 Jan 2011 00:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.484 X-Spam-Level: X-Spam-Status: No, score=-106.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5DB8hE8T3Nb; Wed, 19 Jan 2011 00:28:00 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 5E4163A70D6; Wed, 19 Jan 2011 00:27:59 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-d3-4d36a12dd6a9 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A2.7C.13987.D21A63D4; Wed, 19 Jan 2011 09:30:37 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.2.234.1; Wed, 19 Jan 2011 09:30:37 +0100 Message-ID: <4D36A12C.9010301@ericsson.com> Date: Wed, 19 Jan 2011 09:30:36 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "apps-discuss@ietf.org" , Internet Area , rai-discuss@ietf.org, ops-area@ietf.org, SAAG X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [Int-area] Fwd: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 08:28:01 -0000 Hi, I just want to make people aware of this IETF last call for an update of the IANA procedures for registration of Service Name and Transport protocol port numbers. Best Regards Magnus Westerlund -------- Ursprungligt meddelande -------- Ämne: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Datum: Tue, 18 Jan 2011 22:26:03 +0100 Från: The IESG Till: IETF-Announce Kopia: tsvwg@ietf.org The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry' 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-02-01. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-ports/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-ports/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From remi.despres@free.fr Wed Jan 19 04:39:11 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C666E3A7102; Wed, 19 Jan 2011 04:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iCKHWP5ibLg; Wed, 19 Jan 2011 04:39:10 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by core3.amsl.com (Postfix) with ESMTP id 5EACE3A6FD9; Wed, 19 Jan 2011 04:39:10 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2217.sfr.fr (SMTP Server) with ESMTP id F2089700008B; Wed, 19 Jan 2011 13:41:49 +0100 (CET) Received: from [192.168.103.200] (pat46-invites.rennes.enst-bretagne.fr [192.44.77.46]) by msfrf2217.sfr.fr (SMTP Server) with ESMTP id 68DA17000087; Wed, 19 Jan 2011 13:41:49 +0100 (CET) X-SFR-UUID: 20110119124149429.68DA17000087@msfrf2217.sfr.fr Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <936466CA-1532-4634-A13C-A29BCA71E829@cisco.com> Date: Wed, 19 Jan 2011 13:41:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277357.2050109@sri.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> <936466CA-1532-4634-A13C-A29BCA71E829@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1082) Cc: Mark Smith , IPv6 Operations , Internet Area , Jack Bates Subject: Re: [Int-area] [v6ops] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 12:39:11 -0000 Le 18 janv. 2011 =E0 19:18, Fred Baker a =E9crit : >=20 > On Jan 18, 2011, at 2:50 AM, R=E9mi Despr=E9s wrote: >> (a) These scenarios differ from classical NAT scenarios (incoming = connections are THE subject, rather than having to be blocked).=20 >=20 > Well, they differ from NAT scenarios that the IETF has considered. OK > I would object to the assertion that what you're calling a = "traditional NAT" has as its primary function to block sessions. I didn't say is was their "primary" function, only that they had this = function. =3D> no reason to object (we agree). > A Network Address Translator, in any usage, has as it primary function = the translation of network layer addresses. > What you're pointing out is that any stateful NAT (as opposed to that = described in SIIT for example) has a "translated from" and a "translated = to" side and an algorithm by which it creates its translation state. If "translation from" is synonymous with "mappings initiated by outgoing = connections", we agree. > What you're calling a "traditional NAT" translates "from" in "inside" = domain and doesn't change the "outside" destination address. I only meant that traditional NAT's initiate their mappings with = outgoing connections, . > A load balancer - which is in no sense a new use of NAT technology, Not "new", I agree, but still different from IETF documented uses of = NATs. Again, thanks for having clarified that "data-center load balancing" was = THE scenario being discussed on this thread. > its just one the IETF hasn't focused on - translates "from" the great = wide world, and the algorithm by which it creates translation state is = more complex. OK >> (b) These NATs, to exercise their load-balancing function, do 1:n = mappings.=20 >=20 > That is certainly one way to do it. What I have tried to point out is = that there is a class of widely-used products that do. The point I made (important IMHO) is that, for data-center load = balancing, NPTv6 isn't applicable because its mappings are 1:1 while the = application requires 1:n. Can we agree on this too? Regards, RD =20 =20 From jbates@brightok.net Wed Jan 19 07:07:16 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7A583A7155; Wed, 19 Jan 2011 07:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.026 X-Spam-Level: X-Spam-Status: No, score=-2.026 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4LvUkzGmBE4; Wed, 19 Jan 2011 07:07:15 -0800 (PST) Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id D46C53A713E; Wed, 19 Jan 2011 07:07:15 -0800 (PST) Received: from [69.8.25.182] (fullmetal.brightok.net [69.8.25.182]) (authenticated bits=0) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p0JF9jbI015755; Wed, 19 Jan 2011 09:09:45 -0600 (CST) Message-ID: <4D36FEB9.4010803@brightok.net> Date: Wed, 19 Jan 2011 09:09:45 -0600 From: Jack Bates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fred Baker References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D277EA5.9080304@isi.edu> <4D278833.8090208@matthew.at> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> <20110118230357.49ec2b52@opy.nosense.org> <4D359757.5030409@brightok.net> <20110119072536.6a5c150b@opy.nosense.org> <4D36032E.7020006@brightok.net> <0CA5348B-CB45-41CE-B7A7-BBA4A1EA9DE9@cisco.com> In-Reply-To: <0CA5348B-CB45-41CE-B7A7-BBA4A1EA9DE9@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Smith , =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= , IPv6 Operations , Internet Area Subject: Re: [Int-area] [v6ops] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 15:07:16 -0000 On 1/18/2011 10:04 PM, Fred Baker wrote: > > On Jan 18, 2011, at 1:16 PM, Jack Bates wrote: > >> I didn't see any options in current routers to support utilizing a single path for all packets from a source (required for when current state is only stored on one server and not shared by all servers). > > This confuses me. Let me give you two references, both found via Google. > > I imagine you could find similar statements from any IP router vendor out there. > > If your destination address (the address of the system you are routing towards) is constant (the sessions are all with the same server address), then any hash of the source and destination address should come up with the same number for all sessions from any given source address. Barring a change in routing, that would send them all down the same path. > > Did I miss something? My erroneous use of the word "current" and vendor neutrality. My routers don't always use sourceIP/destIP as the only pieces of a hash. Even the cisco page mentions inclusion of a session ID and today supports 3 algorithms at the global level for cef load-sharing. We checked traffic decisions in the production network at the time we were looking for a solution and had various behaviors and few knobs. We deemed using routing tricks to be too unreliable and dangerous in the face of having to upgrade code regularly for better IPv6 support. Today, I utilize on a per service basis multiple policies. There are cases where I do not want a source address locked to a single server. The load balancer allows a much granular configuration over routing tricks. Jack From Internet-Drafts@ietf.org Wed Jan 19 10:30:02 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D9E03A7193; Wed, 19 Jan 2011 10:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HAxOrp663TP; Wed, 19 Jan 2011 10:30:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 943C93A704D; Wed, 19 Jan 2011 10:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110119183001.30410.51053.idtracker@localhost> Date: Wed, 19 Jan 2011 10:30:01 -0800 Cc: int-area@ietf.org Subject: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recommendations-01.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 18:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group Working Group of the IETF. Title : Logging recommendations for Internet facing servers Author(s) : A. Durand, et al. Filename : draft-ietf-intarea-server-logging-recommendations-01.txt Pages : 6 Date : 2011-01-19 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-intarea-server-logging-recommendations-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-intarea-server-logging-recommendations-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-19101519.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Wed Jan 19 10:30:09 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ECCA3A7195; Wed, 19 Jan 2011 10:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YD1O4I8b-HR; Wed, 19 Jan 2011 10:30:07 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 734FF3A704D; Wed, 19 Jan 2011 10:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110119183002.30410.51185.idtracker@localhost> Date: Wed, 19 Jan 2011 10:30:02 -0800 Cc: int-area@ietf.org Subject: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recommendations-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 18:30:09 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group Working Group of the IETF. Title : Logging recommendations for Internet facing servers Author(s) : A. Durand, et al. Filename : draft-ietf-intarea-server-logging-recommendations-02.txt Pages : 6 Date : 2011-01-19 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-intarea-server-logging-recommendations-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-intarea-server-logging-recommendations-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-19102410.I-D@ietf.org> --NextPart-- From ipng@69706e6720323030352d30312d31340a.nosense.org Wed Jan 19 12:59:01 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A51763A71C9; Wed, 19 Jan 2011 12:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmTqWaqk3oTH; Wed, 19 Jan 2011 12:59:00 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id 78DCA3A71C6; Wed, 19 Jan 2011 12:59:00 -0800 (PST) Received: from 182-239-146-82.ip.adam.com.au ([182.239.146.82] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Pff9o-0004fW-PS; Thu, 20 Jan 2011 07:31:32 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id C6D3B3B31E; Thu, 20 Jan 2011 07:31:31 +1030 (CST) Date: Thu, 20 Jan 2011 07:31:31 +1030 From: Mark Smith To: Jack Bates Message-ID: <20110120073131.462d3218@opy.nosense.org> In-Reply-To: <4D36FEB9.4010803@brightok.net> References: <54E900DC635DAB4DB7A6D799B3C4CD8E049C3E@PLSWM12A.ad.sprint.com> <4D2789AF.1050903@isi.edu> <4D278AE7.4080502@matthew.at> <4D278B93.8050903@isi.edu> <4D27D9EB.4010209@gont.com.ar> <54664744-255E-4702-A42F-E65B37FA9CE9@free.fr> <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <4D32E673.8010409@bogus.com> <20110117072258.35fe843d@opy.nosense.org> <4D34549F.4020601@brightok.net> <4882F44E-C708-4736-9C59-D6AA030FF3B5@free.fr> <4D347327.9040501@brightok.net> <8412CFE5-DB55-4EBD-AFEB-57D67E2F5C2F@cisco.com> <20110118230357.49ec2b52@opy.nosense.org> <4D359757.5030409@brightok.net> <20110119072536.6a5c150b@opy.nosense.org> <4D36032E.7020006@brightok.net> <0CA5348B-CB45-41CE-B7A7-BBA4A1EA9DE9@cisco.com> <4D36FEB9.4010803@brightok.net> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= , IPv6 Operations , Internet Area Subject: Re: [Int-area] [v6ops] End-to-end "address transparency" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 20:59:01 -0000 On Wed, 19 Jan 2011 09:09:45 -0600 Jack Bates wrote: > On 1/18/2011 10:04 PM, Fred Baker wrote: > > > > On Jan 18, 2011, at 1:16 PM, Jack Bates wrote: > > > >> I didn't see any options in current routers to support utilizing a single path for all packets from a source (required for when current state is only stored on one server and not shared by all servers). > > > > This confuses me. Let me give you two references, both found via Google. > > > > > > > I imagine you could find similar statements from any IP router vendor out there. > > > > If your destination address (the address of the system you are routing towards) is constant (the sessions are all with the same server address), then any hash of the source and destination address should come up with the same number for all sessions from any given source address. Barring a change in routing, that would send them all down the same path. > > > > Did I miss something? > > My erroneous use of the word "current" and vendor neutrality. > > My routers don't always use sourceIP/destIP as the only pieces of a > hash. Even the cisco page mentions inclusion of a session ID and today > supports 3 algorithms at the global level for cef load-sharing. We > checked traffic decisions in the production network at the time we were > looking for a solution and had various behaviors and few knobs. We > deemed using routing tricks to be too unreliable and dangerous in the > face of having to upgrade code regularly for better IPv6 support. > > Today, I utilize on a per service basis multiple policies. There are > cases where I do not want a source address locked to a single server. > The load balancer allows a much granular configuration over routing tricks. > When I mentioned what current routers are capable of doing regarding sessions, I was thinking about hashing. However, that was more of an example to show that routers are already capable of sending traffic with the same destination over more than one route in a session aware manner. I think though that the drawback of a simple hash is that it isn't load sensitive. So a forwarding method that actively chooses a destination server based on load is needed, and then subsequently all packets with the same source address and port need to be sent to the same selected server. I've realised that is describing policy routing/forwarding, where the source address and port as well as the destination address is used as a fib entry selector - when ever a new connection comes in, and a server is selected, then a policy route is installed to forward all subsequent traffic to the same server. I was hoping that it might be possible to avoid having to look at the traffic stream after that, and let the policy route take care of it, however those policy routes need to be removed when the session is finished, and I think the only way to know when remove them correctly would be to watch for e.g. TCP FIN/ACKs. Regards, Mark. From julienl@qualcomm.com Thu Jan 27 09:49:16 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22F153A69B8 for ; Thu, 27 Jan 2011 09:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.383 X-Spam-Level: X-Spam-Status: No, score=-106.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88ds4GR5vDT0 for ; Thu, 27 Jan 2011 09:49:15 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id F0F573A69B2 for ; Thu, 27 Jan 2011 09:49:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1296150739; x=1327686739; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"int-area@ietf.org"=20|CC:=20"d raft-ietf-intarea-server-logging-recommendations@tools.ie tf.org"=0D=0A=09,=0D=0A=09"christian.vogt@ericss on.com"=20|Subject:=20RE:=20 [Int-area]=20I-D=0D=0A=09Action:draft-ietf-intarea-server -logging-recommendations-02.txt|Thread-Topic:=20[Int-area ]=20I-D=0D=0A=09Action:draft-ietf-intarea-server-logging- recommendations-02.txt|Thread-Index:=20AQHLuAeRr9aobd9Hqk i8e/J8n8tjzpPlI7JA|Date:=20Thu,=2027=20Jan=202011=2017:52 :16=20+0000|Message-ID:=20<98A16B2D00B5724F81E80EF1927A02 9703FC95@nasanexd01e.na.qualcomm.com>|References:=20<2011 0119183002.30410.51185.idtracker@localhost>|In-Reply-To: =20<20110119183002.30410.51185.idtracker@localhost> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|x-originating-ip: =20[172.30.39.5]|Content-Type:=20text/plain=3B=20charset =3D"us-ascii"|Content-Transfer-Encoding:=20quoted-printab le|MIME-Version:=201.0; bh=UZvbul1nE3eV2a91nKJpWClo3fVr/eKx0eiLCEcjZj4=; b=q6Sc4w1Cw+5O+/n3v7p5e/5EYzJb6+SagAyhTq1rlwsdOkYbdNuo6Wq3 8ip39Q0ASRvfYyG2ZKi/rVZo6MCHxZ3DQyr2sY0LUOAii+pbvKKDALD8Y tLG1aTaG0QX/QC9G/wjMcTrOD7oyjHSOO39Sv4O5zCfNzWscV5F+YTRN7 c=; X-IronPort-AV: E=McAfee;i="5400,1158,6238"; a="72217199" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 27 Jan 2011 09:52:16 -0800 X-IronPort-AV: E=Sophos;i="4.60,386,1291622400"; d="scan'208";a="113059200" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 27 Jan 2011 09:52:16 -0800 Received: from NASANEXD01E.na.qualcomm.com ([fe80::6555:8c37:4ee3:efc4]) by nasanexhc08.na.qualcomm.com ([::1]) with mapi id 14.01.0218.012; Thu, 27 Jan 2011 09:52:16 -0800 From: "Laganier, Julien" To: "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recommendations-02.txt Thread-Index: AQHLuAeRr9aobd9Hqki8e/J8n8tjzpPlI7JA Date: Thu, 27 Jan 2011 17:52:16 +0000 Message-ID: <98A16B2D00B5724F81E80EF1927A029703FC95@nasanexd01e.na.qualcomm.com> References: <20110119183002.30410.51185.idtracker@localhost> In-Reply-To: <20110119183002.30410.51185.idtracker@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-intarea-server-logging-recommendations@tools.ietf.org" , "christian.vogt@ericsson.com" Subject: Re: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recommendations-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 17:49:16 -0000 Folks, We believe that the authors of draft-ietf-intarea-server-logging-recommenda= tions have addressed comments that were made at the last IETF meeting and o= n the mailing list thereafter: Title : Logging recommendations for Internet facing servers Author(s) : A. Durand, et al. Filename : draft-ietf-intarea-server-logging-recommendations-02.tx= t Pages : 6 Date : 2011-01-19 URL : http://tools.ietf.org/html/draft-ietf-intarea-server-log= ging-recommendations-02 This note initiate a two weeks Working Group Last Call. Please review the d= ocument and send your comments to the list and state whether or not you thi= nk this document is ready to be forwarded to IESG. The Working Group Last C= all closes on 2010-02-10 COB PST. Thank you for your support. --julien & christian From julienl@qualcomm.com Thu Jan 27 09:56:43 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3312B3A699E for ; Thu, 27 Jan 2011 09:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.392 X-Spam-Level: X-Spam-Status: No, score=-106.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ApwtQeGYXYH for ; Thu, 27 Jan 2011 09:56:42 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 36B473A68D7 for ; Thu, 27 Jan 2011 09:56:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1296151186; x=1327687186; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"Laganier,=20Julien"=20,=20" int-area@ietf.org"=0D=0A=09|CC:=20"dra ft-ietf-intarea-server-logging-recommendations@tools.ietf .org"=0D=0A=09,=0D=0A=09"christian.vogt@ericsson .com"=20|Subject:=20RE:=20[I nt-area]=09I-D=0D=0A=09Action:draft-ietf-intarea-server-l ogging-recommendations-02.txt|Thread-Topic:=20[Int-area] =09I-D=0D=0A=09Action:draft-ietf-intarea-server-logging-r ecommendations-02.txt|Thread-Index:=20AQHLvkv7/qw5OWJRtEO +RMQImcBZrA=3D=3D|Date:=20Thu,=2027=20Jan=202011=2017:59: 45=20+0000|Message-ID:=20<98A16B2D00B5724F81E80EF1927A029 70404BC@nasanexd01e.na.qualcomm.com>|References:=20<20110 119183002.30410.51185.idtracker@localhost>=0D=0A=20<98A16 B2D00B5724F81E80EF1927A029703FC95@nasanexd01e.na.qualcomm .com>|In-Reply-To:=20<98A16B2D00B5724F81E80EF1927A029703F C95@nasanexd01e.na.qualcomm.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|x-originating-ip:=20[172.30.39.5] |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=yRGPqcDu8UlZaNJw0Ej8cTIvCezUK6nWI1AWTlxwqmk=; b=T3/avmbqpoQAYOl6Snj4COjlOY7w7VH8Gkh+NdZUYN3/2OYTS1Sp3A+x XDTaRjxgf8LwY3BOaRgyWbt7PLITom6k3vQxYL4hD7puYw/XExApwK7MF H4oTGK4MVbE3dqLByvFXHbBlLAGQHrAiEwLXaCsZkQsFyZgm+Ukopv5G7 E=; X-IronPort-AV: E=McAfee;i="5400,1158,6239"; a="72000276" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 27 Jan 2011 09:59:46 -0800 X-IronPort-AV: E=Sophos;i="4.60,386,1291622400"; d="scan'208";a="25611678" Received: from nasanexhc09.na.qualcomm.com ([172.30.39.8]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 27 Jan 2011 09:59:46 -0800 Received: from NASANEXD01E.na.qualcomm.com ([fe80::6555:8c37:4ee3:efc4]) by nasanexhc09.na.qualcomm.com ([::1]) with mapi id 14.01.0218.012; Thu, 27 Jan 2011 09:59:46 -0800 From: "Laganier, Julien" To: "Laganier, Julien" , "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recommendations-02.txt Thread-Index: AQHLvkv7/qw5OWJRtEO+RMQImcBZrA== Date: Thu, 27 Jan 2011 17:59:45 +0000 Message-ID: <98A16B2D00B5724F81E80EF1927A02970404BC@nasanexd01e.na.qualcomm.com> References: <20110119183002.30410.51185.idtracker@localhost> <98A16B2D00B5724F81E80EF1927A029703FC95@nasanexd01e.na.qualcomm.com> In-Reply-To: <98A16B2D00B5724F81E80EF1927A029703FC95@nasanexd01e.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-intarea-server-logging-recommendations@tools.ietf.org" , "christian.vogt@ericsson.com" Subject: Re: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recommendations-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 17:56:43 -0000 Laganier, Julien wrote >=20 > This note initiate a two weeks Working Group Last Call. Please review > the document and send your comments to the list and state whether or > not you think this document is ready to be forwarded to IESG. The > Working Group Last Call closes on 2010-02-10 COB PST. I obviously didn't intend to start an already closed WGLC - I meant 2011-02= -10. --julien