From yiu_lee@cable.comcast.com Sat Jun 1 03:58:28 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022E321F8749 for ; Sat, 1 Jun 2013 03:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.231 X-Spam-Level: X-Spam-Status: No, score=-5.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlqJyknRyGMr for ; Sat, 1 Jun 2013 03:58:22 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE0D21F8746 for ; Sat, 1 Jun 2013 03:58:22 -0700 (PDT) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.74675077; Sat, 01 Jun 2013 04:56:27 -0600 Received: from PACDCEXHUB05.cable.comcast.com (24.40.56.122) by pacdcexhub03.cable.comcast.com (24.40.56.116) with Microsoft SMTP Server (TLS) id 14.2.318.1; Sat, 1 Jun 2013 06:58:18 -0400 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.207]) by pacdcexhub05.cable.comcast.com ([fe80::3d40:bdea:7266:7f5a%18]) with mapi id 14.02.0318.001; Sat, 1 Jun 2013 06:58:18 -0400 From: "Lee, Yiu" To: Softwires WG Thread-Topic: [Softwires] Working group last call for draft-ietf-softwire-dslite-mib-02 Thread-Index: AQHOXrbs9uhfGP23mEGIPxJsp3Cxfg== Date: Sat, 1 Jun 2013 10:58:17 +0000 Message-ID: In-Reply-To: <519EEABD.1090107@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [24.40.55.72] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3452914697_3355164" MIME-Version: 1.0 Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-dslite-mib-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 10:58:28 -0000 --B_3452914697_3355164 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit +1 which is needed for dslite On 5/24/13 12:21 AM, "Suresh Krishnan" wrote: >Hi all, > This message starts a two week softwire working group last call on >advancing the draft defining the DS-Lite MIB as a Standards Track RFC. >The authors believe that this version has addressed all the issues >raised until now on the document. The latest version of the draft is >available at > >http://www.ietf.org/id/draft-ietf-softwire-dslite-mib-02.txt >http://tools.ietf.org/html/draft-ietf-softwire-dslite-mib-02 > >Substantive comments and statements of support/opposition for advancing >this document should be directed to the mailing list. Editorial >suggestions can be sent directly to the authors. The chairs will send in >their comments as well during the last call period. This last call will >conclude on June 2, 2013. > >Regards, >Suresh & Yong > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires --B_3452914697_3355164 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVmQYJKoZIhvcNAQcCoIIVijCCFYYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzEwggU0MIIEHKADAgECAhEAzuhISIgzOwSitfbc2LN4WDANBgkqhkiG9w0BAQUFADCBkzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGll bnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMjA4MjgwMDAwMDBa Fw0xMzA4MjgyMzU5NTlaMCoxKDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2Fz dC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCscOeu5/EoYRdja1jb6L4x o0TIevelc17NsPuRHfr2z3BGUMbfsJY1p0uXO9+inBQoBXwb07ac3SbOjA/6Ef3NlMPItWdT RGeFL6e/sMju9RgVyJURFnFgp7tc2tffnPOupnKZeeRehXeEFjun6+GC6teb1kSMu+WMMaCa D7/XSK+Q+F0Udc2Av0/gUCkGfTDpNnYwutfctEMRnle6EYUqmJMN4C0crEfovmYdMFFgJLKs Wa5Cdc+naFoIqzW8AcZB6+1XUDTzFbgjqgUbFFZFPzVZqNxLDFNy4tn8VlRSp2jBhgwQHtk1 ZA+spFENaeUuebp4tczj0IHG683FhhWjAgMBAAGjggHpMIIB5TAfBgNVHSMEGDAWgBR6E04A dFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUz03csl7CmjwQY+spX9VWeGb5sVQwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEB AwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkG CCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEyg SqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0 dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2Vj dXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAk BgNVHREEHTAbgRl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQBG7LORtWcmzDlw0N/D5AwfsSLe93essAqKFhJ+nt7SmMVBsxGzFnSsZGQHMYQ4UXtiVq9A NjtPk00F3DC3QGxe4mxdwF9LzeYHpHMpCHTzNyilSimKZolLNBO+MO/U0u79rdF2W+dOAwkB dzroWBxK+yMhijJn2DCE/1pgxqBz+c9zbAtJYPVpgbeGNvvfIp6CA/JYsupQNqPX49a4MdJ3 L9yXLTiegSE8uPUlCB3sHZclQOXAttuMewpcKDoIC4wZgERKQqRH61PQO100GLKUO+VrTq+f xNkjOAqA+dih6QO5Djbv3qcMTCcAChJQYK8BS7jved8XgEVa0Ihz7oWKMIIFGjCCBAKgAwIB AgIQbRnqpxlPajMi5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tX mNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vx aa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrl VICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hR mWONGoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0j BBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8 ecV7MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYE VR0gADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVT RVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRo MGYwPQYIKwYBBQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENs aWVudF9DQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJ KoZIhvcNAQEFBQADggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtz bj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqT ecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPN M1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZ htZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/ bucwggSdMIIDhaADAgECAhA0PekrrCc0/4/LNJT7zHBUMA0GCSqGSIb3DQEBBQUAMG8xCzAJ BgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0 ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw HhcNMDUwNjA3MDgwOTEwWhcNMjAwNTMwMTA0ODM4WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNV BAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMT LVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjM apjVTTUZuaRC5c5J4oovHnzSMQfHTrSDZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKT zMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1lepS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZG zaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGoLhu21DEgLLyCio6kDqXXiUP8FlqvHXHX EVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0YqoYymiTHqGFfvVHZcv4TVcodNI0 /zC27vZiMBSMLOsCAwEAAaOB9DCB8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtU GjAdBgNVHQ4EFgQUiYJnfcSdJnAAS7RQSHzePa4Ebn0wDgYDVR0PAQH/BAQDAgEGMA8GA1Ud EwEB/wQFMAMBAf8wEQYDVR0gBAowCDAGBgRVHSAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6 Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA1BggrBgEF BQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZI hvcNAQEFBQADggEBAAG8nONjKLDzMQHC33vdYqABnSMxD5ySc1NR6h9M+tafxMovZ354Mw90 FrmRh5H1iib6ZHAA2B75CwRiUIeTgdTa9SPbNLuFVrRwNG54gzcehRzFERWSX4cXvaxq/fHC 0cyJX7F88D5R8jXzfOxgmGs6K+Dv37N9huu1G/Vb7KJ8mBPXAFC50S1z3gN4dOEFhTFey5q5 nZTGuZQ3dXLcRPtn6PD6JR5Sp9ol6UfgoMc8oE6xCjb7d0if75eK+7T+45QUqIO8XC0/0mBx YO7CcYIM6Yg249ogtKOgbKqWS7iAjnXKSQf2OxS639wF2Z/b4LLmTaB4JufnLW5/X8YeiBUw ggQ2MIIDHqADAgECAgEBMA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQK EwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDAwNTMwMTA0ODM4WhcN MjAwNTMwMTA0ODM4WjBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAk BgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVz dCBFeHRlcm5hbCBDQSBSb290MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/ca M+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ekKUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJ etsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU6cZfD3idmkA8Dqxhql4Uj56HoWpQ3Nea Tq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOrOk+E2N/On+Fpb7vXQtdrROTHre5t QV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe01sTurM0TRLfJK91DACX6Yblp algjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwIDAQABo4HcMIHZMB0GA1Ud DgQWBBStvZh6NLQm9/rEJlTvA73gJMtUGjALBgNVHQ8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB /zCBmQYDVR0jBIGRMIGOgBStvZh6NLQm9/rEJlTvA73gJMtUGqFzpHEwbzELMAkGA1UEBhMC U0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBU VFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdIIBATANBgkq hkiG9w0BAQUFAAOCAQEAsJvghSXC1iPiD5YGkp1BmJzZhHmB2R5bFAcjNmWPsNh3u6xBbEdg g1Gw+TI95/z2JhPHgBalv1r8h894eYkhmuJMBwqGNbzy3lHE0pa33H5O7nD9HDnrDAJRFC2O vRbgwd9Gdeckrez0QrSFk3AQZ7qdBjVKGNMresxRQqF6Y9Hmu6HFK8I2vhMN5r1jfnl7pwkN QKtq3Y+Kw/b2jBpCBVHURfWfp2IhaBUgQzyZ53y9JNipkRdziD9WGzE4GLRxD5rNyA6eji4b 4YyYg8sfMfFETMYEc0l2YA/H+L0XgGsu6cxMDlqaeQ8gCi7VnmMmHlWSlNiCF1p70LzHj06G BDGCAjAwggIsAgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEAzuhISIgzOwSitfbc2LN4WDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFBL+ uNh01E7IiIYe3keaqFYfaxSKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEzMDYwMTEwNTgxNlowDQYJKoZIhvcNAQEBBQAEggEAfJ1bWgotOkb0YbwXyS+0 lRCXoeuZT/B9RIbDKQqwTZ29VKfVJZpgdFWkRE5Ya0A8D1KMvd6EU3P/4bqFUTRyyw4i168D NT33VI+wH8pnJuYKjXUDvGhJP8+Ou4KRzE5n3+NgWM1mhIg9BYkLufiL1BaSwtp6zcVwwTUZ TqKuLY6XNBu8lBU/kUFn4CDLP8vzU5S38e8Q7pOmZWCbfNhiaNBir09KPWWX48W8Y3Xg3r0M nWMxpmjfarBOOw06zjmGr3Tfk0Yf8+IqyNsXBP2Je1DVldKVrHpje7n3dy+on2TfC97JOuHF Gi1ypKFkoeCzJg81gep8Lte1xDQif05rcw== --B_3452914697_3355164-- From yiu_lee@cable.comcast.com Sat Jun 1 03:58:48 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600EC21F89A5 for ; Sat, 1 Jun 2013 03:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.064 X-Spam-Level: X-Spam-Status: No, score=-3.064 tagged_above=-999 required=5 tests=[AWL=-2.167, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZie2eHmRI8w for ; Sat, 1 Jun 2013 03:58:43 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 2064421F8956 for ; Sat, 1 Jun 2013 03:58:43 -0700 (PDT) Received: from ([24.40.56.115]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.54178957; Sat, 01 Jun 2013 06:56:30 -0400 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.207]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Sat, 1 Jun 2013 06:58:41 -0400 From: "Lee, Yiu" To: Softwires WG Thread-Topic: [Softwires] Call for adoption of draft-fu-softwire-map-mib-05 as wg draft Thread-Index: AQHOXrb5kwGmCKsa90mq3UYNhZIYUw== Date: Sat, 1 Jun 2013 10:58:40 +0000 Message-ID: In-Reply-To: <519EE777.2040407@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [24.40.55.72] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3452914720_3365552" MIME-Version: 1.0 Subject: Re: [Softwires] Call for adoption of draft-fu-softwire-map-mib-05 as wg draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 10:58:48 -0000 --B_3452914720_3365552 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit +1 supported On 5/24/13 12:07 AM, "Suresh Krishnan" wrote: >Hi all, > This call is being initiated to determine whether there is WG >consensus towards adoption of draft-fu-softwire-map-mib-05 as a softwire >WG draft. Please state whether or not you're in favor of the adoption by >replying to this email. If you are not in favor, please also state your >objections in your response. The call will complete at midnight PDT on >2013-06-02. > >Regards >Suresh & Yong > > > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires --B_3452914720_3365552 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVmQYJKoZIhvcNAQcCoIIVijCCFYYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzEwggU0MIIEHKADAgECAhEAzuhISIgzOwSitfbc2LN4WDANBgkqhkiG9w0BAQUFADCBkzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGll bnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMjA4MjgwMDAwMDBa Fw0xMzA4MjgyMzU5NTlaMCoxKDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2Fz dC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCscOeu5/EoYRdja1jb6L4x o0TIevelc17NsPuRHfr2z3BGUMbfsJY1p0uXO9+inBQoBXwb07ac3SbOjA/6Ef3NlMPItWdT RGeFL6e/sMju9RgVyJURFnFgp7tc2tffnPOupnKZeeRehXeEFjun6+GC6teb1kSMu+WMMaCa D7/XSK+Q+F0Udc2Av0/gUCkGfTDpNnYwutfctEMRnle6EYUqmJMN4C0crEfovmYdMFFgJLKs Wa5Cdc+naFoIqzW8AcZB6+1XUDTzFbgjqgUbFFZFPzVZqNxLDFNy4tn8VlRSp2jBhgwQHtk1 ZA+spFENaeUuebp4tczj0IHG683FhhWjAgMBAAGjggHpMIIB5TAfBgNVHSMEGDAWgBR6E04A dFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUz03csl7CmjwQY+spX9VWeGb5sVQwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEB AwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkG CCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEyg SqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0 dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2Vj dXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAk BgNVHREEHTAbgRl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQBG7LORtWcmzDlw0N/D5AwfsSLe93essAqKFhJ+nt7SmMVBsxGzFnSsZGQHMYQ4UXtiVq9A NjtPk00F3DC3QGxe4mxdwF9LzeYHpHMpCHTzNyilSimKZolLNBO+MO/U0u79rdF2W+dOAwkB dzroWBxK+yMhijJn2DCE/1pgxqBz+c9zbAtJYPVpgbeGNvvfIp6CA/JYsupQNqPX49a4MdJ3 L9yXLTiegSE8uPUlCB3sHZclQOXAttuMewpcKDoIC4wZgERKQqRH61PQO100GLKUO+VrTq+f xNkjOAqA+dih6QO5Djbv3qcMTCcAChJQYK8BS7jved8XgEVa0Ihz7oWKMIIFGjCCBAKgAwIB AgIQbRnqpxlPajMi5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tX mNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vx aa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrl VICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hR mWONGoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0j BBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8 ecV7MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYE VR0gADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVT RVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRo MGYwPQYIKwYBBQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENs aWVudF9DQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJ KoZIhvcNAQEFBQADggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtz bj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqT ecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPN M1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZ htZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/ bucwggSdMIIDhaADAgECAhA0PekrrCc0/4/LNJT7zHBUMA0GCSqGSIb3DQEBBQUAMG8xCzAJ BgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0 ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw HhcNMDUwNjA3MDgwOTEwWhcNMjAwNTMwMTA0ODM4WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNV BAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMT LVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjM apjVTTUZuaRC5c5J4oovHnzSMQfHTrSDZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKT zMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1lepS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZG zaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGoLhu21DEgLLyCio6kDqXXiUP8FlqvHXHX EVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0YqoYymiTHqGFfvVHZcv4TVcodNI0 /zC27vZiMBSMLOsCAwEAAaOB9DCB8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtU GjAdBgNVHQ4EFgQUiYJnfcSdJnAAS7RQSHzePa4Ebn0wDgYDVR0PAQH/BAQDAgEGMA8GA1Ud EwEB/wQFMAMBAf8wEQYDVR0gBAowCDAGBgRVHSAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6 Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA1BggrBgEF BQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZI hvcNAQEFBQADggEBAAG8nONjKLDzMQHC33vdYqABnSMxD5ySc1NR6h9M+tafxMovZ354Mw90 FrmRh5H1iib6ZHAA2B75CwRiUIeTgdTa9SPbNLuFVrRwNG54gzcehRzFERWSX4cXvaxq/fHC 0cyJX7F88D5R8jXzfOxgmGs6K+Dv37N9huu1G/Vb7KJ8mBPXAFC50S1z3gN4dOEFhTFey5q5 nZTGuZQ3dXLcRPtn6PD6JR5Sp9ol6UfgoMc8oE6xCjb7d0if75eK+7T+45QUqIO8XC0/0mBx YO7CcYIM6Yg249ogtKOgbKqWS7iAjnXKSQf2OxS639wF2Z/b4LLmTaB4JufnLW5/X8YeiBUw ggQ2MIIDHqADAgECAgEBMA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQK EwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDAwNTMwMTA0ODM4WhcN MjAwNTMwMTA0ODM4WjBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAk BgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVz dCBFeHRlcm5hbCBDQSBSb290MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/ca M+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ekKUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJ etsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU6cZfD3idmkA8Dqxhql4Uj56HoWpQ3Nea Tq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOrOk+E2N/On+Fpb7vXQtdrROTHre5t QV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe01sTurM0TRLfJK91DACX6Yblp algjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwIDAQABo4HcMIHZMB0GA1Ud DgQWBBStvZh6NLQm9/rEJlTvA73gJMtUGjALBgNVHQ8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB /zCBmQYDVR0jBIGRMIGOgBStvZh6NLQm9/rEJlTvA73gJMtUGqFzpHEwbzELMAkGA1UEBhMC U0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBU VFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdIIBATANBgkq hkiG9w0BAQUFAAOCAQEAsJvghSXC1iPiD5YGkp1BmJzZhHmB2R5bFAcjNmWPsNh3u6xBbEdg g1Gw+TI95/z2JhPHgBalv1r8h894eYkhmuJMBwqGNbzy3lHE0pa33H5O7nD9HDnrDAJRFC2O vRbgwd9Gdeckrez0QrSFk3AQZ7qdBjVKGNMresxRQqF6Y9Hmu6HFK8I2vhMN5r1jfnl7pwkN QKtq3Y+Kw/b2jBpCBVHURfWfp2IhaBUgQzyZ53y9JNipkRdziD9WGzE4GLRxD5rNyA6eji4b 4YyYg8sfMfFETMYEc0l2YA/H+L0XgGsu6cxMDlqaeQ8gCi7VnmMmHlWSlNiCF1p70LzHj06G BDGCAjAwggIsAgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEAzuhISIgzOwSitfbc2LN4WDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFCuC Q070/YxoMtTr41Al3GxhOm4lMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEzMDYwMTEwNTgzOVowDQYJKoZIhvcNAQEBBQAEggEApURTbjKPMDFSqhQNS8J0 DaKUyp1vB913OHBrao8RcdqqqKvJsqUA4A5JKL2+as/bAsPitz3Hstffc7+oKSCrvOf16tT6 ppm3x+fX9+/a7pUBPa0evgSYlBwewet8TqUmlyrLPHLFZAJ1v70F0cOs2NZQpUAvzpFsBigh ERR9xT8vxys1rG5+OAg4Qw+gyHLEvHeIHh+Cg1sOYqnEyPzi14c8n6XRJqndnb4jXva1rhBU Q6e5KP8yI1lI10yCBpKTgsIjkKXMUE/8Uwtn8H3fYdw7MGv+dJKm2rDzXzjVazC9HEeulun0 SUjC3ectZ1Sh8yeXds2QTeqtLw5X4eTRMA== --B_3452914720_3365552-- From yiu_lee@cable.comcast.com Sat Jun 1 03:59:03 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D8C21F85B8 for ; Sat, 1 Jun 2013 03:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.981 X-Spam-Level: X-Spam-Status: No, score=-1.981 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geLDWl8AT4oZ for ; Sat, 1 Jun 2013 03:58:58 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 6130721F8749 for ; Sat, 1 Jun 2013 03:58:54 -0700 (PDT) Received: from ([24.40.56.115]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.54178965; Sat, 01 Jun 2013 06:56:41 -0400 Received: from PACDCEXHUB04.cable.comcast.com (24.40.56.121) by PACDCEXHUB02.cable.comcast.com (24.40.56.115) with Microsoft SMTP Server (TLS) id 14.2.318.1; Sat, 1 Jun 2013 06:58:53 -0400 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.207]) by pacdcexhub04.cable.comcast.com ([fe80::1532:d330:f9a5:c8a1%18]) with mapi id 14.02.0318.001; Sat, 1 Jun 2013 06:58:52 -0400 From: "Lee, Yiu" To: Softwires WG Thread-Topic: [Softwires] Working group last call for draft-ietf-softwire-mesh-mib-03 Thread-Index: AQHOXrcAWTqckeUiOEG6XOOZiqZUSw== Date: Sat, 1 Jun 2013 10:58:52 +0000 Message-ID: In-Reply-To: <519EEA1E.5090006@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [24.40.55.72] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3452914731_3381993" MIME-Version: 1.0 Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-mesh-mib-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 10:59:04 -0000 --B_3452914731_3381993 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit +1 supported On 5/24/13 12:18 AM, "Suresh Krishnan" wrote: >Hi all, > This message starts a two week softwire working group last call on >advancing the draft defining the Softwire Mesh MIB as a Standards Track >RFC. The authors believe that this version has addressed all the issues >raised until now on the document. The latest version of the draft is >available at > >http://www.ietf.org/id/draft-ietf-softwire-mesh-mib-03.txt >http://tools.ietf.org/html/draft-ietf-softwire-mesh-mib-03 > >Substantive comments and statements of support/opposition for advancing >this document should be directed to the mailing list. Editorial >suggestions can be sent directly to the authors. The chairs will send in >their comments as well during the last call period. This last call will >conclude on June 2, 2013. > >Regards, >Suresh & Yong > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires --B_3452914731_3381993 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVmQYJKoZIhvcNAQcCoIIVijCCFYYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzEwggU0MIIEHKADAgECAhEAzuhISIgzOwSitfbc2LN4WDANBgkqhkiG9w0BAQUFADCBkzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGll bnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMjA4MjgwMDAwMDBa Fw0xMzA4MjgyMzU5NTlaMCoxKDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2Fz dC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCscOeu5/EoYRdja1jb6L4x o0TIevelc17NsPuRHfr2z3BGUMbfsJY1p0uXO9+inBQoBXwb07ac3SbOjA/6Ef3NlMPItWdT RGeFL6e/sMju9RgVyJURFnFgp7tc2tffnPOupnKZeeRehXeEFjun6+GC6teb1kSMu+WMMaCa D7/XSK+Q+F0Udc2Av0/gUCkGfTDpNnYwutfctEMRnle6EYUqmJMN4C0crEfovmYdMFFgJLKs Wa5Cdc+naFoIqzW8AcZB6+1XUDTzFbgjqgUbFFZFPzVZqNxLDFNy4tn8VlRSp2jBhgwQHtk1 ZA+spFENaeUuebp4tczj0IHG683FhhWjAgMBAAGjggHpMIIB5TAfBgNVHSMEGDAWgBR6E04A dFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUz03csl7CmjwQY+spX9VWeGb5sVQwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEB AwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkG CCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEyg SqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0 dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2Vj dXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAk BgNVHREEHTAbgRl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQBG7LORtWcmzDlw0N/D5AwfsSLe93essAqKFhJ+nt7SmMVBsxGzFnSsZGQHMYQ4UXtiVq9A NjtPk00F3DC3QGxe4mxdwF9LzeYHpHMpCHTzNyilSimKZolLNBO+MO/U0u79rdF2W+dOAwkB dzroWBxK+yMhijJn2DCE/1pgxqBz+c9zbAtJYPVpgbeGNvvfIp6CA/JYsupQNqPX49a4MdJ3 L9yXLTiegSE8uPUlCB3sHZclQOXAttuMewpcKDoIC4wZgERKQqRH61PQO100GLKUO+VrTq+f xNkjOAqA+dih6QO5Djbv3qcMTCcAChJQYK8BS7jved8XgEVa0Ihz7oWKMIIFGjCCBAKgAwIB AgIQbRnqpxlPajMi5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tX mNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vx aa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrl VICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hR mWONGoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0j BBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8 ecV7MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYE VR0gADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVT RVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRo MGYwPQYIKwYBBQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENs aWVudF9DQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJ KoZIhvcNAQEFBQADggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtz bj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqT ecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPN M1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZ htZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/ bucwggSdMIIDhaADAgECAhA0PekrrCc0/4/LNJT7zHBUMA0GCSqGSIb3DQEBBQUAMG8xCzAJ BgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0 ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw HhcNMDUwNjA3MDgwOTEwWhcNMjAwNTMwMTA0ODM4WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNV BAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMT LVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjM apjVTTUZuaRC5c5J4oovHnzSMQfHTrSDZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKT zMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1lepS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZG zaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGoLhu21DEgLLyCio6kDqXXiUP8FlqvHXHX EVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0YqoYymiTHqGFfvVHZcv4TVcodNI0 /zC27vZiMBSMLOsCAwEAAaOB9DCB8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtU GjAdBgNVHQ4EFgQUiYJnfcSdJnAAS7RQSHzePa4Ebn0wDgYDVR0PAQH/BAQDAgEGMA8GA1Ud EwEB/wQFMAMBAf8wEQYDVR0gBAowCDAGBgRVHSAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6 Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA1BggrBgEF BQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZI hvcNAQEFBQADggEBAAG8nONjKLDzMQHC33vdYqABnSMxD5ySc1NR6h9M+tafxMovZ354Mw90 FrmRh5H1iib6ZHAA2B75CwRiUIeTgdTa9SPbNLuFVrRwNG54gzcehRzFERWSX4cXvaxq/fHC 0cyJX7F88D5R8jXzfOxgmGs6K+Dv37N9huu1G/Vb7KJ8mBPXAFC50S1z3gN4dOEFhTFey5q5 nZTGuZQ3dXLcRPtn6PD6JR5Sp9ol6UfgoMc8oE6xCjb7d0if75eK+7T+45QUqIO8XC0/0mBx YO7CcYIM6Yg249ogtKOgbKqWS7iAjnXKSQf2OxS639wF2Z/b4LLmTaB4JufnLW5/X8YeiBUw ggQ2MIIDHqADAgECAgEBMA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQK EwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDAwNTMwMTA0ODM4WhcN MjAwNTMwMTA0ODM4WjBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAk BgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVz dCBFeHRlcm5hbCBDQSBSb290MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/ca M+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ekKUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJ etsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU6cZfD3idmkA8Dqxhql4Uj56HoWpQ3Nea Tq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOrOk+E2N/On+Fpb7vXQtdrROTHre5t QV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe01sTurM0TRLfJK91DACX6Yblp algjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwIDAQABo4HcMIHZMB0GA1Ud DgQWBBStvZh6NLQm9/rEJlTvA73gJMtUGjALBgNVHQ8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB /zCBmQYDVR0jBIGRMIGOgBStvZh6NLQm9/rEJlTvA73gJMtUGqFzpHEwbzELMAkGA1UEBhMC U0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBU VFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdIIBATANBgkq hkiG9w0BAQUFAAOCAQEAsJvghSXC1iPiD5YGkp1BmJzZhHmB2R5bFAcjNmWPsNh3u6xBbEdg g1Gw+TI95/z2JhPHgBalv1r8h894eYkhmuJMBwqGNbzy3lHE0pa33H5O7nD9HDnrDAJRFC2O vRbgwd9Gdeckrez0QrSFk3AQZ7qdBjVKGNMresxRQqF6Y9Hmu6HFK8I2vhMN5r1jfnl7pwkN QKtq3Y+Kw/b2jBpCBVHURfWfp2IhaBUgQzyZ53y9JNipkRdziD9WGzE4GLRxD5rNyA6eji4b 4YyYg8sfMfFETMYEc0l2YA/H+L0XgGsu6cxMDlqaeQ8gCi7VnmMmHlWSlNiCF1p70LzHj06G BDGCAjAwggIsAgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEAzuhISIgzOwSitfbc2LN4WDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFNVf O3l8U+4q+NGbCu0Xd3kj/8yGMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEzMDYwMTEwNTg1MFowDQYJKoZIhvcNAQEBBQAEggEAptT1PJ5hDslwSXQHtGji S3ElVN0qiVGDw1vz1GmgCqN6EFr2CmoGNFjUQqF0g7W1oS/6aAfiFayDKRzEToqvVUUcGkPp BbS4yKnc7EOCK5jIMJxRWEtUor1aT7tzu86nxxHDP/g3y+gWl/S09nzb2iceOutTSvKLx8W8 fM1k43itX3H3G9rQs7THHDMnqwFXNG1InNyZt7epnq6UHqVTMijsWqxfpfTownOh3cqATjQC 4tjQD3kcb6BTtGbIcJMQ3sOzitRujgU9cHPtWd5CptI00DdCoJPaMFN7c/vixrjBsk5PxOJh RnZlGQXJ5piat/marrReN6N19OTM1Sz7Rw== --B_3452914731_3381993-- From eleven.fuyu@huawei.com Sun Jun 2 19:47:03 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB2921F8CB7 for ; Sun, 2 Jun 2013 19:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPKmY8WvH559 for ; Sun, 2 Jun 2013 19:46:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 64D6121F8CB5 for ; Sun, 2 Jun 2013 19:46:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASA83226; Mon, 03 Jun 2013 02:46:52 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 3 Jun 2013 03:46:05 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 3 Jun 2013 03:46:49 +0100 Received: from NKGEML505-MBX.china.huawei.com ([169.254.1.159]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.01.0323.007; Mon, 3 Jun 2013 10:46:42 +0800 From: "Fuyu (Eleven)" To: GangChen , Suresh Krishnan Thread-Topic: [Softwires] Call for adoption of draft-jiang-softwire-map-radius-04 as wg draft Thread-Index: AQHOXVYYclwfAUVbaEO9p3yUjdh0w5kjRr9Q Date: Mon, 3 Jun 2013 02:46:42 +0000 Message-ID: References: <519EE806.9080506@ericsson.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Call for adoption of draft-jiang-softwire-map-radius-04 as wg draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 02:47:03 -0000 +1 supported as co-author. It is important to standardize the Radius protocol for MAP information also= from the point of view as vendors. It make sense to implement the unified protocol as different vendors for in= teroperation problem. Cheers Yu -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of GangChen Sent: Friday, May 31, 2013 12:53 AM To: Suresh Krishnan Cc: Softwires WG; Yong Cui Subject: Re: [Softwires] Call for adoption of draft-jiang-softwire-map-radi= us-04 as wg draft Support This interactive radius support for MAP is useful when it comes to real deployment. ISPs are likely use radius to authorize and manage MAP subscribers. BRs Gang 2013/5/24, Suresh Krishnan : > Hi all, > This call is being initiated to determine whether there is WG > consensus towards adoption of draft-jiang-softwire-map-radius-04 as a > softwire WG draft. Please state whether or not you're in favor of the > adoption by replying to this email. If you are not in favor, please also > state your objections in your response. The call will complete at > midnight PDT on 2013-06-02. > > Regards > Suresh & Yong > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From dengguangqing@cnnic.cn Mon Jun 3 04:29:11 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFB821F9600 for ; Mon, 3 Jun 2013 04:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.706 X-Spam-Level: X-Spam-Status: No, score=0.706 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3F6CkRnQcGOn for ; Mon, 3 Jun 2013 04:29:07 -0700 (PDT) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id A5DC521F9424 for ; Mon, 3 Jun 2013 04:29:06 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: dengguangqing@cnnic.cn Received: from unknown127.0.0.1 (HELO dgq-pc) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 03 Jun 2013 19:28:55 +0800 Date: Mon, 3 Jun 2013 19:28:57 +0800 From: "Guangqing Deng" To: "Fuyu (Eleven)" , GangChen , "Suresh Krishnan" References: <519EE806.9080506@ericsson.com> , X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201306031928567942422@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart035220526481_=----" Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Call for adoption of draft-jiang-softwire-map-radius-04 as wg draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dengguangqing List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 11:29:11 -0000 This is a multi-part message in MIME format. ------=_001_NextPart035220526481_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 KzEuIFRoZSBzdGFuZGFyZGl6YXRpb24gb2YgUmFkaXVzIHByb3RvY29sIGZvciBNQVAgaXMgYmVu ZWZpY2lhbCBmb3IgSVNQcywgdmVuZG9ycyBhbmQgZmluYWxseSBJbnRlcm5ldCB1c2Vycy4NCg0K DQoNCg0KR3VhbmdxaW5nIERlbmcNCg0KRnJvbTogRnV5dSAoRWxldmVuKQ0KRGF0ZTogMjAxMy0w Ni0wMyAxMDo0Ng0KVG86IEdhbmdDaGVuOyBTdXJlc2ggS3Jpc2huYW4NCkNDOiBTb2Z0d2lyZXMg V0c7IFlvbmcgQ3VpDQpTdWJqZWN0OiBSZTogW1NvZnR3aXJlc10gQ2FsbCBmb3IgYWRvcHRpb24g b2YgZHJhZnQtamlhbmctc29mdHdpcmUtbWFwLXJhZGl1cy0wNCBhcyB3ZyBkcmFmdA0KKzEgc3Vw cG9ydGVkIGFzIGNvLWF1dGhvci4NCg0KSXQgaXMgaW1wb3J0YW50IHRvIHN0YW5kYXJkaXplIHRo ZSBSYWRpdXMgcHJvdG9jb2wgZm9yIE1BUCBpbmZvcm1hdGlvbiBhbHNvIGZyb20gdGhlIHBvaW50 IG9mIHZpZXcgYXMgdmVuZG9ycy4NCkl0IG1ha2Ugc2Vuc2UgdG8gaW1wbGVtZW50IHRoZSB1bmlm aWVkIHByb3RvY29sIGFzIGRpZmZlcmVudCB2ZW5kb3JzIGZvciBpbnRlcm9wZXJhdGlvbiBwcm9i bGVtLg0KDQpDaGVlcnMNCll1DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IHNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c29mdHdpcmVzLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBHYW5nQ2hlbg0KU2VudDogRnJpZGF5LCBNYXkgMzEsIDIwMTMg MTI6NTMgQU0NClRvOiBTdXJlc2ggS3Jpc2huYW4NCkNjOiBTb2Z0d2lyZXMgV0c7IFlvbmcgQ3Vp DQpTdWJqZWN0OiBSZTogW1NvZnR3aXJlc10gQ2FsbCBmb3IgYWRvcHRpb24gb2YgZHJhZnQtamlh bmctc29mdHdpcmUtbWFwLXJhZGl1cy0wNCBhcyB3ZyBkcmFmdA0KDQpTdXBwb3J0DQpUaGlzIGlu dGVyYWN0aXZlIHJhZGl1cyBzdXBwb3J0IGZvciBNQVAgaXMgdXNlZnVsIHdoZW4gaXQgY29tZXMg dG8NCnJlYWwgZGVwbG95bWVudC4gSVNQcyBhcmUgbGlrZWx5IHVzZSByYWRpdXMgdG8gYXV0aG9y aXplIGFuZCBtYW5hZ2UNCk1BUCBzdWJzY3JpYmVycy4NCg0KQlJzDQoNCkdhbmcNCg0KMjAxMy81 LzI0LCBTdXJlc2ggS3Jpc2huYW4gPHN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20+Og0KPiBI aSBhbGwsDQo+ICAgVGhpcyBjYWxsIGlzIGJlaW5nIGluaXRpYXRlZCB0byBkZXRlcm1pbmUgd2hl dGhlciB0aGVyZSBpcyBXRw0KPiBjb25zZW5zdXMgdG93YXJkcyBhZG9wdGlvbiBvZiBkcmFmdC1q aWFuZy1zb2Z0d2lyZS1tYXAtcmFkaXVzLTA0IGFzIGENCj4gc29mdHdpcmUgV0cgZHJhZnQuIFBs ZWFzZSBzdGF0ZSB3aGV0aGVyIG9yIG5vdCB5b3UncmUgaW4gZmF2b3Igb2YgdGhlDQo+IGFkb3B0 aW9uIGJ5IHJlcGx5aW5nIHRvIHRoaXMgZW1haWwuIElmIHlvdSBhcmUgbm90IGluIGZhdm9yLCBw bGVhc2UgYWxzbw0KPiBzdGF0ZSB5b3VyIG9iamVjdGlvbnMgaW4geW91ciByZXNwb25zZS4gVGhl IGNhbGwgd2lsbCBjb21wbGV0ZSBhdA0KPiBtaWRuaWdodCBQRFQgb24gMjAxMy0wNi0wMi4NCj4N Cj4gUmVnYXJkcw0KPiBTdXJlc2ggJiBZb25nDQo+DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFNvZnR3aXJlcyBtYWlsaW5nIGxpc3QN Cj4gU29mdHdpcmVzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc29mdHdpcmVzDQo+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KU29mdHdpcmVzIG1haWxpbmcgbGlzdA0KU29mdHdpcmVzQGlldGYub3JnDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClNvZnR3aXJlcyBtYWlsaW5n IGxpc3QNClNvZnR3aXJlc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zb2Z0d2lyZXM= ------=_001_NextPart035220526481_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

<= FONT=20 face=3D"Times New Roman">+1. The standar= dization of=20 Radius protocol for MAP is beneficial for ISPs, vendors and finally Internet=20 users.

 
Gua= ngqing=20 Deng
Date: 2013-06-03 10:46
To: GangChen; Suresh Krishnan
Subject: Re: [Softwires] Call for adoption of=20 draft-jiang-softwire-map-radius-04 as wg draft
+1 supported as co-author.
 
It is important to standardize the Radi= us protocol for MAP information also from&nb= sp;the point of view as vendors.
It make sense to implement the unified&= nbsp;protocol as different vendors for interopera= tion problem.
 
Cheers
Yu
 
 
-----Original Message-----
From: softwires-bounces@ietf.org [mailto:softwires-bounces@= ietf.org] On Behalf Of GangChen
Sent: Friday, May 31, 2013 12:53 AM
To: Suresh Krishnan
Cc: Softwires WG; Yong Cui
Subject: Re: [Softwires] Call for adoption&n= bsp;of draft-jiang-softwire-map-radius-04 as wg draft<= /DIV>
 
Support
This interactive radius support for MAP = ;is useful when it comes to
real deployment. ISPs are likely use ra= dius to authorize and manage
MAP subscribers.
 
BRs
 
Gang
 
2013/5/24, Suresh Krishnan <suresh.krishnan@ericsso= n.com>:
> Hi all,
>   This call is being initiate= d to determine whether there is WG
> consensus towards adoption of draft-jia= ng-softwire-map-radius-04 as a
> softwire WG draft. Please state wh= ether or not you're in favor of the
> adoption by replying to this email= . If you are not in favor, please = also
> state your objections in your resp= onse. The call will complete at
> midnight PDT on 2013-06-02.
>
> Regards
> Suresh & Yong
>
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
------=_001_NextPart035220526481_=------ From simon.perreault@viagenie.ca Tue Jun 4 06:25:18 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4921821F9D44 for ; Tue, 4 Jun 2013 06:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvdNEtoo3R24 for ; Tue, 4 Jun 2013 06:25:03 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D4ABE21F9CC3 for ; Tue, 4 Jun 2013 04:53:06 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:2905:fce2:6a47:af4e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 08FB340402 for ; Tue, 4 Jun 2013 07:53:05 -0400 (EDT) Message-ID: <51ADD521.5060600@viagenie.ca> Date: Tue, 04 Jun 2013 13:53:05 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: softwires@ietf.org References: <20130604085406.11827.2429.idtracker@ietfa.amsl.com> In-Reply-To: <20130604085406.11827.2429.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130604085406.11827.2429.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Softwires] Fwd: New Version Notification for draft-perreault-softwire-lw4over6-pcp-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 13:25:18 -0000 WG, He have published a new draft describing how an lw4o6 CPE can use PCP for provisioning. We're looking for high-level feedback on questions such as: - Is using PCP a good idea or is it fatally flawed? - Would this WG consider an alternative to DHCP? - What would be the relationship with the unified CPE draft? Thanks, Simon -------- Message original -------- Sujet: New Version Notification for draft-perreault-softwire-lw4over6-pcp-00.txt Date : Tue, 04 Jun 2013 01:54:06 -0700 De : internet-drafts@ietf.org Pour : Chongfeng Xie , Cathy Zhou , Simon Perreault A new version of I-D, draft-perreault-softwire-lw4over6-pcp-00.txt has been successfully submitted by Chongfeng Xie and posted to the IETF repository. Filename: draft-perreault-softwire-lw4over6-pcp Revision: 00 Title: Provisioning Lightweight 4over6 (lw4o6) with the Port Control Protocol (PCP) Creation date: 2013-06-03 Group: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-perreault-softwire-lw4over6-pcp-00.txt Status: http://datatracker.ietf.org/doc/draft-perreault-softwire-lw4over6-pcp Htmlized: http://tools.ietf.org/html/draft-perreault-softwire-lw4over6-pcp-00 Abstract: This memo defines the procedures that a Lightweight B4 uses for provisioning its parameters with the Port Control Protocol. The IETF Secretariat From bingxuere@gmail.com Tue Jun 4 10:20:45 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB1E21F9A72 for ; Tue, 4 Jun 2013 10:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2S02HfYv0nTi for ; Tue, 4 Jun 2013 10:20:44 -0700 (PDT) Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8911221F9D66 for ; Tue, 4 Jun 2013 08:29:14 -0700 (PDT) Received: by mail-vb0-f53.google.com with SMTP id p12so270665vbe.12 for ; Tue, 04 Jun 2013 08:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6nCZMGwmgZEBQtx2UJpSynPxhd1pozaSTdr/RtOsZas=; b=Z8mbMtNgWCQM/vXWiFdZURSt9i8/af9D3TMbJi+RI8tvO32rorLEiPIDgd2z0YL30N TcvY3FiP7pGRmX/WlzpJ1GjeQmlssZxKY8wOmWZJptaDatvJCWR8FN4dtjOgtAWw44u1 cWJ5g+lwzBt3VMOxohpRp2OR1FyDVaoGdbxtxlmiLU1iO8c4gKmOQO0fvSn9NRLKGDfl bLoNfH3M6BpfZR4jL/EpzG5IfvqgkvW1QzuIbGdYUnGXARS6LxGQwm+2FmUsia53JPk9 XfsgagwiAGHdrjVOUeRZQGIImtv3Ll+Dpil6OtQnVTySBBX475RigdBfMih2V/xcmTqF MtzQ== X-Received: by 10.52.164.19 with SMTP id ym19mr5054001vdb.38.1370359753844; Tue, 04 Jun 2013 08:29:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.115.3 with HTTP; Tue, 4 Jun 2013 08:28:33 -0700 (PDT) In-Reply-To: <519EEA1E.5090006@ericsson.com> References: <519EEA1E.5090006@ericsson.com> From: Qiong Date: Tue, 4 Jun 2013 23:28:33 +0800 Message-ID: To: Suresh Krishnan Content-Type: multipart/alternative; boundary=001a11c22b32580a2404de55bed9 Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-mesh-mib-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 17:20:45 -0000 --001a11c22b32580a2404de55bed9 Content-Type: text/plain; charset=UTF-8 Hi all, I support it to move forward. Thanks. Best wishes Qiong On Fri, May 24, 2013 at 12:18 PM, Suresh Krishnan < suresh.krishnan@ericsson.com> wrote: > Hi all, > This message starts a two week softwire working group last call on > advancing the draft defining the Softwire Mesh MIB as a Standards Track > RFC. The authors believe that this version has addressed all the issues > raised until now on the document. The latest version of the draft is > available at > > http://www.ietf.org/id/draft-ietf-softwire-mesh-mib-03.txt > http://tools.ietf.org/html/draft-ietf-softwire-mesh-mib-03 > > Substantive comments and statements of support/opposition for advancing > this document should be directed to the mailing list. Editorial > suggestions can be sent directly to the authors. The chairs will send in > their comments as well during the last call period. This last call will > conclude on June 2, 2013. > > Regards, > Suresh & Yong > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --001a11c22b32580a2404de55bed9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

I support it to move forw= ard.

Thanks.

Best wishes
Qiong


On Fri, May 24, 2013 at 12:18 PM, Suresh= Krishnan <suresh.krishnan@ericsson.com> wrote:
Hi all,
=C2=A0 This message starts a two week softwire working group last call on advancing the draft defining the Softwire Mesh MIB as a Standards Track
RFC. The authors believe that this version has addressed all the issues
raised until now on the document. The latest version of the draft is
available at

http://www.ietf.org/id/draft-ietf-softwire-mesh-mib-03.txt
http://tools.ietf.org/html/draft-ietf-softwire-mesh-mib-03

Substantive comments and statements of support/opposition for advancing
this document should be directed to the mailing list. Editorial
suggestions can be sent directly to the authors. The chairs will send in their comments as well during the last call period. This last call will
conclude on June 2, 2013.

Regards,
Suresh & Yong

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires



--
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
China T= elecom Beijing Research Institude


Open source code:
lightweig= ht 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--001a11c22b32580a2404de55bed9-- From chenycmx@gmail.com Tue Jun 4 19:42:10 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0594C21F9AD6 for ; Tue, 4 Jun 2013 19:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.845 X-Spam-Level: X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3h9H3cis9tS3 for ; Tue, 4 Jun 2013 19:42:09 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D6BF621F9A9F for ; Tue, 4 Jun 2013 19:42:00 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id wz12so1110860pbc.3 for ; Tue, 04 Jun 2013 19:42:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-has-attach:x-mailer:mime-version:message-id:content-type; bh=MLCMRxBpXRbCJ8lp09OJZDC8ZI2J/NfRFOt6D2KRfjo=; b=epgi9sP4X+WdeKJAS/kssck5UbOp66zv+KcwE8cfNtCZbXAt8pL8CvcJ5EMqsGs3xm tU/c4ZWxjJAU68+XGy5mTDq+2brrYwtt54Xb6voKiRw3vItFITwtOrcESluPiWvRgdUy 7tv9xjKuOH5k5VrNLnl/nrISEHjbCGpGS5RuIh5aKGEfA47BAQ+dB41U/mfrASTE2BK9 KY6pObDtDK7MvM6XmLVXYGajb7bPddykIU49FA3BWU6PGyfOUPRKbBNHAj+6l1693KF5 ubMGNwn1TGvB6MdrxTFc/wPjO779XOhz2QjCimDgCi2UPaFBjmK+KAp176/NTGbBkqKu 2Xug== X-Received: by 10.68.87.229 with SMTP id bb5mr30999784pbb.171.1370400120473; Tue, 04 Jun 2013 19:42:00 -0700 (PDT) Received: from user-902eaffedc ([166.111.68.231]) by mx.google.com with ESMTPSA id nk2sm11091269pbc.43.2013.06.04.19.41.56 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Tue, 04 Jun 2013 19:41:58 -0700 (PDT) Date: Wed, 5 Jun 2013 10:41:55 +0800 From: "Yuchi Chen" To: "Suresh Krishnan" , "softwires WG" References: <519EE806.9080506@ericsson.com> X-Priority: 3 X-GUID: B9749056-C934-4D69-8340-36344035E25B X-Has-Attach: no X-Mailer: Foxmail 7.0.1.88[cn] Mime-Version: 1.0 Message-ID: <201306051041531577575@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart752662642765_=----" Cc: Yong Cui Subject: Re: [Softwires] Call for adoption of draft-jiang-softwire-map-radius-04 as wg draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: chenycmx List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 02:42:10 -0000 This is a multi-part message in MIME format. ------=_001_NextPart752662642765_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U3VwcG9ydC4NCg0KQmVzdCByZWdhcmRzIQ0KDQoNCg0KWXVjaGkgQ2hlbiANCg0KRnJvbTogU3Vy ZXNoIEtyaXNobmFuDQpEYXRlOiAyMDEzLTA1LTI0IDEyOjA5DQpUbzogU29mdHdpcmVzIFdHDQpD QzogWW9uZyBDdWkNClN1YmplY3Q6IFtTb2Z0d2lyZXNdIENhbGwgZm9yIGFkb3B0aW9uIG9mIGRy YWZ0LWppYW5nLXNvZnR3aXJlLW1hcC1yYWRpdXMtMDQgYXMgd2cgZHJhZnQNCkhpIGFsbCwNCiAg VGhpcyBjYWxsIGlzIGJlaW5nIGluaXRpYXRlZCB0byBkZXRlcm1pbmUgd2hldGhlciB0aGVyZSBp cyBXRw0KY29uc2Vuc3VzIHRvd2FyZHMgYWRvcHRpb24gb2YgZHJhZnQtamlhbmctc29mdHdpcmUt bWFwLXJhZGl1cy0wNCBhcyBhDQpzb2Z0d2lyZSBXRyBkcmFmdC4gUGxlYXNlIHN0YXRlIHdoZXRo ZXIgb3Igbm90IHlvdSdyZSBpbiBmYXZvciBvZiB0aGUNCmFkb3B0aW9uIGJ5IHJlcGx5aW5nIHRv IHRoaXMgZW1haWwuIElmIHlvdSBhcmUgbm90IGluIGZhdm9yLCBwbGVhc2UgYWxzbw0Kc3RhdGUg eW91ciBvYmplY3Rpb25zIGluIHlvdXIgcmVzcG9uc2UuIFRoZSBjYWxsIHdpbGwgY29tcGxldGUg YXQNCm1pZG5pZ2h0IFBEVCBvbiAyMDEzLTA2LTAyLg0KDQpSZWdhcmRzDQpTdXJlc2ggJiBZb25n DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K U29mdHdpcmVzIG1haWxpbmcgbGlzdA0KU29mdHdpcmVzQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw== ------=_001_NextPart752662642765_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Support.
 
Best=20 regards!
Yuc= hi=20 Chen 
 
Date: 2013-05-24 12:09
Subject: [Softwires] Call for adoption of=20 draft-jiang-softwire-map-radius-04 as wg draft
Hi all,
  This call is being initiated to&= nbsp;determine whether there is WG
consensus towards adoption of draft-jiang-softwir= e-map-radius-04 as a
softwire WG draft. Please state whether = ;or not you're in favor of the
adoption by replying to this email. If&= nbsp;you are not in favor, please also
state your objections in your response. = ;The call will complete at
midnight PDT on 2013-06-02.
 
Regards
Suresh & Yong
 
 
 
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
------=_001_NextPart752662642765_=------ From chenycmx@gmail.com Tue Jun 4 19:45:09 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C3A21F93B9 for ; Tue, 4 Jun 2013 19:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.845 X-Spam-Level: X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYFfLq1sfu7l for ; Tue, 4 Jun 2013 19:45:09 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 34A7021F939E for ; Tue, 4 Jun 2013 19:45:09 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id bg2so686442pad.39 for ; Tue, 04 Jun 2013 19:45:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-has-attach:x-mailer:mime-version:message-id:content-type; bh=38k9fp9LHKnnwMoDEa6ALi+8ogI+iOGd9SFVFmFgEbY=; b=CXPftjES3ZpBVMWA+Y8Pb/+/LZ1V/XW5Ryz0ohzJVTB+6qyGtVZtj85YRPM8u/mxY3 seyLv0GFVrhY1bU7erwvB1BXIl4l4TrP5w4QtirqGQbmcpO7i33TMnSmcVqwpawdYM9x g/SsYVUutGPeiJMEIdKBYhlIZ8g4h2S9gPS4KRkwNhe01W9N2oyaf454MLFR7hjm/xrT OVeYRsYhsq70Wkbhty+d7/Fk40lqrg5Z0xK4h815Y1eniam0xkwxoaWV9o2q94I9qSV2 tsgkinX95baXIUJm0qi5gFrwT0Ceyn4VB/NkGxmZvBCytOcyVlEES9YASXYEuV90nrcs 9Mtw== X-Received: by 10.66.145.201 with SMTP id sw9mr31558268pab.63.1370400308938; Tue, 04 Jun 2013 19:45:08 -0700 (PDT) Received: from user-902eaffedc ([166.111.68.231]) by mx.google.com with ESMTPSA id dc3sm27299511pbc.9.2013.06.04.19.45.05 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Tue, 04 Jun 2013 19:45:07 -0700 (PDT) Date: Wed, 5 Jun 2013 10:45:04 +0800 From: "Yuchi Chen" To: "Suresh Krishnan" , "softwires WG" References: <519EE777.2040407@ericsson.com> X-Priority: 3 X-GUID: AF8951A6-7446-42CF-8916-D95E6A413D78 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.88[cn] Mime-Version: 1.0 Message-ID: <201306051044594970756@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart545032066468_=----" Cc: Yong Cui Subject: Re: [Softwires] Call for adoption of draft-fu-softwire-map-mib-05 as wg draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: chenycmx List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 02:45:09 -0000 This is a multi-part message in MIME format. ------=_001_NextPart545032066468_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U3VwcG9ydC4NCg0KQmVzdCByZWdhcmRzIQ0KDQoNCg0KWXVjaGkgQ2hlbiANCg0KRnJvbTogU3Vy ZXNoIEtyaXNobmFuDQpEYXRlOiAyMDEzLTA1LTI0IDEyOjA3DQpUbzogU29mdHdpcmVzIFdHDQpD QzogWW9uZyBDdWkNClN1YmplY3Q6IFtTb2Z0d2lyZXNdIENhbGwgZm9yIGFkb3B0aW9uIG9mIGRy YWZ0LWZ1LXNvZnR3aXJlLW1hcC1taWItMDUgYXMgd2cgZHJhZnQNCkhpIGFsbCwNCiAgVGhpcyBj YWxsIGlzIGJlaW5nIGluaXRpYXRlZCB0byBkZXRlcm1pbmUgd2hldGhlciB0aGVyZSBpcyBXRw0K Y29uc2Vuc3VzIHRvd2FyZHMgYWRvcHRpb24gb2YgZHJhZnQtZnUtc29mdHdpcmUtbWFwLW1pYi0w NSBhcyBhIHNvZnR3aXJlDQpXRyBkcmFmdC4gUGxlYXNlIHN0YXRlIHdoZXRoZXIgb3Igbm90IHlv dSdyZSBpbiBmYXZvciBvZiB0aGUgYWRvcHRpb24gYnkNCnJlcGx5aW5nIHRvIHRoaXMgZW1haWwu IElmIHlvdSBhcmUgbm90IGluIGZhdm9yLCBwbGVhc2UgYWxzbyBzdGF0ZSB5b3VyDQpvYmplY3Rp b25zIGluIHlvdXIgcmVzcG9uc2UuIFRoZSBjYWxsIHdpbGwgY29tcGxldGUgYXQgbWlkbmlnaHQg UERUIG9uDQoyMDEzLTA2LTAyLg0KDQpSZWdhcmRzDQpTdXJlc2ggJiBZb25nDQoNCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU29mdHdpcmVzIG1h aWxpbmcgbGlzdA0KU29mdHdpcmVzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NvZnR3aXJlcw== ------=_001_NextPart545032066468_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Support.
 
Best regards!
Yuc= hi=20 Chen 
 
Date: 2013-05-24 12:07
Subject: [Softwires] Call for adoption of=20 draft-fu-softwire-map-mib-05 as wg draft
Hi all,
  This call is being initiated to&= nbsp;determine whether there is WG
consensus towards adoption of draft-fu-softwire-m= ap-mib-05 as a softwire
WG draft. Please state whether or not&n= bsp;you're in favor of the adoption by
replying to this email. If you are = ;not in favor, please also state your
objections in your response. The call w= ill complete at midnight PDT on
2013-06-02.
 
Regards
Suresh & Yong
 
 
 
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
------=_001_NextPart545032066468_=------ From rajiva@cisco.com Wed Jun 5 06:14:13 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E8621F99C0; Wed, 5 Jun 2013 06:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2XwwvJ6bt-r; Wed, 5 Jun 2013 06:14:08 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0728721F999B; Wed, 5 Jun 2013 06:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1002; q=dns/txt; s=iport; t=1370438048; x=1371647648; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=0VuYdvN4FLSfr85yDXqlZf0dSnY6M0edPgKpioihzao=; b=IsFey7HERh4NTYyrtRxyX7IYvSYGwc3qzOAIkhC6cDEseGxeGYeE45Ag v9OaffX2W1HTEiHAGOa8MdxsGDyvqDoqTL6YazdG0M1XSiDxg27/IYSya on/dZtGrpstimj1ra6G2QIMslR+Ca0ifm/wiGk92WeVCg9VIryO7NWkoc I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8FADc5r1GtJXG9/2dsb2JhbABZFoJzMIJ1vDd8FnSCJQEEOj8SASoUQiYBBAENDQGIBL0MjnoxgwFhA6NfhSCDD4In X-IronPort-AV: E=Sophos;i="4.87,806,1363132800"; d="scan'208";a="219055757" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 05 Jun 2013 13:14:07 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r55DE7QQ019360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 13:14:07 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 08:14:06 -0500 From: "Rajiv Asati (rajiva)" To: "v6ops@ietf.org" , "Softwires-wg list (softwires@ietf.org)" , "behave@ietf.org" Thread-Topic: Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlA== Date: Wed, 5 Jun 2013 13:14:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.2.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Erik Kline \(ek@google.com\)" Subject: [Softwires] Home NAPT44 - How many ports? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 13:14:13 -0000 Some of you may recall our discussion (during the last IETF) around "how ma= ny TCP/UDP ports are enough with NAPT44" per home, as ISPs move into A+P pa= radigm. ~500, ~1000, ~3000??? Well, I started monitoring my home router and plotting the NAPT44 port util= ization on a minute-by-minute basis. You may find it here - http://www.empl= oyees.org/~rajiva In short, port range of 500 seems ok, though 1000 would be more than enough= for my home. Suffice to say, this is just a sample representation, since t= he port utilization would vary home to home, based on number of active devi= ces, type of applications, the degree of simultaneous device or application= usage etc. If any of you are doing similar monitoring, then please share. Cheers, Rajiv PS: Thanks to Erik Kline, who explained (with sufficient details) how to us= e google charting for my data. And thanks to Xun Wang & Shaoshuai Dai for h= elping me out significantly. PS: My home has 3-4 active devices. From kristian.poscic@alcatel-lucent.com Wed Jun 5 06:33:17 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE1021F9ABB; Wed, 5 Jun 2013 06:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLrf+ofQT54B; Wed, 5 Jun 2013 06:33:12 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id EE70B21F9ACF; Wed, 5 Jun 2013 06:33:06 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r55DWwG0026696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Jun 2013 08:32:58 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r55DWtQK002234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 09:32:56 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.44]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Wed, 5 Jun 2013 09:32:54 -0400 From: "Poscic, Kristian (Kristian)" To: "Rajiv Asati (rajiva)" , "v6ops@ietf.org" , "Softwires-wg list (softwires@ietf.org)" , "behave@ietf.org" Thread-Topic: Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAA9zuw Date: Wed, 5 Jun 2013 13:32:53 +0000 Message-ID: <7921F977B17D5B49B8DCC955A339D2F02AB3A800@US70UWXCHMBA05.zam.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "Erik Kline \(ek@google.com\)" Subject: Re: [Softwires] Home NAPT44 - How many ports? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 13:33:17 -0000 Thanks. Can you tell us in general what applications did you use for this? This heavily depends on the application type in use...p2p apps, etc. Since = some apps spawn a large number of TCP ports for example. So the question is to what degree do you think is your sample representativ= e of a general user in any region? For example does it cover 30% of users for an ISP in NA while it covers 80%= of users for another ISP in APAC for example? -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= Rajiv Asati (rajiva) Sent: Wednesday, June 05, 2013 6:14 AM To: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org); behave@ietf.org Cc: Erik Kline (ek@google.com) Subject: [BEHAVE] Home NAPT44 - How many ports? Some of you may recall our discussion (during the last IETF) around "how ma= ny TCP/UDP ports are enough with NAPT44" per home, as ISPs move into A+P pa= radigm. ~500, ~1000, ~3000??? Well, I started monitoring my home router and plotting the NAPT44 port util= ization on a minute-by-minute basis. You may find it here - http://www.empl= oyees.org/~rajiva In short, port range of 500 seems ok, though 1000 would be more than enough= for my home. Suffice to say, this is just a sample representation, since t= he port utilization would vary home to home, based on number of active devi= ces, type of applications, the degree of simultaneous device or application= usage etc. If any of you are doing similar monitoring, then please share. Cheers, Rajiv PS: Thanks to Erik Kline, who explained (with sufficient details) how to us= e google charting for my data. And thanks to Xun Wang & Shaoshuai Dai for h= elping me out significantly. PS: My home has 3-4 active devices. _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From repenno@cisco.com Wed Jun 5 08:44:35 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58AC421F9B09; Wed, 5 Jun 2013 08:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0LI7gt3oTY0; Wed, 5 Jun 2013 08:44:30 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 42AE321F9AF8; Wed, 5 Jun 2013 08:44:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2691; q=dns/txt; s=iport; t=1370447068; x=1371656668; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=jHCI/VUd1ESZajsS7uvW7d8rO0TeWCXku1tUS4ssbLA=; b=R/4VqVQr2yBXZvGbtaXuk/QQrKd3lbfVG8GyppDLAtBThdM40X+aHzlS 0xtGrnzhmA9WYpeBy9zLZIzAqCdZAKnUU4m8lICISBFDCVLtv9XiVYLN8 OLOC7ayQ+oUcHPmWMTmB4gHen2/LWGybEu0CFmNabTVuL4PdXT+vcWwka Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAHRbr1GtJV2Z/2dsb2JhbABaFoJzML8sfRZ0giMBAQEEAQEBNzQLDAYBCBEEAQELFAkuCxQJCAEBBAENBQgBiAQMvTGOejEHBoJ0YQOjX4Uggw+CJw X-IronPort-AV: E=Sophos;i="4.87,807,1363132800"; d="scan'208";a="216150526" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 05 Jun 2013 15:44:26 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r55FiQnl029315 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 15:44:26 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 10:44:25 -0500 From: "Reinaldo Penno (repenno)" To: "Poscic, Kristian (Kristian)" , "Rajiv Asati (rajiva)" , "v6ops@ietf.org" , "Softwires-wg list (softwires@ietf.org)" , "behave@ietf.org" Thread-Topic: [BEHAVE] Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAA9zuwAAkCoAA= Date: Wed, 5 Jun 2013 15:44:25 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090A0972@xmb-rcd-x04.cisco.com> In-Reply-To: <7921F977B17D5B49B8DCC955A339D2F02AB3A800@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.243.252] Content-Type: text/plain; charset="us-ascii" Content-ID: <9E976E5D808FB548B1EB58FDFADC5A00@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Erik Kline \(ek@google.com\)" Subject: Re: [Softwires] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 15:44:35 -0000 Yes, there are regional differences. But even then, in general, 90% of the active users can be covered by 1000 ports. I have been collecting data for many years, and actually the number of TCP ports consumed have been going Down due to a number of factors. On the other hand, as Rajiv captured,the number of UDP sessions can be much larger than the number of TCP. Because the way dynamic webpages are constructed today, there are sometimes literally 100s of DNS requests to download a single page. On 6/5/13 10:32 AM, "Poscic, Kristian (Kristian)" wrote: >Thanks. Can you tell us in general what applications did you use for this? >This heavily depends on the application type in use...p2p apps, etc. >Since some apps spawn a large number of TCP ports for example. > >So the question is to what degree do you think is your sample >representative of a general user in any region? > >For example does it cover 30% of users for an ISP in NA while it covers >80% of users for another ISP in APAC for example? > >-----Original Message----- >From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf >Of Rajiv Asati (rajiva) >Sent: Wednesday, June 05, 2013 6:14 AM >To: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org); >behave@ietf.org >Cc: Erik Kline (ek@google.com) >Subject: [BEHAVE] Home NAPT44 - How many ports? > >Some of you may recall our discussion (during the last IETF) around "how >many TCP/UDP ports are enough with NAPT44" per home, as ISPs move into >A+P paradigm. ~500, ~1000, ~3000??? > >Well, I started monitoring my home router and plotting the NAPT44 port >utilization on a minute-by-minute basis. You may find it here - >http://www.employees.org/~rajiva > >In short, port range of 500 seems ok, though 1000 would be more than >enough for my home. Suffice to say, this is just a sample representation, >since the port utilization would vary home to home, based on number of >active devices, type of applications, the degree of simultaneous device >or application usage etc. > >If any of you are doing similar monitoring, then please share. > >Cheers, >Rajiv > >PS: Thanks to Erik Kline, who explained (with sufficient details) how to >use google charting for my data. And thanks to Xun Wang & Shaoshuai Dai >for helping me out significantly. > >PS: My home has 3-4 active devices. >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From repenno@cisco.com Wed Jun 5 09:28:06 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4A821F9A87; Wed, 5 Jun 2013 09:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGr-Y8p1Sl2C; Wed, 5 Jun 2013 09:28:01 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id E5B1721F9B41; Wed, 5 Jun 2013 09:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1183; q=dns/txt; s=iport; t=1370449681; x=1371659281; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=OY/eyAImJt4Tl3Iu98qKlM/W50kA4qcNe27B1L9XoPg=; b=cOsft9Jeg8eigQZG+z4vKr5sBFlP8rDoE+XyOenOT2uDRUVxYa9XHGI5 kd3f27y7UHu6IWBil68uJLbVU+dIrV1xwYfZZ/Pqjo2BOwDr4xOJrjDq/ RbFvVGpHoAlLfSZqXbe3O2PIYw6gd8PlnRznsJbEjVwOjIB0ZR+QzCN7w Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAP1fr1GtJXG+/2dsb2JhbABZgwkwvyx9FnSCJQEEOj8SAQgiFEIlAQEEAQ0FCBaHb707jnoxB4J6YQOof4MPgic X-IronPort-AV: E=Sophos;i="4.87,808,1363132800"; d="scan'208";a="219157721" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 05 Jun 2013 16:28:00 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r55GS0Xb021059 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 16:28:00 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 11:27:59 -0500 From: "Reinaldo Penno (repenno)" To: Michael Richardson , "v6ops@ietf.org" Thread-Topic: [BEHAVE] Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAA9zuwAAkCoAAAB6fzgP//zuwA Date: Wed, 5 Jun 2013 16:27:59 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090A0A82@xmb-rcd-x04.cisco.com> In-Reply-To: <20115.1370449415@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.243.252] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Softwires-wg list \(softwires@ietf.org\)" , "behave@ietf.org" , "Erik Kline \(ek@google.com\)" Subject: Re: [Softwires] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 16:28:06 -0000 On 6/5/13 1:23 PM, "Michael Richardson" wrote: > >>>>>> "repenno" =3D=3D repenno writes: > repenno> On the other hand, as Rajiv captured,the number of > repenno> UDP sessions can be much larger than the number of > repenno> TCP. Because the way > repenno> dynamic webpages are constructed today, there are sometimes > repenno> literally 100s > repenno> of DNS requests to download a single page. > >If one is doing CGN, wouldn't it be reasonable to point customers' at >a recursive DNS server with an interface inside the CGN? Yes. That's what I suggest. But some people use, say, Google's DNS/OpenDns/etc and in some other cases the network is not setup correctly. > >This seems to also suggest that having a *caching* recursive DNS(SEC, >HOMENET+, mDNS+) server inside the customer router is also a big win. Yes, it is. > >--=20 >] Never tell me the odds! | ipv6 mesh >networks [=20 >] Michael Richardson, Sandelman Software Works | network >architect [=20 >] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails > [=20 >=09 From kaname@nttv6.jp Wed Jun 5 11:16:22 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133B621F9B3F; Wed, 5 Jun 2013 11:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.11 X-Spam-Level: * X-Spam-Status: No, score=1.11 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZvU-ToUZH5O; Wed, 5 Jun 2013 11:16:17 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.148]) by ietfa.amsl.com (Postfix) with ESMTP id BAE5221F9B09; Wed, 5 Jun 2013 11:16:17 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:208::212]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 3F00FBDC21; Thu, 6 Jun 2013 03:15:59 +0900 (JST) Received: from [IPv6:::1] (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id C1D9DE1E27; Thu, 6 Jun 2013 03:15:58 +0900 (JST) Message-ID: <51AF805D.4000101@nttv6.jp> Date: Thu, 06 Jun 2013 03:15:57 +0900 From: kaname nishizuka User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Reinaldo Penno (repenno)" References: <45A697A8FFD7CF48BCF2BE7E106F0604090A0A82@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090A0A82@xmb-rcd-x04.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "behave@ietf.org" , Michael Richardson , "Softwires-wg list \(softwires@ietf.org\)" , "Erik Kline \(ek@google.com\)" Subject: Re: [Softwires] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 18:16:22 -0000 With regard to the DNS packets, shortening the time-out of NAT table is another good solution. In larger environment, we tested that when the time-out of DNS was shortened to 3sec, the impact of such DNS requests was much smaller than TCP sessions. 3 sec is sufficient round-trip time in general situation. I don't think it's necessary to place a recursive DNS server inside the CGN. Though there are differences between Home NAPT44 and CGN, it will work well in both case. That is because there are many devices in home and those seldom access the web site within a short time simultaneously. regards, -- kaname (2013/06/06 1:27), Reinaldo Penno (repenno) wrote: > > On 6/5/13 1:23 PM, "Michael Richardson" wrote: > >>>>>>> "repenno" == repenno writes: >> repenno> On the other hand, as Rajiv captured,the number of >> repenno> UDP sessions can be much larger than the number of >> repenno> TCP. Because the way >> repenno> dynamic webpages are constructed today, there are sometimes >> repenno> literally 100s >> repenno> of DNS requests to download a single page. >> >> If one is doing CGN, wouldn't it be reasonable to point customers' at >> a recursive DNS server with an interface inside the CGN? > Yes. That's what I suggest. But some people use, say, Google's > DNS/OpenDns/etc and in some other cases the network is not setup correctly. > >> This seems to also suggest that having a *caching* recursive DNS(SEC, >> HOMENET+, mDNS+) server inside the customer router is also a big win. > Yes, it is. > >> -- >> ] Never tell me the odds! | ipv6 mesh >> networks [ >> ] Michael Richardson, Sandelman Software Works | network >> architect [ >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails >> [ >> > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- ---- Kaname Nishizuka Innovative Architecture Center NTT Communications Corporation +81-50-3812-4704 From rajiva@cisco.com Wed Jun 5 11:45:56 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D6621F9AA6; Wed, 5 Jun 2013 11:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahPZqpGqqQ2n; Wed, 5 Jun 2013 11:45:51 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id B9F4721F99ED; Wed, 5 Jun 2013 11:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3077; q=dns/txt; s=iport; t=1370457948; x=1371667548; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=f5rug0kOETDeusEAiTCgIlRdRwbJjquFc+mpkHtKPCs=; b=GNVp3JFSu17BhPOp4oYnlZQGowSNnvT+lYD+Ars5789HeGInYYUszqoB q+b6ClM8lAh4Oww2h1M03X4gsicaBm5tK6dTTN1TdAOzF6hIJb371GtM7 8XKR4+DxSDF4yQC6bvimxWlYq2WD0T7lBFDuLHBSHcVUzbuzG+wfc31MX A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAP6Gr1GtJXG+/2dsb2JhbABaFoJzML8xfxZ0giMBAQEDAQEBATc0CwUHBAIBCBEEAQELFAkHJwsUCQgBAQQBDQUIAYd+Bgy9T456MQcGgnRhA6NfhSCDD4In X-IronPort-AV: E=Sophos;i="4.87,809,1363132800"; d="scan'208";a="216261513" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 05 Jun 2013 18:45:48 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r55Ijlrg014015 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 18:45:47 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 13:45:47 -0500 From: "Rajiv Asati (rajiva)" To: "Poscic, Kristian (Kristian)" , "v6ops@ietf.org" , "Softwires-wg list (softwires@ietf.org)" , "behave@ietf.org" Thread-Topic: Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAA9zuwAArsfrA= Date: Wed, 5 Jun 2013 18:45:46 +0000 Message-ID: References: <7921F977B17D5B49B8DCC955A339D2F02AB3A800@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <7921F977B17D5B49B8DCC955A339D2F02AB3A800@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.2.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Erik Kline \(ek@google.com\)" Subject: Re: [Softwires] Home NAPT44 - How many ports? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 18:45:56 -0000 Kristian,=20 > Thanks. Can you tell us in general what applications did you use for this= ? > This heavily depends on the application type in use...p2p apps, etc. Sinc= e > some apps spawn a large number of TCP ports for example. In my home, it is 99% web applications - predominant being OTT video consum= ption (besides SSL VPN for work). Wrt p2p, we aggressively use p2p telepho= ny (e.g. vonage, skype, facetime). > So the question is to what degree do you think is your sample > representative of a general user in any region? It is quite subjective to answer, but I think that it represents a reasonab= le chunk of the home internet usage around the world. Cheers, Rajiv > -----Original Message----- > From: Poscic, Kristian (Kristian) [mailto:kristian.poscic@alcatel-lucent.= com] > Sent: Wednesday, June 05, 2013 9:33 AM > To: Rajiv Asati (rajiva); v6ops@ietf.org; Softwires-wg list > (softwires@ietf.org); behave@ietf.org > Cc: Erik Kline (ek@google.com) > Subject: RE: Home NAPT44 - How many ports? >=20 > Thanks. Can you tell us in general what applications did you use for this= ? > This heavily depends on the application type in use...p2p apps, etc. Sinc= e > some apps spawn a large number of TCP ports for example. >=20 > So the question is to what degree do you think is your sample > representative of a general user in any region? >=20 > For example does it cover 30% of users for an ISP in NA while it covers 8= 0% > of users for another ISP in APAC for example? >=20 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Rajiv Asati (rajiva) > Sent: Wednesday, June 05, 2013 6:14 AM > To: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org); behave@ietf.o= rg > Cc: Erik Kline (ek@google.com) > Subject: [BEHAVE] Home NAPT44 - How many ports? >=20 > Some of you may recall our discussion (during the last IETF) around "how > many TCP/UDP ports are enough with NAPT44" per home, as ISPs move into > A+P paradigm. ~500, ~1000, ~3000??? >=20 > Well, I started monitoring my home router and plotting the NAPT44 port > utilization on a minute-by-minute basis. You may find it here - > http://www.employees.org/~rajiva >=20 > In short, port range of 500 seems ok, though 1000 would be more than > enough for my home. Suffice to say, this is just a sample representation, > since the port utilization would vary home to home, based on number of > active devices, type of applications, the degree of simultaneous device o= r > application usage etc. >=20 > If any of you are doing similar monitoring, then please share. >=20 > Cheers, > Rajiv >=20 > PS: Thanks to Erik Kline, who explained (with sufficient details) how to = use > google charting for my data. And thanks to Xun Wang & Shaoshuai Dai for > helping me out significantly. >=20 > PS: My home has 3-4 active devices. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From rajiva@cisco.com Wed Jun 5 11:51:50 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA89521F9BCF; Wed, 5 Jun 2013 11:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lf18YyCgu1Ji; Wed, 5 Jun 2013 11:51:45 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1B821F9BC9; Wed, 5 Jun 2013 11:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3724; q=dns/txt; s=iport; t=1370458305; x=1371667905; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tOuNyimLohr8bAWf69RssZO9QB8zWwDSRLTaDlxJPpc=; b=BMToZLHFACDLOTGjeb7ecCyb+HM/DdbicEgQdf86IlY4PZ6tSOafjIiB jR+N9IxPCEpaBJxobEueYqqpYUKyC8nnK0xbt/oPOkh6nEM/0ClSQSbjS D9zcP1ULh4sN5uf7uTKY4afj2PUMJAMaY09ufz3MTV3jeanQPX7oEf65E I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAMCHr1GtJV2b/2dsb2JhbABaFoJzML8xfxZ0giMBAQEEAQEBNzQLDAQCAQgRBAEBAQoUCQcnCxQJCAEBBAENBQgBiAQMvVCNaoEQMQcGgnRhA6NfhSCDD4FpPg X-IronPort-AV: E=Sophos;i="4.87,809,1363132800"; d="scan'208";a="219039825" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 05 Jun 2013 18:51:36 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r55Ipa5R022335 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 18:51:36 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 13:51:36 -0500 From: "Rajiv Asati (rajiva)" To: "Reinaldo Penno (repenno)" , "Poscic, Kristian (Kristian)" , "v6ops@ietf.org" , "Softwires-wg list (softwires@ietf.org)" , "behave@ietf.org" Thread-Topic: [BEHAVE] Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAA9zuwAAkCoAAAAicnkA== Date: Wed, 5 Jun 2013 18:51:35 +0000 Message-ID: References: <7921F977B17D5B49B8DCC955A339D2F02AB3A800@US70UWXCHMBA05.zam.alcatel-lucent.com> <45A697A8FFD7CF48BCF2BE7E106F0604090A0972@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090A0972@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.2.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Erik Kline \(ek@google.com\)" Subject: Re: [Softwires] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 18:51:50 -0000 Reinaldo, I agree with you. Until I enabled DNS proxy on my router, I noticed that UD= P NAT exceeded TCP NAT entries in few occasions. Since DNS proxy got enable= d, UDP NAT entries became negligible. One interesting observation is how the lowest number of TCP NAT entries sta= yed within the range throughout the night time (when the devices were not m= anually used) based on how many apps (on the smartphones) were left running= . For ex, ~200 TCP ports on April 13-14, or ~30 TCP ports June 4. Cheers, Rajiv > -----Original Message----- > From: Reinaldo Penno (repenno) > Sent: Wednesday, June 05, 2013 11:44 AM > To: Poscic, Kristian (Kristian); Rajiv Asati (rajiva); v6ops@ietf.org; So= ftwires- > wg list (softwires@ietf.org); behave@ietf.org > Cc: Erik Kline (ek@google.com) > Subject: Re: [BEHAVE] Home NAPT44 - How many ports? >=20 > Yes, there are regional differences. But even then, in general, 90% of th= e > active users can be covered by 1000 ports. I have been collecting data fo= r > many years, and actually the number of TCP ports consumed have been > going Down due to a number of factors. >=20 > On the other hand, as Rajiv captured,the number of UDP sessions can be > much larger than the number of TCP. Because the way dynamic webpages > are constructed today, there are sometimes literally 100s of DNS requests= to > download a single page. >=20 >=20 >=20 > On 6/5/13 10:32 AM, "Poscic, Kristian (Kristian)" > wrote: >=20 > >Thanks. Can you tell us in general what applications did you use for thi= s? > >This heavily depends on the application type in use...p2p apps, etc. > >Since some apps spawn a large number of TCP ports for example. > > > >So the question is to what degree do you think is your sample > >representative of a general user in any region? > > > >For example does it cover 30% of users for an ISP in NA while it covers > >80% of users for another ISP in APAC for example? > > > >-----Original Message----- > >From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > >Behalf Of Rajiv Asati (rajiva) > >Sent: Wednesday, June 05, 2013 6:14 AM > >To: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org); > >behave@ietf.org > >Cc: Erik Kline (ek@google.com) > >Subject: [BEHAVE] Home NAPT44 - How many ports? > > > >Some of you may recall our discussion (during the last IETF) around > >"how many TCP/UDP ports are enough with NAPT44" per home, as ISPs > move > >into > >A+P paradigm. ~500, ~1000, ~3000??? > > > >Well, I started monitoring my home router and plotting the NAPT44 port > >utilization on a minute-by-minute basis. You may find it here - > >http://www.employees.org/~rajiva > > > >In short, port range of 500 seems ok, though 1000 would be more than > >enough for my home. Suffice to say, this is just a sample > >representation, since the port utilization would vary home to home, > >based on number of active devices, type of applications, the degree of > >simultaneous device or application usage etc. > > > >If any of you are doing similar monitoring, then please share. > > > >Cheers, > >Rajiv > > > >PS: Thanks to Erik Kline, who explained (with sufficient details) how > >to use google charting for my data. And thanks to Xun Wang & Shaoshuai > >Dai for helping me out significantly. > > > >PS: My home has 3-4 active devices. > >_______________________________________________ > >Behave mailing list > >Behave@ietf.org > >https://www.ietf.org/mailman/listinfo/behave > >_______________________________________________ > >Behave mailing list > >Behave@ietf.org > >https://www.ietf.org/mailman/listinfo/behave From rajiva@cisco.com Wed Jun 5 11:58:05 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6579221F9B84; Wed, 5 Jun 2013 11:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9ST4iSDB90E; Wed, 5 Jun 2013 11:58:00 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B179121F9C14; Wed, 5 Jun 2013 11:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2526; q=dns/txt; s=iport; t=1370458627; x=1371668227; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=z7dErHKNz1kXk0WbYia6JgrHEdbkA7ClmZ6RunDjO2M=; b=EpbTkqSyabqfOCwLsd4z/kUh0yC+nT59MPRBBiR2z7kVguusLy8YGEi4 izyHyfiiaKOvK+Hs1Yx1U7PjQHaCA5/8f3+1i2bi/BeeyaoKlsRy5FulE bIwue49tGUOADatpS0zyti4jhfR2TtIGK+hEbE78850Gitu2iv3l392n/ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAO2Ir1GtJV2c/2dsb2JhbABagwkwvzF/FnSCIwEBAQQ6PwwEAgEIEQQBAQEKFBAyHQgBAQQBDQUIFodvvVqOegYrBwaCdGEDqH+DD4In X-IronPort-AV: E=Sophos;i="4.87,809,1363132800"; d="scan'208";a="219244957" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 05 Jun 2013 18:57:06 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r55Iv6s0024229 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 18:57:06 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 13:57:05 -0500 From: "Rajiv Asati (rajiva)" To: "Reinaldo Penno (repenno)" , Michael Richardson , "v6ops@ietf.org" Thread-Topic: [BEHAVE] Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAA9zuwAAkCoAAAB6fzgP//zuwA///5RqA= Date: Wed, 5 Jun 2013 18:57:05 +0000 Message-ID: References: <20115.1370449415@sandelman.ca> <45A697A8FFD7CF48BCF2BE7E106F0604090A0A82@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090A0A82@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.2.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Softwires-wg list \(softwires@ietf.org\)" , "behave@ietf.org" , "Erik Kline \(ek@google.com\)" Subject: Re: [Softwires] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 18:58:05 -0000 > >If one is doing CGN, wouldn't it be reasonable to point customers' at a > >recursive DNS server with an interface inside the CGN? >=20 > Yes. That's what I suggest. But some people use, say, Google's > DNS/OpenDns/etc and in some other cases the network is not setup > correctly. And in some cases, it is not possible depending on where the NAT function i= s placed and where the DNS server is placed. I recently ran into this in a = large mobile network design.=20 Nonetheless, it is desired, but it is not really a big deal, since UDP NAT = usage tends to be a lot less than that TCP NAT usage (barring few exception= s). > >This seems to also suggest that having a *caching* recursive DNS(SEC, > >HOMENET+, mDNS+) server inside the customer router is also a big win. >=20 > Yes, it is. Well, DNS resolver with or without proxy is a big win, I would say.=20 Cheers, Rajiv > -----Original Message----- > From: Reinaldo Penno (repenno) > Sent: Wednesday, June 05, 2013 12:28 PM > To: Michael Richardson; v6ops@ietf.org > Cc: Poscic, Kristian (Kristian); Rajiv Asati (rajiva); Softwires-wg list > (softwires@ietf.org); behave@ietf.org; Erik Kline (ek@google.com) > Subject: Re: [BEHAVE] Home NAPT44 - How many ports? >=20 >=20 >=20 > On 6/5/13 1:23 PM, "Michael Richardson" wrote: >=20 > > > >>>>>> "repenno" =3D=3D repenno writes: > > repenno> On the other hand, as Rajiv captured,the number of > > repenno> UDP sessions can be much larger than the number of > > repenno> TCP. Because the way > > repenno> dynamic webpages are constructed today, there are > sometimes > > repenno> literally 100s > > repenno> of DNS requests to download a single page. > > > >If one is doing CGN, wouldn't it be reasonable to point customers' at a > >recursive DNS server with an interface inside the CGN? >=20 > Yes. That's what I suggest. But some people use, say, Google's > DNS/OpenDns/etc and in some other cases the network is not setup > correctly. >=20 > > > >This seems to also suggest that having a *caching* recursive DNS(SEC, > >HOMENET+, mDNS+) server inside the customer router is also a big win. >=20 > Yes, it is. >=20 > > > >-- > >] Never tell me the odds! | ipv6 mesh > >networks [ > >] Michael Richardson, Sandelman Software Works | network > >architect [ > >] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rail= s > > [ > > From rajiva@cisco.com Wed Jun 5 12:05:23 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69CB521F8F4A; Wed, 5 Jun 2013 12:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Z2FD7NPuYv0; Wed, 5 Jun 2013 12:05:18 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id BBF6521F9C3D; Wed, 5 Jun 2013 12:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1754; q=dns/txt; s=iport; t=1370459010; x=1371668610; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=y58flFdw94Td7kMJ2B/nZ4ah0aqCovmOUxMFBxA5T+0=; b=SKZelwNloob1RIqjCrLYYIcflwuRaac7/UD1Hnw9989XP3hpIu7fMs+C mBHD0J5CVVzwkfB/3IeNLkUeSyt5RpMqrtBuYF0sg7Z33BZo5KDDf0yXa MJmm5u6I6Gvh4eu3DgQc4yeqLJQQcLL7+JBU/xW2/1Gm8+pxgZv8Vjeln k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAHiKr1GtJXHB/2dsb2JhbABagwkwvzZ/FnSCIwEBAQQ6PwwEAgEIEQQBAQsUCQcyFAkIAQEEDgUIiAW9Xo56BisHBoJ0YQOof4MPgic X-IronPort-AV: E=Sophos;i="4.87,809,1363132800"; d="scan'208";a="216270443" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 05 Jun 2013 19:03:28 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r55J3Sjw030404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 19:03:28 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 14:03:28 -0500 From: "Rajiv Asati (rajiva)" To: Michael Richardson Thread-Topic: [BEHAVE] Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAMUx6AAAA8pzA= Date: Wed, 5 Jun 2013 19:03:27 +0000 Message-ID: References: <24499.1370440297@sandelman.ca> In-Reply-To: <24499.1370440297@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.2.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Softwires-wg list \(softwires@ietf.org\)" , "Erik Kline \(ek@google.com\)" , "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [Softwires] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 19:05:24 -0000 Hi Michael, Total 8 computing devices. Usually 2-4 active devices. My ISP is yet to enable IPv6 in my location, and I have purposely disabled = HE IPv6 to collect my IPv4 NAT data of this round, before enabling my HE IP= v6 to contrast the IPv4 NAT usage. Host based IPSec VPN or SSL VPN on one device.=20 A lots of Vonage & Skype & FT usage. Predominantly OTT video consumption. Cheers, Rajiv > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Michael Richardson > Sent: Wednesday, June 05, 2013 9:52 AM > To: Rajiv Asati (rajiva) > Cc: Softwires-wg list (softwires@ietf.org); Erik Kline (ek@google.com); > v6ops@ietf.org; behave@ietf.org > Subject: Re: [BEHAVE] Home NAPT44 - How many ports? >=20 >=20 > >>>>> "rajiva" =3D=3D rajiva writes: > rajiva> In short, port range of 500 seems ok, though 1000 would be > rajiva> more than enough for my home. Suffice to say, this is just a > rajiva> sample representation, since the port utilization would vary > rajiva> home to home, based on number of active devices, type of > rajiva> applications, the degree of simultaneous device or > rajiva> application usage etc. >=20 > You are a home of how many computers? How many active people? > (I don't assume those are 1:1...) > I guess you have no IPv6 running? > SIP? Skype? VPN (what kind? does it terminate on a desktop, or on your > "router"?) >=20 > -- > ] Never tell me the odds! | ipv6 mesh netwo= rks [ > ] Michael Richardson, Sandelman Software Works | network archite= ct [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails= [ >=20 From rajiva@cisco.com Wed Jun 5 12:07:05 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE2121F9691; Wed, 5 Jun 2013 12:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.849 X-Spam-Level: X-Spam-Status: No, score=-9.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntWVzFDX7n0N; Wed, 5 Jun 2013 12:06:59 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B721121F918C; Wed, 5 Jun 2013 12:05:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2860; q=dns/txt; s=iport; t=1370459109; x=1371668709; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2GshIMoSvnWIY4eCNh2XLvAdjstYt3mbx9PeWg9Ijk4=; b=mw7aEgHHwxtpeRgshM2GZW7Ta4GB/Yb1TbCqgU49zXpacIBfV0xPjoMm fXz4GQPgCCaQbYoD8fi4HXHaJ5AxR38YAYYCgZ6UlmgZ9R+mj5E1w0XvN 8OUm1YcsJBhRaku9KyKxii3JLZd+PgspVfPgqn5S4nk5eYE7aFvWdEWhO c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAFaLr1GtJXG+/2dsb2JhbABagwkwvzh/FnSCIwEBAQQBAQE3NAsMBAIBCBEBAwEBAQoUCQcnCxQDBggCBAENBQgTA4dvDL1SjnoGKwcGgnRhA6h/gw+CJw X-IronPort-AV: E=Sophos;i="4.87,809,1363132800"; d="scan'208";a="219046649" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 05 Jun 2013 19:04:44 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r55J4iqv030246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 19:04:44 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 14:04:44 -0500 From: "Rajiv Asati (rajiva)" To: kaname nishizuka , "Reinaldo Penno (repenno)" Thread-Topic: [BEHAVE] Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAA9zuwAAkCoAAAB6fzgP//zuwAgABQeYCAAEZ/gA== Date: Wed, 5 Jun 2013 19:04:43 +0000 Message-ID: References: <45A697A8FFD7CF48BCF2BE7E106F0604090A0A82@xmb-rcd-x04.cisco.com> <51AF805D.4000101@nttv6.jp> In-Reply-To: <51AF805D.4000101@nttv6.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.2.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "behave@ietf.org" , Michael Richardson , "Softwires-wg list \(softwires@ietf.org\)" , "Erik Kline \(ek@google.com\)" Subject: Re: [Softwires] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 19:07:05 -0000 Kaname-san, That's a good suggestion, though the captured data suggests that UDP NAT ex= haustion is not a problem, but TCP NAT is. Cheers, Rajiv > -----Original Message----- > From: kaname nishizuka [mailto:kaname@nttv6.jp] > Sent: Wednesday, June 05, 2013 2:16 PM > To: Reinaldo Penno (repenno) > Cc: Michael Richardson; v6ops@ietf.org; Softwires-wg list > (softwires@ietf.org); Poscic, Kristian (Kristian); behave@ietf.org; Erik = Kline > (ek@google.com); Rajiv Asati (rajiva) > Subject: Re: [BEHAVE] Home NAPT44 - How many ports? >=20 >=20 > With regard to the DNS packets, shortening the time-out of NAT table is > another good solution. >=20 > In larger environment, we tested that when the time-out of DNS was > shortened to 3sec, the impact of such DNS requests was much smaller than > TCP sessions. > 3 sec is sufficient round-trip time in general situation. > I don't think it's necessary to place a recursive DNS server inside the C= GN. >=20 > Though there are differences between Home NAPT44 and CGN, it will work > well in both case. > That is because there are many devices in home and those seldom access > the web site within a short time simultaneously. >=20 > regards, > -- > kaname >=20 > (2013/06/06 1:27), Reinaldo Penno (repenno) wrote: > > > > On 6/5/13 1:23 PM, "Michael Richardson" > wrote: > > > >>>>>>> "repenno" =3D=3D repenno writes: > >> repenno> On the other hand, as Rajiv captured,the number of > >> repenno> UDP sessions can be much larger than the number of > >> repenno> TCP. Because the way > >> repenno> dynamic webpages are constructed today, there are > sometimes > >> repenno> literally 100s > >> repenno> of DNS requests to download a single page. > >> > >> If one is doing CGN, wouldn't it be reasonable to point customers' at > >> a recursive DNS server with an interface inside the CGN? > > Yes. That's what I suggest. But some people use, say, Google's > > DNS/OpenDns/etc and in some other cases the network is not setup > correctly. > > > >> This seems to also suggest that having a *caching* recursive DNS(SEC, > >> HOMENET+, mDNS+) server inside the customer router is also a big win. > > Yes, it is. > > > >> -- > >> ] Never tell me the odds! | ipv6 mesh > >> networks [ > >> ] Michael Richardson, Sandelman Software Works | network > >> architect [ > >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on ra= ils > >> [ > >> > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave >=20 >=20 > -- > ---- > Kaname Nishizuka > Innovative Architecture Center > NTT Communications Corporation > +81-50-3812-4704 From repenno@cisco.com Wed Jun 5 12:25:25 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A581321F9AB8; Wed, 5 Jun 2013 12:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPoEmxseDO5A; Wed, 5 Jun 2013 12:25:19 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id ABC1321F8808; Wed, 5 Jun 2013 12:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4081; q=dns/txt; s=iport; t=1370460318; x=1371669918; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=b49WIL1Ep8qYdWlzth5PaJxUt/8WbzvqgibUvQOx73U=; b=dXje9RVTCeJK/Qu8GtSScltvBceLjH+GlEr1NubhVrOeu1xjEOOkVsp0 AnHsFKgTEGXU7T4CjZwRIwoxoOuv4ZYOBJpiVtaxpsdv9OuzyNk3gdVgo nw2tfIswffxaOJ7tzPVIip6/N6gadGXFJqMbWh25S2WvY8MMZmnF/qFvU 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMNAHiPr1GtJV2Z/2dsb2JhbABaFoFbCIEQML8/fxZ0giMBAQEEAQEBNzQLDAYBCBEEAQEBChQJLgsUCQgBAQQBDQUIAYgEDL1SjWoPgQExBwaCdGEDo1+FIIMPgWkIFx8 X-IronPort-AV: E=Sophos;i="4.87,809,1363132800"; d="scan'208";a="219224168" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 05 Jun 2013 19:25:18 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r55JPIEP026188 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 19:25:18 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 14:25:17 -0500 From: "Reinaldo Penno (repenno)" To: "Rajiv Asati (rajiva)" , "Poscic, Kristian (Kristian)" , "v6ops@ietf.org" , "Softwires-wg list (softwires@ietf.org)" , "behave@ietf.org" Thread-Topic: [BEHAVE] Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAA9zuwAAkCoAAAAicnkAAFj40A Date: Wed, 5 Jun 2013 19:25:16 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090A0B86@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.243.252] Content-Type: text/plain; charset="us-ascii" Content-ID: <7D2E7946FC55804CBDC577E1BBCD5C62@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Erik Kline \(ek@google.com\)" Subject: Re: [Softwires] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 19:25:25 -0000 that's right. Depending on how much stuff you have running there might be long term TCP connections to mail servers, IM servers, Etc. With the 'connected home' I'm assuming this will go up. On 6/5/13 3:51 PM, "Rajiv Asati (rajiva)" wrote: >Reinaldo, > >I agree with you. Until I enabled DNS proxy on my router, I noticed that >UDP NAT exceeded TCP NAT entries in few occasions. Since DNS proxy got >enabled, UDP NAT entries became negligible. > >One interesting observation is how the lowest number of TCP NAT entries >stayed within the range throughout the night time (when the devices were >not manually used) based on how many apps (on the smartphones) were left >running. For ex, ~200 TCP ports on April 13-14, or ~30 TCP ports June 4. > >Cheers, >Rajiv > > >> -----Original Message----- >> From: Reinaldo Penno (repenno) >> Sent: Wednesday, June 05, 2013 11:44 AM >> To: Poscic, Kristian (Kristian); Rajiv Asati (rajiva); v6ops@ietf.org; >>Softwires- >> wg list (softwires@ietf.org); behave@ietf.org >> Cc: Erik Kline (ek@google.com) >> Subject: Re: [BEHAVE] Home NAPT44 - How many ports? >>=20 >> Yes, there are regional differences. But even then, in general, 90% of >>the >> active users can be covered by 1000 ports. I have been collecting data >>for >> many years, and actually the number of TCP ports consumed have been >> going Down due to a number of factors. >>=20 >> On the other hand, as Rajiv captured,the number of UDP sessions can be >> much larger than the number of TCP. Because the way dynamic webpages >> are constructed today, there are sometimes literally 100s of DNS >>requests to >> download a single page. >>=20 >>=20 >>=20 >> On 6/5/13 10:32 AM, "Poscic, Kristian (Kristian)" >> wrote: >>=20 >> >Thanks. Can you tell us in general what applications did you use for >>this? >> >This heavily depends on the application type in use...p2p apps, etc. >> >Since some apps spawn a large number of TCP ports for example. >> > >> >So the question is to what degree do you think is your sample >> >representative of a general user in any region? >> > >> >For example does it cover 30% of users for an ISP in NA while it covers >> >80% of users for another ISP in APAC for example? >> > >> >-----Original Message----- >> >From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> >Behalf Of Rajiv Asati (rajiva) >> >Sent: Wednesday, June 05, 2013 6:14 AM >> >To: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org); >> >behave@ietf.org >> >Cc: Erik Kline (ek@google.com) >> >Subject: [BEHAVE] Home NAPT44 - How many ports? >> > >> >Some of you may recall our discussion (during the last IETF) around >> >"how many TCP/UDP ports are enough with NAPT44" per home, as ISPs >> move >> >into >> >A+P paradigm. ~500, ~1000, ~3000??? >> > >> >Well, I started monitoring my home router and plotting the NAPT44 port >> >utilization on a minute-by-minute basis. You may find it here - >> >http://www.employees.org/~rajiva >> > >> >In short, port range of 500 seems ok, though 1000 would be more than >> >enough for my home. Suffice to say, this is just a sample >> >representation, since the port utilization would vary home to home, >> >based on number of active devices, type of applications, the degree of >> >simultaneous device or application usage etc. >> > >> >If any of you are doing similar monitoring, then please share. >> > >> >Cheers, >> >Rajiv >> > >> >PS: Thanks to Erik Kline, who explained (with sufficient details) how >> >to use google charting for my data. And thanks to Xun Wang & Shaoshuai >> >Dai for helping me out significantly. >> > >> >PS: My home has 3-4 active devices. >> >_______________________________________________ >> >Behave mailing list >> >Behave@ietf.org >> >https://www.ietf.org/mailman/listinfo/behave >> >_______________________________________________ >> >Behave mailing list >> >Behave@ietf.org >> >https://www.ietf.org/mailman/listinfo/behave > From repenno@cisco.com Wed Jun 5 12:39:57 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A4C21F8CB5; Wed, 5 Jun 2013 12:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.699 X-Spam-Level: X-Spam-Status: No, score=-9.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbPH-mz39LQo; Wed, 5 Jun 2013 12:39:52 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1FF21F84DF; Wed, 5 Jun 2013 12:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2825; q=dns/txt; s=iport; t=1370460459; x=1371670059; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/veQ6r28SRLWB37Ehd5E90SCc7kT+NUcWnvDVnnVIYo=; b=Tm3fL+iCeJpTlIYbkIy84+3JrGig+kKhVD6Qb6/iOmgyw5QBLrWbLO5g Bt95LtKcgQ4M9ho2nfwumZNXKlBtjsoBSiiNgRzffmsbCXW0yxrLWn5am 5z7zb0jDN/3G+Vvt7eHXvUuLusucM0KSEPhQ5uNtrpeoEuBVS+8zzkqmz o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4NAPGPr1GtJV2c/2dsb2JhbABagXEIgRAwvz9/FnSCIwEBAQQ6PwwGAQgRBAEBAQoUQh0IAgQBDQUIFodvvVuOegYrBwaCdGEDqH+DD4In X-IronPort-AV: E=Sophos;i="4.87,809,1363132800"; d="scan'208";a="216280288" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 05 Jun 2013 19:27:38 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r55JRcTf016095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 19:27:38 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 14:27:38 -0500 From: "Reinaldo Penno (repenno)" To: "Rajiv Asati (rajiva)" , Michael Richardson , "v6ops@ietf.org" Thread-Topic: [BEHAVE] Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAA9zuwAAkCoAAAB6fzgP//zuwA///5RqCAADjsgA== Date: Wed, 5 Jun 2013 19:27:38 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090A0BA6@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.243.252] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Softwires-wg list \(softwires@ietf.org\)" , "behave@ietf.org" , "Erik Kline \(ek@google.com\)" Subject: Re: [Softwires] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 19:39:57 -0000 There are some interesting measurements on this "background TCP radiation", i.e., how much state (and bandwidth) a home consumes even when there is no active use. On 6/5/13 3:57 PM, "Rajiv Asati (rajiva)" wrote: >> >If one is doing CGN, wouldn't it be reasonable to point customers' at a >> >recursive DNS server with an interface inside the CGN? >>=20 >> Yes. That's what I suggest. But some people use, say, Google's >> DNS/OpenDns/etc and in some other cases the network is not setup >> correctly. > >And in some cases, it is not possible depending on where the NAT function >is placed and where the DNS server is placed. I recently ran into this in >a large mobile network design. > >Nonetheless, it is desired, but it is not really a big deal, since UDP >NAT usage tends to be a lot less than that TCP NAT usage (barring few >exceptions). > >> >This seems to also suggest that having a *caching* recursive DNS(SEC, >> >HOMENET+, mDNS+) server inside the customer router is also a big win. >>=20 >> Yes, it is. > >Well, DNS resolver with or without proxy is a big win, I would say. > > >Cheers, >Rajiv > > >> -----Original Message----- >> From: Reinaldo Penno (repenno) >> Sent: Wednesday, June 05, 2013 12:28 PM >> To: Michael Richardson; v6ops@ietf.org >> Cc: Poscic, Kristian (Kristian); Rajiv Asati (rajiva); Softwires-wg list >> (softwires@ietf.org); behave@ietf.org; Erik Kline (ek@google.com) >> Subject: Re: [BEHAVE] Home NAPT44 - How many ports? >>=20 >>=20 >>=20 >> On 6/5/13 1:23 PM, "Michael Richardson" wrote: >>=20 >> > >> >>>>>> "repenno" =3D=3D repenno writes: >> > repenno> On the other hand, as Rajiv captured,the number of >> > repenno> UDP sessions can be much larger than the number of >> > repenno> TCP. Because the way >> > repenno> dynamic webpages are constructed today, there are >> sometimes >> > repenno> literally 100s >> > repenno> of DNS requests to download a single page. >> > >> >If one is doing CGN, wouldn't it be reasonable to point customers' at a >> >recursive DNS server with an interface inside the CGN? >>=20 >> Yes. That's what I suggest. But some people use, say, Google's >> DNS/OpenDns/etc and in some other cases the network is not setup >> correctly. >>=20 >> > >> >This seems to also suggest that having a *caching* recursive DNS(SEC, >> >HOMENET+, mDNS+) server inside the customer router is also a big win. >>=20 >> Yes, it is. >>=20 >> > >> >-- >> >] Never tell me the odds! | ipv6 mesh >> >networks [ >> >] Michael Richardson, Sandelman Software Works | network >> >architect [ >> >] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on >>rails >> > [ >> > > From wdec.ietf@gmail.com Thu Jun 6 06:23:14 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E95FF21F995C for ; Thu, 6 Jun 2013 06:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cW06pqaNhBDY for ; Thu, 6 Jun 2013 06:23:11 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0CD21F9958 for ; Thu, 6 Jun 2013 06:23:10 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id d13so286988qak.2 for ; Thu, 06 Jun 2013 06:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=i92n9PkxtJuaGYyoMUpdZ6FI3Sb9V0wiFTF4DzJ94TY=; b=xOD4nxJs148IUEBazpBK+LfCiwcpBOv4NYBMxP2zBwh+6PmK5dfAWeVxUDMkJJVwnp kXnQPdpyzDbPwCPSNgTIpeIyk7QkxSPi8yjDAR5bUxU2VQowlMi9CGkn4ZSdcnT48jt3 xnxB9O2JggEtiGu3PwqpZEj9tITWYXmUadIQakWbZT6yueqnemTTVyYIBgZYAsYFdgpy yYWgGwqpJ1JPNodjrqlNuPnmriG7vyQQJH2bRhqZBYCU1igZP1velo/s54cjigt331jO RYZRnHeiFFVTV6uwynbbQKT4E6ce8Fz8YAW19XJFmQwZWIVu2XyguFLpwZcJKqyp3qdo KJAQ== MIME-Version: 1.0 X-Received: by 10.49.95.134 with SMTP id dk6mr22240836qeb.56.1370524990069; Thu, 06 Jun 2013 06:23:10 -0700 (PDT) Received: by 10.49.109.66 with HTTP; Thu, 6 Jun 2013 06:23:09 -0700 (PDT) Date: Thu, 6 Jun 2013 15:23:09 +0200 Message-ID: From: Wojciech Dec To: Softwires-wg Content-Type: multipart/alternative; boundary=047d7b67844a307fc304de7c37d0 Cc: Congxiao Bao Subject: [Softwires] MAP-T DMR and IPv4 address mapping X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 13:23:14 -0000 --047d7b67844a307fc304de7c37d0 Content-Type: text/plain; charset=ISO-8859-1 Hello All, would like to get your feedback regarding a possible change to the way IPv4 addresses are mapped into the MAP-T DMR prefix. The current text, http://tools.ietf.org/html/draft-ietf-softwire-map-t-01#section-5.4 , follows RFC6052, and sees the IPv4 address inserted after the prefix. This aligns naturally with any/all existing NAT64 implementations, i.e. in a non-shared-address domain, a MAP-T CE would work with any regular NAT64 BR. A direct consequence of following RFC6052 is that, in cases where the prefix is shorter than /64, it results in some "bit spreading" of the IPv4 address across the u-byte. See http://tools.ietf.org/html/rfc6052#page-5. This is likely to be cumbersome operationally. An option for simplifying this, and the change proposal seeking your feedback, would be to specify that the DMR should be a /64 prefix, or at least to make a recommendation to that effect in the specification. Feedback? Regards, Woj. --047d7b67844a307fc304de7c37d0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello All,

woul= d like to get your feedback regarding a possible change to the way IPv4 add= resses are mapped into the MAP-T DMR prefix. The current text, http://= tools.ietf.org/html/draft-ietf-softwire-map-t-01#section-5.4 , follows = RFC6052, and sees the IPv4 address inserted after the prefix. This aligns n= aturally with any/all existing NAT64 implementations, i.e. in a non-shared-= address domain, a MAP-T CE would work with any regular NAT64 BR.
A direct consequence of following RFC6052 is that, in cases where the= prefix is shorter than /64, it results in some "bit spreading" o= f the IPv4 address across the u-byte. See http://tools.ietf.org/html/rfc6052#page-5. This is= likely to be cumbersome operationally.

An option for simplifying this, and the change proposal see= king your feedback, would be to specify that the DMR should be a /64 prefix= , or at least to make a recommendation to that effect in the specification.=

Feedback?

Regards,
Woj.



--047d7b67844a307fc304de7c37d0-- From otroan@employees.org Thu Jun 6 06:28:12 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DE321F9A1E for ; Thu, 6 Jun 2013 06:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LihGSK1WKVA for ; Thu, 6 Jun 2013 06:28:07 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 51B0921F9A1D for ; Thu, 6 Jun 2013 06:28:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFACeNsFGQ/khN/2dsb2JhbABZgwkwAb9GeBZ0giMBAQQBeQULCw44VwaIGgYMuxiOfzMHgnphA5hohHWLIoMROg X-IronPort-AV: E=Sophos;i="4.87,815,1363132800"; d="scan'208";a="14039936" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 06 Jun 2013 13:28:06 +0000 Received: from [10.147.112.161] (dhcp-lys01-vla250-10-147-112-161.cisco.com [10.147.112.161]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r56DS3NI031974 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Jun 2013 13:28:04 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ole Troan In-Reply-To: Date: Thu, 6 Jun 2013 15:28:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3BA2AAEA-E6CA-4370-A66E-40F5437F47E3@employees.org> References: To: Wojciech Dec X-Mailer: Apple Mail (2.1503) Cc: Softwires-wg , Congxiao Bao Subject: Re: [Softwires] MAP-T DMR and IPv4 address mapping X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 13:28:12 -0000 > would like to get your feedback regarding a possible change to the way = IPv4 addresses are mapped into the MAP-T DMR prefix. The current text, = http://tools.ietf.org/html/draft-ietf-softwire-map-t-01#section-5.4 , = follows RFC6052, and sees the IPv4 address inserted after the prefix. = This aligns naturally with any/all existing NAT64 implementations, i.e. = in a non-shared-address domain, a MAP-T CE would work with any regular = NAT64 BR.=20 > A direct consequence of following RFC6052 is that, in cases where the = prefix is shorter than /64, it results in some "bit spreading" of the = IPv4 address across the u-byte. See = http://tools.ietf.org/html/rfc6052#page-5. This is likely to be = cumbersome operationally. >=20 > An option for simplifying this, and the change proposal seeking your = feedback, would be to specify that the DMR should be a /64 prefix, or at = least to make a recommendation to that effect in the specification. given that 6man is removing the special meaning of the U/G bits, perhaps = RFC6052 should be updated, and MAP-T could ignore the U-byte? cheers, Ole From rajiva@cisco.com Thu Jun 6 06:33:47 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA9921F9402 for ; Thu, 6 Jun 2013 06:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ecajlgx+twTQ for ; Thu, 6 Jun 2013 06:33:42 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id BD4D321F9675 for ; Thu, 6 Jun 2013 06:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1910; q=dns/txt; s=iport; t=1370525622; x=1371735222; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=SwP3hr7knI6ONv19pqZnR4V0gCSM2InSX41ZJa//OKY=; b=b9AbHZZgXjsTBmPdyG2fdU9AEPi7pNBlgPW4hlhmxjxXFrF5/SBntEl+ dZD4XxKXQnkuKIRECNPGDm6vxUXCzdI8uWTyWNibpaqaOVgJUmyPW5k+b 1Xux6pqiuqaKkckmLg0QMajo0BALN/85K1KmElvto5xFiwKlaFvdYVVHr Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAGOPsFGtJXG+/2dsb2JhbABZgwkwv0d4FnSCIwEBAQQBAQE3NAsMBAIBCA4DBAEBCxQJBycLFAkIAgQBDQUIiAUMuxyPATEHBoJ0YQOYaJAXgw+CJw X-IronPort-AV: E=Sophos;i="4.87,815,1363132800"; d="scan'208";a="219544939" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 06 Jun 2013 13:33:18 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r56DXIsw006547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 13:33:18 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 08:33:17 -0500 From: "Rajiv Asati (rajiva)" To: Ole Troan , Wojciech Dec Thread-Topic: [Softwires] MAP-T DMR and IPv4 address mapping Thread-Index: AQHOYrkEkB/gHzP2vUiaCHrKAir2A5kpAbMA//+taTA= Date: Thu, 6 Jun 2013 13:33:16 +0000 Message-ID: References: <3BA2AAEA-E6CA-4370-A66E-40F5437F47E3@employees.org> In-Reply-To: <3BA2AAEA-E6CA-4370-A66E-40F5437F47E3@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.252.87] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires-wg , Congxiao Bao Subject: Re: [Softwires] MAP-T DMR and IPv4 address mapping X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 13:33:47 -0000 It would be reasonable to state it as a recommendation (unless U-octet gets= changed by 6man*), since it is advantageous to be able to find the encoded= IPv4 address relatively easily during troubleshooting. * We wouldn't want to wait for that change to happen as a normative referen= ce. Cheers, Rajiv > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > Behalf Of Ole Troan > Sent: Thursday, June 06, 2013 9:28 AM > To: Wojciech Dec > Cc: Softwires-wg; Congxiao Bao > Subject: Re: [Softwires] MAP-T DMR and IPv4 address mapping >=20 > > would like to get your feedback regarding a possible change to the way > IPv4 addresses are mapped into the MAP-T DMR prefix. The current text, > http://tools.ietf.org/html/draft-ietf-softwire-map-t-01#section-5.4 , fol= lows > RFC6052, and sees the IPv4 address inserted after the prefix. This aligns > naturally with any/all existing NAT64 implementations, i.e. in a non-shar= ed- > address domain, a MAP-T CE would work with any regular NAT64 BR. > > A direct consequence of following RFC6052 is that, in cases where the > prefix is shorter than /64, it results in some "bit spreading" of the IPv= 4 > address across the u-byte. See http://tools.ietf.org/html/rfc6052#page-5. > This is likely to be cumbersome operationally. > > > > An option for simplifying this, and the change proposal seeking your > feedback, would be to specify that the DMR should be a /64 prefix, or at > least to make a recommendation to that effect in the specification. >=20 > given that 6man is removing the special meaning of the U/G bits, perhaps > RFC6052 should be updated, and MAP-T could ignore the U-byte? >=20 > cheers, > Ole >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From rajiva@cisco.com Thu Jun 6 06:43:48 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBFBC21F9399; Thu, 6 Jun 2013 06:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M22Q7ulKIqQf; Thu, 6 Jun 2013 06:43:44 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E965221F9289; Thu, 6 Jun 2013 06:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4774; q=dns/txt; s=iport; t=1370526224; x=1371735824; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=I7M+/qo0hkPXbpmaFC2Uok5tewCDHiLzIZO6NTYB0nE=; b=lu7U40ikxNGjiWJ3yuEWqTeBhtl8XOdftf2Ti+K55Y4qGbQejekcK8Av h29HQu4S203EHwnGyfjuKhW1oLw8z7l6nNnjDvHf9Ia7R3MTgFnBLXulz JyhR5QmES9smx8YJtuWUZrPrJI8qphdPp9DGfjXCtYwJF5WUwMjUd0bb1 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFALaRsFGtJV2a/2dsb2JhbABZFoJzML9HeBZ0giMBAQEEAQEBNzQLDAQCAQgRBAEBAQoUCQcnCxQJCAEBBAENBQgBiAQMuxuNcQ+BATEHBoJ0YQOjX4Uggw+BaQgXHw X-IronPort-AV: E=Sophos;i="4.87,815,1363132800"; d="scan'208";a="219549165" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 06 Jun 2013 13:43:25 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r56DhPwW019104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 13:43:25 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 08:43:25 -0500 From: "Rajiv Asati (rajiva)" To: "Reinaldo Penno (repenno)" , "Poscic, Kristian (Kristian)" , "v6ops@ietf.org" , "Softwires-wg list (softwires@ietf.org)" , "behave@ietf.org" Thread-Topic: [BEHAVE] Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAA9zuwAAkCoAAAAicnkAAFj40AACIhOTA= Date: Thu, 6 Jun 2013 13:43:24 +0000 Message-ID: References: <45A697A8FFD7CF48BCF2BE7E106F0604090A0B86@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090A0B86@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.252.87] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Erik Kline \(ek@google.com\)" Subject: Re: [Softwires] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 13:43:49 -0000 Good point. I agree.=20 And hopefully, most of the connected home would be on IPv6 (and not on IPv4= ) in the next few yrs . :) Cheers, Rajiv > -----Original Message----- > From: Reinaldo Penno (repenno) > Sent: Wednesday, June 05, 2013 3:25 PM > To: Rajiv Asati (rajiva); Poscic, Kristian (Kristian); v6ops@ietf.org; So= ftwires- > wg list (softwires@ietf.org); behave@ietf.org > Cc: Erik Kline (ek@google.com) > Subject: Re: [BEHAVE] Home NAPT44 - How many ports? >=20 > that's right. >=20 > Depending on how much stuff you have running there might be long term > TCP connections to mail servers, IM servers, Etc. >=20 > With the 'connected home' I'm assuming this will go up. >=20 >=20 > On 6/5/13 3:51 PM, "Rajiv Asati (rajiva)" wrote: >=20 > >Reinaldo, > > > >I agree with you. Until I enabled DNS proxy on my router, I noticed > >that UDP NAT exceeded TCP NAT entries in few occasions. Since DNS proxy > >got enabled, UDP NAT entries became negligible. > > > >One interesting observation is how the lowest number of TCP NAT entries > >stayed within the range throughout the night time (when the devices > >were not manually used) based on how many apps (on the smartphones) > >were left running. For ex, ~200 TCP ports on April 13-14, or ~30 TCP por= ts > June 4. > > > >Cheers, > >Rajiv > > > > > >> -----Original Message----- > >> From: Reinaldo Penno (repenno) > >> Sent: Wednesday, June 05, 2013 11:44 AM > >> To: Poscic, Kristian (Kristian); Rajiv Asati (rajiva); > >>v6ops@ietf.org; > >>Softwires- > >> wg list (softwires@ietf.org); behave@ietf.org > >> Cc: Erik Kline (ek@google.com) > >> Subject: Re: [BEHAVE] Home NAPT44 - How many ports? > >> > >> Yes, there are regional differences. But even then, in general, 90% > >>of the active users can be covered by 1000 ports. I have been > >>collecting data for many years, and actually the number of TCP ports > >>consumed have been going Down due to a number of factors. > >> > >> On the other hand, as Rajiv captured,the number of UDP sessions can > >>be much larger than the number of TCP. Because the way dynamic > >>webpages are constructed today, there are sometimes literally 100s of > >>DNS requests to download a single page. > >> > >> > >> > >> On 6/5/13 10:32 AM, "Poscic, Kristian (Kristian)" > >> wrote: > >> > >> >Thanks. Can you tell us in general what applications did you use for > >>this? > >> >This heavily depends on the application type in use...p2p apps, etc. > >> >Since some apps spawn a large number of TCP ports for example. > >> > > >> >So the question is to what degree do you think is your sample > >> >representative of a general user in any region? > >> > > >> >For example does it cover 30% of users for an ISP in NA while it > >> >covers 80% of users for another ISP in APAC for example? > >> > > >> >-----Original Message----- > >> >From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > >> >Behalf Of Rajiv Asati (rajiva) > >> >Sent: Wednesday, June 05, 2013 6:14 AM > >> >To: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org); > >> >behave@ietf.org > >> >Cc: Erik Kline (ek@google.com) > >> >Subject: [BEHAVE] Home NAPT44 - How many ports? > >> > > >> >Some of you may recall our discussion (during the last IETF) around > >> >"how many TCP/UDP ports are enough with NAPT44" per home, as ISPs > >> move > >> >into > >> >A+P paradigm. ~500, ~1000, ~3000??? > >> > > >> >Well, I started monitoring my home router and plotting the NAPT44 > >> >port utilization on a minute-by-minute basis. You may find it here - > >> >http://www.employees.org/~rajiva > >> > > >> >In short, port range of 500 seems ok, though 1000 would be more than > >> >enough for my home. Suffice to say, this is just a sample > >> >representation, since the port utilization would vary home to home, > >> >based on number of active devices, type of applications, the degree > >> >of simultaneous device or application usage etc. > >> > > >> >If any of you are doing similar monitoring, then please share. > >> > > >> >Cheers, > >> >Rajiv > >> > > >> >PS: Thanks to Erik Kline, who explained (with sufficient details) > >> >how to use google charting for my data. And thanks to Xun Wang & > >> >Shaoshuai Dai for helping me out significantly. > >> > > >> >PS: My home has 3-4 active devices. > >> >_______________________________________________ > >> >Behave mailing list > >> >Behave@ietf.org > >> >https://www.ietf.org/mailman/listinfo/behave > >> >_______________________________________________ > >> >Behave mailing list > >> >Behave@ietf.org > >> >https://www.ietf.org/mailman/listinfo/behave > > From ssenthil@cisco.com Thu Jun 6 07:58:27 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F29821F9814 for ; Thu, 6 Jun 2013 07:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wME4CoCAuCiN for ; Thu, 6 Jun 2013 07:58:22 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB7521F9640 for ; Thu, 6 Jun 2013 07:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1590; q=dns/txt; s=iport; t=1370530701; x=1371740301; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=EPTNnIxVMD4G2JeJFMmEUmY5N9YoMfaLNMpAKqz3vIo=; b=Vv2FikdUdC4OKKdT0YwntcnZU/ssn7En32LPLT1i3fdtoLD8zDoDoRx2 mVputBydjg7OojtjuC/x3zYmaQQQj8W8Km6WjP9wiKt0Hnyu1idGC4z4F ZR9s+WaK1aNY3SSHSbLGzLWVYe4s8Oz5Cnu9ScmRKYK0Nck13s8Lp5gXx 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFABmjsFGtJXHB/2dsb2JhbABZgwkwv0d4FnSCIwEBAQMBAQEBNzQLEgEIDhQUNwslAgQBDQUIh38GDLsxjwExB4J6YQOYaJAXgw+CJw X-IronPort-AV: E=Sophos;i="4.87,815,1363132800"; d="scan'208";a="219387867" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 06 Jun 2013 14:58:06 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r56Ew6ZP010110 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 14:58:06 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.94]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 09:58:05 -0500 From: "Senthil Sivakumar (ssenthil)" To: Ole Troan , Wojciech Dec Thread-Topic: [Softwires] MAP-T DMR and IPv4 address mapping Thread-Index: AQHOYrkEQFBjfEP6tkCpESwtCwLffZkpAbMA///WG4A= Date: Thu, 6 Jun 2013 14:58:06 +0000 Message-ID: In-Reply-To: <3BA2AAEA-E6CA-4370-A66E-40F5437F47E3@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [64.102.83.112] Content-Type: text/plain; charset="us-ascii" Content-ID: <0032FFAFBFD15C4297CA997CBCC942A5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires-wg , Congxiao Bao Subject: Re: [Softwires] MAP-T DMR and IPv4 address mapping X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 14:58:27 -0000 I think that would be a great idea to update rfc 6052 to ignore the u byte. It has been a pain to code, debug and maintain with bits spraying across this artificial boundary. That would naturally help MAP-T draft as well. Thanks Senthil On 6/6/13 9:28 AM, "Ole Troan" wrote: >> would like to get your feedback regarding a possible change to the way >>IPv4 addresses are mapped into the MAP-T DMR prefix. The current text, >>http://tools.ietf.org/html/draft-ietf-softwire-map-t-01#section-5.4 , >>follows RFC6052, and sees the IPv4 address inserted after the prefix. >>This aligns naturally with any/all existing NAT64 implementations, i.e. >>in a non-shared-address domain, a MAP-T CE would work with any regular >>NAT64 BR.=20 >> A direct consequence of following RFC6052 is that, in cases where the >>prefix is shorter than /64, it results in some "bit spreading" of the >>IPv4 address across the u-byte. See >>http://tools.ietf.org/html/rfc6052#page-5. This is likely to be >>cumbersome operationally. >>=20 >> An option for simplifying this, and the change proposal seeking your >>feedback, would be to specify that the DMR should be a /64 prefix, or at >>least to make a recommendation to that effect in the specification. > >given that 6man is removing the special meaning of the U/G bits, perhaps >RFC6052 should be updated, and MAP-T could ignore the U-byte? > >cheers, >Ole > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From dwing@cisco.com Thu Jun 6 08:43:32 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E2621F9193; Thu, 6 Jun 2013 08:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHlk1C0F+5Jy; Thu, 6 Jun 2013 08:43:28 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF1921F972C; Thu, 6 Jun 2013 08:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2007; q=dns/txt; s=iport; t=1370533405; x=1371743005; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=txT9IPcn+l8DqfE0oZMDVqJhfJVx2BH1mJKxEvbLSIE=; b=lyygDkrAFl4bA0SQNTL6HYnUBgKEvW5ZF1FF3A5gC7sRV/dtwcpCiRgB sTNxsQTljsu5r7upKt0kagyiLZS1u8e6QHBwCcYgWPblZzVK/nSyLSeqd rHxoBMJnL0MN1Fi5UwnvWAWgiIlQjXdZ42RIGYhxf7TTm3l5QV2+SakvK 8=; X-IronPort-AV: E=Sophos;i="4.87,816,1363132800"; d="scan'208";a="79874449" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 06 Jun 2013 15:43:24 +0000 Received: from [10.32.240.194] ([10.32.240.194]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r56FhNUd003338; Thu, 6 Jun 2013 15:43:23 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: Date: Thu, 6 Jun 2013 08:43:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Rajiv Asati (rajiva) X-Mailer: Apple Mail (2.1503) Cc: "Softwires-wg list \(softwires@ietf.org\)" , "Erik Kline \(ek@google.com\)" , "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [Softwires] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 15:43:32 -0000 On Jun 5, 2013, at 6:14 AM, Rajiv Asati (rajiva) = wrote: > Some of you may recall our discussion (during the last IETF) around = "how many TCP/UDP ports are enough with NAPT44" per home, as ISPs move = into A+P paradigm. ~500, ~1000, ~3000??? >=20 > Well, I started monitoring my home router and plotting the NAPT44 port = utilization on a minute-by-minute basis. You may find it here - = http://www.employees.org/~rajiva >=20 > In short, port range of 500 seems ok, though 1000 would be more than = enough for my home. I see several spikes in your data over 500 ports. During those times, = applications would be unable to function (unable to get a port). April = 29/30 is a long time where that occurs very visibly, but there are = shorter spikes elsewhere such as on April 17 and April 18. If you had = only 500 ports on those days, creating a new TCP mapping would have been = impossible, impacting ability to send or receive email, order books from = Amazon.com, and so on. I am surprised you conclude that "500 seems ok" = when such a limit would interfere with your network use on those days. What is the maximum number of mappings supported by your NAPT device? = Some residential-class NATs have a limit of 1024 mappings. -d > Suffice to say, this is just a sample representation, since the port = utilization would vary home to home, based on number of active devices, = type of applications, the degree of simultaneous device or application = usage etc. >=20 > If any of you are doing similar monitoring, then please share. >=20 > Cheers, > Rajiv >=20 > PS: Thanks to Erik Kline, who explained (with sufficient details) how = to use google charting for my data. And thanks to Xun Wang & Shaoshuai = Dai for helping me out significantly. >=20 > PS: My home has 3-4 active devices. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From rajiva@cisco.com Thu Jun 6 15:41:50 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF59521F87B7; Thu, 6 Jun 2013 15:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTpdzmuxH9vS; Thu, 6 Jun 2013 15:41:46 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 20D6321F938E; Thu, 6 Jun 2013 15:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3557; q=dns/txt; s=iport; t=1370558506; x=1371768106; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GcRkabjegJdyA/Ic2V/3cSpwUoMxvBhBDzHbf+ZcycY=; b=glr8BFd7oj/hLQsswcCnfytqSRbvLO6cBKUwyxjK3LPgB9E2VwwnFXKx 4Kb/JpjmfSTxupP+eOb4Q74n+3WONPVBmCa8al7e7QbB7eknffhEhan05 q+kH4HW5f/ggwGHafBzmvB1kyLkOSYEc+d9V0ZJtylYWaxiauF0BjtR0T Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAOUOsVGtJV2Z/2dsb2JhbABZFoJzML5wehZ0giMBAQEDAQEBATc0CwUHBAIBCBEEAQEBChQQJwsdCAEBBA4FCAGHfgYMuz+NcAEJAYEGMQcGgnRhA5Ntj3KFIIMPgWgBCBcf X-IronPort-AV: E=Sophos;i="4.87,817,1363132800"; d="scan'208";a="219603490" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 06 Jun 2013 22:41:45 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r56Mfjcd011311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 22:41:45 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 17:41:44 -0500 From: "Rajiv Asati (rajiva)" To: "Dan Wing (dwing)" Thread-Topic: [BEHAVE] Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlABChP6AAALM1dA= Date: Thu, 6 Jun 2013 22:41:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.252.87] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Softwires-wg list \(softwires@ietf.org\)" , "Erik Kline \(ek@google.com\)" , "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [Softwires] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 22:41:51 -0000 Hi Dan, > and so on. I am surprised you conclude that "500 seems ok" when such a > limit would interfere with your network use on those days. I based that statement ("...seems ok,") on the very fact that the number of= times the NAT utilization exceeded 500 mappings (equating to 500 ports, in= my setup) in the sample period (~2 months) was relatively quite low. So, i= f the NAT device was limited to only 500 mappings, then the experience woul= d have been ok for 99% of the time and degraded 1% of the time. This is an = important consideration, IMO. For ex, in the last 2 weeks, the number of times NAT mappings exceeded 500 = were: June 3 - 1 time May 29 - 1 time May 28 - 3 times May 26 - 1 time May 23 - 1 time May 22 - 2 times May 21 - 3 times =20 Of course, 1000 ports (resulting in 1000+ mappings) would have been more th= an enough to accommodate the times when the mappings exceeded 500, but stay= ed within 1000 (except once). > What is the maximum number of mappings supported by your NAPT device? > Some residential-class NATs have a limit of 1024 mappings. My NAPT device seemingly can use upto 64K ports. :) Cheers, Rajiv > -----Original Message----- > From: Dan Wing (dwing) > Sent: Thursday, June 06, 2013 11:43 AM > To: Rajiv Asati (rajiva) > Cc: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org); > behave@ietf.org; Erik Kline (ek@google.com) > Subject: Re: [BEHAVE] Home NAPT44 - How many ports? >=20 >=20 > On Jun 5, 2013, at 6:14 AM, Rajiv Asati (rajiva) wrote= : >=20 > > Some of you may recall our discussion (during the last IETF) around "ho= w > many TCP/UDP ports are enough with NAPT44" per home, as ISPs move into > A+P paradigm. ~500, ~1000, ~3000??? > > > > Well, I started monitoring my home router and plotting the NAPT44 port > utilization on a minute-by-minute basis. You may find it here - > http://www.employees.org/~rajiva > > > > In short, port range of 500 seems ok, though 1000 would be more than > enough for my home. >=20 > I see several spikes in your data over 500 ports. During those times, > applications would be unable to function (unable to get a port). April 2= 9/30 > is a long time where that occurs very visibly, but there are shorter spik= es > elsewhere such as on April 17 and April 18. If you had only 500 ports on > those days, creating a new TCP mapping would have been impossible, > impacting ability to send or receive email, order books from Amazon.com, > and so on. I am surprised you conclude that "500 seems ok" when such a > limit would interfere with your network use on those days. >=20 > What is the maximum number of mappings supported by your NAPT device? > Some residential-class NATs have a limit of 1024 mappings. >=20 > -d >=20 > > Suffice to say, this is just a sample representation, since the port > utilization would vary home to home, based on number of active devices, > type of applications, the degree of simultaneous device or application > usage etc. > > > > If any of you are doing similar monitoring, then please share. > > > > Cheers, > > Rajiv > > > > PS: Thanks to Erik Kline, who explained (with sufficient details) how t= o use > google charting for my data. And thanks to Xun Wang & Shaoshuai Dai for > helping me out significantly. > > > > PS: My home has 3-4 active devices. > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Thu Jun 6 17:19:07 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2D921F9330; Thu, 6 Jun 2013 17:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytJ6g-ZpnowZ; Thu, 6 Jun 2013 17:19:03 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9F821F92E3; Thu, 6 Jun 2013 17:19:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12207; q=dns/txt; s=iport; t=1370564343; x=1371773943; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=85pyCK9m8qD2ywdUW+y5g6sX9+TFQ3DBCPnrzptH+SU=; b=A8AUfDdHRFKbm29heChSR/niteStnSa17JVZyXjAXz5H4EsPjsGOaqTh B1yV5Pa9KqVFgfdwWvulzgyhO84kdLs2+Sp3k6BWWQOfe7xXdbG1yiW4d PxpkDHAX9ofYnbNVkjVM8CQYroht7Odrk5hecPb8rZtwZt9Lu6fPbxNWU 4=; X-IronPort-AV: E=Sophos;i="4.87,818,1363132800"; d="scan'208,217";a="82926751" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 07 Jun 2013 00:19:02 +0000 Received: from [10.32.240.194] ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r570J1WU006938; Fri, 7 Jun 2013 00:19:01 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_8697BB8D-B577-4D1B-9B1B-27CA59643FD2" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: Date: Thu, 6 Jun 2013 17:19:01 -0700 Message-Id: References: To: John Mann X-Mailer: Apple Mail (2.1503) Cc: "Softwires-wg list \(softwires@ietf.org\)" , "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [Softwires] [v6ops] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 00:19:07 -0000 --Apple-Mail=_8697BB8D-B577-4D1B-9B1B-27CA59643FD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jun 6, 2013, at 5:02 PM, John Mann wrote: > Hi, >=20 > On 7 June 2013 08:41, Rajiv Asati (rajiva) wrote: > Hi Dan, >=20 > > and so on. I am surprised you conclude that "500 seems ok" when = such a > > limit would interfere with your network use on those days. >=20 > I based that statement ("...seems ok,") on the very fact that the = number of times the NAT utilization exceeded 500 mappings (equating to = 500 ports, in my setup) in the sample period (~2 months) was relatively = quite low. So, if the NAT device was limited to only 500 mappings, then = the experience would have been ok for 99% of the time and degraded 1% of = the time. This is an important consideration, IMO. >=20 > For ex, in the last 2 weeks, the number of times NAT mappings exceeded = 500 were: >=20 > June 3 - 1 time > May 29 - 1 time > May 28 - 3 times > May 26 - 1 time > May 23 - 1 time > May 22 - 2 times > May 21 - 3 times >=20 > I think a more-interesting statistic would be "how many connection = setups would have failed". > But I don't think you can measure that just by polling concurrent = connections at specific times. > It might take e.g. netflow exporting and analysis ... >=20 > However "number of concurrent connections that couldn't have been = setup" would be useful in gauging the impact > e.g. on May 29 there was one spike of 734 concurrent connections, then = report that as 234 potential failures. >=20 > Of course, 1000 ports (resulting in 1000+ mappings) would have been = more than enough to accommodate the times when the mappings exceeded = 500, but stayed within 1000 (except once). >=20 >=20 > > What is the maximum number of mappings supported by your NAPT = device? > > Some residential-class NATs have a limit of 1024 mappings. >=20 > Is that a combined limit of TCP and UDP and ICMP, or independent? The study at http://eggert.org/papers/2010-imc-hgw-study.pdf only = analyzed TCP bindings. -d >=20 > My NAPT device seemingly can use upto 64K ports. :) >=20 > Cheers, > Rajiv >=20 >=20 > > -----Original Message----- > > From: Dan Wing (dwing) > > Sent: Thursday, June 06, 2013 11:43 AM > > To: Rajiv Asati (rajiva) > > Cc: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org); > > behave@ietf.org; Erik Kline (ek@google.com) > > Subject: Re: [BEHAVE] Home NAPT44 - How many ports? > > > > > > On Jun 5, 2013, at 6:14 AM, Rajiv Asati (rajiva) = wrote: > > > > > Some of you may recall our discussion (during the last IETF) = around "how > > many TCP/UDP ports are enough with NAPT44" per home, as ISPs move = into > > A+P paradigm. ~500, ~1000, ~3000??? > > > > > > Well, I started monitoring my home router and plotting the NAPT44 = port > > utilization on a minute-by-minute basis. You may find it here - > > http://www.employees.org/~rajiva > > > > > > In short, port range of 500 seems ok, though 1000 would be more = than > > enough for my home. > > > > I see several spikes in your data over 500 ports. During those = times, > > applications would be unable to function (unable to get a port). = April 29/30 > > is a long time where that occurs very visibly, but there are shorter = spikes > > elsewhere such as on April 17 and April 18. If you had only 500 = ports on > > those days, creating a new TCP mapping would have been impossible, > > impacting ability to send or receive email, order books from = Amazon.com, > > and so on. I am surprised you conclude that "500 seems ok" when = such a > > limit would interfere with your network use on those days. > > > > What is the maximum number of mappings supported by your NAPT = device? > > Some residential-class NATs have a limit of 1024 mappings. > > > > -d > > > > > Suffice to say, this is just a sample representation, since the = port > > utilization would vary home to home, based on number of active = devices, > > type of applications, the degree of simultaneous device or = application > > usage etc. > > > > > > If any of you are doing similar monitoring, then please share. > > > > > > Cheers, > > > Rajiv > > > > > > PS: Thanks to Erik Kline, who explained (with sufficient details) = how to use > > google charting for my data. And thanks to Xun Wang & Shaoshuai Dai = for > > helping me out significantly. > > > > > > PS: My home has 3-4 active devices. > > > _______________________________________________ > > > Behave mailing list > > > Behave@ietf.org > > > https://www.ietf.org/mailman/listinfo/behave >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --Apple-Mail=_8697BB8D-B577-4D1B-9B1B-27CA59643FD2 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On Jun 6, 2013, at 5:02 PM, John Mann <john.mann@monash.edu> wrote:

Hi,

On 7 June 2013 08:41, Rajiv Asati (rajiva) <rajiva@cisco.com> wrote:
Hi Dan,

> and so on.  I am surprised you conclude that "500 seems ok" when such a
> limit would interfere with your network use on those days.

I based that statement ("...seems ok,") on the very fact that the number of times the NAT utilization exceeded 500 mappings (equating to 500 ports, in my setup) in the sample period (~2 months) was relatively quite low. So, if the NAT device was limited to only 500 mappings, then the experience would have been ok for 99% of the time and degraded 1% of the time. This is an important consideration, IMO.

For ex, in the last 2 weeks, the number of times NAT mappings exceeded 500 were:

June 3 - 1 time
May 29 - 1 time
May 28 - 3 times
May 26 - 1 time
May 23 - 1 time
May 22 - 2 times
May 21 - 3 times

I think a more-interesting statistic would be "how many connection setups would have failed".
But I don't think you can measure that just by polling concurrent connections at specific times.
It might take e.g. netflow exporting and analysis ...

However "number of concurrent connections that couldn't have been setup" would be useful in gauging the impact
e.g. on May 29 there was one spike of 734 concurrent connections, then report that as 234 potential failures.

Of course, 1000 ports (resulting in 1000+ mappings) would have been more than enough to accommodate the times when the mappings exceeded 500, but stayed within 1000 (except once).


> What is the maximum number of mappings supported by your NAPT device?
> Some residential-class NATs have a limit of 1024 mappings.

Is that a combined limit of TCP and UDP and ICMP, or independent?

The study at http://eggert.org/papers/2010-imc-hgw-study.pdf only analyzed TCP bindings.

-d



My NAPT device seemingly can use upto 64K ports. :)

Cheers,
Rajiv


> -----Original Message-----
> From: Dan Wing (dwing)
> Sent: Thursday, June 06, 2013 11:43 AM
> To: Rajiv Asati (rajiva)
> Cc: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org);
> behave@ietf.org; Erik Kline (ek@google.com)
> Subject: Re: [BEHAVE] Home NAPT44 - How many ports?
>
>
> On Jun 5, 2013, at 6:14 AM, Rajiv Asati (rajiva) <rajiva@cisco.com> wrote:
>
> > Some of you may recall our discussion (during the last IETF) around "how
> many TCP/UDP ports are enough with NAPT44" per home, as ISPs move into
> A+P paradigm. ~500, ~1000, ~3000???
> >
> > Well, I started monitoring my home router and plotting the NAPT44 port
> utilization on a minute-by-minute basis. You may find it here -
> http://www.employees.org/~rajiva
> >
> > In short, port range of 500 seems ok, though 1000 would be more than
> enough for my home.
>
> I see several spikes in your data over 500 ports.  During those times,
> applications would be unable to function (unable to get a port).  April 29/30
> is a long time where that occurs very visibly, but there are shorter spikes
> elsewhere such as on April 17 and April 18.  If you had only 500 ports on
> those days, creating a new TCP mapping would have been impossible,
> impacting ability to send or receive email, order books from Amazon.com,
> and so on.  I am surprised you conclude that "500 seems ok" when such a
> limit would interfere with your network use on those days.
>
> What is the maximum number of mappings supported by your NAPT device?
> Some residential-class NATs have a limit of 1024 mappings.
>
> -d
>
> > Suffice to say, this is just a sample representation, since the port
> utilization would vary home to home, based on number of active devices,
> type of applications, the degree of simultaneous device or application
> usage etc.
> >
> > If any of you are doing similar monitoring, then please share.
> >
> > Cheers,
> > Rajiv
> >
> > PS: Thanks to Erik Kline, who explained (with sufficient details) how to use
> google charting for my data. And thanks to Xun Wang & Shaoshuai Dai for
> helping me out significantly.
> >
> > PS: My home has 3-4 active devices.
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave

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


--Apple-Mail=_8697BB8D-B577-4D1B-9B1B-27CA59643FD2-- From Branimir.Rajtar@t.ht.hr Fri Jun 7 00:31:42 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35E921F9619; Fri, 7 Jun 2013 00:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.602 X-Spam-Level: X-Spam-Status: No, score=0.602 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJ-9C7XsGGY0; Fri, 7 Jun 2013 00:31:36 -0700 (PDT) Received: from mx01.t.ht.hr (mx01.t.ht.hr [195.29.161.88]) by ietfa.amsl.com (Postfix) with SMTP id EBB9A21F944C; Fri, 7 Jun 2013 00:31:34 -0700 (PDT) Received: from no.name.available by mx01.t.ht.hr via smtpd (for mail.ietf.org [12.22.58.30]) with ESMTP; Fri, 7 Jun 2013 08:59:25 +0200 Received: from (unknown [172.17.66.76]) by scmg1.t.ht.hr with smtp id 5a79_411d_46d8ffac_cf44_11e2_850b_00221951415f; Fri, 07 Jun 2013 09:31:32 +0200 Received: (private information removed) Fri, 7 Jun 2013 09:31:32 +0200 Received: (private information removed) S2010EXCHCA1.ad.local ([::1]) with mapi id 14.03.0123.003; Fri, 7 Jun 2013 09:31:32 +0200 From: Branimir Rajtar To: Dan Wing , John Mann Thread-Topic: [BEHAVE] [v6ops] Home NAPT44 - How many ports? Thread-Index: AQHOYxSmFlmur/cKQ0iajTdwC2BYP5kp2xNQ Date: Fri, 7 Jun 2013 07:31:32 +0000 Message-ID: <786F13AA11E69F4DB2CCA23F7400C2FB01464D5F@S2010EXCH1.ad.local> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.5.14] Content-Type: multipart/alternative; boundary="_000_786F13AA11E69F4DB2CCA23F7400C2FB01464D5FS2010EXCH1adloc_" MIME-Version: 1.0 X-OriginalArrivalTime: 07 Jun 2013 07:31:32.0737 (UTC) FILETIME=[088E5710:01CE6351] Cc: "Softwires-wg list \(softwires@ietf.org\)" , "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [Softwires] [BEHAVE] [v6ops] Home NAPT44 - How many ports? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 07:31:42 -0000 --_000_786F13AA11E69F4DB2CCA23F7400C2FB01464D5FS2010EXCH1adloc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 SGkgYWxsLAoKSSd2ZSBiZWVuIHdvcmtpbmcgcXVpdGUgc29tZSB0aW1lIHdpdGggSG9tZSBHYXRl d2F5cyBhbmQgaW4gbXkgZXhwZXJpZW5jZSB0aGUgb2xkZXIgbW9kZWxzICgzKyB5ZWFycykgdHlw aWNhbGx5IHN1cHBvcnQgMTAwMC0yMDAwIHNpbXVsdGFuZW91cyBzZXNzaW9ucywgd2hpbGUgdGhl IG5ld2VyIG9uZXMgZ28gdXAgdG8gNDAwMCwgc29tZSBldmVuIHVwIHRvIDkwMDAuCgpCcmFuaW1p cgoKRnJvbTogYmVoYXZlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpiZWhhdmUtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhbiBXaW5nClNlbnQ6IEZyaWRheSwgSnVuZSAwNywgMjAx MyAyOjE5IEFNClRvOiBKb2huIE1hbm4KQ2M6IFNvZnR3aXJlcy13ZyBsaXN0IChzb2Z0d2lyZXNA aWV0Zi5vcmcpOyB2Nm9wc0BpZXRmLm9yZzsgYmVoYXZlQGlldGYub3JnOyBSYWppdiBBc2F0aSAo cmFqaXZhKQpTdWJqZWN0OiBSZTogW0JFSEFWRV0gW3Y2b3BzXSBIb21lIE5BUFQ0NCAtIEhvdyBt YW55IHBvcnRzPwoKCk9uIEp1biA2LCAyMDEzLCBhdCA1OjAyIFBNLCBKb2huIE1hbm4gPGpvaG4u bWFubkBtb25hc2guZWR1PG1haWx0bzpqb2huLm1hbm5AbW9uYXNoLmVkdT4+IHdyb3RlOgoKCkhp LAoKT24gNyBKdW5lIDIwMTMgMDg6NDEsIFJhaml2IEFzYXRpIChyYWppdmEpIDxyYWppdmFAY2lz Y28uY29tPG1haWx0bzpyYWppdmFAY2lzY28uY29tPj4gd3JvdGU6CkhpIERhbiwKCj4gYW5kIHNv IG9uLiAgSSBhbSBzdXJwcmlzZWQgeW91IGNvbmNsdWRlIHRoYXQgIjUwMCBzZWVtcyBvayIgd2hl biBzdWNoIGEKPiBsaW1pdCB3b3VsZCBpbnRlcmZlcmUgd2l0aCB5b3VyIG5ldHdvcmsgdXNlIG9u IHRob3NlIGRheXMuCkkgYmFzZWQgdGhhdCBzdGF0ZW1lbnQgKCIuLi5zZWVtcyBvaywiKSBvbiB0 aGUgdmVyeSBmYWN0IHRoYXQgdGhlIG51bWJlciBvZiB0aW1lcyB0aGUgTkFUIHV0aWxpemF0aW9u IGV4Y2VlZGVkIDUwMCBtYXBwaW5ncyAoZXF1YXRpbmcgdG8gNTAwIHBvcnRzLCBpbiBteSBzZXR1 cCkgaW4gdGhlIHNhbXBsZSBwZXJpb2QgKH4yIG1vbnRocykgd2FzIHJlbGF0aXZlbHkgcXVpdGUg bG93LiBTbywgaWYgdGhlIE5BVCBkZXZpY2Ugd2FzIGxpbWl0ZWQgdG8gb25seSA1MDAgbWFwcGlu Z3MsIHRoZW4gdGhlIGV4cGVyaWVuY2Ugd291bGQgaGF2ZSBiZWVuIG9rIGZvciA5OSUgb2YgdGhl IHRpbWUgYW5kIGRlZ3JhZGVkIDElIG9mIHRoZSB0aW1lLiBUaGlzIGlzIGFuIGltcG9ydGFudCBj b25zaWRlcmF0aW9uLCBJTU8uCgpGb3IgZXgsIGluIHRoZSBsYXN0IDIgd2Vla3MsIHRoZSBudW1i ZXIgb2YgdGltZXMgTkFUIG1hcHBpbmdzIGV4Y2VlZGVkIDUwMCB3ZXJlOgoKSnVuZSAzIC0gMSB0 aW1lCk1heSAyOSAtIDEgdGltZQpNYXkgMjggLSAzIHRpbWVzCk1heSAyNiAtIDEgdGltZQpNYXkg MjMgLSAxIHRpbWUKTWF5IDIyIC0gMiB0aW1lcwpNYXkgMjEgLSAzIHRpbWVzCgpJIHRoaW5rIGEg bW9yZS1pbnRlcmVzdGluZyBzdGF0aXN0aWMgd291bGQgYmUgImhvdyBtYW55IGNvbm5lY3Rpb24g c2V0dXBzIHdvdWxkIGhhdmUgZmFpbGVkIi4KQnV0IEkgZG9uJ3QgdGhpbmsgeW91IGNhbiBtZWFz dXJlIHRoYXQganVzdCBieSBwb2xsaW5nIGNvbmN1cnJlbnQgY29ubmVjdGlvbnMgYXQgc3BlY2lm aWMgdGltZXMuCkl0IG1pZ2h0IHRha2UgZS5nLiBuZXRmbG93IGV4cG9ydGluZyBhbmQgYW5hbHlz aXMgLi4uCgpIb3dldmVyICJudW1iZXIgb2YgY29uY3VycmVudCBjb25uZWN0aW9ucyB0aGF0IGNv dWxkbid0IGhhdmUgYmVlbiBzZXR1cCIgd291bGQgYmUgdXNlZnVsIGluIGdhdWdpbmcgdGhlIGlt cGFjdAplLmcuIG9uIE1heSAyOSB0aGVyZSB3YXMgb25lIHNwaWtlIG9mIDczNCBjb25jdXJyZW50 IGNvbm5lY3Rpb25zLCB0aGVuIHJlcG9ydCB0aGF0IGFzIDIzNCBwb3RlbnRpYWwgZmFpbHVyZXMu CgpPZiBjb3Vyc2UsIDEwMDAgcG9ydHMgKHJlc3VsdGluZyBpbiAxMDAwKyBtYXBwaW5ncykgd291 bGQgaGF2ZSBiZWVuIG1vcmUgdGhhbiBlbm91Z2ggdG8gYWNjb21tb2RhdGUgdGhlIHRpbWVzIHdo ZW4gdGhlIG1hcHBpbmdzIGV4Y2VlZGVkIDUwMCwgYnV0IHN0YXllZCB3aXRoaW4gMTAwMCAoZXhj ZXB0IG9uY2UpLgoKCj4gV2hhdCBpcyB0aGUgbWF4aW11bSBudW1iZXIgb2YgbWFwcGluZ3Mgc3Vw cG9ydGVkIGJ5IHlvdXIgTkFQVCBkZXZpY2U/Cj4gU29tZSByZXNpZGVudGlhbC1jbGFzcyBOQVRz IGhhdmUgYSBsaW1pdCBvZiAxMDI0IG1hcHBpbmdzLgoKSXMgdGhhdCBhIGNvbWJpbmVkIGxpbWl0 IG9mIFRDUCBhbmQgVURQIGFuZCBJQ01QLCBvciBpbmRlcGVuZGVudD8KClRoZSBzdHVkeSBhdCBo dHRwOi8vZWdnZXJ0Lm9yZy9wYXBlcnMvMjAxMC1pbWMtaGd3LXN0dWR5LnBkZiBvbmx5IGFuYWx5 emVkIFRDUCBiaW5kaW5ncy4KCi1kCgoKCgpNeSBOQVBUIGRldmljZSBzZWVtaW5nbHkgY2FuIHVz ZSB1cHRvIDY0SyBwb3J0cy4gOikKCkNoZWVycywKUmFqaXYKCgo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tCj4gRnJvbTogRGFuIFdpbmcgKGR3aW5nKQo+IFNlbnQ6IFRodXJzZGF5LCBKdW5l IDA2LCAyMDEzIDExOjQzIEFNCj4gVG86IFJhaml2IEFzYXRpIChyYWppdmEpCj4gQ2M6IHY2b3Bz QGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz47IFNvZnR3aXJlcy13ZyBsaXN0IChzb2Z0 d2lyZXNAaWV0Zi5vcmc8bWFpbHRvOnNvZnR3aXJlc0BpZXRmLm9yZz4pOwo+IGJlaGF2ZUBpZXRm Lm9yZzxtYWlsdG86YmVoYXZlQGlldGYub3JnPjsgRXJpayBLbGluZSAoZWtAZ29vZ2xlLmNvbTxt YWlsdG86ZWtAZ29vZ2xlLmNvbT4pCj4gU3ViamVjdDogUmU6IFtCRUhBVkVdIEhvbWUgTkFQVDQ0 IC0gSG93IG1hbnkgcG9ydHM/Cj4KPgo+IE9uIEp1biA1LCAyMDEzLCBhdCA2OjE0IEFNLCBSYWpp diBBc2F0aSAocmFqaXZhKSA8cmFqaXZhQGNpc2NvLmNvbTxtYWlsdG86cmFqaXZhQGNpc2NvLmNv bT4+IHdyb3RlOgo+Cj4gPiBTb21lIG9mIHlvdSBtYXkgcmVjYWxsIG91ciBkaXNjdXNzaW9uIChk dXJpbmcgdGhlIGxhc3QgSUVURikgYXJvdW5kICJob3cKPiBtYW55IFRDUC9VRFAgcG9ydHMgYXJl IGVub3VnaCB3aXRoIE5BUFQ0NCIgcGVyIGhvbWUsIGFzIElTUHMgbW92ZSBpbnRvCj4gQStQIHBh cmFkaWdtLiB+NTAwLCB+MTAwMCwgfjMwMDA/Pz8KPiA+Cj4gPiBXZWxsLCBJIHN0YXJ0ZWQgbW9u aXRvcmluZyBteSBob21lIHJvdXRlciBhbmQgcGxvdHRpbmcgdGhlIE5BUFQ0NCBwb3J0Cj4gdXRp bGl6YXRpb24gb24gYSBtaW51dGUtYnktbWludXRlIGJhc2lzLiBZb3UgbWF5IGZpbmQgaXQgaGVy ZSAtCj4gaHR0cDovL3d3dy5lbXBsb3llZXMub3JnL35yYWppdmEKPiA+Cj4gPiBJbiBzaG9ydCwg cG9ydCByYW5nZSBvZiA1MDAgc2VlbXMgb2ssIHRob3VnaCAxMDAwIHdvdWxkIGJlIG1vcmUgdGhh bgo+IGVub3VnaCBmb3IgbXkgaG9tZS4KPgo+IEkgc2VlIHNldmVyYWwgc3Bpa2VzIGluIHlvdXIg ZGF0YSBvdmVyIDUwMCBwb3J0cy4gIER1cmluZyB0aG9zZSB0aW1lcywKPiBhcHBsaWNhdGlvbnMg d291bGQgYmUgdW5hYmxlIHRvIGZ1bmN0aW9uICh1bmFibGUgdG8gZ2V0IGEgcG9ydCkuICBBcHJp bCAyOS8zMAo+IGlzIGEgbG9uZyB0aW1lIHdoZXJlIHRoYXQgb2NjdXJzIHZlcnkgdmlzaWJseSwg YnV0IHRoZXJlIGFyZSBzaG9ydGVyIHNwaWtlcwo+IGVsc2V3aGVyZSBzdWNoIGFzIG9uIEFwcmls IDE3IGFuZCBBcHJpbCAxOC4gIElmIHlvdSBoYWQgb25seSA1MDAgcG9ydHMgb24KPiB0aG9zZSBk YXlzLCBjcmVhdGluZyBhIG5ldyBUQ1AgbWFwcGluZyB3b3VsZCBoYXZlIGJlZW4gaW1wb3NzaWJs ZSwKPiBpbXBhY3RpbmcgYWJpbGl0eSB0byBzZW5kIG9yIHJlY2VpdmUgZW1haWwsIG9yZGVyIGJv b2tzIGZyb20gQW1hem9uLmNvbTxodHRwOi8vQW1hem9uLmNvbT4sCj4gYW5kIHNvIG9uLiAgSSBh bSBzdXJwcmlzZWQgeW91IGNvbmNsdWRlIHRoYXQgIjUwMCBzZWVtcyBvayIgd2hlbiBzdWNoIGEK PiBsaW1pdCB3b3VsZCBpbnRlcmZlcmUgd2l0aCB5b3VyIG5ldHdvcmsgdXNlIG9uIHRob3NlIGRh eXMuCj4KPiBXaGF0IGlzIHRoZSBtYXhpbXVtIG51bWJlciBvZiBtYXBwaW5ncyBzdXBwb3J0ZWQg YnkgeW91ciBOQVBUIGRldmljZT8KPiBTb21lIHJlc2lkZW50aWFsLWNsYXNzIE5BVHMgaGF2ZSBh IGxpbWl0IG9mIDEwMjQgbWFwcGluZ3MuCj4KPiAtZAo+Cj4gPiBTdWZmaWNlIHRvIHNheSwgdGhp cyBpcyBqdXN0IGEgc2FtcGxlIHJlcHJlc2VudGF0aW9uLCBzaW5jZSB0aGUgcG9ydAo+IHV0aWxp emF0aW9uIHdvdWxkIHZhcnkgaG9tZSB0byBob21lLCBiYXNlZCBvbiBudW1iZXIgb2YgYWN0aXZl IGRldmljZXMsCj4gdHlwZSBvZiBhcHBsaWNhdGlvbnMsIHRoZSBkZWdyZWUgb2Ygc2ltdWx0YW5l b3VzIGRldmljZSBvciBhcHBsaWNhdGlvbgo+IHVzYWdlIGV0Yy4KPiA+Cj4gPiBJZiBhbnkgb2Yg eW91IGFyZSBkb2luZyBzaW1pbGFyIG1vbml0b3JpbmcsIHRoZW4gcGxlYXNlIHNoYXJlLgo+ID4K PiA+IENoZWVycywKPiA+IFJhaml2Cj4gPgo+ID4gUFM6IFRoYW5rcyB0byBFcmlrIEtsaW5lLCB3 aG8gZXhwbGFpbmVkICh3aXRoIHN1ZmZpY2llbnQgZGV0YWlscykgaG93IHRvIHVzZQo+IGdvb2ds ZSBjaGFydGluZyBmb3IgbXkgZGF0YS4gQW5kIHRoYW5rcyB0byBYdW4gV2FuZyAmIFNoYW9zaHVh aSBEYWkgZm9yCj4gaGVscGluZyBtZSBvdXQgc2lnbmlmaWNhbnRseS4KPiA+Cj4gPiBQUzogTXkg aG9tZSBoYXMgMy00IGFjdGl2ZSBkZXZpY2VzLgo+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KPiA+IEJlaGF2ZSBtYWlsaW5nIGxpc3QKPiA+IEJlaGF2 ZUBpZXRmLm9yZzxtYWlsdG86QmVoYXZlQGlldGYub3JnPgo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9iZWhhdmUKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCnY2b3BzIG1haWxpbmcgbGlzdAp2Nm9wc0BpZXRmLm9yZzxtYWls dG86djZvcHNAaWV0Zi5vcmc+Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v djZvcHMKCgoKCjxIVE1MPjxQPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Izk5OTk5OSBzaXplPTE+ DQoNCklaSkFWQSBPIE9EUklDQU5KVSBPREdPVk9STk9TVEk6IFNhZHLFvmFqIG92ZSBwb3J1a2Ug aSBldmVudHVhbG5vIHByaWxvxb5lbmloIGRhdG90ZWthIGplIHBvdmplcmxqaXYgaSBuYW1pamVu amVuIGplIHNhbW8gb3NvYmFtYSBpbGkgc3ViamVrdGltYSBrb2ppIHN1IG5hdmVkZW5pIHUgYWRy ZXNpLiBVa29saWtvIHN0ZSBwcmltaWxpIG92dSBwb3J1a3UgZ3JlxaFrb20sIG1vbGltbyBWYXMs IG9iYXZpamVzdGl0ZSBwb8WhaWxqYXRlbGphLCBhIHBvcnVrdSBpIHN2ZSBuamVuZSBwcml2aXRr ZSBvZG1haCwgYmV6IMSNaXRhbmphLCB0cmFqbm8gdWtsb25pdGUgcyByYcSNdW5hbGEuIEJpbG8g a2Frdm8gcHJlbm/FoWVuamUsIGtvcGlyYW5qZSBpbGkgZGlzdHJpYnVjaWphIGluZm9ybWFjaWph IHNhZHLFvmFuaWggdSBwb3J1Y2kgdHJlxIdpbSBvc29iYW1hIGplIHphYnJhbmplbm8gaSBtb8W+ ZSBiaXRpIHpha29uc2tpIGthxb5uaml2by4gU2FkcsW+YWosIHN0YXZvdmkgaSBtacWhbGplbmph IGl6bmVzZW5pIHUgcG9ydWNpIHN1IGF1dG9yb3ZpIGkgbmUgcHJlZHN0YXZsamFqdSBudcW+bm8g c3Rhdm92ZSBIVCAtIEhydmF0c2tpaCB0ZWxla29tdW5pa2FjaWphIGQuZC4gSFQgbmUgcHJpaHZh xIdhIG5pa2FrdnUgb2Rnb3Zvcm5vc3QgemEgZXZlbnR1YWxudSDFoXRldHUgbmFzdGFsdSBwcmlt aXRrb20gb3ZlIHBvcnVrZSBpIHByaWxvZ2Egc2FkcsW+YW5paCB1IHBvcnVjaS4NCg0KPC9GT05U PjwvUD48UD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSM5OTk5OTkgc2l6ZT0xPg0KDQogRElTQ0xB SU1FUjpUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhcyB3ZWxsIGFzIGFueSBmaWxlcyBhdHRh Y2hlZCB0byBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIGluZGl2 aWR1YWxzIG9yIGVudGl0aWVzIHdoaWNoIHRoZXkgYXJlIGFkZHJlc3NlZCB0by4gSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgYW5kIHBlcm1hbmVudGx5IHJlbW92ZSB0aGUgbWVzc2FnZSBhbmQgYWxsIGF0dGFj aGVkIGZpbGVzIGZyb20gdGhlIGNvbXB1dGVyLiBBbnkgZGlzY2xvc3VyZSwgY29weWluZyBvciBk aXN0cmlidXRpb24gb2YgYWxsIG9yIGEgcGFydCBvZiBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVy ZWluIHRvIG9yIGJ5IHRoaXJkIHBhcnRpZXMgaXMgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3 ZnVsLiBQbGVhc2Ugbm90ZSB0aGF0IGFueSB2aWV3cyBvciBvcGluaW9ucyBwcmVzZW50ZWQgaW4g dGhpcyBtZXNzYWdlIGFyZSBzb2xlbHkgdGhvc2Ugb2YgdGhlIGF1dGhvciBhbmQgZG8gbm90IG5l Y2Vzc2FyaWx5IHJlcHJlc2VudCB0aGUgdmlld3MgYW5kIG9waW5pb25zIG9mIENyb2F0aWFuIFRl bGVjb20gSW5jLiBDcm9hdGlhbiBUZWxlY29tIEluYy4gYWNjZXB0cyBubyBsaWFiaWxpdHkgZm9y IGFueSBwb3RlbnRpYWwgZGFtYWdlIGNhdXNlZCBieSB0aGlzIG1lc3NhZ2UgYW5kIGZpbGVzIGF0 dGFjaGVkIHRvIGl0Lg0KDQo8L0ZPTlQ+PC9QPjwvSFRNTD4K --_000_786F13AA11E69F4DB2CCA23F7400C2FB01464D5FS2010EXCH1adloc_ Content-Type: text/HTML; charset="utf-8" Content-Transfer-Encoding: base64 X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4KPGhlYWQ+CjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQt VHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj4KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+ CjxzdHlsZT48IS0tCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8KQGZvbnQtZmFjZQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOwoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9CkBmb250 LWZhY2UKCXtmb250LWZhbWlseTpDYWxpYnJpOwoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQpAZm9udC1mYWNlCgl7Zm9udC1mYW1pbHk6VGFob21hOwoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLwpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsCgl7bWFyZ2luOjBjbTsKCW1hcmdpbi1ib3R0b206LjAwMDFw dDsKCWZvbnQtc2l6ZToxMi4wcHQ7Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy aWYiO30KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluawoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsK CWNvbG9yOmJsdWU7Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJY29sb3I6cHVy cGxlOwoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9CnNwYW4uRW1haWxTdHlsZTE3Cgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOwoJY29sb3I6IzFGNDk3RDt9Ci5Nc29DaHBEZWZhdWx0Cgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7Cglmb250LXNpemU6MTAuMHB0O30KQHBhZ2UgV29yZFNlY3Rpb24xCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7CgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVw dDt9CmRpdi5Xb3JkU2VjdGlvbjEKCXtwYWdlOldvcmRTZWN0aW9uMTt9Ci0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPgo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPgo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+CjwvaGVhZD4KPGJvZHkgbGFu Zz0iSFIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFr LXdvcmQ7LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOy13ZWJraXQtbGluZS1icmVhazogYWZ0ZXIt d2hpdGUtc3BhY2UiPgo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkhpIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkndmUgYmVlbiB3 b3JraW5nIHF1aXRlIHNvbWUgdGltZSB3aXRoIEhvbWUgR2F0ZXdheXMgYW5kIGluIG15IGV4cGVy aWVuY2UgdGhlIG9sZGVyIG1vZGVscyAoMyYjNDM7IHllYXJzKSB0eXBpY2FsbHkgc3VwcG9ydCAx MDAwLTIwMDAgc2ltdWx0YW5lb3VzCiBzZXNzaW9ucywgd2hpbGUgdGhlIG5ld2VyIG9uZXMgZ28g dXAgdG8gNDAwMCwgc29tZSBldmVuIHVwIHRvIDkwMDAuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+QnJhbmltaXI8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjojMUY0OTdEIj4KPG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPGRpdj4KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiBiZWhhdmUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmJlaGF2ZS1ib3VuY2Vz QGlldGYub3JnXQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkRhbiBXaW5nPGJyPgo8Yj5TZW50OjwvYj4g RnJpZGF5LCBKdW5lIDA3LCAyMDEzIDI6MTkgQU08YnI+CjxiPlRvOjwvYj4gSm9obiBNYW5uPGJy Pgo8Yj5DYzo8L2I+IFNvZnR3aXJlcy13ZyBsaXN0IChzb2Z0d2lyZXNAaWV0Zi5vcmcpOyB2Nm9w c0BpZXRmLm9yZzsgYmVoYXZlQGlldGYub3JnOyBSYWppdiBBc2F0aSAocmFqaXZhKTxicj4KPGI+ U3ViamVjdDo8L2I+IFJlOiBbQkVIQVZFXSBbdjZvcHNdIEhvbWUgTkFQVDQ0IC0gSG93IG1hbnkg cG9ydHM/PG86cD48L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPC9kaXY+CjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+Cjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+CjxkaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5PbiBKdW4gNiwgMjAxMywgYXQgNTowMiBQTSwgSm9obiBNYW5uICZsdDs8YSBocmVmPSJt YWlsdG86am9obi5tYW5uQG1vbmFzaC5lZHUiPmpvaG4ubWFubkBtb25hc2guZWR1PC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4KPGJyPgo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxkaXY+ CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5PbiA3IEp1bmUgMjAxMyAwODo0MSwgUmFqaXYgQXNhdGkgKHJhaml2 YSkgJmx0OzxhIGhyZWY9Im1haWx0bzpyYWppdmFAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ cmFqaXZhQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIERhbiw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4KJmd0OyBhbmQgc28gb24uICZuYnNwO0kg YW0gc3VycHJpc2VkIHlvdSBjb25jbHVkZSB0aGF0ICZxdW90OzUwMCBzZWVtcyBvayZxdW90OyB3 aGVuIHN1Y2ggYTxicj4KJmd0OyBsaW1pdCB3b3VsZCBpbnRlcmZlcmUgd2l0aCB5b3VyIG5ldHdv cmsgdXNlIG9uIHRob3NlIGRheXMuPG86cD48L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgYmFzZWQgdGhhdCBzdGF0ZW1lbnQg KCZxdW90Oy4uLnNlZW1zIG9rLCZxdW90Oykgb24gdGhlIHZlcnkgZmFjdCB0aGF0IHRoZSBudW1i ZXIgb2YgdGltZXMgdGhlIE5BVCB1dGlsaXphdGlvbiBleGNlZWRlZCA1MDAgbWFwcGluZ3MgKGVx dWF0aW5nIHRvIDUwMCBwb3J0cywgaW4gbXkgc2V0dXApIGluIHRoZSBzYW1wbGUgcGVyaW9kICh+ MiBtb250aHMpIHdhcyByZWxhdGl2ZWx5IHF1aXRlIGxvdy4KIFNvLCBpZiB0aGUgTkFUIGRldmlj ZSB3YXMgbGltaXRlZCB0byBvbmx5IDUwMCBtYXBwaW5ncywgdGhlbiB0aGUgZXhwZXJpZW5jZSB3 b3VsZCBoYXZlIGJlZW4gb2sgZm9yIDk5JSBvZiB0aGUgdGltZSBhbmQgZGVncmFkZWQgMSUgb2Yg dGhlIHRpbWUuIFRoaXMgaXMgYW4gaW1wb3J0YW50IGNvbnNpZGVyYXRpb24sIElNTy48YnI+Cjxi cj4KRm9yIGV4LCBpbiB0aGUgbGFzdCAyIHdlZWtzLCB0aGUgbnVtYmVyIG9mIHRpbWVzIE5BVCBt YXBwaW5ncyBleGNlZWRlZCA1MDAgd2VyZTo8YnI+Cjxicj4KSnVuZSAzIC0gMSB0aW1lPGJyPgpN YXkgMjkgLSAxIHRpbWU8YnI+Ck1heSAyOCAtIDMgdGltZXM8YnI+Ck1heSAyNiAtIDEgdGltZTxi cj4KTWF5IDIzIC0gMSB0aW1lPGJyPgpNYXkgMjIgLSAyIHRpbWVzPGJyPgpNYXkgMjEgLSAzIHRp bWVzPG86cD48L286cD48L3NwYW4+PC9wPgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPGRpdj4K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgdGhpbmsgYSBtb3JlLWlu dGVyZXN0aW5nIHN0YXRpc3RpYyB3b3VsZCBiZSAmcXVvdDtob3cgbWFueSBjb25uZWN0aW9uIHNl dHVwcyB3b3VsZCBoYXZlIGZhaWxlZCZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2 Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QnV0IEkgZG9u J3QgdGhpbmsgeW91IGNhbiBtZWFzdXJlIHRoYXQganVzdCBieSBwb2xsaW5nIGNvbmN1cnJlbnQg Y29ubmVjdGlvbnMgYXQgc3BlY2lmaWMgdGltZXMuPG86cD48L286cD48L3NwYW4+PC9wPgo8L2Rp dj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkl0IG1pZ2h0 IHRha2UgZS5nLiBuZXRmbG93IGV4cG9ydGluZyBhbmQgYW5hbHlzaXMgLi4uPG86cD48L286cD48 L3NwYW4+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Ib3dldmVyICZxdW90O251bWJlciBvZiBj b25jdXJyZW50IGNvbm5lY3Rpb25zIHRoYXQgY291bGRuJ3QgaGF2ZSBiZWVuIHNldHVwJnF1b3Q7 IHdvdWxkIGJlIHVzZWZ1bCBpbiZuYnNwO2dhdWdpbmcmbmJzcDt0aGUgaW1wYWN0PG86cD48L286 cD48L3NwYW4+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPmUuZy4gb24gTWF5IDI5IHRoZXJlIHdhcyBvbmUgc3Bpa2Ugb2YgNzM0IGNvbmN1 cnJlbnQgY29ubmVjdGlvbnMsIHRoZW4gcmVwb3J0IHRoYXQgYXMgMjM0IHBvdGVudGlhbCBmYWls dXJlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8L2Rp dj4KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtIj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9m IGNvdXJzZSwgMTAwMCBwb3J0cyAocmVzdWx0aW5nIGluIDEwMDAmIzQzOyBtYXBwaW5ncykgd291 bGQgaGF2ZSBiZWVuIG1vcmUgdGhhbiBlbm91Z2ggdG8gYWNjb21tb2RhdGUgdGhlIHRpbWVzIHdo ZW4gdGhlIG1hcHBpbmdzIGV4Y2VlZGVkIDUwMCwgYnV0IHN0YXllZCB3aXRoaW4gMTAwMCAoZXhj ZXB0IG9uY2UpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4KPGJyPgomZ3Q7IFdoYXQgaXMgdGhlIG1heGltdW0g bnVtYmVyIG9mIG1hcHBpbmdzIHN1cHBvcnRlZCBieSB5b3VyIE5BUFQgZGV2aWNlPzxicj4KJmd0 OyBTb21lIHJlc2lkZW50aWFsLWNsYXNzIE5BVHMgaGF2ZSBhIGxpbWl0IG9mIDEwMjQgbWFwcGlu Z3MuPG86cD48L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPC9ibG9ja3F1b3RlPgo8ZGl2Pgo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPklzIHRoYXQgYSBjb21iaW5lZCBsaW1pdCBvZiBUQ1AgYW5kIFVEUCBhbmQgSUNNUCwgb3Ig aW5kZXBlbmRlbnQ/PG86cD48L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPC9kaXY+CjwvZGl2Pgo8 L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgc3R1ZHkgYXQmbmJzcDs8YSBocmVmPSJodHRwOi8vZWdn ZXJ0Lm9yZy9wYXBlcnMvMjAxMC1pbWMtaGd3LXN0dWR5LnBkZiI+aHR0cDovL2VnZ2VydC5vcmcv cGFwZXJzLzIwMTAtaW1jLWhndy1zdHVkeS5wZGY8L2E+IG9ubHkgYW5hbHl6ZWQgVENQIGJpbmRp bmdzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2 Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LWQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4KPGJyPgo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+CjxkaXY+CjxkaXY+CjxkaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow Y20iPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TXkgTkFQVCBkZXZp Y2Ugc2VlbWluZ2x5IGNhbiB1c2UgdXB0byA2NEsgcG9ydHMuIDopPGJyPgo8YnI+CkNoZWVycyw8 YnI+ClJhaml2PG86cD48L286cD48L3NwYW4+PC9wPgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPgo8YnI+CiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS08YnI+CiZndDsgRnJvbTogRGFuIFdpbmcgKGR3aW5nKTxicj4KJmd0OyBTZW50OiBUaHVy c2RheSwgSnVuZSAwNiwgMjAxMyAxMTo0MyBBTTxicj4KJmd0OyBUbzogUmFqaXYgQXNhdGkgKHJh aml2YSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBDYzogPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGll dGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT47IFNvZnR3aXJlcy13ZyBsaXN0ICg8YSBocmVmPSJt YWlsdG86c29mdHdpcmVzQGlldGYub3JnIj5zb2Z0d2lyZXNAaWV0Zi5vcmc8L2E+KTs8YnI+CiZn dDsgPGEgaHJlZj0ibWFpbHRvOmJlaGF2ZUBpZXRmLm9yZyI+YmVoYXZlQGlldGYub3JnPC9hPjsg RXJpayBLbGluZSAoPGEgaHJlZj0ibWFpbHRvOmVrQGdvb2dsZS5jb20iPmVrQGdvb2dsZS5jb208 L2E+KTxicj4KJmd0OyBTdWJqZWN0OiBSZTogW0JFSEFWRV0gSG9tZSBOQVBUNDQgLSBIb3cgbWFu eSBwb3J0cz88YnI+CiZndDs8YnI+CiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8 ZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBP biBKdW4gNSwgMjAxMywgYXQgNjoxNCBBTSwgUmFqaXYgQXNhdGkgKHJhaml2YSkgJmx0OzxhIGhy ZWY9Im1haWx0bzpyYWppdmFAY2lzY28uY29tIj5yYWppdmFAY2lzY28uY29tPC9hPiZndDsgd3Jv dGU6PGJyPgomZ3Q7PGJyPgomZ3Q7ICZndDsgU29tZSBvZiB5b3UgbWF5IHJlY2FsbCBvdXIgZGlz Y3Vzc2lvbiAoZHVyaW5nIHRoZSBsYXN0IElFVEYpIGFyb3VuZCAmcXVvdDtob3c8YnI+CiZndDsg bWFueSBUQ1AvVURQIHBvcnRzIGFyZSBlbm91Z2ggd2l0aCBOQVBUNDQmcXVvdDsgcGVyIGhvbWUs IGFzIElTUHMgbW92ZSBpbnRvPGJyPgomZ3Q7IEEmIzQzO1AgcGFyYWRpZ20uIH41MDAsIH4xMDAw LCB+MzAwMD8/Pzxicj4KJmd0OyAmZ3Q7PGJyPgomZ3Q7ICZndDsgV2VsbCwgSSBzdGFydGVkIG1v bml0b3JpbmcgbXkgaG9tZSByb3V0ZXIgYW5kIHBsb3R0aW5nIHRoZSBOQVBUNDQgcG9ydDxicj4K Jmd0OyB1dGlsaXphdGlvbiBvbiBhIG1pbnV0ZS1ieS1taW51dGUgYmFzaXMuIFlvdSBtYXkgZmlu ZCBpdCBoZXJlIC08YnI+CiZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5lbXBsb3llZXMub3JnL35y YWppdmEiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmVtcGxveWVlcy5vcmcvfnJhaml2YTwv YT48YnI+CiZndDsgJmd0Ozxicj4KJmd0OyAmZ3Q7IEluIHNob3J0LCBwb3J0IHJhbmdlIG9mIDUw MCBzZWVtcyBvaywgdGhvdWdoIDEwMDAgd291bGQgYmUgbW9yZSB0aGFuPGJyPgomZ3Q7IGVub3Vn aCBmb3IgbXkgaG9tZS48YnI+CiZndDs8YnI+CiZndDsgSSBzZWUgc2V2ZXJhbCBzcGlrZXMgaW4g eW91ciBkYXRhIG92ZXIgNTAwIHBvcnRzLiAmbmJzcDtEdXJpbmcgdGhvc2UgdGltZXMsPGJyPgom Z3Q7IGFwcGxpY2F0aW9ucyB3b3VsZCBiZSB1bmFibGUgdG8gZnVuY3Rpb24gKHVuYWJsZSB0byBn ZXQgYSBwb3J0KS4gJm5ic3A7QXByaWwgMjkvMzA8YnI+CiZndDsgaXMgYSBsb25nIHRpbWUgd2hl cmUgdGhhdCBvY2N1cnMgdmVyeSB2aXNpYmx5LCBidXQgdGhlcmUgYXJlIHNob3J0ZXIgc3Bpa2Vz PGJyPgomZ3Q7IGVsc2V3aGVyZSBzdWNoIGFzIG9uIEFwcmlsIDE3IGFuZCBBcHJpbCAxOC4gJm5i c3A7SWYgeW91IGhhZCBvbmx5IDUwMCBwb3J0cyBvbjxicj4KJmd0OyB0aG9zZSBkYXlzLCBjcmVh dGluZyBhIG5ldyBUQ1AgbWFwcGluZyB3b3VsZCBoYXZlIGJlZW4gaW1wb3NzaWJsZSw8YnI+CiZn dDsgaW1wYWN0aW5nIGFiaWxpdHkgdG8gc2VuZCBvciByZWNlaXZlIGVtYWlsLCBvcmRlciBib29r cyBmcm9tIDxhIGhyZWY9Imh0dHA6Ly9BbWF6b24uY29tIj4KQW1hem9uLmNvbTwvYT4sPGJyPgom Z3Q7IGFuZCBzbyBvbi4gJm5ic3A7SSBhbSBzdXJwcmlzZWQgeW91IGNvbmNsdWRlIHRoYXQgJnF1 b3Q7NTAwIHNlZW1zIG9rJnF1b3Q7IHdoZW4gc3VjaCBhPGJyPgomZ3Q7IGxpbWl0IHdvdWxkIGlu dGVyZmVyZSB3aXRoIHlvdXIgbmV0d29yayB1c2Ugb24gdGhvc2UgZGF5cy48YnI+CiZndDs8YnI+ CiZndDsgV2hhdCBpcyB0aGUgbWF4aW11bSBudW1iZXIgb2YgbWFwcGluZ3Mgc3VwcG9ydGVkIGJ5 IHlvdXIgTkFQVCBkZXZpY2U/PGJyPgomZ3Q7IFNvbWUgcmVzaWRlbnRpYWwtY2xhc3MgTkFUcyBo YXZlIGEgbGltaXQgb2YgMTAyNCBtYXBwaW5ncy48YnI+CiZndDs8YnI+CiZndDsgLWQ8YnI+CiZn dDs8YnI+CiZndDsgJmd0OyBTdWZmaWNlIHRvIHNheSwgdGhpcyBpcyBqdXN0IGEgc2FtcGxlIHJl cHJlc2VudGF0aW9uLCBzaW5jZSB0aGUgcG9ydDxicj4KJmd0OyB1dGlsaXphdGlvbiB3b3VsZCB2 YXJ5IGhvbWUgdG8gaG9tZSwgYmFzZWQgb24gbnVtYmVyIG9mIGFjdGl2ZSBkZXZpY2VzLDxicj4K Jmd0OyB0eXBlIG9mIGFwcGxpY2F0aW9ucywgdGhlIGRlZ3JlZSBvZiBzaW11bHRhbmVvdXMgZGV2 aWNlIG9yIGFwcGxpY2F0aW9uPGJyPgomZ3Q7IHVzYWdlIGV0Yy48YnI+CiZndDsgJmd0Ozxicj4K Jmd0OyAmZ3Q7IElmIGFueSBvZiB5b3UgYXJlIGRvaW5nIHNpbWlsYXIgbW9uaXRvcmluZywgdGhl biBwbGVhc2Ugc2hhcmUuPGJyPgomZ3Q7ICZndDs8YnI+CiZndDsgJmd0OyBDaGVlcnMsPGJyPgom Z3Q7ICZndDsgUmFqaXY8YnI+CiZndDsgJmd0Ozxicj4KJmd0OyAmZ3Q7IFBTOiBUaGFua3MgdG8g RXJpayBLbGluZSwgd2hvIGV4cGxhaW5lZCAod2l0aCBzdWZmaWNpZW50IGRldGFpbHMpIGhvdyB0 byB1c2U8YnI+CiZndDsgZ29vZ2xlIGNoYXJ0aW5nIGZvciBteSBkYXRhLiBBbmQgdGhhbmtzIHRv IFh1biBXYW5nICZhbXA7IFNoYW9zaHVhaSBEYWkgZm9yPGJyPgomZ3Q7IGhlbHBpbmcgbWUgb3V0 IHNpZ25pZmljYW50bHkuPGJyPgomZ3Q7ICZndDs8YnI+CiZndDsgJmd0OyBQUzogTXkgaG9tZSBo YXMgMy00IGFjdGl2ZSBkZXZpY2VzLjxicj4KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPgomZ3Q7ICZndDsgQmVoYXZlIG1haWxpbmcg bGlzdDxicj4KJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpCZWhhdmVAaWV0Zi5vcmciPkJlaGF2 ZUBpZXRmLm9yZzwvYT48YnI+CiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2JlaGF2ZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYmVoYXZlPC9hPjxicj4KPGJyPgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4KdjZvcHMgbWFpbGluZyBsaXN0 PGJyPgo8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPjxi cj4KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZv cHM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPC9kaXY+CjwvYmxvY2txdW90ZT4K PC9kaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8L2Rpdj4KPC9kaXY+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2 PgoKPERJVj48UD48SFI+CjxQPjxGT05UIGNvbG9yPSM5OTk5OTkgc2l6ZT0xIGZhY2U9QXJpYWw+ SVpKQVZBIE8gT0RSSUNBTkpVIE9ER09WT1JOT1NUSTogU2FkciYjMzgyO2FqIG92ZSBwb3J1a2Ug aSBldmVudHVhbG5vIHByaWxvJiMzODI7ZW5paCBkYXRvdGVrYSBqZSBwb3ZqZXJsaml2IGkgbmFt aWplbmplbiBqZSBzYW1vIG9zb2JhbWEgaWxpIHN1Ympla3RpbWEga29qaSBzdSBuYXZlZGVuaSB1 IGFkcmVzaS4gVWtvbGlrbyBzdGUgcHJpbWlsaSBvdnUgcG9ydWt1IGdyZSYjMzUzO2tvbSwgbW9s aW1vIFZhcywgb2JhdmlqZXN0aXRlIHBvJiMzNTM7aWxqYXRlbGphLCBhIHBvcnVrdSBpIHN2ZSBu amVuZSBwcml2aXRrZSBvZG1haCwgYmV6ICYjMjY5O2l0YW5qYSwgdHJham5vIHVrbG9uaXRlIHMg cmEmIzI2OTt1bmFsYS4gQmlsbyBrYWt2byBwcmVubyYjMzUzO2VuamUsIGtvcGlyYW5qZSBpbGkg ZGlzdHJpYnVjaWphIGluZm9ybWFjaWphIHNhZHImIzM4MjthbmloIHUgcG9ydWNpIHRyZSYjMjYz O2ltIG9zb2JhbWEgamUgemFicmFuamVubyBpIG1vJiMzODI7ZSBiaXRpIHpha29uc2tpIGthJiMz ODI7bmppdm8uIFNhZHImIzM4Mjthaiwgc3Rhdm92aSBpIG1pJiMzNTM7bGplbmphIGl6bmVzZW5p IHUgcG9ydWNpIHN1IGF1dG9yb3ZpIGkgbmUgcHJlZHN0YXZsamFqdSBudSYjMzgyO25vIHN0YXZv dmUgSFQgLSBIcnZhdHNrb2cgVGVsZWtvbWEgZC5kLiBIVCBuZSBwcmlodmEmIzI2MzthIG5pa2Fr dnUgb2Rnb3Zvcm5vc3QgemEgZXZlbnR1YWxudSAmIzM1Mzt0ZXR1IG5hc3RhbHUgcHJpbWl0a29t IG92ZSBwb3J1a2UgaSBwcmlsb2dhIHNhZHImIzM4MjthbmloIHUgcG9ydWNpLiA8L0ZPTlQ+PC9Q Pg0KPFA+PEZPTlQgY29sb3I9Izk5OTk5OSBzaXplPTEgZmFjZT1BcmlhbD5ESVNDTEFJTUVSOlRo ZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFzIHdlbGwgYXMgYW55IGZpbGVzIGF0dGFjaGVkIHRv IGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgaW5kaXZpZHVhbHMg b3IgZW50aXRpZXMgd2hpY2ggdGhleSBhcmUgYWRkcmVzc2VkIHRvLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgcGVybWFuZW50bHkgcmVtb3ZlIHRoZSBtZXNzYWdlIGFuZCBhbGwgYXR0YWNoZWQgZmls ZXMgZnJvbSB0aGUgY29tcHV0ZXIuIEFueSBkaXNjbG9zdXJlLCBjb3B5aW5nIG9yIGRpc3RyaWJ1 dGlvbiBvZiBhbGwgb3IgYSBwYXJ0IG9mIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gdG8g b3IgYnkgdGhpcmQgcGFydGllcyBpcyBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIFBs ZWFzZSBub3RlIHRoYXQgYW55IHZpZXdzIG9yIG9waW5pb25zIHByZXNlbnRlZCBpbiB0aGlzIG1l c3NhZ2UgYXJlIHNvbGVseSB0aG9zZSBvZiB0aGUgYXV0aG9yIGFuZCBkbyBub3QgbmVjZXNzYXJp bHkgcmVwcmVzZW50IHRoZSB2aWV3cyBhbmQgb3BpbmlvbnMgb2YgQ3JvYXRpYW4gVGVsZWNvbSBJ bmMuIENyb2F0aWFuIFRlbGVjb20gSW5jLiBhY2NlcHRzIG5vIGxpYWJpbGl0eSBmb3IgYW55IHBv dGVudGlhbCBkYW1hZ2UgY2F1c2VkIGJ5IHRoaXMgbWVzc2FnZSBhbmQgZmlsZXMgYXR0YWNoZWQg dG8gaXQuIDwvRk9OVD48L1A+CjwvUD48L0RJVj4KPC9ib2R5Pgo8L2h0bWw+Cg== --_000_786F13AA11E69F4DB2CCA23F7400C2FB01464D5FS2010EXCH1adloc_-- From kristian.poscic@alcatel-lucent.com Fri Jun 7 10:49:44 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A48121F9968; Fri, 7 Jun 2013 10:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gu0p-srhJXoZ; Fri, 7 Jun 2013 10:49:39 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1C58821F9962; Fri, 7 Jun 2013 10:49:38 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r57HgGSw022575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 7 Jun 2013 12:49:36 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r57G6Di4004375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Jun 2013 12:06:15 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.44]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Fri, 7 Jun 2013 12:06:13 -0400 From: "Poscic, Kristian (Kristian)" To: John Mann , "Rajiv Asati (rajiva)" Thread-Topic: [BEHAVE] [v6ops] Home NAPT44 - How many ports? Thread-Index: AQHOY5e9UtUF75OTtk6+SrU9uyYH2JkqaW8w Date: Fri, 7 Jun 2013 16:06:13 +0000 Message-ID: <7921F977B17D5B49B8DCC955A339D2F02AB410F8@US70UWXCHMBA05.zam.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_7921F977B17D5B49B8DCC955A339D2F02AB410F8US70UWXCHMBA05z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "Softwires-wg list \(softwires@ietf.org\)" , "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [Softwires] [BEHAVE] [v6ops] Home NAPT44 - How many ports? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 17:49:44 -0000 --_000_7921F977B17D5B49B8DCC955A339D2F02AB410F8US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable But why is this a problem in CGN? You initially allocate a port block of 500ports to the subscriber and then = they can dynamically extend this on as needed basis (allocate a new port bl= ock). To me the value of this exercise is to determine what will this initial por= t block size be, not at which point the service will be denied since this c= an be easily extended. For RGs, it is what it is, if they have the limit of 500mapping, then yes, = this is the problem. But for CGN it shouldn't be. From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= John Mann Sent: Thursday, June 06, 2013 5:02 PM To: Rajiv Asati (rajiva) Cc: Softwires-wg list (softwires@ietf.org); v6ops@ietf.org; behave@ietf.org= ; Dan Wing (dwing) Subject: Re: [BEHAVE] [v6ops] Home NAPT44 - How many ports? Hi, On 7 June 2013 08:41, Rajiv Asati (rajiva) > wrote: Hi Dan, > and so on. I am surprised you conclude that "500 seems ok" when such a > limit would interfere with your network use on those days. I based that statement ("...seems ok,") on the very fact that the number of= times the NAT utilization exceeded 500 mappings (equating to 500 ports, in= my setup) in the sample period (~2 months) was relatively quite low. So, i= f the NAT device was limited to only 500 mappings, then the experience woul= d have been ok for 99% of the time and degraded 1% of the time. This is an = important consideration, IMO. For ex, in the last 2 weeks, the number of times NAT mappings exceeded 500 = were: June 3 - 1 time May 29 - 1 time May 28 - 3 times May 26 - 1 time May 23 - 1 time May 22 - 2 times May 21 - 3 times I think a more-interesting statistic would be "how many connection setups w= ould have failed". But I don't think you can measure that just by polling concurrent connectio= ns at specific times. It might take e.g. netflow exporting and analysis ... However "number of concurrent connections that couldn't have been setup" wo= uld be useful in gauging the impact e.g. on May 29 there was one spike of 734 concurrent connections, then repo= rt that as 234 potential failures. Of course, 1000 ports (resulting in 1000+ mappings) would have been more th= an enough to accommodate the times when the mappings exceeded 500, but stay= ed within 1000 (except once). > What is the maximum number of mappings supported by your NAPT device? > Some residential-class NATs have a limit of 1024 mappings. Is that a combined limit of TCP and UDP and ICMP, or independent? My NAPT device seemingly can use upto 64K ports. :) Cheers, Rajiv > -----Original Message----- > From: Dan Wing (dwing) > Sent: Thursday, June 06, 2013 11:43 AM > To: Rajiv Asati (rajiva) > Cc: v6ops@ietf.org; Softwires-wg list (softwires@i= etf.org); > behave@ietf.org; Erik Kline (ek@google.com) > Subject: Re: [BEHAVE] Home NAPT44 - How many ports? > > > On Jun 5, 2013, at 6:14 AM, Rajiv Asati (rajiva) > wrote: > > > Some of you may recall our discussion (during the last IETF) around "ho= w > many TCP/UDP ports are enough with NAPT44" per home, as ISPs move into > A+P paradigm. ~500, ~1000, ~3000??? > > > > Well, I started monitoring my home router and plotting the NAPT44 port > utilization on a minute-by-minute basis. You may find it here - > http://www.employees.org/~rajiva > > > > In short, port range of 500 seems ok, though 1000 would be more than > enough for my home. > > I see several spikes in your data over 500 ports. During those times, > applications would be unable to function (unable to get a port). April 2= 9/30 > is a long time where that occurs very visibly, but there are shorter spik= es > elsewhere such as on April 17 and April 18. If you had only 500 ports on > those days, creating a new TCP mapping would have been impossible, > impacting ability to send or receive email, order books from Amazon.com, > and so on. I am surprised you conclude that "500 seems ok" when such a > limit would interfere with your network use on those days. > > What is the maximum number of mappings supported by your NAPT device? > Some residential-class NATs have a limit of 1024 mappings. > > -d > > > Suffice to say, this is just a sample representation, since the port > utilization would vary home to home, based on number of active devices, > type of applications, the degree of simultaneous device or application > usage etc. > > > > If any of you are doing similar monitoring, then please share. > > > > Cheers, > > Rajiv > > > > PS: Thanks to Erik Kline, who explained (with sufficient details) how t= o use > google charting for my data. And thanks to Xun Wang & Shaoshuai Dai for > helping me out significantly. > > > > PS: My home has 3-4 active devices. > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_7921F977B17D5B49B8DCC955A339D2F02AB410F8US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

But why is this a problem= in CGN?

You initially allocate a = port block of 500ports to the subscriber and then they can dynamically exte= nd this on as needed basis (allocate a new port block).

 <= /p>

To me the value of this e= xercise is to determine what will this initial port block size be, not at w= hich point the service will be denied since this can be easily extended.

 <= /p>

For RGs, it is what it is= , if they have the limit of 500mapping, then yes, this is the problem.=

But for CGN it shouldn= 217;t be.

 <= /p>

From: behave-b= ounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of John Mann
Sent: Thursday, June 06, 2013 5:02 PM
To: Rajiv Asati (rajiva)
Cc: Softwires-wg list (softwires@ietf.org); v6ops@ietf.org; behave@i= etf.org; Dan Wing (dwing)
Subject: Re: [BEHAVE] [v6ops] Home NAPT44 - How many ports?

 

Hi,

 

On 7 June 2013 08:41, Rajiv Asati (rajiva) <rajiva@cisco.com> w= rote:

Hi Dan,


> and so on.  I am surprised you conclude that "500 seems ok&q= uot; when such a
> limit would interfere with your network use on those days.<= /p>

I based that statement ("...seems ok,") on= the very fact that the number of times the NAT utilization exceeded 500 ma= ppings (equating to 500 ports, in my setup) in the sample period (~2 months= ) was relatively quite low. So, if the NAT device was limited to only 500 mappings, then the experience would have been ok f= or 99% of the time and degraded 1% of the time. This is an important consid= eration, IMO.

For ex, in the last 2 weeks, the number of times NAT mappings exceeded 500 = were:

June 3 - 1 time
May 29 - 1 time
May 28 - 3 times
May 26 - 1 time
May 23 - 1 time
May 22 - 2 times
May 21 - 3 times

 

I think a more-interesting statistic would be "= how many connection setups would have failed".

But I don't think you can measure that just by polli= ng concurrent connections at specific times.

It might take e.g. netflow exporting and analysis ..= .

 

However "number of concurrent connections that = couldn't have been setup" would be useful in gauging the imp= act

e.g. on May 29 there was one spike of 734 concurrent= connections, then report that as 234 potential failures.

 

Of course, 1000 ports (resulting in 1000+ mappin= gs) would have been more than enough to accommodate the times when the mapp= ings exceeded 500, but stayed within 1000 (except once).



> What is the maximum number of mappings supported by your NAPT device?<= br> > Some residential-class NATs have a limit of 1024 mappings.<= /p>

 

Is that a combined limit of TCP and UDP and ICMP, or= independent?

 

My NAPT device seemingly can use upto 64K ports. :)<= br>
Cheers,
Rajiv



> -----Original Message-----
> From: Dan Wing (dwing)
> Sent: Thursday, June 06, 2013 11:43 AM
> To: Rajiv Asati (rajiva)

> Cc: v6ops@iet= f.org; Softwires-wg list (softwir= es@ietf.org);
> behave@ietf.org; Erik Kline (ek@google.com)
> Subject: Re: [BEHAVE] Home NAPT44 - How many ports?
>
>

> On Jun 5, 2013, at 6:14 AM, Rajiv Asati (rajiva= ) <rajiva@cisco.com> wrote: >
> > Some of you may recall our discussion (during the last IETF) arou= nd "how
> many TCP/UDP ports are enough with NAPT44" per home, as ISPs move= into
> A+P paradigm. ~500, ~1000, ~3000???
> >
> > Well, I started monitoring my home router and plotting the NAPT44= port
> utilization on a minute-by-minute basis. You may find it here -
> http://= www.employees.org/~rajiva
> >
> > In short, port range of 500 seems ok, though 1000 would be more t= han
> enough for my home.
>
> I see several spikes in your data over 500 ports.  During those t= imes,
> applications would be unable to function (unable to get a port).  = ;April 29/30
> is a long time where that occurs very visibly, but there are shorter s= pikes
> elsewhere such as on April 17 and April 18.  If you had only 500 = ports on
> those days, creating a new TCP mapping would have been impossible,
> impacting ability to send or receive email, order books from Amazon.co= m,
> and so on.  I am surprised you conclude that "500 seems ok&q= uot; when such a
> limit would interfere with your network use on those days.
>
> What is the maximum number of mappings supported by your NAPT device?<= br> > Some residential-class NATs have a limit of 1024 mappings.
>
> -d
>
> > Suffice to say, this is just a sample representation, since the p= ort
> utilization would vary home to home, based on number of active devices= ,
> type of applications, the degree of simultaneous device or application=
> usage etc.
> >
> > If any of you are doing similar monitoring, then please share. > >
> > Cheers,
> > Rajiv
> >
> > PS: Thanks to Erik Kline, who explained (with sufficient details)= how to use
> google charting for my data. And thanks to Xun Wang & Shaoshuai Da= i for
> helping me out significantly.
> >
> > PS: My home has 3-4 active devices.
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave

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

 

--_000_7921F977B17D5B49B8DCC955A339D2F02AB410F8US70UWXCHMBA05z_-- From repenno@cisco.com Fri Jun 7 11:09:14 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF25C21F9600; Fri, 7 Jun 2013 11:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBGr+x+1mzqF; Fri, 7 Jun 2013 11:09:08 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF7321F8F6E; Fri, 7 Jun 2013 11:09:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20455; q=dns/txt; s=iport; t=1370628548; x=1371838148; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=ndEDmyQo9qlHKOw7hms0yEu0UUNZRTfZAnGj/jkBQ7I=; b=BXp/RoWewM3LprHPGBAp3OqnKesd1+R4XSRPtXbnf6+s9eOcINwhLSAq dq//fqCfNq1AdwIDywJA+nKfFtuvJl+QzMHqG3aJCQkuX88FMaeMaNzfj Fw9IHrARfILxpgnWDftXymyb6Sz3JlsT76FKV5+GvgJau6fDBXvaOSiD9 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFACAhslGtJV2b/2dsb2JhbABZDgiCL0Qwvm+BABZ0giMBAQEDAQEBASpBCwUHBgEIEQMBAQEBCh0uCxQJCAIEAQ0FCAGHfgYMvHKNdgEJAYEGIA0EBgEGgnVhA5Nuj3OFIYJRPoFoAQgXHw X-IronPort-AV: E=Sophos;i="4.87,823,1363132800"; d="scan'208,217";a="220192563" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 07 Jun 2013 18:09:07 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r57I97vW024157 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Jun 2013 18:09:07 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Fri, 7 Jun 2013 13:09:06 -0500 From: "Reinaldo Penno (repenno)" To: "Poscic, Kristian (Kristian)" , "John Mann" , "Rajiv Asati (rajiva)" Thread-Topic: [BEHAVE] [v6ops] Home NAPT44 - How many ports? Thread-Index: AQHOY5e6wCO8rb0sYUquZ4EU6EXcyJkqvn+A///wB4A= Date: Fri, 7 Jun 2013 18:09:06 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090A28CA@xmb-rcd-x04.cisco.com> In-Reply-To: <7921F977B17D5B49B8DCC955A339D2F02AB410F8@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.253.76] Content-Type: multipart/alternative; boundary="_000_45A697A8FFD7CF48BCF2BE7E106F0604090A28CAxmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: "Softwires-wg list \(softwires@ietf.org\)" , "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [Softwires] [BEHAVE] [v6ops] Home NAPT44 - How many ports? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 18:09:14 -0000 --_000_45A697A8FFD7CF48BCF2BE7E106F0604090A28CAxmbrcdx04ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable There are certain port allocation methods where extending the port block is= tricky, such as (Stateless) Deterministic NAT. From: "Poscic, Kristian (Kristian)" > Date: Fri, 7 Jun 2013 16:06:13 +0000 To: John Mann >, "Rajiv A= sati (rajiva)" > Cc: "Softwires-wg list (softwires@ietf.org)" >, "v6ops@ietf.org" >, "behave@ietf.org" >, "Dan Wing (dw= ing)" > Subject: Re: [BEHAVE] [v6ops] Home NAPT44 - How many ports? But why is this a problem in CGN? You initially allocate a port block of 500ports to the subscriber and then = they can dynamically extend this on as needed basis (allocate a new port bl= ock). To me the value of this exercise is to determine what will this initial por= t block size be, not at which point the service will be denied since this c= an be easily extended. For RGs, it is what it is, if they have the limit of 500mapping, then yes, = this is the problem. But for CGN it shouldn=92t be. From: behave-bounces@ietf.org [mailto:behav= e-bounces@ietf.org] On Behalf Of John Mann Sent: Thursday, June 06, 2013 5:02 PM To: Rajiv Asati (rajiva) Cc: Softwires-wg list (softwires@ietf.org); v6op= s@ietf.org; behave@ietf.org;= Dan Wing (dwing) Subject: Re: [BEHAVE] [v6ops] Home NAPT44 - How many ports? Hi, On 7 June 2013 08:41, Rajiv Asati (rajiva) > wrote: Hi Dan, > and so on. I am surprised you conclude that "500 seems ok" when such a > limit would interfere with your network use on those days. I based that statement ("...seems ok,") on the very fact that the number of= times the NAT utilization exceeded 500 mappings (equating to 500 ports, in= my setup) in the sample period (~2 months) was relatively quite low. So, i= f the NAT device was limited to only 500 mappings, then the experience woul= d have been ok for 99% of the time and degraded 1% of the time. This is an = important consideration, IMO. For ex, in the last 2 weeks, the number of times NAT mappings exceeded 500 = were: June 3 - 1 time May 29 - 1 time May 28 - 3 times May 26 - 1 time May 23 - 1 time May 22 - 2 times May 21 - 3 times I think a more-interesting statistic would be "how many connection setups w= ould have failed". But I don't think you can measure that just by polling concurrent connectio= ns at specific times. It might take e.g. netflow exporting and analysis ... However "number of concurrent connections that couldn't have been setup" wo= uld be useful in gauging the impact e.g. on May 29 there was one spike of 734 concurrent connections, then repo= rt that as 234 potential failures. Of course, 1000 ports (resulting in 1000+ mappings) would have been more th= an enough to accommodate the times when the mappings exceeded 500, but stay= ed within 1000 (except once). > What is the maximum number of mappings supported by your NAPT device? > Some residential-class NATs have a limit of 1024 mappings. Is that a combined limit of TCP and UDP and ICMP, or independent? My NAPT device seemingly can use upto 64K ports. :) Cheers, Rajiv > -----Original Message----- > From: Dan Wing (dwing) > Sent: Thursday, June 06, 2013 11:43 AM > To: Rajiv Asati (rajiva) > Cc: v6ops@ietf.org; Softwires-wg list (softwires@i= etf.org); > behave@ietf.org; Erik Kline (ek@google.com) > Subject: Re: [BEHAVE] Home NAPT44 - How many ports? > > > On Jun 5, 2013, at 6:14 AM, Rajiv Asati (rajiva) > wrote: > > > Some of you may recall our discussion (during the last IETF) around "ho= w > many TCP/UDP ports are enough with NAPT44" per home, as ISPs move into > A+P paradigm. ~500, ~1000, ~3000??? > > > > Well, I started monitoring my home router and plotting the NAPT44 port > utilization on a minute-by-minute basis. You may find it here - > http://www.employees.org/~rajiva > > > > In short, port range of 500 seems ok, though 1000 would be more than > enough for my home. > > I see several spikes in your data over 500 ports. During those times, > applications would be unable to function (unable to get a port). April 2= 9/30 > is a long time where that occurs very visibly, but there are shorter spik= es > elsewhere such as on April 17 and April 18. If you had only 500 ports on > those days, creating a new TCP mapping would have been impossible, > impacting ability to send or receive email, order books from Amazon.com, > and so on. I am surprised you conclude that "500 seems ok" when such a > limit would interfere with your network use on those days. > > What is the maximum number of mappings supported by your NAPT device? > Some residential-class NATs have a limit of 1024 mappings. > > -d > > > Suffice to say, this is just a sample representation, since the port > utilization would vary home to home, based on number of active devices, > type of applications, the degree of simultaneous device or application > usage etc. > > > > If any of you are doing similar monitoring, then please share. > > > > Cheers, > > Rajiv > > > > PS: Thanks to Erik Kline, who explained (with sufficient details) how t= o use > google charting for my data. And thanks to Xun Wang & Shaoshuai Dai for > helping me out significantly. > > > > PS: My home has 3-4 active devices. > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ Behave mailing list Behave@= ietf.org https://www.ietf.org/mailman/listinfo/beha= ve --_000_45A697A8FFD7CF48BCF2BE7E106F0604090A28CAxmbrcdx04ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
There are certain port allocation methods where extending the port blo= ck is tricky, such as (Stateless) Deterministic NAT.


From: "Poscic, Kristian (Krist= ian)" <kristi= an.poscic@alcatel-lucent.com>
Date: Fri, 7 Jun 2013 16:06:13 += ;0000
To: John Mann <john.mann@monash.edu>, "Rajiv Asati (raj= iva)" <rajiva@cisco.com>=
Cc: "Softwires-wg list (softwires@ietf.org)" <softwires@ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>, "behave@ietf.org" <behave@ietf.org>, "Dan Wing (dw= ing)" <dwing@cisco.com> Subject: Re: [BEHAVE] [v6ops] Home = NAPT44 - How many ports?

But why is this a problem in CGN?<= o:p>

You initially allocate a port bloc= k of 500ports to the subscriber and then they can dynamically extend this o= n as needed basis (allocate a new port block).

 

To me the value of this exercise i= s to determine what will this initial port block size be, not at which poin= t the service will be denied since this can be easily extended.

 

For RGs, it is what it is, if they= have the limit of 500mapping, then yes, this is the problem.

But for CGN it shouldn=92t be.

 

From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of John Mann
Sent: Thursday, June 06, 2013 5:02 PM
To: Rajiv Asati (rajiva)
Cc: Softwires-wg list (softwir= es@ietf.org); v6ops@ietf.org; behave@ietf.org; Dan Wing (dwing)
Subject: Re: [BEHAVE] [v6ops] Home NAPT44 - How many ports?

 

Hi,

 

On 7 June 2013 08:41, Rajiv Asati (rajiva) <rajiva@cisco.com> w= rote:

Hi Dan,


> and so on.  I am surprised you conclude that "500 seems ok&q= uot; when such a
> limit would interfere with your network use on those days.<= /p>

I based that statement ("...seems ok,") on= the very fact that the number of times the NAT utilization exceeded 500 ma= ppings (equating to 500 ports, in my setup) in the sample period (~2 months= ) was relatively quite low. So, if the NAT device was limited to only 500 mappings, then the experience would have been ok f= or 99% of the time and degraded 1% of the time. This is an important consid= eration, IMO.

For ex, in the last 2 weeks, the number of times NAT mappings exceeded 500 = were:

June 3 - 1 time
May 29 - 1 time
May 28 - 3 times
May 26 - 1 time
May 23 - 1 time
May 22 - 2 times
May 21 - 3 times

 

I think a more-interesting statistic would be "= how many connection setups would have failed".

But I don't think you can measure that just by polli= ng concurrent connections at specific times.

It might take e.g. netflow exporting and analysis ..= .

 

However "number of concurrent connections that = couldn't have been setup" would be useful in gauging the imp= act

e.g. on May 29 there was one spike of 734 concurrent= connections, then report that as 234 potential failures.

 

Of course, 1000 ports (resulting in 1000+ mappin= gs) would have been more than enough to accommodate the times when the mapp= ings exceeded 500, but stayed within 1000 (except once).



> What is the maximum number of mappings supported by your NAPT device?<= br> > Some residential-class NATs have a limit of 1024 mappings.<= /p>

 

Is that a combined limit of TCP and UDP and ICMP, or= independent?

 

My NAPT device seemingly can use upto 64K ports. :)<= br>
Cheers,
Rajiv



> -----Original Message-----
> From: Dan Wing (dwing)
> Sent: Thursday, June 06, 2013 11:43 AM
> To: Rajiv Asati (rajiva)

> Cc: v6ops@iet= f.org; Softwires-wg list (softwir= es@ietf.org);
> behave@ietf.org; Erik Kline (ek@google.com)
> Subject: Re: [BEHAVE] Home NAPT44 - How many ports?
>
>

> On Jun 5, 2013, at 6:14 AM, Rajiv Asati (rajiva= ) <rajiva@cisco.com> wrote: >
> > Some of you may recall our discussion (during the last IETF) arou= nd "how
> many TCP/UDP ports are enough with NAPT44" per home, as ISPs move= into
> A+P paradigm. ~500, ~1000, ~3000???
> >
> > Well, I started monitoring my home router and plotting the NAPT44= port
> utilization on a minute-by-minute basis. You may find it here -
> http://= www.employees.org/~rajiva
> >
> > In short, port range of 500 seems ok, though 1000 would be more t= han
> enough for my home.
>
> I see several spikes in your data over 500 ports.  During those t= imes,
> applications would be unable to function (unable to get a port).  = ;April 29/30
> is a long time where that occurs very visibly, but there are shorter s= pikes
> elsewhere such as on April 17 and April 18.  If you had only 500 = ports on
> those days, creating a new TCP mapping would have been impossible,
> impacting ability to send or receive email, order books from Amazon.co= m,
> and so on.  I am surprised you conclude that "500 seems ok&q= uot; when such a
> limit would interfere with your network use on those days.
>
> What is the maximum number of mappings supported by your NAPT device?<= br> > Some residential-class NATs have a limit of 1024 mappings.
>
> -d
>
> > Suffice to say, this is just a sample representation, since the p= ort
> utilization would vary home to home, based on number of active devices= ,
> type of applications, the degree of simultaneous device or application=
> usage etc.
> >
> > If any of you are doing similar monitoring, then please share. > >
> > Cheers,
> > Rajiv
> >
> > PS: Thanks to Erik Kline, who explained (with sufficient details)= how to use
> google charting for my data. And thanks to Xun Wang & Shaoshuai Da= i for
> helping me out significantly.
> >
> > PS: My home has 3-4 active devices.
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave

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

 

_______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave --_000_45A697A8FFD7CF48BCF2BE7E106F0604090A28CAxmbrcdx04ciscoc_-- From cx.cernet@gmail.com Fri Jun 7 22:25:29 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4EE21F9A20 for ; Fri, 7 Jun 2013 22:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9FslecbGH1V for ; Fri, 7 Jun 2013 22:25:29 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B522421F99FC for ; Fri, 7 Jun 2013 22:25:28 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hi5so1884925wib.6 for ; Fri, 07 Jun 2013 22:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vAEegSv/JWzgQmUXhbocBi+GT1zr6wGpgPC4FEe1a44=; b=X2NhIXDB6zOOjbKUdmEMGBk8vbWyfFlRUSptzCl50TKJEDmLtj3aO34Gw/BEnq32X7 vjOxcIUNOAlsKQ9OGvxam4vxlhS/3SYi99smswP7ctdJpfK9OsNSj+/Hius65G7SaN9i KNznAAr/vErUDWaojGBrhPnEqj6dAf9bE/YpO8zVQpn/0q13bFTrCP5Rw10VqhgRvdlz 5Hz4pF4LXieFiP7zTwKhY3eOwVdOqxUCuLSTAkSqrf0yT+4gOKa8hM9vxcElq8ESfg/N Yw/xV4Hx9auENrKWlS++hQNrlkQ0jjESS1a6rAvBO/qC/K22LUfiOnlwfN3mr7v/jQfh jWWw== MIME-Version: 1.0 X-Received: by 10.180.37.133 with SMTP id y5mr405587wij.20.1370669127540; Fri, 07 Jun 2013 22:25:27 -0700 (PDT) Received: by 10.216.212.202 with HTTP; Fri, 7 Jun 2013 22:25:27 -0700 (PDT) In-Reply-To: References: <3BA2AAEA-E6CA-4370-A66E-40F5437F47E3@employees.org> Date: Sat, 8 Jun 2013 13:25:27 +0800 Message-ID: From: Congxiao Bao To: "Rajiv Asati (rajiva)" Content-Type: multipart/alternative; boundary=e89a8f50335a73a53604de9dc669 Cc: Softwires-wg , Congxiao Bao Subject: Re: [Softwires] MAP-T DMR and IPv4 address mapping X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 05:25:29 -0000 --e89a8f50335a73a53604de9dc669 Content-Type: text/plain; charset=ISO-8859-1 I would like suggest: 1. Let /64 be the default for DMR; 2. Keep U-byte in the current MAP-T document, referred to RFC6052; 3. RFC 6052 should be updated aligning the outcome of 6man. Regards, Congxiao 2013/6/6 Rajiv Asati (rajiva) > It would be reasonable to state it as a recommendation (unless U-octet > gets changed by 6man*), since it is advantageous to be able to find the > encoded IPv4 address relatively easily during troubleshooting. > > * We wouldn't want to wait for that change to happen as a normative > reference. > > Cheers, > Rajiv > > > > -----Original Message----- > > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > > Behalf Of Ole Troan > > Sent: Thursday, June 06, 2013 9:28 AM > > To: Wojciech Dec > > Cc: Softwires-wg; Congxiao Bao > > Subject: Re: [Softwires] MAP-T DMR and IPv4 address mapping > > > > > would like to get your feedback regarding a possible change to the way > > IPv4 addresses are mapped into the MAP-T DMR prefix. The current text, > > http://tools.ietf.org/html/draft-ietf-softwire-map-t-01#section-5.4 , > follows > > RFC6052, and sees the IPv4 address inserted after the prefix. This aligns > > naturally with any/all existing NAT64 implementations, i.e. in a > non-shared- > > address domain, a MAP-T CE would work with any regular NAT64 BR. > > > A direct consequence of following RFC6052 is that, in cases where the > > prefix is shorter than /64, it results in some "bit spreading" of the > IPv4 > > address across the u-byte. See http://tools.ietf.org/html/rfc6052#page-5 > . > > This is likely to be cumbersome operationally. > > > > > > An option for simplifying this, and the change proposal seeking your > > feedback, would be to specify that the DMR should be a /64 prefix, or at > > least to make a recommendation to that effect in the specification. > > > > given that 6man is removing the special meaning of the U/G bits, perhaps > > RFC6052 should be updated, and MAP-T could ignore the U-byte? > > > > cheers, > > Ole > > > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --e89a8f50335a73a53604de9dc669 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I would like suggest:
1.=A0Let =A0/64 be the default for DMR= ;
2. Keep U-byte in the current MAP-T document, referred to RFC60= 52;
3. RFC 6052=A0should be updated aligning the outcome=A0 of 6m= an.
=A0
Regards,
Congxiao

2013/6/6 Rajiv Asati (rajiva) <rajiva@cisco.com><= br>
It would be reasonable to state it as a recommendation (unless U-octet gets= changed by 6man*), since it is advantageous to be able to find the encoded= IPv4 address relatively easily during troubleshooting.

* We wouldn't want to wait for that change to happen as a normative ref= erence.

Cheers,
Rajiv


> -----Original Message-----
> From: softwires-bounces@= ietf.org [mailto:softwire= s-bounces@ietf.org] On
> Behalf Of Ole Troan
> Sent: Thursday, June 06, 2013 9:28 AM
> To: Wojciech Dec
> Cc: Softwires-wg; Congxiao Bao
> Subject: Re: [Softwires] MAP-T DMR and IPv4 address mapping
>
> > would like to get your feedback regarding a possible change to th= e way
> IPv4 addresses are mapped into the MAP-T DMR prefix. The current text,=
> http://tools.ietf.org/html/draft-ietf-softwire-= map-t-01#section-5.4 , follows
> RFC6052, and sees the IPv4 address inserted after the prefix. This ali= gns
> naturally with any/all existing NAT64 implementations, i.e. in a non-s= hared-
> address domain, a MAP-T CE would work with any regular NAT64 BR.
> > A direct consequence of following RFC6052 is that, in cases where= the
> prefix is shorter than /64, it results in some "bit spreading&quo= t; of the IPv4
> address across the u-byte. See http://tools.ietf.org/html/rfc6052#page-5<= /a>.
> This is likely to be cumbersome operationally.
> >
> > An option for simplifying this, and the change proposal seeking y= our
> feedback, would be to specify that the DMR should be a /64 prefix, or = at
> least to make a recommendation to that effect in the specification. >
> given that 6man is removing the special meaning of the U/G bits, perha= ps
> RFC6052 should be updated, and MAP-T could ignore the U-byte?
>
> cheers,
> Ole
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--e89a8f50335a73a53604de9dc669-- From simon.perreault@viagenie.ca Mon Jun 10 06:23:25 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD87521F84B4 for ; Mon, 10 Jun 2013 06:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0rLWi2Fj8kJ for ; Mon, 10 Jun 2013 06:23:24 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A7B4721F90CC for ; Mon, 10 Jun 2013 06:23:06 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:975:db0c:5b8b:bf26]) by jazz.viagenie.ca (Postfix) with ESMTPSA id ECDD14044B for ; Mon, 10 Jun 2013 09:23:04 -0400 (EDT) Message-ID: <51B5D337.2000903@viagenie.ca> Date: Mon, 10 Jun 2013 15:23:03 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: softwires@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] MAP-T DMR and IPv4 address mapping X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 13:23:26 -0000 Le 2013-06-06 16:58, Senthil Sivakumar (ssenthil) a écrit : > I think that would be a great idea to update rfc 6052 to ignore the u > byte. It has been a pain to code, debug and maintain with bits spraying > across this artificial boundary. +1 Same experience here. Simon From Tina.Tsou.Zouting@huawei.com Sun Jun 16 20:52:36 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B6721F9AFF for ; Sun, 16 Jun 2013 20:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1kSqzcpkUNK for ; Sun, 16 Jun 2013 20:52:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 320BD21F9E04 for ; Sun, 16 Jun 2013 20:52:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATZ04837; Mon, 17 Jun 2013 03:52:26 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 17 Jun 2013 04:51:59 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 17 Jun 2013 04:52:24 +0100 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.217]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.007; Sun, 16 Jun 2013 20:52:20 -0700 From: Tina TSOU To: "softwires@ietf.org" Thread-Topic: New Version Notification for draft-tsou-softwire-bfd-ds-lite-05.txt Thread-Index: AQHOawFJ1jG3T4u4okuux0rhuTLvn5k5Q9cg Date: Mon, 17 Jun 2013 03:52:18 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.57] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Softwires] FW: New Version Notification for draft-tsou-softwire-bfd-ds-lite-05.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 03:52:36 -0000 RGVhciBhbGwsDQpUaGlzIG5ldyB2ZXJzaW9uIHRyaWVzIHRvIGFkZHJlc3MgcmV2aWV3ZXJzJyBj b21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYWZ0ZXIgSUVURiBPcmxhbmRvIG1lZXRpbmcuDQpodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC10c291LXNvZnR3aXJlLWJmZC1k cy1saXRlLTA1LnR4dA0KVGhhbmtzIGZvciBhbGwgdGhlIHJldmlld2VycycgZXh0ZW5zaXZlIHJl dmlld3MuDQoNCklmIHRoZSBjb21tZW50cyBhcmUgY29uc2lkZXJlZCBzb2x2ZWQsIHdlIHdvdWxk IGxpa2UgdG8gYXNrIHRoZSBjaGFpcnMsIGlzIGl0IHJlYWR5IHRvIGFzayBmb3IgYWRvcHRpb24g ZnJvbSB5b3VyIHBvaW50IG9mIHZpZXc/DQpUaGFuayB5b3UgZm9yIHlvdXIgY29uc2lkZXJhdGlv bi4NCg0KVGhhbmsgeW91LA0KVGluYQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZ10NCj4gU2VudDogMjAxM+W5tDbmnIgxNuaXpSAxOToyMA0KPiBUbzogWmhvdXFpYW4g KENhdGh5KTsgUmVpbmFsZG8gUGVubm87IE1vaGFtZWQgQm91Y2FkYWlyOyBUaW5hIFRTT1U7IExp amlhbg0KPiAoQnJhbmRvbiwgRkJCKTsgSnVlcmdlbiBTY2hvZW53YWVsZGVyDQo+IFN1YmplY3Q6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdHNvdS1zb2Z0d2lyZS1iZmQtZHMt bGl0ZS0NCj4gMDUudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXRz b3Utc29mdHdpcmUtYmZkLWRzLWxpdGUtMDUudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgVGluYSBUc291IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYNCj4gcmVwb3NpdG9y eS4NCj4gDQo+IEZpbGVuYW1lOgkgZHJhZnQtdHNvdS1zb2Z0d2lyZS1iZmQtZHMtbGl0ZQ0KPiBS ZXZpc2lvbjoJIDA1DQo+IFRpdGxlOgkJIERTLUxpdGUgRmFpbHVyZSBEZXRlY3Rpb24gYW5kIEZh aWxvdmVyDQo+IENyZWF0aW9uIGRhdGU6CSAyMDEzLTA2LTE3DQo+IEdyb3VwOgkJIEluZGl2aWR1 YWwgU3VibWlzc2lvbg0KPiBOdW1iZXIgb2YgcGFnZXM6IDExDQo+IFVSTDogICAgICAgICAgICAg aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdHNvdS1zb2Z0d2lyZS0N Cj4gYmZkLWRzLWxpdGUtMDUudHh0DQo+IFN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC10c291LXNvZnR3aXJlLWJmZC0NCj4gZHMtbGl0ZQ0KPiBI dG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRzb3Utc29m dHdpcmUtYmZkLWRzLQ0KPiBsaXRlLTA1DQo+IERpZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtdHNvdS1zb2Z0d2lyZS1iZmQtDQo+IGRzLWxpdGUt MDUNCj4gDQo+IEFic3RyYWN0Og0KPiAgICBJbiBEUy1MaXRlLCB0aGUgdHVubmVsIGlzIHN0YXRl bGVzcywgbm90IGFzc29jaWF0ZWQgd2l0aCBhbnkgc3RhdGUNCj4gICAgaW5mb3JtYXRpb24sIGFu ZCB0aGUgQ0dOIGZ1bmN0aW9uIGF0IHRoZSBBRlRSIGlzIHN0YXRlZnVsLg0KPiAgICBDdXJyZW50 bHksIHRoZXJlIGlzIG5vIGZhaWx1cmUgZGV0ZWN0aW9uIGFuZCBmYWlsb3ZlciBtZWNoYW5pc20g Zm9yDQo+ICAgIGJvdGggc3RhdGVsZXNzIHR1bm5lbCBhbmQgc3RhdGVmdWwgQ0dOIGZ1bmN0aW9u LCB3aGljaCBtYWtlcyBpdA0KPiAgICBkaWZmaWN1bHQgdG8gbWFuYWdlIGFuZCBkaWFnbm9zZSBp ZiB0aGVyZSBpcyBhIHByb2JsZW0uICBUaGlzIGRyYWZ0DQo+ICAgIGFuYWx5emVzIHRoZSBhcHBs aWNhYmlsaXR5IG9mIHNvbWUgb2YgdGhlIHBvc3NpYmxlIHNvbHV0aW9ucy4NCj4gDQo+IA0KPiAN Cj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From swmike@swm.pp.se Sun Jun 16 22:28:55 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B5021F99D0; Sun, 16 Jun 2013 22:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.555 X-Spam-Level: X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[AWL=1.044, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVNCx2fq6BTI; Sun, 16 Jun 2013 22:28:54 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 501AD21F89EB; Sun, 16 Jun 2013 22:28:54 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9E0F99C; Mon, 17 Jun 2013 07:28:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 95E779A; Mon, 17 Jun 2013 07:28:53 +0200 (CEST) Date: Mon, 17 Jun 2013 07:28:53 +0200 (CEST) From: Mikael Abrahamsson To: "Softwires-wg list (softwires@ietf.org)" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [Softwires] [v6ops] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 05:28:55 -0000 On Thu, 6 Jun 2013, Dan Wing wrote: > What is the maximum number of mappings supported by your NAPT device? > Some residential-class NATs have a limit of 1024 mappings. I read some RFQ answers for residential gateways lately and at least the devices there seemed to support around 2048-4096 mapping. Other numbers I've heard kicked around is for larger populations of fixed line customers (CGN for ADSL and similar tech), one needs to support around 30 connections per customer on average. This goes down a bit when it's a single mobile device (without tethering), then it's more like 4-6 TCP connections needed on average. If I was going to support a student dorm I'm pretty sure the above values would be a lot higher though, especially compared to a retirement home Wifi :) -- Mikael Abrahamsson email: swmike@swm.pp.se From prvs=58817db325=suresh.krishnan@ericsson.com Tue Jun 18 12:43:44 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E2711E80FA for ; Tue, 18 Jun 2013 12:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DEt2BhoGEP7 for ; Tue, 18 Jun 2013 12:43:37 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id ACAB211E80F8 for ; Tue, 18 Jun 2013 12:43:37 -0700 (PDT) X-AuditID: c618062d-b7f936d000004481-cb-51c0b868dd93 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 94.5B.17537.868B0C15; Tue, 18 Jun 2013 21:43:37 +0200 (CEST) Received: from eusaamw0712.eamcs.ericsson.se (147.117.20.181) by EUSAAHC006.ericsson.se (147.117.188.90) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 18 Jun 2013 15:43:36 -0400 Received: from [164.48.125.25] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 18 Jun 2013 15:43:34 -0400 Message-ID: <51C0B7BA.9050304@ericsson.com> Date: Tue, 18 Jun 2013 15:40:42 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: Softwires WG X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphluLIzCtJLcpLzFFi42KZXLonSjdzx4FAg4V72S1+bEm2OLxsK5MD k8eSJT+ZPI5/fsscwBTFbZOUWFIWnJmep2+XwJ3RuHoBS8FlxoqNs7eyNzCuYuxi5OSQEDCR +L/9NiuELSZx4d56ti5GLg4hgaOMEn/X3YJy9jBK/DzTwA7hbGWUmHVjAQtIC6+AtsS9vwuY QWwWAVWJPS2rwGw2oLEbdn5mArFFBcIkPixbwgRRLyhxcuYTsF4RoPonOx+wgdjMAmoSM5// BKsRFrCV+P//A9RJkhJbXrSzQ9ToSUy52sIIYctLbH87B2yXkICmxNY131knMArOQrJiFpKW WUhaFjAyr2LkKC1OLctNNzLYxAgMzGMSbLo7GPe8tDzEKM3BoiTO+/LUrkAhgfTEktTs1NSC 1KL4otKc1OJDjEwcnCCCS6qBsZRPu5dlzqWsBf3p6kx+G+KrY0qtu+YV76uaIPzugeDhI/Pn lDD5uyvMmH903V99/+M7G1ZlRSoqrl+k1hnKk7KLJTxuVcburQvrQzIu9UasCH8dMkUwWyz0 d/afmu7lf2um/PHZrBn1xyFaSHmXW7+J6ae9WeW5K+QnzHSb/Db3SrUky4d3SizFGYmGWsxF xYkAUWRmDR8CAAA= Cc: Yong Cui Subject: [Softwires] Adoption of draft-fu-softwire-map-mib-05 as wg draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 19:43:44 -0000 Hi all, The adoption call on the mailing list has demonstrated consensus to adopt this draft as a wg draft. Authors, please resubmit this draft as draft-ietf-softwire-map-mib-00. Regards Suresh & Yong From prvs=7881352dae=suresh.krishnan@ericsson.com Tue Jun 18 12:45:26 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F3611E80FE for ; Tue, 18 Jun 2013 12:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIwnggnekYHV for ; Tue, 18 Jun 2013 12:45:20 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0F411E80F8 for ; Tue, 18 Jun 2013 12:45:20 -0700 (PDT) X-AuditID: c6180641-b7f0e6d0000015f1-0a-51c0b8cf6df8 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id DD.27.05617.FC8B0C15; Tue, 18 Jun 2013 21:45:19 +0200 (CEST) Received: from eusaamw0711.eamcs.ericsson.se (147.117.20.178) by EUSAAHC003.ericsson.se (147.117.188.81) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 18 Jun 2013 15:45:18 -0400 Received: from [164.48.125.25] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 18 Jun 2013 15:45:17 -0400 Message-ID: <51C0B82D.3070703@ericsson.com> Date: Tue, 18 Jun 2013 15:42:37 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: Softwires WG X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgluLIzCtJLcpLzFFi42KZXLonUPf8jgOBBhfmyVn82JJscXjZViYH Jo8lS34yeRz//JY5gCmK2yYpsaQsODM9T98ugTtjYvsBtoJrjBVrdgo1MK5l7GLk5JAQMJHY PGsKK4QtJnHh3no2EFtI4CijxNmvFhD2HkaJ9Q/zuhi5gOytjBJPv31mB0nwCmhLvOz/AtTM wcEioCqxrEEBJMwGNHPDzs9MILaoQJjEh2VLmCDKBSVOznzCAmKLAJU/2fkAbBezgJrEzOc/ wWqEBVwk5v3qYIK4R1Jiy4t2dogaPYkpV1sYIWx5ie1v5zBD3KYpsXXNd9YJjIKzkKyYhaRl FpKWBYzMqxg5SotTy3LTjQw3MQID8pgEm+MOxgWfLA8xSnOwKInzvj+1K1BIID2xJDU7NbUg tSi+qDQntfgQIxMHJ4jgkmpgVHNY4Xr9WmTvxhU8m70Sff2s9e2uuL/duaF2G3dR8a3ZXfuU Fe5o6FkX/c9wU/JfNZHhWTfz5TMbPl2u/L2s7PP3z7HhM3+5T3Fb0vTuq5P3huMz3s5l9Z1r +ovvwynWs5se3Wo/8jHMdfmcc+5mSW3+Wct/ztvDdV/RwPTQ8WtNCTcn7vY5uU+JpTgj0VCL uag4EQAGbYuKGwIAAA== Cc: Yong Cui Subject: [Softwires] Adoption of draft-jiang-softwire-map-radius-04 as wg draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 19:45:26 -0000 Hi all, The adoption call on the mailing list has demonstrated consensus to adopt this draft as a wg draft. Authors, please resubmit this draft as draft-ietf-softwire-map-radius-00. Regards Suresh & Yong From internet-drafts@ietf.org Wed Jun 26 01:45:44 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E5011E80D5; Wed, 26 Jun 2013 01:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.23 X-Spam-Level: X-Spam-Status: No, score=-102.23 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5dloBi3L+Wp; Wed, 26 Jun 2013 01:45:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B01FD21E8108; Wed, 26 Jun 2013 01:45:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130626084542.2664.38678.idtracker@ietfa.amsl.com> Date: Wed, 26 Jun 2013 01:45:42 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-map-mib-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 08:45:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : Definitions of Managed Objects for MAP-E Author(s) : Yu Fu Sheng Jiang Bing Liu Jiang Dong Yuchi Chen Filename : draft-ietf-softwire-map-mib-00.txt Pages : 14 Date : 2013-06-26 Abstract: This memo defines a portion of the Management Information Base (MIB) for using with network management protocols in the Internet community. In particular, it defines managed objects for MAP encapsulation mode. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-map-mib-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Jun 26 09:46:47 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0677821E8063; Wed, 26 Jun 2013 09:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-NclrXUwmfz; Wed, 26 Jun 2013 09:46:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9245B21F9942; Wed, 26 Jun 2013 09:46:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130626164646.9086.40265.idtracker@ietfa.amsl.com> Date: Wed, 26 Jun 2013 09:46:46 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-map-radius-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 16:46:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : RADIUS Attribute for MAP Author(s) : Sheng Jiang Yu Fu Bing Liu Peter Deacon Filename : draft-ietf-softwire-map-radius-00.txt Pages : 14 Date : 2013-06-26 Abstract: Mapping of Address and Port (MAP) is a stateless mechanism for running IPv4 over IPv6-only infrastructure. It provides both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co- existing period. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) MAP options has been defined to configure MAP Customer Edge (CE). However, in many networks, the configuration information may be stored in Authentication Authorization and Accounting (AAA) servers while user configuration is mainly from Broadband Network Gateway (BNG) through DHCPv6 protocol. This document defines a Remote Authentication Dial In User Service (RADIUS) attribute that carries MAP configuration information from AAA server to BNG. The MAP RADIUS attribute are designed following the simplify principle. It provides just enough information to form the correspondent DHCPv6 MAP option. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map-radius There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-map-radius-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/