From mohamed.boucadair@orange.com Thu Oct 4 00:16:50 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D2A21F8624 for ; Thu, 4 Oct 2012 00:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XX3RrcsSVsep for ; Thu, 4 Oct 2012 00:16:49 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2C46B21F8621 for <6man@ietf.org>; Thu, 4 Oct 2012 00:16:46 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 36B39264464 for <6man@ietf.org>; Thu, 4 Oct 2012 09:16:44 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 1A25C23805E for <6man@ietf.org>; Thu, 4 Oct 2012 09:16:44 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Thu, 4 Oct 2012 09:16:43 +0200 From: To: "6man@ietf.org" <6man@ietf.org> Date: Thu, 4 Oct 2012 09:16:42 +0200 Subject: draft-boucadair-6man-sip-proxy-01 Thread-Topic: draft-boucadair-6man-sip-proxy-01 Thread-Index: Ac2h/6EbYM9BLp86T/u2M2fMfoCfDgAAG6vQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E5F75BA9B@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 X-Mailman-Approved-At: Thu, 04 Oct 2012 00:19:28 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 07:16:50 -0000 Dear all, Comments are more than welcome. Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] D= e la part de internet-drafts@ietf.org Envoy=E9 : jeudi 4 octobre 2012 09:12 =C0 : i-d-announce@ietf.org Objet : I-D Action: draft-boucadair-6man-sip-proxy-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : IPv6 RA Option for SIP Proxy Server Author(s) : Mohamed Boucadair David Binet Filename : draft-boucadair-6man-sip-proxy-01.txt Pages : 6 Date : 2012-10-04 Abstract: This document specifies a new optional extension to IPv6 Router Advertisement messages to advertise SIP Proxy Server (e.g., P-CSCF) addresses to IPv6 hosts. The provisioning of the SIP Proxy Server address is crucial for the delivery of SIP-based services. Means to ensure reliable delivery of this information to connecting SIP User Agents is a must. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boucadair-6man-sip-proxy There's also a htmlized version available at: http://tools.ietf.org/html/draft-boucadair-6man-sip-proxy-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-6man-sip-proxy-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From mohamed.boucadair@orange.com Thu Oct 4 00:20:24 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 462831F0C93 for ; Thu, 4 Oct 2012 00:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTrS0RaXKTpp for ; Thu, 4 Oct 2012 00:20:24 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id BA8C41F0C92 for ; Thu, 4 Oct 2012 00:20:23 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id AEAD018C51C for ; Thu, 4 Oct 2012 09:20:22 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 5379923806B for ; Thu, 4 Oct 2012 09:20:22 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Thu, 4 Oct 2012 09:20:21 +0200 From: To: "ipv6@ietf.org" Date: Thu, 4 Oct 2012 09:20:20 +0200 Subject: draft-boucadair-6man-sip-proxy-01 Thread-Topic: draft-boucadair-6man-sip-proxy-01 Thread-Index: Ac2h/6EbYM9BLp86T/u2M2fMfoCfDgAAPdvQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E5F75BA9F@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 07:20:24 -0000 Dear all, Comments are more than welcome. Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] D= e la part de internet-drafts@ietf.org Envoy=E9 : jeudi 4 octobre 2012 09:12 =C0 : i-d-announce@ietf.org Objet : I-D Action: draft-boucadair-6man-sip-proxy-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : IPv6 RA Option for SIP Proxy Server Author(s) : Mohamed Boucadair David Binet Filename : draft-boucadair-6man-sip-proxy-01.txt Pages : 6 Date : 2012-10-04 Abstract: This document specifies a new optional extension to IPv6 Router Advertisement messages to advertise SIP Proxy Server (e.g., P-CSCF) addresses to IPv6 hosts. The provisioning of the SIP Proxy Server address is crucial for the delivery of SIP-based services. Means to ensure reliable delivery of this information to connecting SIP User Agents is a must. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boucadair-6man-sip-proxy There's also a htmlized version available at: http://tools.ietf.org/html/draft-boucadair-6man-sip-proxy-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-6man-sip-proxy-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From otroan@employees.org Thu Oct 4 11:19:30 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A0421F8661 for ; Thu, 4 Oct 2012 11:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[AWL=-1.123, BAYES_00=-2.599, LOCALPART_IN_SUBJECT=2.02, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLqBIM7sII+d for ; Thu, 4 Oct 2012 11:19:30 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 528EC21F8624 for ; Thu, 4 Oct 2012 11:19:30 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 6045D5E70; Thu, 4 Oct 2012 11:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=selector1; bh=mpO5m3AevRyDOZCiYV3AM HYInGw=; b=ai70F4eiFo86SmLvnR0JpsJ4a+Cx7iE2S8II00Qug6rryIqZydCuh B3oHg8vqnkgdyWo66sYa4kgCacTt8FrnnpDEn1Ow9iOIbcHrr0GxQAD5wc/OFq26 v+uyGv1r2cZSRpZ2MhTpKL4EhlEkbdGfB85MlgWryklKdA+pX5FHJs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; q=dns; s=selector1; b=hyQp06lKmhKJKBr bdsmbQFrD8oWtlXNUqckpQb30mfv8TK39egRqk+2gb3ySoZm1Ftv/FLGzyljjCn1 g2sdMtAqdYSZuv3URxexZmTQswL5QREHx5sGZCP4jm0mDBsbG6GdfSG3O5IJxI7v seUNrEbD2vfXnDktlT+AhZQQxvBw= Received: from ams3-vpn-dhcp7380.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 904425E6E; Thu, 4 Oct 2012 11:19:28 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_43E1BEC5-D3B3-4539-B08D-5757DAD8DC0D"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) Subject: Re: Adopting draft-krishnan-6man-resilient-rs From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Thu, 4 Oct 2012 20:19:26 +0200 Message-Id: References: <1DD43EE0-A900-42A6-94FE-563542953210@employees.org> To: draft-krishnan-6man-resilient-rs@tools.ietf.org X-Mailer: Apple Mail (2.1498) Cc: "ipv6@ietf.org 6man" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 18:19:31 -0000 --Apple-Mail=_43E1BEC5-D3B3-4539-B08D-5757DAD8DC0D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 all, this is to confirm the adoption of the draft-krishnan-6man-resilient-rs = as a working group document. can the authors please resubmit the draft as = draft-ietf-6man-resilient-rs. Best regards, Ole & Bob >>=20 >>=20 >> All, >>=20 >> There was consensus in the room for adopting this document in = Vancouver. >> This starts a 1-week call to confirm that consensus on the mailing = list >>=20 >> Title : Packet loss resiliency for Router Solicitations >> Author(s) : S. Krishnan, D. Anipko, D. Thaler >> Filename : draft-krishnan-6man-resilient-rs-01 >> Pages : 5 >> Date : 2012-07-16 >>=20 >> as a 6MAN WG document. Please state your opinion if you object to >> on making this draft a WG draft either on the mailing list or >> to the chairs. This call will end 2012-09-18. >>=20 >> Best regards, >> Bob & Ole >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- --Apple-Mail=_43E1BEC5-D3B3-4539-B08D-5757DAD8DC0D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIxMDA0MTgxOTI2WjAjBgkqhkiG9w0BCQQxFgQUqZWlBMtS8PZmbl0I lj0v27sHc+owggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEAbv7HKSzxmvGP4y8T7evL +ZeV7oK/nWCauuU+NOp5+HL5QBDskkqlMtykU2WFZY98zkVb5iCkonBNwVi21eVMLmaW4SvMHaOO FQ6IWmS8xjJpIXqOiZ3w9X+DEXbNXpeEBrB/KgwtNq1liOMcQY1oZtOriKuNLz0a4C7xUBcAuj8X nHsGSheZZJIHjsT2bLCBKKjO7X5vYzMz7MO5or6YDot4m4aSENptQUdS9Hke4ELYVLG9/eE9lksb 2y7zUBEUNXdX2/79Ht4NAWNR+DCiy/b/5aIc33MxHICZjAEWxwNaUo5RQ6SP1ancLtZ0hAuYjwO9 iSiwJ8Sq81fmpDxbUgAAAAAAAA== --Apple-Mail=_43E1BEC5-D3B3-4539-B08D-5757DAD8DC0D-- From barryleiba@computer.org Thu Oct 4 11:33:15 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5741F0C9F; Thu, 4 Oct 2012 11:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61WoyuolhGRo; Thu, 4 Oct 2012 11:33:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442D31F0C98; Thu, 4 Oct 2012 11:33:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Barry Leiba" To: The IESG Subject: Barry Leiba's Discuss on draft-ietf-6man-udpchecksums-04: (with DISCUSS) X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121004183314.13770.19480.idtracker@ietfa.amsl.com> Date: Thu, 04 Oct 2012 11:33:14 -0700 Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-udpchecksums@tools.ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 18:33:16 -0000 Barry Leiba has entered the following ballot position for draft-ietf-6man-udpchecksums-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is a combined DISCUSS on udpchecksums and udpzero. First, let me say that I have no actual objection to publishing either of these documents. What I'm concerned about is whether we're saying what we want to stay as a "standard", so let's discuss that: The issue comes when I look at udpzero Section 5.1 and udpchecksums section 5. The numbered list in the latter is essentially a word-for-word copy of the numbered list in the former, with the "must"s and "may"s and "should not"s changed to upper case. It always bothers me when a significant amount of important text is duplicated like that, but the real problem comes when I look at what this *says*. Because udpzero is informational, when it says, "If a zero checksum approach were to be adopted by the IETF, the specification should consider adding the following constraints on usage," that makes no normative requirement on any future protocol that runs on UDP and decides to bypass the UDP checksums. Now, of course, we also have a document, udpchecksums, which defines what to do if you do tunneling on UDP and you want to skip the outer checksums (because you have inner ones). *That* document makes this list normative. But what happens if, later, someone decides to document how to do, let's say, media streaming over UDP with zero checksums. The analysis in udpzero applies, of course, but the new document is under no obligation to consider it or any of those usage restrictions in Section 5.1. (It might be that such a document could never get past the current community and ADs, but I'm not sure we want to leave that to chance.) So the question comes to what we want to say normatively. Which is it that we want a standard saying? 1. If you tunnel packets over UDP and want to avoid the UDP checksums, you need to use this list of restrictions. But other applications over UDP that want to avoid the UDP checksums can make entirely different decisions. or 2. If you do *anything* over UDP and want to avoid the UDP checksums, you need to use this list of restrictions. And here's how tunneling over UDP works. I think (2) is right, but the way the documents are structured now says (1). Discussion, please.... From bob.hinden@gmail.com Thu Oct 4 13:24:34 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F24F21F8777 for ; Thu, 4 Oct 2012 13:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.607 X-Spam-Level: X-Spam-Status: No, score=-103.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8FQGvPmF5Jc for ; Thu, 4 Oct 2012 13:24:33 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD6A21F8747 for ; Thu, 4 Oct 2012 13:24:33 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so904199pad.31 for ; Thu, 04 Oct 2012 13:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=+GzyyV9UkwaG1MNGgd462DhpWmIPFuGoXDUuFtrcqno=; b=lBZC+2krbJ2gvjMfzUyb8u5GmYfxFMR4GavlwBHufqs+4c5eLwYTckDfP+m/VdFHuv JV8rQkxXER6K1x5t2Z7TSeAgViJIqXko5cV/Z5HanCSoJJRV8ZsAtmnZT2ArLpm/SQAy 26p0Jsbw3hZXhY/XQxTDxnfkTRfpTwW3ypwGrIWfUbLlv2OS1KXTg6amDJDA00/pwlCe /1O/+lOhdy7LPoBH5UZBpUICBPNRNGqIOc0sEf/tai13orQRqYZhJUKly4Cw8LUir2G3 LG77l9nwgUMY5qcwWYArltDOQPl4/Xpu4LCWHvb8QIGbzPx/qUHzi61l6XwwdCbsIRz8 uOPA== Received: by 10.66.83.129 with SMTP id q1mr16183238pay.4.1349382270979; Thu, 04 Oct 2012 13:24:30 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by mx.google.com with ESMTPS id ho7sm4833298pbc.3.2012.10.04.13.24.29 (version=SSLv3 cipher=OTHER); Thu, 04 Oct 2012 13:24:30 -0700 (PDT) From: Bob Hinden Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 6man IETF85 Call for agenda items Date: Thu, 4 Oct 2012 13:24:29 -0700 Message-Id: To: "ipv6@ietf.org Mailing List" Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 20:24:34 -0000 6MAN has a 2 1/2 hour slot allocated for Atlanta: 6man Session 1 (2:30:00) 5 November 2012 Monday, Morning Session I 0900-1130 Room Name: Salon D [Note the date and time might change] If you have a draft you would like to discuss, please send your request = for agenda time to the 6man chairs. Please include in the request, the = title and file name of the draft, the speakers name (and email), and how = much time you need. We will prioritise drafts that are working group items, drafts that have = been actively discussed on the list, and other individual submissions in = that order. Please have agenda items to us by 15 October 2012 and also note the = following deadlines for IETF85: 2012-10-15 (Monday): Internet Draft Cut-off for initial document (-00) = submission by UTC 24:00 2012-10-22 (Monday): Internet Draft final submission cut-off by UTC = 24:00 Regards, Bob & Ole From turners@ieca.com Thu Oct 4 14:28:04 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DCF21F8718; Thu, 4 Oct 2012 14:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJpzkHGCwE11; Thu, 4 Oct 2012 14:28:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0ECC21F8716; Thu, 4 Oct 2012 14:28:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Sean Turner" To: The IESG Subject: Sean Turner's Discuss on draft-ietf-6man-dad-proxy-05: (with DISCUSS and COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121004212803.5599.40499.idtracker@ietfa.amsl.com> Date: Thu, 04 Oct 2012 14:28:03 -0700 Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-dad-proxy@tools.ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 21:28:04 -0000 Sean Turner has entered the following ballot position for draft-ietf-6man-dad-proxy-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- s6.1, para 1: When won't using SEND without a proxy break the security? = I think what you're trying to say is that using plain old SEND won't work you've got to use SEND with the proxy - right? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) Is the word "proxy" missing from the following in the abstract: The document describes a mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-multipoint architecture with "split-horizon" forwarding scheme. = s1 use "proxy" after DAD and then s1 para 2 says: This document explains also why DAD mechanism [RFC4862] cannot be used in a point-to-multipoint architecture with "split-horizon" forwarding scheme (IPv6 over PPP [RFC5072] is not affected). And could we make it clear that a proxy is needed: This document explains also why DAD mechanism [RFC4862] without a proxy cannot be used in a point-to-multipoint architecture with "split-horizon" forwarding scheme (IPv6 over PPP [RFC5072] is not affected). 2) s4.2: Some minor wording tweaks because I don't know what the MUST pertains to: OLD: perform actions depending on the information in the Binding Table. NEW: perform actions specified in the following sections based on the information in the Binding Table. 3) s4.2.1/s4.2.2: What happens if the BNG does reply/forward? 4) s4.1/s4.2.2: Is the neighborhood cache in s4.2.2 the same thing as the binding table in s4.1? 5) s4.2.3.2: L2 header: Which link-layer address is returned to CPE2? Is it it's own or the one from CPE1? 6) s6.1: Agree with Barry's SHOULD vs MUST discuss. 7) s6.2: r/To ensure a protection/To ensure protection = 8) s6.2: not sure you really need the MAY. Maybe r/MAY/can From barryleiba@gmail.com Thu Oct 4 14:38:18 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF74921F8594; Thu, 4 Oct 2012 14:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.06 X-Spam-Level: X-Spam-Status: No, score=-103.06 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yncph9eKZqtQ; Thu, 4 Oct 2012 14:38:18 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEB121F850C; Thu, 4 Oct 2012 14:38:18 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so1358095vcb.31 for ; Thu, 04 Oct 2012 14:38:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=LrExusDIB2IUXImdU/Iu22t5oKBjl7P+rgXDZaDoHwc=; b=YH8CGJiEedhfDkOnf+gdR0u1ENppQGA7ioSPvD/Cm5+fWg4aLk0J5Jc7Wy6YwZtbpw +SNr+g6rxr8azxt2V7bPCeP7YKhTY7LQaN3UhTLcnZpzwKh/aleZzHsUwIzwqwuqY7D7 W4V33+CqrLz3UUu1LFXIEelZqJMeQw6EAQYVe75du4Zh7fIrhNm9m2if0T7+a+8z5Rzc GsqHQemYMsM9CE+cA1qcQKBYUEjZtWZlmwNWaQsHR8bZUvC0G65Bu3fMyZUmqCAF7x1h qrC48/Fsg88/KMOR2rz6FL2AoWHlAxY8ztiB5O3BnPwXNhNxRiRlNRWSysihV1z7uJg2 ft7Q== MIME-Version: 1.0 Received: by 10.58.209.73 with SMTP id mk9mr4194481vec.25.1349386694972; Thu, 04 Oct 2012 14:38:14 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.59.5.72 with HTTP; Thu, 4 Oct 2012 14:38:14 -0700 (PDT) In-Reply-To: <20121004212803.5599.40499.idtracker@ietfa.amsl.com> References: <20121004212803.5599.40499.idtracker@ietfa.amsl.com> Date: Thu, 4 Oct 2012 17:38:14 -0400 X-Google-Sender-Auth: KY4JH-iYwOyW53qSrb3aLk59oSI Message-ID: Subject: Re: Sean Turner's Discuss on draft-ietf-6man-dad-proxy-05: (with DISCUSS and COMMENT) From: Barry Leiba To: Sean Turner Content-Type: text/plain; charset=ISO-8859-1 Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-dad-proxy@tools.ietf.org, ipv6@ietf.org, The IESG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 21:38:18 -0000 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > s6.1, para 1: When won't using SEND without a proxy break the security? > I think what you're trying to say is that using plain old SEND won't work > you've got to use SEND with the proxy - right? Yeh, same DISCUSS as mine. Barry From bob.hinden@gmail.com Thu Oct 4 14:53:13 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D4121F8528 for ; Thu, 4 Oct 2012 14:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.607 X-Spam-Level: X-Spam-Status: No, score=-103.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1buRaO943ZLT for ; Thu, 4 Oct 2012 14:53:12 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id A939E21F8613 for ; Thu, 4 Oct 2012 14:53:10 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so968694pad.31 for ; Thu, 04 Oct 2012 14:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=tvKl1PFeZC3RyOkzAWQsqnH7SptNjdrEBwRCBLemp7I=; b=AxGH1bc21utG6z48BT9leAURIFmdl/NjQfH4dw1FCWUMt48tqYuAgNS5cv8hBvHHTl R0b38OPif4/Hv0lDcgubFLxUrJSsGP4aCdGWCrc/6WZSqrCCNpsEz3nTlj8eFLR4OQJE GPKqxjeFtG2laTmc/ExT3fI1IhHXlGU9q4AsYx2KUbgxOlY0KombPdMub1cdR1GZO/qu oJ2X3IUSkcCELDBo2vkeWu8xBjm7+dYoilHhOAnYLX0Tum86vTuSjcUXO2NQDYUd14gr iO9AuyZ9/vO4I6b67GwujR+OFWbWiL0QoSxCNU4kKCPkkNnBkYEKOXEc6RIA11Dla6xa bW2Q== Received: by 10.66.83.8 with SMTP id m8mr16454330pay.48.1349387590451; Thu, 04 Oct 2012 14:53:10 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by mx.google.com with ESMTPS id ka4sm4913013pbc.61.2012.10.04.14.53.09 (version=SSLv3 cipher=OTHER); Thu, 04 Oct 2012 14:53:09 -0700 (PDT) From: Bob Hinden Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: 6MAN WG Last Call: Date: Thu, 4 Oct 2012 14:53:08 -0700 Message-Id: <67F311F3-363E-4870-A3AD-643BFC6D2978@gmail.com> To: "ipv6@ietf.org Mailing List" Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 21:53:13 -0000 All, This message starts a two week 6MAN Working Group on advancing: Title : Security Implications of the Use of IPv6 = Extension Headers with IPv6 Neighbor Discovery Author(s) : Fernando Gont Filename : draft-ietf-6man-nd-extension-headers-00.txt Pages : 12 Date : 2012-06-29 = http://tools.ietf.org/html/draft-ietf-6man-nd-extension-headers-00 as Proposed Standard. Substantive comments and statements of support = for advancing this document should be directed to the mailing list. = Editorial suggestions can be sent to the authors. This last call will = end on 18 October 2012. Regards, Bob Hinden & Ole Tr=F8an=20 From gorry@erg.abdn.ac.uk Thu Oct 4 23:56:38 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A043221F859B; Thu, 4 Oct 2012 23:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIO7bQZ8C89k; Thu, 4 Oct 2012 23:56:38 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id B3CBE21F859F; Thu, 4 Oct 2012 23:56:37 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id DE8562B457B; Fri, 5 Oct 2012 07:56:34 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Fri, 5 Oct 2012 07:56:35 +0100 Message-ID: <6ecaf2f61458adc545839c3c856ce7fb.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <20121004183314.13770.19480.idtracker@ietfa.amsl.com> References: <20121004183314.13770.19480.idtracker@ietfa.amsl.com> Date: Fri, 5 Oct 2012 07:56:35 +0100 Subject: Re: Barry Leiba's Discuss on draft-ietf-6man-udpchecksums-04: (with DISCUSS) From: gorry@erg.abdn.ac.uk To: "Barry Leiba" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-udpchecksums@tools.ietf.org, ipv6@ietf.org, The IESG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 06:56:38 -0000 I think this is a good topic to review. I think we should look to this. While we do this, can I check your view on the possible document status? - If we need RFC2119 keywords to make the guidelines normative, would we make the document BCP - or are you happy with standards keywords in an informational document? Gorry > Barry Leiba has entered the following ballot position for > draft-ietf-6man-udpchecksums-04: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This is a combined DISCUSS on udpchecksums and udpzero. First, let me > say that I have no actual objection to publishing either of these > documents. What I'm concerned about is whether we're saying what we want > to stay as a "standard", so let's discuss that: > > The issue comes when I look at udpzero Section 5.1 and udpchecksums > section 5. The numbered list in the latter is essentially a > word-for-word copy of the numbered list in the former, with the "must"s > and "may"s and "should not"s changed to upper case. It always bothers me > when a significant amount of important text is duplicated like that, but > the real problem comes when I look at what this *says*. > > Because udpzero is informational, when it says, "If a zero checksum > approach were to be adopted by the IETF, the specification should > consider adding the following constraints on usage," that makes no > normative requirement on any future protocol that runs on UDP and decides > to bypass the UDP checksums. Now, of course, we also have a document, > udpchecksums, which defines what to do if you do tunneling on UDP and you > want to skip the outer checksums (because you have inner ones). *That* > document makes this list normative. > > But what happens if, later, someone decides to document how to do, let's > say, media streaming over UDP with zero checksums. The analysis in > udpzero applies, of course, but the new document is under no obligation > to consider it or any of those usage restrictions in Section 5.1. (It > might be that such a document could never get past the current community > and ADs, but I'm not sure we want to leave that to chance.) > > So the question comes to what we want to say normatively. Which is it > that we want a standard saying? > > 1. If you tunnel packets over UDP and want to avoid the UDP checksums, > you need to use this list of restrictions. But other applications over > UDP that want to avoid the UDP checksums can make entirely different > decisions. > > or > > 2. If you do *anything* over UDP and want to avoid the UDP checksums, you > need to use this list of restrictions. And here's how tunneling over UDP > works. > > I think (2) is right, but the way the documents are structured now says > (1). > > Discussion, please.... > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From barryleiba@gmail.com Fri Oct 5 04:14:52 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C82021F866C; Fri, 5 Oct 2012 04:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.055 X-Spam-Level: X-Spam-Status: No, score=-103.055 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuLpdkE2+nW6; Fri, 5 Oct 2012 04:14:51 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4E721F8686; Fri, 5 Oct 2012 04:14:50 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so2074000vcb.31 for ; Fri, 05 Oct 2012 04:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=m3IoI1E3k+UO01qcLaM6qKiGGOUiUhn0VpsowbAWOZE=; b=zKoCVEvYsn04HwTwMnTcBpBlICsobTfOx3+2wksqDnKKfDIyNIvCHcbC/TWQxIlPHE N4rlsgYaG9HXexT9AQNUwdTdUFbctpoln1ODh/gTq7f1yQvc3UiUFXKb3yxpxwOunVTL dv5/2r1BTAY9gitxi58GMa0A0EsjW7MS1KRnMZY4GQI1ly9cCrMqkMsHPuMmjBGAgsDt LGQhGRhIUAC2PLqhRmOG/LDNf5vT5G+cUt8LL7ratKOaKMIbb1xL9Beq6mU921qCvLJb bl4zGp0BNA/xB+Z+z5+K/qSin/D+pejHVXqjJEPJJzKp+R3oe34QbXA/Viixi7AewgDo 1hFA== MIME-Version: 1.0 Received: by 10.220.208.210 with SMTP id gd18mr4933897vcb.43.1349435683914; Fri, 05 Oct 2012 04:14:43 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.59.5.72 with HTTP; Fri, 5 Oct 2012 04:14:43 -0700 (PDT) In-Reply-To: <6ecaf2f61458adc545839c3c856ce7fb.squirrel@www.erg.abdn.ac.uk> References: <20121004183314.13770.19480.idtracker@ietfa.amsl.com> <6ecaf2f61458adc545839c3c856ce7fb.squirrel@www.erg.abdn.ac.uk> Date: Fri, 5 Oct 2012 07:14:43 -0400 X-Google-Sender-Auth: sX9c0OXWpgKqDSAxz9v3ZoesdJQ Message-ID: Subject: Re: Barry Leiba's Discuss on draft-ietf-6man-udpchecksums-04: (with DISCUSS) From: Barry Leiba To: gorry@erg.abdn.ac.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-udpchecksums@tools.ietf.org, ipv6@ietf.org, The IESG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 11:14:52 -0000 > While we do this, can I check your view on the possible document status? > - If we need RFC2119 keywords to make the guidelines normative, would we > make the document BCP - or are you happy with standards keywords in an > informational document? Actually, I was thinking Proposed Standard, as an Applicability Statement (see RFC 2026, Section 3.2). BCP would be an alternative also. I think that, *if this is the way the WG decides to go*, it would not require extensive document changes. I see it as something like this: ---- a. Make udpzero a Proposed Standard and call it an Applicability Statement, or make it a BCP. b. Put the 2119 language into udpzero Section 5.1, instead of in udpchecksums Section 5. c. Change the intro paragraph in udpzero Section 5: OLD This section identifies requirements for the protocols that are transported over a transport connection that does not perform a UDP checksum calculation to verify the integrity at the transport endpoints. NEW (for AS) This section is an Applicability Statement that identifies REQUIRED restrictions on the use of techniques that involve not performing UDP checksum calculations to verify the integrity at the transport endpoints. NEW (for BCP) This section specifies best current practice for REQUIRED restrictions on the use of techniques that involve not performing UDP checksum calculations to verify the integrity at the transport endpoints. (Or some similar sort of language to indicate that the restrictions must be followed.) d. Change udpchecksums Section 5 to remove the numbered list and the RFC Editor note, and to make this other change: OLD However, some protocols, such as tunneling protocols that use UDP as a tunnel encapsulation, MAY omit computing the UDP checksum of the encapsulating UDP header and set it to zero, subject to the constraints described in RFCXXXX. NEW However, some protocols, such as tunneling protocols that use UDP as a tunnel encapsulation, MAY omit computing the UDP checksum of the encapsulating UDP header and set it to zero, subject to the constraints described in [I-D.ietf-6man-udpzero], Section 5.1. e. Make udpzero a normative reference. ---- With those changes, most of udpzero remains as informational exposition leading up to Section 5, and Section 5 is the normative part. Barry From v6ops@globis.net Fri Oct 5 12:45:31 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358CF21F86BB for ; Fri, 5 Oct 2012 12:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNDKoliQre3h for ; Fri, 5 Oct 2012 12:45:30 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id E865721F86C2 for <6man@ietf.org>; Fri, 5 Oct 2012 12:45:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 465628700EF; Fri, 5 Oct 2012 21:45:13 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SygezgL8TxkY; Fri, 5 Oct 2012 21:44:44 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 129A7870083; Fri, 5 Oct 2012 21:44:44 +0200 (CEST) Message-ID: <506F38A5.9090407@globis.net> Date: Fri, 05 Oct 2012 21:44:37 +0200 From: Ray Hunter User-Agent: Postbox 3.0.5 (Macintosh/20120826) MIME-Version: 1.0 To: mohamed.boucadair@orange.com Subject: Re: draft-boucadair-6man-sip-proxy-01 References: <94C682931C08B048B7A8645303FDC9F36E5F75BA9B@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5F75BA9B@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 05 Oct 2012 12:55:28 -0700 Cc: "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 19:45:31 -0000 I have read this draft and do not support it as-is. I do not agree with the conclusion that extending RA with a new option for SIP is necessary nor desirable. IMVHO: 1. There are other mechanisms available. DHCPv6 is not mandatory in the IPv6 node requirements, but neither is SIP. Adding a new RA option would mean firmware in mobile devices would have to be updated, just as they would if incorporating a DHCPv6 client, so that's a wash. 2. An FQDN has an indeterminate length, although encoding of an FQDN in RFC1035 limits this to 255 octets, it's still potentially a significant increase in the length of RA messages, which is undesirable for many reasons (including stateless security filtering mechanisms like RA-Guard). 3.There's no padding specified on the FQDN encoding. AFAIK RFC1035 does not specify how to encode an FQDN into 8 octet blocks (required for RA options length calculations). 4. You can hardly talk about advantages of using an RA option rather than an alternative unicast mechanism on a point to point bearer link (where no other nodes can listen out for the broadcast/multicast information to save on multiple transmissions). The end node still also has to resolve the FQDN into one or more IPv6 or IPv4 addresses via DNS before it can transmit any SIP messages, so it's not exactly a RTT start up latency or packet saver either. Or am I missing something? regards, RayH mohamed.boucadair@orange.com wrote: > Dear all, > > Comments are more than welcome. > > Cheers, > Med > > -----Message d'origine----- > De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] De la part de internet-drafts@ietf.org > Envoyé : jeudi 4 octobre 2012 09:12 > À : i-d-announce@ietf.org > Objet : I-D Action: draft-boucadair-6man-sip-proxy-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : IPv6 RA Option for SIP Proxy Server > Author(s) : Mohamed Boucadair > David Binet > Filename : draft-boucadair-6man-sip-proxy-01.txt > Pages : 6 > Date : 2012-10-04 > > Abstract: > This document specifies a new optional extension to IPv6 Router > Advertisement messages to advertise SIP Proxy Server (e.g., P-CSCF) > addresses to IPv6 hosts. > > The provisioning of the SIP Proxy Server address is crucial for the > delivery of SIP-based services. Means to ensure reliable delivery of > this information to connecting SIP User Agents is a must. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-boucadair-6man-sip-proxy > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-boucadair-6man-sip-proxy-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=aft-boucadair-6man-sip-proxy-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From v6ops@globis.net Fri Oct 5 13:02:38 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E5721F8723 for ; Fri, 5 Oct 2012 13:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.275 X-Spam-Level: X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwaFxF2LUEDs for ; Fri, 5 Oct 2012 13:02:38 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4AEE021F864A for ; Fri, 5 Oct 2012 13:02:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 4A8A58700EF; Fri, 5 Oct 2012 22:02:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkRFArf47QzU; Fri, 5 Oct 2012 22:01:52 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id B7D8C870083; Fri, 5 Oct 2012 22:01:52 +0200 (CEST) Message-ID: <506F3CAA.7020302@globis.net> Date: Fri, 05 Oct 2012 22:01:46 +0200 From: Ray Hunter User-Agent: Postbox 3.0.5 (Macintosh/20120826) MIME-Version: 1.0 To: Bob Hinden Subject: Re: 6MAN WG Last Call: References: <67F311F3-363E-4870-A3AD-643BFC6D2978@gmail.com> In-Reply-To: <67F311F3-363E-4870-A3AD-643BFC6D2978@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "ipv6@ietf.org Mailing List" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 20:02:38 -0000 Support. Bob Hinden wrote: > All, > > This message starts a two week 6MAN Working Group on advancing: > > Title : Security Implications of the Use of IPv6 Extension Headers with IPv6 Neighbor Discovery > Author(s) : Fernando Gont > Filename : draft-ietf-6man-nd-extension-headers-00.txt > Pages : 12 > Date : 2012-06-29 > > http://tools.ietf.org/html/draft-ietf-6man-nd-extension-headers-00 > > as Proposed Standard. Substantive comments and statements of support for advancing this document should be directed to the mailing list. Editorial suggestions can be sent to the authors. This last call will end on 18 October 2012. > > Regards, > > Bob Hinden& Ole Trøan > > > From markzzzsmith@yahoo.com.au Sat Oct 6 17:49:52 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8B321F8498 for ; Sat, 6 Oct 2012 17:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.572 X-Spam-Level: X-Spam-Status: No, score=-1.572 tagged_above=-999 required=5 tests=[AWL=0.527, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hhXdfdFQBzM for ; Sat, 6 Oct 2012 17:49:51 -0700 (PDT) Received: from nm9.bullet.mail.ac4.yahoo.com (nm9.bullet.mail.ac4.yahoo.com [98.139.52.206]) by ietfa.amsl.com (Postfix) with SMTP id 15E6E21F8496 for ; Sat, 6 Oct 2012 17:49:50 -0700 (PDT) Received: from [98.139.52.192] by nm9.bullet.mail.ac4.yahoo.com with NNFMP; 07 Oct 2012 00:49:47 -0000 Received: from [98.139.52.146] by tm5.bullet.mail.ac4.yahoo.com with NNFMP; 07 Oct 2012 00:49:47 -0000 Received: from [127.0.0.1] by omp1029.mail.ac4.yahoo.com with NNFMP; 07 Oct 2012 00:49:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 255188.36279.bm@omp1029.mail.ac4.yahoo.com Received: (qmail 69613 invoked by uid 60001); 7 Oct 2012 00:49:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1349570986; bh=ly0fyg0jqz8ol0PKRCbABgaTjP+aaIKFosr7M2DOPrI=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5ITNcGY3cqaQwQJkv/cuxdpMrMq/rNbdk6Yax8OifLaItolTXm5q1DZo2I0d74ICfIcofdf4VQi4MUrcC28IIqsQiSleIsmRUnuqwwXv8bnREFeMPz9ncCIrayGHYCRppY74/cdRmErvBqiBQpHYsSO96XE+pNd1c4vHyYEgrow= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Iiim8n4B3Gv6IshhnCWn0xGk+1AwhGApuP+EPAkBMzK+/atg7qnmAOXwdttcZMMrg4C9SGeqCa+IOLGNAbWN5cpxM9Rh9PhBDxOeFo03GXTGFWm+BeCp32u7fl/ZrkKVk9K27UTnh2N3Hv1x3dwqbmoWF+xw219b7zG3vvMNmxY=; X-YMail-OSG: kvLqDA0VM1lyuoyzfjSPmnt_OFWRObWw46paLf2Kn9Lf34I kSBcGU20Z2AMsTSbranVDuEnb84hIlpQB02TkWlRWXhnbEQELblN3TViwIgp PD4IlKr6SvuOips0LhgXazqideGcXViKdGTH.5IKRMBVSOYKN2EemItb_8x. 1RUKy4LXrlhVqQsMbzWvJeqLTK.IORJBq8Y_Y026w0ysZ9nddOJ6C3z3y3mw uCQtLQE7CKdRTtUNy.LMjokUnjHMQ5UD0kPlOU3EyhZuej_cGkpqf.TWLLR0 sn2ZfYN7SpV3Bn24eiK5OPc5LpEknnYaTR6n_jfOXIds.HsRTIhshj35t9Bu EiYBgs9BY2MbtaZzkYecLKePIUDAPQiYc7aljXPeTlm_tgPL8yMG.eZFin_X nDY9zriu7JJ6I9eRlbweUZ9EC08cR_vVe_ooP0gFEnAHdk1ys9IR1qLnHgpd 0W3Zjt1t_VHdHYlQlASv3iAoAyegacROoAmAXYaqOyutZW0CiCmtjhV9p_pN dWq1_eAZxpZX735oVU6x5vp3fYSEMiQ-- Received: from [150.101.221.237] by web32502.mail.mud.yahoo.com via HTTP; Sat, 06 Oct 2012 17:49:46 PDT X-Mailer: YahooMailWebService/0.8.122.442 References: <20121007004149.10252.36866.idtracker@ietfa.amsl.com> Message-ID: <1349570986.67217.YahooMailNeo@web32502.mail.mud.yahoo.com> Date: Sat, 6 Oct 2012 17:49:46 -0700 (PDT) From: Mark ZZZ Smith Subject: Fw: New Version Notification for draft-smith-6man-mitigate-nd-cache-dos-slnd-00.txt To: "ipv6@ietf.org" In-Reply-To: <20121007004149.10252.36866.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 00:49:52 -0000 Hi,=0A=0AI'd be interested if people think the idea has merit, and is worth= putting more time into.=0A=0AThanks very much,=0AMark.=0A=0A=0A----- Forwa= rded Message -----=0A> From: "internet-drafts@ietf.org" =0A> To: markzzzsmith@yahoo.com.au=0A> Cc: =0A> Sent: Sunday, 7 Octo= ber 2012 11:41 AM=0A> Subject: New Version Notification for draft-smith-6ma= n-mitigate-nd-cache-dos-slnd-00.txt=0A> =0A> =0A> A new version of I-D, dra= ft-smith-6man-mitigate-nd-cache-dos-slnd-00.txt=0A> has been successfully s= ubmitted by Mark Smith and posted to the=0A> IETF repository.=0A> =0A> File= name:=A0=A0=A0 draft-smith-6man-mitigate-nd-cache-dos-slnd=0A> Revision:= =A0=A0=A0 00=0A> Title:=A0=A0=A0 =A0=A0=A0 Mitigating IPv6 Router Neighbo= r Cache DoS Using Stateless =0A> Neighbor Discovery=0A> Creation date:=A0= =A0=A0 2012-10-07=0A> WG ID:=A0=A0=A0 =A0=A0=A0 Individual Submission=0A>= Number of pages: 9=0A> URL:=A0 =A0 =A0 =A0 =A0 =A0 =0A> http://www.ietf.or= g/internet-drafts/draft-smith-6man-mitigate-nd-cache-dos-slnd-00.txt=0A> St= atus:=A0 =A0 =A0 =A0 =A0 =0A> http://datatracker.ietf.org/doc/draft-smith-6= man-mitigate-nd-cache-dos-slnd=0A> Htmlized:=A0 =A0 =A0 =A0 =0A> http://too= ls.ietf.org/html/draft-smith-6man-mitigate-nd-cache-dos-slnd-00=0A> =0A> = =0A> Abstract:=0A> =A0 The IPv6 neighbor discovery cache is vulernable to = a Denial of=0A> =A0 Service attack that purposely exhausts the state used = during the=0A> =A0 neighbor discovery address resolution process.=A0 This = can be very=0A> =A0 disruptive when a router is successfully attacked.=0A>= =0A> =A0 This memo proposes a stateless form of neighbor discovery to be = used=0A> =A0 by routers to eliminate the opportunity for this DoS attack.= =A0 This=0A> =A0 method of stateless neighbor discovery would be used for = unknown or=0A> =A0 untrusted packet sources, when the router's neighbor ca= che's state=0A> =A0 capacity reaches a medium to high threshold of use.=A0= Trusted packet=0A> =A0 sources would continue to be provided with traditi= onal stateful=0A> =A0 neighbor discovery.=0A> =0A> =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =0A> =A0 = =0A> =0A> =0A> The IETF Secretariat=0A> From internet-drafts@ietf.org Sun Oct 7 16:50:50 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6CD21F86CA; Sun, 7 Oct 2012 16:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 168xRZ1ktz8N; Sun, 7 Oct 2012 16:50:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E3921F86B9; Sun, 7 Oct 2012 16:50:49 -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 Subject: I-D Action: draft-ietf-6man-stable-privacy-addresses-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121007235049.15102.96254.idtracker@ietfa.amsl.com> Date: Sun, 07 Oct 2012 16:50:49 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 23:50:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : A method for Generating Stable Privacy-Enhanced Addresse= s with IPv6 Stateless Address Autoconfiguration (SLAAC) Author(s) : Fernando Gont Filename : draft-ietf-6man-stable-privacy-addresses-01.txt Pages : 17 Date : 2012-10-07 Abstract: This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that addresses configured using this method are stable within each subnet, but the Interface Identifier changes when hosts move from one network to another. The aforementioned method is meant to be an alternative to generating Interface Identifiers based on IEEE identifiers, such that the benefits of stable addresses can be achieved without sacrificing the privacy of users. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-stable-privacy-addresses= -01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From fgont@si6networks.com Sun Oct 7 16:52:56 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E95B21F86DD for ; Sun, 7 Oct 2012 16:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWYKB1kaOyhR for ; Sun, 7 Oct 2012 16:52:56 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id F1B7A21F86D1 for ; Sun, 7 Oct 2012 16:52:55 -0700 (PDT) Received: from cust-230-207-109-94.dyn.as47377.net ([94.109.207.230] helo=[192.168.1.119]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TL0eT-000474-5W; Mon, 08 Oct 2012 01:52:53 +0200 Message-ID: <507215D2.6000208@si6networks.com> Date: Mon, 08 Oct 2012 01:52:50 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: "ipv6@ietf.org" Subject: Fwd: New Version Notification for draft-ietf-6man-stable-privacy-addresses-01.txt References: <20121007235049.15102.83502.idtracker@ietfa.amsl.com> In-Reply-To: <20121007235049.15102.83502.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.4 X-Forwarded-Message-Id: <20121007235049.15102.83502.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 23:52:56 -0000 Folks. FYI, I've just posted a rev of the aforementioned I-D. I personally believe that this version is ready for WGLC. Thanks! Best regards, Fernando -------- Original Message -------- Subject: New Version Notification for draft-ietf-6man-stable-privacy-addresses-01.txt Date: Sun, 07 Oct 2012 16:50:49 -0700 From: internet-drafts@ietf.org To: fgont@si6networks.com A new version of I-D, draft-ietf-6man-stable-privacy-addresses-01.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Filename: draft-ietf-6man-stable-privacy-addresses Revision: 01 Title: A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC) Creation date: 2012-10-08 WG ID: 6man Number of pages: 17 URL: http://www.ietf.org/internet-drafts/draft-ietf-6man-stable-privacy-addresses-01.txt Status: http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses Htmlized: http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-stable-privacy-addresses-01 Abstract: This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that addresses configured using this method are stable within each subnet, but the Interface Identifier changes when hosts move from one network to another. The aforementioned method is meant to be an alternative to generating Interface Identifiers based on IEEE identifiers, such that the benefits of stable addresses can be achieved without sacrificing the privacy of users. The IETF Secretariat From stbryant@cisco.com Sun Oct 7 20:26:19 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09C921F873C; Sun, 7 Oct 2012 20:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyOMQto28uTm; Sun, 7 Oct 2012 20:26:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E9121F8732; Sun, 7 Oct 2012 20:26:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Stewart Bryant" To: The IESG Subject: Stewart Bryant's Discuss on draft-ietf-6man-udpzero-06: (with DISCUSS and COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121008032619.20138.82801.idtracker@ietfa.amsl.com> Date: Sun, 07 Oct 2012 20:26:19 -0700 Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-udpchecksums@tools.ietf.org, draft-ietf-6man-udpzero@tools.ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 03:26:20 -0000 Stewart Bryant has entered the following ballot position for draft-ietf-6man-udpzero-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This discuss applies to both this draft and draft-ietf-6man-udpchecksums-04 Fundamentally I support the liberalization of the position regarding IPv6 UDP checksums when UDP is used for tunnels and hope to get to a yes position on both drafts. However, there is some text that needs discussion, and then we need to discuss the consequences of that discussion. The rational for the slightly conservative position taken in the case of tunnels seems to based on the following text: "IP packets may be corrupted as they traverse an Internet path. Evidence has been presented [Sigcomm2000] to show that this was once an issue with IPv4 routers, and occasional corruption could result from bad internal router processing in routers or hosts. These errors are not detected by the strong frame checksums employed at the link-layer [RFC3819]. There is no current evidence that such cases are rare in the modern Internet, nor that they may not be applicable to IPv6. It therefore seems prudent not to relax this constraint. The emergence of low-end IPv6 routers and the proposed use of NAT with IPv6 further motivate the need to protect from this type of error." However we do have a body of evidence that is not discussed in the document. Firstly we have a decade of experience with MPLS VPNs where the VPN Identifier label, which is used to steer the traffic to a particular customer network (i.e. is functionally equivalent to an address), is not protected by a checksum. I am not aware of any concerns expressed by operators in this regard, and I am not aware of any work in the MPLS WG to introduce checksum like protection. We also have a decade of experience with pseudowires. With one exception that we will discuss in a minute, none of the PW designs have any form of data integrity protection other than the CRC imposed by the network datalink at each hop. In the specific case of the Ethernet PW, there are two modes: one in which the CRC is stripped at ingress to the PW and recalculated at egress, and another where it is preserved end to end. There is very little, if any, deployment of the end to end CRC preservation mode. Given that there must be some low level of corruption of the frames, I would conclude that the protocols that are likely to be tunneled are sufficiently hardened that the occasional corruption is of no practical consequence. Thus I would conclude that the level of corruption is sufficiently rare and of sufficiently minor consequence that at least in the case of service provider networks implementing UDP tunneling, it is safe to omit the UDP checksum without analysis of the application. I would propose that the text should include some acknowledgement of this recent body of evidence and that the recommendation be aligned in consequence to unconditionally allow C/S free tunneling, at least within a well managed domain without additional consideration. Section 5.1 seems to be duplicated in the two drafts. It would be better if the text were just in one RFC and the other pointed to it. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- You also note that an application may rely on the checksum to protect it against packets that may damage it. I find this very weak argument, since such an application would be vulnerable to packets deliberately malformed by an attacker, or malformed by a software bug in a peer. The correct approach is surely to harden the application, and thus the checksum argument is not persuasive. You note the need to signal the agreement not to use c/s, I think that you need to include the configuration of this property as an alternative, and note that configuration may be implicit in the definition of the UDP payload. From stbryant@cisco.com Sun Oct 7 20:37:08 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7B921F8748; Sun, 7 Oct 2012 20:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WupPNBJZfl5e; Sun, 7 Oct 2012 20:37:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B183721F873D; Sun, 7 Oct 2012 20:37:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Stewart Bryant" To: The IESG Subject: Stewart Bryant's Discuss on draft-ietf-6man-udpchecksums-04: (with DISCUSS and COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121008033707.32326.82712.idtracker@ietfa.amsl.com> Date: Sun, 07 Oct 2012 20:37:07 -0700 Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-udpchecksums@tools.ietf.org, draft-ietf-6man-udpzero@ietfa.amsl.com, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 03:37:08 -0000 Stewart Bryant has entered the following ballot position for draft-ietf-6man-udpchecksums-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Please see my discuss on draft-ietf-6man-udpzero, and note that I hope to get to yes on this draft also, since I support the liberalization of this protocol design when used for tunnelling. Specifically point 6 in this draft is relevant to this discussion. Additionally a tunnel may not have any way of knowing if the payload is protected (as you suggest), since normally a tunnel has no knowledge of the payload characteristics. = In point 7 you suggest that an application cannot rely on packet length. When PWs are used for tunneling we rely on exactly that (except in the case of packets shorter than 64 octets for Ethenet padding reasons), and I am not aware of any reported issues. Thus when the application is tunnel encap/decap there is a body of evidence that suggests that this OK. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- There is some text in the earlier part of document that looks like it should be written in RFC2119 format. In this case it is not important because the normative change is later and this used RFC2119 directives, however the authors should consider making the document self consistent in this regard. From stbryant@cisco.com Sun Oct 7 20:44:25 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843E221F8744; Sun, 7 Oct 2012 20:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65sMQsTVtXMq; Sun, 7 Oct 2012 20:44:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C1D21F858F; Sun, 7 Oct 2012 20:44:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Stewart Bryant" To: The IESG Subject: Stewart Bryant's No Objection on draft-ietf-6man-dad-proxy-05 X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121008034425.5276.22832.idtracker@ietfa.amsl.com> Date: Sun, 07 Oct 2012 20:44:25 -0700 Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-dad-proxy@tools.ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 03:44:25 -0000 Stewart Bryant has entered the following ballot position for draft-ietf-6man-dad-proxy-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. There are no remarks associated with this position. From gorry@erg.abdn.ac.uk Mon Oct 8 01:07:34 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0299A21F8714; Mon, 8 Oct 2012 01:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.369 X-Spam-Level: X-Spam-Status: No, score=-102.369 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmCCY1WG5mS4; Mon, 8 Oct 2012 01:07:30 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 41E4B21F870F; Mon, 8 Oct 2012 01:07:29 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 612A52B45BD; Mon, 8 Oct 2012 09:07:27 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Mon, 8 Oct 2012 09:07:27 +0100 Message-ID: <49e67b435262485faab7feffa4497482.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <20121008032619.20138.82801.idtracker@ietfa.amsl.com> References: <20121008032619.20138.82801.idtracker@ietfa.amsl.com> Date: Mon, 8 Oct 2012 09:07:27 +0100 Subject: Re: Stewart Bryant's Discuss on draft-ietf-6man-udpzero-06: (with DISCUSS and COMMENT) From: gorry@erg.abdn.ac.uk To: "Stewart Bryant" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-udpchecksums@tools.ietf.org, draft-ietf-6man-udpzero@tools.ietf.org, The IESG , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 08:07:34 -0000 Thanks for your comments, see below. Gorry > Stewart Bryant has entered the following ballot position for > draft-ietf-6man-udpzero-06: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This discuss applies to both this draft and > draft-ietf-6man-udpchecksums-04 > > Fundamentally I support the liberalization of the position regarding IPv6 > UDP checksums when UDP is used for tunnels and hope to get to a yes > position on both drafts. However, there is some text that needs > discussion, and then we need to discuss the consequences of that > discussion. The rational for the slightly conservative position taken in > the case of tunnels seems to based on the following text: > > "IP packets may be corrupted as they traverse an Internet path. > Evidence has been presented [Sigcomm2000] to show that this was once > an issue with IPv4 routers, and occasional corruption could result > from bad internal router processing in routers or hosts. These > errors are not detected by the strong frame checksums employed at the > link-layer [RFC3819]. There is no current evidence that such cases > are rare in the modern Internet, nor that they may not be applicable > to IPv6. It therefore seems prudent not to relax this constraint. > The emergence of low-end IPv6 routers and the proposed use of NAT > with IPv6 further motivate the need to protect from this type of > error." > > However we do have a body of evidence that is not discussed in the > document. Firstly we have a decade of experience with MPLS VPNs where the > VPN Identifier label, which is used to steer the traffic to a particular > customer network (i.e. is functionally equivalent to an address), is not > protected by a checksum. I am not aware of any concerns expressed by > operators in this regard, and I am not aware of any work in the MPLS WG > to introduce checksum like protection. > 1) I'm not sure whether you are saying MPLS is robust to these effects *OR* that MPLS stacks have monitored for this case, e.g. do log such an unexpected VPN Identifier label, and somehow report this (and hence there is evidence that MPLS routers do not see such errors) > We also have a decade of experience with pseudowires. With one exception > that we will discuss in a minute, none of the PW designs have any form of > data integrity protection other than the CRC imposed by the network > datalink at each hop. In the specific case of the Ethernet PW, there are > two modes: one in which the CRC is stripped at ingress to the PW and > recalculated at egress, and another where it is preserved end to end. > There is very little, if any, deployment of the end to end CRC > preservation mode. Given that there must be some low level of corruption > of the frames, I would conclude that the protocols that are likely to be > tunneled are sufficiently hardened that the occasional corruption is of > no practical consequence. > 2) On acceptability of residual corruption: I think I missed something - If you are saying that using Ethernet "bridging" is safe at L2, then that's not this discussion. I am interested in any experience that would help in understanding the impact of no checksum for IPv6, e.g. experience in how often the IPv4 checksum and IPv4/UDP checksum fail. 3) On practical rate of residual corruption: Is there experience of using MPLS/PWE across low-end and legacy routers? I am not aware of this, but I would be really interested in knowing more about the reliability across an end-to-end path i.e. PWE and MPLS through home gateways, firewalls, load-balancers, NAT and NAPT. What experience has the community seen? > Thus I would conclude that the level of corruption is sufficiently rare > and of sufficiently minor consequence that at least in the case of > service provider networks implementing UDP tunneling, it is safe to omit > the UDP checksum without analysis of the application. > 4) I disagree. > I would propose that the text should include some acknowledgement of this > recent body of evidence and that the recommendation be aligned in > consequence to unconditionally allow C/S free tunneling, at least within > a well managed domain without additional consideration. > 5) It seems OK to note the new evidence for use within a well-managed domain, can you supply references to the usage and experience? I have a question: would the domain include host stacks and end-to-end usage or just carrier usage? > Section 5.1 seems to be duplicated in the two drafts. It would be better > if the text were just in one RFC and the other pointed to it. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > You also note that an application may rely on the checksum to protect it > against packets that may damage it. I find this very weak argument, since > such an application would be vulnerable to packets deliberately malformed > by an attacker, or malformed by a software bug in a peer. The correct > approach is surely to harden the application, and thus the checksum > argument is not persuasive. > 6) I'm surprised/misunderstood - many deployed uses of the UDP transport have relied on the UDP cksum (more latterly this not been the advice of the IETF, but hard to enforce). Is this suggesting the IETF actually declare these (existing deployed IPv4) apps as unsuitable for use with IPv6 over the general Internet. That's NOT something I would personally like to do, have I understood correctly? > You note the need to signal the agreement not to use c/s, I think that > you need to include the configuration of this property as an alternative, > and note that configuration may be implicit in the definition of the UDP > payload. > 7) The intent was not to change the semantic of the cksum for apps that expected the original behaviour. If you have an app that is willing to use no cksum - such as the tunnels - this may be fine, then I see two possibilities: It works (e.g. within a carrier network) or it may fail (e.g. via a NAPT/firewall that recalculates a cksum). I think it would be "nice" for the "app" to know it has UDP connectivity, but no UDP zero cksum connectivity - i.e. not just break when a route changes or a user moves to a new network. What do you suggest apps should do? > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From magnus.westerlund@ericsson.com Mon Oct 8 05:30:00 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9C821F8661; Mon, 8 Oct 2012 05:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QU0lIoa3OO1X; Mon, 8 Oct 2012 05:29:59 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id BF9F421F8551; Mon, 8 Oct 2012 05:29:58 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-4b-5072c745f88a Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 0C.71.11467.547C2705; Mon, 8 Oct 2012 14:29:57 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012 14:29:57 +0200 Message-ID: <5072C744.5020605@ericsson.com> Date: Mon, 8 Oct 2012 14:29:56 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Stewart Bryant Subject: Re: Stewart Bryant's Discuss on draft-ietf-6man-udpchecksums-04: (with DISCUSS and COMMENT) References: <20121008033707.32326.82712.idtracker@ietfa.amsl.com> In-Reply-To: <20121008033707.32326.82712.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUyM+Jvra7r8aIAgwM7FC0WdDaxWvzv/cZq 8XzCS0aLGX8mMlu8PPueyeLc0zmMDmweU35vZPVYsuQnk8ejZ2+YPb5c/swWwBLFZZOSmpNZ llqkb5fAldFxqrDgg2LFondfmBsYL0h3MXJySAiYSCzePYUFwhaTuHBvPVsXIxeHkMApRonL 7VPZIZxljBI9VzczgVTxCmhLbD77mBXEZhFQkdh77SgziM0mYCFx80cjG4gtKhAsMWn/FhaI ekGJkzOfANkcHCIC6hKv9ouDzGQWWMQo8amvBWymsECaxPxD68HmCAk4Snz6tBxsDqeAk8Sa u5+YIa6TlHgz+SbYTGYBTYnW7b/ZIWx5ieats6F6tSUamjpYJzAKzUKyehaSlllIWhYwMq9i FM5NzMxJLzfUSy3KTC4uzs/TK07dxAgM/4NbfuvuYDx1TuQQozQHi5I4L1fSfn8hgfTEktTs 1NSC1KL4otKc1OJDjEwcnFINjE0VGxOtb9xetKwiSHDGJrXVemLhcZE/7y5LqpkmrycUcL1w /7GVZemNshWL9lgdONw3T/7un9nbr2SFVPcqb7fUX7jcL4bnRVjHyxlLVrufviFy4IeRyP7c FVqmpVIME1KTtxUdltt8p1t3d6eAa7Rk01IJ/TufXaw/8Pg/zJ0gm5b95OHF10osxRmJhlrM RcWJAAvoC9tNAgAA Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-udpchecksums@tools.ietf.org, draft-ietf-6man-udpzero@ietfa.amsl.com, ipv6@ietf.org, The IESG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 12:30:00 -0000 Hi Stewart, See inline for comments On 2012-10-08 05:37, Stewart Bryant wrote: > Stewart Bryant has entered the following ballot position for > draft-ietf-6man-udpchecksums-04: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Please see my discuss on draft-ietf-6man-udpzero, and note that I hope to > get to yes on this draft also, since I support the liberalization of this > protocol design when used for tunnelling. Specifically point 6 in this > draft is relevant to this discussion. Acknowledged > Additionally a tunnel may not have any way of knowing if the payload is > protected (as you suggest), since normally a tunnel has no knowledge of > the payload characteristics. No, but a tunnel know what general class of traffic it encapsulates. Is it IPv4 that has at least IPv4 header checksums and possibly non-zero transport checksums, or are they some type of other L2 frames that has checksums as part of their frame headers. It is this type of knowledge in the tunnel payload we want the tunnel designer to consider if they need additional checksums or not. > > In point 7 you suggest that an application cannot rely on packet length. > When PWs are used for tunneling we rely on exactly that (except in the > case of packets shorter than 64 octets for Ethenet padding reasons), and > I am not aware of any reported issues. Thus when the application is > tunnel encap/decap there is a body of evidence that suggests that this > OK. First of all, I would like to understand a bit more about these experiences from pseudowires. Which type of psuedowires are we talking about here. And the derived experiences over which type of lower layer are being used. Is this IPv6/UDP or something else like MPLS? Secondly, it is likely that psuedowires is designed such that an error in the length field do not result in any corruption of any state or irregularities in processing that cause any substantial issues beyond possibly loosing that packet from its intended context. >From my perspective, trying to say that there is no risk with removing the UDP checksum even for a limited context is like trying to prove a negative. I am certain that some environments have very low corruption rates, but there might be other environments for IPv6 where it is much higher. I wished someone would repeat Stone and Patridge's investigation to get better understanding of the behaviors of IPv4 and IPv6 in this regards at different points in today's Internet. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > There is some text in the earlier part of document that looks like it > should be written in RFC2119 format. In this case it is not important > because the normative change is later and this used RFC2119 directives, > however the authors should consider making the document self consistent > in this regard. I guess you are referring to some text in the discussion. There are similarities in the discussion with the specification text as it is motivation why things are like they are. But I think the section differences and in addition the actual normative text is formulated in a different way that makes it unsuitable to apply RFC 2119 text on that earlier sections. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From rafiee@hpi.uni-potsdam.de Mon Oct 8 08:04:33 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF23D21F86D3 for ; Mon, 8 Oct 2012 08:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hayJmkI0+Pit for ; Mon, 8 Oct 2012 08:04:32 -0700 (PDT) Received: from mail3.hpi.uni-potsdam.de (mail3.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17b]) by ietfa.amsl.com (Postfix) with ESMTP id 3F47B21F86EC for ; Mon, 8 Oct 2012 08:04:30 -0700 (PDT) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail3.hpi.uni-potsdam.de (Postfix) with ESMTP id 54087169E9C for ; Mon, 8 Oct 2012 17:04:25 +0200 (CEST) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Mon, 8 Oct 2012 17:04:25 +0200 From: "Rafiee, Hosnieh" To: "ipv6@ietf.org" Date: Mon, 8 Oct 2012 17:04:24 +0200 Subject: Request for comments- draft-rafiee-cga-tsig-00.txt Thread-Topic: Request for comments- draft-rafiee-cga-tsig-00.txt Thread-Index: Ac2j45sFxUE0rpu8TkSPBU+zqBLZ4wABA/IAAF+UYsA= Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_EA738325B0580041A50A364F5F76B68924CD4EAF188MXMA1Rhpiuni_" MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 15:04:33 -0000 --_000_EA738325B0580041A50A364F5F76B68924CD4EAF188MXMA1Rhpiuni_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please take a look at my RFC draft and share your comments with me so that = I might improve it. I would like discuss this draft in IETF meetings in Atl= anta. Thanks, Hosnieh A new version of I-D, draft-rafiee-cga-tsig-00.txt has been successfully su= bmitted by Hosnieh Rafiee and posted to the IETF repository. Filename: draft-rafiee-cga-tsig Revision: 00 Title: Transaction SIGnature (TSIG) using CGA Algorith= m in IPv6 Creation date: 2012-09-30 WG ID: Individual Submission Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-rafiee-cga-tsig-= 00.txt Status: http://datatracker.ietf.org/doc/draft-rafiee-cga-tsig Htmlized: http://tools.ietf.org/html/draft-rafiee-cga-tsig-00 Abstract: The first step of Transaction SIGnature (TSIG) (RFC 2845) is to generate a shared secret and exchange it manually between a DNS server and a host. This document, CGA-TSIG, proposes a possible way to automate the now manual process for the authentication of a node with a DNS server during the DNS Update process by using the same parameters as are used in generating a secure address in IPv6 networks, i.e., Cryptographically Generated Addresses (CGA) (RFC 3972). CGA-TSIG facilitates this authentication process and reduces the time needed for DNS Updates. The current signature generation process and verification mechanism in TSIG are thus replaced with CGA. This algorithm is added, as an extension, to TSIG to eliminate the human intervention needed for generation and exchange of keys between a DNS server and a host when SEcure Neighbor Discovery (SEND) (RFC 3971) is used. --_000_EA738325B0580041A50A364F5F76B68924CD4EAF188MXMA1Rhpiuni_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Please take a look at my RFC draft and share y= our comments with me so that I might improve it. I would like discuss this = draft in IETF meetings in Atlanta.

Th= anks,

Hosnieh

 

 

 

A new ve= rsion of I-D, draft-rafiee-cga-tsig-00.txt has been successfully submitted = by Hosnieh Rafiee and posted to the IETF repository.

 

Filename: = ;           draft-rafiee-= cga-tsig

Revision:   &= nbsp;          00

Title:       &= nbsp;           &nbs= p;  Transaction SIGnature (TSIG) using CGA Algorithm in IPv6

Creation date:   2012-09-30

WG ID:      &nb= sp;           Individual = Submission

Number of pages: 13

URL:      &nb= sp;      http://www.ietf.org/internet-drafts/dra= ft-rafiee-cga-tsig-00.txt

Status:=           http://datatracker.ietf.org/d= oc/draft-rafiee-cga-tsig

Htmlized= :        http://tools.ietf.org/html/draft-rafiee-cg= a-tsig-00

 

 

Abstract= :

   The first step of Tran= saction SIGnature (TSIG) (RFC 2845) is to

   generate a shared secret and exchange it manually between= a DNS

   server and a host= . This document, CGA-TSIG, proposes a possible way

  to automate the now manual process for the auth= entication of a node

   wit= h a DNS server during the DNS Update process by using the same

   parameters as are used in generating= a secure address in IPv6

  = ; networks, i.e., Cryptographically Generated Addresses (CGA) (RFC

   3972). CGA-TSIG facilitates this= authentication process and reduces

&= nbsp;  the time needed for DNS Updates. The current signature generati= on

   process and verificat= ion mechanism in TSIG are thus replaced with

   CGA. This algorithm is added, as an extension, to TSIG= to eliminate

   the human = intervention needed for generation and exchange of keys

   between a DNS server and a host when SEcure= Neighbor Discovery (SEND)

 &nbs= p; (RFC 3971) is used.

 

 

= --_000_EA738325B0580041A50A364F5F76B68924CD4EAF188MXMA1Rhpiuni_-- From housley@vigilsec.com Mon Oct 8 08:27:00 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8117121F86F1; Mon, 8 Oct 2012 08:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKuNe3gIQYfb; Mon, 8 Oct 2012 08:27:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2534721F8605; Mon, 8 Oct 2012 08:27:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Russ Housley" To: The IESG Subject: Russ Housley's No Objection on draft-ietf-6man-udpchecksums-04: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121008152700.13599.69578.idtracker@ietfa.amsl.com> Date: Mon, 08 Oct 2012 08:27:00 -0700 Cc: Peter Yee , 6man-chairs@tools.ietf.org, ipv6@ietf.org, draft-ietf-6man-udpchecksums@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 15:27:00 -0000 Russ Housley has entered the following ballot position for draft-ietf-6man-udpchecksums-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please consider the non-blocking comments from the Gen-ART Review by Peter Yee on 30-Sep-2012. You can find the review here: http://www.ietf.org/mail-archive/web/gen-art/current/msg07809.html From stbryant@cisco.com Mon Oct 8 10:22:56 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B370821F86F8; Mon, 8 Oct 2012 10:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.602 X-Spam-Level: X-Spam-Status: No, score=-110.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXeHYzYCSbyE; Mon, 8 Oct 2012 10:22:55 -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 17A8A21F85B6; Mon, 8 Oct 2012 10:22:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5557; q=dns/txt; s=iport; t=1349716975; x=1350926575; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=TF/n8leiAGoYZXPDAOdOzYXfsN8bsiwdXJocg3zwuEY=; b=Y8WwMfAP4dAgFgju7LV9HxY4JjW8WCdQRJNPvQ7aNw/NBAgC0j4KazwS t0rkC4Rqsba+NDuZEEN1O+jIpuTnpkmOJHjlbMuSZ5P8lEDl5uQaTTrFO wyjhMRZvKGEsW6en2LgEKSW9Csn9w4zhSpTJGjKcefyR2AAeLm/CeUQDO w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAPsKc1CQ/khN/2dsb2JhbABFhhG5HRR0Y4EjAQEUBAEBAQMBEgECDhUvEQEQCxgCAgUWCwICCQMCAQIBRQYNAQcBAQUZhScHghkWBguaGYNKEIlBkkqBIYouFIRqgRIDlWuORYEGY4JugVkJ X-IronPort-AV: E=Sophos;i="4.80,555,1344211200"; d="scan'208";a="8613508" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 08 Oct 2012 17:22:50 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q98HMom6014618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Oct 2012 17:22:50 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q98HMfgg016293; Mon, 8 Oct 2012 18:22:43 +0100 (BST) Message-ID: <50730BE1.3010809@cisco.com> Date: Mon, 08 Oct 2012 18:22:41 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: Stewart Bryant's Discuss on draft-ietf-6man-udpchecksums-04: (with DISCUSS and COMMENT) References: <20121008033707.32326.82712.idtracker@ietfa.amsl.com> <5072C744.5020605@ericsson.com> In-Reply-To: <5072C744.5020605@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-udpchecksums@tools.ietf.org, draft-ietf-6man-udpzero@ietfa.amsl.com, ipv6@ietf.org, The IESG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 17:22:56 -0000 Hi Magnus, On 08/10/2012 13:29, Magnus Westerlund wrote: > Hi Stewart, > > See inline for comments > > On 2012-10-08 05:37, Stewart Bryant wrote: >> Stewart Bryant has entered the following ballot position for >> draft-ietf-6man-udpchecksums-04: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Please see my discuss on draft-ietf-6man-udpzero, and note that I hope to >> get to yes on this draft also, since I support the liberalization of this >> protocol design when used for tunnelling. Specifically point 6 in this >> draft is relevant to this discussion. > Acknowledged > >> Additionally a tunnel may not have any way of knowing if the payload is >> protected (as you suggest), since normally a tunnel has no knowledge of >> the payload characteristics. > No, but a tunnel know what general class of traffic it encapsulates. Is > it IPv4 that has at least IPv4 header checksums and possibly non-zero > transport checksums, or are they some type of other L2 frames that has > checksums as part of their frame headers. It is this type of knowledge > in the tunnel payload we want the tunnel designer to consider if they > need additional checksums or not. Sure you know if you are carrying IP or L2, but L2 mostly carries IP anyway. However you do not actually know what the user is going to carry over L2, and really have no right to know. You have to treat it as opaque traffic. In any case, as I said we take no precautions in PWs and we do not observe any issues carrying 'L1' or L2 over PW over MPLS without a c/s at either the network or the tunnel layer. > > >> In point 7 you suggest that an application cannot rely on packet length. >> When PWs are used for tunneling we rely on exactly that (except in the >> case of packets shorter than 64 octets for Ethenet padding reasons), and >> I am not aware of any reported issues. Thus when the application is >> tunnel encap/decap there is a body of evidence that suggests that this >> OK. > First of all, I would like to understand a bit more about these > experiences from pseudowires. Which type of psuedowires are we talking > about here. And the derived experiences over which type of lower layer > are being used. Is this IPv6/UDP or something else like MPLS? I am talking about PW/MPLS. Although PW/L2TP/IP exist in theory there is very little deployment. The most common PWs seem to be Ethernet (carrying whatever the Ethernet is carrying, IP but other protocols as well), ATM and TDM. There is also some Frame Relay (again with c/s removed and reconstructed), in all cases carried directly over MPLS. > > Secondly, it is likely that psuedowires is designed such that an error > in the length field do not result in any corruption of any state or > irregularities in processing that cause any substantial issues beyond > possibly loosing that packet from its intended context. Yes, PWs are stateless, but the application receiving the packet has unknown properties and if we make a mistake on the length the application will get a corrupt packet with a valid datalink c/s. However I have never heard this type of error discussed. > > >From my perspective, trying to say that there is no risk with removing > the UDP checksum even for a limited context is like trying to prove a > negative. I am certain that some environments have very low corruption > rates, but there might be other environments for IPv6 where it is much > higher. > > I wished someone would repeat Stone and Patridge's investigation to get > better understanding of the behaviors of IPv4 and IPv6 in this regards > at different points in today's Internet. My point is that we have a practical experiment ongoing with the huge number of PWs in deployment running over MPLS without c/s protection at the tunnel or network layer and I have never seen anyone raise an issue in either the PWE3 or MPLS WG. Hence my conclusion that whilst there is a theoretical risk, the evidence is that there are no reported issues. Note that I am only discussing the tunnel case, I make no comment on any other type of application. > > >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> There is some text in the earlier part of document that looks like it >> should be written in RFC2119 format. In this case it is not important >> because the normative change is later and this used RFC2119 directives, >> however the authors should consider making the document self consistent >> in this regard. > I guess you are referring to some text in the discussion. There are > similarities in the discussion with the specification text as it is > motivation why things are like they are. But I think the section > differences and in addition the actual normative text is formulated in a > different way that makes it unsuitable to apply RFC 2119 text on that > earlier sections. OK, I leave this to your judgement. - Stewart From cabo@tzi.org Mon Oct 8 11:13:43 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D1121F847A; Mon, 8 Oct 2012 11:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.216 X-Spam-Level: X-Spam-Status: No, score=-106.216 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsnqCIgPMcAw; Mon, 8 Oct 2012 11:13:43 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id F240721F8472; Mon, 8 Oct 2012 11:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q98IDVNl004987; Mon, 8 Oct 2012 20:13:31 +0200 (CEST) Received: from [192.168.217.105] (p54891A2C.dip.t-dialin.net [84.137.26.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2CCE6F82; Mon, 8 Oct 2012 20:13:31 +0200 (CEST) Subject: Re: Stewart Bryant's Discuss on draft-ietf-6man-udpchecksums-04: (with DISCUSS and COMMENT) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <50730BE1.3010809@cisco.com> Date: Mon, 8 Oct 2012 20:13:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121008033707.32326.82712.idtracker@ietfa.amsl.com> <5072C744.5020605@ericsson.com> <50730BE1.3010809@cisco.com> To: stbryant@cisco.com X-Mailer: Apple Mail (2.1499) Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, draft-ietf-6man-udpchecksums@tools.ietf.org, draft-ietf-6man-udpzero@ietfa.amsl.com, The IESG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 18:13:43 -0000 On Oct 8, 2012, at 19:22, Stewart Bryant wrote: > My point is that we have a practical experiment ongoing with the > huge number of PWs in deployment running over MPLS without > c/s protection at the tunnel or network layer and I have never seen > anyone raise an issue in either the PWE3 or MPLS WG. Hence > my conclusion that whilst there is a theoretical risk, the evidence > is that there are no reported issues. One reason the occasional misdirected packet is not causing problems = here might be that there are higher level headers that prevent delivery = to an application (be it for a checksum mismatch or more likely because = the higher level addresses just don't point in the direction of = trouble). Which would mesh fine with the argument made in the draft = that UDP zero checksum is fine for tunnels but not so much for other = applications like end-to-end. I definitely agree with the subtext that the udpzero issue is often seen = a bit more dogmatic than needs be, but I also think that having this = degree of robustness in a widely deployed protocol is a desirable = property that shouldn't be given up lightly. Gr=FC=DFe, Carsten From rafiee@hpi.uni-potsdam.de Tue Oct 9 04:13:42 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB1921F84F0; Tue, 9 Oct 2012 04:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNGaPDApEs1w; Tue, 9 Oct 2012 04:13:41 -0700 (PDT) Received: from mail3.hpi.uni-potsdam.de (mail3.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17b]) by ietfa.amsl.com (Postfix) with ESMTP id F349F21F84F1; Tue, 9 Oct 2012 04:13:38 -0700 (PDT) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail3.hpi.uni-potsdam.de (Postfix) with ESMTP id 6B774169E7B; Tue, 9 Oct 2012 13:13:33 +0200 (CEST) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Tue, 9 Oct 2012 13:13:33 +0200 From: "Rafiee, Hosnieh" To: "dnsext@ietf.org" Date: Tue, 9 Oct 2012 13:13:32 +0200 Subject: RE: [dnsext] draft-rafiee-cga-tsig-00 - call for more comments Thread-Topic: [dnsext] draft-rafiee-cga-tsig-00 - call for more comments Thread-Index: Ac2lkN6YCNqEW9kdTEm8XD7GV2kI9AAfe1VA Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "DNSOP@ietf.org" , "Int-area@ietf.org" , "v6ops@ietf.org" , "ipv6@ietf.org" , "saag@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 11:13:42 -0000 More ideas and comments would be greatly apprecitated as I want to upload a= new version of my draft RFC in which I will incorporate applicable comment= s. -----Original Message----- From: Rafiee, Hosnieh=20 Sent: Thursday, October 04, 2012 9:28 AM To: 'Mark Andrews' Cc: dnsext@ietf.org Subject: RE: [dnsext] draft-rafiee-cga-tsig-00 - request for comments Thank you, I will change it and move the whole CGA-TSIG DATA inside the Other DATA. -----Original Message----- From: Mark Andrews [mailto:marka@isc.org]=20 Sent: Thursday, October 04, 2012 9:15 AM To: Rafiee, Hosnieh Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-rafiee-cga-tsig-00 - request for comments In message , "Rafiee, Hosnieh" writes: > Hello Mark, > Thank you for your comment. Yes can be,=3D20 But the reason is the TSIG= =20 > parsers need to be adapted with this new algori=3D thm and it is not=20 > different whether to put it in Other DATA or after Other =3D DATA field.= =20 > Because Other Data has variable length too like the CGA-TSIG DA=3D TA. > If I missed something please advise. It is different. Examine the behaviour of CGA-TSIG client talking to a non= CGA-TSIG aware server. The response to using a unknown algorithm should b= e BADKEY not FORMERR because the server couldn't parse the TSIG record. Mark > Thank you. > Hosnieh > -----Original Message----- > From: Mark Andrews [mailto:marka@isc.org]=3D20 > Sent: Thursday, October 04, 2012 8:45 AM > To: Rafiee, Hosnieh > Cc: dnsext@ietf.org > Subject: Re: [dnsext] draft-rafiee-cga-tsig-00 - request for comments >=20 >=20 > Why are the CGA parameters not part of other data? That field was=20 > added to=3D TSIG to hold stuff similar to CGA parameters. By making it= =20 > a seperate fie=3D ld you break all existing TSIG parsers. The CGA=20 > parameters could just be d=3D efined to be the initial part of other data= . >=20 > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From magnus.westerlund@ericsson.com Tue Oct 9 04:20:50 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB56821F8703; Tue, 9 Oct 2012 04:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4reZZRCZ1ets; Tue, 9 Oct 2012 04:20:49 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id BDC5321F86D6; Tue, 9 Oct 2012 04:20:48 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-81-5074088f454a Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id DF.89.17130.F8804705; Tue, 9 Oct 2012 13:20:47 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012 13:20:47 +0200 Message-ID: <5074088E.2020909@ericsson.com> Date: Tue, 9 Oct 2012 13:20:46 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: stbryant@cisco.com Subject: Re: Stewart Bryant's Discuss on draft-ietf-6man-udpchecksums-04: (with DISCUSS and COMMENT) References: <20121008033707.32326.82712.idtracker@ietfa.amsl.com> <5072C744.5020605@ericsson.com> <50730BE1.3010809@cisco.com> In-Reply-To: <50730BE1.3010809@cisco.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+JvrW4/R0mAwaGFGhYLOptYLf73fmO1 +PhsHYvFjD8TmS1enn3PZHHu6RxGBzaPKb83snosWfKTyePL5c9sAcxRXDYpqTmZZalF+nYJ XBmrO3+wFBw1q7g9cQNrA+Nx7S5GTg4JAROJf/evsUDYYhIX7q1n62Lk4hASOMUo8eHmXlYI ZxmjxPo7RxlBqngFtCXuNU5nBrFZBFQkrrxYARZnE7CQuPmjkQ3EFhUIlpi0fwsLRL2gxMmZ T4BsDg4RoA23ZyWDzGQWOM8o8WTqfiaQGmGBNIn5h9aDzRQSqJPYvuU8G0g9p4CmxMRvuhDH SUq8mXwTbCQzULh1+292CFteonnrbKhWbYmGpg7WCYxCs5BsnoWkZRaSlgWMzKsYhXMTM3PS y831Uosyk4uL8/P0ilM3MQKD/uCW3wY7GDfdFzvEKM3BoiTOq6e6319IID2xJDU7NbUgtSi+ qDQntfgQIxMHp1QDo1aWdN3+cK2ASY4zgtfzGGq/vHKuu2TRN934Y++V+u3qgsTrL6sXbFms y7DRYKXF9UIlxYnb3nV9eRSzc/9hzvV3ZN9a2Poy+h+a8vJ8WNmqKf8vfX/zoH5rsGSdfzrX sU+NdVv6plRVPYoPDutw3DJ79ZqltvZCece/unI+YW5muqx3YFPMXyWW4oxEQy3mouJEADQd 1VpIAgAA Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-udpchecksums@tools.ietf.org, "draft-ietf-6man-udpzero@tools.ietf.org" , The IESG , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 11:20:50 -0000 Hi Stewart, Comments inline. On 2012-10-08 19:22, Stewart Bryant wrote: > Hi Magnus, > > On 08/10/2012 13:29, Magnus Westerlund wrote: >> Hi Stewart, >> >> See inline for comments >> >> On 2012-10-08 05:37, Stewart Bryant wrote: >>> Stewart Bryant has entered the following ballot position for >> No, but a tunnel know what general class of traffic it encapsulates. Is >> it IPv4 that has at least IPv4 header checksums and possibly non-zero >> transport checksums, or are they some type of other L2 frames that has >> checksums as part of their frame headers. It is this type of knowledge >> in the tunnel payload we want the tunnel designer to consider if they >> need additional checksums or not. > Sure you know if you are carrying IP or L2, but L2 mostly carries > IP anyway. However you do not actually know what the user > is going to carry over L2, and really have no right to know. You > have to treat it as opaque traffic. > > In any case, as I said we take no precautions in PWs and we do > not observe any issues carrying 'L1' or L2 over PW over MPLS > without a c/s at either the network or the tunnel layer. Are you really certain that PW doesn't have taken precautions. I took a look at RFC 4448 Ethernet over MPLS. That specification contains the following text: 4.4.4. Frame Error Processing An encapsulated Ethernet frame traversing a pseudowire may be dropped, corrupted, or delivered out-of-order. As described in [PWE3-REQ], frame loss, corruption, and out-of-order delivery are considered to be a "generalized bit error" of the pseudowire. PW frames that are corrupted will be detected at the PSN layer and dropped. At the ingress of the PW, the native Ethernet frame error processing mechanisms MUST be enabled. Therefore, if a PE device receives an Ethernet frame containing hardware-level Cyclic Redundancy Check (CRC) errors, framing errors, or a runt condition, the frame MUST be discarded on input. Note that defining this processing is part of the NSP function and is outside the scope of this document. Which I interprets that for an Ethernet PW over MPLS there will be verification of the Ethernets CRC, thus any assembly or payload errors are likely to be detected. This leaves primarily errors in the label addressing on the MPLS layer. What I lack in knowledge is to analyze how likely this is to occur and secondly what the effects are. How likely is it that a miss-labeled ethernet frame actually arrive in a context where it is either harmful to the receiver or actually ends up in some higher layer context not intended. I would guess due to the ethernet addressing an ethernet frame delivered to the wrong physical network will just be discarded due to lack of recipient in the domain it arrived in. I guess other L2 may look different but my understanding is that any PW must fulfill the basic requirements and assumptions on L1 that the carried L2 has. I think few L2 protocols are assuming an error free channel. And those who does requires PW encapsulation to meet these goals. > >> >> >>> In point 7 you suggest that an application cannot rely on packet length. >>> When PWs are used for tunneling we rely on exactly that (except in the >>> case of packets shorter than 64 octets for Ethenet padding reasons), and >>> I am not aware of any reported issues. Thus when the application is >>> tunnel encap/decap there is a body of evidence that suggests that this >>> OK. >> First of all, I would like to understand a bit more about these >> experiences from pseudowires. Which type of psuedowires are we talking >> about here. And the derived experiences over which type of lower layer >> are being used. Is this IPv6/UDP or something else like MPLS? > I am talking about PW/MPLS. Although PW/L2TP/IP exist in theory > there is very little deployment. The most common PWs seem to be > Ethernet (carrying whatever the Ethernet is carrying, IP but other > protocols as well), ATM and TDM. There is also some Frame Relay > (again with c/s removed and reconstructed), in all cases > carried directly over MPLS. The first if it is RFC4448 encapsulated then there is Ethernet layer CRCs that take care of most of the issues as discussed above. The second appear more interesting due to the lack of C/S at that layer. Question is what assumptions the thing on top of frame relay have done. If most of that traffic has checksums then a higher layer verification happens. >> I wished someone would repeat Stone and Patridge's investigation to get >> better understanding of the behaviors of IPv4 and IPv6 in this regards >> at different points in today's Internet. > > My point is that we have a practical experiment ongoing with the > huge number of PWs in deployment running over MPLS without > c/s protection at the tunnel or network layer and I have never seen > anyone raise an issue in either the PWE3 or MPLS WG. Hence > my conclusion that whilst there is a theoretical risk, the evidence > is that there are no reported issues. Well, without more knowledge about what is actually being run I am not certain that you actually are getting data that doesn't have a higher layer protection against errors. > > Note that I am only discussing the tunnel case, I make no comment > on any other type of application. To try to come to some conclusions from my perspective. What you raise as an issue that the formulation may be to strict in regards to using unchecksumed information. I think the examples you have brought up appears to use higher layer checksum to verify the usage of an checksummed field. Nor does it result in accumulation of state. Thus the impact of using such a field are limited to a potential for increased residual errors. It is not like the error rate will be significantly higher due to these assumption errors. I would assume that a packet corruption will in most cases be non reversible, thus the need for a checksum would simply be to avoid propagating the error. But, if you do solutions that uses unverified fields in larger construct the effect amount of data might be larger and thus create significant larger error impact and thus warrant additional checks at lower layer. This have to be analyzed on a protocol to protocol basis. That is the goal of the list. Please be aware of the following and consider if you are impacted by them. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From stbryant@cisco.com Tue Oct 9 05:34:47 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A212821F856C; Tue, 9 Oct 2012 05:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.473 X-Spam-Level: X-Spam-Status: No, score=-110.473 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hLHiI+kwpYl; Tue, 9 Oct 2012 05:34:46 -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 3C7A821F8891; Tue, 9 Oct 2012 05:34:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8858; q=dns/txt; s=iport; t=1349786085; x=1350995685; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=QAXcYI3wHvUZE6NVFApQI8OIfg3HJbXxx39kgnYCqOA=; b=THVWAXjUghCV3R/L4ar5sWRL39WbjaU6R2h+s/JRthRR+EAb6m/YId4+ bByerA68Jx7grYRVDUy87g1HpQ3b8tDEjTmFbKf+RcAzIjLs2unwqFY/F +wetFjvZfQHavC506H3Wx1zGy0B42TOTaPEgAEotzrfQEqPtQuZJC6fKl k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIYZdFCQ/khM/2dsb2JhbABFDr8ggQiCIAEBAQMBEgECIy0CEQEQCxgJFg8JAwIBAgFFEwEFAgEBBQsOh10GC5sPg0oQi3yQPIs5hhMDlWqORYEGZYIyPIFi X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="8637238" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 09 Oct 2012 12:34:29 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q99CYTow026633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Oct 2012 12:34:29 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q99CYN5t010703; Tue, 9 Oct 2012 13:34:25 +0100 (BST) Message-ID: <507419CF.9080103@cisco.com> Date: Tue, 09 Oct 2012 13:34:23 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk Subject: Re: Stewart Bryant's Discuss on draft-ietf-6man-udpzero-06: (with DISCUSS and COMMENT) References: <20121008032619.20138.82801.idtracker@ietfa.amsl.com> <49e67b435262485faab7feffa4497482.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <49e67b435262485faab7feffa4497482.squirrel@www.erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-udpchecksums@tools.ietf.org, draft-ietf-6man-udpzero@tools.ietf.org, The IESG , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 12:34:47 -0000 On 08/10/2012 09:07, gorry@erg.abdn.ac.uk wrote: > Thanks for your comments, see below. > > Gorry > >> Stewart Bryant has entered the following ballot position for >> draft-ietf-6man-udpzero-06: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> This discuss applies to both this draft and >> draft-ietf-6man-udpchecksums-04 >> >> Fundamentally I support the liberalization of the position regarding IPv6 >> UDP checksums when UDP is used for tunnels and hope to get to a yes >> position on both drafts. However, there is some text that needs >> discussion, and then we need to discuss the consequences of that >> discussion. The rational for the slightly conservative position taken in >> the case of tunnels seems to based on the following text: >> >> "IP packets may be corrupted as they traverse an Internet path. >> Evidence has been presented [Sigcomm2000] to show that this was once >> an issue with IPv4 routers, and occasional corruption could result >> from bad internal router processing in routers or hosts. These >> errors are not detected by the strong frame checksums employed at the >> link-layer [RFC3819]. There is no current evidence that such cases >> are rare in the modern Internet, nor that they may not be applicable >> to IPv6. It therefore seems prudent not to relax this constraint. >> The emergence of low-end IPv6 routers and the proposed use of NAT >> with IPv6 further motivate the need to protect from this type of >> error." >> >> However we do have a body of evidence that is not discussed in the >> document. Firstly we have a decade of experience with MPLS VPNs where the >> VPN Identifier label, which is used to steer the traffic to a particular >> customer network (i.e. is functionally equivalent to an address), is not >> protected by a checksum. I am not aware of any concerns expressed by >> operators in this regard, and I am not aware of any work in the MPLS WG >> to introduce checksum like protection. >> > 1) I'm not sure whether you are saying MPLS is robust to these effects > *OR* that MPLS stacks have monitored for this case, e.g. do log such an > unexpected VPN Identifier label, and somehow report this (and hence there > is evidence that MPLS routers do not see such errors) MPLS is not robust against this. If it gets a packet with a valid DL CRC and it finds the VPNid in the label table, the packet gets delivered without further ado. However if it gets delivered to the wrong customer then that is a security violation, and that does not seem to be an issue expressed by the operator or user community, and thus I conclude that the occurrence is not significant. It's implementation specific, but I am fairly sure that unknown VPNid will be counted in most implementations. >> We also have a decade of experience with pseudowires. With one exception >> that we will discuss in a minute, none of the PW designs have any form of >> data integrity protection other than the CRC imposed by the network >> datalink at each hop. In the specific case of the Ethernet PW, there are >> two modes: one in which the CRC is stripped at ingress to the PW and >> recalculated at egress, and another where it is preserved end to end. >> There is very little, if any, deployment of the end to end CRC >> preservation mode. Given that there must be some low level of corruption >> of the frames, I would conclude that the protocols that are likely to be >> tunneled are sufficiently hardened that the occasional corruption is of >> no practical consequence. >> > 2) On acceptability of residual corruption: I think I missed something - > If you are saying that using Ethernet "bridging" is safe at L2, then > that's not this discussion. I am interested in any experience that would > help in understanding the impact of no checksum for IPv6, e.g. experience > in how often the IPv4 checksum and IPv4/UDP checksum fail. To be clear I am only considering the tunneling case not the general case, and note that with the most frequently used tunneling protocol (MPLS) it is unprotected and this does not seem to be causing any issue. > > 3) On practical rate of residual corruption: Is there experience of using > MPLS/PWE across low-end and legacy routers? I am not aware of this, but I > would be really interested in knowing more about the reliability across an > end-to-end path i.e. PWE and MPLS through home gateways, firewalls, > load-balancers, NAT and NAPT. What experience has the community seen? People are looking at low end with a view to pushing MPLS out to closer to the edge of the network, but the concern is with label security rather than label corruption. However there is not much experience with low end boxes. > >> Thus I would conclude that the level of corruption is sufficiently rare >> and of sufficiently minor consequence that at least in the case of >> service provider networks implementing UDP tunneling, it is safe to omit >> the UDP checksum without analysis of the application. >> > 4) I disagree. I would assume so. I suspect because we are looking at different aspect of the problem. > >> I would propose that the text should include some acknowledgement of this >> recent body of evidence and that the recommendation be aligned in >> consequence to unconditionally allow C/S free tunneling, at least within >> a well managed domain without additional consideration. >> > 5) It seems OK to note the new evidence for use within a well-managed > domain, can you supply references to the usage and experience? I have a > question: would the domain include host stacks and end-to-end usage or > just carrier usage? The experience we have is with carrier usage, and we only have (strong) negative evidence. People rarely write reports saying that a system works well (as expected). > >> Section 5.1 seems to be duplicated in the two drafts. It would be better >> if the text were just in one RFC and the other pointed to it. >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> You also note that an application may rely on the checksum to protect it >> against packets that may damage it. I find this very weak argument, since >> such an application would be vulnerable to packets deliberately malformed >> by an attacker, or malformed by a software bug in a peer. The correct >> approach is surely to harden the application, and thus the checksum >> argument is not persuasive. >> > 6) I'm surprised/misunderstood - many deployed uses of the UDP transport > have relied on the UDP cksum (more latterly this not been the advice of > the IETF, but hard to enforce). Is this suggesting the IETF actually > declare these (existing deployed IPv4) apps as unsuitable for use with > IPv6 over the general Internet. That's NOT something I would personally > like to do, have I understood correctly? No, but your argument is non-the-less weak. If the only thing holding the app from melting is the UDP c/s, then it really needs some security hardening. > >> You note the need to signal the agreement not to use c/s, I think that >> you need to include the configuration of this property as an alternative, >> and note that configuration may be implicit in the definition of the UDP >> payload. >> > 7) The intent was not to change the semantic of the cksum for apps that > expected the original behaviour. If you have an app that is willing to use > no cksum - such as the tunnels - this may be fine, then I see two > possibilities: It works (e.g. within a carrier network) or it may fail > (e.g. via a NAPT/firewall that recalculates a cksum). I think it would be > "nice" for the "app" to know it has UDP connectivity, but no UDP zero > cksum connectivity - i.e. not just break when a route changes or a user > moves to a new network. What do you suggest apps should do? > By definition an app does not know that it is being tunneled. If the app wants to set the c/s in the UDP header that it requests from the host stack, that is something that I actively support. However the path over the network once it leaves that stack (including tunneling in the host itself) is not something that it should know or care about. - Stewart From stbryant@cisco.com Tue Oct 9 05:44:01 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8F021F86CA; Tue, 9 Oct 2012 05:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+UymT6ZgxIm; Tue, 9 Oct 2012 05:44:00 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 707D021F86C3; Tue, 9 Oct 2012 05:44:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2271; q=dns/txt; s=iport; t=1349786640; x=1350996240; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ZtUrJyur3zB1alIRe2ElSMUFTa2JlEGqUPSW2+zfB3E=; b=VpftBnCho8gXHS5QxpaXp9tqseXhKaIgJYL+ulWu8NnB1klARcgFqvsq rIXOnbGnqaLZyjUqj72RMYNOmwpEzi3oCPZDmNRRaEzMXxveq+wh0KxHR ihIcwthsQ8ZqXlPmXPtoX3z7VYQdzh4phHnuYjST8I1qKYgcMFx7baadk Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABcbdFCQ/khM/2dsb2JhbABFvy6BCIIgAQEBBBIBAh0BBUABEAsOCgkWDwkDAgECAUUGDQEFAgEBEA6HY5sig0oQi3yQPIs5hhMDlWqORYEGZYJu X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="8646993" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 09 Oct 2012 12:43:59 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q99ChwQ5029277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Oct 2012 12:43:59 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q99Chrh1011321; Tue, 9 Oct 2012 13:43:54 +0100 (BST) Message-ID: <50741C08.9000904@cisco.com> Date: Tue, 09 Oct 2012 13:43:52 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Carsten Bormann Subject: Re: Stewart Bryant's Discuss on draft-ietf-6man-udpchecksums-04: (with DISCUSS and COMMENT) References: <20121008033707.32326.82712.idtracker@ietfa.amsl.com> <5072C744.5020605@ericsson.com> <50730BE1.3010809@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, draft-ietf-6man-udpchecksums@tools.ietf.org, draft-ietf-6man-udpzero@ietfa.amsl.com, The IESG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 12:44:02 -0000 On 08/10/2012 19:13, Carsten Bormann wrote: > On Oct 8, 2012, at 19:22, Stewart Bryant wrote: > >> My point is that we have a practical experiment ongoing with the >> huge number of PWs in deployment running over MPLS without >> c/s protection at the tunnel or network layer and I have never seen >> anyone raise an issue in either the PWE3 or MPLS WG. Hence >> my conclusion that whilst there is a theoretical risk, the evidence >> is that there are no reported issues. > One reason the occasional misdirected packet is not causing problems here might be that there are higher level headers that prevent delivery to an application (be it for a checksum mismatch or more likely because the higher level addresses just don't point in the direction of trouble). Which would mesh fine with the argument made in the draft that UDP zero checksum is fine for tunnels but not so much for other applications like end-to-end. > > I definitely agree with the subtext that the udpzero issue is often seen a bit more dogmatic than needs be, but I also think that having this degree of robustness in a widely deployed protocol is a desirable property that shouldn't be given up lightly. > > Grüße, Carsten Carsten I think you are correct the few packets that have errors and actually get delivered probably then either get caught by the packet parser, or hit an idempotent system that corrects the state based on a later packet or local state. Let's look at this from another perspective for a moment. The tunnel use of UDP is really "GRE that goes through firewalls and gets ECMPed". GRE has no c/s and as far as I know has no c/s added for IPv6 and thus is subject to the same issues that we are talking about here. What is going to happen in practice is that the tunnel implementers are all going to say (for reasons in the text) that c/s is too hard, we will not do c/s and the application had better look after itself. You can see this is what is happening in LISP, which is one of the protocols that triggered this document pair. Thus my goal here is to align the text with actually is happening and is likely to continue to happen, since I think that benefits the community in the long term. - Stewart From martin.stiemerling@neclab.eu Tue Oct 9 05:44:53 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE5821F86EE; Tue, 9 Oct 2012 05:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZIL+tZC-b1F; Tue, 9 Oct 2012 05:44:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0DC221F86DA; Tue, 9 Oct 2012 05:44:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Martin Stiemerling" To: The IESG Subject: Martin Stiemerling's No Objection on draft-ietf-6man-dad-proxy-05: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121009124452.17507.47275.idtracker@ietfa.amsl.com> Date: Tue, 09 Oct 2012 05:44:52 -0700 Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-dad-proxy@tools.ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 12:44:53 -0000 Martin Stiemerling has entered the following ballot position for draft-ietf-6man-dad-proxy-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) I have no general concern about the publication of the draft, but I doubt that it is for the Internet in general. = It is more adding support for a very specific set of deployments, e.g., DSL access networks. = This is somehow stated in the abstract "point-to-multipoint architecture with "split-horizon" forwarding scheme." but it is hard to understand and the proposed solution probably does not work in other settings that use the same description or claim similar ground. = Can we add a more specific wording right upfront that this is primarly for "Digital Subscriber Line (DSL) and Fiber access architectures" as noted in Section 2? This would also be inline with the rest of the document which uses very specific terminology out of broadband access networks, e.g., BNG. The Internet itself does not has BNGs, but routers or first hop routers (AKA BNG in this context) Also in this context: Section 3.2., paragraph 3: > As the BNG must not forward link-local scoped messages sent from a > CPE to other CPEs, ND Proxy cannot be implemented in the BNG. This seems to be the restriction of a very specific deployment scenario, but is not a limitation per se. Other people could allow this in their architecture. 2) Section 4.1., paragraph 1: > A BNG needs to store in a Binding Table information related to the > IPv6 addresses generated by any CPE. This Binding Table MAY be > distinct from the Neighbor Cache. This must be done per point to This 'MAY' does not look correct here, but a 'can' would just do the job, as this is implementation specific, isn't it? 3) Appendix A., paragraph 1: > This appendix contains a summary (cf. Table 1) of the actions done by > the BNG when it receives a DAD based NS (DAD-NS) message. The > tentative address in this message is IPv6-CPE1 and the associated > Link-layer address is Link-layer-CPE2. The actions are precisely > specified in Section 4.2. Is this appendix normative or not? What takes precedence: the text or the table? From adrian@olddog.co.uk Tue Oct 9 05:46:52 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6175A1F0C8C; Tue, 9 Oct 2012 05:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwNhnVK5w33M; Tue, 9 Oct 2012 05:46:43 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 6B84C21F86D6; Tue, 9 Oct 2012 05:46:43 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q99CkbaV003473; Tue, 9 Oct 2012 13:46:37 +0100 Received: from 950129200 ([74.125.61.190]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q99Ckanl003457 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Oct 2012 13:46:37 +0100 From: "Adrian Farrel" To: , Subject: RE: Stewart Bryant's Discuss on draft-ietf-6man-udpzero-06: (with DISCUSS and COMMENT) Date: Tue, 9 Oct 2012 13:46:38 +0100 Message-ID: <013e01cda61c$1ff13910$5fd3ab30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2mG/3dYkBsmz6oTkOKfg4S2hXZYg== Content-Language: en-gb Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-udpchecksums@tools.ietf.org, draft-ietf-6man-udpzero@tools.ietf.org, 'The IESG' , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 12:46:52 -0000 Are we in the weeds yet? One thing about MPLS is that it is not substantially run as a native layer 2 encapsulation. The result is that it is usually MPLSoE or similar (even when the LSP is being used to carry Ethernet). The data link thus usually provides some form of robustness such as CRC that protects the packet on the wire. So we are left with random hits on packets inside router buffers, or subverted/malicious routers. Hence MPLS seems to be considered safe at the moment. It is unclear what will happen when/if MPLS is used as a native layer 2. Maybe, however, MPLSoLambda will use its own FCS perhaps provided by GFP. Adrian > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of > Stewart Bryant > Sent: 09 October 2012 13:34 > To: gorry@erg.abdn.ac.uk > Cc: 6man-chairs@tools.ietf.org; draft-ietf-6man-udpchecksums@tools.ietf.org; > draft-ietf-6man-udpzero@tools.ietf.org; The IESG; ipv6@ietf.org > Subject: Re: Stewart Bryant's Discuss on draft-ietf-6man-udpzero-06: (with > DISCUSS and COMMENT) > > On 08/10/2012 09:07, gorry@erg.abdn.ac.uk wrote: > > Thanks for your comments, see below. > > > > Gorry > > > >> Stewart Bryant has entered the following ballot position for > >> draft-ietf-6man-udpzero-06: Discuss > >> > >> When responding, please keep the subject line intact and reply to all > >> email addresses included in the To and CC lines. (Feel free to cut this > >> introductory paragraph, however.) > >> > >> > >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > >> for more information about IESG DISCUSS and COMMENT positions. > >> > >> > >> ---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> This discuss applies to both this draft and > >> draft-ietf-6man-udpchecksums-04 > >> > >> Fundamentally I support the liberalization of the position regarding IPv6 > >> UDP checksums when UDP is used for tunnels and hope to get to a yes > >> position on both drafts. However, there is some text that needs > >> discussion, and then we need to discuss the consequences of that > >> discussion. The rational for the slightly conservative position taken in > >> the case of tunnels seems to based on the following text: > >> > >> "IP packets may be corrupted as they traverse an Internet path. > >> Evidence has been presented [Sigcomm2000] to show that this was once > >> an issue with IPv4 routers, and occasional corruption could result > >> from bad internal router processing in routers or hosts. These > >> errors are not detected by the strong frame checksums employed at the > >> link-layer [RFC3819]. There is no current evidence that such cases > >> are rare in the modern Internet, nor that they may not be applicable > >> to IPv6. It therefore seems prudent not to relax this constraint. > >> The emergence of low-end IPv6 routers and the proposed use of NAT > >> with IPv6 further motivate the need to protect from this type of > >> error." > >> > >> However we do have a body of evidence that is not discussed in the > >> document. Firstly we have a decade of experience with MPLS VPNs where the > >> VPN Identifier label, which is used to steer the traffic to a particular > >> customer network (i.e. is functionally equivalent to an address), is not > >> protected by a checksum. I am not aware of any concerns expressed by > >> operators in this regard, and I am not aware of any work in the MPLS WG > >> to introduce checksum like protection. > >> > > 1) I'm not sure whether you are saying MPLS is robust to these effects > > *OR* that MPLS stacks have monitored for this case, e.g. do log such an > > unexpected VPN Identifier label, and somehow report this (and hence there > > is evidence that MPLS routers do not see such errors) > MPLS is not robust against this. If it gets a packet with a valid DL CRC > and it finds the VPNid in the label table, the packet gets delivered > without further ado. However if it gets delivered to the wrong customer > then that is a security violation, and that does not seem to be an > issue expressed by the operator or user community, and thus I conclude > that the occurrence is not significant. > > It's implementation specific, but I am fairly sure that unknown VPNid will > be counted in most implementations. > > >> We also have a decade of experience with pseudowires. With one exception > >> that we will discuss in a minute, none of the PW designs have any form of > >> data integrity protection other than the CRC imposed by the network > >> datalink at each hop. In the specific case of the Ethernet PW, there are > >> two modes: one in which the CRC is stripped at ingress to the PW and > >> recalculated at egress, and another where it is preserved end to end. > >> There is very little, if any, deployment of the end to end CRC > >> preservation mode. Given that there must be some low level of corruption > >> of the frames, I would conclude that the protocols that are likely to be > >> tunneled are sufficiently hardened that the occasional corruption is of > >> no practical consequence. > >> > > 2) On acceptability of residual corruption: I think I missed something - > > If you are saying that using Ethernet "bridging" is safe at L2, then > > that's not this discussion. I am interested in any experience that would > > help in understanding the impact of no checksum for IPv6, e.g. experience > > in how often the IPv4 checksum and IPv4/UDP checksum fail. > To be clear I am only considering the tunneling case not the general case, > and note that with the most frequently used tunneling protocol (MPLS) > it is unprotected and this does not seem to be causing any issue. > > > > 3) On practical rate of residual corruption: Is there experience of using > > MPLS/PWE across low-end and legacy routers? I am not aware of this, but I > > would be really interested in knowing more about the reliability across an > > end-to-end path i.e. PWE and MPLS through home gateways, firewalls, > > load-balancers, NAT and NAPT. What experience has the community seen? > People are looking at low end with a view to pushing MPLS out to > closer to the edge of the network, but the concern is with label > security rather than label corruption. However there is not much > experience with low end boxes. > > > >> Thus I would conclude that the level of corruption is sufficiently rare > >> and of sufficiently minor consequence that at least in the case of > >> service provider networks implementing UDP tunneling, it is safe to omit > >> the UDP checksum without analysis of the application. > >> > > 4) I disagree. > I would assume so. I suspect because we are looking at different > aspect of the problem. > > > >> I would propose that the text should include some acknowledgement of this > >> recent body of evidence and that the recommendation be aligned in > >> consequence to unconditionally allow C/S free tunneling, at least within > >> a well managed domain without additional consideration. > >> > > 5) It seems OK to note the new evidence for use within a well-managed > > domain, can you supply references to the usage and experience? I have a > > question: would the domain include host stacks and end-to-end usage or > > just carrier usage? > The experience we have is with carrier usage, and we only have (strong) > negative evidence. People rarely write reports saying that a system works > well (as expected). > > > > >> Section 5.1 seems to be duplicated in the two drafts. It would be better > >> if the text were just in one RFC and the other pointed to it. > >> > >> > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> You also note that an application may rely on the checksum to protect it > >> against packets that may damage it. I find this very weak argument, since > >> such an application would be vulnerable to packets deliberately malformed > >> by an attacker, or malformed by a software bug in a peer. The correct > >> approach is surely to harden the application, and thus the checksum > >> argument is not persuasive. > >> > > 6) I'm surprised/misunderstood - many deployed uses of the UDP transport > > have relied on the UDP cksum (more latterly this not been the advice of > > the IETF, but hard to enforce). Is this suggesting the IETF actually > > declare these (existing deployed IPv4) apps as unsuitable for use with > > IPv6 over the general Internet. That's NOT something I would personally > > like to do, have I understood correctly? > No, but your argument is non-the-less weak. If the only thing holding > the app from melting is the UDP c/s, then it really needs some > security hardening. > > > > >> You note the need to signal the agreement not to use c/s, I think that > >> you need to include the configuration of this property as an alternative, > >> and note that configuration may be implicit in the definition of the UDP > >> payload. > >> > > 7) The intent was not to change the semantic of the cksum for apps that > > expected the original behaviour. If you have an app that is willing to use > > no cksum - such as the tunnels - this may be fine, then I see two > > possibilities: It works (e.g. within a carrier network) or it may fail > > (e.g. via a NAPT/firewall that recalculates a cksum). I think it would be > > "nice" for the "app" to know it has UDP connectivity, but no UDP zero > > cksum connectivity - i.e. not just break when a route changes or a user > > moves to a new network. What do you suggest apps should do? > > > By definition an app does not know that it is being tunneled. > If the app wants to set the c/s in the UDP header that it requests from > the host stack, that is something that I actively support. However > the path over the network once it leaves that stack (including > tunneling in the host itself) is not something that it should know > or care about. > > - Stewart From brian@innovationslab.net Tue Oct 9 05:56:19 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B602021F865B; Tue, 9 Oct 2012 05:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.37 X-Spam-Level: X-Spam-Status: No, score=-102.37 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zexmbxyL0H3A; Tue, 9 Oct 2012 05:56:19 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4B60D21F8615; Tue, 9 Oct 2012 05:56:19 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id BBAC088090; Tue, 9 Oct 2012 05:56:18 -0700 (PDT) Received: from Littlejohn.local (c-69-140-213-249.hsd1.md.comcast.net [69.140.213.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id D1194140039; Tue, 9 Oct 2012 05:56:17 -0700 (PDT) Message-ID: <50741EF0.9000208@innovationslab.net> Date: Tue, 09 Oct 2012 08:56:16 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: adrian@olddog.co.uk Subject: Re: Stewart Bryant's Discuss on draft-ietf-6man-udpzero-06: (with DISCUSS and COMMENT) References: <013e01cda61c$1ff13910$5fd3ab30$@olddog.co.uk> In-Reply-To: <013e01cda61c$1ff13910$5fd3ab30$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, draft-ietf-6man-udpchecksums@tools.ietf.org, 'The IESG' , draft-ietf-6man-udpzero@tools.ietf.org, stbryant@cisco.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 12:56:19 -0000 On 10/9/12 8:46 AM, Adrian Farrel wrote: > Are we in the weeds yet? I believe we are. > > One thing about MPLS is that it is not substantially run as a native layer 2 > encapsulation. The result is that it is usually MPLSoE or similar (even when the > LSP is being used to carry Ethernet). The data link thus usually provides some > form of robustness such as CRC that protects the packet on the wire. So we are > left with random hits on packets inside router buffers, or subverted/malicious > routers. Agreed. As long as there is a robust L-2, the chance of in-transit errors is low. If MPLS is predominantly carried over Ethernet, I suspect the Ethernet CRC is providing sufficient/significant protection. > > Hence MPLS seems to be considered safe at the moment. > > It is unclear what will happen when/if MPLS is used as a native layer 2. Maybe, > however, MPLSoLambda will use its own FCS perhaps provided by GFP. Agree as well. > > Adrian > Regards, Brian From stbryant@cisco.com Tue Oct 9 06:40:26 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E81D21F85F4; Tue, 9 Oct 2012 06:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcVm0u54E4qc; Tue, 9 Oct 2012 06:40:25 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF8521F8540; Tue, 9 Oct 2012 06:40:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8712; q=dns/txt; s=iport; t=1349790024; x=1350999624; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=D+Lax+cl7agslVcPX1oSIK6z8of7iXT4D/NXRnsSYUs=; b=JmIgijgHVIoEvSaejb2Avcrd2TMk15Riro/8FNOGr8ZqK2SLd/nrrNkM vUoTSY4l9mLlzprHpZ6p8KqmNXw7DNnnKFy1zaMLOSKxt6X1YMnOJDVDI VhMSHaiV2izrXe5ZE6rwVK3hznkfRw9dbM0TPzoOQIt3HFvTlEVFTsLFr Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFADAodFCQ/khL/2dsb2JhbABFhhG1Y4M6gQiCIAEBAQMBEgECDhUvEQEFCwsYAgIFFgsCAgkDAgECAUUGDQEHAQEQBweHXQabOINKEIlBgjuQPIEhihgUhG2BEgOSOYMxjkWBBmWCboFZ X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="8649486" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 09 Oct 2012 13:40:23 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q99DeMxw015351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Oct 2012 13:40:23 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q99DeH4Q014964; Tue, 9 Oct 2012 14:40:19 +0100 (BST) Message-ID: <50742941.1020108@cisco.com> Date: Tue, 09 Oct 2012 14:40:17 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: Stewart Bryant's Discuss on draft-ietf-6man-udpchecksums-04: (with DISCUSS and COMMENT) References: <20121008033707.32326.82712.idtracker@ietfa.amsl.com> <5072C744.5020605@ericsson.com> <50730BE1.3010809@cisco.com> <5074088E.2020909@ericsson.com> In-Reply-To: <5074088E.2020909@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-udpchecksums@tools.ietf.org, "draft-ietf-6man-udpzero@tools.ietf.org" , The IESG , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 13:40:26 -0000 On 09/10/2012 12:20, Magnus Westerlund wrote: > Hi Stewart, > > Comments inline. > > On 2012-10-08 19:22, Stewart Bryant wrote: >> Hi Magnus, >> >> On 08/10/2012 13:29, Magnus Westerlund wrote: >>> Hi Stewart, >>> >>> See inline for comments >>> >>> On 2012-10-08 05:37, Stewart Bryant wrote: >>>> Stewart Bryant has entered the following ballot position for >>> No, but a tunnel know what general class of traffic it encapsulates. Is >>> it IPv4 that has at least IPv4 header checksums and possibly non-zero >>> transport checksums, or are they some type of other L2 frames that has >>> checksums as part of their frame headers. It is this type of knowledge >>> in the tunnel payload we want the tunnel designer to consider if they >>> need additional checksums or not. >> Sure you know if you are carrying IP or L2, but L2 mostly carries >> IP anyway. However you do not actually know what the user >> is going to carry over L2, and really have no right to know. You >> have to treat it as opaque traffic. >> >> In any case, as I said we take no precautions in PWs and we do >> not observe any issues carrying 'L1' or L2 over PW over MPLS >> without a c/s at either the network or the tunnel layer. > Are you really certain that PW doesn't have taken precautions. I took a > look at RFC 4448 Ethernet over MPLS. That specification contains the > following text: > > 4.4.4. Frame Error Processing > > An encapsulated Ethernet frame traversing a pseudowire may be > dropped, corrupted, or delivered out-of-order. As described in > [PWE3-REQ], frame loss, corruption, and out-of-order delivery are > considered to be a "generalized bit error" of the pseudowire. PW > frames that are corrupted will be detected at the PSN layer and > dropped. This is saying that Ethernet frames may be delivered out of order and that if we get a CRC failure in the PSN we will simple drop the packet. > > At the ingress of the PW, the native Ethernet frame error processing > mechanisms MUST be enabled. Therefore, if a PE device receives an > Ethernet frame containing hardware-level Cyclic Redundancy Check > (CRC) errors, framing errors, or a runt condition, the frame MUST be > discarded on input. Note that defining this processing is part of > the NSP function and is outside the scope of this document. > > Which I interprets that for an Ethernet PW over MPLS there will be > verification of the Ethernets CRC, At ingress only. The CRC is then discarded. There was no CRC retention mode when RFC4448 was written. > thus any assembly or payload errors > are likely to be detected. No, there is no assembly. RFC4448 describes Ethernet PW over MPLS and MPLS has no fragmentation. > This leaves primarily errors in the label > addressing on the MPLS layer. They exist, but if the payload gets corrupted in a PE or an LSR packet buffer, it stays corrupted and gets played out with a good CRC. > What I lack in knowledge is to analyze how > likely this is to occur and secondly what the effects are. How likely is > it that a miss-labeled ethernet frame actually arrive in a context where > it is either harmful to the receiver or actually ends up in some higher > layer context not intended. I would guess due to the ethernet addressing > an ethernet frame delivered to the wrong physical network will just be > discarded due to lack of recipient in the domain it arrived in. Yes, there is some protection due to the Ethernet addressing, but not all PWs have this. Frame Relay for example reconstructs the DLCI at egress. > > I guess other L2 may look different but my understanding is that any PW > must fulfill the basic requirements and assumptions on L1 that the > carried L2 has. I think few L2 protocols are assuming an error free > channel. And those who does requires PW encapsulation to meet these goals. The PWE3 WG has some pretty blunt advice to it's user community. We explain the simplifications, and if the quality of emulation is not good enough, then the user is advised to either design a better emulation, or to use a real service. However so far the cost efficiencies of the extremely simple emulations, combined with the low error rate and relatively hard applications have meant that the simple emulations are overwhelmingly used. My prediction is that this will be the case for the UDP as a tunnel class of applications. > >>> >>>> In point 7 you suggest that an application cannot rely on packet length. >>>> When PWs are used for tunneling we rely on exactly that (except in the >>>> case of packets shorter than 64 octets for Ethenet padding reasons), and >>>> I am not aware of any reported issues. Thus when the application is >>>> tunnel encap/decap there is a body of evidence that suggests that this >>>> OK. >>> First of all, I would like to understand a bit more about these >>> experiences from pseudowires. Which type of psuedowires are we talking >>> about here. And the derived experiences over which type of lower layer >>> are being used. Is this IPv6/UDP or something else like MPLS? >> I am talking about PW/MPLS. Although PW/L2TP/IP exist in theory >> there is very little deployment. The most common PWs seem to be >> Ethernet (carrying whatever the Ethernet is carrying, IP but other >> protocols as well), ATM and TDM. There is also some Frame Relay >> (again with c/s removed and reconstructed), in all cases >> carried directly over MPLS. > The first if it is RFC4448 encapsulated then there is Ethernet layer > CRCs that take care of most of the issues as discussed above. No, there is no Ethernet CRC in an RFC4448 encapsulated packet. Please see RFC4720, which states it more clearly. Noting that RFC4720 is hardly implemented. > The second appear more interesting due to the lack of C/S at that layer. > Question is what assumptions the thing on top of frame relay have done. > If most of that traffic has checksums then a higher layer verification > happens. The applications just see the datalink as a datalink, and don't realize they are being sent over a PW, or understand what the PW is doing to the datalink CRC. > > > >>> I wished someone would repeat Stone and Patridge's investigation to get >>> better understanding of the behaviors of IPv4 and IPv6 in this regards >>> at different points in today's Internet. >> My point is that we have a practical experiment ongoing with the >> huge number of PWs in deployment running over MPLS without >> c/s protection at the tunnel or network layer and I have never seen >> anyone raise an issue in either the PWE3 or MPLS WG. Hence >> my conclusion that whilst there is a theoretical risk, the evidence >> is that there are no reported issues. > Well, without more knowledge about what is actually being run I am not > certain that you actually are getting data that doesn't have a higher > layer protection against errors. Sure, that is what is keeping the system afloat against the error, but that is also true of L2 and L3 protocols tunneled over UDP. > >> Note that I am only discussing the tunnel case, I make no comment >> on any other type of application. > To try to come to some conclusions from my perspective. What you raise > as an issue that the formulation may be to strict in regards to using > unchecksumed information. I think the examples you have brought up > appears to use higher layer checksum to verify the usage of an > checksummed field. No, the deployed PW/MPLS cases run without a datalink CRC. > Nor does it result in accumulation of state. Thus > the impact of using such a field are limited to a potential for > increased residual errors. It is not like the error rate will be > significantly higher due to these assumption errors. I would assume that > a packet corruption will in most cases be non reversible, thus the need > for a checksum would simply be to avoid propagating the error. > > But, if you do solutions that uses unverified fields in larger construct > the effect amount of data might be larger and thus create significant > larger error impact and thus warrant additional checks at lower layer. > This have to be analyzed on a protocol to protocol basis. > > That is the goal of the list. Please be aware of the following and > consider if you are impacted by them. Understand that at the end of the day, I am not going to stand in the way of the draft, what I am trying to do here is to help it reflect the reality of existing tunnel experience and to be closer to the path that the UDP tunnel designer's appear to be taking anyway. - Stewart From stbryant@cisco.com Tue Oct 9 06:45:12 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30DB1F0C5F; Tue, 9 Oct 2012 06:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.169 X-Spam-Level: X-Spam-Status: No, score=-110.169 tagged_above=-999 required=5 tests=[AWL=-0.429, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toH377Q89dW1; Tue, 9 Oct 2012 06:45:11 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1665C21F865B; Tue, 9 Oct 2012 06:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1219; q=dns/txt; s=iport; t=1349790311; x=1350999911; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=0QtJZd+CV9kyRHnNTxFZCdeIlt5UKecvIC1On7iFFOU=; b=UAoAz+ONL2+KIEaJGZECY4oe3syFh82if1eQqcY8GusN3yy7QDIAgyUk bTzYrgs9f99aW6MA3kg4nRftAC95SoTi9Y57XZDTvH63kJk8lIBwJrUBe 5HmKH2O8baX73dh97dIDwb7WCiFuidlWE+m6Ly2FUAtmUaow7TMrJWLdJ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPgpdFCQ/khR/2dsb2JhbABFu3SDOoEIgiABAQEEEgECIy8SEAsYCSUPAkYGDQEHAQEeh2ObOYNKEIt8kDyLOYYTA5VqjkWBBmWCbg X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="77302556" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 09 Oct 2012 13:45:09 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q99Dj9pS031062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Oct 2012 13:45:09 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q99Dj3FZ015171; Tue, 9 Oct 2012 14:45:05 +0100 (BST) Message-ID: <50742A5F.90309@cisco.com> Date: Tue, 09 Oct 2012 14:45:03 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Brian Haberman Subject: Re: Stewart Bryant's Discuss on draft-ietf-6man-udpzero-06: (with DISCUSS and COMMENT) References: <013e01cda61c$1ff13910$5fd3ab30$@olddog.co.uk> <50741EF0.9000208@innovationslab.net> In-Reply-To: <50741EF0.9000208@innovationslab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-6man-udpchecksums@tools.ietf.org, ipv6@ietf.org, 'The IESG' , adrian@olddog.co.uk, draft-ietf-6man-udpzero@tools.ietf.org, 6man-chairs@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 13:45:12 -0000 On 09/10/2012 13:56, Brian Haberman wrote: >> >> One thing about MPLS is that it is not substantially run as a native >> layer 2 >> encapsulation. The result is that it is usually MPLSoE or similar >> (even when the >> LSP is being used to carry Ethernet). The data link thus usually >> provides some >> form of robustness such as CRC that protects the packet on the wire. >> So we are >> left with random hits on packets inside router buffers, or >> subverted/malicious >> routers. > > Agreed. As long as there is a robust L-2, the chance of in-transit > errors is low. If MPLS is predominantly carried over Ethernet, I > suspect the Ethernet CRC is providing sufficient/significant protection. > >> >> Hence MPLS seems to be considered safe at the moment. >> >> It is unclear what will happen when/if MPLS is used as a native layer >> 2. Maybe, >> however, MPLSoLambda will use its own FCS perhaps provided by GFP. > > Agree as well. > >> >> Adrian >> I agree with the above, but it is even more applicable to the UDP tunneling case, since the stack will normally be datalink(CRC)/IPv6/UDP/Payload, and IPv6oLambda is not AFAICS on anyone's radar. Stewart S From rdroms.ietf@gmail.com Tue Oct 9 06:47:28 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6F221F870F; Tue, 9 Oct 2012 06:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.34 X-Spam-Level: X-Spam-Status: No, score=-102.34 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDEmP9Rq8qkD; Tue, 9 Oct 2012 06:47:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7870521F859A; Tue, 9 Oct 2012 06:47:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Ralph Droms" To: The IESG Subject: Ralph Droms' No Objection on draft-ietf-6man-udpzero-06: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121009134728.14083.47245.idtracker@ietfa.amsl.com> Date: Tue, 09 Oct 2012 06:47:28 -0700 Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, draft-ietf-6man-udpzero@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 13:47:28 -0000 Ralph Droms has entered the following ballot position for draft-ietf-6man-udpzero-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In section 4.1, is there a reference to the "proposal to simply ignore the UDP checksum value on reception at the tunnel egress" that can be cited to give more background? In section 4.2.1, "The methods that ignores the checksum has an additional downside" needs to be plural or singular throughout. The first paragraph of section 5 tells me it identifies requirements for protocols carried without UDP checksum. Section 5.1 talks only about "zero checksum"; does the proposal to ignore the checksum at the tunnel egress also fit here? Also, stylistically, I think the section header for 5.1 can simply be dropped. In section 5.1, I can't parse out what list item 5 is trying to convey. What is the "tunnel layer" and is it always recommended and required for some tunnel mechanisms? From jhw@apple.com Tue Oct 9 11:10:30 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB56A21F87F2 for ; Tue, 9 Oct 2012 11:10:30 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfAM7fDwk8o1 for ; Tue, 9 Oct 2012 11:10:30 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 033FB21F87E6 for ; Tue, 9 Oct 2012 11:10:30 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0MBN00BYM157J8X5@mail-out.apple.com> for ipv6@ietf.org; Tue, 09 Oct 2012 11:10:29 -0700 (PDT) X-AuditID: 11807134-b7fb46d00000395a-71-50746849768b Received: from fenugreek.apple.com (fenugreek.apple.com [17.128.115.97]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id 48.78.14682.94864705; Tue, 09 Oct 2012 11:09:13 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by fenugreek.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MBN00KV513B6A60@fenugreek.apple.com> for ipv6@ietf.org; Tue, 09 Oct 2012 11:09:13 -0700 (PDT) Subject: Re: 6MAN WG Last Call: From: james woodyatt In-reply-to: <67F311F3-363E-4870-A3AD-643BFC6D2978@gmail.com> Date: Tue, 09 Oct 2012 11:09:10 -0700 Message-id: References: <67F311F3-363E-4870-A3AD-643BFC6D2978@gmail.com> To: IETF IPv6 X-Mailer: Apple Mail (2.1499) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUi2FCcqDs1oyTA4MtVRouXZ98zOTB6LFny kymAMYrLJiU1J7MstUjfLoErY8uZDWwFx9gqjlxbxdbA+IOli5GTQ0LAROJZw3Q2CFtM4sK9 9UA2F4eQwAwmiQMfZzNBOLOZJD58a2EGqWIW0JHo/f4NyObg4BXQk5i0PwgkLCzgK/Fl/lSw EjYBFYlvl+8ygdicArYSE/sgbBYBVYmva5rZIcZoSzx5d4EVYoyNxNzjuiBhISDz7JTPYPeI CMhK7N90Ceo2WYkVU3uZJjDyz0JyxCyEI2YhGbqAkXkVo2BRak5ipaGJXmJBQU6qXnJ+7iZG cHgVmuxgPPiT/xCjAAejEg+vZHxJgBBrYllxZe4hRgkOZiUR3v32QCHelMTKqtSi/Pii0pzU 4kOM0hwsSuK8fhuKA4QE0hNLUrNTUwtSi2CyTBycUg2M3Ns9E7nva/96ViNUWvFG+ALbnDdr OrhWCf17K/yYk+Fnwvpf56bOS7/t8ZnVK/FB1P6j7HdXHZu34MXBFV8O8R+vlJxTH/ZlYpW3 UH3gVmuBuJ6boU/nbXNx+Ch0eFlX36r2/w+0zy6/vfuU19FtkwX0rOV1C93MiubNuLIrUbd6 15PemO0ii5VYijMSDbWYi4oTAbIeCIArAgAA X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 18:10:30 -0000 On Oct 4, 2012, at 14:53 , Bob Hinden wrote: > > This message starts a two week 6MAN Working Group on advancing: > > Title : Security Implications of the Use of IPv6 Extension Headers with IPv6 Neighbor Discovery > Author(s) : Fernando Gont > Filename : draft-ietf-6man-nd-extension-headers-00.txt > Pages : 12 > Date : 2012-06-29 > > http://tools.ietf.org/html/draft-ietf-6man-nd-extension-headers-00 > > as Proposed Standard. Substantive comments and statements of support for advancing this document should be directed to the mailing list. Editorial suggestions can be sent to the authors. This last call will end on 18 October 2012. I support. -- james woodyatt core os networking From rbonica@juniper.net Tue Oct 9 11:57:26 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E193A11E80C5; Tue, 9 Oct 2012 11:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aC1Rp0lNS80O; Tue, 9 Oct 2012 11:57:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B2111E808A; Tue, 9 Oct 2012 11:57:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Ronald Bonica" To: The IESG Subject: Ronald Bonica's Discuss on draft-ietf-6man-udpzero-06: (with DISCUSS) X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121009185726.29097.69699.idtracker@ietfa.amsl.com> Date: Tue, 09 Oct 2012 11:57:26 -0700 Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, draft-ietf-6man-udpzero@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 18:57:27 -0000 Ronald Bonica has entered the following ballot position for draft-ietf-6man-udpzero-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is a two-part DISCUSS-DISCUSS. Both parts relate to bullet points in Section 5.1. Bullet 5 =3D=3D=3D=3D=3D=3D "Tunnels that encapsulate IP may rely on the inner packet integrity checks provided that the tunnel will not significantly increase the rate of corruption of the inner IP packet." - What does it mean to *significantly* increase the rate of corruption of the inner IP packet? - Shouldn't we also be concerned about corruption of the UDP header and any additional encapsulation that comes between the UDP header and the inner IP packet? - How does a tunnel ingress node know whether the tunnel will significantly increase the rate of corruption of the inner IP packet? Bullet 7 =3D=3D=3D=3D=3D- " UDP applications that support use of a zero-checksum, should not rely upon correct reception of the IP and UDP protocol information (including the length of the packet) when decoding and processing the packet payload. In particular, the application must be designed so that corruption of this information does not result in accumulated state or incorrect processing of a tunneled payload." - How could any application achieve this goal? Possibly by analyzing the consequences if any field in the IPv6 or UDP header were corrupted? (draft-ietf-6man-udpchecksums begins this analysis.) Again, wouldn't the analysis have to include any additional encapsulation that comes between the UDP header and the inner IP header? - Wouldn't the analysis, mentioned above, have to include assurances regarding the case when the destination port is corrupted? Specifically, would it have to include a guarantee that if the encapsulated inner packet were delivered to any randomly chosen port, it would not cause any harm to the application listening on that port? From rbonica@juniper.net Tue Oct 9 11:59:06 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3545F11E813A; Tue, 9 Oct 2012 11:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwuqiuv2iLDT; Tue, 9 Oct 2012 11:59:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC10511E8133; Tue, 9 Oct 2012 11:59:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Ronald Bonica" To: The IESG Subject: Ronald Bonica's Discuss on draft-ietf-6man-udpchecksums-04: (with DISCUSS) X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121009185905.29120.38799.idtracker@ietfa.amsl.com> Date: Tue, 09 Oct 2012 11:59:05 -0700 Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-udpchecksums@tools.ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 18:59:06 -0000 Ronald Bonica has entered the following ballot position for draft-ietf-6man-udpchecksums-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This DISCUSS is related to my DISCUSS on the udpzero document. As soon as that DISCUSS is addressed, I will clear this one. From rpaulo@apple.com Tue Oct 9 12:25:54 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B9A21F874F for ; Tue, 9 Oct 2012 12:25:54 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdMZ-u1vJkiV for ; Tue, 9 Oct 2012 12:25:52 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 36D5E21F8747 for ; Tue, 9 Oct 2012 12:25:52 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0MBN005LB4MDEE90@mail-out.apple.com> for ipv6@ietf.org; Tue, 09 Oct 2012 12:25:27 -0700 (PDT) X-AuditID: 11807134-b7fb46d00000395a-70-50747a26a91e Received: from rui-macbook-pro.apple.com (rui-macbook-pro.apple.com [17.193.13.39]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id 44.7A.14682.72A74705; Tue, 09 Oct 2012 12:25:27 -0700 (PDT) Subject: Re: 6MAN WG Last Call: From: Rui Paulo In-reply-to: <67F311F3-363E-4870-A3AD-643BFC6D2978@gmail.com> Date: Tue, 09 Oct 2012 12:25:26 -0700 Message-id: <897E7BDE-DB8A-400F-8E22-996FA6C87096@apple.com> References: <67F311F3-363E-4870-A3AD-643BFC6D2978@gmail.com> To: "ipv6@ietf.org Mailing List" X-Mailer: Apple Mail (2.1498) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupiluLIzCtJLcpLzFFi42IRPMirrqteVRJgMLvY4uXZ90wOjB5Llvxk CmCM4rJJSc3JLEst0rdL4Mp493gSe8FStoqrM6axNjDeYOli5OCQEDCRaD2q2sXICWSKSVy4 t56ti5GLQ0hgJZPEym+v2EASzAI6Eju33mEDqecV0JNY1c0DEhYW8JX4Mn8qM4jNJqAk8azv BDuIzSlgK9Hy+C4riM0ioCIxp285M8QYbYllC1+D2bwCNhKL1u4BqxcCss9O+Qy2SkTAQGLv 2VPMEPfIStx78ZttAiPfLCRXzEK4YhaSqQsYmVcxChal5iRWGproJRYU5KTqJefnbmIEhVBD ockOxoM/+Q8xCnAwKvHwSsaXBAixJpYVV+YeYpTgYFYS4d1vDxTiTUmsrEotyo8vKs1JLT7E KM3BoiTO67ehOEBIID2xJDU7NbUgtQgmy8TBKdXA2HGhYGHJtM/p504V3f/QZ3K4SKTe1e/K ZfX7bxIVnLnORX30O8OzoNFbdkd8WWpN1su7Shutf5rt7Hh2o/Os8LWgbR/Sj765m16h/9Go ZbvI98B61UWNP/K2KPJFtJr8mpERkB83a13CRS3hBX+vqu74761f+GoPpzjbovwLcZHS/3ie SU9ZoMRSnJFoqMVcVJwIAJ1+s/YdAgAA X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 19:25:55 -0000 On 4 Oct 2012, at 14:53, Bob Hinden wrote: > All, > > This message starts a two week 6MAN Working Group on advancing: > > Title : Security Implications of the Use of IPv6 Extension Headers with IPv6 Neighbor Discovery > Author(s) : Fernando Gont > Filename : draft-ietf-6man-nd-extension-headers-00.txt > Pages : 12 > Date : 2012-06-29 > > http://tools.ietf.org/html/draft-ietf-6man-nd-extension-headers-00 > > as Proposed Standard. Substantive comments and statements of support for advancing this document should be directed to the mailing list. Editorial suggestions can be sent to the authors. This last call will end on 18 October 2012. I support. -- Rui Paulo From bclaise@cisco.com Tue Oct 9 13:41:55 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79111F0C8E; Tue, 9 Oct 2012 13:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMZ6LPs5dOGn; Tue, 9 Oct 2012 13:41:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D9F1F041C; Tue, 9 Oct 2012 13:41:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Benoit Claise" To: The IESG Subject: Benoit Claise's No Objection on draft-ietf-6man-udpchecksums-04: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121009204154.19921.15426.idtracker@ietfa.amsl.com> Date: Tue, 09 Oct 2012 13:41:54 -0700 Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-udpchecksums@tools.ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 20:41:56 -0000 Benoit Claise has entered the following ballot position for draft-ietf-6man-udpchecksums-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- No objection to the publication of this document, but I really would like to have the following requirement clarified. 2. Implementations MUST provide a way to signal the set of ports that will be enabled to receive UDP datagrams with a zero checksum. = What is an implementation? The application running over the tunnel? You refer to "An encapsulating protocol" in the sentence before the bullet points, is this what you mean? = If yes, signal from where to whom? Or maybe by "implementation" you mean "IPv6 protocol stack implementation" From bclaise@cisco.com Tue Oct 9 13:43:31 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB83421F84FE; Tue, 9 Oct 2012 13:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNXDKdhvieNP; Tue, 9 Oct 2012 13:43:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6276621F842F; Tue, 9 Oct 2012 13:43:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Benoit Claise" To: The IESG Subject: Benoit Claise's No Objection on draft-ietf-6man-udpzero-06: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121009204331.6077.14763.idtracker@ietfa.amsl.com> Date: Tue, 09 Oct 2012 13:43:31 -0700 Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-udpzero@tools.ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 20:43:31 -0000 Benoit Claise has entered the following ballot position for draft-ietf-6man-udpzero-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- No objection to the publication of this document, but I really would like to have the following points clarified. - 2. Implementations MUST provide a way to signal the set of ports that will be enabled to receive UDP datagrams with a zero checksum. What is an implementation? The application running over the tunnel? You refer to "An encapsulating protocol" in the sentence before the bullet points, is this what you mean? If yes, signal from where to whom? Or maybe by "implementation" you mean "IPv6 protocol stack implementation" - Section 3.1.2 Corruption of the source IP address Please mention Unicast Reverse Path Forwarding, which might discard packets. From magnus.westerlund@ericsson.com Wed Oct 10 01:24:00 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E108421F84F6; Wed, 10 Oct 2012 01:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.12 X-Spam-Level: X-Spam-Status: No, score=-106.12 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xjmyjz3BnoQF; Wed, 10 Oct 2012 01:24:00 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7391E21F84F2; Wed, 10 Oct 2012 01:23:59 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-64-5075309d273d Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E4.73.25676.D9035705; Wed, 10 Oct 2012 10:23:58 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Wed, 10 Oct 2012 10:23:57 +0200 Message-ID: <5075309D.3040401@ericsson.com> Date: Wed, 10 Oct 2012 10:23:57 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Benoit Claise Subject: Re: Benoit Claise's No Objection on draft-ietf-6man-udpzero-06: (with COMMENT) References: <20121009204331.6077.14763.idtracker@ietfa.amsl.com> In-Reply-To: <20121009204331.6077.14763.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLLMWRmVeSWpSXmKPExsUyM+Jvre48g9IAgyP/mS0WdDaxWhx9LGHx 8dk6FosZfyYyW7w8+57JgdVjyu+NrB5Llvxk8vhy+TNbAHMUl01Kak5mWWqRvl0CV8a/AydY Cj4KVVycf52lgXE+fxcjJ4eEgIlE45NHrBC2mMSFe+vZQGwhgVOMEhM3ynYxcgHZyxkl/s1b yQiS4BXQlnh1aBsziM0ioCrx4exfFhCbTcBC4uaPRrBmUYFgiUn7t7BA1AtKnJz5BMwWAarv 3woRZxYokjh5aTMTiC0sECnRfnMNUC8H0DIHiR17g0FMTgFHiXtzHSBOk5R4M/kmVKemROv2 3+wQtrxE89bZzBAna0s0NHWwTmAUmoVk8SwkLbOQtCxgZF7FKJybmJmTXm6kl1qUmVxcnJ+n V5y6iREY5Ae3/FbdwXjnnMghRmkOFiVxXuute/yFBNITS1KzU1MLUovii0pzUosPMTJxcEo1 MC6uqbrh9yyt2CbHr+O2ub5t3rxUZkaLc16zWHeu+mVwYs+1KfqmmvWKD97sNvZ3DfmwMWzx 52tmM1fb3it5/cQsjmPV/7jz7xZfP8iiya1RlqfxVOaT7vLZfut6VJ/mnj5eu/XxN4lt+6+9 /N2d82NNxFfJmdtecT+5rRA5ySh6cZXhmUoJk1VKLMUZiYZazEXFiQDL9DoAQAIAAA== Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-udpzero@tools.ietf.org, ipv6@ietf.org, The IESG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 08:24:01 -0000 On 2012-10-09 22:43, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > draft-ietf-6man-udpzero-06: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > No objection to the publication of this document, but I really would > like to have the following points clarified. > > - 2. Implementations MUST provide a way to signal the set of ports > that will be enabled to receive UDP datagrams with a zero > checksum. > > What is an implementation? The application running over the tunnel? You > refer to "An encapsulating protocol" in the sentence before the bullet > points, is this what you mean? For a tunnel protocol it is the tunnel protocol implementation that needs either implicitly or explicitly indicate or signal that it will use zero checksum for a particular flow or ports. > If yes, signal from where to whom? > Or maybe by "implementation" you mean "IPv6 protocol stack > implementation" The protocol or implementation using zero checksum is the one that needs to signal it. But from my perspective it can be dealt with implicitly in some cases where static ports works. Lets try to clarify that formulation. > > - Section 3.1.2 Corruption of the source IP address > > Please mention Unicast Reverse Path Forwarding, which might discard > packets. Yes, we can add that as a existing cause for packets with erronous source address to be dropped. cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From otroan@employees.org Wed Oct 10 01:28:10 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A704B21F87B4 for ; Wed, 10 Oct 2012 01:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.144 X-Spam-Level: X-Spam-Status: No, score=-10.144 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erYEGb0qdVtd for ; Wed, 10 Oct 2012 01:28:10 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id BB10521F87A8 for ; Wed, 10 Oct 2012 01:28:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAJAPowdVCQ/khR/2dsb2JhbABEhUu4XAQEe4EIgjkBWwuBPjWHYwuXCqAci0aFQGADlwCNMIFrgm8 X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="8684010" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 10 Oct 2012 08:28:05 +0000 Received: from dhcp-lys01-vla250-10-147-112-212.cisco.com (dhcp-lys01-vla250-10-147-112-212.cisco.com [10.147.112.212]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9A8S4be029829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 10 Oct 2012 08:28:05 GMT From: =?iso-8859-1?Q?Ole_Tr=F8an?= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: 6MAN WG Last Call: Date: Wed, 10 Oct 2012 10:28:02 +0200 Message-Id: <0D1941A7-217D-44E1-A3E3-45D30D51A273@employees.org> To: "ipv6@ietf.org 6man" Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) X-Mailer: Apple Mail (2.1498) Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 08:28:10 -0000 All, This message starts a two week 6MAN Working Group on advancing: Title : Distributing Address Selection Policy using = DHCPv6 Author(s) : A. Matsumoto, T. Fujisaki, T. Chown Filename : draft-ietf-6man-addr-select-opt-06.txt Pages : 10 Date : 2012-09-21 http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-06 as Proposed Standard. Substantive comments and statements of support = for advancing this document should be directed to the mailing list. = Editorial suggestions can be sent to the authors. This last call will = end on 24. October 2012. Regards, Ole Tr=F8an & Bob Hinden= From magnus.westerlund@ericsson.com Wed Oct 10 01:30:47 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A7521F87BD; Wed, 10 Oct 2012 01:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.112 X-Spam-Level: X-Spam-Status: No, score=-106.112 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3Uehy3UcZYq; Wed, 10 Oct 2012 01:30:47 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8172421F84C8; Wed, 10 Oct 2012 01:30:46 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-de-50753235ba63 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A8.7A.11467.53235705; Wed, 10 Oct 2012 10:30:45 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Wed, 10 Oct 2012 10:30:44 +0200 Message-ID: <50753234.3070703@ericsson.com> Date: Wed, 10 Oct 2012 10:30:44 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Brian Haberman Subject: Re: Stewart Bryant's Discuss on draft-ietf-6man-udpzero-06: (with DISCUSS and COMMENT) References: <013e01cda61c$1ff13910$5fd3ab30$@olddog.co.uk> <50741EF0.9000208@innovationslab.net> In-Reply-To: <50741EF0.9000208@innovationslab.net> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvra6pUWmAQcNeQYsFnU2sFj96bjBb zOz5x2jxv/cbq8XHZ+tYLGb8mchs8fLseyaLc0/nMDpweEz5vZHVY8mSn0weM49/YfFYsXkl o8eXy5/ZAlijuGxSUnMyy1KL9O0SuDK27lrOUjBbrOL1l/3sDYx3BbsYOTkkBEwkPr2Zzghh i0lcuLeerYuRi0NI4BSjRNPqPewQznJGiQtXmlhBqngFtCXur1zNDGKzCKhKvJ0EYbMJWEjc /NHIBmKLCgRLTNq/hQWiXlDi5MwnYLaIgK5EY8cKFpChzAJnGSXe9O8EGyoskCgx79FLsEFC AgkSjc27wBo4BYwkdjZNZoE4T1LizeSbYDazgJ7ElKstjBC2vETz1tlQvdoSDU0drBMYhWYh 2T0LScssJC0LGJlXMQrnJmbmpJcb6qUWZSYXF+fn6RWnbmIERsjBLb91dzCeOidyiFGag0VJ nJcrab+/kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkaNhvyv93gTt+x8u2WiguzfpqN/FKYu UVz6/6NznvGJ84Z9NnP5nr7sbEtq38+dMO38va2cy1MNWwRtzr9/Zd+zWbxReY1eZqC1xIY7 2gLZActuh+YYF7olfzVY9SAlvN8qZXrShU2h/UsYj0yJVWfZUy9h/t27x2WW59ubV0P/KgR9 dNXZKa7EUpyRaKjFXFScCACNeHvnXgIAAA== Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-udpchecksums@tools.ietf.org, ipv6@ietf.org, 'The IESG' , adrian@olddog.co.uk, draft-ietf-6man-udpzero@tools.ietf.org, stbryant@cisco.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 08:30:47 -0000 On 2012-10-09 14:56, Brian Haberman wrote: > On 10/9/12 8:46 AM, Adrian Farrel wrote: >> Are we in the weeds yet? > > I believe we are. Likely, but the weeds here are fascinating and possibly relevant. > > Agreed. As long as there is a robust L-2, the chance of in-transit > errors is low. If MPLS is predominantly carried over Ethernet, I > suspect the Ethernet CRC is providing sufficient/significant protection. I think you are missing one point of the following reference: [Sigcomm2000] Jonathan Stone and Craig Partridge , , "When the CRC and TCP Checksum Disagree", 2000. That is that this paper found a significant amount of erroneous packets where the UDP or TCP checksum discarded the packet, not the L2 CRCs. The whole point of the paper is trying to analyze what type and why their is errors that only the transport checksums detects. When the topic of UDP checksums was discussed in the WG it was questioned if this now 12 year old paper was still relevant. People in the WG went looking at their network interface stats and found that several different machines has UDP checksum discard rates that was higher than one every 1000 packets. So yes there is still a lot of packets being discard in the destination host due to transport checksums. If "Why" has changed we don't know because someone needs to repeat the study Stone and Partridge did. I would not be surprised if there is differences between IP routing, especially at the edge and MPLS label switching in regards to error characteristics. I think my main point around this whole issue is that you have to be careful to understand the environment and what mitigating factors that may exist so that you don't see these issues. I am fine with updating the text to better reflect reality. However, I don't understand this MPLS and PW area sufficiently to determine what error factors and saving graces that happens to be built into the system. The whole point of the argumentation and checklist is. Checksums are there for a reason. IF you have analyzed it the implications of turning of the checksum and what it means to use a particular protocol header field that is now unprotected then yes you can go ahead and use it. But don't forget how other users of the network might suffer from your traffic. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed Oct 10 01:59:34 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE5421F872E; Wed, 10 Oct 2012 01:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.105 X-Spam-Level: X-Spam-Status: No, score=-106.105 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkAAU9HDHKhk; Wed, 10 Oct 2012 01:59:33 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 853EE21F86FE; Wed, 10 Oct 2012 01:59:32 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-b0-507538f20789 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 32.E2.17130.2F835705; Wed, 10 Oct 2012 10:59:30 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Wed, 10 Oct 2012 10:59:30 +0200 Message-ID: <507538F1.5080505@ericsson.com> Date: Wed, 10 Oct 2012 10:59:29 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ronald Bonica Subject: Re: Ronald Bonica's Discuss on draft-ietf-6man-udpzero-06: (with DISCUSS) References: <20121009185726.29097.69699.idtracker@ietfa.amsl.com> In-Reply-To: <20121009185726.29097.69699.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUyM+Jvre4ni9IAg8lLpCwWdDaxWnx8to7F YsaficwWL8++Z7I48N3BgdVjyZKfTB7Xm66ye3y5/JktgDmKyyYlNSezLLVI3y6BK2Ptjn7W gr/qFZ8nzGBqYOxX6GLk5JAQMJE4uv0CE4QtJnHh3nq2LkYuDiGBU4wS/b2vmSGc5YwSH45M ZAGp4hXQlni55yNrFyMHB4uAqsSOd4wgYTYBC4mbPxrZQGxRgWCJSfu3QJULSpyc+QTMFhFQ l3i8ahpYDbNAkUTj7FvsILawQIjEho3PwI4QEnCUeND8iRnE5hRwkvhzah4zxHGSEm8m32SB 6NWUaN3+mx3Clpdo3jqbGaJXW6KhqYN1AqPQLCSrZyFpmYWkZQEj8ypG4dzEzJz0cnO91KLM 5OLi/Dy94tRNjMBAP7jlt8EOxk33xQ4xSnOwKInz6qnu9xcSSE8sSc1OTS1ILYovKs1JLT7E yMTBKdXAeODx2XMpLNdqzzIx7K4TzVp7wdkx5N3BWWIsVpeW7O5PWsfsWHK4uGqv2deAbpcr RUeDs1Qfpc316HYLZDw0O+LUAi+rJW2+r3u2af46oKSvVb9pneqPtUxWYlc3MUybcq2pxUpD 1mHtUYPwdQq2N4X/9X/W/S6sq/X3gV+6llfn+kVKL3avU2Ipzkg01GIuKk4EAAuCV/pCAgAA Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, draft-ietf-6man-udpzero@tools.ietf.org, The IESG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 08:59:34 -0000 On 2012-10-09 20:57, Ronald Bonica wrote: > Ronald Bonica has entered the following ballot position for > draft-ietf-6man-udpzero-06: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This is a two-part DISCUSS-DISCUSS. Both parts relate to bullet points in > Section 5.1. > > Bullet 5 > ====== > "Tunnels that encapsulate IP may rely on the inner packet > integrity checks provided that the tunnel will not significantly > increase the rate of corruption of the inner IP packet." > > - What does it mean to *significantly* increase the rate of corruption of > the inner IP packet? That is a good question. And the answer is it depends. If you are considering a tunnel protocols which target deployment area is one where you have very low rates of corruption, lets say below 10^-6 then a factor of 2 or even 10 might be fine as the resulting end-to-end basic IP service may still be fine. But if that same tunnel is supposed to support something that requires a packet loss rate below 10^-6 then any increase in corruption might be to high. > - Shouldn't we also be concerned about corruption of the UDP header and > any additional encapsulation that comes between the UDP header and the > inner IP packet? I think the formulation actually is considering that. If the IPv6/UDP/FOO tunnel protocol carries IP and FOO is senesitive to corruption then isn't the payload of the tunnel, i.e. the inner IP going to suffer an increased corruption rate. > - How does a tunnel ingress node know whether the tunnel will > significantly increase the rate of corruption of the inner IP packet? That is something you have to statistically analyze when designing the protocol and deciding on using zero-checksum. > > Bullet 7 > =====- > " UDP applications that support use of a zero-checksum, should not > rely upon correct reception of the IP and UDP protocol > information (including the length of the packet) when decoding > and processing the packet payload. In particular, the > application must be designed so that corruption of this > information does not result in accumulated state or incorrect > processing of a tunneled payload." > > - How could any application achieve this goal? Possibly by analyzing the > consequences if any field in the IPv6 or UDP header were corrupted? > (draft-ietf-6man-udpchecksums begins this analysis.) Again, wouldn't the > analysis have to include any additional encapsulation that comes between > the UDP header and the inner IP header? Yes, this is a design analysis which includes the tunnel protocols headers. > > - Wouldn't the analysis, mentioned above, have to include assurances > regarding the case when the destination port is corrupted? Specifically, > would it have to include a guarantee that if the encapsulated inner > packet were delivered to any randomly chosen port, it would not cause any > harm to the application listening on that port? Clearly it can't include a guarantee that it will not harm what ever is at the randomly chosen port. But one part we try to get across in this document is that this is the reason we want to ensure that default remains to have the UDP checksum enabled to avoid having applications not having considered this in their design or at least been analyzed to be safe enough to get zero checksummed packets. The next step is the question of potential harm is a statistics game. And the more traffic that are transported over the network with zero-checksum the higher the probability that you will get a packet not intended for your context. Thus you will have to deal with it. Here I think most tunnel egresses are reasonably simple to analyze what happens. You attempt to decapsulate it according to whats in the packet. If that is not a mismatch you try to do the next step for the inner packet, switching or forwarding that based on whats there. That either matches or not the context and are thus sent further or discarded. If there is a checksum on that level it can help discarding packets that completely misses the context. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From bclaise@cisco.com Wed Oct 10 02:18:40 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A50221F8530; Wed, 10 Oct 2012 02:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.663 X-Spam-Level: X-Spam-Status: No, score=-8.663 tagged_above=-999 required=5 tests=[AWL=1.677, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tu8aLbCXaDz3; Wed, 10 Oct 2012 02:18:39 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA0721F84D7; Wed, 10 Oct 2012 02:18:39 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9A9IZkd007064; Wed, 10 Oct 2012 11:18:36 +0200 (CEST) Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9A9IZ5p025262; Wed, 10 Oct 2012 11:18:35 +0200 (CEST) Message-ID: <50753D6B.6010201@cisco.com> Date: Wed, 10 Oct 2012 11:18:35 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: Benoit Claise's No Objection on draft-ietf-6man-udpzero-06: (with COMMENT) References: <20121009204331.6077.14763.idtracker@ietfa.amsl.com> <5075309D.3040401@ericsson.com> In-Reply-To: <5075309D.3040401@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-udpzero@tools.ietf.org, ipv6@ietf.org, The IESG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 09:18:40 -0000 Hi Magnus, > On 2012-10-09 22:43, Benoit Claise wrote: >> Benoit Claise has entered the following ballot position for >> draft-ietf-6man-udpzero-06: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> No objection to the publication of this document, but I really would >> like to have the following points clarified. >> >> - 2. Implementations MUST provide a way to signal the set of ports >> that will be enabled to receive UDP datagrams with a zero >> checksum. >> >> What is an implementation? The application running over the tunnel? You >> refer to "An encapsulating protocol" in the sentence before the bullet >> points, is this what you mean? > For a tunnel protocol it is the tunnel protocol implementation that > needs either implicitly or explicitly indicate or signal that it will > use zero checksum for a particular flow or ports. > >> If yes, signal from where to whom? >> Or maybe by "implementation" you mean "IPv6 protocol stack >> implementation" > The protocol or implementation using zero checksum is the one that needs > to signal it. But from my perspective it can be dealt with implicitly in > some cases where static ports works. > > Lets try to clarify that formulation. I would like to see the new text proposal. Because THE question behind my questions is: how is this requirement fulfilled in draft-ietf-6man-udpchecksums-04? Regards, Benoit. > >> - Section 3.1.2 Corruption of the source IP address >> >> Please mention Unicast Reverse Path Forwarding, which might discard >> packets. > Yes, we can add that as a existing cause for packets with erronous > source address to be dropped. > > cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > From v6ops@globis.net Wed Oct 10 03:01:14 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A812721F878B for ; Wed, 10 Oct 2012 03:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOHVwHd6F0wb for ; Wed, 10 Oct 2012 03:01:13 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2A41521F8787 for ; Wed, 10 Oct 2012 03:01:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id D91E7870109; Wed, 10 Oct 2012 12:00:56 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 320grLfb-SJ5; Wed, 10 Oct 2012 12:00:40 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id BD432870056; Wed, 10 Oct 2012 12:00:39 +0200 (CEST) Message-ID: <50754741.9090506@globis.net> Date: Wed, 10 Oct 2012 12:00:33 +0200 From: Ray Hunter User-Agent: Postbox 3.0.5 (Macintosh/20120826) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ole_Tr=F8an?= Subject: Re: 6MAN WG Last Call: References: <0D1941A7-217D-44E1-A3E3-45D30D51A273@employees.org> In-Reply-To: <0D1941A7-217D-44E1-A3E3-45D30D51A273@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org>, "ipv6@ietf.org 6man" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 10:01:14 -0000 I support this work. Discussion ========== Section 4.2 s/the default policy should be restored/the previously active policy should be restored/ ? Nits & clarification ============= Section 2 s/A address selection option contains/An Address Selection option contains/ s/Multiple policy table options in a Policy Table option constitute a single policy table./ Multiple Policy Table options in an Address Selection option constitute a single policy table./ s/zero padded/left aligned, big-endian, and zero padded on the right/ Section 3 s/in any messages other/in any DHCPv6 messages other/ Section 4.1 s/his requirement/their own requirements/ s/a) It receives distributed policy table, and replaces the existing policy tables with that. b) It preserves the default policy table, or manually configured policy./ a) replace the existing active policy table with the DHCPv6 distributed policy table . b) preserve the existing active policy table, whether this be the default policy table, or user configured policy./ Section 4.3 s/node-global information by its nature/node-global information by their nature/ s/One of the reason is/One reason being/ s/multiple address selection policy/multiple address selection policies,/ s/the effect of both policy/the effect of both policies/ s/that absence of the distributed policy/that absence of a distributed policy/ a/mean preference/mean a preference/ s/deal with multiple received policy/deal with multiple received policies/ s/DHCPv6 clients need to convert this label to a representation specified by each implementation/DHCPv6 clients SHOULD convert this label to a representation appropriate for the local implementation/ s/So, the number of the options and the total size of the options should be taken care of. Since the number of selection rules could be large, an administrator configuring the policy to be distributed should consider the resulting DHCPv6 message size/ Network administrators SHOULD consider local limitations to the maximum DHCPv6 message size that can be reliably transported via their specific local infrastructure to end nodes; and therefore they SHOULD consider the number of options, the total size of the options, and the resulting DHCPv6 message size, when defining their Policy Table./ Section 6: s/and the affected packets might be blocked at an outgoing ISP because of ingress filtering/and the affected packets might be blocked at an outgoing ISP because of ingress filtering, incur additional network charges, or be misdirected to an attacker's machine/ s/should be communicated through a secure/should communicate through a secure/ s/This issue will not be degraded regardless of the introduction of this option, or regardless/This issue will not be modified by the introduction of this option, regardless/ regards, RayH Ole Trøan wrote: > All, > > This message starts a two week 6MAN Working Group on advancing: > > Title : Distributing Address Selection Policy using DHCPv6 > Author(s) : A. Matsumoto, T. Fujisaki, T. Chown > Filename : draft-ietf-6man-addr-select-opt-06.txt > Pages : 10 > Date : 2012-09-21 > > http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-06 > > as Proposed Standard. Substantive comments and statements of support for advancing this document should be directed to the mailing list. Editorial suggestions can be sent to the authors. This last call will end on 24. October 2012. > > Regards, > > Ole Trøan& Bob Hinden From stbryant@cisco.com Wed Oct 10 04:52:03 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CAE21F8735; Wed, 10 Oct 2012 04:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.457 X-Spam-Level: X-Spam-Status: No, score=-110.457 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXQRX2haYQV2; Wed, 10 Oct 2012 04:52:02 -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 0EA5F21F8724; Wed, 10 Oct 2012 04:52:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=548; q=dns/txt; s=iport; t=1349869922; x=1351079522; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=GQGgG2Um26NNGUCLGiYKU3YRPYDuFXNRXj7JCFxidlg=; b=Au3J59r2SJxMQkbxBoxxzfebZeo9mZcpMdeo+jcA71Llkd6sMbwRhBhS vEbIIRl5krw0NUZ8aDoJKMXNGDSw1W677VfGzJfrKvRJ+3eeb4JpVdPrV u4lxKoa5iLmVNKrP70bLgyu0t/Yru/Jnx4b+4CDE+rim0Rl9lg0jaLyEB 4=; X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="8684611" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 10 Oct 2012 11:52:01 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9ABq0fR020100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Oct 2012 11:52:01 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q9ABpuq1024341; Wed, 10 Oct 2012 12:51:57 +0100 (BST) Message-ID: <5075615C.6080406@cisco.com> Date: Wed, 10 Oct 2012 12:51:56 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: Benoit Claise's No Objection on draft-ietf-6man-udpzero-06: (with COMMENT) References: <20121009204331.6077.14763.idtracker@ietfa.amsl.com> <5075309D.3040401@ericsson.com> In-Reply-To: <5075309D.3040401@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Benoit Claise , 6man-chairs@tools.ietf.org, draft-ietf-6man-udpzero@tools.ietf.org, The IESG , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 11:52:03 -0000 What is an implementation? The application running over the tunnel? You refer to "An encapsulating protocol" in the sentence before the bullet points, is this what you mean? > For a tunnel protocol it is the tunnel protocol implementation that > needs either implicitly or explicitly indicate or signal that it will > use zero checksum for a particular flow or ports. > That was a point that I made concerning the text. Are you planning to add text to the draft(s) to indicate configuration and implicit signalling are OK? Stewart From stbryant@cisco.com Wed Oct 10 05:51:47 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EDC21F8698; Wed, 10 Oct 2012 05:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.453 X-Spam-Level: X-Spam-Status: No, score=-110.453 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSZeKhabY68Y; Wed, 10 Oct 2012 05:51:47 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFAA21F8686; Wed, 10 Oct 2012 05:51:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6914; q=dns/txt; s=iport; t=1349873506; x=1351083106; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=wqLB9V18+1kHtD0ED2liLXY+1+IHwUomGltJ6oUf9qo=; b=Jf1006Wl2JpheuTpkSkunHsmyE+1R17RKVFV/uoS5I6hAdvto6Gl3+zY 1GwdNSWZXkfVNNpxPLlFafe491jIWQnEhNfVwBMoWcJB8CQyc04NtqLd8 xdqtUGvLj1963jYOM7bhQpKf3LVSECZ8bZHmvHwmrhmAot5BAteq1FG+m E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAKhudVCQ/khL/2dsb2JhbABEhhK5GYEIgiABAQEEEgECDhUvEQEQCxgCAgUQAQEECwICCQMCAQIBRQYNAQcBAQUZhW+BdAuXR4NMEIlBkwGBIYolgwwEgX6BEgOVa4UziRKBBmWCboFi X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="145079398" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 10 Oct 2012 12:51:42 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9ACpgBJ013745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Oct 2012 12:51:42 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q9ACpbUU027755; Wed, 10 Oct 2012 13:51:38 +0100 (BST) Message-ID: <50756F59.5090307@cisco.com> Date: Wed, 10 Oct 2012 13:51:37 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: Ronald Bonica's Discuss on draft-ietf-6man-udpzero-06: (with DISCUSS) References: <20121009185726.29097.69699.idtracker@ietfa.amsl.com> <507538F1.5080505@ericsson.com> In-Reply-To: <507538F1.5080505@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-udpzero@tools.ietf.org, ipv6@ietf.org, The IESG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 12:51:47 -0000 On 10/10/2012 09:59, Magnus Westerlund wrote: > On 2012-10-09 20:57, Ronald Bonica wrote: >> Ronald Bonica has entered the following ballot position for >> draft-ietf-6man-udpzero-06: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> This is a two-part DISCUSS-DISCUSS. Both parts relate to bullet points in >> Section 5.1. >> >> Bullet 5 >> ====== >> "Tunnels that encapsulate IP may rely on the inner packet >> integrity checks provided that the tunnel will not significantly >> increase the rate of corruption of the inner IP packet." >> >> - What does it mean to *significantly* increase the rate of corruption of >> the inner IP packet? > That is a good question. And the answer is it depends. If you are > considering a tunnel protocols which target deployment area is one where > you have very low rates of corruption, lets say below 10^-6 then a > factor of 2 or even 10 might be fine as the resulting end-to-end basic > IP service may still be fine. But if that same tunnel is supposed to > support something that requires a packet loss rate below 10^-6 then any > increase in corruption might be to high. A useful and relevant question, which is worth asking the user to consider is what exactly are those loss rates. A lot of systems do much better than 10^-6. At 10Gb/s that is 10^4 errors/sec, so you can see they have to do better that that. I am not sure what state of the art is, but the range 10^-12 is often quoted as a working number. Maybe we need to text of the form where the underlying IPv6 network is considered to have an acceptably low error rate, that may indicate that it is safe to operate without a UDP checksum, without further analysis consideration of the protocols to be carried over the UDP tunnel. > >> - Shouldn't we also be concerned about corruption of the UDP header and >> any additional encapsulation that comes between the UDP header and the >> inner IP packet? > I think the formulation actually is considering that. If the > IPv6/UDP/FOO tunnel protocol carries IP and FOO is senesitive to > corruption then isn't the payload of the tunnel, i.e. the inner IP going > to suffer an increased corruption rate. > >> - How does a tunnel ingress node know whether the tunnel will >> significantly increase the rate of corruption of the inner IP packet? > That is something you have to statistically analyze when designing the > protocol and deciding on using zero-checksum. My concern is that is impractical, the tunnel payload is opaque. Remember the UDP tunnel will in many cases be the functional equivalent of GRE, and we neither have the ability to include a c/s for IPv6/GRE, nor the ability to predict the payload type. BTW, you need to realize that it's going to be very difficult to do the do the c/s checking in a fast tunnel router and will often need h/w changes. Unlike a common transport protocol stack implementation a fast tunneling router does not have access to all the packet data to run the c/s check. For that reason alone, I predict that most of these routers will neither impose or verify the UDP c/s in the tunnel case. > >> Bullet 7 >> =====- >> " UDP applications that support use of a zero-checksum, should not >> rely upon correct reception of the IP and UDP protocol >> information (including the length of the packet) when decoding >> and processing the packet payload. In particular, the >> application must be designed so that corruption of this >> information does not result in accumulated state or incorrect >> processing of a tunneled payload." >> >> - How could any application achieve this goal? Possibly by analyzing the >> consequences if any field in the IPv6 or UDP header were corrupted? >> (draft-ietf-6man-udpchecksums begins this analysis.) Again, wouldn't the >> analysis have to include any additional encapsulation that comes between >> the UDP header and the inner IP header? > Yes, this is a design analysis which includes the tunnel protocols headers. > >> - Wouldn't the analysis, mentioned above, have to include assurances >> regarding the case when the destination port is corrupted? Specifically, >> would it have to include a guarantee that if the encapsulated inner >> packet were delivered to any randomly chosen port, it would not cause any >> harm to the application listening on that port? > Clearly it can't include a guarantee that it will not harm what ever is > at the randomly chosen port. But one part we try to get across in this > document is that this is the reason we want to ensure that default > remains to have the UDP checksum enabled to avoid having applications > not having considered this in their design or at least been analyzed to > be safe enough to get zero checksummed packets. > > The next step is the question of potential harm is a statistics game. > And the more traffic that are transported over the network with > zero-checksum the higher the probability that you will get a packet not > intended for your context. Thus you will have to deal with it. Here I > think most tunnel egresses are reasonably simple to analyze what > happens. You attempt to decapsulate it according to whats in the packet. > If that is not a mismatch you try to do the next step for the inner > packet, switching or forwarding that based on whats there. That either > matches or not the context and are thus sent further or discarded. If > there is a checksum on that level it can help discarding packets that > completely misses the context. > Let me take another cut on this. We accept that IPv6/GRE is safe, since we did not update GRE for IPv6, and we have not deprecated it. Why are we not simply saying : "It will commonly be the case that the use of a UDP tunnel is functionally equivalent to GRE, and consequently when the UDP c/s is not used, there may be some level of undetected data corruption in the tunnel which is propagated to the recipient of the tunnel payload. Thus, where the UDP c/s is not used in a tunnel application, the same consideration of data integrity apply to both UDP tunnels as apply to GRE tunnels, and must be taken into consideration by the tunnel provider." That is probably the necessary and sufficient text for the the reader to understand the context and the design considerations. - Stewart From gorry@erg.abdn.ac.uk Wed Oct 10 07:38:52 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802D421F8686; Wed, 10 Oct 2012 07:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.385 X-Spam-Level: X-Spam-Status: No, score=-102.385 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2eeBf85x0yf; Wed, 10 Oct 2012 07:38:51 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 685D121F852C; Wed, 10 Oct 2012 07:38:51 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id C1D842B45DB; Wed, 10 Oct 2012 15:38:49 +0100 (BST) Received: from 2001:630:241:210:3615:9eff:fe1b:2376 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Wed, 10 Oct 2012 15:38:50 +0100 Message-ID: In-Reply-To: <50756F59.5090307@cisco.com> References: <20121009185726.29097.69699.idtracker@ietfa.amsl.com> <507538F1.5080505@ericsson.com> <50756F59.5090307@cisco.com> Date: Wed, 10 Oct 2012 15:38:50 +0100 Subject: Re: Ronald Bonica's Discuss on draft-ietf-6man-udpzero-06: (with DISCUSS) From: gorry@erg.abdn.ac.uk To: stbryant@cisco.com, ipv6@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-udpzero@tools.ietf.org, The IESG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 14:38:52 -0000 See comments in-line. Gorry > On 10/10/2012 09:59, Magnus Westerlund wrote: >> On 2012-10-09 20:57, Ronald Bonica wrote: >>> Ronald Bonica has entered the following ballot position for >>> draft-ietf-6man-udpzero-06: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to >>> http://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> This is a two-part DISCUSS-DISCUSS. Both parts relate to bullet points >>> in >>> Section 5.1. >>> >>> Bullet 5 >>> ====== >>> "Tunnels that encapsulate IP may rely on the inner packet >>> integrity checks provided that the tunnel will not significantly >>> increase the rate of corruption of the inner IP packet." >>> >>> - What does it mean to *significantly* increase the rate of corruption >>> of >>> the inner IP packet? >> That is a good question. And the answer is it depends. If you are >> considering a tunnel protocols which target deployment area is one where >> you have very low rates of corruption, lets say below 10^-6 then a >> factor of 2 or even 10 might be fine as the resulting end-to-end basic >> IP service may still be fine. But if that same tunnel is supposed to >> support something that requires a packet loss rate below 10^-6 then any >> increase in corruption might be to high. > > A useful and relevant question, which is worth asking the user to consider > is what exactly are those loss rates. A lot of systems do much better than > 10^-6. At 10Gb/s that is 10^4 errors/sec, so you can see they have to > do better that that. I am not sure what state of the art is, but the > range 10^-12 is often quoted as a working number. > > Maybe we need to text of the form where the underlying IPv6 network is > considered to have an acceptably low error rate, that may indicate that > it is safe to operate without a UDP checksum, without further analysis > consideration of the protocols to be carried over the UDP tunnel. > I don't think that is what we need to debate or comment upon. We were never intending to review the PILC WG recommendations on link design. I suggest that link error rate will dictate the need for link CRC. The draft is about a transport checksum and the focus of the draft is on two cases: end-to-end paths and tunnel paths between network endpoints, but done over transport layer connections. In these cases we worry about not just cables - middlebox manipulations (RTP mixers, load balancers, NAPT, firewalls, etc) and end stack implications are arguably more important. >> >>> - Shouldn't we also be concerned about corruption of the UDP header and >>> any additional encapsulation that comes between the UDP header and the >>> inner IP packet? >> I think the formulation actually is considering that. If the >> IPv6/UDP/FOO tunnel protocol carries IP and FOO is senesitive to >> corruption then isn't the payload of the tunnel, i.e. the inner IP going >> to suffer an increased corruption rate. >> >>> - How does a tunnel ingress node know whether the tunnel will >>> significantly increase the rate of corruption of the inner IP packet? >> That is something you have to statistically analyze when designing the >> protocol and deciding on using zero-checksum. > > My concern is that is impractical, the tunnel payload is opaque. > Remember the UDP tunnel will in many cases be the functional > equivalent of GRE, and we neither have the ability to include > a c/s for IPv6/GRE, nor the ability to predict the payload type. > If one uses GRE, there are indeed no issues providing you stick with the requirement that encapsulated data itself uses a UDP checksum - I don't see GRE as an end-to-end transport. > BTW, you need to realize that it's going to be very difficult > to do the do the c/s checking in a fast tunnel router and will > often need h/w changes. Unlike a common transport protocol > stack implementation a fast tunneling router does not > have access to all the packet data to run the c/s check. > For that reason alone, I predict that most of these routers > will neither impose or verify the UDP c/s in the tunnel case. > Isn't this discussed already? For an end host, it can even be that a zero checksum will be replaced by an actual checksum in common hardware interfaces! >>> Bullet 7 >>> =====- >>> " UDP applications that support use of a zero-checksum, should not >>> rely upon correct reception of the IP and UDP protocol >>> information (including the length of the packet) when decoding >>> and processing the packet payload. In particular, the >>> application must be designed so that corruption of this >>> information does not result in accumulated state or incorrect >>> processing of a tunneled payload." >>> >>> - How could any application achieve this goal? Possibly by analyzing >>> the >>> consequences if any field in the IPv6 or UDP header were corrupted? >>> (draft-ietf-6man-udpchecksums begins this analysis.) Again, wouldn't >>> the >>> analysis have to include any additional encapsulation that comes >>> between >>> the UDP header and the inner IP header? >> Yes, this is a design analysis which includes the tunnel protocols >> headers. >> >>> - Wouldn't the analysis, mentioned above, have to include assurances >>> regarding the case when the destination port is corrupted? >>> Specifically, >>> would it have to include a guarantee that if the encapsulated inner >>> packet were delivered to any randomly chosen port, it would not cause >>> any >>> harm to the application listening on that port? >> Clearly it can't include a guarantee that it will not harm what ever is >> at the randomly chosen port. But one part we try to get across in this >> document is that this is the reason we want to ensure that default >> remains to have the UDP checksum enabled to avoid having applications >> not having considered this in their design or at least been analyzed to >> be safe enough to get zero checksummed packets. >> >> The next step is the question of potential harm is a statistics game. >> And the more traffic that are transported over the network with >> zero-checksum the higher the probability that you will get a packet not >> intended for your context. Thus you will have to deal with it. Here I >> think most tunnel egresses are reasonably simple to analyze what >> happens. You attempt to decapsulate it according to whats in the packet. >> If that is not a mismatch you try to do the next step for the inner >> packet, switching or forwarding that based on whats there. That either >> matches or not the context and are thus sent further or discarded. If >> there is a checksum on that level it can help discarding packets that >> completely misses the context. >> > Let me take another cut on this. We accept that IPv6/GRE is safe, since > we did not update GRE for IPv6, and we have not deprecated it. > Why are we not simply saying : > > "It will commonly be the case that the use of a UDP tunnel is > functionally equivalent to GRE, and consequently when the > UDP c/s is not used, there may be some level of undetected > data corruption in the tunnel which is propagated to the recipient > of the tunnel payload. Thus, where the UDP c/s is not used > in a tunnel application, the same consideration of data integrity > apply to both UDP tunnels as apply to GRE tunnels, and must > be taken into consideration by the tunnel provider." > > That is probably the necessary and sufficient text for the the > reader to understand the context and the design considerations. > No, I think we've lost context here about how end hosts handle UDP packets and what the implications are - that precisely why there are two drafts on this topic and it has taken quite some debate at the IETF to get to the stage of this particular update request. I'm sure you'd agree that end hosts can be tunnel end points and that linux-based routers are common, hence we need to treat packets with GRE header different to those with UDP. > - Stewart > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From ammar.salih@auis.edu.iq Wed Oct 10 07:52:26 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3875021F8551 for ; Wed, 10 Oct 2012 07:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMvb1nxVwgIb for ; Wed, 10 Oct 2012 07:52:25 -0700 (PDT) Received: from na3sys010aog103.obsmtp.com (na3sys010aog103.obsmtp.com [74.125.245.74]) by ietfa.amsl.com (Postfix) with SMTP id 47D7F21F86A8 for ; Wed, 10 Oct 2012 07:52:23 -0700 (PDT) Received: from mail-pb0-f44.google.com ([209.85.160.44]) (using TLSv1) by na3sys010aob103.postini.com ([74.125.244.12]) with SMTP ID DSNKUHWLpvMjk0/o8b4VDQx3PA+HnYcY7eFM@postini.com; Wed, 10 Oct 2012 07:52:24 PDT Received: by mail-pb0-f44.google.com with SMTP id ro8so806170pbb.31 for ; Wed, 10 Oct 2012 07:52:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language:x-gm-message-state; bh=JkfnrMvOm40fYIGC9qMSz+QIg4nOdK3wB7wzkeQD5DE=; b=fR46Kba2UBQWVzzOgOw1c1b5AgQ5QmpsNjdpvwq5dAfLWsROXHq3Wbr7Qkjk/PySF4 pmIk12plrQRwZaBm/uTPTKBs38vQ6qAFLCFlzeRtkvqbiTe8EYQBlFgZ6WVsmL3P7oly VJOYqtnJdfFDbQRfSjffbvd4woCJnydaTICHzhy/29mgRCgSlJpr2a46P2gjfyJw7Qeu Fa+gpnt7JXPub1gNJotE0Z2eem0wZ61klUcMhz0OlmWh82hjzlSb4BKPe3F0E2DfMbWq H3K6B27d0bd7cD9m+osgqAk8Adr0iamKEf4PTVu3iwrBoYg8WUhwaD5QIm6H/228RyaS YYhQ== Received: by 10.68.225.34 with SMTP id rh2mr74614011pbc.78.1349880742323; Wed, 10 Oct 2012 07:52:22 -0700 (PDT) Received: from AMMARSALIH ([46.30.228.16]) by mx.google.com with ESMTPS id s9sm971110paz.9.2012.10.10.07.52.18 (version=SSLv3 cipher=OTHER); Wed, 10 Oct 2012 07:52:21 -0700 (PDT) From: "Ammar Salih" To: Subject: IPv6 modification suggestion Date: Wed, 10 Oct 2012 17:52:15 +0300 Message-ID: <50758ba5.e956420a.71b1.6dbb@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01CDA70F.FEE91A90" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2m9tYhnhRC3JXcQ5muO3i8dg+/Mw== Content-Language: en-us X-Gm-Message-State: ALoCoQlhgGxPV2d2mZqPyA7u+wTlm3GoBhIcexOtNvYv4R7pKatE1zwGTEaV5ehbN20E2KWCBo/h X-Mailman-Approved-At: Wed, 10 Oct 2012 08:23:57 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 14:54:57 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_003A_01CDA70F.FEE91A90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello Dears, I would like to suggest adding GPS coordinates to IPv6 header, as you know the current way of determining the location of the IP address is through the IP registration, which is not very accurate as it depends on how the ISP registers it's IP subnets, which is normally done based on country/city. Getting more accurate locations will enhance many services provided by the web, like targeted commercials (for example, I can get Ads regarding restaurants available in my neighborhood instead of all restaurants in the city), another good example would be webpage's language, my language will be detected more accurately based on my exact area rather than my countery, as there are many countries with more than one popular language. Maps, navigation, emergency calls and many other services will also get enhanced with accurate locations. I hope you will find my suggestion beneficial, and looking forward to hearing from you. Best, Ammar Salih | B.Sc.Eng, CCNA-S, CCVP, CCIE-V written Technical Lead - Voice and Data Support Services Mob: +964 (0) 770 533 0306 Office: +964 (0) 53 511 2020 - Ext. 2221 Email: ammar.salih@auis.edu.iq The American University of Iraq - Sulaimani ------=_NextPart_000_003A_01CDA70F.FEE91A90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Dears,

 

I would like to suggest = adding GPS coordinates to IPv6 header, as you know the current way of = determining the location of the IP address is through the IP = registration, which is not very accurate as it depends on how the ISP = registers it’s IP subnets, which is normally done based on = country/city.

 

Getting more accurate = locations will enhance many services provided by the web, like targeted = commercials (for example, I can get Ads regarding restaurants available = in my neighborhood instead of all restaurants in the city), another good = example would be webpage’s language, my language will be detected = more accurately based on my exact area rather than my countery, as there = are many countries with more than one popular = language.

 

Maps, navigation, = emergency calls and many other services will also get enhanced with = accurate locations.

 

I hope you will find my = suggestion beneficial, and looking forward to hearing from = you.

 

 

Best,

 

Ammar Salih | B.Sc.Eng, CCNA-S, CCVP, CCIE-V = written

Technical Lead - Voice and Data = Support Services

 

Mob: +964 (0) 770 533 = 0306 

Office: +964 (0) 53 511 2020  = -  Ext. 2221

Email: ammar.salih@auis.edu.iq

The American University of Iraq = – Sulaimani

 

<= p class=3DMsoNormal> 

------=_NextPart_000_003A_01CDA70F.FEE91A90-- From brian@innovationslab.net Wed Oct 10 10:25:51 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFBA21F86DD; Wed, 10 Oct 2012 10:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.473 X-Spam-Level: X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEieY6Dj2b3D; Wed, 10 Oct 2012 10:25:50 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id CC20921F86D6; Wed, 10 Oct 2012 10:25:50 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 78C0F880A5; Wed, 10 Oct 2012 10:25:50 -0700 (PDT) Received: from clemson.local (nat-gwifi.jhuapl.edu [128.244.87.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id ACD493200B4; Wed, 10 Oct 2012 10:25:49 -0700 (PDT) Message-ID: <5075AF9C.80204@innovationslab.net> Date: Wed, 10 Oct 2012 13:25:48 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: Stewart Bryant's Discuss on draft-ietf-6man-udpzero-06: (with DISCUSS and COMMENT) References: <013e01cda61c$1ff13910$5fd3ab30$@olddog.co.uk> <50741EF0.9000208@innovationslab.net> <50753234.3070703@ericsson.com> In-Reply-To: <50753234.3070703@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-udpchecksums@tools.ietf.org, ipv6@ietf.org, 'The IESG' , adrian@olddog.co.uk, draft-ietf-6man-udpzero@tools.ietf.org, stbryant@cisco.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 17:25:51 -0000 On 10/10/12 4:30 AM, Magnus Westerlund wrote: > On 2012-10-09 14:56, Brian Haberman wrote: >> On 10/9/12 8:46 AM, Adrian Farrel wrote: >>> Are we in the weeds yet? >> >> I believe we are. > > Likely, but the weeds here are fascinating and possibly relevant. > Given what you say below, I am not sure how relevant it is (regardless of the fascination factor). > >> >> Agreed. As long as there is a robust L-2, the chance of in-transit >> errors is low. If MPLS is predominantly carried over Ethernet, I >> suspect the Ethernet CRC is providing sufficient/significant protection. > > I think you are missing one point of the following reference: > [Sigcomm2000] > Jonathan Stone and Craig Partridge , , "When the CRC and > TCP Checksum Disagree", 2000. > > That is that this paper found a significant amount of erroneous packets > where the UDP or TCP checksum discarded the packet, not the L2 CRCs. The > whole point of the paper is trying to analyze what type and why their is > errors that only the transport checksums detects. If your comment about missing the point of the above paper is directed to me, it is quite the opposite. Given that I was involved in those 6MAN WG discussions about this draft, I have a good understanding of the questions raised by the paper. > > When the topic of UDP checksums was discussed in the WG it was > questioned if this now 12 year old paper was still relevant. People in > the WG went looking at their network interface stats and found that > several different machines has UDP checksum discard rates that was > higher than one every 1000 packets. So yes there is still a lot of > packets being discard in the destination host due to transport > checksums. If "Why" has changed we don't know because someone needs to > repeat the study Stone and Partridge did. > > I would not be surprised if there is differences between IP routing, > especially at the edge and MPLS label switching in regards to error > characteristics. Completely agreed. > > I think my main point around this whole issue is that you have to be > careful to understand the environment and what mitigating factors that > may exist so that you don't see these issues. > Yes! And that is why the draft is currently restricting the UDP checksum value of 0 to tunneling protocols. I don't see any justification, at *this* time, to loosen the rules in general. > I am fine with updating the text to better reflect reality. However, I > don't understand this MPLS and PW area sufficiently to determine what > error factors and saving graces that happens to be built into the system. > > The whole point of the argumentation and checklist is. Checksums are > there for a reason. IF you have analyzed it the implications of turning > of the checksum and what it means to use a particular protocol header > field that is now unprotected then yes you can go ahead and use it. > > But don't forget how other users of the network might suffer from your > traffic. Right. This leads me to believe that the draft should remain focused on allowing tunneling protocols to use checksum=0 when the encapsulated payload is protected by a checksum. Regards, Brian From stbryant@cisco.com Wed Oct 10 10:38:02 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA1521F877D; Wed, 10 Oct 2012 10:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.45 X-Spam-Level: X-Spam-Status: No, score=-110.45 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cp-cTUlavpH; Wed, 10 Oct 2012 10:38:01 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id D0E3E21F8735; Wed, 10 Oct 2012 10:38:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=414; q=dns/txt; s=iport; t=1349890681; x=1351100281; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=O+aeEIr3daXLsd9YdPQK+nlb7zK0mD8F3nZIqICH1FI=; b=Jw7m47zBSaU8CLQLjGVJbmWW3uOqR57Uw2S2IYpW+whnbNaRtuH9BsIP P7AONh7AgIbP/1fVSQUo/wE93V/mjcThQIfUrYmhppiogVyKXzB8znJ7f NhfXxtOCFJe7cBaNQCisp07GeoNfU86Cdg58250cJJbTIEdo0s6pI0bTv Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHyxdVCQ/khL/2dsb2JhbABEvzGBCIIgAQEBAwESAQIjQAEFCwshFg8JAwIBAgFFBg0BBwEBHodcBpdTg0wQnEWRZwOVbI5FgQZlgm4 X-IronPort-AV: E=Sophos;i="4.80,565,1344211200"; d="scan'208";a="145107952" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 10 Oct 2012 17:37:59 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9AHbxKx002141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Oct 2012 17:37:59 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q9AHbo6Z018374; Wed, 10 Oct 2012 18:37:52 +0100 (BST) Message-ID: <5075B26D.4060702@cisco.com> Date: Wed, 10 Oct 2012 18:37:49 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Brian Haberman Subject: Re: Stewart Bryant's Discuss on draft-ietf-6man-udpzero-06: (with DISCUSS and COMMENT) References: <013e01cda61c$1ff13910$5fd3ab30$@olddog.co.uk> <50741EF0.9000208@innovationslab.net> <50753234.3070703@ericsson.com> <5075AF9C.80204@innovationslab.net> In-Reply-To: <5075AF9C.80204@innovationslab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, draft-ietf-6man-udpchecksums@tools.ietf.org, 'The IESG' , adrian@olddog.co.uk, draft-ietf-6man-udpzero@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 17:38:02 -0000 > Right. This leads me to believe that the draft should remain focused > on allowing tunneling protocols to use checksum=0 when the > encapsulated payload is protected by a checksum. I would phrase this as "the draft should allow tunneling protocols to use checksum=0 and assume that the encapsulated payload is protected by a checksum." Since that is what is going to happen in practice. Stewart From aservin@lacnic.net Wed Oct 10 11:58:29 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEAE21F8503 for ; Wed, 10 Oct 2012 11:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.833 X-Spam-Level: X-Spam-Status: No, score=-2.833 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qV7m2B8Lm+X for ; Wed, 10 Oct 2012 11:58:29 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id CDE2721F84F2 for ; Wed, 10 Oct 2012 11:58:28 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy (unknown [IPv6:2001:13c7:7001:5128:c4c7:ad11:48db:5011]) by mail.lacnic.net.uy (Postfix) with ESMTP id 7C148308445 for ; Wed, 10 Oct 2012 16:58:17 -0200 (UYST) Message-ID: <5075C549.7010900@lacnic.net> Date: Wed, 10 Oct 2012 16:58:17 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121005 Thunderbird/16.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: IPv6 modification suggestion References: <50758ba5.e956420a.71b1.6dbb@mx.google.com> In-Reply-To: <50758ba5.e956420a.71b1.6dbb@mx.google.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 18:58:29 -0000 I would not support to add GPS coordinates to the IPv6 header. I think it violates the user privacy. As a user, I sometimes want to disclosure my position, but only to services that I know and I want to. I wouldn't want to do it automatically to the whole Internet. I would give more counter arguments to some of the advantages that you mentioned, but I think privacy is the most important. Regards as On 10/10/2012 12:52, Ammar Salih wrote: > Hello Dears, > > > > I would like to suggest adding GPS coordinates to IPv6 header, as you > know the current way of determining the location of the IP address is > through the IP registration, which is not very accurate as it depends on > how the ISP registers it’s IP subnets, which is normally done based on > country/city. > > > > Getting more accurate locations will enhance many services provided by > the web, like targeted commercials (for example, I can get Ads regarding > restaurants available in my neighborhood instead of all restaurants in > the city), another good example would be webpage’s language, my language > will be detected more accurately based on my exact area rather than my > countery, as there are many countries with more than one popular language. > > > > Maps, navigation, emergency calls and many other services will also get > enhanced with accurate locations. > > > > I hope you will find my suggestion beneficial, and looking forward to > hearing from you. > > > > > > Best, > > > > *Ammar Salih *|***B.Sc.Eng, CCNA-S, CCVP, CCIE-V written* > > Technical Lead - Voice and Data Support Services > > > > *Mob*: +964 (0) 770 533 0306 > > *Office*: +964 (0) 53 511 2020 - Ext. 2221 > > *Email*:ammar.salih@auis.edu.iq > > *The American University of Iraq – Sulaimani* > > * * > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From rpaulo@apple.com Wed Oct 10 12:21:53 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A2321F8605 for ; Wed, 10 Oct 2012 12:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbRWZ4jJNOVq for ; Wed, 10 Oct 2012 12:21:51 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id E2CF221F8516 for ; Wed, 10 Oct 2012 12:21:48 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Received: from relay17.apple.com ([17.128.113.18]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MBO00JJ5YWMG1W0@mail-out.apple.com> for ipv6@ietf.org; Wed, 10 Oct 2012 12:21:24 -0700 (PDT) X-AuditID: 11807112-b7f286d000000c4e-0c-5075cab391fa Received: from rui-macbook-pro.apple.com (rui-macbook-pro.apple.com [17.193.13.39]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay17.apple.com (Apple SCV relay) with SMTP id 15.36.03150.4BAC5705; Wed, 10 Oct 2012 12:21:24 -0700 (PDT) Subject: Re: 6MAN WG Last Call: From: Rui Paulo In-reply-to: <0D1941A7-217D-44E1-A3E3-45D30D51A273@employees.org> Date: Wed, 10 Oct 2012 12:21:23 -0700 Content-transfer-encoding: quoted-printable Message-id: <2E1F7C5A-3642-47C1-91B8-9E08270AE1CD@apple.com> References: <0D1941A7-217D-44E1-A3E3-45D30D51A273@employees.org> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1498) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUieJBXXXfLqdIAg7f/WSwWdDaxWrw8+57J YnLbCjYHZo+Dxz4yeixZ8pPJ48vlz2wBzFFcNimpOZllqUX6dglcGY/Ob2Et2MxSMX/9LNYG xhXMXYwcHBICJhJ3b9l3MXICmWISF+6tZ+ti5OIQEljJJPFxeSMLSIJZQEdi59Y7bCD1vAJ6 Equ6eUDCwgIeEsuvnGQFsdkElCSe9Z1gB7E5BRwl5nyfywRiswioSjx/0c4K0soskCPx+GAQ xERtiWULXzOD2LwCNhJHJneC2UICDhK/GtYxgtgiAuYSTfO+sECcJitx78VvtgmM/LOQHDQL 4aBZSKYuYGRexShYlJqTWGlorpdYUJCTqpecn7uJERSCDYVCOxjv79I7xCjAwajEw/tidWmA EGtiWXFl7iFGCQ5mJRHea8eAQrwpiZVVqUX58UWlOanFhxilOViUxHnDlpcECAmkJ5akZqem FqQWwWSZODilGhgDJO6+2qd1bMmm/VF7jxbf+sjy8m3BYu5v3LF/Lspt+lkft/eXipCDKGPz xDx2PqMLE8X7m2RLTbfPlPj9VvHSxX96d06Y80mUfmfxl33KvevI65KjYY7qc9hVg8pMvrw8 0vde6CPL1fLYZgXtk3/53i6QW7I1Xuv6MS4Jwdqw2Cp7N/WI1KNKLMUZiYZazEXFiQAY0oIw PQIAAA== Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org>, "ipv6@ietf.org 6man" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 19:21:53 -0000 On 10 Oct 2012, at 01:28, Ole Tr=F8an wrote: > This message starts a two week 6MAN Working Group on advancing: >=20 > Title : Distributing Address Selection Policy using = DHCPv6 > Author(s) : A. Matsumoto, T. Fujisaki, T. Chown > Filename : draft-ietf-6man-addr-select-opt-06.txt > Pages : 10 > Date : 2012-09-21 >=20 > http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-06 Support, but agree with Ray Hunter's discussion request / = clarifications. -- Rui Paulo From markzzzsmith@yahoo.com.au Wed Oct 10 12:43:52 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA7821F8433 for ; Wed, 10 Oct 2012 12:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpBPCSUCYH8W for ; Wed, 10 Oct 2012 12:43:49 -0700 (PDT) Received: from nm6.bullet.mail.sp2.yahoo.com (nm6.bullet.mail.sp2.yahoo.com [98.139.91.76]) by ietfa.amsl.com (Postfix) with ESMTP id 31F3821F8608 for ; Wed, 10 Oct 2012 12:43:49 -0700 (PDT) Received: from [72.30.22.79] by nm6.bullet.mail.sp2.yahoo.com with NNFMP; 10 Oct 2012 19:43:43 -0000 Received: from [72.30.22.39] by tm13.bullet.mail.sp2.yahoo.com with NNFMP; 10 Oct 2012 19:43:43 -0000 Received: from [127.0.0.1] by omp1069.mail.sp2.yahoo.com with NNFMP; 10 Oct 2012 19:43:43 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 769606.90421.bm@omp1069.mail.sp2.yahoo.com Received: (qmail 36738 invoked by uid 60001); 10 Oct 2012 19:43:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1349898223; bh=VOKFL+N16yclCqMGPjofnAk47Y/1V/0s48mBVfXxXV4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=RmMxzNgV/lBGE3rdtbq5BHS+bU69DHLqh7+eGBBWBlY/+H0CSM2zQP22YyDzfGa61JtfsZu498RKdtaYozJQ9v0OGTtvtLTDAKJ8VWIowoOXupSopZJBKhQMlBFfDmmdYugEisb0zoBJdts1B/PN9kFSxwUp5tVKWQCfZr9DhbM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=l3xXb0nLZQi5kWxgwyz+QtypXsOff9aqSa3Of2k4Ov4bxaVsGn32Z6XGQ57NbagGPdFD9DoEx1aHZfhCw8oOLKcD4ahd4aRX0E0gWZV/EeSUkeRXoNjgRXH4HxtPY/DREFw1cVEc0hl0ccVB7U/aKMdf21B47nRU1voKQ7f+OT0=; X-YMail-OSG: vuoriLgVM1kvtEYU9mqELBmyyzHRDphB1r7HqVtac8f7PV5 JxDVNsMf0rgY9Ucv.Xnp.dN8TCe8LCqkXGLxa.lvlOCJ_xgtsC6xh06N_771 6Lrom_SLsHa0TQv_IKSa6Au2Wsjb8KREX_THuHRXMoHPkIITIAwNdmaGkmTa b5MvE_w0M1sJnWXFxozq5Af2sqdBnjssPVTyqTGYo1WdQv.JZcpUqX7pnXUB VwA3LayJGsojttbuT2a5zYk0MToFFdToRB4zrGIfFNkOI4hktPhhP_DS.gwK jYphd7HKxwTFHoWS5Bx6WR4NrZCVSX_1Q.C5qmoCtQr2r1yZCuh9u5ZvK7R2 cYEV42SbVxyIpm9X6hbDobs781IYh0WFQC7uAHJNqh63Zbed7py7eT5P1IBG vpyEyiCM12kl7yYLUvPoL8QSoyqhQtStU95Ec8iOJtyvy7vxv4ISvykcV6kL Gw2456Gq.NmnKQ6kQRRmXWlcrXPkTRuXDWZG9cKdPnOHeKNwKeU2fmLSC3AR mncbHrxElzQjB Received: from [150.101.221.237] by web32507.mail.mud.yahoo.com via HTTP; Wed, 10 Oct 2012 12:43:42 PDT X-Rocket-MIMEInfo: 001.001, SGksCgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo.IEZyb206IFJ1aSBQYXVsbyA8cnBhdWxvQGFwcGxlLmNvbT4KPiBUbzogImlwdjZAaWV0Zi5vcmcgTWFpbGluZyBMaXN0IiA8aXB2NkBpZXRmLm9yZz4KPiBDYzogCj4gU2VudDogV2VkbmVzZGF5LCAxMCBPY3RvYmVyIDIwMTIgNjoyNSBBTQo.IFN1YmplY3Q6IFJlOiA2TUFOIFdHIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtNm1hbi1uZC1leHRlbnNpb24taGVhZGVycy0wMC50eHQ.Cj4gCj4gT24gNCBPY3QgMjAxMiwgYXQgMTQ6NTMsIEJvYiBIaW4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.450 References: <67F311F3-363E-4870-A3AD-643BFC6D2978@gmail.com> <897E7BDE-DB8A-400F-8E22-996FA6C87096@apple.com> Message-ID: <1349898222.11668.YahooMailNeo@web32507.mail.mud.yahoo.com> Date: Wed, 10 Oct 2012 12:43:42 -0700 (PDT) From: Mark ZZZ Smith Subject: Re: 6MAN WG Last Call: To: "ipv6@ietf.org Mailing List" In-Reply-To: <897E7BDE-DB8A-400F-8E22-996FA6C87096@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 19:43:52 -0000 Hi,=0A=0A=0A----- Original Message -----=0A> From: Rui Paulo =0A> To: "ipv6@ietf.org Mailing List" =0A> Cc: =0A> Sent= : Wednesday, 10 October 2012 6:25 AM=0A> Subject: Re: 6MAN WG Last Call: =0A> =0A> On 4 Oct 2012, at 14:5= 3, Bob Hinden wrote:=0A> =0A>> All,=0A>> =0A>> Thi= s message starts a two week 6MAN Working Group on advancing:=0A>> =0A>> = =A0=A0=A0 Title=A0 =A0 =A0 =A0 =A0 : Security Implications of the Use of I= Pv6 Extension =0A> Headers with IPv6 Neighbor Discovery=0A>> =A0=A0=A0 Aut= hor(s)=A0 =A0 =A0 : Fernando Gont=0A>> =A0=A0=A0 Filename=A0 =A0 =A0 =A0 = : draft-ietf-6man-nd-extension-headers-00.txt=0A>> =A0=A0=A0 Pages=A0 =A0 = =A0 =A0 =A0 : 12=0A>> =A0=A0=A0 Date=A0 =A0 =A0 =A0 =A0 =A0 : 2012-06-29= =0A>> =0A>> =A0 =A0 =A0 http://tools.ietf.org/html/draft-ietf-6man-nd-exten= sion-headers-00=0A>> =0A>> as Proposed Standard.=A0 Substantive comments a= nd statements of support for =0A> advancing this document should be directe= d to the mailing list.=A0 Editorial =0A> suggestions can be sent to the aut= hors.=A0 This last call will end on 18 October =0A> 2012.=0A> =0A>=A0=0A=0A= I support.=0A=0AIt might be worth also mentioning Inverse ND (RFC3122), as = it potentially could have created large ND packets that needed fragmentatio= n with long lists of addresses in NAs. I've skimmed through it, and it seem= s to have specifically not done so (multiple neighbor advertisements are se= nt if the address list is too long for a single NA), although it uses the t= erm "message" rather than "packet". I don't seem to be able to find an abso= lute statement that says "message" =3D packet, so a misinterpretation could= be that a single "message" could be built and then fragmented into multipl= e packets for transmission.=0A=0ARegards,=0AMark. From george+ipng@m5p.com Wed Oct 10 17:05:39 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBD21F0425 for ; Wed, 10 Oct 2012 17:05:39 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4pkbJvIsQuM for ; Wed, 10 Oct 2012 17:05:38 -0700 (PDT) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by ietfa.amsl.com (Postfix) with ESMTP id A83DF1F041F for ; Wed, 10 Oct 2012 17:05:38 -0700 (PDT) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id q9B05K9j043635 for ; Wed, 10 Oct 2012 20:05:26 -0400 (EDT) (envelope-from george+ipng@m5p.com) Message-ID: <50760D40.9000404@m5p.com> Date: Wed, 10 Oct 2012 20:05:20 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120923 Thunderbird/15.0.1 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: IPv6 modification suggestion References: <50758ba5.e956420a.71b1.6dbb@mx.google.com> In-Reply-To: <50758ba5.e956420a.71b1.6dbb@mx.google.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.24 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Wed, 10 Oct 2012 20:05:34 -0400 (EDT) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 00:05:39 -0000 On 10/10/12 10:52, Ammar Salih wrote: > Hello Dears, > > I would like to suggest adding GPS coordinates to IPv6 header, as you > know the current way of determining the location of the IP address is > through the IP registration, which is not very accurate as it depends on > how the ISP registers it’s IP subnets, which is normally done based on > country/city. > > Getting more accurate locations will enhance many services provided by > the web, like targeted commercials (for example, I can get Ads regarding > restaurants available in my neighborhood instead of all restaurants in > the city), another good example would be webpage’s language, my language > will be detected more accurately based on my exact area rather than my > countery, as there are many countries with more than one popular language. > > Maps, navigation, emergency calls and many other services will also get > enhanced with accurate locations. > > I hope you will find my suggestion beneficial, and looking forward to > hearing from you. > > Best, > > *Ammar Salih *|***B.Sc.Eng, CCNA-S, CCVP, CCIE-V written* > > Technical Lead - Voice and Data Support Services > > *Mob*: +964 (0) 770 533 0306 > > *Office*: +964 (0) 53 511 2020 - Ext. 2221 > > *Email*:ammar.salih@auis.edu.iq > > *The American University of Iraq – Sulaimani* > > ** > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > Sensational idea. Don't forget to leave space for the cryptographic signature to forestall forgery. I look forward to seeing tens of packets following this standard over the next hundred years. -- George Mitchell From sm@resistor.net Wed Oct 10 17:53:17 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76B421F8607 for ; Wed, 10 Oct 2012 17:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rk0GHWxRDcdQ for ; Wed, 10 Oct 2012 17:53:17 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A15421F8594 for ; Wed, 10 Oct 2012 17:53:17 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q9B0r7I6001035; Wed, 10 Oct 2012 17:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1349916791; bh=J818mD1eWtEs4iUu/QLulhjJFAa8CGsDOhQskG54u5U=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ESIy6QqZwyLBAxfkI+1N6EFqYs3+OOJOYz86gNOtRhrEaPxhR6zFcWtcWnRlKEHTF Vpn2jGVKUAzdTXpy5Rkv4v6b1XwTnNi1Grby2PgLJJXNNGzLLxkeLNL3+aTt7RYMAO ScmD6YU0mvEdRE46UiBLD45GMGDmwoB84zSLY+zE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1349916791; i=@resistor.net; bh=J818mD1eWtEs4iUu/QLulhjJFAa8CGsDOhQskG54u5U=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ftUo/38M4pWO8EtuBetf5iy4cT2vRiEkrq2JxXip8lAw0MZGpMdKdStmNqzINlazs sBaTlYN6lMelBNulvh80YbzM29nHboPVYFtlsbrqYjLvZvy+iWDBiAHvARK9EDXoCt WWEoSQcqFPe1r2yRofaruZ3oHJ6NgcG+mWJK0AJQ= Message-Id: <6.2.5.6.2.20121010174943.0ab78a48@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 10 Oct 2012 17:52:30 -0700 To: "Ammar Salih" From: SM Subject: Re: IPv6 modification suggestion In-Reply-To: <50758ba5.e956420a.71b1.6dbb@mx.google.com> References: <50758ba5.e956420a.71b1.6dbb@mx.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 00:53:17 -0000 Hi Ammar, At 07:52 10-10-2012, Ammar Salih wrote: >I would like to suggest adding GPS coordinates to IPv6 header, as >you know the current way of determining the location of the IP >address is through the IP registration, which is not very accurate >as it depends on how the ISP registers it's IP subnets, which is >normally done based on country/city. Please see the work of the GEOPRIV WG ( https://datatracker.ietf.org/wg/geopriv/charter/ ). >Getting more accurate locations will enhance many services provided >by the web, like targeted commercials (for example, I can get Ads >regarding restaurants available in my neighborhood instead of all >restaurants in the city), another good example would be webpage's >language, my language will be detected more accurately based on my >exact area rather than my countery, as there are many countries with >more than one popular language. > >Maps, navigation, emergency calls and many other services will also >get enhanced with accurate locations. The above are arguments in favor of such a functionality. What are the disadvantages? Regards, -sm From rbonica@juniper.net Wed Oct 10 20:10:07 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B7B1F0C55; Wed, 10 Oct 2012 20:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.375 X-Spam-Level: X-Spam-Status: No, score=-106.375 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1o2RgPH-7L7g; Wed, 10 Oct 2012 20:09:54 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 2B29F1F0C3E; Wed, 10 Oct 2012 20:09:50 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUHY4YYrZpnvhWOJHRMuw4k4C1ooQqnju@postini.com; Wed, 10 Oct 2012 20:09:53 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 10 Oct 2012 20:05:05 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 10 Oct 2012 23:05:04 -0400 From: Ronald Bonica To: Magnus Westerlund Date: Wed, 10 Oct 2012 23:05:02 -0400 Subject: RE: Ronald Bonica's Discuss on draft-ietf-6man-udpzero-06: (with DISCUSS) Thread-Topic: Ronald Bonica's Discuss on draft-ietf-6man-udpzero-06: (with DISCUSS) Thread-Index: Ac2mxZKr4wqdE9U+Rven3Zoyz+FfkQAk4upw Message-ID: <13205C286662DE4387D9AF3AC30EF456D783A25412@EMBX01-WF.jnpr.net> References: <20121009185726.29097.69699.idtracker@ietfa.amsl.com> <507538F1.5080505@ericsson.com> In-Reply-To: <507538F1.5080505@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "ipv6@ietf.org" , "draft-ietf-6man-udpzero@tools.ietf.org" , The IESG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 03:10:07 -0000 TWFnbnVzLA0KDQpJIHRoaW5rIHRoYXQgd2UgYXJlIG9uIHRoZSBzYW1lIHBhZ2UgYW5kIEkgYW0g bmVhcmx5IHJlYWR5IHRvIGNsZWFyIG15IERJU0NVU1MuIA0KDQpXb3VsZCB5b3UgYmUgd2lsbGlu ZyB0byBhZGQgYSBzaG9ydCBzZWN0aW9uIGluIGFuIEFwcGVuZGl4IHRoYXQgaWxsdXN0cmF0ZXMg dGhlIGtpbmQgb2YgYW5hbHlzaXMgdGhhdCB5b3UgYXJlIHJlcXVpcmluZyBvZiBhIHByb3RvY29s IHRoYXQgd2FudHMgdG8gcmVseSBvbiBVRFBaZXJvPyBJIGFtIHRoaW5raW5nIG9mIHNvbWV0aGlu ZyBsaWtlIHRoZSBmb2xsb3dpbmc6DQoNClNhbXBsZSBUZXh0DQo9PT09PT09PT09PQ0KUHJvdG9j b2wgRm9vIGVuY2Fwc3VsYXRlcyBhbiBJUCBkYXRhZ3JhbSB3aXRoaW4gdGhlIGZvbGxvd2luZzoN Cg0KLSBhIGZvbyBoZWFkZXINCi0gYSBVRFAgaGVhZGVyDQotIGFuIG91dGVyIElQdjYgaGVhZGVy DQoNCkJlY2F1c2UgdGhlIFVEUCBjaGVja3N1bSBpcyBzZXQgdG8gemVybywgdGhlIGZvbGxvd2lu ZyBmaWVsZHMgYXJlIHVucHJvdGVjdGVkOg0KDQotIGZvbyBoZWFkZXI6IGZpZWxkMQ0KLSBmb28g aGVhZGVyOiBmaWVsZDINCi0gVURQIGhlYWRlcjogc291cmNlIHBvcnQNCi0gVURQIGhlYWRlcjog ZGVzdGluYXRpb24gcG9ydA0KLSBvdXRlciBJUHY2IGhlYWRlcjogc291cmNlIGFkZHJlc3MNCi0g b3V0ZXIgSVB2NiBoZWFkZXI6IGRlc3RpbmF0aW9uICBhZGRyZXNzDQoNClRoZSBjb25zZXF1ZW5j ZSBvZiBjb3JydXB0aW9uIGluIGZpZWxkMSBvZiB0aGUgZm9vIGhlYWRlciBpcyBtdW1ibGUuIFRo ZSBjb25zZXF1ZW5jZSBvZiBjb3JydXB0aW9uIGluIGZpZWxkMiBvZiB0aGUgZm9vIGhlYWRlciBp cyBncnVtYmxlLCBidXQgb25seSBpZiBzb21lIG90aGVyIGNvbmRpdGlvbiBpcyB0cnVlLiBUaGUg Y29uc2VxdWVuY2Ugb2YgY29ycnVwdGlvbiBpbiBhbnkgb3RoZXIgZmllbGQgaXMsIGF0IHdvcnN0 LCBsb3NzIG9mIHRoZSBwYWNrZXQuDQoNCkFzc3VtZSBhIHR1bm5lbCB3aXRoIHRoZSBmb2xsb3dp bmcgY2hhcmFjdGVyaXN0aWNzOg0KDQotIHN1c3RhaW5lZCBkYXRhIHJhdGUgb2YgMSBHYnBzDQot IEJpdCBlcnJvciByYXRlIG9mIDEwKiotMTIgb24gZWFjaCBvZiA0IGNvbnN0aXR1ZW50IGxpbmtz DQotIGF2ZXJhZ2UgcGFja2V0IHNpemUgZXF1YWwgdG8gMTUwMCBieXRlcw0KDQpUaGUgYnVsbGV0 IGxpc3QsIGJlbG93LCBwcm92aWRlcyBhbiBlc3RpbWF0ZSBvZiB0aGUgZnJlcXVlbmN5IHdpdGgg d2hpY2ggZWFjaCBvZiB0aGUgYWJvdmUgbWVudGlvbmVkIGZpZWxkcyB3aWxsIGJlIGNvcnJ1cHRl ZDoNCg0KLSBmb28gaGVhZGVyOiBmaWVsZDEgKG9uY2UgcGVyIE4gc2Vjb25kcykNCi0gZm9vIGhl YWRlcjogZmllbGQyIChvbmNlIHBlciBOIHNlY29uZHMpDQotIFVEUCBoZWFkZXI6IHNvdXJjZSBw b3J0IChvbmNlIHBlciBOIHNlY29uZHMpDQotIFVEUCBoZWFkZXI6IGRlc3RpbmF0aW9uIHBvcnQg KG9uY2UgcGVyIE4gc2Vjb25kcykNCi0gb3V0ZXIgSVB2NiBoZWFkZXI6IHNvdXJjZSBhZGRyZXNz IChvbmNlIHBlciBOIHNlY29uZHMpDQotIG91dGVyIElQdjYgaGVhZGVyOiBkZXN0aW5hdGlvbiAg YWRkcmVzcyAob25jZSBwZXIgTiBzZWNvbmRzKQ0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KRW5kIHNhbXBsZSB0ZXh0DQoNCkRvZXMgdGhpcyBzb3VuZCByZWFzb25hYmxlPw0KDQogICAg ICAgICAgICAgICAgICAgICAgICBSb24NCg0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBNYWdudXMgV2VzdGVybHVuZCBbbWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5k QGVyaWNzc29uLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDEwLCAyMDEyIDQ6NTkg QU0NCj4gVG86IFJvbmFsZCBCb25pY2ENCj4gQ2M6IFRoZSBJRVNHOyA2bWFuLWNoYWlyc0B0b29s cy5pZXRmLm9yZzsgZHJhZnQtaWV0Zi02bWFuLQ0KPiB1ZHB6ZXJvQHRvb2xzLmlldGYub3JnOyBp cHY2QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBSb25hbGQgQm9uaWNhJ3MgRGlzY3VzcyBvbiBk cmFmdC1pZXRmLTZtYW4tdWRwemVyby0wNjoNCj4gKHdpdGggRElTQ1VTUykNCj4gDQo+IE9uIDIw MTItMTAtMDkgMjA6NTcsIFJvbmFsZCBCb25pY2Egd3JvdGU6DQo+ID4gUm9uYWxkIEJvbmljYSBo YXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gPiBkcmFmdC1p ZXRmLTZtYW4tdWRwemVyby0wNjogRGlzY3Vzcw0KPiA+DQo+ID4gV2hlbiByZXNwb25kaW5nLCBw bGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+ID4g ZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZy ZWUgdG8gY3V0DQo+ID4gdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4g Pg0KPiA+DQo+ID4gUGxlYXNlIHJlZmVyIHRvDQo+ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9pZXNn L3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4gPiBmb3IgbW9yZSBpbmZvcm1hdGlv biBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiA+DQo+ID4NCj4g Pg0KPiA+DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0NCj4gPiBESVNDVVNTOg0KPiA+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiAtDQo+ID4NCj4gPiBUaGlzIGlzIGEgdHdvLXBhcnQgRElTQ1VTUy1ESVNDVVNTLiBC b3RoIHBhcnRzIHJlbGF0ZSB0byBidWxsZXQNCj4gcG9pbnRzDQo+ID4gaW4gU2VjdGlvbiA1LjEu DQo+ID4NCj4gPiBCdWxsZXQgNQ0KPiA+ID09PT09PQ0KPiA+ICJUdW5uZWxzIHRoYXQgZW5jYXBz dWxhdGUgSVAgbWF5IHJlbHkgb24gdGhlIGlubmVyIHBhY2tldA0KPiA+ICAgaW50ZWdyaXR5IGNo ZWNrcyBwcm92aWRlZCB0aGF0IHRoZSB0dW5uZWwgd2lsbCBub3Qgc2lnbmlmaWNhbnRseQ0KPiA+ ICAgaW5jcmVhc2UgdGhlIHJhdGUgb2YgY29ycnVwdGlvbiBvZiB0aGUgaW5uZXIgSVAgcGFja2V0 LiINCj4gPg0KPiA+IC0gV2hhdCBkb2VzIGl0IG1lYW4gdG8gKnNpZ25pZmljYW50bHkqIGluY3Jl YXNlIHRoZSByYXRlIG9mDQo+IGNvcnJ1cHRpb24NCj4gPiBvZiB0aGUgaW5uZXIgSVAgcGFja2V0 Pw0KPiANCj4gVGhhdCBpcyBhIGdvb2QgcXVlc3Rpb24uIEFuZCB0aGUgYW5zd2VyIGlzIGl0IGRl cGVuZHMuIElmIHlvdSBhcmUNCj4gY29uc2lkZXJpbmcgYSB0dW5uZWwgcHJvdG9jb2xzIHdoaWNo IHRhcmdldCBkZXBsb3ltZW50IGFyZWEgaXMgb25lDQo+IHdoZXJlIHlvdSBoYXZlIHZlcnkgbG93 IHJhdGVzIG9mIGNvcnJ1cHRpb24sIGxldHMgc2F5IGJlbG93IDEwXi02IHRoZW4NCj4gYSBmYWN0 b3Igb2YgMiBvciBldmVuIDEwIG1pZ2h0IGJlIGZpbmUgYXMgdGhlIHJlc3VsdGluZyBlbmQtdG8t ZW5kDQo+IGJhc2ljIElQIHNlcnZpY2UgbWF5IHN0aWxsIGJlIGZpbmUuIEJ1dCBpZiB0aGF0IHNh bWUgdHVubmVsIGlzIHN1cHBvc2VkDQo+IHRvIHN1cHBvcnQgc29tZXRoaW5nIHRoYXQgcmVxdWly ZXMgYSBwYWNrZXQgbG9zcyByYXRlIGJlbG93IDEwXi02IHRoZW4NCj4gYW55IGluY3JlYXNlIGlu IGNvcnJ1cHRpb24gbWlnaHQgYmUgdG8gaGlnaC4NCj4gDQo+ID4gLSBTaG91bGRuJ3Qgd2UgYWxz byBiZSBjb25jZXJuZWQgYWJvdXQgY29ycnVwdGlvbiBvZiB0aGUgVURQIGhlYWRlcg0KPiA+IGFu ZCBhbnkgYWRkaXRpb25hbCBlbmNhcHN1bGF0aW9uIHRoYXQgY29tZXMgYmV0d2VlbiB0aGUgVURQ IGhlYWRlcg0KPiBhbmQNCj4gPiB0aGUgaW5uZXIgSVAgcGFja2V0Pw0KPiANCj4gSSB0aGluayB0 aGUgZm9ybXVsYXRpb24gYWN0dWFsbHkgaXMgY29uc2lkZXJpbmcgdGhhdC4gSWYgdGhlDQo+IElQ djYvVURQL0ZPTyB0dW5uZWwgcHJvdG9jb2wgY2FycmllcyBJUCBhbmQgRk9PIGlzIHNlbmVzaXRp dmUgdG8NCj4gY29ycnVwdGlvbiB0aGVuIGlzbid0IHRoZSBwYXlsb2FkIG9mIHRoZSB0dW5uZWws IGkuZS4gdGhlIGlubmVyIElQDQo+IGdvaW5nIHRvIHN1ZmZlciBhbiBpbmNyZWFzZWQgY29ycnVw dGlvbiByYXRlLg0KPiANCj4gPiAtIEhvdyBkb2VzIGEgdHVubmVsIGluZ3Jlc3Mgbm9kZSBrbm93 IHdoZXRoZXIgdGhlIHR1bm5lbCB3aWxsDQo+ID4gc2lnbmlmaWNhbnRseSBpbmNyZWFzZSB0aGUg cmF0ZSBvZiBjb3JydXB0aW9uIG9mIHRoZSBpbm5lciBJUCBwYWNrZXQ/DQo+IA0KPiBUaGF0IGlz IHNvbWV0aGluZyB5b3UgaGF2ZSB0byBzdGF0aXN0aWNhbGx5IGFuYWx5emUgd2hlbiBkZXNpZ25p bmcgdGhlDQo+IHByb3RvY29sIGFuZCBkZWNpZGluZyBvbiB1c2luZyB6ZXJvLWNoZWNrc3VtLg0K PiANCj4gPg0KPiA+IEJ1bGxldCA3DQo+ID4gPT09PT0tDQo+ID4gICAgIiBVRFAgYXBwbGljYXRp b25zIHRoYXQgc3VwcG9ydCB1c2Ugb2YgYSB6ZXJvLWNoZWNrc3VtLCBzaG91bGQgbm90DQo+ID4g ICAgICAgIHJlbHkgdXBvbiBjb3JyZWN0IHJlY2VwdGlvbiBvZiB0aGUgSVAgYW5kIFVEUCBwcm90 b2NvbA0KPiA+ICAgICAgICBpbmZvcm1hdGlvbiAoaW5jbHVkaW5nIHRoZSBsZW5ndGggb2YgdGhl IHBhY2tldCkgd2hlbiBkZWNvZGluZw0KPiA+ICAgICAgICBhbmQgcHJvY2Vzc2luZyB0aGUgcGFj a2V0IHBheWxvYWQuICBJbiBwYXJ0aWN1bGFyLCB0aGUNCj4gPiAgICAgICAgYXBwbGljYXRpb24g bXVzdCBiZSBkZXNpZ25lZCBzbyB0aGF0IGNvcnJ1cHRpb24gb2YgdGhpcw0KPiA+ICAgICAgICBp bmZvcm1hdGlvbiBkb2VzIG5vdCByZXN1bHQgaW4gYWNjdW11bGF0ZWQgc3RhdGUgb3IgaW5jb3Jy ZWN0DQo+ID4gICAgICAgIHByb2Nlc3Npbmcgb2YgYSB0dW5uZWxlZCBwYXlsb2FkLiINCj4gPg0K PiA+IC0gSG93IGNvdWxkIGFueSBhcHBsaWNhdGlvbiBhY2hpZXZlIHRoaXMgZ29hbD8gUG9zc2li bHkgYnkgYW5hbHl6aW5nDQo+ID4gdGhlIGNvbnNlcXVlbmNlcyBpZiBhbnkgZmllbGQgaW4gdGhl IElQdjYgb3IgVURQIGhlYWRlciB3ZXJlDQo+IGNvcnJ1cHRlZD8NCj4gPiAoZHJhZnQtaWV0Zi02 bWFuLXVkcGNoZWNrc3VtcyBiZWdpbnMgdGhpcyBhbmFseXNpcy4pICBBZ2Fpbiwgd291bGRuJ3QN Cj4gPiB0aGUgYW5hbHlzaXMgaGF2ZSB0byBpbmNsdWRlIGFueSBhZGRpdGlvbmFsIGVuY2Fwc3Vs YXRpb24gdGhhdCBjb21lcw0KPiA+IGJldHdlZW4gdGhlIFVEUCBoZWFkZXIgYW5kIHRoZSBpbm5l ciBJUCBoZWFkZXI/DQo+IA0KPiBZZXMsIHRoaXMgaXMgYSBkZXNpZ24gYW5hbHlzaXMgd2hpY2gg aW5jbHVkZXMgdGhlIHR1bm5lbCBwcm90b2NvbHMNCj4gaGVhZGVycy4NCj4gDQo+ID4NCj4gPiAt IFdvdWxkbid0IHRoZSBhbmFseXNpcywgbWVudGlvbmVkIGFib3ZlLCBoYXZlIHRvIGluY2x1ZGUg YXNzdXJhbmNlcw0KPiA+IHJlZ2FyZGluZyB0aGUgY2FzZSB3aGVuIHRoZSBkZXN0aW5hdGlvbiBw b3J0IGlzIGNvcnJ1cHRlZD8NCj4gPiBTcGVjaWZpY2FsbHksIHdvdWxkIGl0IGhhdmUgdG8gaW5j bHVkZSBhIGd1YXJhbnRlZSB0aGF0IGlmIHRoZQ0KPiA+IGVuY2Fwc3VsYXRlZCBpbm5lciBwYWNr ZXQgd2VyZSBkZWxpdmVyZWQgdG8gYW55IHJhbmRvbWx5IGNob3NlbiBwb3J0LA0KPiA+IGl0IHdv dWxkIG5vdCBjYXVzZSBhbnkgaGFybSB0byB0aGUgYXBwbGljYXRpb24gbGlzdGVuaW5nIG9uIHRo YXQNCj4gcG9ydD8NCj4gDQo+IENsZWFybHkgaXQgY2FuJ3QgaW5jbHVkZSBhIGd1YXJhbnRlZSB0 aGF0IGl0IHdpbGwgbm90IGhhcm0gd2hhdCBldmVyIGlzDQo+IGF0IHRoZSByYW5kb21seSBjaG9z ZW4gcG9ydC4gQnV0IG9uZSBwYXJ0IHdlIHRyeSB0byBnZXQgYWNyb3NzIGluIHRoaXMNCj4gZG9j dW1lbnQgaXMgdGhhdCB0aGlzIGlzIHRoZSByZWFzb24gd2Ugd2FudCB0byBlbnN1cmUgdGhhdCBk ZWZhdWx0DQo+IHJlbWFpbnMgdG8gaGF2ZSB0aGUgVURQIGNoZWNrc3VtIGVuYWJsZWQgdG8gYXZv aWQgaGF2aW5nIGFwcGxpY2F0aW9ucw0KPiBub3QgaGF2aW5nIGNvbnNpZGVyZWQgdGhpcyBpbiB0 aGVpciBkZXNpZ24gb3IgYXQgbGVhc3QgYmVlbiBhbmFseXplZCB0bw0KPiBiZSBzYWZlIGVub3Vn aCB0byBnZXQgemVybyBjaGVja3N1bW1lZCBwYWNrZXRzLg0KPiANCj4gVGhlIG5leHQgc3RlcCBp cyB0aGUgcXVlc3Rpb24gb2YgcG90ZW50aWFsIGhhcm0gaXMgYSBzdGF0aXN0aWNzIGdhbWUuDQo+ IEFuZCB0aGUgbW9yZSB0cmFmZmljIHRoYXQgYXJlIHRyYW5zcG9ydGVkIG92ZXIgdGhlIG5ldHdv cmsgd2l0aCB6ZXJvLQ0KPiBjaGVja3N1bSB0aGUgaGlnaGVyIHRoZSBwcm9iYWJpbGl0eSB0aGF0 IHlvdSB3aWxsIGdldCBhIHBhY2tldCBub3QNCj4gaW50ZW5kZWQgZm9yIHlvdXIgY29udGV4dC4g VGh1cyB5b3Ugd2lsbCBoYXZlIHRvIGRlYWwgd2l0aCBpdC4gSGVyZSBJDQo+IHRoaW5rIG1vc3Qg dHVubmVsIGVncmVzc2VzIGFyZSByZWFzb25hYmx5IHNpbXBsZSB0byBhbmFseXplIHdoYXQNCj4g aGFwcGVucy4gWW91IGF0dGVtcHQgdG8gZGVjYXBzdWxhdGUgaXQgYWNjb3JkaW5nIHRvIHdoYXRz IGluIHRoZQ0KPiBwYWNrZXQuDQo+IElmIHRoYXQgaXMgbm90IGEgbWlzbWF0Y2ggeW91IHRyeSB0 byBkbyB0aGUgbmV4dCBzdGVwIGZvciB0aGUgaW5uZXINCj4gcGFja2V0LCBzd2l0Y2hpbmcgb3Ig Zm9yd2FyZGluZyB0aGF0IGJhc2VkIG9uIHdoYXRzIHRoZXJlLiBUaGF0IGVpdGhlcg0KPiBtYXRj aGVzIG9yIG5vdCB0aGUgY29udGV4dCBhbmQgYXJlIHRodXMgc2VudCBmdXJ0aGVyIG9yIGRpc2Nh cmRlZC4gSWYNCj4gdGhlcmUgaXMgYSBjaGVja3N1bSBvbiB0aGF0IGxldmVsIGl0IGNhbiBoZWxw IGRpc2NhcmRpbmcgcGFja2V0cyB0aGF0DQo+IGNvbXBsZXRlbHkgbWlzc2VzIHRoZSBjb250ZXh0 Lg0KPiANCj4gDQo+IENoZWVycw0KPiANCj4gTWFnbnVzIFdlc3Rlcmx1bmQNCj4gDQo+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gTXVsdGltZWRpYSBUZWNobm9sb2dpZXMsIEVyaWNzc29uIFJlc2VhcmNoIEVB Qi9UVk0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBFcmljc3NvbiBBQiAgICAgICAgICAgICAgICB8IFBo b25lICArNDYgMTAgNzE0ODI4Nw0KPiBGw6Ryw7ZnYXRhbiA2ICAgICAgICAgICAgICAgIHwgTW9i aWxlICs0NiA3MyAwOTQ5MDc5DQo+IFNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbnwgbWFpbHRv OiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo= From bob.hinden@gmail.com Wed Oct 10 20:37:32 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788A921F8668 for ; Wed, 10 Oct 2012 20:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.279 X-Spam-Level: X-Spam-Status: No, score=-103.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZdtXOS7KYCj for ; Wed, 10 Oct 2012 20:37:32 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id A83D821F865D for ; Wed, 10 Oct 2012 20:37:31 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id fm10so3879797wgb.1 for ; Wed, 10 Oct 2012 20:37:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Qeru+81+ypSfIW38OIsFMJoP9Q1hIsAZqgubVwMCdAw=; b=P9icZf0m6WSZJHi9IkAsg8xrLwI9S+u8GhLy+0Da1IgalGmclqgG1EDgR8vI3XxP34 7wSxLeynLSMjp8tAUjsF6pR94XoM2iGpZfHcjuLZTen1+k7YWir1P3XynFRcGSS5q4aw zhffdxozEB3YcBqI315FWQaso2FMrm2beYccwBJ0swCVBnW2IODnBXGDbqDRQgdYmv3L 4SAAGLG2wZDH5kc12aOskkjNuOBDjppoTVBAAvVzDJvzH5E4A8k0iGoI1r0gnswpdSly dVEChwFYK39oEqIP1cNjFMGfUFDXznn/+ZLU5x2UfWRe2dJWFGF+isSAb/lz6zKKtS9x XDSw== Received: by 10.180.91.71 with SMTP id cc7mr17452427wib.2.1349926650424; Wed, 10 Oct 2012 20:37:30 -0700 (PDT) Received: from ?IPv6:2601:9:4080:10:ec1e:9c10:86f9:b702? ([2601:9:4080:10:ec1e:9c10:86f9:b702]) by mx.google.com with ESMTPS id gg4sm6263603wib.6.2012.10.10.20.37.28 (version=SSLv3 cipher=OTHER); Wed, 10 Oct 2012 20:37:29 -0700 (PDT) Subject: Re: IPv6 modification suggestion Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Bob Hinden In-Reply-To: <50758ba5.e956420a.71b1.6dbb@mx.google.com> Date: Wed, 10 Oct 2012 20:37:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50758ba5.e956420a.71b1.6dbb@mx.google.com> To: Ammar Salih X-Mailer: Apple Mail (2.1283) Cc: ipv6@ietf.org, Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 03:37:32 -0000 Ammar, On Oct 10, 2012, at 7:52 AM, Ammar Salih wrote: > Hello Dears, > =20 > I would like to suggest adding GPS coordinates to IPv6 header, as you = know the current way of determining the location of the IP address is = through the IP registration, which is not very accurate as it depends on = how the ISP registers it=92s IP subnets, which is normally done based on = country/city. I agree with you that IP addresses are not very reliable as a means of = determining geographic location. That said, I don't think it is a good = idea to add GPS position to every IPv6 header. It would add a lot of = overhead, there are many privacy related issues (as others have pointed = out), it doesn't need to be in every packet. An alternative would be to = create a application layer protocols that could request and send GPS = positions. That is a better way to to deal with the privacy issues and = the GPS position would only need to be sent when desired or when = requested. The GEOPRIV working group is doing some work in this area. See: http://datatracker.ietf.org/wg/geopriv/charter/ Bob > =20 > Getting more accurate locations will enhance many services provided by = the web, like targeted commercials (for example, I can get Ads regarding = restaurants available in my neighborhood instead of all restaurants in = the city), another good example would be webpage=92s language, my = language will be detected more accurately based on my exact area rather = than my countery, as there are many countries with more than one popular = language. > =20 > Maps, navigation, emergency calls and many other services will also = get enhanced with accurate locations. > =20 > I hope you will find my suggestion beneficial, and looking forward to = hearing from you. > =20 > =20 > Best, > =20 > Ammar Salih | B.Sc.Eng, CCNA-S, CCVP, CCIE-V written > Technical Lead - Voice and Data Support Services > =20 > Mob: +964 (0) 770 533 0306=20 > Office: +964 (0) 53 511 2020 - Ext. 2221 > Email: ammar.salih@auis.edu.iq > The American University of Iraq =96 Sulaimani > =20 > =20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From ietf-secretariat-reply@ietf.org Wed Oct 10 12:25:39 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403FD11E80A2 for ; Wed, 10 Oct 2012 12:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbw5tANJSG07; Wed, 10 Oct 2012 12:25:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D052C11E80AD; Wed, 10 Oct 2012 12:25:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: 6man-chairs@tools.ietf.org, draft-ietf-6man-udpchecksums@tools.ietf.org, ipv6@ietf.org Subject: ID Tracker State Update Notice: X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121010192538.25083.51090.idtracker@ietfa.amsl.com> Date: Wed, 10 Oct 2012 12:25:38 -0700 From: IETF Secretariat X-Mailman-Approved-At: Thu, 11 Oct 2012 01:46:16 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 19:25:39 -0000 State changed to IESG Evaluation from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksum= s/ From ietf-secretariat-reply@ietf.org Wed Oct 10 12:26:18 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6331C21F86B1 for ; Wed, 10 Oct 2012 12:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sweq5NUP5niM; Wed, 10 Oct 2012 12:26:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137ED21F86A4; Wed, 10 Oct 2012 12:26:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: 6man-chairs@tools.ietf.org, draft-ietf-6man-dad-proxy@tools.ietf.org, ipv6@ietf.org Subject: ID Tracker State Update Notice: X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121010192618.17151.25270.idtracker@ietfa.amsl.com> Date: Wed, 10 Oct 2012 12:26:18 -0700 From: IETF Secretariat X-Mailman-Approved-At: Thu, 11 Oct 2012 01:46:16 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 19:26:18 -0000 State changed to IESG Evaluation from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-6man-dad-proxy/ From ietf-secretariat-reply@ietf.org Wed Oct 10 12:26:36 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7234121F86B1 for ; Wed, 10 Oct 2012 12:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.433 X-Spam-Level: X-Spam-Status: No, score=-102.433 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XEUbtbHceFg; Wed, 10 Oct 2012 12:26:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28ED611E80AD; Wed, 10 Oct 2012 12:26:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: 6man-chairs@tools.ietf.org, draft-ietf-6man-udpzero@tools.ietf.org, ipv6@ietf.org Subject: ID Tracker State Update Notice: X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121010192636.29620.49285.idtracker@ietfa.amsl.com> Date: Wed, 10 Oct 2012 12:26:36 -0700 From: IETF Secretariat X-Mailman-Approved-At: Thu, 11 Oct 2012 01:46:16 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 19:26:36 -0000 State changed to IESG Evaluation from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/ From ammar.salih@auis.edu.iq Thu Oct 11 01:41:07 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76ED21F86DD for ; Thu, 11 Oct 2012 01:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.75 X-Spam-Level: X-Spam-Status: No, score=-5.75 tagged_above=-999 required=5 tests=[AWL=0.849, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlXNE3wL76TH for ; Thu, 11 Oct 2012 01:41:07 -0700 (PDT) Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) by ietfa.amsl.com (Postfix) with SMTP id 1EDC421F86D0 for ; Thu, 11 Oct 2012 01:41:07 -0700 (PDT) Received: from mail-pa0-f70.google.com ([209.85.220.70]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP ID DSNKUHaGIifHPBzRQqkigsy1mwQ0/QxRtpMz@postini.com; Thu, 11 Oct 2012 01:41:07 PDT Received: by mail-pa0-f70.google.com with SMTP id fb10so2926630pad.1 for ; Thu, 11 Oct 2012 01:41:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=bk+yOc2kZ4dGvTMHHUG8lr2RkMUESkROc2pLtHEsFc4=; b=Tz/SKD+T2xVtSWLfvQE48nekri9PTjLoIDCEfEih3ex+xXh4Z7keZCP9ybFXiR0pEo Z40siOSzSU2VKi2VEoENO2CE1CAaWAqTYJ9EvXIpIK1XiDaKf0J0rheFliEZq9yh409o nPYuQhJn1Mr8k80kKwPT4AKUzIny2VWMN6hmlGquvZDi7dEEkars27pqEQHYrUpZZiG8 IuBGRjPUop7TjgkmgYx8ct76rZXI2ONuRiu/HTLKqOp3vkqvj276GlUQIMEvsuqSbBkO pAuGnVz0UAzSOQ8A4dZl/oKEFhQAOLPqIgmBXOJsdO5Cs6vqFQNkIM3uG0rYLUy6nsiM DP2A== Received: by 10.66.76.98 with SMTP id j2mr234857paw.65.1349944866335; Thu, 11 Oct 2012 01:41:06 -0700 (PDT) Received: by 10.66.76.98 with SMTP id j2mr234823paw.65.1349944866050; Thu, 11 Oct 2012 01:41:06 -0700 (PDT) Received: from AMMARSALIH ([46.30.228.16]) by mx.google.com with ESMTPS id uh7sm2414768pbc.35.2012.10.11.01.41.01 (version=SSLv3 cipher=OTHER); Thu, 11 Oct 2012 01:41:04 -0700 (PDT) From: "Ammar Salih" To: "'Bob Hinden'" References: <50758ba5.e956420a.71b1.6dbb@mx.google.com> In-Reply-To: Subject: RE: IPv6 modification suggestion Date: Thu, 11 Oct 2012 11:40:58 +0300 Message-ID: <50768620.e7ea440a.0d8f.0033@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2nYb9+B2JU5/S2TjaXUBla9dpJ1wAGEG4w Content-Language: en-us X-Gm-Message-State: ALoCoQm8Ro2pdxzdfNk9fAAddk+6f73GfwO0xBAP51YP2jFBhOfEoK4DxxXwtecH7TEZ98Q9u8PSPgGo4Ptj2F6m6VsvOhMSTBDutO70bOt+ry81AsS+poUwLa3E3TrFSGglO52scWnq X-Mailman-Approved-At: Thu, 11 Oct 2012 01:46:16 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 08:41:07 -0000 Hello Bob, > That said, I don't think it is a good idea to add GPS position to every IPv6 header. It would add a lot of overhead. It does not have to be in every IPv6 header, only when there is location update, also it can be included in the first header (just like RTP and cRTP) > there are many privacy related issues (as others have pointed out). This can be set manually in case of any privacy concerns, just like other header's information like IP address. > An alternative would be to create a application layer protocols that could request and send GPS positions. Sounds awesom, but in this case all webpages, phone applications, server side scripting languages ... etc have to be modified to support the new application protocol. Not mensioning that layer 3 devices (like routers) won't be able to support the feature, let's say in the feature you want to do dynamic routing based on geo location. In anycase, I still feel quite interested about the new layer 7 protocol, will try to go through the GEOPRIV documentation this weekend in order to get more details. Thank you for your kind response, Ammar -----Original Message----- From: Bob Hinden [mailto:bob.hinden@gmail.com] Sent: Thursday, October 11, 2012 6:37 AM To: Ammar Salih Cc: Bob Hinden; ipv6@ietf.org Subject: Re: IPv6 modification suggestion Ammar, On Oct 10, 2012, at 7:52 AM, Ammar Salih wrote: > Hello Dears, > > I would like to suggest adding GPS coordinates to IPv6 header, as you know the current way of determining the location of the IP address is through the IP registration, which is not very accurate as it depends on how the ISP registers it's IP subnets, which is normally done based on country/city. I agree with you that IP addresses are not very reliable as a means of determining geographic location. That said, I don't think it is a good idea to add GPS position to every IPv6 header. It would add a lot of overhead, there are many privacy related issues (as others have pointed out), it doesn't need to be in every packet. An alternative would be to create a application layer protocols that could request and send GPS positions. That is a better way to to deal with the privacy issues and the GPS position would only need to be sent when desired or when requested. The GEOPRIV working group is doing some work in this area. See: http://datatracker.ietf.org/wg/geopriv/charter/ Bob > > Getting more accurate locations will enhance many services provided by the web, like targeted commercials (for example, I can get Ads regarding restaurants available in my neighborhood instead of all restaurants in the city), another good example would be webpage's language, my language will be detected more accurately based on my exact area rather than my countery, as there are many countries with more than one popular language. > > Maps, navigation, emergency calls and many other services will also get enhanced with accurate locations. > > I hope you will find my suggestion beneficial, and looking forward to hearing from you. > > > Best, > > Ammar Salih | B.Sc.Eng, CCNA-S, CCVP, CCIE-V written Technical Lead - > Voice and Data Support Services > > Mob: +964 (0) 770 533 0306 > Office: +964 (0) 53 511 2020 - Ext. 2221 > Email: ammar.salih@auis.edu.iq > The American University of Iraq - Sulaimani > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From stephen.farrell@cs.tcd.ie Thu Oct 11 04:14:24 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2D121F862A; Thu, 11 Oct 2012 04:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oB78hMTjsETO; Thu, 11 Oct 2012 04:14:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458F921F8589; Thu, 11 Oct 2012 04:14:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Stephen Farrell" To: The IESG Subject: Stephen Farrell's No Objection on draft-ietf-6man-udpchecksums-04: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121011111424.6375.61972.idtracker@ietfa.amsl.com> Date: Thu, 11 Oct 2012 04:14:24 -0700 Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-udpchecksums@tools.ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 11:14:24 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-6man-udpchecksums-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - The DCCP-UDP tunnel draft [1] says you MUST have a non-zero UDP checksum. Does that conflict with this or need to be called out as an exception? (And if so, does anything else?) [1] http://datatracker.ietf.org/doc/draft-ietf-dccp-udpencap/ - Ought 6man-udpzero be a normative reference? Seems odd to say this "requires" that (top of p7) but for the referred thing to be informative and an informational RFC. Is all the right text in the right places? - The secdir review [2] suggested calling more stuff out to application developers, which seems worth considering. [2] http://www.ietf.org/mail-archive/web/secdir/current/msg03555.html From stephen.farrell@cs.tcd.ie Thu Oct 11 04:46:35 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF3121F86B8; Thu, 11 Oct 2012 04:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubvNiHN9iPeo; Thu, 11 Oct 2012 04:46:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE1D521F861D; Thu, 11 Oct 2012 04:46:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Stephen Farrell" To: The IESG Subject: Stephen Farrell's Discuss on draft-ietf-6man-dad-proxy-05: (with DISCUSS and COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121011114634.23051.53116.idtracker@ietfa.amsl.com> Date: Thu, 11 Oct 2012 04:46:34 -0700 Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-dad-proxy@tools.ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 11:46:35 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-6man-dad-proxy-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Does the deployment model for this actually fit the SAVI charter which is limited to systems on the same IP link? Its not clear to me that it does, and if it doesn't then I'm not sure how SAVI "MAY be used" to protect against address spoofing. (It could be that this does fit with SAVI, I'm just not sure.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - The last sentence in the abstract confused me, what's "this last one" mean? - I agree with Martin and Sean's DISCUSSes. From adrian@olddog.co.uk Thu Oct 11 07:28:23 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB52F21F86E0; Thu, 11 Oct 2012 07:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWA4Ra4N+IFg; Thu, 11 Oct 2012 07:28:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62AE521F8625; Thu, 11 Oct 2012 07:28:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Adrian Farrel" To: The IESG Subject: Adrian Farrel's No Objection on draft-ietf-6man-udpzero-06: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121011142823.17203.46896.idtracker@ietfa.amsl.com> Date: Thu, 11 Oct 2012 07:28:23 -0700 Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, draft-ietf-6man-udpzero@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 14:28:23 -0000 Adrian Farrel has entered the following ballot position for draft-ietf-6man-udpzero-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A couple of thughts about this document which I am not raising as a Discuss, but I hope the authors will have a look at. --- Section 5.1 2. Implementations must provide a way to signal the set of ports that will be enabled to receive UDP datagrams with a zero checksum. An IPv6 node that enables reception of UDP packets with a zero-checksum, must enable this only for a specific port or port-range. This may be implemented via a socket API call, or similar mechanism. I believe "signal" is a confusing word here. Signalling means (to me) = that the implementation builds a message and sends it to the remote end. So, "implementations" cannot provide this mechanism - it is the protocol specification that must do it. And a sockets API call provides a way for an implementation to request the zero-checksum feature locally, but it does not provide a way to "signal the set of ports that will ..." Probably, the consistancy of this requirement would be most easily obtained by s/signal/register/ However, that change would leave open the question of how two end points coordinate (i.e. signal) on which ports they will use zero checksum. = That is a requirement on the specification of transported protocols, which is exactly what this section is about. --- Section 9 seems to make a valid point, so I am surprised that no conclusions are drawn from what it says. It also seems to me that it is important to drop and log corrupted = packets as early as possible. This offers three benefits: 1. Corruptions in the tunnelling encapsulation are detected so that mis-delivery of the tunnelled packets is less likely 2. Causes of corruption can be more effectively isolated (for example, was it the encapsulation mechanism, the transmission, or the = storage of the tunnelled packet that introduced the corruption). In particular, where the corruption is the result of an attack, this may be valuable information. 3. The later the corruption is detected and the packet dropped, the more processing has been "wasted" handling the packet. Thus, late = detection offers a way to waste transmission/receiver resources. I found some of these points hinted at in the body of the document and = in the Summary. Maybe Section 9 is just positioned a little late in the document meaning that the authors didn't feel there was muych to say by = the time the reader got there? Might be nice to beef up the Section a = little and arrange for it to come before the Summary. From adrian@olddog.co.uk Thu Oct 11 07:39:38 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAA221F86C7; Thu, 11 Oct 2012 07:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edE2ykkfm3O9; Thu, 11 Oct 2012 07:39:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4607421F86BA; Thu, 11 Oct 2012 07:39:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Adrian Farrel" To: The IESG Subject: Adrian Farrel's No Objection on draft-ietf-6man-udpzero-06: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121011143936.28482.90917.idtracker@ietfa.amsl.com> Date: Thu, 11 Oct 2012 07:39:36 -0700 Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, draft-ietf-6man-udpzero@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 14:39:38 -0000 Adrian Farrel has entered the following ballot position for draft-ietf-6man-udpzero-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Updated Comment with an additional point. A couple of thoughts about this document which I am not raising as a Discuss, but I hope the authors will have a look at. --- Section 5.1 2. Implementations must provide a way to signal the set of ports that will be enabled to receive UDP datagrams with a zero checksum. An IPv6 node that enables reception of UDP packets with a zero-checksum, must enable this only for a specific port or port-range. This may be implemented via a socket API call, or similar mechanism. I believe "signal" is a confusing word here. Signalling means (to me) = that the implementation builds a message and sends it to the remote end. So, "implementations" cannot provide this mechanism - it is the protocol specification that must do it. And a sockets API call provides a way for an implementation to request the zero-checksum feature locally, but it does not provide a way to "signal the set of ports that will ..." Probably, the consistancy of this requirement would be most easily obtained by s/signal/register/ However, that change would leave open the question of how two end points coordinate (i.e. signal) on which ports they will use zero checksum. = That is a requirement on the specification of transported protocols, which is exactly what this section is about. --- Section 9 seems to make a valid point, so I am surprised that no conclusions are drawn from what it says. It also seems to me that it is important to drop and log corrupted = packets as early as possible. This offers three benefits: 1. Corruptions in the tunnelling encapsulation are detected so that mis-delivery of the tunnelled packets is less likely 2. Causes of corruption can be more effectively isolated (for example, was it the encapsulation mechanism, the transmission, or the = storage of the tunnelled packet that introduced the corruption). In particular, where the corruption is the result of an attack, this may be valuable information. 3. The later the corruption is detected and the packet dropped, the more processing has been "wasted" handling the packet. Thus, late = detection offers a way to waste transmission/receiver resources. I found some of these points hinted at in the body of the document and = in the Summary. Maybe Section 9 is just positioned a little late in the document meaning that the authors didn't feel there was muych to say by = the time the reader got there? Might be nice to beef up the Section a = little and arrange for it to come before the Summary. --- Section 5.1 should probably also talk about the management requirements. Can ports be manually configured for zero checksum? Should implementations provide management access to say on which ports zero checksum is operated? From adrian@olddog.co.uk Thu Oct 11 07:49:16 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F076621F85C2; Thu, 11 Oct 2012 07:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4mWz6VjnOqx; Thu, 11 Oct 2012 07:49:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DD721F8528; Thu, 11 Oct 2012 07:49:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Adrian Farrel" To: The IESG Subject: Adrian Farrel's Discuss on draft-ietf-6man-dad-proxy-05: (with DISCUSS) X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121011144915.23193.19473.idtracker@ietfa.amsl.com> Date: Thu, 11 Oct 2012 07:49:15 -0700 Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-dad-proxy@tools.ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 14:49:16 -0000 Adrian Farrel has entered the following ballot position for draft-ietf-6man-dad-proxy-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I don't see any discussion of the size of the Binding Table. In fact, it seems to be assumed to be "large enough". History shows that we are not good at guessing the value of "large enough" and certainly the = application of this mechanism to VPNs makes this a little worrying. That probably means that the document needs to describe what happens when the Binding Table is full. Might be as simple as handling the failure case in 4.2.1. --- Shouldn't you describe some manageability considerations? What events should be logged? What access to the stored informaiton should be provided? (For example, should theoperator be able to read the Binding Table?) From adrian@olddog.co.uk Thu Oct 11 09:29:37 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 199BD21F8545; Thu, 11 Oct 2012 09:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLV5BjWeLiSR; Thu, 11 Oct 2012 09:29:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FC821F852C; Thu, 11 Oct 2012 09:29:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Adrian Farrel" To: The IESG Subject: Adrian Farrel's Discuss on draft-ietf-6man-dad-proxy-05: (with DISCUSS and COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121011162936.1240.92414.idtracker@ietfa.amsl.com> Date: Thu, 11 Oct 2012 09:29:36 -0700 Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-dad-proxy@tools.ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 16:29:37 -0000 Adrian Farrel has entered the following ballot position for draft-ietf-6man-dad-proxy-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Updated Discuss after Telechat conversation with Brian. I have moved my first point into a Comment and added some clarification. --- Shouldn't you describe some manageability considerations? What events should be logged? What access to the stored informaiton should be provided? (For example, should the operator be able to read the Binding Table?) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In my Discuss I originally wrote: > I don't see any discussion of the size of the Binding Table. In > fact, it seems to be assumed to be "large enough". History shows > that we are not good at guessing the value of "large enough" and > certainly the application of this mechanism to VPNs makes this a > little worrying. That probably means that the document needs to = > describe what happens when the Binding Table is full. Might be as > simple as handling the failure case in 4.2.1. First, don't be distracted by the VPN thing. I am just asking about what happens when a BNG receives a Neighbor Solicitation message and is unable to store the tentative address as mandated in Section 4.2.1. Brian says that the protocol is unreliable, so it is as simple as making a local decision to drop the message or flush an entry from the cache. That sounds fine to me, and I started to look for text in the I-D that describes "lost message", "cache full", "cache cycling", and "cache timeout". I am not convinced that this is an issue. But I am slightly worried = about the impact of a node that has been happily alive and running suddenly being dropped from the cache and "replaced" by another node with the same address. From adrian@olddog.co.uk Thu Oct 11 12:15:13 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A741F21F8643; Thu, 11 Oct 2012 12:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o47kDlgyGz1k; Thu, 11 Oct 2012 12:15:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1832721F861A; Thu, 11 Oct 2012 12:15:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Adrian Farrel" To: The IESG Subject: Adrian Farrel's Discuss on draft-ietf-6man-dad-proxy-05: (with DISCUSS) X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121011191513.4133.43593.idtracker@ietfa.amsl.com> Date: Thu, 11 Oct 2012 12:15:13 -0700 Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-dad-proxy@tools.ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 19:15:13 -0000 Adrian Farrel has entered the following ballot position for draft-ietf-6man-dad-proxy-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Sorry about the ping-pong! Brian and i have been discussing this further and have talked ourselves back into believing that I have a valid concern. So I have moved it back from my Comment and reworded it (with a little help from Brian). There are two scenarios that give rise to concern: 1. Node A with address a sends NS. The message is lost in the network. Because the message is not normally acknowledged, when Node B sends NS with the same address, the duplication is not noticed. Note that an obvious variation of this scenario is when the NS from = Node B is lost. 2. Node A with address a sends NS. The message reaches the BNG and is added to the cache. At a later time, the cache becomes full and this entry is discarded according to some local policy. Now Node B sends = NS with the same address. The duplicate is added to the cache, but = the duplication is not noticed. Note that a variation on the second scenario occurs when the policy of a full cache is to ignore new NSes. This variant gives rise to = scenario 1 with the message loss being in the BNG. So, it is not reasonable for this document to have to fix DAD. The problem of lost messages exists in DAD (although at a slightly less probable level because normally there is a chance for Node A to receive Node B's NS even if Node A's NS was lost). I think that the first scenario can be handled in this document simply by noting that the problem exists and is made slightly more of an exposure when a proxy is used because the loss of either of the NSes will lead to duplication = being missed. I think that the second scenario is only a problem if the Binding Table is not large enough. So it is clear that "the Binding Table MUST be = large enough for the deployment in which it is used." You certainly need to say this, and you should add some guidance. You also need to add that implementations MUST either state the fixed size of Binding Table that = they support or make the size configurable. In the latter case, = implementations MUST state the largest Binding Table size that they = support. Additionally, implementations SHOULD allow an operator to = enquire the current occupancy level of the Binding Table to determine if it is about to become full. = If you do all that, you only need to note that implementations = encountering a full Binding Table will likely handle it in a way similar to NS message loss. And all of that just leaves me with one last question which is: since NS is not refreshed in DAD, is there a risk that the cache will grow = forever with undisciplined nodes disappearing or renumbering without bothering to tell the BNG? That would be bad. --- Shouldn't you describe some manageability considerations? What events should be logged? What access to the stored informaiton should be provided? (For example, should the operator be able to read the Binding Table?) From ietf-secretariat-reply@ietf.org Thu Oct 11 11:02:28 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F8921F8736 for ; Thu, 11 Oct 2012 11:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.453 X-Spam-Level: X-Spam-Status: No, score=-101.453 tagged_above=-999 required=5 tests=[AWL=-1.073, BAYES_00=-2.599, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qy6wrqFnOb-F; Thu, 11 Oct 2012 11:02:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F02D21F8587; Thu, 11 Oct 2012 11:02:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: 6man-chairs@tools.ietf.org, draft-ietf-6man-dad-proxy@tools.ietf.org, ipv6@ietf.org Subject: ID Tracker State Update Notice: X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121011180228.27149.30454.idtracker@ietfa.amsl.com> Date: Thu, 11 Oct 2012 11:02:28 -0700 From: IETF Secretariat X-Mailman-Approved-At: Thu, 11 Oct 2012 12:58:52 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 18:02:29 -0000 State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-6man-dad-proxy/ From ietf-secretariat-reply@ietf.org Thu Oct 11 11:07:48 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA45E21F86FC for ; Thu, 11 Oct 2012 11:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.452 X-Spam-Level: X-Spam-Status: No, score=-101.452 tagged_above=-999 required=5 tests=[AWL=-1.072, BAYES_00=-2.599, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqK-DCkq2k89; Thu, 11 Oct 2012 11:07:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CADD21F8737; Thu, 11 Oct 2012 11:07:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: 6man-chairs@tools.ietf.org, draft-ietf-6man-udpchecksums@tools.ietf.org, ipv6@ietf.org Subject: ID Tracker State Update Notice: X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121011180748.20890.36949.idtracker@ietfa.amsl.com> Date: Thu, 11 Oct 2012 11:07:48 -0700 From: IETF Secretariat X-Mailman-Approved-At: Thu, 11 Oct 2012 12:58:52 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 18:07:49 -0000 State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksum= s/ From ietf-secretariat-reply@ietf.org Thu Oct 11 11:09:09 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4CC91F0423 for ; Thu, 11 Oct 2012 11:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.323 X-Spam-Level: X-Spam-Status: No, score=-101.323 tagged_above=-999 required=5 tests=[AWL=-1.202, BAYES_00=-2.599, SARE_SUB_OBFU_Z=0.259, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvZWrkAfHZZV; Thu, 11 Oct 2012 11:09:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830C31F042B; Thu, 11 Oct 2012 11:09:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: 6man-chairs@tools.ietf.org, draft-ietf-6man-udpzero@tools.ietf.org, ipv6@ietf.org Subject: ID Tracker State Update Notice: X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121011180909.5356.68505.idtracker@ietfa.amsl.com> Date: Thu, 11 Oct 2012 11:09:09 -0700 From: IETF Secretariat X-Mailman-Approved-At: Thu, 11 Oct 2012 12:58:52 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 18:09:10 -0000 State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/ From samita.chakrabarti@ericsson.com Thu Oct 11 18:29:08 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9D51F0C61 for ; Thu, 11 Oct 2012 18:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kewVpC5mQahc for ; Thu, 11 Oct 2012 18:29:07 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 85F6C1F0C69 for ; Thu, 11 Oct 2012 18:29:07 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q9C1UCkw009024 for ; Thu, 11 Oct 2012 20:30:13 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.214]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 11 Oct 2012 21:29:00 -0400 From: Samita Chakrabarti To: 6man Mailing List Date: Thu, 11 Oct 2012 21:28:59 -0400 Subject: FW: draft-chakrabarti-nordmark-6man-efficient-nd-00.txt Thread-Topic: draft-chakrabarti-nordmark-6man-efficient-nd-00.txt Thread-Index: Ac2oE4rOkWojGtISRjmUEu098HOyiAAA5dbQ Message-ID: <16D60F43CA0B724F8052D7E9323565D72ECE73F3B4@EUSAACMS0715.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 01:29:08 -0000 Hello: The co-authors have submitted the draft-chakrabarti-nordmark-6man-efficient= -nd-00.txt(see below) as a follow-up from =20 https://tools.ietf.org/html/draft-chakrabarti-nordmark-energy-aware-nd-02 a= fter incorporating comments received from 6man and int-area working groups. The outline of changes are: - Objective is now to have an efficient ND ( rather than only energy-effic= ient) - Added clarifications on interactions with DHCPv6, ND-Proxy and DNA implem= entations - Clarified Duplicate Address detection=20 The document addresses both legacy IPv6 and efficient IPv6 ND compliant nod= es in "mixed-mode". It supports beahvior of sleepy nodes using node registration. Thanks, -Samita -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Thursday, October 11, 2012 5:50 PM To: Samita Chakrabarti Cc: mrw@lilacglade.org; nordmark@cisco.com Subject: New Version Notification for draft-chakrabarti-nordmark-6man-effic= ient-nd-00.txt A new version of I-D, draft-chakrabarti-nordmark-6man-efficient-nd-00.txt has been successfully submitted by Samita Chakrabarti and posted to the IET= F repository. Filename: draft-chakrabarti-nordmark-6man-efficient-nd Revision: 00 Title: Efficiency aware IPv6 Neighbor Discovery Optimizations Creation date: 2012-10-12 WG ID: Individual Submission Number of pages: 26 URL: http://www.ietf.org/internet-drafts/draft-chakrabarti-nord= mark-6man-efficient-nd-00.txt Status: http://datatracker.ietf.org/doc/draft-chakrabarti-nordmark= -6man-efficient-nd Htmlized: http://tools.ietf.org/html/draft-chakrabarti-nordmark-6man= -efficient-nd-00 Abstract: IPv6 Neighbor Discovery (RFC 4861) protocol has been designed for neighbor's address resolution, unreachability detection, address autoconfiguration, router advertisement and solicitation. With the progress of Internet adoption on various industries including home, wireless, m2m and Cellular(LTE) networks, there is a desire for optimizing legacy IPv6 Neighbor Discovery protocol to be more efficient in terms of number of signaling messages in the network. This document describes a method of optimization by reducing periodic multicast messages, frequent Neighbor Solicitation messages and supports interoperability with legacy IPv6 nodes and avoids Duplicate Address Detection by introducing an address Registration mechanism. Efficient IPv6 Neighbor Discovery protocol is useful for energy- efficient IPv6 networks as well as Data Center and Home Networks. = =20 The IETF Secretariat From cabo@tzi.org Thu Oct 11 23:23:48 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E4D21F8499 for ; Thu, 11 Oct 2012 23:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.219 X-Spam-Level: X-Spam-Status: No, score=-106.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LzTpRzOYBWr for ; Thu, 11 Oct 2012 23:23:47 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id F339C21F81FE for ; Thu, 11 Oct 2012 23:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q9C6NcTk029722; Fri, 12 Oct 2012 08:23:38 +0200 (CEST) Received: from [192.168.217.105] (p54894040.dip.t-dialin.net [84.137.64.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 66C3A3C1; Fri, 12 Oct 2012 08:23:38 +0200 (CEST) Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd-00.txt Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <16D60F43CA0B724F8052D7E9323565D72ECE73F3B4@EUSAACMS0715.eamcs.ericsson.se> Date: Fri, 12 Oct 2012 08:23:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <653FE6CB-CBFF-4CF5-967B-3227B5295B46@tzi.org> References: <16D60F43CA0B724F8052D7E9323565D72ECE73F3B4@EUSAACMS0715.eamcs.ericsson.se> To: Samita Chakrabarti X-Mailer: Apple Mail (2.1499) Cc: 6man Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 06:23:48 -0000 Two quick comments: -- this still uses 10 seconds as a scaler for the ARO registration = lifetime. 6LoWPAN-ND used to use 10, but now uses 60 seconds. -- I'm not too wild about the E-bit. Maybe we should extract the 6CIO = from draft-bormann-6lowpan-ghc and use this? The two areas in which I think this proposal can benefit from some more = discussion: Clearly, mitigating the external ND table DoS is one of the major pain = points addressed by this. Thinking point: Is there any way to structure = the transition from legacy ND to efficient ND in such a way that it = becomes easier to reap this benefit? For DC applications, the assumption of uniqueness of the EUI-64 probably = requires some more thinking. VMs get copied all the time, and it is way = too easy to copy this kind of config info in the process. Gr=FC=DFe, Carsten From mohamed.boucadair@orange.com Fri Oct 12 02:01:02 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 483AD21F842B for ; Fri, 12 Oct 2012 02:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ft3t4XxVpcp8 for ; Fri, 12 Oct 2012 02:01:01 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 592DF21F8458 for <6man@ietf.org>; Fri, 12 Oct 2012 02:01:01 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id C114D22C55F; Fri, 12 Oct 2012 11:00:59 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 9FFBD35C045; Fri, 12 Oct 2012 11:00:59 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Fri, 12 Oct 2012 11:00:55 +0200 From: To: Ray Hunter Date: Fri, 12 Oct 2012 11:00:53 +0200 Subject: RE: draft-boucadair-6man-sip-proxy-01 Thread-Topic: draft-boucadair-6man-sip-proxy-01 Thread-Index: Ac2jMf+o6DgZ5wHZRImMj6r88RUa8AFIcdwg Message-ID: <94C682931C08B048B7A8645303FDC9F36E63206263@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E5F75BA9B@PUEXCB1B.nanterre.francetelecom.fr> <506F38A5.9090407@globis.net> In-Reply-To: <506F38A5.9090407@globis.net> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.1.82415 X-Mailman-Approved-At: Fri, 12 Oct 2012 02:05:41 -0700 Cc: "6man@ietf.org" <6man@ietf.org>, BINET David OLNC/OLN X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 09:01:02 -0000 Dear Ray,=20 Thank you for the comments.=20 Please see inline.=20 Cheers, Med >-----Message d'origine----- >De : Ray Hunter [mailto:v6ops@globis.net]=20 >Envoy=E9 : vendredi 5 octobre 2012 21:45 >=C0 : BOUCADAIR Mohamed OLNC/OLN >Cc : 6man@ietf.org >Objet : Re: draft-boucadair-6man-sip-proxy-01 > >I have read this draft and do not support it as-is. > >I do not agree with the conclusion that extending RA with a new option=20 >for SIP is necessary nor desirable. > >IMVHO: > >1. There are other mechanisms available. DHCPv6 is not=20 >mandatory in the=20 >IPv6 node requirements, but neither is SIP. Adding a new RA=20 >option would=20 >mean firmware in mobile devices would have to be updated, just as they=20 >would if incorporating a DHCPv6 client, so that's a wash. Med: I have several comments here: * The discovery of the SIP Proxy server is almost critical as the discovery= of a DNS server (RFC6106): If no server is discovered no session can be pl= aced. This may be critical for no SIM-based terminals (e.g., placing an eme= rgency call). * With the advent of Mobile VoIP, a solution which ** guarantee ** the prov= isioning of the SIP Proxy Server is needed. I would argue RA-based method w= ould have less impact on terminals * This method can be used for auto configuring SIP terminals with a SIP Pro= xy Server deployed in a homenet context. * For Fixed-Mobile Convergence, SIP-based traffic may also be interesting t= o offload (this is similar to local breakout scenarios for the roaming cont= ext): having a consistent method to discover the SIP Proxy in both fixed an= d mobile access would be helpful. > >2. An FQDN has an indeterminate length, although encoding of=20 >an FQDN in=20 >RFC1035 limits this to 255 octets, it's still potentially a=20 >significant=20 >increase in the length of RA messages, which is undesirable for many=20 >reasons (including stateless security filtering mechanisms=20 >like RA-Guard). > >3.There's no padding specified on the FQDN encoding. AFAIK=20 >RFC1035 does=20 >not specify how to encode an FQDN into 8 octet blocks (required for RA=20 >options length calculations). Med: You are right, padding may be needed. We can work out better the speci= fication once there is a support to use RA for SIP Proxy Server discovery. > >4. You can hardly talk about advantages of using an RA option rather=20 >than an alternative unicast mechanism on a point to point bearer link=20 >(where no other nodes can listen out for the broadcast/multicast=20 >information to save on multiple transmissions). The end node=20 >still also=20 >has to resolve the FQDN into one or more IPv6 or IPv4=20 >addresses via DNS=20 >before it can transmit any SIP messages, so it's not exactly a=20 >RTT start=20 >up latency or packet saver either. Med: This may or may not be considered as an issue: the reason is there is = likely a registration phase before placing a session. Anyway, this issue ca= n be solved by changing the encoding of the name into string. Doing so woul= d: (1) allow to convey any name (including IP address literals) that can be pa= ssed to an underlying resolution library (2) not require to define two formats (one for fqdn and another one for IP = address). One single option will do the job. > >Or am I missing something? Med: Your questions are valid one. I hope I clarified some of them. Thanks = for the review. > >regards, >RayH > >mohamed.boucadair@orange.com wrote: >> Dear all, >> >> Comments are more than welcome. >> >> Cheers, >> Med >> >> -----Message d'origine----- >> De : i-d-announce-bounces@ietf.org=20 >[mailto:i-d-announce-bounces@ietf.org] De la part de=20 >internet-drafts@ietf.org >> Envoy=E9 : jeudi 4 octobre 2012 09:12 >> =C0 : i-d-announce@ietf.org >> Objet : I-D Action: draft-boucadair-6man-sip-proxy-01.txt >> >> >> A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. >> >> >> Title : IPv6 RA Option for SIP Proxy Server >> Author(s) : Mohamed Boucadair >> David Binet >> Filename : draft-boucadair-6man-sip-proxy-01.txt >> Pages : 6 >> Date : 2012-10-04 >> >> Abstract: >> This document specifies a new optional extension to IPv6 Router >> Advertisement messages to advertise SIP Proxy Server=20 >(e.g., P-CSCF) >> addresses to IPv6 hosts. >> >> The provisioning of the SIP Proxy Server address is=20 >crucial for the >> delivery of SIP-based services. Means to ensure=20 >reliable delivery of >> this information to connecting SIP User Agents is a must. >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-boucadair-6man-sip-proxy >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-boucadair-6man-sip-proxy-01 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Daft-boucadair-6man-sip-proxy-01 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >= From magnus.westerlund@ericsson.com Fri Oct 12 02:19:13 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3CBE21F850B; Fri, 12 Oct 2012 02:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.102 X-Spam-Level: X-Spam-Status: No, score=-106.102 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYBAhI6Zg6kC; Fri, 12 Oct 2012 02:19:13 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 61CBA21F8508; Fri, 12 Oct 2012 02:19:12 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-f9-5077e089a0b4 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E8.8C.17130.980E7705; Fri, 12 Oct 2012 11:19:05 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Fri, 12 Oct 2012 11:19:04 +0200 Message-ID: <5077E087.5070407@ericsson.com> Date: Fri, 12 Oct 2012 10:19:03 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: stbryant@cisco.com Subject: Re: Benoit Claise's No Objection on draft-ietf-6man-udpzero-06: (with COMMENT) References: <20121009204331.6077.14763.idtracker@ietfa.amsl.com> <5075309D.3040401@ericsson.com> <5075615C.6080406@cisco.com> In-Reply-To: <5075615C.6080406@cisco.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+JvrW7ng/IAgxOHpCwWdDaxWhx9LGHx 8dk6FosZfyYyW7w8+57J4tzTOYwObB5Tfm9k9Viy5CeTx5fLn9kCmKO4bFJSczLLUov07RK4 MmY//MdYcJ2j4u/V8gbGTvYuRk4OCQETiavfD7JA2GISF+6tZ+ti5OIQEjjFKPHv2EwWCGc5 o8Sq5RvBOngFtCU+nHrLBmKzCKhKPLowgxHEZhOwkLj5oxEsLioQLDFp/xYWiHpBiZMznwDZ HBwiQBtuz0oGmcksMINRYu7SP0wgNcICkRLtN9eA9QoJ1EpMvbwRbCangKbEkY9/2SCuk5R4 M/km2ExmoHjr9t/sELa8RPPW2cwQvdoSDU0drBMYhWYhWT0LScssJC0LGJlXMQrnJmbmpJeb 66UWZSYXF+fn6RWnbmIEhvzBLb8NdjBuui92iFGag0VJnFdPdb+/kEB6YklqdmpqQWpRfFFp TmrxIUYmDk6pBsZ+U/MUFnajYr5TMXHtHW6nZObf+ZC1qe9t68kjeVMv3HBmKztne8skRy90 xYQYsQmTz9sxxRtM+RwvO22h563bLTYmaV8f6Gz/s/C5d9ka/WWPNUulRO853Pow12O+Tf1x X8Z+W4n3WwqvZZ2YyP7wgKVbhLPIzgnfnk1WLr38rFum/F74JU0lluKMREMt5qLiRAAW6tB5 RwIAAA== Cc: Benoit Claise , 6man-chairs@tools.ietf.org, draft-ietf-6man-udpzero@tools.ietf.org, The IESG , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 09:19:13 -0000 On 2012-10-10 12:51, Stewart Bryant wrote: > > What is an implementation? The application running over the tunnel? You > refer to "An encapsulating protocol" in the sentence before the bullet > points, is this what you mean? > >> For a tunnel protocol it is the tunnel protocol implementation that >> needs either implicitly or explicitly indicate or signal that it will >> use zero checksum for a particular flow or ports. >> > That was a point that I made concerning the text. Are you planning > to add text to the draft(s) to indicate configuration and implicit > signalling are OK? I think that is appropriate. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Fri Oct 12 02:24:39 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567DE21F84D9; Fri, 12 Oct 2012 02:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.097 X-Spam-Level: X-Spam-Status: No, score=-106.097 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4GYgBGZcMvQ; Fri, 12 Oct 2012 02:24:38 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6BF21F84D8; Fri, 12 Oct 2012 02:24:36 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-ed-5077e1d2c6a7 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 1C.9E.11467.2D1E7705; Fri, 12 Oct 2012 11:24:35 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Fri, 12 Oct 2012 11:24:24 +0200 Message-ID: <5077E1C7.4090404@ericsson.com> Date: Fri, 12 Oct 2012 10:24:23 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ronald Bonica Subject: Re: Ronald Bonica's Discuss on draft-ietf-6man-udpzero-06: (with DISCUSS) References: <20121009185726.29097.69699.idtracker@ietfa.amsl.com> <507538F1.5080505@ericsson.com> <13205C286662DE4387D9AF3AC30EF456D783A25412@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D783A25412@EMBX01-WF.jnpr.net> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUyM+Jvre7lh+UBBh1zuSwWdDaxWnx8to7F YsaficwWL8++Z7I48N3BgdVjyZKfTB7Xm66ye3y5/JktgDmKyyYlNSezLLVI3y6BK+Pf+rks BQcdK3ZPWMvawLjCpIuRk0NCwETi0uejLBC2mMSFe+vZuhi5OIQETjFK/F11gBHCWc4o8Xrr JCaQKl4BbYmmO6+YQWwWAVWJvlm/GEFsNgELiZs/GtlAbFGBYIlJ+7ewQNQLSpyc+QTMFhFQ l3i8ahrYBmaBS4wSO2e+YQdJCAuESGzY+IwJYttCRomzd9eBTeIU8JF4vmYiE8R9khJvJt8E m8QsoCnRuv03O4QtL9G8dTbYRUJA1zU0dbBOYBSahWT5LCQts5C0LGBkXsUonJuYmZNebqiX WpSZXFycn6dXnLqJERjuB7f81t3BeOqcyCFGaQ4WJXFerqT9/kIC6YklqdmpqQWpRfFFpTmp xYcYmTg4pRoYVU0l2Hxex6/gZ+kUcdO4Od/T3+3wsUzl3EeiITeWq3KaKH7RW7oqztdgU6Op 4UMdnj1yzxTU2rLj5JgfCt64ZVNgNGv7VgXVgPsWTysDE2XO86gyTc2r4WuYM23uT6Xn7LEz CqWPKS5a4TNP/aCqwbREfZlM88D/G756rN8b8kA6U1pQbqUSS3FGoqEWc1FxIgDO05jiRQIA AA== Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "ipv6@ietf.org" , "draft-ietf-6man-udpzero@tools.ietf.org" , The IESG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 09:24:39 -0000 Hi, Only having thought about this shortly, I think this is reasonable to add. I might have another opinion when we actually start writing it. But in that case I will come back and tell why I have another opinion. Cheers Magnus On 2012-10-11 04:05, Ronald Bonica wrote: > Magnus, > > I think that we are on the same page and I am nearly ready to clear my DISCUSS. > > Would you be willing to add a short section in an Appendix that illustrates the kind of analysis that you are requiring of a protocol that wants to rely on UDPZero? I am thinking of something like the following: > > Sample Text > =========== > Protocol Foo encapsulates an IP datagram within the following: > > - a foo header > - a UDP header > - an outer IPv6 header > > Because the UDP checksum is set to zero, the following fields are unprotected: > > - foo header: field1 > - foo header: field2 > - UDP header: source port > - UDP header: destination port > - outer IPv6 header: source address > - outer IPv6 header: destination address > > The consequence of corruption in field1 of the foo header is mumble. The consequence of corruption in field2 of the foo header is grumble, but only if some other condition is true. The consequence of corruption in any other field is, at worst, loss of the packet. > > Assume a tunnel with the following characteristics: > > - sustained data rate of 1 Gbps > - Bit error rate of 10**-12 on each of 4 constituent links > - average packet size equal to 1500 bytes > > The bullet list, below, provides an estimate of the frequency with which each of the above mentioned fields will be corrupted: > > - foo header: field1 (once per N seconds) > - foo header: field2 (once per N seconds) > - UDP header: source port (once per N seconds) > - UDP header: destination port (once per N seconds) > - outer IPv6 header: source address (once per N seconds) > - outer IPv6 header: destination address (once per N seconds) > > ========================== > End sample text > > Does this sound reasonable? > > Ron > > > > >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Wednesday, October 10, 2012 4:59 AM >> To: Ronald Bonica >> Cc: The IESG; 6man-chairs@tools.ietf.org; draft-ietf-6man- >> udpzero@tools.ietf.org; ipv6@ietf.org >> Subject: Re: Ronald Bonica's Discuss on draft-ietf-6man-udpzero-06: >> (with DISCUSS) >> >> On 2012-10-09 20:57, Ronald Bonica wrote: >>> Ronald Bonica has entered the following ballot position for >>> draft-ietf-6man-udpzero-06: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut >>> this introductory paragraph, however.) >>> >>> >>> Please refer to >>> http://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> >>> >>> --------------------------------------------------------------------- >> - >>> DISCUSS: >>> --------------------------------------------------------------------- >> - >>> >>> This is a two-part DISCUSS-DISCUSS. Both parts relate to bullet >> points >>> in Section 5.1. >>> >>> Bullet 5 >>> ====== >>> "Tunnels that encapsulate IP may rely on the inner packet >>> integrity checks provided that the tunnel will not significantly >>> increase the rate of corruption of the inner IP packet." >>> >>> - What does it mean to *significantly* increase the rate of >> corruption >>> of the inner IP packet? >> >> That is a good question. And the answer is it depends. If you are >> considering a tunnel protocols which target deployment area is one >> where you have very low rates of corruption, lets say below 10^-6 then >> a factor of 2 or even 10 might be fine as the resulting end-to-end >> basic IP service may still be fine. But if that same tunnel is supposed >> to support something that requires a packet loss rate below 10^-6 then >> any increase in corruption might be to high. >> >>> - Shouldn't we also be concerned about corruption of the UDP header >>> and any additional encapsulation that comes between the UDP header >> and >>> the inner IP packet? >> >> I think the formulation actually is considering that. If the >> IPv6/UDP/FOO tunnel protocol carries IP and FOO is senesitive to >> corruption then isn't the payload of the tunnel, i.e. the inner IP >> going to suffer an increased corruption rate. >> >>> - How does a tunnel ingress node know whether the tunnel will >>> significantly increase the rate of corruption of the inner IP packet? >> >> That is something you have to statistically analyze when designing the >> protocol and deciding on using zero-checksum. >> >>> >>> Bullet 7 >>> =====- >>> " UDP applications that support use of a zero-checksum, should not >>> rely upon correct reception of the IP and UDP protocol >>> information (including the length of the packet) when decoding >>> and processing the packet payload. In particular, the >>> application must be designed so that corruption of this >>> information does not result in accumulated state or incorrect >>> processing of a tunneled payload." >>> >>> - How could any application achieve this goal? Possibly by analyzing >>> the consequences if any field in the IPv6 or UDP header were >> corrupted? >>> (draft-ietf-6man-udpchecksums begins this analysis.) Again, wouldn't >>> the analysis have to include any additional encapsulation that comes >>> between the UDP header and the inner IP header? >> >> Yes, this is a design analysis which includes the tunnel protocols >> headers. >> >>> >>> - Wouldn't the analysis, mentioned above, have to include assurances >>> regarding the case when the destination port is corrupted? >>> Specifically, would it have to include a guarantee that if the >>> encapsulated inner packet were delivered to any randomly chosen port, >>> it would not cause any harm to the application listening on that >> port? >> >> Clearly it can't include a guarantee that it will not harm what ever is >> at the randomly chosen port. But one part we try to get across in this >> document is that this is the reason we want to ensure that default >> remains to have the UDP checksum enabled to avoid having applications >> not having considered this in their design or at least been analyzed to >> be safe enough to get zero checksummed packets. >> >> The next step is the question of potential harm is a statistics game. >> And the more traffic that are transported over the network with zero- >> checksum the higher the probability that you will get a packet not >> intended for your context. Thus you will have to deal with it. Here I >> think most tunnel egresses are reasonably simple to analyze what >> happens. You attempt to decapsulate it according to whats in the >> packet. >> If that is not a mismatch you try to do the next step for the inner >> packet, switching or forwarding that based on whats there. That either >> matches or not the context and are thus sent further or discarded. If >> there is a checksum on that level it can help discarding packets that >> completely misses the context. >> >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From rbonica@juniper.net Fri Oct 12 06:55:06 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A212221F857D; Fri, 12 Oct 2012 06:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.335 X-Spam-Level: X-Spam-Status: No, score=-106.335 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ql8r3fcUl6b0; Fri, 12 Oct 2012 06:55:05 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 3507A21F853B; Fri, 12 Oct 2012 06:55:03 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUHghNGZ2v55iHCtOSNn9pDC+z/PKAcf0@postini.com; Fri, 12 Oct 2012 06:55:05 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 12 Oct 2012 06:51:46 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 12 Oct 2012 09:51:45 -0400 From: Ronald Bonica To: Magnus Westerlund Date: Fri, 12 Oct 2012 09:51:44 -0400 Subject: RE: Ronald Bonica's Discuss on draft-ietf-6man-udpzero-06: (with DISCUSS) Thread-Topic: Ronald Bonica's Discuss on draft-ietf-6man-udpzero-06: (with DISCUSS) Thread-Index: Ac2oW2nbX2QHV3Q0Q0yMRvdesFIvVgAJRDVQ Message-ID: <13205C286662DE4387D9AF3AC30EF456D783A25756@EMBX01-WF.jnpr.net> References: <20121009185726.29097.69699.idtracker@ietfa.amsl.com> <507538F1.5080505@ericsson.com> <13205C286662DE4387D9AF3AC30EF456D783A25412@EMBX01-WF.jnpr.net> <5077E1C7.4090404@ericsson.com> In-Reply-To: <5077E1C7.4090404@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "ipv6@ietf.org" , "draft-ietf-6man-udpzero@tools.ietf.org" , The IESG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 13:55:06 -0000 TWFnbnVzLA0KDQpUaGFua3MhIEkgd2lsbCBkb3duZ3JhZGUgbXkgRElTQ1VTUyB0byBhIGNvbW1l bnQgYW5kIHRydXN0IHlvdSB0byBtYWtlIHRoYXQgY2hhbmdlLg0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uDQoNCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYWdudXMgV2VzdGVybHVuZCBbbWFpbHRvOm1hZ251cy53 ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbV0NCj4gU2VudDogRnJpZGF5LCBPY3RvYmVyIDEyLCAyMDEy IDU6MjQgQU0NCj4gVG86IFJvbmFsZCBCb25pY2ENCj4gQ2M6IFRoZSBJRVNHOyA2bWFuLWNoYWly c0B0b29scy5pZXRmLm9yZzsgZHJhZnQtaWV0Zi02bWFuLQ0KPiB1ZHB6ZXJvQHRvb2xzLmlldGYu b3JnOyBpcHY2QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBSb25hbGQgQm9uaWNhJ3MgRGlzY3Vz cyBvbiBkcmFmdC1pZXRmLTZtYW4tdWRwemVyby0wNjoNCj4gKHdpdGggRElTQ1VTUykNCj4gDQo+ IEhpLA0KPiANCj4gT25seSBoYXZpbmcgdGhvdWdodCBhYm91dCB0aGlzIHNob3J0bHksIEkgdGhp bmsgdGhpcyBpcyByZWFzb25hYmxlIHRvDQo+IGFkZC4gSSBtaWdodCBoYXZlIGFub3RoZXIgb3Bp bmlvbiB3aGVuIHdlIGFjdHVhbGx5IHN0YXJ0IHdyaXRpbmcgaXQuDQo+IEJ1dCBpbiB0aGF0IGNh c2UgSSB3aWxsIGNvbWUgYmFjayBhbmQgdGVsbCB3aHkgSSBoYXZlIGFub3RoZXIgb3Bpbmlvbi4N Cj4gDQo+IENoZWVycw0KPiANCj4gTWFnbnVzDQo+IA0KPiBPbiAyMDEyLTEwLTExIDA0OjA1LCBS b25hbGQgQm9uaWNhIHdyb3RlOg0KPiA+IE1hZ251cywNCj4gPg0KPiA+IEkgdGhpbmsgdGhhdCB3 ZSBhcmUgb24gdGhlIHNhbWUgcGFnZSBhbmQgSSBhbSBuZWFybHkgcmVhZHkgdG8gY2xlYXINCj4g bXkgRElTQ1VTUy4NCj4gPg0KPiA+IFdvdWxkIHlvdSBiZSB3aWxsaW5nIHRvIGFkZCBhIHNob3J0 IHNlY3Rpb24gaW4gYW4gQXBwZW5kaXggdGhhdA0KPiBpbGx1c3RyYXRlcyB0aGUga2luZCBvZiBh bmFseXNpcyB0aGF0IHlvdSBhcmUgcmVxdWlyaW5nIG9mIGEgcHJvdG9jb2wNCj4gdGhhdCB3YW50 cyB0byByZWx5IG9uIFVEUFplcm8/IEkgYW0gdGhpbmtpbmcgb2Ygc29tZXRoaW5nIGxpa2UgdGhl DQo+IGZvbGxvd2luZzoNCj4gPg0KPiA+IFNhbXBsZSBUZXh0DQo+ID4gPT09PT09PT09PT0NCj4g PiBQcm90b2NvbCBGb28gZW5jYXBzdWxhdGVzIGFuIElQIGRhdGFncmFtIHdpdGhpbiB0aGUgZm9s bG93aW5nOg0KPiA+DQo+ID4gLSBhIGZvbyBoZWFkZXINCj4gPiAtIGEgVURQIGhlYWRlcg0KPiA+ IC0gYW4gb3V0ZXIgSVB2NiBoZWFkZXINCj4gPg0KPiA+IEJlY2F1c2UgdGhlIFVEUCBjaGVja3N1 bSBpcyBzZXQgdG8gemVybywgdGhlIGZvbGxvd2luZyBmaWVsZHMgYXJlDQo+IHVucHJvdGVjdGVk Og0KPiA+DQo+ID4gLSBmb28gaGVhZGVyOiBmaWVsZDENCj4gPiAtIGZvbyBoZWFkZXI6IGZpZWxk Mg0KPiA+IC0gVURQIGhlYWRlcjogc291cmNlIHBvcnQNCj4gPiAtIFVEUCBoZWFkZXI6IGRlc3Rp bmF0aW9uIHBvcnQNCj4gPiAtIG91dGVyIElQdjYgaGVhZGVyOiBzb3VyY2UgYWRkcmVzcw0KPiA+ IC0gb3V0ZXIgSVB2NiBoZWFkZXI6IGRlc3RpbmF0aW9uICBhZGRyZXNzDQo+ID4NCj4gPiBUaGUg Y29uc2VxdWVuY2Ugb2YgY29ycnVwdGlvbiBpbiBmaWVsZDEgb2YgdGhlIGZvbyBoZWFkZXIgaXMg bXVtYmxlLg0KPiBUaGUgY29uc2VxdWVuY2Ugb2YgY29ycnVwdGlvbiBpbiBmaWVsZDIgb2YgdGhl IGZvbyBoZWFkZXIgaXMgZ3J1bWJsZSwNCj4gYnV0IG9ubHkgaWYgc29tZSBvdGhlciBjb25kaXRp b24gaXMgdHJ1ZS4gVGhlIGNvbnNlcXVlbmNlIG9mIGNvcnJ1cHRpb24NCj4gaW4gYW55IG90aGVy IGZpZWxkIGlzLCBhdCB3b3JzdCwgbG9zcyBvZiB0aGUgcGFja2V0Lg0KPiA+DQo+ID4gQXNzdW1l IGEgdHVubmVsIHdpdGggdGhlIGZvbGxvd2luZyBjaGFyYWN0ZXJpc3RpY3M6DQo+ID4NCj4gPiAt IHN1c3RhaW5lZCBkYXRhIHJhdGUgb2YgMSBHYnBzDQo+ID4gLSBCaXQgZXJyb3IgcmF0ZSBvZiAx MCoqLTEyIG9uIGVhY2ggb2YgNCBjb25zdGl0dWVudCBsaW5rcw0KPiA+IC0gYXZlcmFnZSBwYWNr ZXQgc2l6ZSBlcXVhbCB0byAxNTAwIGJ5dGVzDQo+ID4NCj4gPiBUaGUgYnVsbGV0IGxpc3QsIGJl bG93LCBwcm92aWRlcyBhbiBlc3RpbWF0ZSBvZiB0aGUgZnJlcXVlbmN5IHdpdGgNCj4gd2hpY2gg ZWFjaCBvZiB0aGUgYWJvdmUgbWVudGlvbmVkIGZpZWxkcyB3aWxsIGJlIGNvcnJ1cHRlZDoNCj4g Pg0KPiA+IC0gZm9vIGhlYWRlcjogZmllbGQxIChvbmNlIHBlciBOIHNlY29uZHMpDQo+ID4gLSBm b28gaGVhZGVyOiBmaWVsZDIgKG9uY2UgcGVyIE4gc2Vjb25kcykNCj4gPiAtIFVEUCBoZWFkZXI6 IHNvdXJjZSBwb3J0IChvbmNlIHBlciBOIHNlY29uZHMpDQo+ID4gLSBVRFAgaGVhZGVyOiBkZXN0 aW5hdGlvbiBwb3J0IChvbmNlIHBlciBOIHNlY29uZHMpDQo+ID4gLSBvdXRlciBJUHY2IGhlYWRl cjogc291cmNlIGFkZHJlc3MgKG9uY2UgcGVyIE4gc2Vjb25kcykNCj4gPiAtIG91dGVyIElQdjYg aGVhZGVyOiBkZXN0aW5hdGlvbiAgYWRkcmVzcyAob25jZSBwZXIgTiBzZWNvbmRzKQ0KPiA+DQo+ ID4gPT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gPiBFbmQgc2FtcGxlIHRleHQNCj4gPg0K PiA+IERvZXMgdGhpcyBzb3VuZCByZWFzb25hYmxlPw0KPiA+DQo+ID4gICAgICAgICAgICAgICAg ICAgICAgICAgUm9uDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPj4gRnJvbTogTWFnbnVzIFdlc3Rlcmx1bmQgW21haWx0bzptYWdudXMud2Vz dGVybHVuZEBlcmljc3Nvbi5jb21dDQo+ID4+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxMCwg MjAxMiA0OjU5IEFNDQo+ID4+IFRvOiBSb25hbGQgQm9uaWNhDQo+ID4+IENjOiBUaGUgSUVTRzsg Nm1hbi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IGRyYWZ0LWlldGYtNm1hbi0NCj4gPj4gdWRwemVy b0B0b29scy5pZXRmLm9yZzsgaXB2NkBpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogUm9uYWxk IEJvbmljYSdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi02bWFuLXVkcHplcm8tMDY6DQo+ID4+ICh3 aXRoIERJU0NVU1MpDQo+ID4+DQo+ID4+IE9uIDIwMTItMTAtMDkgMjA6NTcsIFJvbmFsZCBCb25p Y2Egd3JvdGU6DQo+ID4+PiBSb25hbGQgQm9uaWNhIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcg YmFsbG90IHBvc2l0aW9uIGZvcg0KPiA+Pj4gZHJhZnQtaWV0Zi02bWFuLXVkcHplcm8tMDY6IERp c2N1c3MNCj4gPj4+DQo+ID4+PiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJq ZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0bw0KPiA+Pj4gYWxsIGVtYWlsIGFkZHJlc3NlcyBp bmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvDQo+ID4+PiBjdXQg dGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4gPj4+DQo+ID4+Pg0KPiA+ Pj4gUGxlYXNlIHJlZmVyIHRvDQo+ID4+PiBodHRwOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVt ZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiA+Pj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJv dXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gPj4+DQo+ID4+Pg0KPiA+ Pj4NCj4gPj4+DQo+ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0NCj4gPj4+IC0NCj4gPj4gLQ0KPiA+Pj4g RElTQ1VTUzoNCj4gPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLQ0KPiA+Pj4gLQ0KPiA+PiAtDQo+ID4+Pg0K PiA+Pj4gVGhpcyBpcyBhIHR3by1wYXJ0IERJU0NVU1MtRElTQ1VTUy4gQm90aCBwYXJ0cyByZWxh dGUgdG8gYnVsbGV0DQo+ID4+IHBvaW50cw0KPiA+Pj4gaW4gU2VjdGlvbiA1LjEuDQo+ID4+Pg0K PiA+Pj4gQnVsbGV0IDUNCj4gPj4+ID09PT09PQ0KPiA+Pj4gIlR1bm5lbHMgdGhhdCBlbmNhcHN1 bGF0ZSBJUCBtYXkgcmVseSBvbiB0aGUgaW5uZXIgcGFja2V0DQo+ID4+PiAgIGludGVncml0eSBj aGVja3MgcHJvdmlkZWQgdGhhdCB0aGUgdHVubmVsIHdpbGwgbm90IHNpZ25pZmljYW50bHkNCj4g Pj4+ICAgaW5jcmVhc2UgdGhlIHJhdGUgb2YgY29ycnVwdGlvbiBvZiB0aGUgaW5uZXIgSVAgcGFj a2V0LiINCj4gPj4+DQo+ID4+PiAtIFdoYXQgZG9lcyBpdCBtZWFuIHRvICpzaWduaWZpY2FudGx5 KiBpbmNyZWFzZSB0aGUgcmF0ZSBvZg0KPiA+PiBjb3JydXB0aW9uDQo+ID4+PiBvZiB0aGUgaW5u ZXIgSVAgcGFja2V0Pw0KPiA+Pg0KPiA+PiBUaGF0IGlzIGEgZ29vZCBxdWVzdGlvbi4gQW5kIHRo ZSBhbnN3ZXIgaXMgaXQgZGVwZW5kcy4gSWYgeW91IGFyZQ0KPiA+PiBjb25zaWRlcmluZyBhIHR1 bm5lbCBwcm90b2NvbHMgd2hpY2ggdGFyZ2V0IGRlcGxveW1lbnQgYXJlYSBpcyBvbmUNCj4gPj4g d2hlcmUgeW91IGhhdmUgdmVyeSBsb3cgcmF0ZXMgb2YgY29ycnVwdGlvbiwgbGV0cyBzYXkgYmVs b3cgMTBeLTYNCj4gPj4gdGhlbiBhIGZhY3RvciBvZiAyIG9yIGV2ZW4gMTAgbWlnaHQgYmUgZmlu ZSBhcyB0aGUgcmVzdWx0aW5nDQo+ID4+IGVuZC10by1lbmQgYmFzaWMgSVAgc2VydmljZSBtYXkg c3RpbGwgYmUgZmluZS4gQnV0IGlmIHRoYXQgc2FtZQ0KPiA+PiB0dW5uZWwgaXMgc3VwcG9zZWQg dG8gc3VwcG9ydCBzb21ldGhpbmcgdGhhdCByZXF1aXJlcyBhIHBhY2tldCBsb3NzDQo+ID4+IHJh dGUgYmVsb3cgMTBeLTYgdGhlbiBhbnkgaW5jcmVhc2UgaW4gY29ycnVwdGlvbiBtaWdodCBiZSB0 byBoaWdoLg0KPiA+Pg0KPiA+Pj4gLSBTaG91bGRuJ3Qgd2UgYWxzbyBiZSBjb25jZXJuZWQgYWJv dXQgY29ycnVwdGlvbiBvZiB0aGUgVURQIGhlYWRlcg0KPiA+Pj4gYW5kIGFueSBhZGRpdGlvbmFs IGVuY2Fwc3VsYXRpb24gdGhhdCBjb21lcyBiZXR3ZWVuIHRoZSBVRFAgaGVhZGVyDQo+ID4+IGFu ZA0KPiA+Pj4gdGhlIGlubmVyIElQIHBhY2tldD8NCj4gPj4NCj4gPj4gSSB0aGluayB0aGUgZm9y bXVsYXRpb24gYWN0dWFsbHkgaXMgY29uc2lkZXJpbmcgdGhhdC4gSWYgdGhlDQo+ID4+IElQdjYv VURQL0ZPTyB0dW5uZWwgcHJvdG9jb2wgY2FycmllcyBJUCBhbmQgRk9PIGlzIHNlbmVzaXRpdmUg dG8NCj4gPj4gY29ycnVwdGlvbiB0aGVuIGlzbid0IHRoZSBwYXlsb2FkIG9mIHRoZSB0dW5uZWws IGkuZS4gdGhlIGlubmVyIElQDQo+ID4+IGdvaW5nIHRvIHN1ZmZlciBhbiBpbmNyZWFzZWQgY29y cnVwdGlvbiByYXRlLg0KPiA+Pg0KPiA+Pj4gLSBIb3cgZG9lcyBhIHR1bm5lbCBpbmdyZXNzIG5v ZGUga25vdyB3aGV0aGVyIHRoZSB0dW5uZWwgd2lsbA0KPiA+Pj4gc2lnbmlmaWNhbnRseSBpbmNy ZWFzZSB0aGUgcmF0ZSBvZiBjb3JydXB0aW9uIG9mIHRoZSBpbm5lciBJUA0KPiBwYWNrZXQ/DQo+ ID4+DQo+ID4+IFRoYXQgaXMgc29tZXRoaW5nIHlvdSBoYXZlIHRvIHN0YXRpc3RpY2FsbHkgYW5h bHl6ZSB3aGVuIGRlc2lnbmluZw0KPiA+PiB0aGUgcHJvdG9jb2wgYW5kIGRlY2lkaW5nIG9uIHVz aW5nIHplcm8tY2hlY2tzdW0uDQo+ID4+DQo+ID4+Pg0KPiA+Pj4gQnVsbGV0IDcNCj4gPj4+ID09 PT09LQ0KPiA+Pj4gICAgIiBVRFAgYXBwbGljYXRpb25zIHRoYXQgc3VwcG9ydCB1c2Ugb2YgYSB6 ZXJvLWNoZWNrc3VtLCBzaG91bGQNCj4gbm90DQo+ID4+PiAgICAgICAgcmVseSB1cG9uIGNvcnJl Y3QgcmVjZXB0aW9uIG9mIHRoZSBJUCBhbmQgVURQIHByb3RvY29sDQo+ID4+PiAgICAgICAgaW5m b3JtYXRpb24gKGluY2x1ZGluZyB0aGUgbGVuZ3RoIG9mIHRoZSBwYWNrZXQpIHdoZW4NCj4gZGVj b2RpbmcNCj4gPj4+ICAgICAgICBhbmQgcHJvY2Vzc2luZyB0aGUgcGFja2V0IHBheWxvYWQuICBJ biBwYXJ0aWN1bGFyLCB0aGUNCj4gPj4+ICAgICAgICBhcHBsaWNhdGlvbiBtdXN0IGJlIGRlc2ln bmVkIHNvIHRoYXQgY29ycnVwdGlvbiBvZiB0aGlzDQo+ID4+PiAgICAgICAgaW5mb3JtYXRpb24g ZG9lcyBub3QgcmVzdWx0IGluIGFjY3VtdWxhdGVkIHN0YXRlIG9yDQo+IGluY29ycmVjdA0KPiA+ Pj4gICAgICAgIHByb2Nlc3Npbmcgb2YgYSB0dW5uZWxlZCBwYXlsb2FkLiINCj4gPj4+DQo+ID4+ PiAtIEhvdyBjb3VsZCBhbnkgYXBwbGljYXRpb24gYWNoaWV2ZSB0aGlzIGdvYWw/IFBvc3NpYmx5 IGJ5DQo+IGFuYWx5emluZw0KPiA+Pj4gdGhlIGNvbnNlcXVlbmNlcyBpZiBhbnkgZmllbGQgaW4g dGhlIElQdjYgb3IgVURQIGhlYWRlciB3ZXJlDQo+ID4+IGNvcnJ1cHRlZD8NCj4gPj4+IChkcmFm dC1pZXRmLTZtYW4tdWRwY2hlY2tzdW1zIGJlZ2lucyB0aGlzIGFuYWx5c2lzLikgIEFnYWluLA0K PiA+Pj4gd291bGRuJ3QgdGhlIGFuYWx5c2lzIGhhdmUgdG8gaW5jbHVkZSBhbnkgYWRkaXRpb25h bCBlbmNhcHN1bGF0aW9uDQo+ID4+PiB0aGF0IGNvbWVzIGJldHdlZW4gdGhlIFVEUCBoZWFkZXIg YW5kIHRoZSBpbm5lciBJUCBoZWFkZXI/DQo+ID4+DQo+ID4+IFllcywgdGhpcyBpcyBhIGRlc2ln biBhbmFseXNpcyB3aGljaCBpbmNsdWRlcyB0aGUgdHVubmVsIHByb3RvY29scw0KPiA+PiBoZWFk ZXJzLg0KPiA+Pg0KPiA+Pj4NCj4gPj4+IC0gV291bGRuJ3QgdGhlIGFuYWx5c2lzLCBtZW50aW9u ZWQgYWJvdmUsIGhhdmUgdG8gaW5jbHVkZQ0KPiBhc3N1cmFuY2VzDQo+ID4+PiByZWdhcmRpbmcg dGhlIGNhc2Ugd2hlbiB0aGUgZGVzdGluYXRpb24gcG9ydCBpcyBjb3JydXB0ZWQ/DQo+ID4+PiBT cGVjaWZpY2FsbHksIHdvdWxkIGl0IGhhdmUgdG8gaW5jbHVkZSBhIGd1YXJhbnRlZSB0aGF0IGlm IHRoZQ0KPiA+Pj4gZW5jYXBzdWxhdGVkIGlubmVyIHBhY2tldCB3ZXJlIGRlbGl2ZXJlZCB0byBh bnkgcmFuZG9tbHkgY2hvc2VuDQo+ID4+PiBwb3J0LCBpdCB3b3VsZCBub3QgY2F1c2UgYW55IGhh cm0gdG8gdGhlIGFwcGxpY2F0aW9uIGxpc3RlbmluZyBvbg0KPiA+Pj4gdGhhdA0KPiA+PiBwb3J0 Pw0KPiA+Pg0KPiA+PiBDbGVhcmx5IGl0IGNhbid0IGluY2x1ZGUgYSBndWFyYW50ZWUgdGhhdCBp dCB3aWxsIG5vdCBoYXJtIHdoYXQgZXZlcg0KPiA+PiBpcyBhdCB0aGUgcmFuZG9tbHkgY2hvc2Vu IHBvcnQuIEJ1dCBvbmUgcGFydCB3ZSB0cnkgdG8gZ2V0IGFjcm9zcyBpbg0KPiA+PiB0aGlzIGRv Y3VtZW50IGlzIHRoYXQgdGhpcyBpcyB0aGUgcmVhc29uIHdlIHdhbnQgdG8gZW5zdXJlIHRoYXQN Cj4gPj4gZGVmYXVsdCByZW1haW5zIHRvIGhhdmUgdGhlIFVEUCBjaGVja3N1bSBlbmFibGVkIHRv IGF2b2lkIGhhdmluZw0KPiA+PiBhcHBsaWNhdGlvbnMgbm90IGhhdmluZyBjb25zaWRlcmVkIHRo aXMgaW4gdGhlaXIgZGVzaWduIG9yIGF0IGxlYXN0DQo+ID4+IGJlZW4gYW5hbHl6ZWQgdG8gYmUg c2FmZSBlbm91Z2ggdG8gZ2V0IHplcm8gY2hlY2tzdW1tZWQgcGFja2V0cy4NCj4gPj4NCj4gPj4g VGhlIG5leHQgc3RlcCBpcyB0aGUgcXVlc3Rpb24gb2YgcG90ZW50aWFsIGhhcm0gaXMgYSBzdGF0 aXN0aWNzDQo+IGdhbWUuDQo+ID4+IEFuZCB0aGUgbW9yZSB0cmFmZmljIHRoYXQgYXJlIHRyYW5z cG9ydGVkIG92ZXIgdGhlIG5ldHdvcmsgd2l0aA0KPiB6ZXJvLQ0KPiA+PiBjaGVja3N1bSB0aGUg aGlnaGVyIHRoZSBwcm9iYWJpbGl0eSB0aGF0IHlvdSB3aWxsIGdldCBhIHBhY2tldCBub3QNCj4g Pj4gaW50ZW5kZWQgZm9yIHlvdXIgY29udGV4dC4gVGh1cyB5b3Ugd2lsbCBoYXZlIHRvIGRlYWwg d2l0aCBpdC4gSGVyZQ0KPiBJDQo+ID4+IHRoaW5rIG1vc3QgdHVubmVsIGVncmVzc2VzIGFyZSBy ZWFzb25hYmx5IHNpbXBsZSB0byBhbmFseXplIHdoYXQNCj4gPj4gaGFwcGVucy4gWW91IGF0dGVt cHQgdG8gZGVjYXBzdWxhdGUgaXQgYWNjb3JkaW5nIHRvIHdoYXRzIGluIHRoZQ0KPiA+PiBwYWNr ZXQuDQo+ID4+IElmIHRoYXQgaXMgbm90IGEgbWlzbWF0Y2ggeW91IHRyeSB0byBkbyB0aGUgbmV4 dCBzdGVwIGZvciB0aGUgaW5uZXINCj4gPj4gcGFja2V0LCBzd2l0Y2hpbmcgb3IgZm9yd2FyZGlu ZyB0aGF0IGJhc2VkIG9uIHdoYXRzIHRoZXJlLiBUaGF0DQo+ID4+IGVpdGhlciBtYXRjaGVzIG9y IG5vdCB0aGUgY29udGV4dCBhbmQgYXJlIHRodXMgc2VudCBmdXJ0aGVyIG9yDQo+ID4+IGRpc2Nh cmRlZC4gSWYgdGhlcmUgaXMgYSBjaGVja3N1bSBvbiB0aGF0IGxldmVsIGl0IGNhbiBoZWxwDQo+ ID4+IGRpc2NhcmRpbmcgcGFja2V0cyB0aGF0IGNvbXBsZXRlbHkgbWlzc2VzIHRoZSBjb250ZXh0 Lg0KPiA+Pg0KPiA+Pg0KPiA+PiBDaGVlcnMNCj4gPj4NCj4gPj4gTWFnbnVzIFdlc3Rlcmx1bmQN Cj4gPj4NCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLQ0KPiA+PiAtIE11bHRpbWVkaWEgVGVjaG5vbG9n aWVzLCBFcmljc3NvbiBSZXNlYXJjaCBFQUIvVFZNDQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tDQo+ ID4+IEVyaWNzc29uIEFCICAgICAgICAgICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQo+ ID4+IEbDpHLDtmdhdGFuIDYgICAgICAgICAgICAgICAgfCBNb2JpbGUgKzQ2IDczIDA5NDkwNzkN Cj4gPj4gU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVufCBtYWlsdG86IG1hZ251cy53ZXN0ZXJs dW5kQGVyaWNzc29uLmNvbQ0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtDQo+ID4+IC0NCj4gPg0KPiAN Cj4gDQo+IC0tDQo+IA0KPiBNYWdudXMgV2VzdGVybHVuZA0KPiANCj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiBNdWx0aW1lZGlhIFRlY2hub2xvZ2llcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RWTQ0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+IEVyaWNzc29uIEFCICAgICAgICAgICAgICAgIHwgUGhvbmUgICs0NiAx MCA3MTQ4Mjg3DQo+IEbDpHLDtmdhdGFuIDYgICAgICAgICAgICAgICAgfCBNb2JpbGUgKzQ2IDcz IDA5NDkwNzkNCj4gU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVufCBtYWlsdG86IG1hZ251cy53 ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg== From rbonica@juniper.net Fri Oct 12 06:55:39 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1AF321F85A7; Fri, 12 Oct 2012 06:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.426 X-Spam-Level: X-Spam-Status: No, score=-102.426 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C45yfM2iM9Jj; Fri, 12 Oct 2012 06:55:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A7521F8582; Fri, 12 Oct 2012 06:55:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Ronald Bonica" To: The IESG Subject: Ronald Bonica's Yes on draft-ietf-6man-udpzero-06: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121012135539.23556.53985.idtracker@ietfa.amsl.com> Date: Fri, 12 Oct 2012 06:55:39 -0700 Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, draft-ietf-6man-udpzero@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 13:55:40 -0000 Ronald Bonica has entered the following ballot position for draft-ietf-6man-udpzero-06: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Would you be willing to add a short section in an Appendix that illustrates the kind of analysis that you are requiring of a protocol that wants to rely on UDPZero? I am thinking of something like the following: Sample Text =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Protocol Foo encapsulates an IP datagram within the following: - a foo header - a UDP header - an outer IPv6 header Because the UDP checksum is set to zero, the following fields are unprotected: - foo header: field1 - foo header: field2 - UDP header: source port - UDP header: destination port - outer IPv6 header: source address - outer IPv6 header: destination address The consequence of corruption in field1 of the foo header is mumble. The consequence of corruption in field2 of the foo header is grumble, but only if some other condition is true. The consequence of corruption in any other field is, at worst, loss of the packet. Assume a tunnel with the following characteristics: - sustained data rate of 1 Gbps - Bit error rate of 10**-12 on each of 4 constituent links - average packet size equal to 1500 bytes The bullet list, below, provides an estimate of the frequency with which each of the above mentioned fields will be corrupted: - foo header: field1 (once per N seconds) - foo header: field2 (once per N seconds) - UDP header: source port (once per N seconds) - UDP header: destination port (once per N seconds) - outer IPv6 header: source address (once per N seconds) - outer IPv6 header: destination address (once per N seconds) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D End sample text Does this sound reasonable? From rbonica@juniper.net Fri Oct 12 06:57:03 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240B221F85C3; Fri, 12 Oct 2012 06:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3q9AdD5gbryL; Fri, 12 Oct 2012 06:57:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1B421F85B6; Fri, 12 Oct 2012 06:57:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Ronald Bonica" To: The IESG Subject: Ronald Bonica's Yes on draft-ietf-6man-udpchecksums-04 X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121012135702.23610.91583.idtracker@ietfa.amsl.com> Date: Fri, 12 Oct 2012 06:57:02 -0700 Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-udpchecksums@tools.ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 13:57:03 -0000 Ronald Bonica has entered the following ballot position for draft-ietf-6man-udpchecksums-04: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. There are no remarks associated with this position. From rja.lists@gmail.com Fri Oct 12 11:59:36 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54FD21F86C1 for ; Fri, 12 Oct 2012 11:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.538 X-Spam-Level: X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yX9AgGYlv11Y for ; Fri, 12 Oct 2012 11:59:36 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0DE21F86BD for ; Fri, 12 Oct 2012 11:59:36 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id 25so99557qao.10 for ; Fri, 12 Oct 2012 11:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=i5BI4DlTbrK4Q8uYDmoK4ZncyrxCpP/zUbk5h4Jffjo=; b=bSnLMm++cKWrnK3R+B6u5SgNcR6Y3VWDhUj+BVfAurGXtpmQpyJniZhK8FYfvGbsT9 pqeU9ADx1kMtpMiVhd+8NaLUVZp8t0z2/yw+e9ssvl+x7p4P5O9cx5ruiGxKlRg/utLm GzqM/NFEIB19JX8BvyzzZ0zlts9bcOeObalfmslw3BQHAVV+q6FIFYlSo1Tjt4giZC1v UvlqRXneao3/gPLWYyKYlzdOR11aZPTOuc3ZcxUq/gZBfHaglzfb4xH8yVYmSm2qIKI9 4RDc8wBplNARIm9h5ISL1gXasImkyxKpN1gjdFCRMHNYP8NK/VCArlDwugIGvD908/+F 4mMw== Received: by 10.49.59.82 with SMTP id x18mr11926442qeq.9.1350068375854; Fri, 12 Oct 2012 11:59:35 -0700 (PDT) Received: from [10.30.20.14] (pool-74-110-100-136.nrflva.fios.verizon.net. [74.110.100.136]) by mx.google.com with ESMTPS id f1sm7082334qes.2.2012.10.12.11.59.34 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Oct 2012 11:59:35 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: 6MAN WG Last Call: Date: Fri, 12 Oct 2012 14:59:33 -0400 Message-Id: <699244DC-3921-411C-A7B1-6FC3BD7C9EF6@gmail.com> To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 18:59:36 -0000 I support publishing this on the IETF Standards Track. Ran From rja.lists@gmail.com Fri Oct 12 12:04:37 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 396B421F871D for ; Fri, 12 Oct 2012 12:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.541 X-Spam-Level: X-Spam-Status: No, score=-3.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7G1lI52wxHt for ; Fri, 12 Oct 2012 12:04:36 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2768021F870F for ; Fri, 12 Oct 2012 12:04:36 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so2896509qcg.31 for ; Fri, 12 Oct 2012 12:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=gFy0Huc3UHP+aZ+SWUNlJz1CU+lCx3o2NyIjPumZkpc=; b=jypcjOqpiwiEk5dkKy7HMTwsLd/kAA/hgzRPwVjkO0e9Ig4blT9H8c4wUHaR+rwQ1z PX7yMV+Er56fjKzVHDcEpt//dwL8jcpU9Ix2VTMMpcxqiSGqZpez5KyUGzycK+fM6Kio WQRrVHgU20IV2Rx1eGnWWhghLkJFUPktHsZV7ZwhctcqcuC4iSFWD3qLkRAXIpqFKk9j 3Z2zLpJ/NbZfm8BLYlQCF5KsXoeXAyZUikNq9nwF3cVQhjCA4oGC3bghajswpq9dmRQy 7h58GfMfkFxpQjFL0eSNIaom+Kr61Ftw8mub2BhXcJXo4nNuEyu/aZ95Z+fdrfE0caZu tZKA== Received: by 10.224.190.136 with SMTP id di8mr8973996qab.72.1350068672728; Fri, 12 Oct 2012 12:04:32 -0700 (PDT) Received: from [10.30.20.14] (pool-74-110-100-136.nrflva.fios.verizon.net. [74.110.100.136]) by mx.google.com with ESMTPS id cz8sm2160092qab.21.2012.10.12.12.04.31 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Oct 2012 12:04:32 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: 6MAN WG Last Call: Date: Fri, 12 Oct 2012 15:04:30 -0400 Message-Id: To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 19:04:37 -0000 I support publishing this as an IETF Standards-Track RFC. I have no objection to the clarifying edits proposed by Ray Hunter in his IPv6 list note of 10 Oct 2012 at 12:00:33 +0200. Ran From rja.lists@gmail.com Fri Oct 12 12:07:20 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611F721F8753 for ; Fri, 12 Oct 2012 12:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKfkovu7JSzy for ; Fri, 12 Oct 2012 12:07:19 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id BC0D521F8750 for ; Fri, 12 Oct 2012 12:07:19 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id j40so95855qab.10 for ; Fri, 12 Oct 2012 12:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=jI+dvPFNl1Sw7bT75HmpAB+t4LoDssXtxYKP0gLduqw=; b=ab7uDSDeeJYDG3w7l8KT9zo8XDasV3P92rfkQ+EKzLW7B8joQMsWpsKBsqx6wt1b8b 6Biz7G8u+yLDdCUdCj4ctbFT7PWzsBatCIBNiHmxQIWlsGzdCHxgUFtml7GYUa12HrQy kAwXgaiAPuZbSn2ySUiqTCeC8A9zp8sQZvXh/8ugICoKLRVuqW7tEbpNSlgTHE5IUyxs +ECBiS4lzxAw9IkA+G1+HWW2v7OSe6GqeRCBLOs5BZrGwBeA3KJf/jlbF0LtWmO7sfjK kU9Sq9PH3HtYgIuR3tdLQ0/4cR/4YrkLSI9sZdqKtpN8/guf1jaFf90h0RzfoOJbDro/ fzjg== Received: by 10.224.180.7 with SMTP id bs7mr8923106qab.37.1350068839293; Fri, 12 Oct 2012 12:07:19 -0700 (PDT) Received: from [10.30.20.14] (pool-74-110-100-136.nrflva.fios.verizon.net. [74.110.100.136]) by mx.google.com with ESMTPS id q7sm7085242qeo.6.2012.10.12.12.07.18 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Oct 2012 12:07:18 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: draft-boucadair-6man-sip-proxy-01 Date: Fri, 12 Oct 2012 15:07:17 -0400 Message-Id: <07099AAD-5C12-48FC-B6A9-F3A2332AB5E5@gmail.com> To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 19:07:20 -0000 I agree with Ray Hunter's analysis of this proposal, as posted on the IPv6 list (available at the URL above). Ran From markzzzsmith@yahoo.com.au Fri Oct 12 16:16:29 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A828321F86FF for ; Fri, 12 Oct 2012 16:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4IC3t3tAm3U2 for ; Fri, 12 Oct 2012 16:16:28 -0700 (PDT) Received: from nm28.bullet.mail.ac4.yahoo.com (nm28.bullet.mail.ac4.yahoo.com [98.139.52.225]) by ietfa.amsl.com (Postfix) with ESMTP id EB8AE21F86C1 for <6man@ietf.org>; Fri, 12 Oct 2012 16:16:27 -0700 (PDT) Received: from [98.139.52.193] by nm28.bullet.mail.ac4.yahoo.com with NNFMP; 12 Oct 2012 23:16:24 -0000 Received: from [98.139.52.153] by tm6.bullet.mail.ac4.yahoo.com with NNFMP; 12 Oct 2012 23:16:24 -0000 Received: from [127.0.0.1] by omp1036.mail.ac4.yahoo.com with NNFMP; 12 Oct 2012 23:16:24 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 905051.90117.bm@omp1036.mail.ac4.yahoo.com Received: (qmail 87170 invoked by uid 60001); 12 Oct 2012 23:16:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1350083784; bh=apC3RRrv5OLWAh9UXrFpEqq+SpJdymMO/LyUd/D3a9w=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=4KdBtLYiUsXkOPFPpaIw+53DKHFm5E+D2kf/ia50TfNyifk2CDcuPaa9d7eQTwfCobqqGN8R+gu216YhfMuDiZOe0UTUeuNRw/7ivr0bj8xVu/xB2rFnGGRibeotUUMTiqh1eRV2KMCn0kKQpkvWA3DXNxwU6IZL6TwMaRRpTNQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=edMhFvsciEdVSRYPQUMKwYwTB7q+Eu3/N2RWpTV2WH7LIYt3k3A8pCasV7jC5gi9Lr9FuKIeSYlpqN0nPU1S4gFgNNWhVQBoSjKtTZ6KjL83SERB9BF5H8XDN36sSmrqt6TnLQyoVY9wz1efRBHQSd/6XUP/SAbX8Y1k+3d3XEU=; X-YMail-OSG: zA5KHjoVM1mDHquVS8yqMpFzFfcDfZMVotW55NbchfFGC.G VWIP8B0K3Us4cZYZb.95lnPZy7pBWoQV8SeLXNIgBnhKYddiuDl_zvkaCvVs Ncyn9RRS08FlMnfDO7bd4IGudxt3xy.PvHYdKZQNNppBTbT.OtvYbkkfVvM1 qWdbtCz0X._pTtzlZTcvNy.aRwQKgX7tIK3YD06Q095EaSJQEC9GBvDzX2Jh Vcyv4RbUKClyoZ6ZGpX8m0D9JN.nztnXuqoMu_MEt3P8ZFw9POY8natbR2Ng bYMxup0F6S5O1T_8DDMVaTsW9eqGYjvz60KnepBOYnQ5FZCMdRIr7FAVD_rv EoGL6_wwNIpKIO3zkxq_Z4BbOTN1hnbNcEGwHQTIxDmJ_2lN4rK2D88UrDRA blgDNUu30lq.QV0HKlkauzS70Gnz88S2SEINouRKHKNW5z8IxLDL1Y56oRzN uhlB_4_yDm5iVP3uedXlB9tCmhK1A.cqdA798JPaUd41Nzr8ElXiepuAySrO pgYEO4CKkqjIe_Q-- Received: from [150.101.221.237] by web32508.mail.mud.yahoo.com via HTTP; Fri, 12 Oct 2012 16:16:24 PDT X-Rocket-MIMEInfo: 001.001, SGksCgoKCkkgYWdyZWUgd2l0aCBSYXksIEkgdGhpbmsgdGhpcyBpcyBmdW5kYW1lbnRhbGx5IGp1c3QgcmUtaW52ZW50aW5nIHRoZSB3aGVlbC4KCkkgbm90aWNlIHRoYXQgb25lIG9mIHRoZSBqdXN0aWZpY2F0aW9ucyBmb3IgdGhpcyBpcyB0aGF0ICJESENQdjYgaXMgbm90CnJlcXVpcmVkIGluIGFsbCAzR1BQIHJlbGVhc2VzLiIgV2h5IGlzbid0IGl0PyBCYXNlZCBvbiB0aGlzIHN0YXRlbWVudCwKaXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgM0dQUCBhcmNoaXRlY3R1cmUgZG9lc24ndCByZWNvZ25pc2UgdGgBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.450 References: <94C682931C08B048B7A8645303FDC9F36E5F75BA9B@PUEXCB1B.nanterre.francetelecom.fr> <506F38A5.9090407@globis.net> <94C682931C08B048B7A8645303FDC9F36E63206263@PUEXCB1B.nanterre.francetelecom.fr> Message-ID: <1350083784.71918.YahooMailNeo@web32508.mail.mud.yahoo.com> Date: Fri, 12 Oct 2012 16:16:24 -0700 (PDT) From: Mark ZZZ Smith Subject: Re: draft-boucadair-6man-sip-proxy-01 To: "mohamed.boucadair@orange.com" , Ray Hunter In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E63206263@PUEXCB1B.nanterre.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 12 Oct 2012 16:27:52 -0700 Cc: "6man@ietf.org" <6man@ietf.org>, BINET David OLNC/OLN X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 23:16:29 -0000 Hi,=0A=0A=0A=0AI agree with Ray, I think this is fundamentally just re-inve= nting the wheel.=0A=0AI notice that one of the justifications for this is t= hat "DHCPv6 is not=0Arequired in all 3GPP releases." Why isn't it? Based on= this statement,=0Ait seems to me that the 3GPP architecture doesn't recogn= ise that there=0Aisn't really anything special about (smart)phones - they'r= e just portable,=0Asingle or multi-homed hosts with one or more wireless in= terfaces, and=0Atherefore should use standard and existing IPv6 mechanisms.= Making phone=0Acalls on them is just an application running on the host.= =0A=0ASupport for DHCPv6 is a SHOULD for hosts that support more than one= =0Aspecialised application: http://tools.ietf.org/html/rfc6434#section-7.2.= 1=0A=0AI think putting options like this and DNS (and of course, down the= =0Atrack, most other DHCPv6 options) in RAs is a violation of the Internet= =0Aarchitecture. The Internet is meant to be application transparent,=0Aand= I think this is it's greatest strength and advantage compared to the previ= ous=0Aapplication-specific networks such as the PSTN. It shouldn't be neces= sary=0Ato upgrade the software/firmware in a router to be able to run a new= =0Aapplication residing on the hosts, yet this is what applications/service= s=0Aconfiguration options in RAs would require.=0A=0ASo I think the Interne= t needs to be kept both services/application=0Atransparent as well as servi= ce/application configuration method=0Atransparent. RAs should be left to ju= st configuring the network layer/IP=0Aparameters, and an "over-the-top" pro= tocol, stateless DHCPv6, used to=0Aconfigure hosts' service and application= s. Routers operating as=0ADCHPv6 relays fit within this model because they'= re (new) DHCPv6 option=0Atransparent.=0A=0ARegards,=0AMark.=0A=0A=0A=0A----= - Original Message -----=0A> From: "mohamed.boucadair@orange.com" =0A> To: Ray Hunter =0A> Cc: "6man@i= etf.org" <6man@ietf.org>; BINET David OLNC/OLN =0A>= Sent: Friday, 12 October 2012 8:00 PM=0A> Subject: RE: draft-boucadair-6ma= n-sip-proxy-01=0A> =0A> Dear Ray, =0A> =0A> Thank you for the comments. =0A= > =0A> Please see inline. =0A> =0A> Cheers,=0A> Med=0A> =0A>> -----Message = d'origine-----=0A>> De : Ray Hunter [mailto:v6ops@globis.net] =0A>> Envoy= =E9 : vendredi 5 octobre 2012 21:45=0A>> =C0 : BOUCADAIR Mohamed OLNC/OLN= =0A>> Cc : 6man@ietf.org=0A>> Objet : Re: draft-boucadair-6man-sip-proxy-01= =0A>> =0A>> I have read this draft and do not support it as-is.=0A>> =0A>> = I do not agree with the conclusion that extending RA with a new option =0A>= > for SIP is necessary nor desirable.=0A>> =0A>> IMVHO:=0A>> =0A>> 1. There= are other mechanisms available. DHCPv6 is not =0A>> mandatory in the =0A>>= IPv6 node requirements, but neither is SIP. Adding a new RA =0A>> option w= ould =0A>> mean firmware in mobile devices would have to be updated, just a= s they =0A>> would if incorporating a DHCPv6 client, so that's a wash.=0A> = =0A> Med: I have several comments here:=0A> =0A> * The discovery of the SIP= Proxy server is almost critical as the discovery of a =0A> DNS server (RFC= 6106): If no server is discovered no session can be placed. This =0A> may b= e critical for no SIM-based terminals (e.g., placing an emergency call).=0A= > =0A> * With the advent of Mobile VoIP, a solution which ** guarantee ** t= he =0A> provisioning of the SIP Proxy Server is needed. I would argue RA-ba= sed method =0A> would have less impact on terminals=0A> =0A> * This method = can be used for auto configuring SIP terminals with a SIP Proxy =0A> Server= deployed in a homenet context.=0A> =0A> * For Fixed-Mobile Convergence, SI= P-based traffic may also be interesting to =0A> offload (this is similar to= local breakout scenarios for the roaming context): =0A> having a consisten= t method to discover the SIP Proxy in both fixed and mobile =0A> access wou= ld be helpful.=0A> =0A> =0A>> =0A>> 2. An FQDN has an indeterminate length,= although encoding of =0A>> an FQDN in =0A>> RFC1035 limits this to 255 oct= ets, it's still potentially a =0A>> significant =0A>> increase in the lengt= h of RA messages, which is undesirable for many =0A>> reasons (including st= ateless security filtering mechanisms =0A>> like RA-Guard).=0A>> =0A>> 3.Th= ere's no padding specified on the FQDN encoding. AFAIK =0A>> RFC1035 does = =0A>> not specify how to encode an FQDN into 8 octet blocks (required for R= A =0A>> options length calculations).=0A> =0A> Med: You are right, padding = may be needed. We can work out better the =0A> specification once there is = a support to use RA for SIP Proxy Server discovery.=0A> =0A>> =0A>> 4. You = can hardly talk about advantages of using an RA option rather =0A>> than an= alternative unicast mechanism on a point to point bearer link =0A>> (where= no other nodes can listen out for the broadcast/multicast =0A>> informatio= n to save on multiple transmissions). The end node =0A>> still also =0A>> h= as to resolve the FQDN into one or more IPv6 or IPv4 =0A>> addresses via DN= S =0A>> before it can transmit any SIP messages, so it's not exactly a =0A>= > RTT start =0A>> up latency or packet saver either.=0A> =0A> Med: This may= or may not be considered as an issue: the reason is there is =0A> likely a= registration phase before placing a session. Anyway, this issue can be =0A= > solved by changing the encoding of the name into string. Doing so would:= =0A> (1) allow to convey any name (including IP address literals) that can = be passed =0A> to an underlying resolution library=0A> (2) not require to d= efine two formats (one for fqdn and another one for IP =0A> address). One s= ingle option will do the job.=0A> =0A>> =0A>> Or am I missing something?=0A= > =0A> Med: Your questions are valid one. I hope I clarified some of them. = Thanks for =0A> the review.=0A> =0A>> =0A>> regards,=0A>> RayH=0A>> =0A>> m= ohamed.boucadair@orange.com wrote:=0A>>> Dear all,=0A>>> =0A>>> Comments = are more than welcome.=0A>>> =0A>>> Cheers,=0A>>> Med=0A>>> =0A>>> -----= Message d'origine-----=0A>>> De : i-d-announce-bounces@ietf.org =0A>> [mai= lto:i-d-announce-bounces@ietf.org] De la part de =0A>> internet-drafts@ietf= .org=0A>>> Envoy=E9 : jeudi 4 octobre 2012 09:12=0A>>> =C0 : i-d-announce= @ietf.org=0A>>> Objet : I-D Action: draft-boucadair-6man-sip-proxy-01.txt= =0A>>> =0A>>> =0A>>> A New Internet-Draft is available from the on-line = =0A>> Internet-Drafts directories.=0A>>> =0A>>> =0A>>> =A0=A0=A0 Title=A0 = =A0 =A0 =A0 =A0 : IPv6 RA Option for SIP Proxy Server=0A>>> =A0=A0=A0 Aut= hor(s)=A0 =A0 =A0 : Mohamed Boucadair=0A>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 David Binet=0A>>> =A0=A0=A0 Filename=A0 =A0 = =A0 =A0 : draft-boucadair-6man-sip-proxy-01.txt=0A>>> =A0=A0=A0 Pages=A0 = =A0 =A0 =A0 =A0 : 6=0A>>> =A0=A0=A0 Date=A0 =A0 =A0 =A0 =A0 =A0 : 2012-10= -04=0A>>> =0A>>> Abstract:=0A>>> =A0 =A0 This document specifies a new op= tional extension to IPv6 Router=0A>>> =A0 =A0 Advertisement messages to ad= vertise SIP Proxy Server =0A>> (e.g., P-CSCF)=0A>>> =A0 =A0 addresses to I= Pv6 hosts.=0A>>> =0A>>> =A0 =A0 The provisioning of the SIP Proxy Server a= ddress is =0A>> crucial for the=0A>>> =A0 =A0 delivery of SIP-based servic= es.=A0 Means to ensure =0A>> reliable delivery of=0A>>> =A0 =A0 this infor= mation to connecting SIP User Agents is a must.=0A>>> =0A>>> =0A>>> =0A>>> = The IETF datatracker status page for this draft is:=0A>>> https://datatra= cker.ietf.org/doc/draft-boucadair-6man-sip-proxy=0A>>> =0A>>> There's also= a htmlized version available at:=0A>>> http://tools.ietf.org/html/draft-b= oucadair-6man-sip-proxy-01=0A>>> =0A>>> A diff from the previous version i= s available at:=0A>>> http://www.ietf.org/rfcdiff?url2=3Daft-boucadair-6ma= n-sip-proxy-01=0A>>> =0A>>> =0A>>> Internet-Drafts are also available by a= nonymous FTP at:=0A>>> ftp://ftp.ietf.org/internet-drafts/=0A>>> =0A>>> _= ______________________________________________=0A>>> I-D-Announce mailing = list=0A>>> I-D-Announce@ietf.org=0A>>> https://www.ietf.org/mailman/listi= nfo/i-d-announce=0A>>> Internet-Draft directories: http://www.ietf.org/sha= dow.html=0A>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt=0A>>> =0A>> = =0A> --------------------------------------------------------------------= =0A> IETF IPv6 working group mailing list=0A> ipv6@ietf.org=0A> Administrat= ive Requests: https://www.ietf.org/mailman/listinfo/ipv6=0A> --------------= ------------------------------------------------------=0A> From markzzzsmith@yahoo.com.au Fri Oct 12 16:41:45 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C30721F8574 for ; Fri, 12 Oct 2012 16:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQUa6fvIIEmI for ; Fri, 12 Oct 2012 16:41:42 -0700 (PDT) Received: from nm33.bullet.mail.bf1.yahoo.com (nm33.bullet.mail.bf1.yahoo.com [72.30.238.133]) by ietfa.amsl.com (Postfix) with ESMTP id 1177D21F855A for ; Fri, 12 Oct 2012 16:41:41 -0700 (PDT) Received: from [98.139.215.140] by nm33.bullet.mail.bf1.yahoo.com with NNFMP; 12 Oct 2012 23:41:41 -0000 Received: from [98.139.212.222] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 12 Oct 2012 23:41:41 -0000 Received: from [127.0.0.1] by omp1031.mail.bf1.yahoo.com with NNFMP; 12 Oct 2012 23:41:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 501082.75061.bm@omp1031.mail.bf1.yahoo.com Received: (qmail 81399 invoked by uid 60001); 12 Oct 2012 23:41:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1350085300; bh=y4eWkZy7eqGNEd/RqJyHFusW8hk805pEKp7j9LkP3JI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mKoLODlUjDvuJpJS7wktbhZq+eHcNAFZgWz3FuMYkZknxtAG37iaE5D6+pPy11qB9Qvrk/DhaQ9RrzZ5hv5U21FBcbadMtPq24kGMZrhJsttv/4p12b5aiV/GnHbl9KuMYLckJ3t1ROaptgtcQTGpR6sd+uPfCl/92XvX0MPCqY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bPXDW4BwyxXJLKZ7bFL8y0ZVuEo87llh0V/lAw73KOsr0fK6nZOg0wmHi8EWAkcOWMJHa4CvyVyBPmGP8+xJ6QGEbEqR4FqvcKAyPtq798caWLj3aSFePctPwaZdPhF47WtTeNyzRqjfhRoUgha4Zw30chaB/fLOYywwQczhbNk=; X-YMail-OSG: 1.LoagkVM1mH4NEuiE7kfM53S7aFPS3PuFJPO4rEAfh_zNW nstCdPTkZLnZpL885QpxzASN_A2WoQFETnnAM87VJaYq2EWFGeLfr3Isn7OH XtiMvb13N7ThNUJWXgFCXUuNKlCkuPBF6kHn7i_dfsbQHg3gmuYHCIBTxP_0 6xmhufa5MohcbcArpuQXftPtvSmFN0vtnfV0gWIX11eh5JcaYLIoIgytphyP J2.ji37xPdHJCKCvrtX6bjB_gUsl7yDqRHD15_p0PEEpzkcxZGqltfuj6yPX MJXU13TM4ILugSXz1wRSlBphXQUUp3jpl.CzeDqTDc0dZ_22pOfWbb6RjY99 odBGBYzN9TOSbbHBvvsW55Ftlb4XRZyvTNo8GUP6UY9cQSxg49xl_48_GgoV C_NR956UsOvBjSciK5Iqihb8CAcP9kndQQn_1oGQ80bD05N8qEyPsqqQ9RkJ SASriKyi4A9_qON3u7jfOyI6rAlZs_Xo9Wi5dYMfX_QfwuHfc0XaTvqFOquY HuRop07GOdHyG6CkC Received: from [150.101.221.237] by web32501.mail.mud.yahoo.com via HTTP; Fri, 12 Oct 2012 16:41:40 PDT X-Rocket-MIMEInfo: 001.001, SGksCgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo.IEZyb206IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPgo.IFRvOiBTYW1pdGEgQ2hha3JhYmFydGkgPHNhbWl0YS5jaGFrcmFiYXJ0aUBlcmljc3Nvbi5jb20.Cj4gQ2M6IDZtYW4gTWFpbGluZyBMaXN0IDxpcHY2QGlldGYub3JnPgo.IFNlbnQ6IEZyaWRheSwgMTIgT2N0b2JlciAyMDEyIDU6MjMgUE0KPiBTdWJqZWN0OiBSZTogZHJhZnQtY2hha3JhYmFydGktbm9yZG1hcmstNm1hbi1lZmZpY2llbnQtbmQtMDAudHh0Cj4gCj5UIHdvIHEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.450 References: <16D60F43CA0B724F8052D7E9323565D72ECE73F3B4@EUSAACMS0715.eamcs.ericsson.se> <653FE6CB-CBFF-4CF5-967B-3227B5295B46@tzi.org> Message-ID: <1350085300.71992.YahooMailNeo@web32501.mail.mud.yahoo.com> Date: Fri, 12 Oct 2012 16:41:40 -0700 (PDT) From: Mark ZZZ Smith Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd-00.txt To: Carsten Bormann , Samita Chakrabarti In-Reply-To: <653FE6CB-CBFF-4CF5-967B-3227B5295B46@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 23:41:45 -0000 Hi,=0A=0A=0A----- Original Message -----=0A> From: Carsten Bormann =0A> To: Samita Chakrabarti =0A> Cc:= 6man Mailing List =0A> Sent: Friday, 12 October 2012 5:23 P= M=0A> Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd-00.txt=0A> = =0A>T wo quick comments:=0A> =0A=A0=0A=0A> Clearly, mitigating the ex= ternal ND table DoS is one of the major pain points =0A> addressed by this.= =A0 Thinking point: Is there any way to structure the transition =0A> from = legacy ND to efficient ND in such a way that it becomes easier to reap this= =0A> benefit?=0A>=0A=A0=0AI've been thinking about a registration protocol= recently, which would have=0Aleveraged the MLDv2 election process at route= r interface connection =A0to=0Adiscover existing nodes' link local addresse= s, Inverse Neighbor Discovery=0Ato query the nodes' for their other address= es (other LLs, ULAs, GUAs),=0ADAD to detect new nodes/addresses, and NUD to= detect when nodes/addresses=0Adisappear. The drawback as you indirectly po= int out is that it requires=0Aall nodes to support the registration protoco= l before it can be enabled=0Aand the DoS mitigated. So I worked on the foll= owing draft first, which=0AI think mitigates the DoS for routers, and only = requires changes to=0Arouters' neighbor discovery operation:=0A=0A"Mitigati= ng IPv6 Router Neighbor Cache=A0DoS Using Stateless Neighbor Discovery"=0A= =0Ahttp://tools.ietf.org/search/draft-smith-6man-mitigate-nd-cache-dos-slnd= -00=0A=0AI've got a new update nearly finished, which I'll post later today= .=0A=0AI definitely think a registration protocol is necessary. While worki= ng on=0Athe above draft, I realised that on-link sources can also cause the= off-link=0Aneighbor cache DoS, by using spoofed non-existent source addres= ses from=0Awithin the local subnet, and sending that traffic to a remote ho= st that=0Asends replies back (e.g. lots of spoofed source addressed outgoin= g TCP SYNs, reply=0ATCP SYN/ACKs would cause the neighbor cache DoS attack = on the router). A=0Aregistration protocol would allow individual address-ba= sed rather than just prefix level=0ABCP38 protection, because routers now k= now exactly what devices exist=0Aon-link, and can therefore drop traffic wi= th spoofed local subnet source addresses.=0A=0ARegards,=0AMark. From markzzzsmith@yahoo.com.au Fri Oct 12 17:58:00 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECD921F868A for ; Fri, 12 Oct 2012 17:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.836 X-Spam-Level: X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkeO5kqhPwkH for ; Fri, 12 Oct 2012 17:58:00 -0700 (PDT) Received: from nm2-vm0.bullet.mail.sp2.yahoo.com (nm2-vm0.bullet.mail.sp2.yahoo.com [98.139.91.248]) by ietfa.amsl.com (Postfix) with ESMTP id F093021F8682 for <6man@ietf.org>; Fri, 12 Oct 2012 17:57:59 -0700 (PDT) Received: from [98.139.91.69] by nm2.bullet.mail.sp2.yahoo.com with NNFMP; 13 Oct 2012 00:57:53 -0000 Received: from [72.30.22.38] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 13 Oct 2012 00:57:53 -0000 Received: from [127.0.0.1] by omp1068.mail.sp2.yahoo.com with NNFMP; 13 Oct 2012 00:57:53 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 260105.94308.bm@omp1068.mail.sp2.yahoo.com Received: (qmail 51951 invoked by uid 60001); 13 Oct 2012 00:57:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1350089872; bh=Uq+lckJkvZmWtdWQUtASymlh1D83OQXjXnJnq4UqcOw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=W43nzVijr4IJ1r/A+8rZXutD8xUETHCmp59hMpAoMWa4Z/U5OAoxA4CKeoMrwjEyketycwgZYroCeJoYggX0o+DdoD0S5wj1jSbfCtt7C6bFNPTk/CIzEqENmSx3O5e5mgRbMg9/C0x0/agqefUNs0mJNHBaiXkYxIlxwAhkWmo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=CpAEiXQcnoLkYjrjBLbvzkmu2eVoyDFfbqT7veAucZxF/xrEijA7yXoHRgLRpz6DBPKzv5WrbNulBGXky3T6LHmqkwwCRDIvnP2LY59IVN/bRXUe6hReS8RDW/gV0mjMc/XUnAj87ITIxvL3dmC6GZiIKZadALA4uCCnDkvRrOc=; X-YMail-OSG: .a8lETgVM1l._ycLzJxa6mUvu966y0PK5GkcG9.fv0UFgH1 CNB4urzNxevnS.7sa_qnBp5m_fNUYQKpl3HU8j5JkeOspmA8oHBcCvY0HlND Jo.y_QQ0H9kluv4JZCDsQ09U0gQAGuHMjW081ckhJGgVWH2rUET5DWOilxAY Jusic_1hiO1cJPq9bfhMXUdY5h_guF_2k.9meadj4wS3_7QKzHoVswVtMZqF cl5XIesIoGoB0pf49uF_VI4y2Fcgj9Znpb9kn5XDyIPqGAVTBf6TMXSutCC0 4lRWyYYJ1ngkCsavsV8vFPyyx.8skyoEW7DfZMsVbceiUf3x.nI3Ggpfgbm9 JItmM1dRsNx_zyg5F.BLaxFO1z06Q1sAJ4hmbZQuVSk.cxbYcP7GEdLZB7EB hD2eI3BSqfNEiLHpa24FHfQhOBP23IOYEIcCoPlNxk14B0gfqTx54jUfKR0x yNz9dsqlLtymj303BGTr_hIUX5cJlwP6lruVz0Omboo2fk4N9YJqQh6Y.WZL So_tH52NjXqBq Received: from [150.101.221.237] by web32502.mail.mud.yahoo.com via HTTP; Fri, 12 Oct 2012 17:57:52 PDT X-Rocket-MIMEInfo: 001.001, SGksCgpIZXJlJ3MgYSBuZXcgdmVyc2lvbiBvZiBteSBzdGF0ZWxlc3MgbmVpZ2hib3IgZGlzY292ZXJ5IGRyYWZ0LiBDaGFuZ2VzOgoKLSBtYWtlIGl0IG1vcmUgb2J2aW91cyB0aGF0IGhvc3RzIGRvbid0IG5lZWQgdG8gYmUgY2hhbmdlZAotIG1vcmUgaW5mb3JtYXRpdmUgaW50cm9kdWN0aW9uL3Byb2JsZW0gZGVmaW5pdGlvbiB0ZXh0Ci0gYWxsb3cgbG93IGVuZC9lbWJlZGRlZCBwbGF0Zm9ybXMgdG8gY29uc2lkZXIgYWxsIHRyYWZmaWMgc291cmNlcyB1bnRydXN0ZWQgaWYgYSBEb1MgYXR0YWNrIGlzIG8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.450 References: <20121013004926.30959.4900.idtracker@ietfa.amsl.com> Message-ID: <1350089872.31077.YahooMailNeo@web32502.mail.mud.yahoo.com> Date: Fri, 12 Oct 2012 17:57:52 -0700 (PDT) From: Mark ZZZ Smith Subject: Fw: New Version Notification for draft-smith-6man-mitigate-nd-cache-dos-slnd-01.txt To: "6man@ietf.org" <6man@ietf.org> In-Reply-To: <20121013004926.30959.4900.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 12 Oct 2012 18:04:46 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 00:58:00 -0000 Hi,=0A=0AHere's a new version of my stateless neighbor discovery draft. Cha= nges:=0A=0A- make it more obvious that hosts don't need to be changed=0A- m= ore informative introduction/problem definition text=0A- allow low end/embe= dded platforms to consider all traffic sources untrusted if a DoS attack is= occurring=0A- misc. text re-wordings and changes=0A=0AThanks to Ray Hunter= and Matthew Moyle-Croft for their reviews and comments.=0A=0AComments most= appreciated.=0A=0AThanks,=0AMark.=0A=0A=0A=0A----- Forwarded Message -----= =0A> From: "internet-drafts@ietf.org" =0A> To: ma= rkzzzsmith@yahoo.com.au=0A> Cc: =0A> Sent: Saturday, 13 October 2012 11:49 = AM=0A> Subject: New Version Notification for draft-smith-6man-mitigate-nd-c= ache-dos-slnd-01.txt=0A> =0A> =0A> A new version of I-D, draft-smith-6man-m= itigate-nd-cache-dos-slnd-01.txt=0A> has been successfully submitted by Mar= k Smith and posted to the=0A> IETF repository.=0A> =0A> Filename:=A0=A0=A0 = draft-smith-6man-mitigate-nd-cache-dos-slnd=0A> Revision:=A0=A0=A0 01=0A>= Title:=A0=A0=A0 =A0=A0=A0 Mitigating IPv6 Router Neighbor Cache DoS Using= Stateless =0A> Neighbor Discovery=0A> Creation date:=A0=A0=A0 2012-10-13= =0A> WG ID:=A0=A0=A0 =A0=A0=A0 Individual Submission=0A> Number of pages: = 11=0A> URL:=A0 =A0 =A0 =A0 =A0 =A0 =0A> http://www.ietf.org/internet-drafts= /draft-smith-6man-mitigate-nd-cache-dos-slnd-01.txt=0A> Status:=A0 =A0 =A0 = =A0 =A0 =0A> http://datatracker.ietf.org/doc/draft-smith-6man-mitigate-nd-c= ache-dos-slnd=0A> Htmlized:=A0 =A0 =A0 =A0 =0A> http://tools.ietf.org/html/= draft-smith-6man-mitigate-nd-cache-dos-slnd-01=0A> Diff:=A0 =A0 =A0 =A0 =A0= =A0 =0A> http://www.ietf.org/rfcdiff?url2=3Ddraft-smith-6man-mitigate-nd-c= ache-dos-slnd-01=0A> =0A> Abstract:=0A> =A0 The IPv6 neighbor discovery ca= che is vulnerable to a Denial of=0A> =A0 Service attack that purposely exh= austs the state used during the=0A> =A0 neighbor discovery address resolut= ion process.=A0 This attack can be=0A> =A0 very disruptive when the target= is a router.=A0 This memo proposes a=0A> =A0 stateless form of neighbor d= iscovery to be used by routers to=0A> =A0 mitigate this attack.=A0 It does= not require any changes to hosts.=0A> =0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =0A> =A0 =0A> =0A> = =0A> The IETF Secretariat=0A> From kauer@biplane.com.au Fri Oct 12 18:25:21 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE39821F86BD for ; Fri, 12 Oct 2012 18:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaBiby0OMLZ9 for ; Fri, 12 Oct 2012 18:25:20 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 73B2B21F86B9 for ; Fri, 12 Oct 2012 18:25:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAOvBeFCWZX+7/2dsb2JhbAANOIYSvQUBAQEEI1QSCxgCAiYCAlcZsAFuklKBIYpGgweCD4ESA6ETiAuBRw Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.200]) ([150.101.127.187]) by ipmail06.adl6.internode.on.net with ESMTP; 13 Oct 2012 11:55:17 +1030 Message-ID: <1350091515.2856.37.camel@karl> Subject: Re: Fw: New Version Notification for draft-smith-6man-mitigate-nd-cache-dos-slnd-01.txt From: Karl Auer To: ipv6@ietf.org Date: Sat, 13 Oct 2012 12:25:15 +1100 In-Reply-To: <1350089872.31077.YahooMailNeo@web32502.mail.mud.yahoo.com> References: <20121013004926.30959.4900.idtracker@ietfa.amsl.com> <1350089872.31077.YahooMailNeo@web32502.mail.mud.yahoo.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 01:25:22 -0000 On Fri, 2012-10-12 at 17:57 -0700, Mark ZZZ Smith wrote: > Here's a new version of my stateless neighbor discovery draft. Changes: This para seems a little harder to understand than it should be: "A default route should never be used to define a trusted packet source prefix. If a router's operator wishes to trust all packet sources, they should specify ::/0 as a configured trusted prefix." It seems to be saying "never use a default route to define a trusted packet source prefix. If a router's operator wishes to trust all packet sources, they should use a default route"! Because there are no ND cache entries for a packet except at the last router in its journey, there is no way to delegate the problem upstream. It would be nice if, once a router had decided to start rate limiting NS from a prefix, it could pass that info upstream to have the upstream router rate limit it instead (or as well). I appreciate that your mechanism is not designed to do this, but I thought I'd mention it. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 From mohamed.boucadair@orange.com Sun Oct 14 23:37:59 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B5821F8605 for ; Sun, 14 Oct 2012 23:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZCcoyLCHBFg for ; Sun, 14 Oct 2012 23:37:58 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id D7CCC21F844B for <6man@ietf.org>; Sun, 14 Oct 2012 23:37:53 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 6AF8C324131; Mon, 15 Oct 2012 08:37:52 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 4155135C045; Mon, 15 Oct 2012 08:37:52 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Mon, 15 Oct 2012 08:37:49 +0200 From: To: Mark ZZZ Smith , Ray Hunter Date: Mon, 15 Oct 2012 08:37:48 +0200 Subject: RE: draft-boucadair-6man-sip-proxy-01 Thread-Topic: draft-boucadair-6man-sip-proxy-01 Thread-Index: Ac2oz5qK5dVotZYpSVKblh3sSSIZYABzDRbQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E63206636@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E5F75BA9B@PUEXCB1B.nanterre.francetelecom.fr> <506F38A5.9090407@globis.net> <94C682931C08B048B7A8645303FDC9F36E63206263@PUEXCB1B.nanterre.francetelecom.fr> <1350083784.71918.YahooMailNeo@web32508.mail.mud.yahoo.com> In-Reply-To: <1350083784.71918.YahooMailNeo@web32508.mail.mud.yahoo.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.15.54224 X-Mailman-Approved-At: Sun, 14 Oct 2012 23:45:32 -0700 Cc: "6man@ietf.org" <6man@ietf.org>, BINET David OLNC/OLN X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 06:37:59 -0000 Dear Mark, Thanks for the comments.=20 Please see inline. Cheers, Med=20 >-----Message d'origine----- >De : Mark ZZZ Smith [mailto:markzzzsmith@yahoo.com.au]=20 >Envoy=E9 : samedi 13 octobre 2012 01:16 >=C0 : BOUCADAIR Mohamed OLNC/OLN; Ray Hunter >Cc : 6man@ietf.org; BINET David OLNC/OLN >Objet : Re: draft-boucadair-6man-sip-proxy-01 > >Hi, > >I agree with Ray, I think this is fundamentally just=20 >re-inventing the wheel. Med: Yes, this is only a way to provision a node with another yet channel. = No magic there. The question is: are we confident existing tools are suffic= ient to ensure access to the Internet service in a consistent and homogenou= s manner whatever the attachment network used by a host? BTW, I'm using the= Internet service in a wider definition as defined in RFC1287 (http://tools= .ietf.org/rfc/rfc1287.txt): "The Internet should be extended to support "re= al-time" applications like voice and video. " > >I notice that one of the justifications for this is that "DHCPv6 is not >required in all 3GPP releases." Why isn't it? Med: Because there is another channel which is supposed to provide such inf= ormation during PDP Context. This assumption becomes obsolete when you atta= ch to a non 3-GPP network. Based on this statement, >it seems to me that the 3GPP architecture doesn't recognise that there >isn't really anything special about (smart)phones - they're=20 >just portable, >single or multi-homed hosts with one or more wireless interfaces, and >therefore should use standard and existing IPv6 mechanisms. Med: That's the point. Is there are a guarantee that based on host capabili= ties and diverse network attachment types, access to the telephony service = will be preserved? =20 >Making phone >calls on them is just an application running on the host. Med: The only issue is that unlike other Internet applications, provisionin= g the DNS is not sufficient to work: the information about the proxy server= is required.=20 > >Support for DHCPv6 is a SHOULD for hosts that support more than one >specialised application:=20 >http://tools.ietf.org/html/rfc6434#section-7.2.1 Med: SHOULD is not a MUST. =20 > >I think putting options like this and DNS (and of course, down the >track, most other DHCPv6 options) in RAs is a violation of the Internet >architecture. Med: I disagree: * There are already examples of protocols violating that model: TCP. (I agr= ee this is not a reason to do it with another protocol.) * IPv5 (ST) focuses exclusively on real-time services=20 * RFC1287 clearly extends the Internet model to real-time services.=20 The Internet is meant to be application transparent, Med: I would love to; but IP connectivity is heavily dependent of rendezvou= s services (in all its forms: DNS, SIP registration, etc.) >and I think this is it's greatest strength and advantage=20 >compared to the previous >application-specific networks such as the PSTN. Med: See my comment above. It shouldn't=20 >be necessary >to upgrade the software/firmware in a router to be able to run a new >application residing on the hosts, yet this is what=20 >applications/services >configuration options in RAs would require. Med: I'm not asking to include all application-related configuration in RA = but only the mandatory rendezvous services for Internet service to be corre= ctly be invoked and delivered:=20 * DNS is already supported (RFC6106) * This I-D is claiming SIP-based configuration should also be part of this = package. > >So I think the Internet needs to be kept both services/application >transparent as well as service/application configuration method >transparent. RAs should be left to just configuring the=20 >network layer/IP >parameters, and an "over-the-top" protocol, stateless DHCPv6, used to >configure hosts' service and applications. Routers operating as >DCHPv6 relays fit within this model because they're (new) DHCPv6 option >transparent. > >Regards, >Mark. > > > >----- Original Message ----- >> From: "mohamed.boucadair@orange.com" >> To: Ray Hunter >> Cc: "6man@ietf.org" <6man@ietf.org>; BINET David OLNC/OLN=20 > >> Sent: Friday, 12 October 2012 8:00 PM >> Subject: RE: draft-boucadair-6man-sip-proxy-01 >>=20 >> Dear Ray,=20 >>=20 >> Thank you for the comments.=20 >>=20 >> Please see inline.=20 >>=20 >> Cheers, >> Med >>=20 >>> -----Message d'origine----- >>> De : Ray Hunter [mailto:v6ops@globis.net]=20 >>> Envoy=E9 : vendredi 5 octobre 2012 21:45 >>> =C0 : BOUCADAIR Mohamed OLNC/OLN >>> Cc : 6man@ietf.org >>> Objet : Re: draft-boucadair-6man-sip-proxy-01 >>>=20 >>> I have read this draft and do not support it as-is. >>>=20 >>> I do not agree with the conclusion that extending RA with a=20 >new option=20 >>> for SIP is necessary nor desirable. >>>=20 >>> IMVHO: >>>=20 >>> 1. There are other mechanisms available. DHCPv6 is not=20 >>> mandatory in the=20 >>> IPv6 node requirements, but neither is SIP. Adding a new RA=20 >>> option would=20 >>> mean firmware in mobile devices would have to be updated,=20 >just as they=20 >>> would if incorporating a DHCPv6 client, so that's a wash. >>=20 >> Med: I have several comments here: >>=20 >> * The discovery of the SIP Proxy server is almost critical=20 >as the discovery of a=20 >> DNS server (RFC6106): If no server is discovered no session=20 >can be placed. This=20 >> may be critical for no SIM-based terminals (e.g., placing an=20 >emergency call). >>=20 >> * With the advent of Mobile VoIP, a solution which **=20 >guarantee ** the=20 >> provisioning of the SIP Proxy Server is needed. I would=20 >argue RA-based method=20 >> would have less impact on terminals >>=20 >> * This method can be used for auto configuring SIP terminals=20 >with a SIP Proxy=20 >> Server deployed in a homenet context. >>=20 >> * For Fixed-Mobile Convergence, SIP-based traffic may also=20 >be interesting to=20 >> offload (this is similar to local breakout scenarios for the=20 >roaming context):=20 >> having a consistent method to discover the SIP Proxy in both=20 >fixed and mobile=20 >> access would be helpful. >>=20 >>=20 >>>=20 >>> 2. An FQDN has an indeterminate length, although encoding of=20 >>> an FQDN in=20 >>> RFC1035 limits this to 255 octets, it's still potentially a=20 >>> significant=20 >>> increase in the length of RA messages, which is undesirable=20 >for many=20 >>> reasons (including stateless security filtering mechanisms=20 >>> like RA-Guard). >>>=20 >>> 3.There's no padding specified on the FQDN encoding. AFAIK=20 >>> RFC1035 does=20 >>> not specify how to encode an FQDN into 8 octet blocks=20 >(required for RA=20 >>> options length calculations). >>=20 >> Med: You are right, padding may be needed. We can work out=20 >better the=20 >> specification once there is a support to use RA for SIP=20 >Proxy Server discovery. >>=20 >>>=20 >>> 4. You can hardly talk about advantages of using an RA=20 >option rather=20 >>> than an alternative unicast mechanism on a point to point=20 >bearer link=20 >>> (where no other nodes can listen out for the broadcast/multicast=20 >>> information to save on multiple transmissions). The end node=20 >>> still also=20 >>> has to resolve the FQDN into one or more IPv6 or IPv4=20 >>> addresses via DNS=20 >>> before it can transmit any SIP messages, so it's not exactly a=20 >>> RTT start=20 >>> up latency or packet saver either. >>=20 >> Med: This may or may not be considered as an issue: the=20 >reason is there is=20 >> likely a registration phase before placing a session.=20 >Anyway, this issue can be=20 >> solved by changing the encoding of the name into string.=20 >Doing so would: >> (1) allow to convey any name (including IP address literals)=20 >that can be passed=20 >> to an underlying resolution library >> (2) not require to define two formats (one for fqdn and=20 >another one for IP=20 >> address). One single option will do the job. >>=20 >>>=20 >>> Or am I missing something? >>=20 >> Med: Your questions are valid one. I hope I clarified some=20 >of them. Thanks for=20 >> the review. >>=20 >>>=20 >>> regards, >>> RayH >>>=20 >>> mohamed.boucadair@orange.com wrote: >>>> Dear all, >>>>=20 >>>> Comments are more than welcome. >>>>=20 >>>> Cheers, >>>> Med >>>>=20 >>>> -----Message d'origine----- >>>> De : i-d-announce-bounces@ietf.org=20 >>> [mailto:i-d-announce-bounces@ietf.org] De la part de=20 >>> internet-drafts@ietf.org >>>> Envoy=E9 : jeudi 4 octobre 2012 09:12 >>>> =C0 : i-d-announce@ietf.org >>>> Objet : I-D Action: draft-boucadair-6man-sip-proxy-01.txt >>>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line=20 >>> Internet-Drafts directories. >>>>=20 >>>>=20 >>>> =A0=A0=A0 Title=A0 =A0 =A0 =A0 =A0 : IPv6 RA Option for SIP Proxy Se= rver >>>> =A0=A0=A0 Author(s)=A0 =A0 =A0 : Mohamed Boucadair >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 David Binet >>>> =A0=A0=A0 Filename=A0 =A0 =A0 =A0 : draft-boucadair-6man-sip-proxy-01= .txt >>>> =A0=A0=A0 Pages=A0 =A0 =A0 =A0 =A0 : 6 >>>> =A0=A0=A0 Date=A0 =A0 =A0 =A0 =A0 =A0 : 2012-10-04 >>>>=20 >>>> Abstract: >>>> =A0 =A0 This document specifies a new optional extension to=20 >IPv6 Router >>>> =A0 =A0 Advertisement messages to advertise SIP Proxy Server=20 >>> (e.g., P-CSCF) >>>> =A0 =A0 addresses to IPv6 hosts. >>>>=20 >>>> =A0 =A0 The provisioning of the SIP Proxy Server address is=20 >>> crucial for the >>>> =A0 =A0 delivery of SIP-based services.=A0 Means to ensure=20 >>> reliable delivery of >>>> =A0 =A0 this information to connecting SIP User Agents is a must. >>>>=20 >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-boucadair-6man-sip-proxy >>>>=20 >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-boucadair-6man-sip-proxy-01 >>>>=20 >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=3Daft-boucadair-6man-sip-proxy-01 >>>>=20 >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>=20 >>>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >= From mohamed.boucadair@orange.com Sun Oct 14 23:45:43 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2242F21F85B4 for ; Sun, 14 Oct 2012 23:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ne9DKsqmmE-3 for ; Sun, 14 Oct 2012 23:45:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9167521F85A4 for ; Sun, 14 Oct 2012 23:45:42 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id DAA443B407D; Mon, 15 Oct 2012 08:45:41 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id BFBBD27C058; Mon, 15 Oct 2012 08:45:41 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Mon, 15 Oct 2012 08:45:38 +0200 From: To: RJ Atkinson , "ipv6@ietf.org" Date: Mon, 15 Oct 2012 08:45:36 +0200 Subject: RE: draft-boucadair-6man-sip-proxy-01 Thread-Topic: draft-boucadair-6man-sip-proxy-01 Thread-Index: Ac2orNRhRGGMWe+dRTGztYk2N1pvbwB8yIBA Message-ID: <94C682931C08B048B7A8645303FDC9F36E6320663C@PUEXCB1B.nanterre.francetelecom.fr> References: <07099AAD-5C12-48FC-B6A9-F3A2332AB5E5@gmail.com> In-Reply-To: <07099AAD-5C12-48FC-B6A9-F3A2332AB5E5@gmail.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.15.54224 Cc: BINET David OLNC/OLN X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 06:45:43 -0000 Dear Ran, Thank you for sharing your point of view.=20 The points raised by Ray Hunter are good ones. I tried to provided further = explanation here: http://www.ietf.org/mail-archive/web/ipv6/current/msg1643= 5.html. I hope that answer solves some of your concerns. Cheers, Med=20 >-----Message d'origine----- >De : ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] De=20 >la part de RJ Atkinson >Envoy=E9 : vendredi 12 octobre 2012 21:07 >=C0 : ipv6@ietf.org >Objet : Re: draft-boucadair-6man-sip-proxy-01 > > > >I agree with Ray Hunter's analysis of this proposal, >as posted on the IPv6 list (available at the URL above). > >Ran > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- >= From oliver@8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa Mon Oct 15 07:10:10 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1862A11E808A for ; Mon, 15 Oct 2012 07:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.56 X-Spam-Level: X-Spam-Status: No, score=-0.56 tagged_above=-999 required=5 tests=[AWL=2.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oggrPiBXNHAx for ; Mon, 15 Oct 2012 07:10:08 -0700 (PDT) Received: from mail.uptheinter.net (mail.uptheinter.net [IPv6:2001:470:9738::]) by ietfa.amsl.com (Postfix) with ESMTP id 9257011E8099 for ; Mon, 15 Oct 2012 07:10:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.uptheinter.net (Postfix) with ESMTP id AB752A55C4 for ; Mon, 15 Oct 2012 15:09:55 +0100 (BST) X-DKIM: Sendmail DKIM Filter v2.7.2 mail.uptheinter.net AB752A55C4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa; s=default; t=1350310195; bh=9Id 5RpTK/x+T75dt6S+V+b9+bhkN/SNz30J97vONNOg=; h=From:To:Subject:Date: Message-ID:In-Reply-To:References:MIME-Version: Content-Transfer-Encoding:Content-Type; b=Ndwwmxjq221mL6pY6WxNrG5o aVvpkg2SILLgONWGc+wbvouRlasj3BIvhD2lBPUEiR4Uh1UL3lFfoxdRnNfVRplUjHL lUZPbpsjp/H/FFyoDSp8EZQ9JH0s2tJ+xiRw1D83QxYK/1lx5zTOOeWZdESjbF4brX6 oX3PgG+FKIIIo= X-Virus-Scanned: amavisd-new at Received: from mail.uptheinter.net ([127.0.0.1]) by localhost (vps2.uptheinter.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fFDjVHe2RxaV for ; Mon, 15 Oct 2012 15:09:50 +0100 (BST) From: Oliver To: ipv6@ietf.org Subject: Re: Fw: New Version Notification for draft-smith-6man-mitigate-nd-cache-dos-slnd-01.txt Date: Mon, 15 Oct 2012 15:44:28 +0200 Message-ID: <3078632.Ade1popzkY@gentoovm> User-Agent: KMail/4.8.5 (Linux/3.4.11-4-zerolag-rt19+; KDE/4.8.5; x86_64; ; ) In-Reply-To: <1350089872.31077.YahooMailNeo@web32502.mail.mud.yahoo.com> References: <20121013004926.30959.4900.idtracker@ietfa.amsl.com> <1350089872.31077.YahooMailNeo@web32502.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 14:12:48 -0000 On Friday 12 October 2012 17:57:52 Mark ZZZ Smith wrote: > Hi, > > Here's a new version of my stateless neighbor discovery draft. Changes: > > - make it more obvious that hosts don't need to be changed > - more informative introduction/problem definition text > - allow low end/embedded platforms to consider all traffic sources untrusted > if a DoS attack is occurring - misc. text re-wordings and changes > > Thanks to Ray Hunter and Matthew Moyle-Croft for their reviews and comments. > > Comments most appreciated. > > Thanks, > Mark. Hi, Overall I like the principle of the implementation but I would also say there are a few issues that should be addressed: 1) TUSP should be defineable on an address/interface/packet marking basis; I would say that the exact method of determining a trusted/untrusted querier should (will) ultimately be down to the implementation and as such, this should exist as a recommendation - perhaps call it a "TUD List" instead (Trusted/Untrusted Discriminator) with implementation of a TUD mandatory. 2) While SLND is active, a packet that requires a solicitation MAY be dropped outright but can optionally be requeued/buffered etc - queue discipline should be considered beyond the scope of this document. I am also pondering the possibility of securing the on-link side by way of ND cookies (with a prerequiste being that the subnet size is at least /64) Essentially, while using SLND, a node would generate a neighbour solicitation for unknown on-link hosts using an algorithmically calculated source address resulting from a hash operation over a node-unique seed, the target address contained within the advertisement and the IPv6 header destination address. Thus when receiving a neighbor advertisement, the node can simply hash the data in order to verify if the advertisement is spurious or not. The node must not bind to nor answer solicitatation for these calculated addresses. This will ensure that in the event of a duplicate address, ND for the duplicate would not result in a false discovery. This does come with the downside that a solicited host will most likely attempt discovery of the algorithmically calculated source address - however, I would argue that the cost of this extra noise is outweighed by the benefit of ensuring non-spurious advertisements. Kind Regards, Oliver From markzzzsmith@yahoo.com.au Mon Oct 15 12:30:59 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B0D21F897C for ; Mon, 15 Oct 2012 12:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wN13o+whelJt for ; Mon, 15 Oct 2012 12:30:59 -0700 (PDT) Received: from nm22-vm0.bullet.mail.ac4.yahoo.com (nm22-vm0.bullet.mail.ac4.yahoo.com [98.139.53.218]) by ietfa.amsl.com (Postfix) with ESMTP id C355121F893D for ; Mon, 15 Oct 2012 12:30:58 -0700 (PDT) Received: from [98.139.52.194] by nm22.bullet.mail.ac4.yahoo.com with NNFMP; 15 Oct 2012 19:30:55 -0000 Received: from [98.139.52.156] by tm7.bullet.mail.ac4.yahoo.com with NNFMP; 15 Oct 2012 19:30:55 -0000 Received: from [127.0.0.1] by omp1039.mail.ac4.yahoo.com with NNFMP; 15 Oct 2012 19:30:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 785620.80717.bm@omp1039.mail.ac4.yahoo.com Received: (qmail 45136 invoked by uid 60001); 15 Oct 2012 19:30:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1350329425; bh=uCYQm+Tu8TrQfbpvS3VoRC4raXugHGAyD3BPB0hSI30=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0rF9j5xC34enJniVaLr8TeLFOjwHPS6YdRidMLFgQE6N9RashltuEjgz2NWR5x+mC7nUlE5eq4AHjLKPKV2UtrABZWYAnXGdLABVETPMjRWB+39PWUcpkVOrUTLtv61b1I6N+HqpcmlF6g8FlNkvzrTRLgr9QCxfMy/SN7qkmgk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=USZ53SQySsWSjN8lVmNmpTZVu2R5dj1BA141Km5cVZz3VRUtFiMaRodshEZdF3HLnjZgqnqPRrcQgHlHefUz7k8fYmeaAyTAERVAP+cm2zDTdjXvZVHXglCrgqbJ0dNRjMfrBnK3t0f3ARE/N0ng4CkiaOwdiRv8SaZTnZCvXhY=; X-YMail-OSG: mA4lXt0VM1kF_HvmStzK5mIBVSWggzbzuMCYOQQAW4xviy9 PuzrKHyBpdLP7fFROGNT7Qey5Ksm61D5g2XGo3mkmWGghTF8ndARMkKJnlmt ovaOjntkJ5XE2yHIB7g6G5k1fgydAsbthX_Y92LMV7V7MjxGEdrS6_RaoiH. gXqBs81oW7XRZbrANVQokycsNruhF6hRSTHnAQhd.fIIRuNNZqg3B_48MDGp NiZbTSzpo86tfSBTEa0EZMeOzu0j0kKch9nDbiFVt7NlDLCtFwxKFiemYL3W 2nXYH3s8oG1ZgD.QXkT_euW2r2bs4Xx_UY1sDNzVNUkWA5SelmBb82RrCLOv TT9bKl0fOnQmf5w.0F7jJkKcS.w1txBliIXdyflUAculPCG3Hus0Zb8Dj.fU qGq7DVDab8cSJ1lyOZ2ta1ndIMKigUMcczS4eRLlTgqiPhpmzyVbY2UcsyAs 8pWr3RdE11XHIcmppUoOwZESQ9kAUJR9wBf1QXTQIDdwSlfK6w9xms_kNMWv n.9e2J.KV Received: from [150.101.221.237] by web32501.mail.mud.yahoo.com via HTTP; Mon, 15 Oct 2012 12:30:25 PDT X-Rocket-MIMEInfo: 001.001, SGkgS2FybCzCoAoKVGhhbmtzIHZlcnkgbXVjaCBmb3IgeW91ciBmZWVkYmFjay4KCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBLYXJsIEF1ZXIgPGthdWVyQGJpcGxhbmUuY29tLmF1Pgo.IFRvOiBpcHY2QGlldGYub3JnCj4gQ2M6IAo.IFNlbnQ6IFNhdHVyZGF5LCAxMyBPY3RvYmVyIDIwMTIgMTI6MjUgUE0KPiBTdWJqZWN0OiBSZTogRnc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc21pdGgtNm1hbi1taXRpZ2F0ZS1uZC1jYWNoZS1kb3Mtc2xuZC0wMS50eHQKPiABMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.450 References: <20121013004926.30959.4900.idtracker@ietfa.amsl.com> <1350089872.31077.YahooMailNeo@web32502.mail.mud.yahoo.com> <1350091515.2856.37.camel@karl> Message-ID: <1350329425.36767.YahooMailNeo@web32501.mail.mud.yahoo.com> Date: Mon, 15 Oct 2012 12:30:25 -0700 (PDT) From: Mark Smith Subject: Re: Fw: New Version Notification for draft-smith-6man-mitigate-nd-cache-dos-slnd-01.txt To: Karl Auer , "ipv6@ietf.org" In-Reply-To: <1350091515.2856.37.camel@karl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 19:31:00 -0000 Hi Karl,=A0=0A=0AThanks very much for your feedback.=0A=0A----- Original Me= ssage -----=0A> From: Karl Auer =0A> To: ipv6@ietf.or= g=0A> Cc: =0A> Sent: Saturday, 13 October 2012 12:25 PM=0A> Subject: Re: Fw= : New Version Notification for draft-smith-6man-mitigate-nd-cache-dos-slnd-= 01.txt=0A> =0A> On Fri, 2012-10-12 at 17:57 -0700, Mark ZZZ Smith wrote:=0A= >> Here's a new version of my stateless neighbor discovery draft. Changes:= =0A> =0A> This para seems a little harder to understand than it should be:= =0A> =0A> =A0 "A default route should never be used to define a trusted=0A= > =A0 =A0 packet source prefix.=A0 If a router's operator wishes to=0A> =A0= =A0 trust all packet sources, they should specify ::/0 as a=0A> =A0 =A0 co= nfigured trusted prefix."=0A> =0A> It seems to be saying "never use a defau= lt route to define a trusted=0A> packet source prefix. If a router's operat= or wishes to trust all packet=0A> sources, they should use a default route"= !=0A>=A0=0A=0AI can see how that could be misinterpreted, although ::/0 is = really only=0A=0Athe default when it is used as routing information. I'll t= ry to reword=0Athis text to make it a bit clearer that ::/0 is intended to = be an "all=0AIPv6 addresses" prefix added to the configured source prefix l= ist if all=0Asources are to be trusted.=0A=0A=0A> Because there are no ND c= ache entries for a packet except at the last=0A> router in its journey, the= re is no way to delegate the problem upstream.=0A> It would be nice if, onc= e a router had decided to start rate limiting NS=0A> from a prefix, it coul= d pass that info upstream to have the upstream=0A> router rate limit it ins= tead (or as well). I appreciate that your=0A> mechanism is not designed to = do this, but I thought I'd mention it.=0A>=A0=0A=0A=0AI like the idea of th= at, although the hard part is how to avoid creating=0Aper destination addre= ss, or per source address or source prefix state=0Ato do it, in either the = router that is the target of the DoS, or the=0Aupstream router(s) (e.g. per= -source address backhole routes). It seems=0Ato me that any state that is c= reated that is created to store or created=0Arelated to IPv6 addresses is w= here address related DoS opportunities are=0Acreated. I've though about thi= s idea a little bit for the last few days,=0Aand can't see how you wouldn't= create further address related state that=0Acould be DoS exploited in eith= er the device that is the target of the DoS,=0Aor the upstream device.=0A= =0AOne perspective on my proposal might be that it is in effect pushing mos= t=0A=0Aof the functions that ND performs that use state back onto hosts tha= t=0Aoriginate the traffic in the first place, which results in that state= =0Abeing distributed across those hosts, rather than being concentrated on= =0Athe directly attached router.=0A=0ARegards,=0AMark. From markzzzsmith@yahoo.com.au Mon Oct 15 13:31:18 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0858821F89A1 for ; Mon, 15 Oct 2012 13:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioxzB6yBllPZ for ; Mon, 15 Oct 2012 13:31:17 -0700 (PDT) Received: from nm10.bullet.mail.sp2.yahoo.com (nm10.bullet.mail.sp2.yahoo.com [98.139.91.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4C93221F899C for ; Mon, 15 Oct 2012 13:31:17 -0700 (PDT) Received: from [98.139.91.70] by nm10.bullet.mail.sp2.yahoo.com with NNFMP; 15 Oct 2012 20:31:11 -0000 Received: from [98.139.91.8] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 15 Oct 2012 20:31:11 -0000 Received: from [127.0.0.1] by omp1008.mail.sp2.yahoo.com with NNFMP; 15 Oct 2012 20:31:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 838411.36924.bm@omp1008.mail.sp2.yahoo.com Received: (qmail 9894 invoked by uid 60001); 15 Oct 2012 20:31:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1350333071; bh=nHTaTX6sVcPvYcKJTuVW+OMtTm3zo6hLptuNT7Mgzy4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=p2GTKuyUhUgow3G2KwITaLyCAC+imFJ9/03kdUNIqKgKgxNj2DEcbUjLhS/RSACldlh4JFYfN9SOPkUppVgVB8qgdOrT+S1LnvOCuUvxZWGX3w+VPhrr1WbOd5hR2yWKp28foZJv6KQRRmy5f2fIal1BipgfAjB6zlDdU/6/OIg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=THJwbiQdZzpj2tiWD7Hdc83VcooHnkw0hu2oEKvFtXpt04ps3Z2lHH47KRLnKMqVJ7/mgI7LozsgKo/yvrHVhp0WVsg1g+sG3p/XbBbTOzH3zEZNUihkILokGUQo50PhTpU8cJUHlUzCblYqB7Cdv5K1bNvZNC+7IOY2SY5dkqA=; X-YMail-OSG: Tp15BCwVM1k.Lr8RcOXrfav8Z7c4HYnNTsOz632EJCuZSND foRiaOQPcwpUnbJSDBkmrthbowd_KBkcXJCOrXdy.nJdNIN4wGtKK6lrTKl1 x8fSwLjH0ArJ5zJmuOGWpHO6gGiOMzhfBtVSuvExQ_XYcpl7iiPjGaiwinmK aIHVIIYB_YyFOHNkmsoZ3DjVnxSiNGRH87IWDCQvc_ozLtVhBRD2FLpRPbZU MF_wogJjWI3WKIBgC2Eh3qKfCmscl7cIzq5oVa.AFaTgp8YjvPLS3SypGoP1 YL1tQvO1_MigA3Lr._2F72XeKT25nILOjC6U1W2HgelUYpi6l5csONr5w2dc BhOJpY7IEvIj..oJZSFbT35wlsNL7tmaC57urQJJ4uxUbZJK_j6gde3Q3us9 GOj83kgoPFUoLZageaXz_RBklAvQNvs1zUSpgTsEKQupnUaY2e00KAYK51vK eXZqCMLiGvrxqF7yyyJtGTsDwF1_W0cDh61B72_CZrjA3BUgIyxGpK3VTrkY 1JLP3C_oEjaWOhlz6sFa0URWj5BFC1A-- Received: from [150.101.221.237] by web32507.mail.mud.yahoo.com via HTTP; Mon, 15 Oct 2012 13:31:10 PDT X-Rocket-MIMEInfo: 001.001, SGkgT2xpdmVyLAoKVGhhbmtzIHZlcnkgbXVjaCBmb3IgeW91ciBmZWVkYmFjay4KCgotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4gRnJvbTogT2xpdmVyIDxvbGl2ZXJAOC5jLjkuYi4wLjcuNC4wLjEuMC4wLjIuaXA2LmFycGE.Cj4gVG86IGlwdjZAaWV0Zi5vcmcKPiBDYzogCj4gU2VudDogVHVlc2RheSwgMTYgT2N0b2JlciAyMDEyIDEyOjQ0IEFNCj4gU3ViamVjdDogUmU6IEZ3OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNtaXRoLTZtYW4tbWl0aWdhdGUtbmQtY2FjaGUtZG8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.450 References: <20121013004926.30959.4900.idtracker@ietfa.amsl.com> <1350089872.31077.YahooMailNeo@web32502.mail.mud.yahoo.com> <3078632.Ade1popzkY@gentoovm> Message-ID: <1350333070.6466.YahooMailNeo@web32507.mail.mud.yahoo.com> Date: Mon, 15 Oct 2012 13:31:10 -0700 (PDT) From: Mark Smith Subject: Re: Fw: New Version Notification for draft-smith-6man-mitigate-nd-cache-dos-slnd-01.txt To: Oliver , "ipv6@ietf.org" In-Reply-To: <3078632.Ade1popzkY@gentoovm> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 20:31:18 -0000 Hi Oliver,=0A=0AThanks very much for your feedback.=0A=0A=0A----- Original = Message -----=0A> From: Oliver =0A= > To: ipv6@ietf.org=0A> Cc: =0A> Sent: Tuesday, 16 October 2012 12:44 AM=0A= > Subject: Re: Fw: New Version Notification for draft-smith-6man-mitigate-n= d-cache-dos-slnd-01.txt=0A> =0A> On Friday 12 October 2012 17:57:52 Mark ZZ= Z Smith wrote:=0A>> Hi,=0A>> =0A=0A> =0A> Hi,=0A> =0A> Overall I lik= e the principle of the implementation but I would also say there =0A> are a= few issues that should be addressed:=0A> =0A> 1) TUSP should be defineable= on an address/interface/packet marking basis; I =0A> would say that the ex= act method of determining a trusted/untrusted querier =0A> should (will) ul= timately be down to the implementation and as such, this =0A> should exist = as a recommendation - perhaps call it a "TUD List" =0A> instead =0A> (Trust= ed/Untrusted Discriminator) with implementation of a TUD mandatory.=0A>=A0= =0A=0AI think there is value in that (I think generalising is a good idea i= f you=0A=0Acan do it), however I would be interested in some use cases wher= e something=0Aother than the source address prefix would be a useful discri= minator. I'm=0Astruggling to think of one right now. (It is 6.30 am which m= ight explain it)=0A=0A> 2) While SLND is active, a packet that requires a s= olicitation MAY be dropped =0A> outright but can optionally be requeued/buf= fered etc - queue discipline should =0A> be considered beyond the scope of = this document.=0A>=A0=0A=0AI though about maintaining an "destination addre= ss independent" queue of=0A=0Atraffic that triggered stateless neighbor dis= covery. I realised though I'd=0Athen have to work out answers to things lik= e should new packets replace old=0Aones, how big the queue is by default, a= nd how it is worked out whether=0Aa packet can be removed from the queue. I= then realised that there is=0Aprobably already a queue of some form betwee= n the forwarding plane and the=0Acontrol plane of the router, so I though t= his new queue may not be worth=0Athe additional complexity it would create = =A0I'll review that decision though.=0A=0AOne thing I'm also trying to do i= s keep in mind that this proposal is=0A=0Adealing with an exceptional case = rather than a common case, meaning that=0Athe mechanisms might only be rare= ly if ever used. So I think there is some=0Avalue in trying to keep the mec= hanisms as simple as possible. I'm still=0Ahaving a bit of a debate with my= self as to whether the trusted/untrusted=0Aprefix mechanism is even necessa= ry - to protect against the DoS it would=0Abe adequate to just resort to st= ateless ND for all traffic sources once=0Athe neighbor cache becomes reason= ably near capacity.=0A=0A> I am also pondering the possibility of securing = the on-link side by way of ND=A0=0A=0A> cookies (with a prerequiste being t= hat the subnet size is at least /64)=0A> =0A> Essentially, while using SLND= , a node would generate a neighbour solicitation =0A> for unknown on-link h= osts using an algorithmically calculated source address =0A> resulting from= a hash operation over a node-unique seed, the target address =0A> containe= d within the advertisement and the IPv6 header destination address.=0A> =0A= > Thus when receiving a neighbor advertisement, the node can simply hash th= e =0A> data in order to verify if the advertisement is spurious or not. The= node must =0A> not bind to nor answer solicitatation for these calculated = addresses. This =0A> will ensure that in the event of a duplicate address, = ND for the duplicate =0A> would not result in a false discovery.=0A>=A0=0A= =0AI like that idea because it doesn't require changes to hosts. However I'= m=0A=0Anot sure I understand how the neighbor advertisements would be sent = back to=0Athe router issuing the neighbor solicitations? Where you think th= ey would=0Abe multicast, so that the hash source address didn't have to be = used to=0Aunicast them back to the router, avoiding the unicast ND related = issues?=0A=0A> This does come with the downside that a solicited host will = most likely =0A> attempt discovery of the algorithmically calculated source= address - however, =0A> I would argue that the cost of this extra noise is= outweighed by the benefit of =0A> ensuring non-spurious advertisements.=0A= >=A0=0A=0AThanks very much,=0AMark. From oliver@8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa Mon Oct 15 14:30:50 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB51121F8A63 for ; Mon, 15 Oct 2012 14:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uys++3W08QSk for ; Mon, 15 Oct 2012 14:30:49 -0700 (PDT) Received: from mail.uptheinter.net (mail.uptheinter.net [IPv6:2001:470:9738::]) by ietfa.amsl.com (Postfix) with ESMTP id 95B1921F8A3D for ; Mon, 15 Oct 2012 14:30:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.uptheinter.net (Postfix) with ESMTP id 7B538A5643; Mon, 15 Oct 2012 22:30:47 +0100 (BST) X-DKIM: Sendmail DKIM Filter v2.7.2 mail.uptheinter.net 7B538A5643 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa; s=default; t=1350336647; bh=CwI H9Fg0CUBlNU2cVAS2rqk0w7M/KymKVXyufbk1Esc=; h=From:To:Cc:Subject: Date:Message-ID:In-Reply-To:References:MIME-Version: Content-Transfer-Encoding:Content-Type; b=le2QEkgH0c2QwQRdxXoRt2Sq I6QpGncyGFv9aFx2ALo+JETkB4WPrIzqSbyIkfv106tGTR11G2Z8ofWa+4VuNWNOC/B W0xXIwxltGUD6Lscb36l807/hH5EqSrIQEJ09juGodozUSmfIvaJWC1VaHUoUMaRdTz 6GGcL1yokICFI= X-Virus-Scanned: amavisd-new at Received: from mail.uptheinter.net ([127.0.0.1]) by localhost (vps2.uptheinter.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6pw13z2Alfa5; Mon, 15 Oct 2012 22:30:29 +0100 (BST) From: Oliver To: Mark Smith Subject: Re: Fw: New Version Notification for draft-smith-6man-mitigate-nd-cache-dos-slnd-01.txt Date: Mon, 15 Oct 2012 22:58:25 +0200 Message-ID: <18500494.21ToXmMCiW@gentoovm> User-Agent: KMail/4.8.5 (Linux/3.4.11-4-zerolag-rt19+; KDE/4.8.5; x86_64; ; ) In-Reply-To: <1350333070.6466.YahooMailNeo@web32507.mail.mud.yahoo.com> References: <20121013004926.30959.4900.idtracker@ietfa.amsl.com> <3078632.Ade1popzkY@gentoovm> <1350333070.6466.YahooMailNeo@web32507.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 21:30:50 -0000 On Monday 15 October 2012 13:31:10 Mark Smith wrote: > Hi Oliver, > > Thanks very much for your feedback. > > I think there is value in that (I think generalising is a good idea if you > > can do it), however I would be interested in some use cases where something > other than the source address prefix would be a useful discriminator. I'm > struggling to think of one right now. (It is 6.30 am which might explain it) I'd say there will ostensibly be situations where you do not actually care about the addresses you need to trust (or may simply not know it in advance/change so often that it's an administrative nightmare) but *do* know that all traffic arriving from interface X is trustworthy, in that instance, being able to classify by ingress interface would be invaluable. Taking it to the extreme, arbitrary packet marks/tags provide a means to classify based on practically anything. Additionally, I can think of existing IPv6 implementations where there is already infrastructure for matching based on interfaces or marks but providing an in-stack table of addresses would be cumbersome. > > 2) While SLND is active, a packet that requires a solicitation MAY be > > dropped outright but can optionally be requeued/buffered etc - queue > > discipline should be considered beyond the scope of this document. > > I though about maintaining an "destination address independent" queue of > > traffic that triggered stateless neighbor discovery. I realised though I'd > then have to work out answers to things like should new packets replace old > ones, how big the queue is by default, and how it is worked out whether > a packet can be removed from the queue. I then realised that there is > probably already a queue of some form between the forwarding plane and the > control plane of the router, so I though this new queue may not be worth > the additional complexity it would create I'll review that decision though. This wouldn't necessarily require a separate queue; any dequeued packet that results in a solicitation being sent would then need to have a counter set on it to prevent it from triggering another solicitation if dequeued again and eventually get dropped - this would then also open up the option of generating an ICMPv6 error at expiry. Essentially, a change to the architecture of the queue is more along the lines of what is required as opposed to maintaining an entirely separate queue. > > One thing I'm also trying to do is keep in mind that this proposal is > > dealing with an exceptional case rather than a common case, meaning that > the mechanisms might only be rarely if ever used. So I think there is some > value in trying to keep the mechanisms as simple as possible. I'm still > having a bit of a debate with myself as to whether the trusted/untrusted > prefix mechanism is even necessary - to protect against the DoS it would > be adequate to just resort to stateless ND for all traffic sources once > the neighbor cache becomes reasonably near capacity. I'm definitely all for occam's razor, but I believe that being flexible is also important. The opportunistic level of complexity should be covered in the RFC and then left down to the implementor, otherwise I'd anticipate a situation where future RFCs end up being written after complex implementations have already come into existence. In other words, "attempt to cover all the bases" - providing some means of mitigating ND flooding is most certainly a Good Thing, whether it be rudimentary or everything but the kitchen sink, I would aim to set an acceptable baseline (which IMO this document has certainly already achieved) and also give opportunity & suggestions for exemplary robustness. > > > I am also pondering the possibility of securing the on-link side by way of > > ND > > > > cookies (with a prerequiste being that the subnet size is at least /64) > > > > Essentially, while using SLND, a node would generate a neighbour > > solicitation for unknown on-link hosts using an algorithmically > > calculated source address resulting from a hash operation over a > > node-unique seed, the target address contained within the advertisement > > and the IPv6 header destination address. > > > > Thus when receiving a neighbor advertisement, the node can simply hash the > > data in order to verify if the advertisement is spurious or not. The node > > must not bind to nor answer solicitatation for these calculated > > addresses. This will ensure that in the event of a duplicate address, ND > > for the duplicate would not result in a false discovery. > > > > > > I like that idea because it doesn't require changes to hosts. However I'm > > not sure I understand how the neighbor advertisements would be sent back to > the router issuing the neighbor solicitations? Where you think they would > be multicast, so that the hash source address didn't have to be used to > unicast them back to the router, avoiding the unicast ND related issues? When sending an ICMPv6 neighbour solicitation, if there is an applicable data- link layer, the sending host can indicate the appropriate L2 address as an added option to the ICMPv6 message - this results in the solicited node sending the neighbor advertisement response to that indicated data-link layer address, maintaining the IPv6 layer address as destination - however, if the node is unknown, without this option included, the L2 response destination will be taken from the L2 source of the solicitation. Were it the case that sending a neighbour advertisement depended on already knowing the L2 address of the querier, IPv6 would have a serious chicken & egg problem :) Kind Regards, Oliver From n@arifumi.net Tue Oct 16 01:54:01 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1828D21F86C9 for ; Tue, 16 Oct 2012 01:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7YktzvtspYI for ; Tue, 16 Oct 2012 01:54:00 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B448721F86A3 for ; Tue, 16 Oct 2012 01:53:59 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so7498737vcb.31 for ; Tue, 16 Oct 2012 01:53:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding:x-gm-message-state; bh=NAgeJwzm9h63VULJsesiCRyeTSR4zROlR0u21S1UQw4=; b=oWdy/1L6ZwHFvUtlOiYEM3c9O0De7Ax5v//LjNtjR9WJOyri4rZzH3PYOhloe8F34D D0laQuRWC8bEswvMmtbss92JS61lxgCHByxYK6jspQh1le7blMeV8tufKNnfU4MAagZC ELSbC9ZssIYN4SJmaYBxBp1LTPL0kP7uf02TYwOecTicfVrOTBiDytmI5+OQkpOZGd1h mxEe5AocALJeiobBLGlfxkXXuBO465cBSQRpKzZbXWfTF2A0UyeWZq7jJ1TvGh5wf8o7 n6MnIbasLg5vmDQIbQQWhFtTFvBD33+/SaFs4QlJRClbAu893Rjq2KzJ+BwKf8hbqumW 7JyQ== MIME-Version: 1.0 Received: by 10.52.30.167 with SMTP id t7mr1435392vdh.56.1350377639177; Tue, 16 Oct 2012 01:53:59 -0700 (PDT) Sender: n@arifumi.net Received: by 10.58.178.229 with HTTP; Tue, 16 Oct 2012 01:53:59 -0700 (PDT) X-Originating-IP: [129.60.57.66] In-Reply-To: <50754741.9090506@globis.net> References: <0D1941A7-217D-44E1-A3E3-45D30D51A273@employees.org> <50754741.9090506@globis.net> Date: Tue, 16 Oct 2012 17:53:59 +0900 X-Google-Sender-Auth: IRWWHpmhwMV7mCMXoZGifwnQYqs Message-ID: Subject: Re: 6MAN WG Last Call: From: Arifumi Matsumoto To: ipv6@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlqs3ZfzbvvyvB3bbzWsjiLrYysoAd/O9NrothFPB6QVhI1rISILXCSyQmPWuH8IuJTdnO6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 08:54:01 -0000 Ray, thank you for review and comments. Responses below. 2012/10/10 Ray Hunter : > I support this work. > > Discussion > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Section 4.2 > s/the default policy should be restored/the previously active policy shou= ld > be restored/ ? It is assumed that the configuration will be either using distributed polic= y or using manually configured policy as described in 4.1. So, 4.2 is written like this. Do you propose to change the above assumption ? I really appreciate your reviewing and suggestions below. 2012/10/10 Ray Hunter : > I support this work. > > Discussion > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Section 4.2 > s/the default policy should be restored/the previously active policy shou= ld > be restored/ ? > > Nits & clarification > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Section 2 > s/A address selection option contains/An Address Selection option contain= s/ > > s/Multiple policy table options in a Policy Table option constitute a sin= gle > policy table./ > Multiple Policy Table options in an Address Selection option constitute a > single policy table./ > > s/zero padded/left aligned, big-endian, and zero padded on the right/ > > Section 3 > s/in any messages other/in any DHCPv6 messages other/ > > Section 4.1 > s/his requirement/their own requirements/ > > s/a) It receives distributed policy table, and replaces the existing > policy tables with that. > b) It preserves the default policy table, or manually configured > policy./ > a) replace the existing active policy table with the DHCPv6 distributed > policy table . > b) preserve the existing active policy table, whether this be the default > policy table, or user configured policy./ > > > Section 4.3 > s/node-global information by its nature/node-global information by their > nature/ > > s/One of the reason is/One reason being/ > > s/multiple address selection policy/multiple address selection policies,/ > > s/the effect of both policy/the effect of both policies/ > > s/that absence of the distributed policy/that absence of a distributed > policy/ > a/mean preference/mean a preference/ > > s/deal with multiple received policy/deal with multiple received policies= / > > s/DHCPv6 clients need to convert this label to a representation specified= by > each implementation/DHCPv6 clients SHOULD convert this label to a > representation appropriate for the local implementation/ > > s/So, the number of the options and the total size of the options should = be > taken care of. Since the number of selection rules could be large, an > administrator configuring the policy to be distributed should consider th= e > resulting DHCPv6 message size/ > Network administrators SHOULD consider local limitations to the maximum > DHCPv6 message size that can be reliably transported via their specific > local infrastructure to end nodes; and therefore they SHOULD consider the > number of options, the total size of the options, and the resulting DHCPv= 6 > message size, when defining their Policy Table./ > > Section 6: > > s/and the affected packets might be blocked at an outgoing ISP because of > ingress filtering/and the affected packets might be blocked at an outgoin= g > ISP because of ingress filtering, incur additional network charges, or be > misdirected to an attacker's machine/ > > s/should be communicated through a secure/should communicate through a > secure/ > > s/This issue will not be degraded regardless of the introduction of this > option, or regardless/This issue will not be modified by the introduction= of > this option, regardless/ > > regards, > RayH > > Ole Tr=F8an wrote: >> >> All, >> >> This message starts a two week 6MAN Working Group on advancing: >> >> Title : Distributing Address Selection Policy using >> DHCPv6 >> Author(s) : A. Matsumoto, T. Fujisaki, T. Chown >> Filename : draft-ietf-6man-addr-select-opt-06.txt >> Pages : 10 >> Date : 2012-09-21 >> >> http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-06 >> >> as Proposed Standard. Substantive comments and statements of support fo= r >> advancing this document should be directed to the mailing list. Editori= al >> suggestions can be sent to the authors. This last call will end on 24. >> October 2012. >> >> Regards, >> >> Ole Tr=F8an& Bob Hinden > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From brian.e.carpenter@gmail.com Tue Oct 16 03:29:27 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797EA21F8797 for ; Tue, 16 Oct 2012 03:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.566 X-Spam-Level: X-Spam-Status: No, score=-103.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQhAd3ibkN17 for ; Tue, 16 Oct 2012 03:29:26 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7B921F8796 for ; Tue, 16 Oct 2012 03:29:26 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so2758050bkc.31 for ; Tue, 16 Oct 2012 03:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5TzS4NreQPaKAKdjbZZMA+Um2kR3aZonBD5YCxsSnwQ=; b=pZCuiwoW/vLvfww3LjpSPGy4LhIg8LmM6CbhvjJsA8xZbcbeYeL5E2YVEFVtgjANa5 tWZAq2+MqQFf9wp1zILdQP/wQ22dejrGL7AeL7zBvqHExTk8BfFJoO1DdSQyNr7o4RRP ptD0GMF726cL9Z0DhobfBb72vpLuxLP6VlITTKQ5Ra9hbg4hN8M3+vRSCdR5oFVY3dPj hmQEekwHqaYYjMybTfNy0oCS8coO4ktTyn/GVYANZdeCZ0+1lTGC7KAyEWn13IhD1A4l DFogb/mPKVfB5WDQISZDcfi8pG30Swy1dKc9Fm3mS2XjWcURHPBlhSZff8W6ZFWYnDxr DMTA== Received: by 10.204.128.89 with SMTP id j25mr3969081bks.23.1350383365238; Tue, 16 Oct 2012 03:29:25 -0700 (PDT) Received: from [128.232.110.214] (c214.al.cl.cam.ac.uk. [128.232.110.214]) by mx.google.com with ESMTPS id x13sm10246459bkv.16.2012.10.16.03.29.23 (version=SSLv3 cipher=OTHER); Tue, 16 Oct 2012 03:29:23 -0700 (PDT) Message-ID: <507D3706.4020300@gmail.com> Date: Tue, 16 Oct 2012 11:29:26 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "ipv6@ietf.org 6man" Subject: Re: 6MAN WG Last Call: References: <0D1941A7-217D-44E1-A3E3-45D30D51A273@employees.org> In-Reply-To: <0D1941A7-217D-44E1-A3E3-45D30D51A273@employees.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 10:29:27 -0000 Hi, I support this draft but have a couple of comments. > A: Automatic Row Addition flag. This flag toggles the Automatic > Row Addition flag at client hosts, which is described in the > section 2.1 in RFC 6724 [RFC6724]. If this flag is set to 1, i= t > does not change client host behavior, that is, a client MAY > automatically add additional site-specific rows to the policy > table. If set to 0, the Automatic Row Addition flag is > disabled, and a client MAY NOT automatically add rows to the > policy table. This text includes "MAY NOT" (in upper case). This is specifically not covered by RFC 2119 because it's unclear. I think we want "MUST NOT" instead. Or do we want "SHOULD NOT"? The existence of this flag is a "SHOULD" in RFC 6724. > P: Privacy Preference flag. This flag toggles the Privacy > Preference flag at client hosts, which is described in the > section 5 in RFC 6724 [RFC6724]. If this flag is set to 1, it > does not change client host behavior, that is, a client SHOULD > prefer temporary addresses. If set to 0, the Privacy Preferenc= e > flag is disabled, and a client SHOULD prefer public addresses. I am a little bothered by those two SHOULDs. It seems to me that they sub= tly modify what is said in RFC 6724, where the relevant text is quite subtle already. I would prefer to see the two SHOULD clauses deleted. Alternativ= ely, s/SHOULD/will/ would better align the text with RFC 6724. Nit: [I-D.ietf-6man-stable-privacy-addresses] is defined but not used. Regards Brian Carpenter On 10/10/2012 09:28, Ole Tr=C3=B8an wrote: > All, >=20 > This message starts a two week 6MAN Working Group on advancing: >=20 > Title : Distributing Address Selection Policy using DHCPv6 > Author(s) : A. Matsumoto, T. Fujisaki, T. Chown > Filename : draft-ietf-6man-addr-select-opt-06.txt > Pages : 10 > Date : 2012-09-21 >=20 > http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-06 >=20 > as Proposed Standard. Substantive comments and statements of support f= or advancing this document should be directed to the mailing list. Edito= rial suggestions can be sent to the authors. This last call will end on = 24. October 2012. >=20 > Regards, >=20 > Ole Tr=C3=B8an & Bob Hinden > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From kauer@biplane.com.au Thu Oct 18 05:30:49 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E645C21F8643 for ; Thu, 18 Oct 2012 05:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.304 X-Spam-Level: X-Spam-Status: No, score=-1.304 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, PLING_QUERY=1.39] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDyfsCA6RiVo for ; Thu, 18 Oct 2012 05:30:49 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id C18F721F86F5 for ; Thu, 18 Oct 2012 05:30:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYdAOf1f1ABmB6LPGdsb2JhbAANOIYSuh4lAQEBATiCfn4NAiYCRQYBExOwcm6TCoEhj2eBEgObb4UjiBA Received: from unknown (HELO [10.230.19.94]) ([1.152.30.139]) by ipmail06.adl6.internode.on.net with ESMTP; 18 Oct 2012 23:00:44 +1030 Message-ID: <1350563448.2987.14.camel@karl> Subject: Win7 - no managed flag, DHCP address released?!? From: Karl Auer To: IETF IPv6 Date: Thu, 18 Oct 2012 23:30:48 +1100 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 12:30:50 -0000 My apologies if this is not the right list for this comment/question; suggestions for alternatives are welcome. I have just seen the following demonstrated. Two routers, short RA interval, both sending RAs for the same prefix, both with the autoconf flag set, one with the managed flag set and one without. A Windows 7 host gets an address via DHCPv6 when the RA with the managed flag comes around - and DROPS IT when an RA without the managed flag comes past. This is not the valid lifetime expiring normally. I was not able to determine whether the Windows host is actually sending a DHCPv6 release as well, but it is most certainly dropping the address from the interface. I will be trying to do my own tests to confirm (or not) this behaviour, but has anyone else seen it? Or seen it with other operating systems? If it is indeed happening, this behaviour seems very badly broken to me. I don't feel the relevant RFCs can reasonably be interpreted as supporting this behaviour. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 From oliver@8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa Thu Oct 18 06:20:05 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103CF21F8599 for ; Thu, 18 Oct 2012 06:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, PLING_QUERY=1.39] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPnRGv5tsYzs for ; Thu, 18 Oct 2012 06:20:04 -0700 (PDT) Received: from mail.uptheinter.net (mail.uptheinter.net [IPv6:2001:470:9738::]) by ietfa.amsl.com (Postfix) with ESMTP id 40EB421F8589 for ; Thu, 18 Oct 2012 06:20:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.uptheinter.net (Postfix) with ESMTP id 16E73A56D4 for ; Thu, 18 Oct 2012 14:20:03 +0100 (BST) X-DKIM: Sendmail DKIM Filter v2.7.2 mail.uptheinter.net 16E73A56D4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa; s=default; t=1350566403; bh=vx7 pO6YQJmYRVydV+rwsUg3MosTrcyyDm3VRpX++foE=; h=From:To:Subject:Date: Message-ID:In-Reply-To:References:MIME-Version: Content-Transfer-Encoding:Content-Type; b=VeEu9MAHL9X7AkRoLu3CzI8V NUl8e1SfnIZfeLsHbE92YgadkD3rrdzJIFxmVwEzjcI/cqrz0svL24et89UttMxLObb Yi4PMMa+PJwVKDg1BasX9i7fAbQh9EsmHYnJhDXqN7t2raZpEksmxWj5geuIShMOBL+ f9QAG9eRwN+8k= X-Virus-Scanned: amavisd-new at Received: from mail.uptheinter.net ([127.0.0.1]) by localhost (vps2.uptheinter.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oHB7sZ0-0CQc for ; Thu, 18 Oct 2012 14:19:56 +0100 (BST) From: Oliver To: ipv6@ietf.org Subject: Re: Win7 - no managed flag, DHCP address released?!? Date: Thu, 18 Oct 2012 13:48:45 +0200 Message-ID: <2055283.QkGonX4Apk@gentoovm> User-Agent: KMail/4.8.5 (Linux/3.4.11-4-zerolag-rt19+; KDE/4.8.5; x86_64; ; ) In-Reply-To: <1350563448.2987.14.camel@karl> References: <1350563448.2987.14.camel@karl> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 13:20:05 -0000 On Thursday 18 October 2012 23:30:48 Karl Auer wrote: > My apologies if this is not the right list for this comment/question; > suggestions for alternatives are welcome. I'd recommend the ipv6-ops mailing list on cluenet.de and possibly NANOG Regards, Oliver From ammar.salih@auis.edu.iq Thu Oct 18 13:03:51 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B9221F845B for ; Thu, 18 Oct 2012 13:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqlrsfefjQVo for ; Thu, 18 Oct 2012 13:03:50 -0700 (PDT) Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) by ietfa.amsl.com (Postfix) with SMTP id 00D3321F844E for ; Thu, 18 Oct 2012 13:03:49 -0700 (PDT) Received: from mail-wi0-f198.google.com ([209.85.212.198]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP ID DSNKUIBgpUyeffqgEC+Ly7M+nuubLO1lokRy@postini.com; Thu, 18 Oct 2012 13:03:50 PDT Received: by mail-wi0-f198.google.com with SMTP id cb5so1662071wib.1 for ; Thu, 18 Oct 2012 13:03:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=OyG2x55P+lFtjaUb/PxI62axM9pnyGJgzbgSiR+LRdE=; b=cCG97hz1vyFCcUJIYAeAdv1C/3oDE0mplRUVuZrNo/sK+kZtStoh3HG2xY+e/4CYj+ oXJvuDknW5shNol6ye41SNZZERC8cHO+BHReU6OtXDuvQY7F6ECqjLULhz5q8vqjD64I 676R/6/O8AKFdQWk0hCWSWDobcgPYLg7deeMuQSB+gsKbqGcTfD4CeiO3GkWIPSZNYTr tETbr0O3Z/BnBJfTH4yjcEeo1ZxnlOAlzi77AtA+97/TgQFTcs1DjCXMn2rxQEGBxPxi h6AI8JIWUl/DTKetiuQ/ZbAq1oeuVlZ9pmq9ADwRAYkUqy7TjEtNFsqQR+vaHmngR8ah ThJg== Received: by 10.14.214.2 with SMTP id b2mr25198666eep.32.1350590628032; Thu, 18 Oct 2012 13:03:48 -0700 (PDT) Received: by 10.14.214.2 with SMTP id b2mr25198655eep.32.1350590627885; Thu, 18 Oct 2012 13:03:47 -0700 (PDT) Received: from AMMARSALIH ([95.159.79.188]) by mx.google.com with ESMTPS id 42sm41504812eee.0.2012.10.18.13.03.40 (version=SSLv3 cipher=OTHER); Thu, 18 Oct 2012 13:03:44 -0700 (PDT) From: "Ammar Salih" To: , References: <50758ba5.e956420a.71b1.6dbb@mx.google.com> In-Reply-To: Subject: RE: IPv6 modification suggestion Date: Thu, 18 Oct 2012 23:03:32 +0300 Message-ID: <508060a0.42020e0a.3ead.ffff9089@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2nYb9+B2JU5/S2TjaXUBla9dpJ1wAGEG4wAXry01A= Content-Language: en-us X-Gm-Message-State: ALoCoQnIUsTPxB5WcpEunnJfOj4EQwoT1zmuBUfmyyg4a/+gkrKSjloSGgJx6/660X3um96zUvIpQwKmtxSXbXRexVlbwgcygDI9uV05NkBOAre2n1EPNKT0dbu3eIfO7X1bodJP790z X-Mailman-Approved-At: Thu, 18 Oct 2012 13:14:02 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 20:03:51 -0000 Hello everyone, I had a brief look at GEOPRIV and I was very much impressed, There has been so much work done by this amazing group! At the same time, I would like to raise my concern regarding the http location request which will not be detected by layer-3 devices (Routers), I am anticipating that in the future, GPS capability will be added to the router itself (just like smart phones) and packet marking and classification based on geo-location will be required. QoS, firewall and routing based on geo-location will be highly demanded when mobile routers move from one geo-location to another which has different regulations/electronic laws. Here is an example, if your router is within city-X and this city has very good electronic and copyright laws, then users will have relaxed network security settings, but what if the very same router moved to city-Y which according to its law, certain websites should be blocked (like facebook in china for example) .. these rules based on geographic location won't be feasible unless the mobile router has a GPS and can read/write coordinates to layer-3 packets. Best, Ammar -----Original Message----- From: Ammar Salih [mailto:ammar.salih@auis.edu.iq] Sent: Thursday, October 11, 2012 11:41 AM To: 'Bob Hinden' Cc: 'ipv6@ietf.org' Subject: RE: IPv6 modification suggestion Hello Bob, > That said, I don't think it is a good idea to add GPS position to every IPv6 header. It would add a lot of overhead. It does not have to be in every IPv6 header, only when there is location update, also it can be included in the first header (just like RTP and cRTP) > there are many privacy related issues (as others have pointed out). This can be set manually in case of any privacy concerns, just like other header's information like IP address. > An alternative would be to create a application layer protocols that could request and send GPS positions. Sounds awesom, but in this case all webpages, phone applications, server side scripting languages ... etc have to be modified to support the new application protocol. Not mensioning that layer 3 devices (like routers) won't be able to support the feature, let's say in the feature you want to do dynamic routing based on geo location. In anycase, I still feel quite interested about the new layer 7 protocol, will try to go through the GEOPRIV documentation this weekend in order to get more details. Thank you for your kind response, Ammar -----Original Message----- From: Bob Hinden [mailto:bob.hinden@gmail.com] Sent: Thursday, October 11, 2012 6:37 AM To: Ammar Salih Cc: Bob Hinden; ipv6@ietf.org Subject: Re: IPv6 modification suggestion Ammar, On Oct 10, 2012, at 7:52 AM, Ammar Salih wrote: > Hello Dears, > > I would like to suggest adding GPS coordinates to IPv6 header, as you know the current way of determining the location of the IP address is through the IP registration, which is not very accurate as it depends on how the ISP registers it's IP subnets, which is normally done based on country/city. I agree with you that IP addresses are not very reliable as a means of determining geographic location. That said, I don't think it is a good idea to add GPS position to every IPv6 header. It would add a lot of overhead, there are many privacy related issues (as others have pointed out), it doesn't need to be in every packet. An alternative would be to create a application layer protocols that could request and send GPS positions. That is a better way to to deal with the privacy issues and the GPS position would only need to be sent when desired or when requested. The GEOPRIV working group is doing some work in this area. See: http://datatracker.ietf.org/wg/geopriv/charter/ Bob > > Getting more accurate locations will enhance many services provided by the web, like targeted commercials (for example, I can get Ads regarding restaurants available in my neighborhood instead of all restaurants in the city), another good example would be webpage's language, my language will be detected more accurately based on my exact area rather than my countery, as there are many countries with more than one popular language. > > Maps, navigation, emergency calls and many other services will also get enhanced with accurate locations. > > I hope you will find my suggestion beneficial, and looking forward to hearing from you. > > > Best, > > Ammar Salih | B.Sc.Eng, CCNA-S, CCVP, CCIE-V written Technical Lead - > Voice and Data Support Services > > Mob: +964 (0) 770 533 0306 > Office: +964 (0) 53 511 2020 - Ext. 2221 > Email: ammar.salih@auis.edu.iq > The American University of Iraq - Sulaimani > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From albert.e.manfredi@boeing.com Thu Oct 18 13:50:35 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E8F21F8533 for ; Thu, 18 Oct 2012 13:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkO40YMXRbj1 for ; Thu, 18 Oct 2012 13:50:34 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAB521F8532 for ; Thu, 18 Oct 2012 13:50:34 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9IKoXvk013468 for ; Thu, 18 Oct 2012 15:50:33 -0500 Received: from XCH-MWHT-05.mw.nos.boeing.com (xch-mwht-05.mw.nos.boeing.com [134.57.119.160]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9IKoWc0013457 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 18 Oct 2012 15:50:32 -0500 Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.118.180]) by XCH-MWHT-05.mw.nos.boeing.com ([134.57.119.160]) with mapi; Thu, 18 Oct 2012 15:50:32 -0500 From: "Manfredi, Albert E" To: Ammar Salih , "ipv6@ietf.org" Date: Thu, 18 Oct 2012 15:50:30 -0500 Subject: RE: IPv6 modification suggestion Thread-Topic: IPv6 modification suggestion Thread-Index: Ac2nYb9+B2JU5/S2TjaXUBla9dpJ1wAGEG4wAXry01AAAosPsA== Message-ID: References: <50758ba5.e956420a.71b1.6dbb@mx.google.com> <508060a0.42020e0a.3ead.ffff9089@mx.google.com> In-Reply-To: <508060a0.42020e0a.3ead.ffff9089@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 20:50:35 -0000 I don't see any of this as being remotely desirable, as part of IETF standa= rds. If a router is to be installed in a repressive country, then it is certainl= y possible to have whatever layer 3-7 filters implemented in that router, a= s just such filters are implemented in "firewalls." Or, if an Internet site= wants to serve customers with special location-based apps, they can certai= nly do so without having to impact the IETF standards (either by requiring = GPS input into the app, or by asking the user to provide his location). Or, if a group wants to develop a location-based routing protocol, they can= certainly do so, without forcing this information to impact IETF standards= . It just seems unwise, to say the least, to build this feature directly into= layer 3 or 4 protocols, where it becomes ubiquitous, and where the user is= not in control of it. Bert -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Amm= ar Salih Sent: Thursday, October 18, 2012 4:04 PM To: ipv6@ietf.org; geopriv@ietf.org Subject: RE: IPv6 modification suggestion Hello everyone, I had a brief look at GEOPRIV and I was very much impressed= , There has been so much work done by this amazing group! At the same time, I would like to raise my concern regarding the http location request which will not be detected by layer-3 devices (Routers), I am anticipating that in the future, GPS capability will be added to the router itself (just like smart phones) and packet marking and classificatio= n based on geo-location will be required. QoS, firewall and routing based on geo-location will be highly demanded whe= n mobile routers move from one geo-location to another which has different regulations/electronic laws. Here is an example, if your router is within city-X and this city has very good electronic and copyright laws, then users will have relaxed network security settings, but what if the very same router moved to city-Y which according to its law, certain websites should be blocked (like facebook in china for example) .. these rules based on geographic location won't be feasible unless the mobile router has a GPS and can read/write coordinates to layer-3 packets. Best, Ammar From oliver@8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa Thu Oct 18 14:04:35 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1742521F84CE for ; Thu, 18 Oct 2012 14:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o02yRwAowq8X for ; Thu, 18 Oct 2012 14:04:34 -0700 (PDT) Received: from mail.uptheinter.net (mail.uptheinter.net [IPv6:2001:470:9738::]) by ietfa.amsl.com (Postfix) with ESMTP id 1214821F844C for ; Thu, 18 Oct 2012 14:04:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.uptheinter.net (Postfix) with ESMTP id E7BB1A571F for ; Thu, 18 Oct 2012 22:04:29 +0100 (BST) X-DKIM: Sendmail DKIM Filter v2.7.2 mail.uptheinter.net E7BB1A571F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa; s=default; t=1350594269; bh=jcU BOMzTsep1oBkpl9G1N9xOd2170hCbFPyc1qYQWGM=; h=From:To:Subject:Date: Message-ID:In-Reply-To:References:MIME-Version:Content-Type: Content-Transfer-Encoding; b=dW6HwvIsB2aBxCQdq57h+L1vC8IAdINm2XE1X hPvIYpJH7oYWT13wRENrAjoXG1hqsYY10/C25RT6dH+Gk6+rv9BrX4C8vN7KO3JHn4D BkWamrnYiMg/K+9MOAcJwUCWcyIAuM5WGPLLmtdRDcJqKT2c3b3Ry4jUNyq36AO69KM = X-Virus-Scanned: amavisd-new at Received: from mail.uptheinter.net ([127.0.0.1]) by localhost (vps2.uptheinter.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id lN5aGstzSye8 for ; Thu, 18 Oct 2012 22:04:25 +0100 (BST) From: Oliver To: ipv6@ietf.org Subject: Re: IPv6 modification suggestion Date: Thu, 18 Oct 2012 21:25:50 +0200 Message-ID: <3127510.enq5ZB6RCp@gentoovm> User-Agent: KMail/4.8.5 (Linux/3.4.11-4-zerolag-rt19+; KDE/4.8.5; x86_64; ; ) In-Reply-To: <508060a0.42020e0a.3ead.ffff9089@mx.google.com> References: <50758ba5.e956420a.71b1.6dbb@mx.google.com> <508060a0.42020e0a.3ead.ffff9089@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="nextPart5579173.195lSnPpuZ" Content-Transfer-Encoding: 7Bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 21:04:35 -0000 --nextPart5579173.195lSnPpuZ Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Thursday 18 October 2012 23:03:32 Ammar Salih wrote: > Hello everyone, I had a brief look at GEOPRIV and I was very much impressed, > There has been so much work done by this amazing group! > > At the same time, I would like to raise my concern regarding the http > location request which will not be detected by layer-3 devices (Routers), I > am anticipating that in the future, GPS capability will be added to the > router itself (just like smart phones) and packet marking and classification > based on geo-location will be required. quite a big assumption to make, whom will require this, and more to the point, how does that need in any way legitimise putting GPS coordinates in a packet header? > Here is an example, if your router is within city-X and this city has very > good electronic and copyright laws, then users will have relaxed network > security settings, but what if the very same router moved to city-Y which > according to its law, certain websites should be blocked (like facebook in > china for example) .. these rules based on geographic location won't be > feasible unless the mobile router has a GPS and can read/write coordinates > to layer-3 packets. Rather than comment on this immediately, I will first introduce the context of a quote you have made further down. > > there are many privacy related issues (as others have pointed out). > > This can be set manually in case of any privacy concerns, just like other > header's information like IP address. If you can arbitrarily alter the coordinates, the copyright enforcement aspect that you are proposing is violated. If you wish to declare exceptions where it cannot be altered, the privacy assurance is violated. In any case, it loses all value at the nexthop; there will be absolutely nothing preventing another router from mangling the value, whether intentionally or due to accidental corruption. Not to mention someone elsewhere simply firing out a packet spoofing your source address. A proposal such as this goes far beyond the intended scope of IPv6; if GPS coordinates are acceptable, where shall we go next? Social Security numbers? Reductio ad absurdum. Regards, Oliver --nextPart5579173.195lSnPpuZ Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="us-ascii"

On Thursday 18 October 2012 23:03:32 Ammar Salih wrote:

> Hello everyone, I had a brief look at GEOPRIV and I was very much impressed,

> There has been so much work done by this amazing group!

>

> At the same time, I would like to raise my concern regarding the http

> location request which will not be detected by layer-3 devices (Routers), I

> am anticipating that in the future, GPS capability will be added to the

> router itself (just like smart phones) and packet marking and classification

> based on geo-location will be required.

 

quite a big assumption to make, whom will require this, and more to the point, how does that need in any way legitimise putting GPS coordinates in a packet header?

 

> Here is an example, if your router is within city-X and this city has very

> good electronic and copyright laws, then users will have relaxed network

> security settings, but what if the very same router moved to city-Y which

> according to its law, certain websites should be blocked (like facebook in

> china for example) .. these rules based on geographic location won't be

> feasible unless the mobile router has a GPS and can read/write coordinates

> to layer-3 packets.

 

Rather than comment on this immediately, I will first introduce the context of a quote you have made further down.

 

> > there are many privacy related issues (as others have pointed out).

>

> This can be set manually in case of any privacy concerns, just like other

> header's information like IP address.

 

If you can arbitrarily alter the coordinates, the copyright enforcement aspect that you are proposing is violated. If you wish to declare exceptions where it cannot be altered, the privacy assurance is violated.

 

In any case, it loses all value at the nexthop; there will be absolutely nothing preventing another router from mangling the value, whether intentionally or due to accidental corruption. Not to mention someone elsewhere simply firing out a packet spoofing your source address.

 

A proposal such as this goes far beyond the intended scope of IPv6; if GPS coordinates are acceptable, where shall we go next? Social Security numbers? Reductio ad absurdum.

 

Regards,

Oliver

--nextPart5579173.195lSnPpuZ-- From alexandru.petrescu@gmail.com Fri Oct 19 01:00:01 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B1E21F8646 for ; Fri, 19 Oct 2012 01:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.019 X-Spam-Level: X-Spam-Status: No, score=-10.019 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yebL3KhmpvUv for ; Fri, 19 Oct 2012 01:00:00 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAEB21F859E for ; Fri, 19 Oct 2012 00:59:59 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q9J7xw5d019255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 19 Oct 2012 09:59:58 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q9J7xwU9017177 for ; Fri, 19 Oct 2012 09:59:58 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q9J7xvk9003867 for ; Fri, 19 Oct 2012 09:59:58 +0200 Message-ID: <5081087D.2020807@gmail.com> Date: Fri, 19 Oct 2012 09:59:57 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: IPv6 Subject: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 08:00:01 -0000 Dear participants to 6man group, We just submitted "Prefix Delegation extension to Neighbor Discovery protocol" draft-kaiser-nd-pd-00 available at: http://tools.ietf.org/html/draft-kaiser-nd-pd-00 The context is vehicular environments, the goal to realize IP vehicle-to-vehicle-to-infrastructure communications. We had several problems to solve before materializing IP connectivity between vehicles and up to infrastructure: which IPv6 addresses to use in a disconnected vehicle, how would one Internet-connected vehicle offer access to several IP devices in a nearby non-SIM-but-WiFi vehicle, etc. To solve the latter, we started by using existing ND, DHCP and Mobile IP protocols and realized that some mechanisms were missing. Some of the needed mechanism was Prefix Delegation in ND (even though ND does offer default route, address auto-config, _is_ widely available, etc.) Hence we conceived this PD method for ND which is just one part of a bigger system. We have prototyped and experimented it. We would like the 6man group to consider this draft. Comments about the idea in this draft? About the problem? Thanks in advance, Alex > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Prefix Delegation extension to Neighbor Discovery > protocol Author(s) : Arnaud Kaiser Sylvain Decremps Alexandru > Petrescu Filename : draft-kaiser-nd-pd-00.txt Pages : 24 Date > : 2012-10-15 > > Abstract: This document describes an extension to the Neighbor > Discovery protocol (ND). The proposed extension enhances ND by > providing it a new option: the Prefix Delegation option (ND_PD). > ND_PD offers the possibility for a router to ask for prefixes to be > delegated, even if no DHCPv6 Server (or Relay) are present on link. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-kaiser-nd-pd > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-kaiser-nd-pd-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ I-D-Announce mailing > list I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft > directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > From swmike@swm.pp.se Fri Oct 19 01:08:40 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C1E21F843E for ; Fri, 19 Oct 2012 01:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I20CSDZjxw+t for ; Fri, 19 Oct 2012 01:08:40 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 17D9D21F87E6 for ; Fri, 19 Oct 2012 01:08:40 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 63DDD9C; Fri, 19 Oct 2012 10:08:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 600989A; Fri, 19 Oct 2012 10:08:39 +0200 (CEST) Date: Fri, 19 Oct 2012 10:08:39 +0200 (CEST) From: Mikael Abrahamsson To: Alexandru Petrescu Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt In-Reply-To: <5081087D.2020807@gmail.com> Message-ID: References: <5081087D.2020807@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 08:08:40 -0000 On Fri, 19 Oct 2012, Alexandru Petrescu wrote: > Comments about the idea in this draft? About the problem? What is the rationale for duplicating the functionality in DHCPv6-PD into ND? If code needs to be changed, why can't that code change be to implement existing standard instead of implementing a new standard? Isn't ND handled by the kernel in a lot of OSes? Does prefix delegation really belong there? -- Mikael Abrahamsson email: swmike@swm.pp.se From pkern@spike.0x539.de Fri Oct 19 01:22:19 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E4221F884C for ; Fri, 19 Oct 2012 01:22:19 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-oi7wZhapLD for ; Fri, 19 Oct 2012 01:22:19 -0700 (PDT) Received: from hub.kern.lc (hub.kern.lc [IPv6:2a00:1158:3::c7]) by ietfa.amsl.com (Postfix) with ESMTP id DCB7021F87DA for ; Fri, 19 Oct 2012 01:22:18 -0700 (PDT) Received: from [2001:4dd0:ff00:809d:224:d7ff:fe9d:1198] (helo=spike.0x539.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1TP7qQ-0005QX-2M; Fri, 19 Oct 2012 10:22:14 +0200 Received: from pkern by spike.0x539.de with local (Exim 4.80) (envelope-from ) id 1TP7qP-0003yv-B8; Fri, 19 Oct 2012 10:22:13 +0200 Date: Fri, 19 Oct 2012 10:22:13 +0200 From: Philipp Kern To: Mikael Abrahamsson Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt Message-ID: <20121019082213.GA14631@spike.0x539.de> References: <5081087D.2020807@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="+QahgC5+KEYLbs62" Content-Disposition: inline In-Reply-To: Organization: Fachschaft Mathematik / Informatik am Karlsruher Institut fuer Technologie (KIT) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Alexandru Petrescu , IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 08:22:20 -0000 --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Mikael, am Fri, Oct 19, 2012 at 10:08:39AM +0200 hast du folgendes geschrieben: > On Fri, 19 Oct 2012, Alexandru Petrescu wrote: > >Comments about the idea in this draft? About the problem? > What is the rationale for duplicating the functionality in DHCPv6-PD > into ND? If code needs to be changed, why can't that code change be > to implement existing standard instead of implementing a new > standard? >=20 > Isn't ND handled by the kernel in a lot of OSes? Does prefix > delegation really belong there? that reminds me of the RA/DHCPv6 for DNS recursor host configuration in RFC4339, which provides advantages/disadvantages for shipping this information by RDNSS vs. DHCPv6. Kind regards Philipp Kern --+QahgC5+KEYLbs62 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJQgQ21AAoJEERuJUU10FbstIIH/0ZGYJ7oKBfRG71PYhvS6NZn era18IKx8aUu/74osXJXBGnLtoKrnfWHl69dZ/6pJ08NuBE7+AeJ9cT5h7Coa+bK z7PQNjEhKBEkDqdtA269w02XwnxgTFFuv8eu/bFPLO4y3HgeG2Jw6SYf+v0vPtNv TAUwOs42z867WE/c0ksXLMDQjZZ+6+8NT/5Tk3qZ9x/CF2LFR+dqZCwB3WKX9Cwz o+fBLReiT7zqrd64iKXxdRTX31sIFlku8JUKNZONol6baZ5c/x8fPfxBuS/zYf8F CHqYi5eaoGtTZflPyW39bulqVGCSt6Y9WW1B61OHMWqscQG4UCiE/b5YOTR1rbA= =jRJk -----END PGP SIGNATURE----- --+QahgC5+KEYLbs62-- From ietfc@btconnect.com Fri Oct 19 07:17:36 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3B821F8639 for ; Fri, 19 Oct 2012 07:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.245 X-Spam-Level: X-Spam-Status: No, score=-3.245 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXyJXkVpIzal for ; Fri, 19 Oct 2012 07:17:35 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id A7C6821F84D8 for ; Fri, 19 Oct 2012 07:17:35 -0700 (PDT) Received: from mail181-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.23; Fri, 19 Oct 2012 14:17:30 +0000 Received: from mail181-va3 (localhost [127.0.0.1]) by mail181-va3-R.bigfish.com (Postfix) with ESMTP id 55DBD400078; Fri, 19 Oct 2012 14:17:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.85; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: PS-23(zz9371Ic89bh936eI542Mzz1202h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h304l1155h) Received: from mail181-va3 (localhost.localdomain [127.0.0.1]) by mail181-va3 (MessageSwitch) id 1350656247568986_17828; Fri, 19 Oct 2012 14:17:27 +0000 (UTC) Received: from VA3EHSMHS008.bigfish.com (unknown [10.7.14.246]) by mail181-va3.bigfish.com (Postfix) with ESMTP id 873CF2A0048; Fri, 19 Oct 2012 14:17:27 +0000 (UTC) Received: from DB3PRD0710HT001.eurprd07.prod.outlook.com (157.56.253.85) by VA3EHSMHS008.bigfish.com (10.7.99.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 19 Oct 2012 14:17:26 +0000 Received: from BL2PRD0410HT004.namprd04.prod.outlook.com (157.56.240.85) by pod51017.outlook.com (10.255.75.36) with Microsoft SMTP Server (TLS) id 14.16.224.5; Fri, 19 Oct 2012 14:17:24 +0000 Message-ID: <023f01cdae04$6d68cf60$4001a8c0@gateway.2wire.net> From: t.petch To: =?iso-8859-1?Q?Ole_Tr=F8an?= , References: <0D1941A7-217D-44E1-A3E3-45D30D51A273@employees.org> Subject: Re: 6MAN WG Last Call: Date: Fri, 19 Oct 2012 15:17:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.240.85] Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com Cc: 6man-chairs@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 14:17:36 -0000 s.7 IANA considerations request the allocation of a code for OPTION_ADDRSEL_ZONE Is this the now removed OPTION_ZONE_INDEX ? If not, what? s.2 "POLICY TABLE OPITONS" Tom Petch ----- Original Message ----- From: "Ole Tr=F8an" To: Cc: <6man-chairs@tools.ietf.org> Sent: Wednesday, October 10, 2012 9:28 AM All, This message starts a two week 6MAN Working Group on advancing: Title : Distributing Address Selection Policy using DHCPv6 Author(s) : A. Matsumoto, T. Fujisaki, T. Chown Filename : draft-ietf-6man-addr-select-opt-06.txt Pages : 10 Date : 2012-09-21 http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-06 as Proposed Standard. Substantive comments and statements of support for advancing this document should be directed to the mailing list. Editorial suggestions can be sent to the authors. This last call will end on 24. October 2012. Regards, Ole Tr=F8an & Bob Hinden -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From sarikaya2012@gmail.com Fri Oct 19 08:50:22 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7AC21F879D for ; Fri, 19 Oct 2012 08:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.519 X-Spam-Level: X-Spam-Status: No, score=-3.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lNIjfo-CU8W for ; Fri, 19 Oct 2012 08:50:22 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 352D121F875C for ; Fri, 19 Oct 2012 08:50:22 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so1053535iec.31 for ; Fri, 19 Oct 2012 08:50:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/zhvsvzTB0z3bRBMv54ZXsbwPNXTjkuBEEEmdAHxh9c=; b=hSnyNYHWHdmV9DMNTH+uqEJCkmyJ2ZoAC7BWICs+enBgFjEG94GmfIoo4VkCP/1Q5B vRpXZkpqOyNAfICZsiDJ5N2nKtMF0wyzUDxQuli+SWiWAPBLZG71RXW7u9MLW5v67Cji D3L6WzZV9s1J87uTkRVUmxr35Jd9eWNUf1ngIGalQRaiy/N8N8xJuMC9io6nPi+2z1Zw bUJCzm0qTKgm/ecl2nk07jRLvIjgxMImtfSV9TypD/BhjagqgDpfUxyWWScgaGOunwMu DllxhTkjfEfUoRchP2i2wvQRMa232WsihsUms+SDWv96ZKiiBrMhTGxlkDiVHKKHsrRw 74DQ== MIME-Version: 1.0 Received: by 10.42.18.193 with SMTP id y1mr1562060ica.0.1350661821859; Fri, 19 Oct 2012 08:50:21 -0700 (PDT) Received: by 10.231.85.26 with HTTP; Fri, 19 Oct 2012 08:50:21 -0700 (PDT) In-Reply-To: References: <5081087D.2020807@gmail.com> Date: Fri, 19 Oct 2012 10:50:21 -0500 Message-ID: Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt From: Behcet Sarikaya To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexandru Petrescu , IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 15:50:22 -0000 Hi Mikael, On Fri, Oct 19, 2012 at 3:08 AM, Mikael Abrahamsson wrote: > On Fri, 19 Oct 2012, Alexandru Petrescu wrote: > >> Comments about the idea in this draft? About the problem? > > > What is the rationale for duplicating the functionality in DHCPv6-PD into > ND? If code needs to be changed, why can't that code change be to implement > existing standard instead of implementing a new standard? > It is not just implementing that code in one node. DHCPv6-PD requires Delegating Router on a DHCP server somewhere and then Requesting Router on the edge router (there was a proposal to implement it on a UE). It is a system support issue, I think. Regards, Behcet > Isn't ND handled by the kernel in a lot of OSes? Does prefix delegation > really belong there? > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From aservin@lacnic.net Fri Oct 19 08:59:17 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE3C21F851E for ; Fri, 19 Oct 2012 08:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+-csyzdMfrm for ; Fri, 19 Oct 2012 08:59:17 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 1983F21F846F for ; Fri, 19 Oct 2012 08:59:17 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy (unknown [IPv6:2001:13c7:7001:5128:f53e:fa07:7542:77fd]) by mail.lacnic.net.uy (Postfix) with ESMTP id 50F7A308465 for ; Fri, 19 Oct 2012 13:59:05 -0200 (UYST) Message-ID: <508178C4.3090303@lacnic.net> Date: Fri, 19 Oct 2012 13:59:00 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: IPv6 modification suggestion References: <50758ba5.e956420a.71b1.6dbb@mx.google.com> <508060a0.42020e0a.3ead.ffff9089@mx.google.com> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 15:59:17 -0000 Ammar Agree with Albert. You are trying to add capabilities in the wrong layer. Regards, as On 18/10/2012 18:50, Manfredi, Albert E wrote: > I don't see any of this as being remotely desirable, as part of IETF standards. > > If a router is to be installed in a repressive country, then it is certainly possible to have whatever layer 3-7 filters implemented in that router, as just such filters are implemented in "firewalls." Or, if an Internet site wants to serve customers with special location-based apps, they can certainly do so without having to impact the IETF standards (either by requiring GPS input into the app, or by asking the user to provide his location). > > Or, if a group wants to develop a location-based routing protocol, they can certainly do so, without forcing this information to impact IETF standards. > > It just seems unwise, to say the least, to build this feature directly into layer 3 or 4 protocols, where it becomes ubiquitous, and where the user is not in control of it. > > Bert > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Ammar Salih > Sent: Thursday, October 18, 2012 4:04 PM > To: ipv6@ietf.org; geopriv@ietf.org > Subject: RE: IPv6 modification suggestion > > Hello everyone, I had a brief look at GEOPRIV and I was very much impressed, > There has been so much work done by this amazing group! > > At the same time, I would like to raise my concern regarding the http > location request which will not be detected by layer-3 devices (Routers), I > am anticipating that in the future, GPS capability will be added to the > router itself (just like smart phones) and packet marking and classification > based on geo-location will be required. > > QoS, firewall and routing based on geo-location will be highly demanded when > mobile routers move from one geo-location to another which has different > regulations/electronic laws. > > Here is an example, if your router is within city-X and this city has very > good electronic and copyright laws, then users will have relaxed network > security settings, but what if the very same router moved to city-Y which > according to its law, certain websites should be blocked (like facebook in > china for example) .. these rules based on geographic location won't be > feasible unless the mobile router has a GPS and can read/write coordinates > to layer-3 packets. > > Best, > Ammar > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From swmike@swm.pp.se Fri Oct 19 09:16:47 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E548821F851E for ; Fri, 19 Oct 2012 09:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5IaITZiZLPv for ; Fri, 19 Oct 2012 09:16:47 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3EB21F846F for ; Fri, 19 Oct 2012 09:16:47 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 857EA9C; Fri, 19 Oct 2012 18:16:45 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 7C5F89A; Fri, 19 Oct 2012 18:16:45 +0200 (CEST) Date: Fri, 19 Oct 2012 18:16:45 +0200 (CEST) From: Mikael Abrahamsson To: sarikaya@ieee.org Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt In-Reply-To: Message-ID: References: <5081087D.2020807@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alexandru Petrescu , IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 16:16:48 -0000 On Fri, 19 Oct 2012, Behcet Sarikaya wrote: > It is not just implementing that code in one node. DHCPv6-PD requires > Delegating Router on a DHCP server somewhere and then Requesting > Router on the edge router (there was a proposal to implement it on a > UE). I know of implementations that do this in a single box (local DHCPv6-PD address pool), so that's not a deciding argument as far as I can tell. > It is a system support issue, I think. Well, that's what I'm after, the actual rationale. In the document, as far as I could find, the only motivation for implenting PD in ND was "DHCPv6-PD might not be available". -- Mikael Abrahamsson email: swmike@swm.pp.se From oliver@8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa Fri Oct 19 09:42:46 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA8921F87F3 for ; Fri, 19 Oct 2012 09:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4dyMyB9YCzR for ; Fri, 19 Oct 2012 09:42:45 -0700 (PDT) Received: from mail.uptheinter.net (mail.uptheinter.net [IPv6:2001:470:9738::]) by ietfa.amsl.com (Postfix) with ESMTP id 7253D21F876D for ; Fri, 19 Oct 2012 09:42:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.uptheinter.net (Postfix) with ESMTP id 824B0A574E for ; Fri, 19 Oct 2012 17:42:44 +0100 (BST) X-DKIM: Sendmail DKIM Filter v2.7.2 mail.uptheinter.net 824B0A574E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa; s=default; t=1350664964; bh=xul R5yggrq+TRl3KDxEUOfEBj7w8Tz7pPZwfA/NA18A=; h=From:To:Subject:Date: Message-ID:MIME-Version:Content-Transfer-Encoding:Content-Type; b=VNCEtej/oO8WqT8WRYr/2lJ6YJify0ltym6wqXU60dYTc9WziAKPlpsNJFw3q3M08 kXQkLnD1eYHRowWrFhMKgf3O+GbDHxq2MXXAvkXupVTAkfCt0SxwJcotQrpRFJe68pn C2YXPV4cgxjMJ/6hg2Ts+GrVywWJGFtmYm1aOyg= X-Virus-Scanned: amavisd-new at Received: from mail.uptheinter.net ([127.0.0.1]) by localhost (vps2.uptheinter.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2EAsXBah_3f3 for ; Fri, 19 Oct 2012 17:42:37 +0100 (BST) From: Oliver To: ipv6@ietf.org Subject: Announcing Hashed SLND and other changes to draft-smith-6man-mitigate-nd-cache-dos-slnd Date: Fri, 19 Oct 2012 18:25:17 +0200 Message-ID: <2823118.ETXEjJL9LI@gentoovm> User-Agent: KMail/4.8.5 (Linux/3.4.11-4-zerolag-rt19+; KDE/4.8.5; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 16:42:46 -0000 Link for convenience: http://tools.ietf.org/html/draft-smith-6man-mitigate-nd- cache-dos-slnd-04 The following is a (non-exhaustive) overview of the changes: 1) Described Hashed SLND 2) Replaced TUSP with TUD 3) Clarified required & optional behaviour. 4) Expanded scope for SLND 5) fixed up a few nits. Comment and feedback most appreciated. Kind Regards, Oliver From albert.e.manfredi@boeing.com Fri Oct 19 12:50:43 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD1921F8836 for ; Fri, 19 Oct 2012 12:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZcRmH3htr0j for ; Fri, 19 Oct 2012 12:50:42 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3E721F880A for ; Fri, 19 Oct 2012 12:50:42 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9JJoZUF031482 for ; Fri, 19 Oct 2012 12:50:35 -0700 Received: from XCH-MWHT-01.mw.nos.boeing.com (xch-mwht-01.mw.nos.boeing.com [134.57.113.35]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9JJoYgM031454 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 19 Oct 2012 12:50:35 -0700 Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.118.180]) by XCH-MWHT-01.mw.nos.boeing.com ([134.57.113.35]) with mapi; Fri, 19 Oct 2012 14:50:34 -0500 From: "Manfredi, Albert E" To: Ammar Salih Date: Fri, 19 Oct 2012 14:50:33 -0500 Subject: RE: IPv6 modification suggestion Thread-Topic: IPv6 modification suggestion Thread-Index: Ac2nYb9+B2JU5/S2TjaXUBla9dpJ1wAGEG4wAXry01AAAosPsAAokdowAAfKMBA= Message-ID: References: <50758ba5.e956420a.71b1.6dbb@mx.google.com> <508060a0.42020e0a.3ead.ffff9089@mx.google.com> <50818d47.83c60e0a.466e.ffffb5e6@mx.google.com> In-Reply-To: <50818d47.83c60e0a.466e.ffffb5e6@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 19:50:44 -0000 > -----Original Message----- > From: Ammar Salih [mailto:ammar.salih@auis.edu.iq] > I remember few years ago when there were > sanctions on Iraq, people used to download software updates through > VSAT as > their IP address shows Germany or Netherlands. But I'm suggesting to you that most people in the IETF consider that to be = a "feature," not a "bug." If you wanted to take a consensus within the IETF= , I would bet that most would not want to facilitate the efforts of a coupl= e of well-known regimes today, to isolate their citizens from the Internet.= If, with today's protocols, these efforts are less than 100 percent effect= ive, I'm suggesting most people would consider that to be a "good thing." > I am suggesting to make locations more accurate and controlable through > OS > and network devices, exactly like IP addressess (user can change it's > IP > address and router can also modify the header information in case it's > required). Since you mention IP addresses, we have "privacy addresses" in IPv6 for exa= ctly this reason. Many feel that disclosing even something as seemingly inn= ocuous as your real MAC address, in IPv6 SLAAC, could be problematic, so it= is no longer mandatory to do so. So what I'm trying to get across is, these concerns are hardly new to the I= ETF. Bert From albert.e.manfredi@boeing.com Fri Oct 19 14:34:58 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B0A21F87D2 for ; Fri, 19 Oct 2012 14:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1gEoqNHSUkl for ; Fri, 19 Oct 2012 14:34:58 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id 650B521F87B2 for ; Fri, 19 Oct 2012 14:34:58 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9JLZ9CS026216 for ; Fri, 19 Oct 2012 14:35:09 -0700 Received: from XCH-MWHT-06.mw.nos.boeing.com (xch-mwht-06.mw.nos.boeing.com [134.57.113.166]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9JLZ72U025998 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 19 Oct 2012 14:35:08 -0700 Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.118.180]) by XCH-MWHT-06.mw.nos.boeing.com ([134.57.113.166]) with mapi; Fri, 19 Oct 2012 16:34:56 -0500 From: "Manfredi, Albert E" To: Ammar Salih Date: Fri, 19 Oct 2012 16:34:54 -0500 Subject: RE: IPv6 modification suggestion Thread-Topic: IPv6 modification suggestion Thread-Index: Ac2nYb9+B2JU5/S2TjaXUBla9dpJ1wAGEG4wAXry01AAAosPsAAokdowAAfKMBAAAV94oAACByxA Message-ID: References: <50758ba5.e956420a.71b1.6dbb@mx.google.com> <508060a0.42020e0a.3ead.ffff9089@mx.google.com> <50818d47.83c60e0a.466e.ffffb5e6@mx.google.com> <5081c0f6.e86db40a.5a38.ffffe8b2@mx.google.com> In-Reply-To: <5081c0f6.e86db40a.5a38.ffffe8b2@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 21:34:59 -0000 > -----Original Message----- > From: Ammar Salih [mailto:ammar.salih@auis.edu.iq] > It's not about supporting dictatorial regimes in isolating their > citizens > from the internet, Interesting how politics manages to enter into everything. It doesn't matter what the original intent might have been. Such schemes wo= uld immediately facilitate all manner of control that could, and undoubtedl= y would, easily be abused. Therefore, if precise location is to be provided= , this is best done in a way that can be switched off by the users. At the = application layer, for example. In the US, this same discussion occurred with respect to having GPS locatio= n provided by cell phones. Of course the intent was personal safety (e.g. l= ocation of individual if he dialed 911, the emergency number in the US). Ho= wever the feature could also easily be abused. Hence the debate. Users shou= ld be allowed control over that feature. > It's about implementing regulations, for example, > certain > regions does not allow VoIP calls over GSM/GPRS network. How is this a problem? If a phone is attempting to make a VoIP call and sen= d it through a cell tower that doesn't permit it, the call is dropped. If t= he user can walk a few minutes to be within range of a cell tower that perm= its VoIP, that should be allowed. Cell coverage is not wide enough to make = an issue of this. And, whatever cell service provider doesn't like VoIP wou= ld be free to not allow VoIP on that service provider's towers. > And it's not only filtering and restrictions, location-based Bandwidth > Management could mean (for the sake of example) you assign Bandwidth > based > on area population rather than router's uplink. I'm not sure what this means. Are you suggesting that if an individual ISP = decides to upgrade his network, the government could come in and prevent hi= m from offering the extra bandwidth, based on the location of specific user= s? I'm sorry, but again going to suggest that application layer solutions, = e.g. configuration settings by the ISP on each of its routers, would best b= e used in this case too. Whether or not there are sound, legitimate reasons to implement such precis= e user location solutions, this must not be done in such a way that it beco= mes so intrinsic to IPv6 that user control of the feature becomes necessari= ly removed. In my opinion, of course. Bert From ammar.salih@auis.edu.iq Fri Oct 19 10:26:38 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9D021F87D2 for ; Fri, 19 Oct 2012 10:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.856 X-Spam-Level: X-Spam-Status: No, score=-5.856 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+4EGtDDecrA for ; Fri, 19 Oct 2012 10:26:38 -0700 (PDT) Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with SMTP id A7B5F21F8793 for ; Fri, 19 Oct 2012 10:26:37 -0700 (PDT) Received: from mail-fa0-f70.google.com ([209.85.161.70]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKUIGNTQJiGV72wHG3D4OFP+7ThE/TfKmL@postini.com; Fri, 19 Oct 2012 10:26:37 PDT Received: by mail-fa0-f70.google.com with SMTP id v1so761869fav.1 for ; Fri, 19 Oct 2012 10:26:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=0G2kCN3QkJcZVb6cZj9RAS2ZV1MZKXL6kUe1t+9ZS2c=; b=kggOeWqtjlQl/BLWp5EeLCA5zsXTyGe3hWMZf4v9/2wGBv8eZhBjeUS2PDV+H2PRTA 7DI/LpgzZnPOFbjvfMZt5ZFSgENe9VpIAwjWsXB8EEKhqVVwjQRwRvVXzHk+OQhz61o4 oI4rz9F9UMmyp9Xsh7iZUHxvjIGeMTiBewQes8Dq3mmBUHJ/MAGSmsCymgaZv8Ahr19T FFV2Pl5ggkPAGhVwzCt65t++1eKYc5/lOmhi7CPin97H8X3Dvjm+XD4BnqVw5S7mEPBO w+Ra/Ntf8wUBwWM24P0Mj18lA3D1Jch2HIZayHUCHzs+WC1NeAattm3bqP62gJseqdyG GdSw== Received: by 10.14.175.71 with SMTP id y47mr2934368eel.36.1350667595714; Fri, 19 Oct 2012 10:26:35 -0700 (PDT) Received: by 10.14.175.71 with SMTP id y47mr2934363eel.36.1350667595570; Fri, 19 Oct 2012 10:26:35 -0700 (PDT) Received: from AMMARSALIH ([95.159.78.55]) by mx.google.com with ESMTPS id v3sm3602388een.1.2012.10.19.10.26.29 (version=SSLv3 cipher=OTHER); Fri, 19 Oct 2012 10:26:31 -0700 (PDT) From: "Ammar Salih" To: "'Manfredi, Albert E'" References: <50758ba5.e956420a.71b1.6dbb@mx.google.com> <508060a0.42020e0a.3ead.ffff9089@mx.google.com> In-Reply-To: Subject: RE: IPv6 modification suggestion Date: Fri, 19 Oct 2012 20:26:23 +0300 Message-ID: <50818d47.83c60e0a.466e.ffffb5e6@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2nYb9+B2JU5/S2TjaXUBla9dpJ1wAGEG4wAXry01AAAosPsAAokdow Content-Language: en-us X-Gm-Message-State: ALoCoQlyPt6PclBDOjhM8ZN/dwmIQe30KjdXkMEeeesbkwq8k4ICx1VNujRkVIGz7DsWxVsQ2z7LmJaJJxhEy9cXy+wY8YE6uAONw9YRCxGcXmcgTDI5oGgtBVTWucHk6oxtU4zlzo0M X-Mailman-Approved-At: Fri, 19 Oct 2012 16:49:12 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 17:26:38 -0000 Hello Albert, > If a router is to be installed in a repressive country, then it is certainly possible to have whatever layer 3-7 filters implemented in that router, as just such filters are implemented in "firewalls." Or, if an Internet site wants to serve customers with special location-based apps, they can certainly do so without having to impact the IETF standards (either by requiring GPS input into the app, or by asking the user to provide his location). How would you know if a mobile router crossed the city or country boarders, so you can change the "firewall" rules? it could be very short distance in terms of physical locations and defiantly won't be reflected on topology. and it's not about firewalls in repressive countries, it's about classification and marking where you can implement location-based policies like QoS, ACL, routing .. etc. > It just seems unwise, to say the least, to build this feature directly into layer 3 or 4 protocols, where it becomes ubiquitous, and where the user is not in control of it. Today locations are assigned to IP addresses without user awareness or control, everytime I do ip-lookup query I find myself in a different city because I am connected to a different ISP which has it's IP subnet registered to a different area. I remember few years ago when there were sanctions on Iraq, people used to download software updates through VSAT as their IP address shows Germany or Netherlands. I am suggesting to make locations more accurate and controlable through OS and network devices, exactly like IP addressess (user can change it's IP address and router can also modify the header information in case it's required). > Or, if a group wants to develop a location-based routing protocol, they can certainly do so, without forcing this information to impact IETF standards. I totally understand, appreciate and highly recognize your efforts to safeguard IETF standards, i wish you guys the best of luck and looking forward to see more promissing projects. Thank you, Ammar -----Original Message----- From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] Sent: Thursday, October 18, 2012 11:51 PM To: Ammar Salih; ipv6@ietf.org Subject: RE: IPv6 modification suggestion I don't see any of this as being remotely desirable, as part of IETF standards. If a router is to be installed in a repressive country, then it is certainly possible to have whatever layer 3-7 filters implemented in that router, as just such filters are implemented in "firewalls." Or, if an Internet site wants to serve customers with special location-based apps, they can certainly do so without having to impact the IETF standards (either by requiring GPS input into the app, or by asking the user to provide his location). Or, if a group wants to develop a location-based routing protocol, they can certainly do so, without forcing this information to impact IETF standards. It just seems unwise, to say the least, to build this feature directly into layer 3 or 4 protocols, where it becomes ubiquitous, and where the user is not in control of it. Bert -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Ammar Salih Sent: Thursday, October 18, 2012 4:04 PM To: ipv6@ietf.org; geopriv@ietf.org Subject: RE: IPv6 modification suggestion Hello everyone, I had a brief look at GEOPRIV and I was very much impressed, There has been so much work done by this amazing group! At the same time, I would like to raise my concern regarding the http location request which will not be detected by layer-3 devices (Routers), I am anticipating that in the future, GPS capability will be added to the router itself (just like smart phones) and packet marking and classification based on geo-location will be required. QoS, firewall and routing based on geo-location will be highly demanded when mobile routers move from one geo-location to another which has different regulations/electronic laws. Here is an example, if your router is within city-X and this city has very good electronic and copyright laws, then users will have relaxed network security settings, but what if the very same router moved to city-Y which according to its law, certain websites should be blocked (like facebook in china for example) .. these rules based on geographic location won't be feasible unless the mobile router has a GPS and can read/write coordinates to layer-3 packets. Best, Ammar From ammar.salih@auis.edu.iq Fri Oct 19 14:07:07 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490F421F8753 for ; Fri, 19 Oct 2012 14:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.887 X-Spam-Level: X-Spam-Status: No, score=-5.887 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKotU+dqg300 for ; Fri, 19 Oct 2012 14:07:06 -0700 (PDT) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by ietfa.amsl.com (Postfix) with SMTP id 7006C21F8742 for ; Fri, 19 Oct 2012 14:07:06 -0700 (PDT) Received: from mail-ee0-f70.google.com ([74.125.83.70]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKUIHA+ROORPIyW0+ccCLQidZ25r0nAd/P@postini.com; Fri, 19 Oct 2012 14:07:06 PDT Received: by mail-ee0-f70.google.com with SMTP id b57so883373eek.1 for ; Fri, 19 Oct 2012 14:07:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=9MvLBGYkXCvVodIpXWcVJEV2McF0+OCyC8xudK7XRXs=; b=knG7n9ylq83R3TgkuykMWAhIYh7mlKkYOXAKwUKdxoxsp3aBUF4AKSEkN1O4CCPsJw AuANGQfLdchLuNiBSQqC7bwmYgjYyoSdd+Waape4hvRDhCwQnTVEzWm8X8HwFr5LL9Lc BK762CzAV5T3l2ypd8Ut4SZEzk2yFwz6hrt9aFNVZ1c/tElQdg8UmZ7aFmVX1NUCGzGE iDSpl2vXn9THvHTia12TtgrOZ55mJnoax72t4WawMFxzPEeIGp2HPyQ/sDGOYGbnXMzW 3c14n1uUIx5SNat6aepVCNk55nMx2EFKlpE7H/PbDDYLDcpRC2bkQH4ThMOU18pff3hO a3nw== Received: by 10.216.26.138 with SMTP id c10mr1548413wea.76.1350680824609; Fri, 19 Oct 2012 14:07:04 -0700 (PDT) Received: by 10.216.26.138 with SMTP id c10mr1548410wea.76.1350680824469; Fri, 19 Oct 2012 14:07:04 -0700 (PDT) Received: from AMMARSALIH ([95.159.78.55]) by mx.google.com with ESMTPS id hv8sm3046486wib.0.2012.10.19.14.07.00 (version=SSLv3 cipher=OTHER); Fri, 19 Oct 2012 14:07:02 -0700 (PDT) From: "Ammar Salih" To: "'Manfredi, Albert E'" References: <50758ba5.e956420a.71b1.6dbb@mx.google.com> <508060a0.42020e0a.3ead.ffff9089@mx.google.com> <50818d47.83c60e0a.466e.ffffb5e6@mx.google.com> In-Reply-To: Subject: RE: IPv6 modification suggestion Date: Sat, 20 Oct 2012 00:06:54 +0300 Message-ID: <5081c0f6.e86db40a.5a38.ffffe8b2@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2nYb9+B2JU5/S2TjaXUBla9dpJ1wAGEG4wAXry01AAAosPsAAokdowAAfKMBAAAV94oA== Content-Language: en-us X-Gm-Message-State: ALoCoQkhpkrzbEprEUtyynBY/ploI7/VrWnkBYeQRwhnj1mLNk8ODDIqO7gzH+GvdhNjXMwwvAy+8l4Lny/jqR791r26IwWRVZt5WAfIIMT27II1E0qWXVxz+eYsC5h7TOSCzwJmymzq X-Mailman-Approved-At: Fri, 19 Oct 2012 16:49:12 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 21:07:07 -0000 > -----Original Message----- > From: Ammar Salih [mailto:ammar.salih@auis.edu.iq] > But I'm suggesting to you that most people in the IETF consider that to be > a "feature," not a "bug." If you wanted to take a consensus within the > IETF, I would bet that most would not want to facilitate the efforts of a > couple of well-known regimes today, to isolate their citizens from the > Internet. If, with today's protocols, these efforts are less than 100 > percent effective, I'm suggesting most people would consider that to be a > "good thing." It's not about supporting dictatorial regimes in isolating their citizens from the internet, It's about implementing regulations, for example, certain regions does not allow VoIP calls over GSM/GPRS network. And it's not only filtering and restrictions, location-based Bandwidth Management could mean (for the sake of example) you assign Bandwidth based on area population rather than router's uplink. Many applications will be supporting the feature differently (like http://tools.ietf.org/html/rfc6442 ), then one day it will be much easier to unify them and have the feature in the IP header. > Since you mention IP addresses, we have "privacy addresses" in IPv6 for > exactly this reason. Many feel that disclosing even something as seemingly > innocuous as your real MAC address, in IPv6 SLAAC, could be problematic, so > it is no longer mandatory to do so. I don't see why "privacy addresses" is mentioned here, I am 100% with users privacy and suggesting that they have more control over a more accurate details (locations)... such details that they are not allowed to control in the current setup. Thank you, Ammar From ammar.salih@auis.edu.iq Fri Oct 19 15:19:15 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C3521F865F for ; Fri, 19 Oct 2012 15:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.653 X-Spam-Level: X-Spam-Status: No, score=-5.653 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZCcDQKRJW7U for ; Fri, 19 Oct 2012 15:19:14 -0700 (PDT) Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) by ietfa.amsl.com (Postfix) with SMTP id 95DBB21F865C for ; Fri, 19 Oct 2012 15:19:14 -0700 (PDT) Received: from mail-pb0-f70.google.com ([209.85.160.70]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKUIHR4ZLHvsw4SI5KKaNXesz9KN9XntbS@postini.com; Fri, 19 Oct 2012 15:19:14 PDT Received: by mail-pb0-f70.google.com with SMTP id rp16so3008162pbb.1 for ; Fri, 19 Oct 2012 15:19:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=i+wUz4rotUebrYZ2Td16szfXcwHMLyDyJGeChGF1BfM=; b=Kalmn2cnBLNY1dlnGRhzjzTA8sGX+2bDNoZ2aMI0DgqZWqawYiJSiDIzbHJUgsiY9E vGXBAmZXxmXccxj00xiYaCSFDMYMCwQ65w/NvjTCUCQX9O57aYWhEuq6YdQ3pPKE+R7g QtF4AbrTrdyPj5pRm64UzB//91yoIZYuEJuJ8DbG5LKnZHc5losCBRB2kUOj9A6QjLTT P7wOiT3wpGj45lrMqNzspmo7gk0Kl7ZijmmZxuN60UX6WVbcd5M5g9SUQ5wG8/DRzC+1 COH0sL/mdYnnnMEEAnueVcJ6Fy0t/muzAngHoi/6NVjo6UFH2uCbS3PgJkhFl+meDAIE tIIg== Received: by 10.66.90.33 with SMTP id bt1mr7432166pab.49.1350685150079; Fri, 19 Oct 2012 15:19:10 -0700 (PDT) Received: by 10.66.90.33 with SMTP id bt1mr7431993pab.49.1350685148195; Fri, 19 Oct 2012 15:19:08 -0700 (PDT) Received: from AMMARSALIH ([46.30.226.16]) by mx.google.com with ESMTPS id qd9sm1821891pbb.31.2012.10.19.15.19.02 (version=SSLv3 cipher=OTHER); Fri, 19 Oct 2012 15:19:06 -0700 (PDT) From: "Ammar Salih" To: "'Manfredi, Albert E'" References: <50758ba5.e956420a.71b1.6dbb@mx.google.com> <508060a0.42020e0a.3ead.ffff9089@mx.google.com> <50818d47.83c60e0a.466e.ffffb5e6@mx.google.com> <5081c0f6.e86db40a.5a38.ffffe8b2@mx.google.com> In-Reply-To: Subject: RE: IPv6 modification suggestion Date: Sat, 20 Oct 2012 01:18:54 +0300 Message-ID: <5081d1da.e988440a.6dbb.ffffaef8@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2nYb9+B2JU5/S2TjaXUBla9dpJ1wAGEG4wAXry01AAAosPsAAokdowAAfKMBAAAV94oAACByxAAAEbLrA= Content-Language: en-us X-Gm-Message-State: ALoCoQnpdYbJeGNnZia4fAuZnxIXfxLJR8MnPUkFdOlRh23Aoj62iTNduXpWghYRWG+9zGkL54Bxzyla8K/pvXKEDS4zqqf8Fk6CJC+WD96q2GuQSG0oYwEJjcTVePmc23gITMeLfVrc X-Mailman-Approved-At: Fri, 19 Oct 2012 16:49:12 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 22:19:15 -0000 > -----Original Message----- > From: Ammar Salih [mailto:ammar.salih@auis.edu.iq] > this is best done in a way that can be switched off by the users. At the application layer. I totally agree, but again, application layer will be limited to application servers. Network devices won't be able to understand the feature. > How is this a problem? If a phone is attempting to make a VoIP call and send it through a cell tower > that doesn't permit it, the call is dropped. If the user can walk a few minutes to be within range of a > cell tower that permits VoIP, that should be allowed. Cell coverage is not wide enough to make an issue > of this. And, whatever cell service provider doesn't like VoIP would be free to not allow VoIP on that > service provider's towers. It does not allow VoIP calls according to "operation license" which is based on city, state or region regulations .. my suggestion is that the tower moves not the user.. search for mobile BTS. It happens in certain occasions where hundreds of thousands of people head to the same area at the same time to attend some sort of event, so operators move mobile BTSs to the location of the event for a day or two... in this case the operator needs to put configuration that reflects the agreement with the state/city or region .. it could be much easier if geo-location is involved in the game, not at the user's end but only between routers. > I'm not sure what this means. Are you suggesting that if an individual ISP decides to upgrade his > network, the government could come in and prevent him from offering the extra bandwidth, based on the > location of specific users? I'm sorry, but again going to suggest that application layer solutions, e.g. > configuration settings by the ISP on each of its routers, would best be used in this case too. Nope, I am assuming that the operator could manage bandwidth based on estimated population, static configuration on the router would be ideal if the router is fixed, but what if the router is mobile. Ammar From george+ipng@m5p.com Fri Oct 19 17:32:36 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B0921F8864 for ; Fri, 19 Oct 2012 17:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5mRWlTp04TP for ; Fri, 19 Oct 2012 17:32:35 -0700 (PDT) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by ietfa.amsl.com (Postfix) with ESMTP id B14E821F8840 for ; Fri, 19 Oct 2012 17:32:35 -0700 (PDT) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id q9K0WRXV041192 for ; Fri, 19 Oct 2012 20:32:32 -0400 (EDT) (envelope-from george+ipng@m5p.com) Message-ID: <5081F11B.3040009@m5p.com> Date: Fri, 19 Oct 2012 20:32:27 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120923 Thunderbird/15.0.1 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: IPv6 modification suggestion References: <50758ba5.e956420a.71b1.6dbb@mx.google.com> <508060a0.42020e0a.3ead.ffff9089@mx.google.com> <50818d47.83c60e0a.466e.ffffb5e6@mx.google.com> <5081c0f6.e86db40a.5a38.ffffe8b2@mx.google.com> In-Reply-To: <5081c0f6.e86db40a.5a38.ffffe8b2@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.24 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Fri, 19 Oct 2012 20:32:33 -0400 (EDT) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 00:32:36 -0000 On 10/19/12 17:06, Ammar Salih wrote: >>[...] > It's not about supporting dictatorial regimes in isolating their citizens > from the internet, It's about implementing regulations, for example, certain > regions does not allow VoIP calls over GSM/GPRS network. > [...] You would probably have more success implementing a regulation that everybody be healthy and prosperous. -- George Mitchell From steenjj@gmail.com Fri Oct 19 19:24:56 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35E8021F85BA for ; Fri, 19 Oct 2012 19:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.053 X-Spam-Level: X-Spam-Status: No, score=-2.053 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joo86zalE0Bv for ; Fri, 19 Oct 2012 19:24:55 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9C68821F85B3 for ; Fri, 19 Oct 2012 19:24:55 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so1307364vcb.31 for ; Fri, 19 Oct 2012 19:24:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=OJwy2PtCY4FMYGIx9sb50k97M7gApM9efcj9QxioTjc=; b=IRvx2q3xVxE9Tzjsi/jXCUHvu7qt1UPCt/ePpj3gx2jAWAQiDlRWO2m6ZRRK7frLET hdElk1viPvubHVdKppjbUDlQG/fZ3J4o6/G6vz1frGsmUsTnETs8xzuoIbNPxv1/dMu7 CZL8hMcMxp+x+YKRE/DA7rop14eHW+zrSuEaNrQMuKkqggzHBUfPdqeNAO2C1oYYa4c6 o1CpYbFsp4FuGHIL6jg9j5bzrBlAi13MKN8/rWSDNxzIW2T3X/FYfRblIaM18onft0CW BRd6rITkIZplExlruBo00KIZwOKyDJ7c4qUws4q42CausQaMZ5+VIQPuYrtnf9sRccmG t8pQ== Received: by 10.220.38.73 with SMTP id a9mr3989880vce.72.1350699895004; Fri, 19 Oct 2012 19:24:55 -0700 (PDT) Received: from [10.198.142.78] (mobile-198-228-205-219.mycingular.net. [198.228.205.219]) by mx.google.com with ESMTPS id w10sm3038087vef.5.2012.10.19.19.24.53 (version=SSLv3 cipher=OTHER); Fri, 19 Oct 2012 19:24:54 -0700 (PDT) References: <50758ba5.e956420a.71b1.6dbb@mx.google.com> <508060a0.42020e0a.3ead.ffff9089@mx.google.com> <50818d47.83c60e0a.466e.ffffb5e6@mx.google.com> <5081c0f6.e86db40a.5a38.ffffe8b2@mx.google.com> <5081F11B.3040009@m5p.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5081F11B.3040009@m5p.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <345B00B7-0771-4070-86EB-FE5C50CBEDB0@gmail.com> X-Mailer: iPhone Mail (10A403) From: Jon Steen Subject: Re: IPv6 modification suggestion Date: Fri, 19 Oct 2012 22:24:45 -0400 To: George Mitchell Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 02:24:56 -0000 Agreed! I know very well of customer ISPs and large independent enterprise n= etwork customers that one, would not accept this and two, since they have th= eir own address space this would FAIL! Sent from my iPhone On Oct 19, 2012, at 8:32 PM, George Mitchell wrote: > On 10/19/12 17:06, Ammar Salih wrote: >>> [...] >> It's not about supporting dictatorial regimes in isolating their citizens= >> from the internet, It's about implementing regulations, for example, cert= ain >> regions does not allow VoIP calls over GSM/GPRS network. >> [...] > You would probably have more success implementing a regulation that > everybody be healthy and prosperous. -- George Mitchell > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From alexandru.petrescu@gmail.com Sat Oct 20 08:39:06 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D5121F86A1 for ; Sat, 20 Oct 2012 08:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.096 X-Spam-Level: X-Spam-Status: No, score=-0.096 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUPsZ37K0oNt for ; Sat, 20 Oct 2012 08:39:05 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id CC7D021F8452 for ; Sat, 20 Oct 2012 08:39:00 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 62570940005; Sat, 20 Oct 2012 17:38:53 +0200 (CEST) Message-ID: <5082C58C.6040008@gmail.com> Date: Sat, 20 Oct 2012 17:38:52 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Mikael Abrahamsson Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt References: <5081087D.2020807@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 121020-0, 20/10/2012), Outbound message X-Antivirus-Status: Clean Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 15:39:06 -0000 Le 19/10/2012 10:08, Mikael Abrahamsson a écrit : > On Fri, 19 Oct 2012, Alexandru Petrescu wrote: > >> Comments about the idea in this draft? About the problem? > > What is the rationale for duplicating the functionality in DHCPv6-PD > into ND? If code needs to be changed, why can't that code change be > to implement existing standard instead of implementing a new > standard? Well, as you say below it depends on the software availability on various platforms and contexts. To such a generic question I could only say that in some setting ND is preferred over DHCP but still prefix delegation is needed. > Isn't ND handled by the kernel in a lot of OSes? Does prefix > delegation really belong there? Right, parts of ND are handled in kernel in most OSes. But one key part that would need to be modified is RA and that is userspace. In linux that means mainly radvd, and curiously enough that lacks RS which is mostly kernel. So, instead of preferring DHCP one may bring RS out of kernel into radvd (a so called 'rsadvd'). At that point it's relatively easier to do Prefix Delegation with ND than with DHCP, implementation-wise, not least because code is smaller. Where does PD belong - to DHCP or ND is a long discussion and I'll be happy to take part if it happens. ND to assign _full_ addresses (instead of just beaconing a prefix) is something to which there was opposition but which also got RFC'ed. If that happened then why not prefixes as well. If the discussion turns about which use case, then also I can provide description about the use case - it's mostly in vehicular environments. Listening. Alex > From alexandru.petrescu@gmail.com Sat Oct 20 08:43:22 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDECD21F85CF for ; Sat, 20 Oct 2012 08:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.121 X-Spam-Level: X-Spam-Status: No, score=-0.121 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5dIkAWRVCAL for ; Sat, 20 Oct 2012 08:43:22 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 49A2C21F85B6 for ; Sat, 20 Oct 2012 08:43:20 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 21CD49400CE; Sat, 20 Oct 2012 17:43:14 +0200 (CEST) Message-ID: <5082C691.4090902@gmail.com> Date: Sat, 20 Oct 2012 17:43:13 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Philipp Kern Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt References: <5081087D.2020807@gmail.com> <20121019082213.GA14631@spike.0x539.de> In-Reply-To: <20121019082213.GA14631@spike.0x539.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 121020-0, 20/10/2012), Outbound message X-Antivirus-Status: Clean Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 15:43:23 -0000 Le 19/10/2012 10:22, Philipp Kern a écrit : > Mikael, > > am Fri, Oct 19, 2012 at 10:08:39AM +0200 hast du folgendes > geschrieben: >> On Fri, 19 Oct 2012, Alexandru Petrescu wrote: >>> Comments about the idea in this draft? About the problem? >> What is the rationale for duplicating the functionality in >> DHCPv6-PD into ND? If code needs to be changed, why can't that code >> change be to implement existing standard instead of implementing a >> new standard? >> >> Isn't ND handled by the kernel in a lot of OSes? Does prefix >> delegation really belong there? > > that reminds me of the RA/DHCPv6 for DNS recursor host configuration > in RFC4339, which provides advantages/disadvantages for shipping > this information by RDNSS vs. DHCPv6. I agree. There is a certain similarity. And there still exist parameters exclusively configured by DHCP while others exclusive to ND (MTU, printers, more). As long as they exist trend will push to do at one what the other does. (let me add that I received a couple of private emails questioning the necessity of ND PD even for vehicular environments, and citing ND PD similar work some of which we still need to cite in our draft. I replied privately but I am open to discussion on the mailing list as well.) Listening. Alex > > Kind regards Philipp Kern > From alexandru.petrescu@gmail.com Sat Oct 20 08:47:03 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7EC21F85B6 for ; Sat, 20 Oct 2012 08:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.133 X-Spam-Level: X-Spam-Status: No, score=-0.133 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFE7My9XxPwx for ; Sat, 20 Oct 2012 08:47:03 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 11E7C21F886A for ; Sat, 20 Oct 2012 08:46:55 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 97AAC940101; Sat, 20 Oct 2012 17:46:49 +0200 (CEST) Message-ID: <5082C768.6000802@gmail.com> Date: Sat, 20 Oct 2012 17:46:48 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: sarikaya@ieee.org Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt References: <5081087D.2020807@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 121020-0, 20/10/2012), Outbound message X-Antivirus-Status: Clean Cc: IPv6 , Behcet Sarikaya X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 15:47:03 -0000 Le 19/10/2012 17:50, Behcet Sarikaya a écrit : > Hi Mikael, > > On Fri, Oct 19, 2012 at 3:08 AM, Mikael Abrahamsson > wrote: >> On Fri, 19 Oct 2012, Alexandru Petrescu wrote: >> >>> Comments about the idea in this draft? About the problem? >> >> >> What is the rationale for duplicating the functionality in >> DHCPv6-PD into ND? If code needs to be changed, why can't that code >> change be to implement existing standard instead of implementing a >> new standard? >> > > It is not just implementing that code in one node. DHCPv6-PD > requires Delegating Router on a DHCP server somewhere and then > Requesting Router on the edge router (there was a proposal to > implement it on a UE). > > It is a system support issue, I think. I tend to agree. I also work in a perspective where it is hard to say today which particular feature will future ND and future DHCP support, especially in vehicular environments. In this sense, intelligent mechanisms may be needed for an arbitrary vehicle to decide what kind of protocol to use when facing another vehicle ready to provide it a default route and maybe a prefix: try first ND, then DHCP... or similar logic. However, as much as I consider a system issue and appreciate the value of an algorithm implementing it, it may be the case that no real protocol work could be documented in an Internet Draft about such system issue. Just some thoughts. Alex > > Regards, > > Behcet >> Isn't ND handled by the kernel in a lot of OSes? Does prefix >> delegation really belong there? >> >> -- Mikael Abrahamsson email: swmike@swm.pp.se >> >> -------------------------------------------------------------------- >> >> IETF IPv6 working group mailing list >> ipv6@ietf.org Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > From alexandru.petrescu@gmail.com Sat Oct 20 08:54:59 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6383821F8472 for ; Sat, 20 Oct 2012 08:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+kpq73ZOnBh for ; Sat, 20 Oct 2012 08:54:59 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 20A0221F8467 for ; Sat, 20 Oct 2012 08:54:55 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id BD60094013A; Sat, 20 Oct 2012 17:54:49 +0200 (CEST) Message-ID: <5082C948.3080109@gmail.com> Date: Sat, 20 Oct 2012 17:54:48 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Mikael Abrahamsson Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt References: <5081087D.2020807@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 121020-0, 20/10/2012), Outbound message X-Antivirus-Status: Clean Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 15:54:59 -0000 Le 19/10/2012 18:16, Mikael Abrahamsson a écrit : > On Fri, 19 Oct 2012, Behcet Sarikaya wrote: > >> It is not just implementing that code in one node. DHCPv6-PD >> requires Delegating Router on a DHCP server somewhere and then >> Requesting Router on the edge router (there was a proposal to >> implement it on a UE). > > I know of implementations that do this in a single box (local > DHCPv6-PD address pool), so that's not a deciding argument as far as > I can tell. > >> It is a system support issue, I think. > > Well, that's what I'm after, the actual rationale. In the document, > as far as I could find, the only motivation for implenting PD in ND > was "DHCPv6-PD might not be available". One point that guided towards choosing ND over DHCP is topology. DHCP topology can be relatively complex with Client/Relay/Server, whereas ND is simpler one-on-one. In a setting with an IV (Internet Vehicle, with SIM card) and an LV (Leaf Vehicle, no SIM card) the IV needs to run a DHCP Client to obtain a prefix for its devices, because LTE only uses DHCP for PD. Then, if LV requests a prefix from IV then IV should be able to run DHCP Relay (or DHCP Server) as well. This makes IV to must support both Client _and_ Relay (or Server). This may be feasible in practice but I think it would be cleaner to have distinct protocols on a same machine for receiving a prefix and for sending a prefix. That's one aspect which led to this. There is also the question of availability of DHCP software on smaller platforms which have no SIM card. It may be easier to do this with ND in smaller settings. Alex > From sthaug@nethelp.no Sat Oct 20 09:36:31 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4128D21F84F3 for ; Sat, 20 Oct 2012 09:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRzh8uDzkNXK for ; Sat, 20 Oct 2012 09:36:30 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 4488A21F8491 for ; Sat, 20 Oct 2012 09:36:29 -0700 (PDT) Received: (qmail 48093 invoked from network); 20 Oct 2012 16:36:28 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 20 Oct 2012 16:36:28 -0000 Date: Sat, 20 Oct 2012 18:36:28 +0200 (CEST) Message-Id: <20121020.183628.74709756.sthaug@nethelp.no> To: alexandru.petrescu@gmail.com Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt From: sthaug@nethelp.no In-Reply-To: <5082C948.3080109@gmail.com> References: <5082C948.3080109@gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 16:36:31 -0000 > There is also the question of availability of DHCP software on smaller > platforms which have no SIM card. It may be easier to do this with ND > in smaller settings. The obvious conclusion to this argument is that a *lot* of DHCP functionality will be duplicated in ND. Is this where we want to go? I'm coming from the DHCP side of the argument. In my world DHCP is needed because it gives you a single place to handle dynamic address allocation, *and* it ties in with all sorts of support & backend systems. I am against adding lots of new ND functionality until we have DHCPv6 that is considerably more feature complete. Some of this is probably coming (client MAC address), some of it is still being opposed for mostly religious reasons (e.g. running DHCP without RA). Steinar Haug, AS 2116 From swmike@swm.pp.se Sat Oct 20 09:36:49 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FD121F869A for ; Sat, 20 Oct 2012 09:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5hO3zWz2S3s for ; Sat, 20 Oct 2012 09:36:48 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id F3B5F21F8680 for ; Sat, 20 Oct 2012 09:36:39 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 2E0419C; Sat, 20 Oct 2012 18:36:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2A5B69A; Sat, 20 Oct 2012 18:36:37 +0200 (CEST) Date: Sat, 20 Oct 2012 18:36:37 +0200 (CEST) From: Mikael Abrahamsson To: Alexandru Petrescu Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt In-Reply-To: <5082C58C.6040008@gmail.com> Message-ID: References: <5081087D.2020807@gmail.com> <5082C58C.6040008@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 16:36:49 -0000 On Sat, 20 Oct 2012, Alexandru Petrescu wrote: > Right, parts of ND are handled in kernel in most OSes. But one key part > that would need to be modified is RA and that is userspace. In linux > that means mainly radvd, and curiously enough that lacks RS which is > mostly kernel. Sending of RA is userspace, reception of RA is kernel. > So, instead of preferring DHCP one may bring RS out of kernel into radvd > (a so called 'rsadvd'). At that point it's relatively easier to do > Prefix Delegation with ND than with DHCP, implementation-wise, not least > because code is smaller. Why is it easier? Also, I'd imagine there are already implementations of DHCPv6-PD available under quite permissive licenses, instead of what you're proposing which requires everybody to develop new code. > Where does PD belong - to DHCP or ND is a long discussion and I'll be > happy to take part if it happens. For me, this is that discussion. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Sat Oct 20 09:42:30 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B79121F86E1 for ; Sat, 20 Oct 2012 09:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8v8syQg85eF for ; Sat, 20 Oct 2012 09:42:30 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id EC71621F8630 for ; Sat, 20 Oct 2012 09:42:29 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A80999C; Sat, 20 Oct 2012 18:42:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A18289A; Sat, 20 Oct 2012 18:42:28 +0200 (CEST) Date: Sat, 20 Oct 2012 18:42:28 +0200 (CEST) From: Mikael Abrahamsson To: Alexandru Petrescu Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt In-Reply-To: <5082C948.3080109@gmail.com> Message-ID: References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 16:42:30 -0000 On Sat, 20 Oct 2012, Alexandru Petrescu wrote: > One point that guided towards choosing ND over DHCP is topology. DHCP > topology can be relatively complex with Client/Relay/Server, whereas ND > is simpler one-on-one. There is nothing saying DHCPv6-PD can't be done in a single device (the router itself). That's what I do in my home, cisco router, local DHCPv6-PD pool, local DHCPv6-PD server, also installing routes into RIB. > _and_ Relay (or Server). This may be feasible in practice but I think > it would be cleaner to have distinct protocols on a same machine for > receiving a prefix and for sending a prefix. What is cleaner is to use existing standards where there already is running code. > There is also the question of availability of DHCP software on smaller > platforms which have no SIM card. It may be easier to do this with ND > in smaller settings. I'd imagine that there already are 2-3 existing FOSS available implementations that do what you need for DHCPv6-PD client and server. Instead you want to invent a new standard and create new code. I'm not saying this shouldn't be done, I'm just saying I don't really see the rationale for it. I used to hate DHCPv6 role in IPv6, but after a few years of being exposed to it, I've come to accept that this is the way it is. There is code going back to a standard Windows Vista that correctly implements DHCPv6-PD client, and that is what, 5-6 years ago it was released? I've had PD in my home on Cisco code for 3-5 years already, with no server infrastructure at all, just single device doing "everything" for the role needed. If this was 2002, I'd agree with you that ND PD could be feasable, but I believe the train has already left the station and we should focus on keeping IPv6 stable when it comes to how it works, and get implementations going, not new standards. -- Mikael Abrahamsson email: swmike@swm.pp.se From alexandru.petrescu@gmail.com Sat Oct 20 10:56:38 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA73F21F88EB for ; Sat, 20 Oct 2012 10:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.08 X-Spam-Level: X-Spam-Status: No, score=0.08 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKh4DR2IERqe for ; Sat, 20 Oct 2012 10:56:37 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 9894A21F88EC for ; Sat, 20 Oct 2012 10:56:35 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 211549401A5; Sat, 20 Oct 2012 19:56:29 +0200 (CEST) Message-ID: <5082E5CC.90502@gmail.com> Date: Sat, 20 Oct 2012 19:56:28 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: sthaug@nethelp.no Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt References: <5082C948.3080109@gmail.com> <20121020.183628.74709756.sthaug@nethelp.no> In-Reply-To: <20121020.183628.74709756.sthaug@nethelp.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 121020-0, 20/10/2012), Outbound message X-Antivirus-Status: Clean Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 17:56:38 -0000 Le 20/10/2012 18:36, sthaug@nethelp.no a écrit : >> There is also the question of availability of DHCP software on >> smaller platforms which have no SIM card. It may be easier to do >> this with ND in smaller settings. > > The obvious conclusion to this argument is that a *lot* of DHCP > functionality will be duplicated in ND. Is this where we want to go? I guess yes, and vice-versa. > I'm coming from the DHCP side of the argument. In my world DHCP is > needed because it gives you a single place to handle dynamic address > allocation, *and* it ties in with all sorts of support & backend > systems. Well yes, when that backend is a fixed infrastructure with things planned, highly human assisted. But in a dynamic yet simple network (without assistance of various backend) it's hard to use DHCP: a Relay can't 'discover' a Server, a Relay can hardly become a Server upon network change, etc. > I am against adding lots of new ND functionality until we have DHCPv6 > that is considerably more feature complete. Some of this is probably > coming (client MAC address), some of it is still being opposed for > mostly religious reasons (e.g. running DHCP without RA). As a side note, running DHCP without RA has significant advantages in machine-class devices. The memory constraint may lead to select one among the two to implement, not the two in the same small memory. In the same class, one may also prefer _just_ ND; but it does not give it enough functionality to establish IP. Alex > > Steinar Haug, AS 2116 > From alexandru.petrescu@gmail.com Sat Oct 20 11:01:45 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A077121F89B9 for ; Sat, 20 Oct 2012 11:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.052 X-Spam-Level: X-Spam-Status: No, score=0.052 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYsjTHJtGI0t for ; Sat, 20 Oct 2012 11:01:44 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 696B721F86E1 for ; Sat, 20 Oct 2012 11:01:42 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 6A13594010D; Sat, 20 Oct 2012 20:01:37 +0200 (CEST) Message-ID: <5082E700.6000200@gmail.com> Date: Sat, 20 Oct 2012 20:01:36 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Mikael Abrahamsson Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt References: <5081087D.2020807@gmail.com> <5082C58C.6040008@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 121020-0, 20/10/2012), Outbound message X-Antivirus-Status: Clean Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 18:01:45 -0000 Le 20/10/2012 18:36, Mikael Abrahamsson a écrit : > On Sat, 20 Oct 2012, Alexandru Petrescu wrote: > >> Right, parts of ND are handled in kernel in most OSes. But one >> key part that would need to be modified is RA and that is >> userspace. In linux that means mainly radvd, and curiously enough >> that lacks RS which is mostly kernel. > > Sending of RA is userspace, reception of RA is kernel. Right, and that may make it an issue. Our implementation of reception RA is userspace. I think it does not interfere with what the kernel first does with that RA. This should be ensured. >> So, instead of preferring DHCP one may bring RS out of kernel into >> radvd (a so called 'rsadvd'). At that point it's relatively easier >> to do Prefix Delegation with ND than with DHCP, >> implementation-wise, not least because code is smaller. > > Why is it easier? Also, I'd imagine there are already > implementations of DHCPv6-PD available under quite permissive > licenses, instead of what you're proposing which requires everybody > to develop new code. Well, not everybody should develop new code. Just download some :-) But there is indeed a point about compatibility with existing ND implementations. There may be a need to make sure that the proposed PD extension implementation does not break other computers' ND stacks when faced with it. I think this would be enough, no? Alex >> Where does PD belong - to DHCP or ND is a long discussion and I'll >> be happy to take part if it happens. > > For me, this is that discussion. > From alexandru.petrescu@gmail.com Sat Oct 20 11:11:09 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFEF821F8881 for ; Sat, 20 Oct 2012 11:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.03 X-Spam-Level: X-Spam-Status: No, score=0.03 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mEJDKYvmcvU for ; Sat, 20 Oct 2012 11:11:09 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 17CA721F88AF for ; Sat, 20 Oct 2012 11:11:07 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 2914A9401B2; Sat, 20 Oct 2012 20:10:59 +0200 (CEST) Message-ID: <5082E933.60205@gmail.com> Date: Sat, 20 Oct 2012 20:10:59 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Mikael Abrahamsson Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 121020-0, 20/10/2012), Outbound message X-Antivirus-Status: Clean Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 18:11:10 -0000 Le 20/10/2012 18:42, Mikael Abrahamsson a écrit : > On Sat, 20 Oct 2012, Alexandru Petrescu wrote: > >> One point that guided towards choosing ND over DHCP is topology. >> DHCP topology can be relatively complex with Client/Relay/Server, >> whereas ND is simpler one-on-one. > > There is nothing saying DHCPv6-PD can't be done in a single device > (the router itself). That's what I do in my home, cisco router, local > DHCPv6-PD pool, local DHCPv6-PD server, also installing routes into > RIB. YEs, because at home one typically puts up the interface once a month and gets typically the same prefix from ADSL operator as 1 year before. But with vehicles, one connects a vehicle here and gets a prefix, then moves in that area and gets another prefix. At that point, if the router obtaining a prefix wants to delegate further to another vehicle needs to change the delegated prefix. This dynamic change between the received prefix and the delegated prefix is not a matter of DHCP. It can be implemented by like scripting which are independent of DHCP implementation. One has to touch the conf files be it of DHCP or of ND. >> _and_ Relay (or Server). This may be feasible in practice but I >> think it would be cleaner to have distinct protocols on a same >> machine for receiving a prefix and for sending a prefix. > > What is cleaner is to use existing standards where there already is > running code. Right, there is cleanliness in reuse. Reuse as much as possible. >> There is also the question of availability of DHCP software on >> smaller platforms which have no SIM card. It may be easier to do >> this with ND in smaller settings. > > I'd imagine that there already are 2-3 existing FOSS available > implementations that do what you need for DHCPv6-PD client and > server. Instead you want to invent a new standard and create new > code. In addition to FOSS (what is FOSS?) DHCP one also needs to dynamically change the delegated prefix when the assigned prefix changed. > I'm not saying this shouldn't be done, I'm just saying I don't really > see the rationale for it. I used to hate DHCPv6 role in IPv6, but > after a few years of being exposed to it, I've come to accept that > this is the way it is. There is code going back to a standard Windows > Vista that correctly implements DHCPv6-PD client, and that is what, > 5-6 years ago it was released? I've had PD in my home on Cisco code > for 3-5 years already, with no server infrastructure at all, just > single device doing "everything" for the role needed. > > If this was 2002, I'd agree with you that ND PD could be feasable, > but I believe the train has already left the station and we should > focus on keeping IPv6 stable when it comes to how it works, and get > implementations going, not new standards. WEll yes, I agree that IPv6 should be kept stable and part of that may be that we try to make sure that a new proposal does not break existing implementation. This is a matter of further work. Alex From swmike@swm.pp.se Sat Oct 20 13:08:15 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A399621F8944 for ; Sat, 20 Oct 2012 13:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dn35lFwW6NrF for ; Sat, 20 Oct 2012 13:08:15 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDB021F8934 for ; Sat, 20 Oct 2012 13:08:14 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A4B8B9C; Sat, 20 Oct 2012 22:08:13 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9D97E9A; Sat, 20 Oct 2012 22:08:13 +0200 (CEST) Date: Sat, 20 Oct 2012 22:08:13 +0200 (CEST) From: Mikael Abrahamsson To: Alexandru Petrescu Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt In-Reply-To: <5082E933.60205@gmail.com> Message-ID: References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> <5082E933.60205@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 20:08:15 -0000 On Sat, 20 Oct 2012, Alexandru Petrescu wrote: > But with vehicles, one connects a vehicle here and gets a prefix, then > moves in that area and gets another prefix. At that point, if the > router obtaining a prefix wants to delegate further to another vehicle > needs to change the delegated prefix. > > This dynamic change between the received prefix and the delegated prefix > is not a matter of DHCP. It can be implemented by like scripting which > are independent of DHCP implementation. One has to touch the conf files > be it of DHCP or of ND. I'm sorry. I don't follow your reasoning. Could you please write some text with a clear use case where DHCPv6-PD can't be used for what you want to do, thus justifying why your proposal is needed? Please keep it at a protocol level, not implementation level. >> What is cleaner is to use existing standards where there already is >> running code. > > Right, there is cleanliness in reuse. Reuse as much as possible. Then why do you feel the need to create something new when there already is existing standards that will achieve the same thing? > In addition to FOSS (what is FOSS?) DHCP one also needs to dynamically > change the delegated prefix when the assigned prefix changed. FOSS = Free and Open Source Software. > WEll yes, I agree that IPv6 should be kept stable and part of that may > be that we try to make sure that a new proposal does not break existing > implementation. This is a matter of further work. I'd say it's an absolute requirement that any proposal do not break existing implementations. -- Mikael Abrahamsson email: swmike@swm.pp.se From dougb@dougbarton.us Sat Oct 20 13:26:32 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A180121F8BCC for ; Sat, 20 Oct 2012 13:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4C8OIuN3Z1O for ; Sat, 20 Oct 2012 13:26:32 -0700 (PDT) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by ietfa.amsl.com (Postfix) with ESMTP id E901621F8B6B for ; Sat, 20 Oct 2012 13:26:31 -0700 (PDT) Received: (qmail 7306 invoked by uid 399); 20 Oct 2012 20:26:13 -0000 Received: from unknown (HELO ?192.168.0.101?) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 20 Oct 2012 20:26:13 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <508308EE.7020306@dougbarton.us> Date: Sat, 20 Oct 2012 13:26:22 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: sthaug@nethelp.no Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt References: <5082C948.3080109@gmail.com> <20121020.183628.74709756.sthaug@nethelp.no> In-Reply-To: <20121020.183628.74709756.sthaug@nethelp.no> X-Enigmail-Version: 1.4.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: alexandru.petrescu@gmail.com, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 20:26:32 -0000 On 10/20/2012 9:36 AM, sthaug@nethelp.no wrote: >> There is also the question of availability of DHCP software on smaller >> platforms which have no SIM card. It may be easier to do this with ND >> in smaller settings. > > The obvious conclusion to this argument is that a *lot* of DHCP > functionality will be duplicated in ND. Is this where we want to go? > > I'm coming from the DHCP side of the argument. In my world DHCP is > needed because it gives you a single place to handle dynamic address > allocation, *and* it ties in with all sorts of support & backend > systems. > > I am against adding lots of new ND functionality until we have DHCPv6 > that is considerably more feature complete. Some of this is probably > coming (client MAC address), some of it is still being opposed for > mostly religious reasons (e.g. running DHCP without RA). > > Steinar Haug, AS 2116 +1 on all counts. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From hesham@elevatemobile.com Sat Oct 20 17:45:44 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0D221F87B2 for ; Sat, 20 Oct 2012 17:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 166hAhBYM1wZ for ; Sat, 20 Oct 2012 17:45:43 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 5D82421F897A for ; Sat, 20 Oct 2012 17:45:42 -0700 (PDT) Received: from [1.155.46.31] (helo=[172.20.10.3]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1TPjff-0003aM-6f; Sun, 21 Oct 2012 11:45:39 +1100 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Sun, 21 Oct 2012 11:45:30 +1100 Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt From: Hesham Soliman To: Message-ID: Thread-Topic: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt In-Reply-To: <20121020.183628.74709756.sthaug@nethelp.no> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 00:45:44 -0000 > >The obvious conclusion to this argument is that a *lot* of DHCP >functionality will be duplicated in ND. Is this where we want to go? > >I'm coming from the DHCP side of the argument. In my world DHCP is >needed because it gives you a single place to handle dynamic address >allocation, *and* it ties in with all sorts of support & backend >systems. => Agreed. I'm not coming from a DHCP side of the argument but I see the only reason for having this feature is that some people think adding/implementing this in ND is more convenient than adding a DHCP agent/relay. I don't agree. But even if that's the truth, it seems to be six of one and half dozen of the other. No compelling reason AFAICS. Hesham > >I am against adding lots of new ND functionality until we have DHCPv6 >that is considerably more feature complete. Some of this is probably >coming (client MAC address), some of it is still being opposed for >mostly religious reasons (e.g. running DHCP without RA). > >Steinar Haug, AS 2116 >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- From thierry.ernst@inria.fr Sun Oct 21 01:43:35 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 455FD21F89AC for ; Sun, 21 Oct 2012 01:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.18 X-Spam-Level: X-Spam-Status: No, score=-9.18 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpq7DLFezrIT for ; Sun, 21 Oct 2012 01:43:34 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id 4475021F8475 for ; Sun, 21 Oct 2012 01:43:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,625,1344204000"; d="vcf'?scan'208";a="178183869" Received: from roc019r.vpn.inria.fr (HELO Mont-Ventoux.local) ([128.93.183.19]) by mail1-relais-roc.national.inria.fr with ESMTP; 21 Oct 2012 10:43:30 +0200 Message-ID: <50831CF0.7050106@inria.fr> Date: Sat, 20 Oct 2012 23:51:44 +0200 From: Thierry Ernst Organization: INRIA User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> <5082E933.60205@gmail.com> In-Reply-To: <5082E933.60205@gmail.com> Content-Type: multipart/mixed; boundary="------------070605020205070303040601" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 08:43:35 -0000 This is a multi-part message in MIME format. --------------070605020205070303040601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear Alex, Would you explain why the vehicle would need to get a new prefix (and thus I assume configure all the nodes in the vehicle) every time it enters a new area ? Thierry On 20/10/12 20:10, Alexandru Petrescu wrote: > Le 20/10/2012 18:42, Mikael Abrahamsson a écrit : >> On Sat, 20 Oct 2012, Alexandru Petrescu wrote: >> >>> One point that guided towards choosing ND over DHCP is topology. >>> DHCP topology can be relatively complex with Client/Relay/Server, >>> whereas ND is simpler one-on-one. >> >> There is nothing saying DHCPv6-PD can't be done in a single device >> (the router itself). That's what I do in my home, cisco router, local >> DHCPv6-PD pool, local DHCPv6-PD server, also installing routes into >> RIB. > > YEs, because at home one typically puts up the interface once a month > and gets typically the same prefix from ADSL operator as 1 year before. > > But with vehicles, one connects a vehicle here and gets a prefix, then > moves in that area and gets another prefix. At that point, if the > router obtaining a prefix wants to delegate further to another vehicle > needs to change the delegated prefix. > > This dynamic change between the received prefix and the delegated prefix > is not a matter of DHCP. It can be implemented by like scripting which > are independent of DHCP implementation. One has to touch the conf files > be it of DHCP or of ND. > >>> _and_ Relay (or Server). This may be feasible in practice but I >>> think it would be cleaner to have distinct protocols on a same >>> machine for receiving a prefix and for sending a prefix. >> >> What is cleaner is to use existing standards where there already is >> running code. > > Right, there is cleanliness in reuse. Reuse as much as possible. > >>> There is also the question of availability of DHCP software on >>> smaller platforms which have no SIM card. It may be easier to do >>> this with ND in smaller settings. >> >> I'd imagine that there already are 2-3 existing FOSS available >> implementations that do what you need for DHCPv6-PD client and >> server. Instead you want to invent a new standard and create new >> code. > > In addition to FOSS (what is FOSS?) DHCP one also needs to dynamically > change the delegated prefix when the assigned prefix changed. > >> I'm not saying this shouldn't be done, I'm just saying I don't really >> see the rationale for it. I used to hate DHCPv6 role in IPv6, but >> after a few years of being exposed to it, I've come to accept that >> this is the way it is. There is code going back to a standard Windows >> Vista that correctly implements DHCPv6-PD client, and that is what, >> 5-6 years ago it was released? I've had PD in my home on Cisco code >> for 3-5 years already, with no server infrastructure at all, just >> single device doing "everything" for the role needed. >> >> If this was 2002, I'd agree with you that ND PD could be feasable, >> but I believe the train has already left the station and we should >> focus on keeping IPv6 stable when it comes to how it works, and get >> implementations going, not new standards. > > WEll yes, I agree that IPv6 should be kept stable and part of that may > be that we try to make sure that a new proposal does not break existing > implementation. This is a matter of further work. > > Alex > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --------------070605020205070303040601 Content-Type: text/x-vcard; charset=utf-8; name="thierry_ernst.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="thierry_ernst.vcf" begin:vcard fn:Thierry Ernst n:Ernst;Thierry org:INRIA - Project Team IMARA - LaRA JRU tel;work:+33 1 3963 59 30 tel;fax:+33 1 39 63 54 91 tel;cell:+33 6 76 56 25 96 url:http://www.lara.prd.fr version:2.1 end:vcard --------------070605020205070303040601-- From markzzzsmith@yahoo.com.au Sun Oct 21 14:06:45 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4B821F8985 for ; Sun, 21 Oct 2012 14:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.937 X-Spam-Level: X-Spam-Status: No, score=-1.937 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lWSxl6Y1NJ6 for ; Sun, 21 Oct 2012 14:06:44 -0700 (PDT) Received: from nm26-vm0.bullet.mail.sp2.yahoo.com (nm26-vm0.bullet.mail.sp2.yahoo.com [98.139.91.230]) by ietfa.amsl.com (Postfix) with ESMTP id 3437421F894A for ; Sun, 21 Oct 2012 14:06:40 -0700 (PDT) Received: from [98.139.91.64] by nm26.bullet.mail.sp2.yahoo.com with NNFMP; 21 Oct 2012 21:06:33 -0000 Received: from [98.139.91.42] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 21 Oct 2012 21:06:33 -0000 Received: from [127.0.0.1] by omp1042.mail.sp2.yahoo.com with NNFMP; 21 Oct 2012 21:06:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 317514.20557.bm@omp1042.mail.sp2.yahoo.com Received: (qmail 9954 invoked by uid 60001); 21 Oct 2012 21:06:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1350853592; bh=l2vvHgEqboPBdWXHqVv5pU3GLBsoDYgaY0NMLMZrOwM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nYLJpdw9AAOgi/wOF6reSha3dqtp+pSKQARKwqrA2b1KC4I6yTEkGjjhVBdAfMg6FfvE/q7cyUyoTHLMKfR4rRzRIjqoYtEOH3Nk4zuVdm6qiUjNUcnKgROD+mcKEnKsZ+nkoAwY3en6iBIP/wDbbyV1OAp7gmXrvGb30r+EgEo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qPXJsSKFbe/6H91giMWkptkC3sqi+Wz87faSf4bae/ixBCQ0RCksiSXVtxCQ5D0CiWw/e7uOPSEoIoIzvfTvveeKBdbShBkCwLwl9jYQHILwBZhgu5xc9IHyiwJu1A4pVffFTqsIEzdZ1o97FzpjHRlyZohZlXvl2JSbad/K86w=; X-YMail-OSG: Yr4qSX0VM1leboR7prnfKMQZ1q178_KVpubkPp7nuvC6ARY rgTdt0yiVYBzHOfhksvalaoI1v34LPq4uxIeH06zh1QLt9Hazh6ZHBsgQV4w GKu9ROcInnlV7kw_rGu24dDy8TXA1.sUvaS9.0UB23jkhpvTp7mAPktxGqrC 9KWuoOMewUw_524C0ZG4LiEBm7NYfMycsjc6z6NDOuO_XAYoIIguR_7nVN24 .L4ZZ.z8LzqOXYSSUjjfd5Sq9UuKwOV6qbeQrXvtPlGjY_k18nQ4jPBEEmUc nVH5fKt4Q5UfAl96VRbXsTArgE269CjLVN7Od6FW5GBDnxsnHreLYxgyKyMX PxxGyIO2Q3R7UOJy.9wcINJnKh9B9Hje6IGXinn35YETVV3s8x0MiaVPwPRZ sDi4V0WtfDz12y86Tpr2FBsr4dWfB39ZpM1SpTJB8JZdhTZMw1eAe3m3ar0A kmaz8qPW3GTgKDHq.fbgHI0LmRRPiKMLub92.d9E0nhnRpJQC0HhTqJQLsFm iEnKxw6kT4e_p Received: from [150.101.221.237] by web32506.mail.mud.yahoo.com via HTTP; Sun, 21 Oct 2012 14:06:32 PDT X-Rocket-MIMEInfo: 001.001, SGksCgoKCldoaWxlIEkgYXBwcmVjaWF0ZSB0aGUgZW50aHVzaWFzbSBmb3IgdGhlIGlkZWEgb2Ygc3RhdGVsZXNzIG5laWdoYm9yCmRpc2NvdmVyeSwgbm9uZSBvZiB0aGVzZSBjaGFuZ2VzICh2ZXJzaW9ucyAwMiB0aHJvdWdoIDA0KSBoYXZlIGdvbmUKdGhyb3VnaCBtZS4gSSBhbHNvIGFzc3VtZSB0aGF0IGl0IGlzIHVwIHRvIG1lIGFzIHRvIHdoZXRoZXIgT2xpdmVyIGJlY29tZXMKY28tYXV0aG9yIG9yIG5vdCwgYXMgdmVyc2lvbnMgMDAgYW5kIDAxIHdlcmUgbXkgaW5kaXZpZHVhbCB3b3JrLgoKSSdkIGEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.450 References: <2823118.ETXEjJL9LI@gentoovm> Message-ID: <1350853592.3644.YahooMailNeo@web32506.mail.mud.yahoo.com> Date: Sun, 21 Oct 2012 14:06:32 -0700 (PDT) From: Mark Smith Subject: Re: Announcing Hashed SLND and other changes to draft-smith-6man-mitigate-nd-cache-dos-slnd To: Oliver , "ipv6@ietf.org" , "bob.hinden@gmail.com" , "otroan@employees.org" In-Reply-To: <2823118.ETXEjJL9LI@gentoovm> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 21:06:45 -0000 Hi,=0A=0A=0A=0AWhile I appreciate the enthusiasm for the idea of stateless = neighbor=0Adiscovery, none of these changes (versions 02 through 04) have g= one=0Athrough me. I also assume that it is up to me as to whether Oliver be= comes=0Aco-author or not, as versions 00 and 01 were my individual work.=0A= =0AI'd appreciate some advice from the Working Group chairs as to what to d= o=0Ain this situation.=0A=0AOliver, I think your Hashed SLND idea is differ= ent enough that it should be in=0Aa separate ID, which I think should refer= ence rather than be derived from a=0Acopy of my ID. I have two concerns abo= ut it - firstly, it would significantly=0Aincrease the processing load on t= he control plane, due to the calculations=0Aof hashes, which may create ano= ther opportunity for an attacker to DoS the=0Acontrol plane of the router b= y exhausting it's CPU resources. Secondly,=0Ait would require a router to a= ssign those addresses to it's interface for=0Aat least as long as the NS/NA= transaction can take place, otherwise the=0Aincoming NA would be dropped, = and as these hashed addresses are derived from=0Athe destination address th= at triggered the NS/NA transaction, this could=0Aalso create a DoS opportun= ity, as temporarily assigning these addresses=0Ato the router's interface w= ould also require state that could be exploited.=0A=0AUltimately, I think a= host registration protocol is necessary to properly=0Asolve the problem, a= s it ensures off-link hosts can't create any unnecessary=0Astate or process= ing on routers, allows full logging of hosts that attach=0Ato the network (= which stateful DHCPv6 won't do because it doesn't record=0Ahost static addr= ess assignments), and prevents on-link hosts from spoofing=0Asource address= es that fall within the local subnets, something that BCP38=0Acan't do. My = proposal is about mitigating the DoS opportunity for existing=0Ahosts while= a registration protocol is developed and deployed. It needs=0Ato be kept s= imple so that it is both quick and easy to deploy, and not=0Abecome so "fea= tureful" such that the effort involved in developing and=0Adeploying it is = taking time away from the effort involved in developing=0Aand deploying a r= egistration protocol.=0A=0A=0AThanks,=0AMark.=0A=0A>_______________________= _________=0A> From: Oliver =0A>To:= ipv6@ietf.org =0A>Sent: Saturday, 20 October 2012 3:25 AM=0A>Subject: Anno= uncing Hashed SLND and other changes to draft-smith-6man-mitigate-nd-cache-= dos-slnd=0A> =0A>Link for convenience: http://tools.ietf.org/html/draft-smi= th-6man-mitigate-nd-=0A>cache-dos-slnd-04=0A>=0A>The following is a (non-ex= haustive) overview of the changes:=0A>=0A>1) Described Hashed SLND=0A>=0A>2= ) Replaced TUSP with TUD=0A>=0A>3) Clarified required & optional behaviour.= =0A>=0A>4) Expanded scope for SLND=0A>=0A>5) fixed up a few nits.=0A>=0A>Co= mment and feedback most appreciated.=0A>=0A>Kind Regards,=0A>Oliver=0A>----= ----------------------------------------------------------------=0A>IETF IP= v6 working group mailing list=0A>ipv6@ietf.org=0A>Administrative Requests: = https://www.ietf.org/mailman/listinfo/ipv6=0A>-----------------------------= ---------------------------------------=0A>=0A>=0A> From markzzzsmith@yahoo.com.au Sun Oct 21 14:45:25 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9A321F8797 for ; Sun, 21 Oct 2012 14:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AT+wGKs6sGae for ; Sun, 21 Oct 2012 14:45:25 -0700 (PDT) Received: from nm30-vm0.bullet.mail.ne1.yahoo.com (nm30-vm0.bullet.mail.ne1.yahoo.com [98.138.91.69]) by ietfa.amsl.com (Postfix) with ESMTP id ABF6F21F891F for ; Sun, 21 Oct 2012 14:45:24 -0700 (PDT) Received: from [98.138.90.54] by nm30.bullet.mail.ne1.yahoo.com with NNFMP; 21 Oct 2012 21:45:19 -0000 Received: from [98.138.88.234] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 21 Oct 2012 21:45:19 -0000 Received: from [127.0.0.1] by omp1034.mail.ne1.yahoo.com with NNFMP; 21 Oct 2012 21:45:19 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 973104.31829.bm@omp1034.mail.ne1.yahoo.com Received: (qmail 57856 invoked by uid 60001); 21 Oct 2012 21:45:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1350855919; bh=LyTgWsmZKVrXi2aCvQSNhQu8vCxAHnidU58PV79x9TE=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lU3pL44brdIZ/pJxHFGWfJACNJli8SqvqapZxUD8jXaFfW53IEPykMxLKjRUZ7ku6xXI0mYzsGKmQSvcSQbeBxv13K+u9EuUx7QuHG28jKUE7BQavBfCwL1aZX0UAKbZ2cD/ZFOVjx+Z2mKTtV0YTO8obdwxw7EqvHvoevitOB4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=R2UqrYdcgp3aIaWlqWlm0pNBo+1H+S4P1Pzn8YAa3aT0V7aIWKHQG2KIHyopm2B66FfeJdrcdQxCDmeTXMF9kCIt8muXugGn13CI9TSFfcKNnPlFPcjT3afvthIGdkDBf6EcVf673c6Xoo8YKiwC/VMYM+EGYtD17YyDrGrxOOw=; X-YMail-OSG: 7VLClxsVM1klVp48uAwCCG3xDcGFWwcXurStsnp4ezHqiHA OifJy9J9lmHmSyHtByBtHadHgaZFAJbhnVD7fv8EqAYLSS5RO2GIZ7NmXEem _tBrd2SprUAbd9TgmgrsRrYw3QJH7zQJdYE5v.VzgdKklbf9LlJKU8oKeGuL wNGbv7_qZEU06OFqzEl.1VLLFFy8ZZ96ASmZepfXEhRha8vg82djrhGcSdrF s.7YGxrBui9O9RRDW4axdVVEW1oLk17XGN1C_dJrgSrLanLstC2Bl3P71KYb hUWMyuFp0lU69ITaPNoUfOk99bt05jpatJ5tgqJbvdXuQKoYAxAvdaW412Km V0MudcmUW3rOun9aTuJSDNckHy5ldS0B2IQXrat1kJJ_xoY9qKvkDgo04qkV 1Wf4dTXRSF.onRlvR_8xRX8..R38xYEweGYsSxvYPDpeCJwiHHvKcFIopcyI idC3f6q42nHpXkOwh37W_WCrF8Cu5jF7jwFpkMjMLNEFncJxlcEccHDYF8m_ CqlIyAYfZ9LrklijMiz2ZccSyA.HklM8S Received: from [150.101.221.237] by web32503.mail.mud.yahoo.com via HTTP; Sun, 21 Oct 2012 14:45:18 PDT X-Rocket-MIMEInfo: 001.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBBbGV4YW5kcnUgUGV0cmVzY3UgPGFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb20.Cj4gVG86IHN0aGF1Z0BuZXRoZWxwLm5vCj4gQ2M6IGlwdjZAaWV0Zi5vcmcKPiBTZW50OiBTdW5kYXksIDIxIE9jdG9iZXIgMjAxMiA0OjU2IEFNCj4gU3ViamVjdDogUmU6IEFubm91bmNpbmcgUHJlZml4IERlbGVnYXRpb24gZXh0ZW5zaW9ucyB0byBORCBkcmFmdC1rYWlzZXItbmQtcGQtMDAudHh0Cj4gCj4gTGUgMjAvMTAvMjAxMiAxODozNiwgc3QBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.450 References: <5082C948.3080109@gmail.com> <20121020.183628.74709756.sthaug@nethelp.no> <5082E5CC.90502@gmail.com> Message-ID: <1350855918.42829.YahooMailNeo@web32503.mail.mud.yahoo.com> Date: Sun, 21 Oct 2012 14:45:18 -0700 (PDT) From: Mark Smith Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt To: Alexandru Petrescu , "sthaug@nethelp.no" In-Reply-To: <5082E5CC.90502@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 21:45:25 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Alexandru Petrescu =0A> To: sthaug@nethelp.no=0A> Cc: ipv6@ietf.org= =0A> Sent: Sunday, 21 October 2012 4:56 AM=0A> Subject: Re: Announcing Pref= ix Delegation extensions to ND draft-kaiser-nd-pd-00.txt=0A> =0A> Le 20/10/= 2012 18:36, sthaug@nethelp.no a =E9crit :=0A>>> There is also the question= of availability of DHCP software on=0A>>> smaller platforms which have no= SIM card.=A0 It may be easier to do=0A>>> this with ND in smaller setting= s.=0A>> =0A>> The obvious conclusion to this argument is that a *lot* of D= HCP=0A>> functionality will be duplicated in ND. Is this where we want to = go?=0A> =0A> I guess yes, and vice-versa.=0A> =0A>> I'm coming from the DH= CP side of the argument. In my world DHCP is=0A>> needed because it gives = you a single place to handle dynamic address=0A>> =A0 allocation, *and* it = ties in with all sorts of support & backend=0A>> systems.=0A> =0A> Well ye= s, when that backend is a fixed infrastructure with things=0A> planned, hig= hly human assisted.=A0 But in a dynamic yet simple network=0A> (without ass= istance of various backend) it's hard to use DHCP: a Relay=0A> can't 'disco= ver' a Server,=0A=0A=0AActually it can, as the destination address for the = server the relay uses=0Acan be the all-dhcp-serviers site-local (FF05:0:0:0= :0:0:1:3) multicast=0Aaddress. DHCPv6 uses multicast addresses where ever p= ossible for these=0Asorts of scenario. Geographically distributed DHCPv6 se= rvers can then be=0Aa member of a multicast that spans locations across the= network.=0A=0A=0ARFC3315,=A05.1. Multicast Addresses=0A=0A=A0DHCP makes us= e of the following multicast addresses:=0A=0A=A0 =A0 =A0 All_DHCP_Relay_Age= nts_and_Servers (FF02::1:2) A link-scoped=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 multicast address used by a client to communicate with=0A=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 neighboring (i.e., on-link) relay agents and server= s.=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 All servers and relay agents are m= embers of this=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 multicast group.=0A=0A= =A0 =A0 =A0 All_DHCP_Servers (FF05::1:3) A site-scoped multicast address us= ed=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 by a relay agent to communicate wi= th servers, either=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 because the relay = agent wants to send messages to=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 all s= ervers or because it does not know the unicast=0A=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 addresses of the servers. =A0Note that in order for=0A=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 a relay agent to use this address, it must have= an=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 address of sufficient scope to be= reachable by the=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 servers. =A0All ser= vers within the site are members of=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 t= his multicast group.=0A From kauer@biplane.com.au Sun Oct 21 16:52:45 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC2421F8A21 for ; Sun, 21 Oct 2012 16:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pa1-eKylZtel for ; Sun, 21 Oct 2012 16:52:45 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id F20DA21F8A19 for ; Sun, 21 Oct 2012 16:52:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIBAEKKhFCWZX+7/2dsb2JhbAANN8Q5AQEBBIEJCxguVxmvTJJTjyuDIwOIJZh4iBA Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.201]) ([150.101.127.187]) by ipmail07.adl2.internode.on.net with ESMTP; 22 Oct 2012 10:22:36 +1030 Message-ID: <1350863554.3457.88.camel@karl> Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt From: Karl Auer To: ipv6@ietf.org Date: Mon, 22 Oct 2012 10:52:34 +1100 In-Reply-To: <1350855918.42829.YahooMailNeo@web32503.mail.mud.yahoo.com> References: <5082C948.3080109@gmail.com> <20121020.183628.74709756.sthaug@nethelp.no> <5082E5CC.90502@gmail.com> <1350855918.42829.YahooMailNeo@web32503.mail.mud.yahoo.com> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-814AW9jS7ryvgrfZC5M6" X-Mailer: Evolution 3.2.3-0ubuntu6 Mime-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 23:52:46 -0000 --=-814AW9jS7ryvgrfZC5M6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable On Sun, 2012-10-21 at 14:45 -0700, Mark Smith wrote: > Actually it can, as the destination address for the server the relay uses > can be the all-dhcp-serviers site-local (FF05:0:0:0:0:0:1:3) multicast > address. I have yet to see this in the wild, and would be interested to hear if anyone actually does this. It seems to me that it is asking for trouble - anyone could set up a server and add themselves to that group, then receive - and answer! - DHCP queries. That is of course true anyway on the client link, but it's a different scale of problem on the wider network. Mitigation would need filters everywhere, just in case. Unicasting from relays requires configuration of all relays, but that is required anyway - and all the relays could have the *same* configuration, which is always good. My understanding (poor) is that since site-local was deprecated, the various ff05::/16 addresses were pretty much deprecated as well. Actually that's not an understanding, it's an assumption :-) And I can see that an alternative path would be to let all the site-local well-known addresses stand alone; no longer site-local as such, just "they are what they are". =20 Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 --=-814AW9jS7ryvgrfZC5M6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iF4EABEIAAYFAlCEisIACgkQFpl7eE7uYBd3XAD/a3mxk0Qk1en4Vo1ExMiZ/RJq iEyS4YIH83QkPzVVsPoBAI6qjXukBLYB60JgA/D1nsxAMPVd1Xk2kanX5o7XESW7 =U37N -----END PGP SIGNATURE----- --=-814AW9jS7ryvgrfZC5M6-- From markzzzsmith@yahoo.com.au Sun Oct 21 17:04:24 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045A621F8475 for ; Sun, 21 Oct 2012 17:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.264 X-Spam-Level: X-Spam-Status: No, score=-1.264 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, PLING_QUERY=1.39] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvuDdWjoN+sm for ; Sun, 21 Oct 2012 17:04:23 -0700 (PDT) Received: from nm13-vm4.bullet.mail.ne1.yahoo.com (nm13-vm4.bullet.mail.ne1.yahoo.com [98.138.91.173]) by ietfa.amsl.com (Postfix) with ESMTP id 163EC21F8465 for ; Sun, 21 Oct 2012 17:04:23 -0700 (PDT) Received: from [98.138.90.50] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 22 Oct 2012 00:04:20 -0000 Received: from [98.138.226.168] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 22 Oct 2012 00:04:20 -0000 Received: from [127.0.0.1] by omp1069.mail.ne1.yahoo.com with NNFMP; 22 Oct 2012 00:04:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 149595.88260.bm@omp1069.mail.ne1.yahoo.com Received: (qmail 30282 invoked by uid 60001); 22 Oct 2012 00:04:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1350864259; bh=hnR4Zm2zZuOF2LNSv19M9JkuNtw46vk8NzN7LKKom68=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=03T9jdE7n0C/R4QaxkjwNGBAX9pHPJGqpIVZ4n/AGLHWruHe/B/eOLNYmnbzjKIqifC6AnnZlzCf7XFrd4Rg4bGnBBQejOwEJgRlw3BuGtsjfO33QD8NRVpZj2mHvP1cLQkJQ3HyYcH/zn9idMol3TRnUfC0CzWPVadSwmqHLdk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=3uy3jzYlmsVAi+qLtzYD4sJJk6BCI+tVkoLlPBWsQGPRN2mTGanCmXUJK0PJeoY+wyjBy2cpaJF7jx6jLqbQVNP6CSOwSZ45D5rni3Xqnoov86iokz7csJx/ecIlVGbjpwW74iGUm4/+uP48AQoq1Hf328OCWp+OMMDCDqveNZ8=; X-YMail-OSG: L.R8pNsVM1m7ywKbqZu6W6mDBgFD1ldw9IsdZz_3RrzcumK yp1S4lobDBxtpCpqbexi.blRI2VcOuwO2qukCSZ1ivkxB2NszbWfxy.s0cSA Lf3ACfo56ccmEkjRfu.U1VNIGNPRLtVWS5TDgpemnPIf9GtKC1TiuespwBYu aNKOT0foTpnV7XqhSw1m810BEOmCVTpg2qOTxvu5GxPAtBzYtZ12yXNBRHEm VZ1FXk0h19YeA2UbL6TUINkO2Whgk8UHCgqKV4CzLjWAgtacj15Eu3b_muP3 s55lsdDakmiKlUmpbDeqdFoT9Li0MkCnIHFTj.YVHkgSWWDBdjJb70A_KM7L 99O6leEoNF88XSRQJOWMjEWKPytrQ.i6aHA9Jloutd1ubPVO4b72wj4_EyNa N3HtZTJSf97atb2o2.xUmVoxsmQ2glXOZQDR1P_tPzL1zUiDt3Vq.KRZENQH gLWsQGfmzI.NKIBAzWkQoOHY7Q_zBq6TKMmKOtzw4I3iStZjL7k6Z2J_ojPY 1BeA2qGif9w-- Received: from [150.101.221.237] by web32502.mail.mud.yahoo.com via HTTP; Sun, 21 Oct 2012 17:04:19 PDT X-Rocket-MIMEInfo: 001.001, SGkgS2FybCwKCgotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4gRnJvbTogS2FybCBBdWVyIDxrYXVlckBiaXBsYW5lLmNvbS5hdT4KPiBUbzogSUVURiBJUHY2IDxpcHY2QGlldGYub3JnPgo.IENjOiAKPiBTZW50OiBUaHVyc2RheSwgMTggT2N0b2JlciAyMDEyIDExOjMwIFBNCj4gU3ViamVjdDogV2luNyAtIG5vIG1hbmFnZWQgZmxhZywgREhDUCBhZGRyZXNzIHJlbGVhc2VkPyE_Cj4gCj4gTXkgYXBvbG9naWVzIGlmIHRoaXMgaXMgbm90IHRoZSByaWdodCBsaXN0IGZvciB0aGlzIGNvbW1lbnQvcXUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.450 References: <1350563448.2987.14.camel@karl> Message-ID: <1350864259.15057.YahooMailNeo@web32502.mail.mud.yahoo.com> Date: Sun, 21 Oct 2012 17:04:19 -0700 (PDT) From: Mark Smith Subject: Re: Win7 - no managed flag, DHCP address released?!? To: Karl Auer , IETF IPv6 In-Reply-To: <1350563448.2987.14.camel@karl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 00:04:24 -0000 Hi Karl,=0A=0A=0A----- Original Message -----=0A> From: Karl Auer =0A> To: IETF IPv6 =0A> Cc: =0A> Sent: Thursday= , 18 October 2012 11:30 PM=0A> Subject: Win7 - no managed flag, DHCP addres= s released?!?=0A> =0A> My apologies if this is not the right list for this = comment/question;=0A> suggestions for alternatives are welcome.=0A> =0A> I = have just seen the following demonstrated.=0A> =0A> Two routers, short RA i= nterval, both sending RAs for the same prefix,=0A> both with the autoconf f= lag set, one with the managed flag set and one=0A> without.=0A>=A0=0A=0ASo = to be clear,=A0=0A=0ARA1 - M=3D1, O=3D1, PIO: pfx=3D2001:db8:0:1::/64, L=3D= 1, A=3D1=0ARA2 - M=3D0, O=3D1, PIO:=A0pfx=3D2001:db8:0:1::/64, L=3D1, A=3D1= =0A=0A6.2.7, "Router Advertisement Consistency" in RFC4861 does say routers= should=0A=0Acheck the RAs from other routers, and log inconsistencies, as = it indicates=0Athat a misconfiguration has occurred. The M and O bits are s= pecifically=0Amentioned.=0A=0AAlthough the M bit is a whole of link flag as= it is global in the RA,=0A=0Arather than being a prefix specific flag, the= definition of the M bit in=0ARFC4861 seems to only indicate to attempt sta= teful DHCPv6, rather than=0Aalso override the A bit in any received PIOs:= =0A=0A=0A=A0 =A0 =A0M =A0 =A0 =A0 =A0 =A0 =A0 =A01-bit "Managed address con= figuration" flag. =A0When=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0set,= it indicates that addresses are available via=0A=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0Dynamic Host Configuration Protocol [DHCPv6].=0A=0A=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0If the M flag is set, the O flag is = redundant and=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0can be ignored b= ecause DHCPv6 will return all=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= available configuration information.=0A=0ALooking a bit further, RFC4861 sa= ys that (6.3.4)=0A=0A=A0 =A0When multiple routers are present, the informat= ion advertised=0A=A0 =A0collectively by all routers may be a superset of th= e information=0A=A0 =A0contained in a single Router Advertisement. =A0Moreo= ver, information=0A=A0 =A0may also be obtained through other dynamic means = like DHCPv6. =A0Hosts=0A=A0 =A0accept the union of all received information= ; the receipt of a Router=0A=A0 =A0Advertisement MUST NOT invalidate all in= formation received in a=0A=A0 =A0previous advertisement or from another sou= rce. =A0However, when=0A=A0 =A0received information for a specific paramete= r (e.g., Link MTU) or=0A=A0 =A0option (e.g., Lifetime on a specific Prefix)= differs from information=0A=A0 =A0received earlier, and the parameter/opti= on can only have one value,=0A=A0 =A0the most recently received information= is considered authoritative.=0A=0ASo I'd say Windows 7 is doing the wrong = thing if the M bit changes from=0A=0A1 to 0. It should stop using DHCPv6 fr= om that point onwards to acquire=0Aor refresh addresses, but still should r= espect the preferred and=0Avalid lifetimes of the addresses it previously a= cquired using DHCPv6. It=0Ashould also perform SLAAC using the RA PIOs with= the A bits, independently=0Aof the value of the M bit.=0A=0AIt seems that = an exclusively stateful DHCPv6 or SLAAC model has been=0A=0Aadopted by Wind= ows 7, rather than a stateful DHCPv6 and/or SLAAC model,=0Awhich is what RF= C4861 provides. RFC4861's model would allow the addition=0Aof a stateful DH= CPv6 server to a formerly SLAAC only link, or vice versa,=0Aand facilitate = a phased rather than disruptive move to a SLAAC=0Aonly or stateful DHCPv6 o= nly operation if that is the goal.=0A> A Windows 7 host gets an address via= DHCPv6 when the RA with the managed=0A> flag comes around - and DROPS IT w= hen an RA without the managed flag=0A> comes past.=0A> =0A> This is not the= valid lifetime expiring normally. I was not able to=0A> determine whether = the Windows host is actually sending a DHCPv6 release=0A> as well, but it i= s most certainly dropping the address from the=0A> interface.=0A> =0A> I wi= ll be trying to do my own tests to confirm (or not) this behaviour,=0A> but= has anyone else seen it? Or seen it with other operating systems?=0A> =0A>= If it is indeed happening, this behaviour seems very badly broken to me.= =0A> I don't feel the relevant RFCs can reasonably be interpreted as=0A> su= pporting this behaviour.=0A> =0A> Regards, K.=0A> =0A=0A=0ARegards,=0AMark.= =0A From markzzzsmith@yahoo.com.au Sun Oct 21 17:29:51 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E821E21F8B13 for ; Sun, 21 Oct 2012 17:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEBWaNfd1NvU for ; Sun, 21 Oct 2012 17:29:50 -0700 (PDT) Received: from nm27.bullet.mail.ac4.yahoo.com (nm27.bullet.mail.ac4.yahoo.com [98.139.52.224]) by ietfa.amsl.com (Postfix) with ESMTP id 18D5A21F8A8B for ; Sun, 21 Oct 2012 17:29:50 -0700 (PDT) Received: from [98.139.52.194] by nm27.bullet.mail.ac4.yahoo.com with NNFMP; 22 Oct 2012 00:29:47 -0000 Received: from [98.139.52.187] by tm7.bullet.mail.ac4.yahoo.com with NNFMP; 22 Oct 2012 00:29:47 -0000 Received: from [127.0.0.1] by omp1070.mail.ac4.yahoo.com with NNFMP; 22 Oct 2012 00:29:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 41006.54147.bm@omp1070.mail.ac4.yahoo.com Received: (qmail 3139 invoked by uid 60001); 22 Oct 2012 00:29:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1350865786; bh=7CFr+qaRmpNzYQr/cgmngnvCVD8168CtOP/vY5TytPY=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=z9pMiH2xFyewr/IldUOlzjGbBzRaYJZBmmVLXBxxAb/O6nWJEJIZhPNkZTliXVNkurgGfBGr3dYkO5tkyJs9MKIxl5a9zly1Dvtr0gxvncuKAbe8l4pejQu3mIU8s0ZhJaqOuIURh75TFC741ETToHU860HDi+/A8oovwQ/jFzA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ur3n0hExT5y/+HFlVEIOr8PReInohBzX2xIn8kBl2kG4kDzIbdVrlHSXQtGhJPKXJQEUYIPqzH3jUtZAddmm7dezyzg7T4r6W2qJV8nHnqb3UDMsvXW8WVUiRpioomBjph5dpS23ISaKP7uR05tOcOxz8aG1SfBcyT0NkNC08DY=; X-YMail-OSG: 7OyiauEVM1nLNTMAas4Q.JjAwr9fWC5hIeEw70Ul_xXgSCo aCUCdbw95bBWYKekSrWFhgjCJuLh_GMcKpboc05Idgul5rAdLnW193RQ86RX H3VtjNqKXzpy4jEGDKXabp6DG20G03pez1RzJ8L_NhGIjDbk6SlAdYTADNQt UQxyoR8dy8Lu7vQ22Yo_7TKJ7RBWKLJWzXDaY9B.zTAV42Wxfbguj0apQ7d. okhzAyK6osO7Tnn6jGUuvuhQdtMNivrvNCGug9BF211GyOZR2J_00gghvFKh yl_0747.79Pbi7pBOlCbHwkwzDdSLd2OUEsmsHxFlmUKDvDIopynT3HFQiPR 0a.w24JnfB4.8OsqRbaLk7t0LdBW8ApRftrtXOIKBzIfPq8.UyQF9.ff81fk A8vQDhd2mH9x0DIjsEK_NtWV.Yhn4gNAS8rS5r8qu9igkTvykiuVDTqXrq4g gS2hviEPoi1H3p.TFoMe4mSLVrzopM9vOe9C4ROwHi1OGCY42wsAPOf9ZDZd V0qAPpe4uwbj1 Received: from [150.101.221.237] by web32507.mail.mud.yahoo.com via HTTP; Sun, 21 Oct 2012 17:29:46 PDT X-Rocket-MIMEInfo: 001.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiAic3RoYXVnQG5ldGhlbHAubm8iIDxzdGhhdWdAbmV0aGVscC5ubz4KPiBUbzogYWxleGFuZHJ1LnBldHJlc2N1QGdtYWlsLmNvbQo.IENjOiBpcHY2QGlldGYub3JnCj4gU2VudDogU3VuZGF5LCAyMSBPY3RvYmVyIDIwMTIgMzozNiBBTQo.IFN1YmplY3Q6IFJlOiBBbm5vdW5jaW5nIFByZWZpeCBEZWxlZ2F0aW9uIGV4dGVuc2lvbnMgdG8gTkQgZHJhZnQta2Fpc2VyLW5kLXBkLTAwLnR4dAo.IAo.PiAgVGhlcmUgaXMgYWxzbyB0aGUgcXUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.450 References: <5082C948.3080109@gmail.com> <20121020.183628.74709756.sthaug@nethelp.no> Message-ID: <1350865786.583.YahooMailNeo@web32507.mail.mud.yahoo.com> Date: Sun, 21 Oct 2012 17:29:46 -0700 (PDT) From: Mark Smith Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt To: "sthaug@nethelp.no" , "alexandru.petrescu@gmail.com" In-Reply-To: <20121020.183628.74709756.sthaug@nethelp.no> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 00:29:51 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: "sthaug@nethelp.no" =0A> To: alexandru.petrescu@gmail.com=0A> Cc: ipv6@ietf.org= =0A> Sent: Sunday, 21 October 2012 3:36 AM=0A> Subject: Re: Announcing Pref= ix Delegation extensions to ND draft-kaiser-nd-pd-00.txt=0A> =0A>> There i= s also the question of availability of DHCP software on smaller=0A>> platf= orms which have no SIM card.=A0 It may be easier to do this with ND=0A>> i= n smaller settings.=0A> =0A> The obvious conclusion to this argument is tha= t a *lot* of DHCP=0A> functionality will be duplicated in ND. Is this where= we want to go?=0A> =0A> I'm coming from the DHCP side of the argument. In = my world DHCP is=0A> needed because it gives you a single place to handle d= ynamic address=0A> allocation, *and* it ties in with all sorts of support &= backend=0A> systems.=0A> =0A> I am against adding lots of new ND functiona= lity until we have DHCPv6=0A> that is considerably more feature complete. S= ome of this is probably=0A> coming (client MAC address), some of it is stil= l being opposed for=0A> mostly religious reasons (e.g. running DHCP without= RA).=0A>=A0=0A=0ACan people stop religiously using the "religious reasons"= to complain about DHCPv6=0A=0Anot having a default gateway option?=0A=0A= =0AThe argument against a default gateway option in DHCPv6 is exactly the o= ne=0A=0Ayou're using against additional ND options - it's not only a solved= problem,=0Athe code to implement it has been widely deployed and widely wo= rks.=0A=0ASome people believe that you need DHCPv6 to support a default=0Ag= ateway option so that you can selectively give different hosts different=0A= default gateways. That is not true, RAs can be also selectively sent to=0Ad= ifferent hosts, and the radvd daemon implements it - see the "clients"=0Ain= terface option. From markzzzsmith@yahoo.com.au Sun Oct 21 17:54:32 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3649D21F8611 for ; Sun, 21 Oct 2012 17:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gY4E1+atgKV for ; Sun, 21 Oct 2012 17:54:31 -0700 (PDT) Received: from nm12-vm0.bullet.mail.ne1.yahoo.com (nm12-vm0.bullet.mail.ne1.yahoo.com [98.138.91.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCD121F85F9 for ; Sun, 21 Oct 2012 17:54:31 -0700 (PDT) Received: from [98.138.226.178] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 22 Oct 2012 00:54:25 -0000 Received: from [98.138.89.167] by tm13.bullet.mail.ne1.yahoo.com with NNFMP; 22 Oct 2012 00:54:25 -0000 Received: from [127.0.0.1] by omp1023.mail.ne1.yahoo.com with NNFMP; 22 Oct 2012 00:54:25 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 679300.42238.bm@omp1023.mail.ne1.yahoo.com Received: (qmail 49755 invoked by uid 60001); 22 Oct 2012 00:54:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1350867265; bh=cbKQDeFFTTTD2i3icboO84YfJqhzPHLCH0aH/wyvDh4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=OC524JWNEPUHZzFae3wSDB83pwN4cr9DKfQCvvdj1XZEI9/qqnMquqLumE0FLGQddy8KNT0Q9QnO8GoZpmp6DNkydl7SoAdD1mEwmhwEBySI7305/XSUK4GWveoiFMKO3oXMpa+r8qZTSpAKjg7VdCZAYJ+7nx0u9sx8ZJKpfc0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=2eyC+7JoQuOToNB9to/cAcw9Dxf1LP3m7ACdEP20Lmwlib+X0bUsVoyWRLWYMIu27dAuPxq/UXa39P7cR8MdXXpRpueJQMCIxWKBTwm97lirFfn/rpG9PL85glw45Ts6eyVDG6AHWfKxUbrBTsWZy2fZFXQdNRDz/1jwqFnFCNc=; X-YMail-OSG: dNcJbTAVM1ndk5ky5XGUpZsxtjxYQJfyIeTXkuwbch5GSJL 2wk5Lf2z9UqmJMme5f9Xj_wD2o.TzHQdWbMOqDpU7FIhadk_zG94e.vF4GYU ubzjiWnm8MmTYfdX.Uoe_h9dvpSDv4iGsseAyNBW6pLvv9H1.p1iqhTQXn3b .c4kxYgAKzG5n2tIiU77kFlzqc_PX16WnPcYKe8Dtd1Aj6_98oWDg8.Lt.I5 NPmHutsjb8kBN6UTqfbOlXk2pIfqYYC2I9pPDV0Eu7a5vzMI_SrM7i7PKcVE 8mv0SZyObQ2dEhpKwE.jYWDvReVeEmp1PlOzPDDz4BFtM1X9WINySTloI2oe wUPy4IFx1RYBq.256dCa2xByWrPUrx29HZVsJPJExPwXUL4Abv5M2AaLz4g1 JhuSmcWvLjebzXQSZyY1EDUFx3cThdm0ZodP_y9KdXRxTEC5GjuzJ0OaOI31 gpjoRnwgZakzQ7tEwawj0HculTxA1Gvi293E04wmAlF4f8T7OIssfJC0D9YQ IJFFw8Svi Received: from [150.101.221.237] by web32505.mail.mud.yahoo.com via HTTP; Sun, 21 Oct 2012 17:54:24 PDT X-Rocket-MIMEInfo: 001.001, SGkgS2FybCwKCgotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4gRnJvbTogS2FybCBBdWVyIDxrYXVlckBiaXBsYW5lLmNvbS5hdT4KPiBUbzogaXB2NkBpZXRmLm9yZwo.IENjOiAKPiBTZW50OiBNb25kYXksIDIyIE9jdG9iZXIgMjAxMiAxMDo1MiBBTQo.IFN1YmplY3Q6IFJlOiBBbm5vdW5jaW5nIFByZWZpeCBEZWxlZ2F0aW9uIGV4dGVuc2lvbnMgdG8gTkQgZHJhZnQta2Fpc2VyLW5kLXBkLTAwLnR4dAo.IAo.IE9uIFN1biwgMjAxMi0xMC0yMSBhdCAxNDo0NSAtMDcwMCwgTWFyayBTbWl0aCB3cm8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.450 References: <5082C948.3080109@gmail.com> <20121020.183628.74709756.sthaug@nethelp.no> <5082E5CC.90502@gmail.com> <1350855918.42829.YahooMailNeo@web32503.mail.mud.yahoo.com> <1350863554.3457.88.camel@karl> Message-ID: <1350867264.15372.YahooMailNeo@web32505.mail.mud.yahoo.com> Date: Sun, 21 Oct 2012 17:54:24 -0700 (PDT) From: Mark Smith Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt To: Karl Auer , "ipv6@ietf.org" In-Reply-To: <1350863554.3457.88.camel@karl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 00:54:32 -0000 Hi Karl,=0A=0A=0A----- Original Message -----=0A> From: Karl Auer =0A> To: ipv6@ietf.org=0A> Cc: =0A> Sent: Monday, 22 October 2= 012 10:52 AM=0A> Subject: Re: Announcing Prefix Delegation extensions to ND= draft-kaiser-nd-pd-00.txt=0A> =0A> On Sun, 2012-10-21 at 14:45 -0700, Mark= Smith wrote:=0A>> Actually it can, as the destination address for the ser= ver the relay uses=0A>> can be the all-dhcp-serviers site-local (FF05:0:0:= 0:0:0:1:3) multicast=0A>> address.=0A> =0A> I have yet to see this in the = wild, and would be interested to hear if=0A> anyone actually does this.=0A= =0AI'd suggest that is because most people have only lived in a unicast IPv= 4=0A=0Aworld, so there is very little understanding of and recognition of w= hat=0Avalue multicast can provide to network operations.=0A=0AThat's not to= say it should always be used for a relay, it is a trade=0A=0Aoff. My point= was that there is a method available for a relay to discover=0ADHCPv6 serv= ers without the configuration issues related to only being able=0Ato use a = specific GUA or ULA unicast address.=0A=0A> It seems to me that it is askin= g for trouble=0A> - anyone could set up a server and add themselves to that= group, then=0A> receive - and answer! - DHCP queries. That is of course tr= ue anyway on=0A> the client link, but it's a different scale of problem on = the wider=0A> network. Mitigation would need filters everywhere, just in ca= se.=0A=0ATrue, however you also have the same sort of vulnerability issues = to rogue=0A=0ADHCP servers. That would be one of the considerations of whet= her to do it=0Aor not.=0A=0A> Unicasting from relays requires configuration= of all relays, but that is=0A> required anyway - and all the relays could = have the *same*=0A> configuration, which is always good.=0A>=A0=0A=0AWell, = the same multicast address would be used on the relays' configurations,=0A= =0Aso they'd all be the same. The drawback of unicast is that the relay=0At= arget DHCPv6 server becomes a single point of failure. I'm not sure if=0Ayo= u could use or whether it would be wise to use an anycast address as a=0ADH= CPv6 server address in that scenario.=0A=0A=0A> My understanding (poor) is = that since site-local was deprecated, the=0A> various ff05::/16 addresses w= ere pretty much deprecated as well.=0A=0AI'm pretty sure site-local multica= st scope wasn't deprecated with site-local=0A=0Aunicast addresses were. The= issue with site-local unicast addresses wasn't=0Athat the idea of a site w= as invalid, it was their non-uniqueness and=0Atherefore it recreated in IPv= 6 all the sorts of issues similar we suffer=0Afrom with overlapping or dupl= icated RFC1918 address spaces. If you ever=0Awant to explain to IPv4 people= the issues with duplicated RFC1918 address=0Aspaces, the IPv6 site local d= eprecation RFC provides a good list.=0A=0A=0A> Actually that's not an under= standing, it's an assumption :-) And I can=0A> see that an alternative path= would be to let all the site-local=0A> well-known addresses stand alone; n= o longer site-local as such, just=0A> "they are what they are".=0A> =0A> Re= gards, K.=0A> =0A=0A=0ARegards,=0AMark. From kauer@biplane.com.au Sun Oct 21 18:30:09 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E7C21F8AAB for ; Sun, 21 Oct 2012 18:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.767 X-Spam-Level: X-Spam-Status: No, score=-1.767 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ldOtCxMOYQZ for ; Sun, 21 Oct 2012 18:30:08 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id C8D0921F88F8 for ; Sun, 21 Oct 2012 18:30:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIBAIighFCWZX+7/2dsb2JhbAANN8Q5AQEBAwF+CwsYLlcGE4d+p2qSU4tphmUDiCWYeIgQ Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.201]) ([150.101.127.187]) by ipmail07.adl2.internode.on.net with ESMTP; 22 Oct 2012 12:00:03 +1030 Message-ID: <1350869401.3457.104.camel@karl> Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt From: Karl Auer To: "ipv6@ietf.org" Date: Mon, 22 Oct 2012 12:30:01 +1100 In-Reply-To: <1350867264.15372.YahooMailNeo@web32505.mail.mud.yahoo.com> References: <5082C948.3080109@gmail.com> <20121020.183628.74709756.sthaug@nethelp.no> <5082E5CC.90502@gmail.com> <1350855918.42829.YahooMailNeo@web32503.mail.mud.yahoo.com> <1350863554.3457.88.camel@karl> <1350867264.15372.YahooMailNeo@web32505.mail.mud.yahoo.com> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-BtCZC/RD9FgCCzASBXIo" X-Mailer: Evolution 3.2.3-0ubuntu6 Mime-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 01:30:09 -0000 --=-BtCZC/RD9FgCCzASBXIo Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable On Sun, 2012-10-21 at 17:54 -0700, Mark Smith wrote: > > network. Mitigation would need filters everywhere, just in case. > True, however you also have the same sort of vulnerability issues to rogu= e > DHCP servers. Unicast queries go only to the correct servers. Rogues don't get a look in - except on the single link they are actually on, and filtering doesn't help there (except on the hosts themselves, I suppose, which doesn't scale well). You could automate the detection of rogue DHPv6 servers by snooping on MLD - they have to add themselves to the two DHCPv6 multicast addresses. It'd be an interesting feature to add to switches, and probably fairly trivial since an IPv6 aware switch already does MLD snooping... > Well, the same multicast address would be used on the relays' configurati= ons, The default for a relay is to send to a well-known site-local multicast address. No config needed at all. RFC3315: 20. Relay Agent Behavior [...]If the relay agent has not been explicitly configured, it MUST use the All_DHCP_Servers multicast address as the default. You could put a *different* multicast address on the relays, provided the servers can be configured to support it. However, I reckon unicast is a better idea, so I'd be interested in the experience of anyone who has actually tried the multicast method. > so they'd all be the same. The drawback of unicast is that the relay > target DHCPv6 server becomes a single point of failure. You configure the relays with a list of unicast addresses, just as you do IPv4 "relays" now. No SPOF. RFC3315 again: 20. Relay Agent Behavior The relay agent MAY be configured to use a list of destination addresses, which MAY include unicast addresses, the All_DHCP_Servers multicast address, or other addresses selected by the network administrator. > you could use or whether it would be wise to use an anycast address as a > DHCPv6 server address in that scenario. Actually I'm not sure anycast would work, I haven't thought about it enough yet ;-) I think there would be issues if failover ever gets reimplemented for IPv6. Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 --=-BtCZC/RD9FgCCzASBXIo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iF4EABEIAAYFAlCEoZoACgkQFpl7eE7uYBdeuwD/XAKu+Grs+ZCtp1s2sQeX77R2 Irvt67YgJXNwCrmoeBwA/1IfNFG8tvnPYY4bDHluGDiAHn/yylEK+gVx3uUiidDz =vbZh -----END PGP SIGNATURE----- --=-BtCZC/RD9FgCCzASBXIo-- From n@arifumi.net Mon Oct 22 01:25:14 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6099321F845B for ; Mon, 22 Oct 2012 01:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hr6WseLI+hoU for ; Mon, 22 Oct 2012 01:25:13 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id AB6A721F844C for ; Mon, 22 Oct 2012 01:25:13 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so2914861vcb.31 for ; Mon, 22 Oct 2012 01:25:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=Ck/c0YhWbymcmyPAIPp3M/iAzC8IJK+2yosiBWH89Ok=; b=pEsYynBAu1u1uxjFn/59QoxvEgEULgBkps1Py6Z/S5smnwsZLgAHv3Xnf4nuXf6KXX k8T+5m/0gw03sBVVQXb8ykWcQe154aFMC8I6IoImIps1Vuqv3Vj0FnvORISf4GwtXTQ7 3UdeUrpH3i++QrhQi3PDgfoTzgJRUgIbRbjCqYtSEhhWQaVovrC+tIX+9X+tYnteqc7l S4UpXrQP6jWF25Ktg868yg8LcYYZ78o+3+MW5IhVHaHc8HrMUFysYADSYV9ar5ZTVNf9 D9u3+AJxwDmzGvM3pKrvGOcQ4SxkjmQV+1+VagnaEmMacVDtMqsijSPppPzwEZdRjVnY S6XA== MIME-Version: 1.0 Received: by 10.52.30.167 with SMTP id t7mr10807576vdh.56.1350894312842; Mon, 22 Oct 2012 01:25:12 -0700 (PDT) Sender: n@arifumi.net Received: by 10.58.178.229 with HTTP; Mon, 22 Oct 2012 01:25:12 -0700 (PDT) X-Originating-IP: [192.47.162.190] In-Reply-To: <023f01cdae04$6d68cf60$4001a8c0@gateway.2wire.net> References: <0D1941A7-217D-44E1-A3E3-45D30D51A273@employees.org> <023f01cdae04$6d68cf60$4001a8c0@gateway.2wire.net> Date: Mon, 22 Oct 2012 17:25:12 +0900 X-Google-Sender-Auth: Vp5hn-Jhl2ubNrcrrP6r7ekkGyY Message-ID: Subject: Re: 6MAN WG Last Call: From: Arifumi Matsumoto To: "t.petch" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl3gfzoJhymkVY06Qo3Q1QQw29rUev1Lx7bo+5tChD/Og3ceZ1Sjay0dmeqd2qjNtBwKwdz Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 08:25:14 -0000 This should be removed. Thanks. 2012/10/19 t.petch : > s.7 IANA considerations request the allocation of a code for > OPTION_ADDRSEL_ZONE > Is this the now removed > OPTION_ZONE_INDEX ? > If not, what? > > s.2 "POLICY TABLE OPITONS" > > Tom Petch > > > ----- Original Message ----- > From: "Ole Tr=F8an" > To: > Cc: <6man-chairs@tools.ietf.org> > Sent: Wednesday, October 10, 2012 9:28 AM > > > All, > > This message starts a two week 6MAN Working Group on advancing: > > Title : Distributing Address Selection Policy using DHCPv6 > Author(s) : A. Matsumoto, T. Fujisaki, T. Chown > Filename : draft-ietf-6man-addr-select-opt-06.txt > Pages : 10 > Date : 2012-09-21 > > http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-06 > > as Proposed Standard. Substantive comments and statements of support > for advancing this document should be directed to the mailing list. > Editorial suggestions can be sent to the authors. This last call will > end on 24. October 2012. > > Regards, > > Ole Tr=F8an & Bob Hinden > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From internet-drafts@ietf.org Mon Oct 22 01:58:44 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAD921F876B; Mon, 22 Oct 2012 01:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.401 X-Spam-Level: X-Spam-Status: No, score=-102.401 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mFPALa3xr3c; Mon, 22 Oct 2012 01:58:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86FCF21F87EB; Mon, 22 Oct 2012 01:58:43 -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 Subject: I-D Action: draft-ietf-6man-udpzero-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022085843.27941.31252.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 01:58:43 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 08:58:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Applicability Statement for the use of IPv6 UDP Datagram= s with Zero Checksums Author(s) : Godred Fairhurst Magnus Westerlund Filename : draft-ietf-6man-udpzero-07.txt Pages : 33 Date : 2012-10-21 Abstract: This document provides an applicability statement for the use of UDP transport checksums when used with IPv6. This defines recommendations and requirements for use of IPv6 UDP datagrams with a zero checksum. It examines the role of the IPv6 UDP transport checksum, as defined in RFC2460 and presents a summary of the trade- offs for evaluating the safety of updating RFC 2460 to permit an IPv6 UDP endpoint to use a zero value in the checksum field as an indication that no checksum is present. This method is compared with some other possibilities. The document also describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations. XXX NOTE - This revision is a partial response to comments received during IESG review. There are additional comments to be incorporated - and updates anticipated to the related PS that updates IPv6. This is therefore an interim version. XXX The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-udpzero There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-udpzero-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-udpzero-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 22 01:58:45 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C094121F86EB for ; Mon, 22 Oct 2012 01:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.401 X-Spam-Level: X-Spam-Status: No, score=-102.401 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVpsDZZccbRh; Mon, 22 Oct 2012 01:58:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60D221F8623; Mon, 22 Oct 2012 01:58:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: 6man-chairs@tools.ietf.org, draft-ietf-6man-udpzero@tools.ietf.org, ipv6@ietf.org, brian@innovationslab.net, barryleiba@computer.org, stbryant@cisco.com Subject: New Version Notification - draft-ietf-6man-udpzero-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022085843.27941.90525.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 01:58:43 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 08:58:45 -0000 A new version (-07) has been submitted for draft-ietf-6man-udpzero: http://www.ietf.org/internet-drafts/draft-ietf-6man-udpzero-07.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-udpzero-07 IETF Secretariat. From n@arifumi.net Mon Oct 22 02:00:29 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E06721F88D5 for ; Mon, 22 Oct 2012 02:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VC14FjOJrUaw for ; Mon, 22 Oct 2012 02:00:28 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E00F421F87E0 for ; Mon, 22 Oct 2012 02:00:27 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so2965091vbb.31 for ; Mon, 22 Oct 2012 02:00:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=3ZSZAn2oO3Fkl9kEC8/6GfgXLstk0ByfPSmHNHKFyxI=; b=SYHTd/CXV0Iv5/i3bN7xq5tEzXZ2URxmQBIjVGQY7UKvW+/Aa1wka8WzP+lEwkFiDk g2xeqxu6eSy2sHWlt4Ft/A0eq5rGszOw8kMI7NfGB4rcmQkVyY6Wn1PrL4iqD2nJU3XR M75Q0fwNyfTPh4XkQBITOXVk8jv6C3Q2lFJ9T4uI6g59WqM7KTkN5sCkYmRWPfmUpxyJ n8bC9tj5uklY/29nx6Cs+RzqkjJTn3R1LN+m7Q5nZxMqKItWODZ8YFq5COmRmnV4pxdS McdsW0e0GonoQrwzQ9Kxldqgw/tLr9de75S4HRA3te/2Cjy5bZOyZSllT9srEJRHuwMZ Pg9g== MIME-Version: 1.0 Received: by 10.58.187.84 with SMTP id fq20mr14706458vec.25.1350896423823; Mon, 22 Oct 2012 02:00:23 -0700 (PDT) Sender: n@arifumi.net Received: by 10.58.178.229 with HTTP; Mon, 22 Oct 2012 02:00:23 -0700 (PDT) X-Originating-IP: [192.47.162.190] In-Reply-To: <507D78AA.7020502@globis.net> References: <0D1941A7-217D-44E1-A3E3-45D30D51A273@employees.org> <50754741.9090506@globis.net> <507D78AA.7020502@globis.net> Date: Mon, 22 Oct 2012 18:00:23 +0900 X-Google-Sender-Auth: WVZAgPjAt_Oo3XfJaKivvkcYvOQ Message-ID: Subject: Re: 6MAN WG Last Call: From: Arifumi Matsumoto To: Ray Hunter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQny7vNK3UMlYUSmLndzbuVga2Njz8ASA+XJcCOCwZ1+qZle6Yt3D2jyCBvT9KCdkOkuiFRF Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 09:00:29 -0000 Hi, I received the following e-mail directly. Let me add Cc to the list. 2012/10/17 Ray Hunter : > inline. >> >> Arifumi Matsumoto >> 16 October 2012 10:53 >> >> Ray, >> thank you for review and comments. >> >> Responses below. >> >> 2012/10/10 Ray Hunter: >>> >>> I support this work. >>> >>> Discussion >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> Section 4.2 >>> s/the default policy should be restored/the previously active policy >>> should >>> be restored/ ? >> >> >> It is assumed that the configuration will be either using distributed >> policy or >> using manually configured policy as described in 4.1. >> So, 4.2 is written like this. >> >> Do you propose to change the above assumption ? >> > It is more of a question than a proposal. > > Some implementations (e.g. Windows) make a distinction between a > manually-configured change to the policy table that will survive a reboot= , > and other changes that are only valid for this user session, using the > concept of a "store". See "netsh interface ipv6 show prefixpolicy > [[store=3D]{active | persistent}]" > > If there's been a manually-configured persistent policy set, if an [activ= e] > DHCPv6-derived policy table goes stale, it might be more appropriate to > (re)activate the manually-configured persistent policy that is specific t= o > this node, rather than the "default" policy table defined in section 2.1 = of > RFC6724. > > It's really a question of if we need to further clarify what is meant by > "default policy" in Section 4.2 of draft-ietf-6man-addr-select-opt-06. > > Is it the manually configured node-specific default, or the RFC6724 secti= on > 2.1 default policy table, or is this behaviour simply implementation > dependent and we should remain silent on an appropriate default? IMHO, it should be complex to allow to receive distributed policy even when the policy is manually configured. However, I agree that it should be out-of-scope of this document. This document should just state the requirements as in 4.1. > Further clarification on section 2 /A address selection option contains z= ero > or more policy table options/: > > I think it would also be useful if we added one sentence after this: /An > Address Selection option containing zero Policy Table options SHOULD be > interpreted as the RFC6724 Section 2.1 default policy table./ > > This will allow administrators to easily and positively provide local nod= es > with a hint that they should use the default table of RFC6724, without > having to redefine and transport this every time, or rely on time outs. The reason for allowing zero policy table options is to deliver only the A and P flags of the Address Selection option. If we want to do this, we should add another flag for it. However, IMHO, we should not add such a thing, to keep things simple. Thank you. > >> I really appreciate your reviewing and suggestions below. > > You're welcome. >>> >>> Nits& clarification >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> Section 2 >>> s/A address selection option contains/An Address Selection option >>> contains/ >>> >>> s/Multiple policy table options in a Policy Table option constitute a >>> single >>> policy table./ >>> Multiple Policy Table options in an Address Selection option constitute= a >>> single policy table./ >>> >>> s/zero padded/left aligned, big-endian, and zero padded on the right/ >>> >>> Section 3 >>> s/in any messages other/in any DHCPv6 messages other/ >>> >>> Section 4.1 >>> s/his requirement/their own requirements/ >>> >>> s/a) It receives distributed policy table, and replaces the existing >>> policy tables with that. >>> b) It preserves the default policy table, or manually configured >>> policy./ >>> a) replace the existing active policy table with the DHCPv6 distributed >>> policy table . >>> b) preserve the existing active policy table, whether this be the defau= lt >>> policy table, or user configured policy./ >>> >>> >>> Section 4.3 >>> s/node-global information by its nature/node-global information by thei= r >>> nature/ >>> >>> s/One of the reason is/One reason being/ >>> >>> s/multiple address selection policy/multiple address selection policies= ,/ >>> >>> s/the effect of both policy/the effect of both policies/ >>> >>> s/that absence of the distributed policy/that absence of a distributed >>> policy/ >>> a/mean preference/mean a preference/ >>> >>> s/deal with multiple received policy/deal with multiple received >>> policies/ >>> >>> s/DHCPv6 clients need to convert this label to a representation specifi= ed >>> by >>> each implementation/DHCPv6 clients SHOULD convert this label to a >>> representation appropriate for the local implementation/ >>> >>> s/So, the number of the options and the total size of the options shoul= d >>> be >>> taken care of. Since the number of selection rules could be large, an >>> administrator configuring the policy to be distributed should consider >>> the >>> resulting DHCPv6 message size/ >>> Network administrators SHOULD consider local limitations to the maximum >>> DHCPv6 message size that can be reliably transported via their specific >>> local infrastructure to end nodes; and therefore they SHOULD consider t= he >>> number of options, the total size of the options, and the resulting >>> DHCPv6 >>> message size, when defining their Policy Table./ >>> >>> Section 6: >>> >>> s/and the affected packets might be blocked at an outgoing ISP because = of >>> ingress filtering/and the affected packets might be blocked at an >>> outgoing >>> ISP because of ingress filtering, incur additional network charges, or = be >>> misdirected to an attacker's machine/ >>> >>> s/should be communicated through a secure/should communicate through a >>> secure/ >>> >>> s/This issue will not be degraded regardless of the introduction of thi= s >>> option, or regardless/This issue will not be modified by the introducti= on >>> of >>> this option, regardless/ >>> >>> regards, >>> RayH >>> >>> Ole Tr=C5=99an wrote: >>>> >>>> All, >>>> >>>> This message starts a two week 6MAN Working Group on advancing: >>>> >>>> Title : Distributing Address Selection Policy using >>>> DHCPv6 >>>> Author(s) : A. Matsumoto, T. Fujisaki, T. Chown >>>> Filename : draft-ietf-6man-addr-select-opt-06.txt >>>> Pages : 10 >>>> Date : 2012-09-21 >>>> >>>> http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-06 >>>> >>>> as Proposed Standard. Substantive comments and statements of support >>>> for >>>> advancing this document should be directed to the mailing list. >>>> Editorial >>>> suggestions can be sent to the authors. This last call will end on 24= . >>>> October 2012. >>>> >>>> Regards, >>>> >>>> Ole Tr=C5=99an& Bob Hinden >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> >> Ray Hunter >> 10 October 2012 12:00 >> >> I support this work. >> >> Discussion >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Section 4.2 >> s/the default policy should be restored/the previously active policy >> should be restored/ ? >> >> Nits & clarification >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Section 2 >> s/A address selection option contains/An Address Selection option >> contains/ >> >> s/Multiple policy table options in a Policy Table option constitute a >> single policy table./ >> Multiple Policy Table options in an Address Selection option constitute = a >> single policy table./ >> >> s/zero padded/left aligned, big-endian, and zero padded on the right/ >> >> Section 3 >> s/in any messages other/in any DHCPv6 messages other/ >> >> Section 4.1 >> s/his requirement/their own requirements/ >> >> s/a) It receives distributed policy table, and replaces the existing >> policy tables with that. >> b) It preserves the default policy table, or manually configured >> policy./ >> a) replace the existing active policy table with the DHCPv6 distributed >> policy table . >> b) preserve the existing active policy table, whether this be the defaul= t >> policy table, or user configured policy./ >> >> >> Section 4.3 >> s/node-global information by its nature/node-global information by their >> nature/ >> >> s/One of the reason is/One reason being/ >> >> s/multiple address selection policy/multiple address selection policies,= / >> >> s/the effect of both policy/the effect of both policies/ >> >> s/that absence of the distributed policy/that absence of a distributed >> policy/ >> a/mean preference/mean a preference/ >> >> s/deal with multiple received policy/deal with multiple received policie= s/ >> >> s/DHCPv6 clients need to convert this label to a representation specifie= d >> by each implementation/DHCPv6 clients SHOULD convert this label to a >> representation appropriate for the local implementation/ >> >> s/So, the number of the options and the total size of the options should >> be taken care of. Since the number of selection rules could be large, an >> administrator configuring the policy to be distributed should consider t= he >> resulting DHCPv6 message size/ >> Network administrators SHOULD consider local limitations to the maximum >> DHCPv6 message size that can be reliably transported via their specific >> local infrastructure to end nodes; and therefore they SHOULD consider th= e >> number of options, the total size of the options, and the resulting DHCP= v6 >> message size, when defining their Policy Table./ >> >> Section 6: >> >> s/and the affected packets might be blocked at an outgoing ISP because o= f >> ingress filtering/and the affected packets might be blocked at an outgoi= ng >> ISP because of ingress filtering, incur additional network charges, or b= e >> misdirected to an attacker's machine/ >> >> s/should be communicated through a secure/should communicate through a >> secure/ >> >> s/This issue will not be degraded regardless of the introduction of this >> option, or regardless/This issue will not be modified by the introductio= n of >> this option, regardless/ >> >> regards, >> RayH >> >> >> ------------------------------------------------------------------------ > > From n@arifumi.net Mon Oct 22 02:08:23 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61AA121F8C88 for ; Mon, 22 Oct 2012 02:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.827 X-Spam-Level: X-Spam-Status: No, score=-102.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNQvr-pvRNYE for ; Mon, 22 Oct 2012 02:08:21 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id BE26F21F898D for ; Mon, 22 Oct 2012 02:08:12 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so2955170vcb.31 for ; Mon, 22 Oct 2012 02:08:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=Gd0gbiDhz+X47Psw3sp8mewISpfRvmkJQuLJprewPdo=; b=XHeXwsEJvqELUTgea27iw3E6BIxDfVAFr2bHAnwnrYpWH4vAOkvcJrFvyPflJzZyXr EU4iYyeNRf262vmgRU1gHwovGWygmvsjdFBTJ3fnCR2zsAYSPy9zYG0PgpnUsE5v5q73 G7K3dEOja8YJEmOyr7l8jGhLQamhOAR31VgwZFmhUaqQajuOuwlWxqbJ4/6pI+Pa49CT Qp5y+Zd/eiWxQF5gFT5fA6j+HRMDo3+sgWdYu2Gcnl99isNYZR8bRHmChQBpjHSw3lFr a/eYBslXEXflFeqyWqAte1KwgO6iIfcQ3tnmPBE92S8LZNM9ti6TCrK6rcXpqUxusWit Pr4g== MIME-Version: 1.0 Received: by 10.52.91.204 with SMTP id cg12mr10750462vdb.98.1350896892299; Mon, 22 Oct 2012 02:08:12 -0700 (PDT) Sender: n@arifumi.net Received: by 10.58.178.229 with HTTP; Mon, 22 Oct 2012 02:08:12 -0700 (PDT) X-Originating-IP: [192.47.162.190] In-Reply-To: <507D3706.4020300@gmail.com> References: <0D1941A7-217D-44E1-A3E3-45D30D51A273@employees.org> <507D3706.4020300@gmail.com> Date: Mon, 22 Oct 2012 18:08:12 +0900 X-Google-Sender-Auth: zsIyM5tA--F-BY4clhx2gBJwLks Message-ID: Subject: Re: 6MAN WG Last Call: From: Arifumi Matsumoto To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl8bH5S2wA1z2vaYHykDVIjGF1HubW7i6ljbO/AxXdQ7kD9RWA8yG/A7B1030+0jh+vC27e Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org>, "ipv6@ietf.org 6man" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 09:08:23 -0000 Brian, 2012/10/16 Brian E Carpenter : > Hi, > > I support this draft but have a couple of comments. > >> A: Automatic Row Addition flag. This flag toggles the Automatic >> Row Addition flag at client hosts, which is described in the >> section 2.1 in RFC 6724 [RFC6724]. If this flag is set to 1, it >> does not change client host behavior, that is, a client MAY >> automatically add additional site-specific rows to the policy >> table. If set to 0, the Automatic Row Addition flag is >> disabled, and a client MAY NOT automatically add rows to the >> policy table. > > This text includes "MAY NOT" (in upper case). This is specifically not > covered by RFC 2119 because it's unclear. I think we want "MUST NOT" > instead. Or do we want "SHOULD NOT"? The existence of this flag is > a "SHOULD" in RFC 6724. Oops. Thank you for pointing this out. I think "SHOULD NOT" is better. As we do not prohibit manual policy table configuration, so "MUST NOT" should not work. >> P: Privacy Preference flag. This flag toggles the Privacy >> Preference flag at client hosts, which is described in the >> section 5 in RFC 6724 [RFC6724]. If this flag is set to 1, it >> does not change client host behavior, that is, a client SHOULD >> prefer temporary addresses. If set to 0, the Privacy Preference >> flag is disabled, and a client SHOULD prefer public addresses. > > I am a little bothered by those two SHOULDs. It seems to me that they sub= tly > modify what is said in RFC 6724, where the relevant text is quite subtle > already. I would prefer to see the two SHOULD clauses deleted. Alternativ= ely, > s/SHOULD/will/ would better align the text with RFC 6724. It sounds good to me. > > Nit: [I-D.ietf-6man-stable-privacy-addresses] is defined but not used. > I'll delete in the revision. Thanks. > Regards > Brian Carpenter > > On 10/10/2012 09:28, Ole Tr=F8an wrote: >> All, >> >> This message starts a two week 6MAN Working Group on advancing: >> >> Title : Distributing Address Selection Policy using DHCP= v6 >> Author(s) : A. Matsumoto, T. Fujisaki, T. Chown >> Filename : draft-ietf-6man-addr-select-opt-06.txt >> Pages : 10 >> Date : 2012-09-21 >> >> http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-06 >> >> as Proposed Standard. Substantive comments and statements of support fo= r advancing this document should be directed to the mailing list. Editoria= l suggestions can be sent to the authors. This last call will end on 24. O= ctober 2012. >> >> Regards, >> >> Ole Tr=F8an & Bob Hinden >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From tjc@ecs.soton.ac.uk Mon Oct 22 02:19:45 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC75521F8A35 for ; Mon, 22 Oct 2012 02:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAreTKtVAfWV for ; Mon, 22 Oct 2012 02:19:44 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 74E6921F8436 for ; Mon, 22 Oct 2012 02:19:44 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9M9Ijpm014494; Mon, 22 Oct 2012 10:18:45 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q9M9Ijpm014494 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1350897526; bh=lTi5SEAHVxZEZj3dOtToyyKxAQo=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=AvHm5O9/6EqKwP7pLVSqI2HFocf1rS6UFiwfAA8EnKlWV2jYO4Qkbu3IqVhuVzc+z /1o2jLs4If1I5gxQdHu/bbMx5eHNDZ9wb21Ub3i/J8Pul7sIDIfNT5Q8guLScl2xit tqkkIaddSs7w8waAF29AqIyj7F1SOSk/Sm+jq0Lw= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id o9LAIj0430608987KX ret-id none; Mon, 22 Oct 2012 10:18:46 +0100 Received: from ip-205-178.eduroam.soton.ac.uk (ip-205-178.eduroam.soton.ac.uk [152.78.205.178]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9M9IgUK009701 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Oct 2012 10:18:43 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: 6MAN WG Last Call: From: Tim Chown In-Reply-To: Date: Mon, 22 Oct 2012 10:18:49 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <0D1941A7-217D-44E1-A3E3-45D30D51A273@employees.org> <507D3706.4020300@gmail.com> <01D8584E-A436-48C0-8672-A4CC7A048371@ecs.soton.ac.uk> To: Arifumi Matsumoto X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o9LAIj043060898700; tid=o9LAIj0430608987KX; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q9M9Ijpm014494 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org>, "ipv6@ietf.org 6man" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 09:19:45 -0000 On 22 Oct 2012, at 10:08, Arifumi Matsumoto wrote: > Brian, >=20 > 2012/10/16 Brian E Carpenter : >> Hi, >>=20 >> I support this draft but have a couple of comments. >>=20 >>> A: Automatic Row Addition flag. This flag toggles the Automatic >>> Row Addition flag at client hosts, which is described in the >>> section 2.1 in RFC 6724 [RFC6724]. If this flag is set to 1, = it >>> does not change client host behavior, that is, a client MAY >>> automatically add additional site-specific rows to the policy >>> table. If set to 0, the Automatic Row Addition flag is >>> disabled, and a client MAY NOT automatically add rows to the >>> policy table. >>=20 >> This text includes "MAY NOT" (in upper case). This is specifically = not >> covered by RFC 2119 because it's unclear. I think we want "MUST NOT" >> instead. Or do we want "SHOULD NOT"? The existence of this flag is >> a "SHOULD" in RFC 6724. >=20 > Oops. Thank you for pointing this out. >=20 > I think "SHOULD NOT" is better. > As we do not prohibit manual policy table configuration, so "MUST NOT" > should not work. Yes, that sounds better. >>> P: Privacy Preference flag. This flag toggles the Privacy >>> Preference flag at client hosts, which is described in the >>> section 5 in RFC 6724 [RFC6724]. If this flag is set to 1, = it >>> does not change client host behavior, that is, a client = SHOULD >>> prefer temporary addresses. If set to 0, the Privacy = Preference >>> flag is disabled, and a client SHOULD prefer public = addresses. >>=20 >> I am a little bothered by those two SHOULDs. It seems to me that they = subtly >> modify what is said in RFC 6724, where the relevant text is quite = subtle >> already. I would prefer to see the two SHOULD clauses deleted. = Alternatively, >> s/SHOULD/will/ would better align the text with RFC 6724. >=20 > It sounds good to me. We're drifting into similar territory as the M and O flags here. There = was pushback before against introducing an RA option to indicate whether = privacy addresses should be used. So again here I think the flag should = be no more than a hint.=20 It might be good to say 'prefer privacy addresses *where enabled*'. I = think if they're not enabled, e.g. on some server that shares a link = with clients, then the server should not take this hint to enable = privacy addresses. The main use case here seemed to be that raised by Eric, i.e. to avoid = the use of privacy addresses for ULAs within the same site. >> Nit: [I-D.ietf-6man-stable-privacy-addresses] is defined but not = used. >=20 > I'll delete in the revision. I think the stable privacy address draft is good and hope it will = progress, but I agree it's not needed here. I guess the question is = whether such addresses count as public or temporary. The idea of these = addresses is to replace the SLAAC-based public address, so if we did add = a note it would just be to clarify that. Tim > Thanks. >=20 >> Regards >> Brian Carpenter >>=20 >> On 10/10/2012 09:28, Ole Tr=F8an wrote: >>> All, >>>=20 >>> This message starts a two week 6MAN Working Group on advancing: >>>=20 >>> Title : Distributing Address Selection Policy using = DHCPv6 >>> Author(s) : A. Matsumoto, T. Fujisaki, T. Chown >>> Filename : draft-ietf-6man-addr-select-opt-06.txt >>> Pages : 10 >>> Date : 2012-09-21 >>>=20 >>> http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-06 >>>=20 >>> as Proposed Standard. Substantive comments and statements of = support for advancing this document should be directed to the mailing = list. Editorial suggestions can be sent to the authors. This last call = will end on 24. October 2012. >>>=20 >>> Regards, >>>=20 >>> Ole Tr=F8an & Bob Hinden >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From oliver@8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa Mon Oct 22 04:10:31 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B5821F8B66 for ; Mon, 22 Oct 2012 04:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8frV+o7qCVs for ; Mon, 22 Oct 2012 04:10:31 -0700 (PDT) Received: from mail.uptheinter.net (mail.uptheinter.net [IPv6:2001:470:9738::]) by ietfa.amsl.com (Postfix) with ESMTP id E7AB121F84D6 for ; Mon, 22 Oct 2012 04:10:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.uptheinter.net (Postfix) with ESMTP id 47FF1A57AA; Mon, 22 Oct 2012 12:10:13 +0100 (BST) X-DKIM: Sendmail DKIM Filter v2.7.2 mail.uptheinter.net 47FF1A57AA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa; s=default; t=1350904213; bh=c3a e8ymoADLvDk/zcxbyWq377iqB8heXnlkIEzQMEJc=; h=From:To:Cc:Subject: Date:Message-ID:In-Reply-To:References:MIME-Version: Content-Transfer-Encoding:Content-Type; b=yDwlMQhrgy7VWcePAvat32YL ecbsEJrqFQomU4cDDiOABIDODSpj7tj7RrB7c4CYWseKbpBp7iGFtnaZv9oH9s9vTHa 3IKepe5zqoDKqJw/2j91c3k0LlWuhEEkebBc9v0LV6ICykLQHxg2rRYAGNisCmNETv4 wQGYhVTtj/aSg= X-Virus-Scanned: amavisd-new at Received: from mail.uptheinter.net ([127.0.0.1]) by localhost (vps2.uptheinter.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KHETcaW1TtAQ; Mon, 22 Oct 2012 12:10:08 +0100 (BST) From: Oliver To: Mark Smith Subject: Re: Announcing Hashed SLND and other changes to draft-smith-6man-mitigate-nd-cache-dos-slnd Date: Sun, 21 Oct 2012 16:33:34 +0200 Message-ID: <1646383.X0mnybMaTs@gentoovm> User-Agent: KMail/4.8.5 (Linux/3.4.11-4-zerolag-rt19+; KDE/4.8.5; x86_64; ; ) In-Reply-To: <1350853592.3644.YahooMailNeo@web32506.mail.mud.yahoo.com> References: <2823118.ETXEjJL9LI@gentoovm> <1350853592.3644.YahooMailNeo@web32506.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 11:10:31 -0000 On Sunday 21 October 2012 14:06:32 Mark Smith wrote: > Hi, > > > > While I appreciate the enthusiasm for the idea of stateless neighbor > discovery, none of these changes (versions 02 through 04) have gone > through me. I also assume that it is up to me as to whether Oliver becomes > co-author or not, as versions 00 and 01 were my individual work. Mark & relevant parties, Thank you for the clarification. I unreservedly apologise for this faux pas, I was not aware this was inappropriate for the IETF document development process. I hope all can understand that I acted in good faith - once again I apologise for this error, I will re-review the IETF Tao and related RFCs. Kind Regards, Oliver From tjc@ecs.soton.ac.uk Mon Oct 22 04:23:28 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C896B21F897F for ; Mon, 22 Oct 2012 04:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fkn+uCOO+zqP for ; Mon, 22 Oct 2012 04:23:28 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 6A05B21F851B for ; Mon, 22 Oct 2012 04:23:27 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9M9LxED015158; Mon, 22 Oct 2012 10:21:59 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q9M9LxED015158 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1350897719; bh=2L7aHsp2yim9/1/1/d7rcArfehg=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=GmTjeG+jOHz/7dxt0WVusrZyBe79j2cuBiDFEtxPsOw60H8UJpkQwAMYBR+ywUYNm wC3W+4dhoDJ7UHvq32lP5fjzF5N/d6PnWQTKIdlc7J9cdm7tnEgZrq+02AsB5+X/4B MyhB8RMdkcJ0G/pHkqxmLDemxnXSOgfedT/2QrNI= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id o9LALx0430609016yl ret-id none; Mon, 22 Oct 2012 10:21:59 +0100 Received: from ip-205-178.eduroam.soton.ac.uk (ip-205-178.eduroam.soton.ac.uk [152.78.205.178]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9M9LrVq010419 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Oct 2012 10:21:54 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: 6MAN WG Last Call: From: Tim Chown In-Reply-To: Date: Mon, 22 Oct 2012 10:22:00 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <0D1941A7-217D-44E1-A3E3-45D30D51A273@employees.org> <50754741.9090506@globis.net> <507D78AA.7020502@globis.net> <3BC7566D-CC2B-4B8A-A186-6EA840EB9341@ecs.soton.ac.uk> To: Arifumi Matsumoto X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o9LALx043060901600; tid=o9LALx0430609016yl; client=relay,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q9M9LxED015158 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: Ray Hunter , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 11:23:28 -0000 On 22 Oct 2012, at 10:00, Arifumi Matsumoto wrote: >=20 > 2012/10/17 Ray Hunter : >>=20 >> It's really a question of if we need to further clarify what is meant = by >> "default policy" in Section 4.2 of = draft-ietf-6man-addr-select-opt-06. >>=20 >> Is it the manually configured node-specific default, or the RFC6724 = section >> 2.1 default policy table, or is this behaviour simply implementation >> dependent and we should remain silent on an appropriate default? >=20 > IMHO, it should be complex to allow to receive distributed policy even > when the policy is manually configured. However, I agree that it = should be > out-of-scope of this document. This document should just state the > requirements as in 4.1. The idea in the original discussions was that 'default policy' meant the = default described in the RFC, rather than something local to the site. = After all, the reason a site may be using this DHCPv6 option is to = change that default. Tim= From tjc@ecs.soton.ac.uk Mon Oct 22 05:53:58 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814F221F8B13 for ; Mon, 22 Oct 2012 05:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.866 X-Spam-Level: X-Spam-Status: No, score=-1.866 tagged_above=-999 required=5 tests=[AWL=-0.658, BAYES_00=-2.599, HTML_MESSAGE=0.001, PLING_QUERY=1.39] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCQnSVSPJ6bt for ; Mon, 22 Oct 2012 05:53:57 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id B9BBB21F8A87 for ; Mon, 22 Oct 2012 05:53:56 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9MCrsnW004015 for ; Mon, 22 Oct 2012 13:53:54 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q9MCrsnW004015 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1350910434; bh=ol2Npzk9o5eS9qw5EmTE1YMPDGw=; h=From:Mime-Version:Subject:Date:References:To:In-Reply-To; b=31MqQlR5UZYvjXyduQjaaGBJcS3i4UCpDku3eoUoyyiqK1kHlTdKkOC2kg7YaA4A5 GHzTjWbDHIzpaOMGo+JLp4NhsDHngcZ0XeZzT7DpL9/XJQXBvlacY8ykMbJYql5zgH LA3cnpy95r5HVxmSGGrR/qJnBpoZlf1hDnLgHYIo= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id o9LDrs0430611259BG ret-id none; Mon, 22 Oct 2012 13:53:54 +0100 Received: from ip-205-178.eduroam.soton.ac.uk (ip-205-178.eduroam.soton.ac.uk [152.78.205.178]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9MCroUH019179 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 22 Oct 2012 13:53:50 +0100 From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_9553EA12-3A99-4904-88B9-34DD32867D3A" Message-ID: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Win7 - no managed flag, DHCP address released?!? Date: Mon, 22 Oct 2012 13:53:49 +0100 References: <1350563448.2987.14.camel@karl> <1350864259.15057.YahooMailNeo@web32502.mail.mud.yahoo.com> <83C07165-A450-4E7D-93FC-E17121D6B593@ecs.soton.ac.uk> To: IETF IPv6 In-Reply-To: <1350864259.15057.YahooMailNeo@web32502.mail.mud.yahoo.com> X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o9LDrs043061125900; tid=o9LDrs0430611259BG; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q9MCrsnW004015 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 12:53:59 -0000 --Apple-Mail=_9553EA12-3A99-4904-88B9-34DD32867D3A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 22 Oct 2012, at 01:04, Mark Smith wrote: > Hi Karl, >=20 >=20 > ----- Original Message ----- >> From: Karl Auer >> To: IETF IPv6 >> Cc:=20 >> Sent: Thursday, 18 October 2012 11:30 PM >> Subject: Win7 - no managed flag, DHCP address released?!? >>=20 >> My apologies if this is not the right list for this comment/question; >> suggestions for alternatives are welcome. >>=20 >> I have just seen the following demonstrated. >>=20 >> Two routers, short RA interval, both sending RAs for the same prefix, >> both with the autoconf flag set, one with the managed flag set and = one >> without. >> =20 >=20 > So to be clear,=20 >=20 > RA1 - M=3D1, O=3D1, PIO: pfx=3D2001:db8:0:1::/64, L=3D1, A=3D1 > RA2 - M=3D0, O=3D1, PIO: pfx=3D2001:db8:0:1::/64, L=3D1, A=3D1 >=20 > 6.2.7, "Router Advertisement Consistency" in RFC4861 does say routers = should >=20 > check the RAs from other routers, and log inconsistencies, as it = indicates > that a misconfiguration has occurred. The M and O bits are = specifically > mentioned. >=20 > Although the M bit is a whole of link flag as it is global in the RA, >=20 > rather than being a prefix specific flag, the definition of the M bit = in > RFC4861 seems to only indicate to attempt stateful DHCPv6, rather than > also override the A bit in any received PIOs: >=20 >=20 > M 1-bit "Managed address configuration" flag. When > set, it indicates that addresses are available = via > Dynamic Host Configuration Protocol [DHCPv6]. >=20 > If the M flag is set, the O flag is redundant and > can be ignored because DHCPv6 will return all > available configuration information. >=20 > Looking a bit further, RFC4861 says that (6.3.4) >=20 > When multiple routers are present, the information advertised > collectively by all routers may be a superset of the information > contained in a single Router Advertisement. Moreover, information > may also be obtained through other dynamic means like DHCPv6. = Hosts > accept the union of all received information; the receipt of a = Router > Advertisement MUST NOT invalidate all information received in a > previous advertisement or from another source. However, when > received information for a specific parameter (e.g., Link MTU) or > option (e.g., Lifetime on a specific Prefix) differs from = information > received earlier, and the parameter/option can only have one value, > the most recently received information is considered authoritative. >=20 > So I'd say Windows 7 is doing the wrong thing if the M bit changes = from >=20 > 1 to 0. It should stop using DHCPv6 from that point onwards to acquire > or refresh addresses, but still should respect the preferred and > valid lifetimes of the addresses it previously acquired using DHCPv6. = It > should also perform SLAAC using the RA PIOs with the A bits, = independently > of the value of the M bit. >=20 > It seems that an exclusively stateful DHCPv6 or SLAAC model has been >=20 > adopted by Windows 7, rather than a stateful DHCPv6 and/or SLAAC = model, > which is what RFC4861 provides. RFC4861's model would allow the = addition > of a stateful DHCPv6 server to a formerly SLAAC only link, or vice = versa, > and facilitate a phased rather than disruptive move to a SLAAC > only or stateful DHCPv6 only operation if that is the goal. >> A Windows 7 host gets an address via DHCPv6 when the RA with the = managed >> flag comes around - and DROPS IT when an RA without the managed flag >> comes past. >>=20 >> This is not the valid lifetime expiring normally. I was not able to >> determine whether the Windows host is actually sending a DHCPv6 = release >> as well, but it is most certainly dropping the address from the >> interface. >>=20 >> I will be trying to do my own tests to confirm (or not) this = behaviour, >> but has anyone else seen it? Or seen it with other operating systems? >>=20 >> If it is indeed happening, this behaviour seems very badly broken to = me. >> I don't feel the relevant RFCs can reasonably be interpreted as >> supporting this behaviour. Part of the problem here is the whole long-running issue with the 'soft' = nature of the M and O flags. Their semantics have been diluted in the = update of the SLAAC RFC. Many people I think would be happy to see them = gone completely. I think there's two questions here. One is what a host should do if it = receives conflicting information from the same sender. The other is what = to do if conflicting information comes from two senders. This issue has come up recently in 6renum discussions, actually from = Karl as well :) http://www.ietf.org/mail-archive/web/ipv6/current/msg16179.html The discussion there was about the former case - successive RAs from a = single sender changing. There may be valid reasons for the M/O bit = values changing, e.g. to move from a DHCPv6 model to a SLAAC model for = address management. In such a case you would probably expect the 'old' = address to be deprecated, similar to the approach in RFC4192, such that = it is still valid, but not preferred for new connections. Which is = pretty much what Karl said in that thread. The example being considered here with two senders and inconsistent = settings is a misconfiguration. The inconsistency should be logged and = corrected, regardless of what the host behaviour is. If the second RA is = a rogue, then methods for rogue RA suppression should be in place. A similar discussion could be had if each RA carried different DNS = resolver addresses in the RFC6106 option. That RFC says "configurations = where different information is provided by different sources may lead to = problems. Therefore, the network administrator needs to configure DNS = options in multiple sources in order to prevent such problems from = happening." A similar argument. Tim --Apple-Mail=_9553EA12-3A99-4904-88B9-34DD32867D3A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 markzzzsmith@yahoo.com.au>= ; wrote:
Hi Karl,


----- Original Message = -----
From: Karl Auer <kauer@biplane.com.au>
To: = IETF IPv6 <ipv6@ietf.org>
Cc:
Sent: = Thursday, 18 October 2012 11:30 PM
Subject: Win7 - no managed flag, = DHCP address released?!?

My apologies if this is not the right = list for this comment/question;
suggestions for alternatives are = welcome.

I have just seen the following demonstrated.

Two = routers, short RA interval, both sending RAs for the same = prefix,
both with the autoconf flag set, one with the managed flag = set and one
without.
 

So to be = clear, 

RA1 - M=3D1, O=3D1, PIO: pfx=3D2001:db8:0:1::/64, = L=3D1, A=3D1
RA2 - M=3D0, O=3D1, PIO: pfx=3D2001:db8:0:1::/64, = L=3D1, A=3D1

6.2.7, "Router Advertisement Consistency" in RFC4861 = does say routers should

check the RAs from other routers, and log = inconsistencies, as it indicates
that a misconfiguration has = occurred. The M and O bits are = specifically
mentioned.

Although the M bit is a whole of link = flag as it is global in the RA,

rather than being a prefix = specific flag, the definition of the M bit in
RFC4861 seems to only = indicate to attempt stateful DHCPv6, rather than
also override the A = bit in any received PIOs:


     M     =          1-bit "Managed address configuration" = flag.  When
              =        set, it indicates that addresses are = available via
                =      Dynamic Host Configuration Protocol = [DHCPv6].

                =      If the M flag is set, the O flag is redundant = and
                  =    can be ignored because DHCPv6 will return all
  =                   =  available configuration information.

Looking a bit further, = RFC4861 says that (6.3.4)

   When multiple routers are = present, the information advertised
   collectively by all = routers may be a superset of the information
   contained = in a single Router Advertisement.  Moreover, information
  =  may also be obtained through other dynamic means like DHCPv6. =  Hosts
   accept the union of all received = information; the receipt of a Router
   Advertisement MUST = NOT invalidate all information received in a
   previous = advertisement or from another source.  However, when
  =  received information for a specific parameter (e.g., Link MTU) = or
   option (e.g., Lifetime on a specific Prefix) differs = from information
   received earlier, and the = parameter/option can only have one value,
   the most = recently received information is considered authoritative.

So I'd = say Windows 7 is doing the wrong thing if the M bit changes = from

1 to 0. It should stop using DHCPv6 from that point onwards = to acquire
or refresh addresses, but still should respect the = preferred and
valid lifetimes of the addresses it previously acquired = using DHCPv6. It
should also perform SLAAC using the RA PIOs with the = A bits, independently
of the value of the M bit.

It seems that = an exclusively stateful DHCPv6 or SLAAC model has been

adopted by = Windows 7, rather than a stateful DHCPv6 and/or SLAAC model,
which is = what RFC4861 provides. RFC4861's model would allow the addition
of a = stateful DHCPv6 server to a formerly SLAAC only link, or vice = versa,
and facilitate a phased rather than disruptive move to a = SLAAC
only or stateful DHCPv6 only operation if that is the = goal.
A Windows 7 host gets an address via = DHCPv6 when the RA with the managed
flag comes around - and DROPS IT = when an RA without the managed flag
comes past.

This is not = the valid lifetime expiring normally. I was not able to
determine = whether the Windows host is actually sending a DHCPv6 release
as = well, but it is most certainly dropping the address from = the
interface.

I will be trying to do my own tests to confirm = (or not) this behaviour,
but has anyone else seen it? Or seen it with = other operating systems?

If it is indeed happening, this = behaviour seems very badly broken to me.
I don't feel the relevant = RFCs can reasonably be interpreted as
supporting this = behaviour.

Part of the = problem here is the whole long-running issue with the 'soft' nature of = the M and O flags. Their semantics have been diluted in the update of = the SLAAC RFC. Many people I think would be happy to see them gone = completely.

I think there's two questions here. One is = what a host should do if it receives conflicting information from the = same sender. The other is what to do if conflicting information = comes from two senders.

This issue has come up = recently in 6renum discussions, actually from Karl as well = :)

The discussion there was about the former case - = successive RAs from a single sender changing. There may be valid = reasons for the M/O bit values changing, e.g. to move from a DHCPv6 = model to a SLAAC model for address management. In such a case you would = probably expect the 'old' address to be deprecated, similar to the = approach in RFC4192, such that it is still valid, but not preferred for = new connections.  Which is pretty much what Karl said in that = thread.

The example being considered here with = two senders and inconsistent settings is a misconfiguration. The = inconsistency should be logged and corrected, regardless of what the = host behaviour is. If the second RA is a rogue, then methods for rogue = RA suppression should be in place.

A similar = discussion could be had if each RA carried different DNS resolver = addresses in the RFC6106 option. That RFC says "configurations where = different information is provided by different sources may lead to = problems. Therefore, the network administrator needs to configure = DNS options in multiple sources in order to prevent such problems = from happening." A similar = argument.

Tim

= --Apple-Mail=_9553EA12-3A99-4904-88B9-34DD32867D3A-- From barryleiba@computer.org Mon Oct 22 06:31:55 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB91621F8B8C; Mon, 22 Oct 2012 06:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4tk1mv+5m7s; Mon, 22 Oct 2012 06:31:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5A321F8B81; Mon, 22 Oct 2012 06:31:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Barry Leiba" To: The IESG Subject: Barry Leiba's Discuss on draft-ietf-6man-udpzero-07: (with DISCUSS) X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022133155.29924.73732.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 06:31:55 -0700 Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, draft-ietf-6man-udpzero@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 13:31:56 -0000 Barry Leiba has entered the following ballot position for draft-ietf-6man-udpzero-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- See my DISCUSS for draft-ietf-6man-udpchecksums: http://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums/ballot/ Update for -07: This is exactly what I had in mind. Assuming that the WG is happy with this, when the corresponding changes are made to the udpchecksums doc my concerns will be well addressed. From gorry@erg.abdn.ac.uk Mon Oct 22 06:37:58 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5331621F8BCB; Mon, 22 Oct 2012 06:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.417 X-Spam-Level: X-Spam-Status: No, score=-102.417 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3MCFBoG6vZT; Mon, 22 Oct 2012 06:37:57 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 83E0621F8BCA; Mon, 22 Oct 2012 06:37:54 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 8AE492B4356; Mon, 22 Oct 2012 14:37:53 +0100 (BST) Received: from 88.210.175.129 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Mon, 22 Oct 2012 14:37:53 +0100 Message-ID: <1d78f5b6c22a2fd31af8f320267c22af.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <20121022133155.29924.73732.idtracker@ietfa.amsl.com> References: <20121022133155.29924.73732.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 14:37:53 +0100 Subject: Re: Barry Leiba's Discuss on draft-ietf-6man-udpzero-07: (with DISCUSS) From: gorry@erg.abdn.ac.uk To: "Barry Leiba" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-udpzero@tools.ietf.org, ipv6@ietf.org, The IESG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 13:37:58 -0000 That is helpful. There's obviously a few details to be sorted in this rearrangement of text (and some other people's comments still to incorporate), we now need to affirm we are on the correct path. Magnus and I will liaise and work with the 6man chairs. Thanks for the feedback, Gorry > Barry Leiba has entered the following ballot position for > draft-ietf-6man-udpzero-07: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > See my DISCUSS for draft-ietf-6man-udpchecksums: > http://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums/ballot/ > > Update for -07: > This is exactly what I had in mind. Assuming that the WG is happy with > this, when the corresponding changes are made to the udpchecksums doc my > concerns will be well addressed. > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From v6ops@globis.net Mon Oct 22 06:44:10 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD5321F8476 for ; Mon, 22 Oct 2012 06:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.791 X-Spam-Level: X-Spam-Status: No, score=-2.791 tagged_above=-999 required=5 tests=[AWL=0.808, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SS5n8VwEIL4U for ; Mon, 22 Oct 2012 06:44:09 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 265D421F8475 for ; Mon, 22 Oct 2012 06:44:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id C21F28700AC; Mon, 22 Oct 2012 15:38:51 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cU8LrK1aMblS; Mon, 22 Oct 2012 15:38:23 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id DA76D87002E; Mon, 22 Oct 2012 15:38:22 +0200 (CEST) Message-ID: <50854C48.4050808@globis.net> Date: Mon, 22 Oct 2012 15:38:16 +0200 From: Ray Hunter User-Agent: Postbox 3.0.5 (Macintosh/20120826) MIME-Version: 1.0 To: Tim Chown Subject: Re: Re: 6MAN WG Last Call: References: <0D1941A7-217D-44E1-A3E3-45D30D51A273@employees.org> <50754741.9090506@globis.net> <507D78AA.7020502@globis.net> <3BC7566D-CC2B-4B8A-A186-6EA840EB9341@ecs.soton.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 13:44:10 -0000 Tim Chown wrote: > On 22 Oct 2012, at 10:00, Arifumi Matsumoto wrote: > >> 2012/10/17 Ray Hunter : >>> It's really a question of if we need to further clarify what is meant by >>> "default policy" in Section 4.2 of draft-ietf-6man-addr-select-opt-06. >>> >>> Is it the manually configured node-specific default, or the RFC6724 section >>> 2.1 default policy table, or is this behaviour simply implementation >>> dependent and we should remain silent on an appropriate default? >> IMHO, it should be complex to allow to receive distributed policy even >> when the policy is manually configured. However, I agree that it should be >> out-of-scope of this document. This document should just state the >> requirements as in 4.1. > > The idea in the original discussions was that 'default policy' meant the default described in the RFC, rather than something local to the site. After all, the reason a site may be using this DHCPv6 option is to change that default. > > Tim Not necessarily. In the days of highly mobile nodes, the concept of site is going to become vague. Any manual configured policy on a node is likely to be node specific, and not site specific. It might even be that the manual config detects network settings before becoming active. e.g. based on local interface address ranges. There's plenty examples of this today in e.g. Windows. The network operator may want to positively hint to the end node that it should be running the RFC6724 defined default policy on this network (and not some manually configured policy used by this node when connected to other networks.) I agree that it is possible to implement this behavior by the network operator configuring an explicit DHCPv6 policy table that matches the RFC6724 default table, and the user accepting this policy as defined in 4.1. I believe in symmetry, so handling stale DHCPv6 information should really be the reverse process of 4.1 For example, when the DHCPv6 policy expires (due to a timeout, or the end node disconnecting from the network), you could get a situation where the user has accepted a DHCPv6 distributed policy from network X, but they may revert to a connection to another network Y that does not support DHCPv6 distributed policy, but does require a manually configured policy. Then it would make sense to install the manually configured policy. Equally, they may also still be connected to network X and it's just the DHCPv6 that has timed out. In which case keeping the DHCPv6 policy active might be the correct thing to do. Or they might be connected to a completely new network, in which case the RFC6724 default is appropriate. I therefore think it probably should then be left to the end node whether the end node should reactivate the manually configured (node default) policy, or the RFC6724 defined default policy, or keep the DHCPv6 learned policy active even though it has timed out. Suggested text for Section 4.2 s/When the information from the DHCP server goes stale, the policy received form the DHCP server should be removed and the default policy should be restored./When the information from the DHCP server goes stale, the policy received from the DHCP server should be deprecated./ Optionally add to 4.2. /Which policy should then become active is a matter for the local implementation./ regards, RayH From alexandru.petrescu@gmail.com Mon Oct 22 09:50:36 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F18221F89C5 for ; Mon, 22 Oct 2012 09:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.438 X-Spam-Level: X-Spam-Status: No, score=-9.438 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_65=0.6, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihyCQyhsMIdQ for ; Mon, 22 Oct 2012 09:50:35 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 1858D21F894D for ; Mon, 22 Oct 2012 09:50:34 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q9MGoTr0010163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Oct 2012 18:50:29 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q9MGoSsd002420; Mon, 22 Oct 2012 18:50:28 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q9MGoO6k026724; Mon, 22 Oct 2012 18:50:28 +0200 Message-ID: <50857951.90609@gmail.com> Date: Mon, 22 Oct 2012 18:50:25 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Mikael Abrahamsson Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> <5082E933.60205@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:50:36 -0000 Le 20/10/2012 22:08, Mikael Abrahamsson a écrit : > On Sat, 20 Oct 2012, Alexandru Petrescu wrote: > >> But with vehicles, one connects a vehicle here and gets a prefix, >> then moves in that area and gets another prefix. At that point, if >> the router obtaining a prefix wants to delegate further to another >> vehicle needs to change the delegated prefix. >> >> This dynamic change between the received prefix and the delegated >> prefix is not a matter of DHCP. It can be implemented by like >> scripting which are independent of DHCP implementation. One has to >> touch the conf files be it of DHCP or of ND. > > I'm sorry. I don't follow your reasoning. > > Could you please write some text with a clear use case where > DHCPv6-PD can't be used for what you want to do, thus justifying why > your proposal is needed? Please keep it at a protocol level, not > implementation level. Writing this text is feasible. Let me first try an explanation here. This topology is extracted from the draft. Is this kind of explanation what would make sense? +----------+ | INTERNET | | ACCESS | +-----+----+ | | E2 | +-------------------------+ +-------------------------+ | | | | | | | | | | | +-----------+ | E1 E1 | +-----------+ | | | MR-LV |------|---------------|------| MR-IV | | | +-----------+ | | +-----------+ | | I1 | | | I1 | | | | | | | | | --------+-------- | | --------+-------- | | | | | | | | | | | | LFN-1 LFN-2 ... LFN-x | | LFN-1 LFN-2 ... LFN-x | | | | | +-------------------------+ +-------------------------+ Leaf Vehicle Internet Vehicle We need MR-LV to be a DHCP Client and acquire a prefix that is topologically correct both at MR-IV and in the infrastructure, to avoid risks of ingress filtering. Using DHCP-PD for LV in this figure can be done in two ways: (1) MR-IV is a Client+Server or (2) MR-IV is a Client+Relay. In first case it has the drawback that it has to change the prefix it delegates as Server each time it acquires a new prefix as Client. This functionality is not part of DHCP. Besides, the management of different parts (Client and Server) of DHCP software on same machine may be cumbersome if I can say so. Add that at times, there may be a need of a third part of DHCP, a Client which requests a prefix over a tunnel not over the real iface (DHCP-PD for NEMO). This becomes complex DHCP on same machine. For the second case - MR-IV is a Client and a Relay, we assume that the Server is in the infrastructure and not on MR-IV. At that point, whenever the MR-IV Client changes its IP address, the Relay running on the MR-IV must inform the Server about its new IP address. Otherwise the relationship between Relay and Server can't work. This is not part of DHCP and doesnt exist as far as I can tell. Finally, the connection between MR-LV and MR-IV is a link which does not use global addresses - only link local addresses. MR-LV does not require an IP address from anywhere. It only needs a prefix for its LFNs. The DHCP it may use to acquire that prefix is only a DHCP for a prefix, not for addresses. At that point we may end up with a requirement that _both_ DHCP _and_ ND to run on MR-LV. But MR-LV may prefer to just run one protocol, not two. Because small. If MR-LV must choose between which to run - ND or DHCP? It will choose ND because it's the only one to give a default route. But ND doesn't give it Prefix Delegation. Hence enhance ND with PD. >>> What is cleaner is to use existing standards where there already >>> is running code. >> >> Right, there is cleanliness in reuse. Reuse as much as possible. > > Then why do you feel the need to create something new when there > already is existing standards that will achieve the same thing? For several reasons as expressed above. IT would be good to have only one protocol to achieve this V2V2I but as it stands today it requires two: ND and DHCP. Second, DHCP has some issues described according to logic above. >> In addition to FOSS (what is FOSS?) DHCP one also needs to >> dynamically change the delegated prefix when the assigned prefix >> changed. > > FOSS = Free and Open Source Software. > >> WEll yes, I agree that IPv6 should be kept stable and part of that >> may be that we try to make sure that a new proposal does not break >> existing implementation. This is a matter of further work. > > I'd say it's an absolute requirement that any proposal do not break > existing implementations. Yes, noted and set aside to always consider it in further design. Alex > From alexandru.petrescu@gmail.com Mon Oct 22 09:55:17 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3A411E80D7 for ; Mon, 22 Oct 2012 09:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.008 X-Spam-Level: X-Spam-Status: No, score=-10.008 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhA76RhBY5Al for ; Mon, 22 Oct 2012 09:55:12 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 1892D21F895C for ; Mon, 22 Oct 2012 09:55:00 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q9MGt0T6011537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 22 Oct 2012 18:55:00 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q9MGt0Eu003080 for ; Mon, 22 Oct 2012 18:55:00 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q9MGsxX7028047 for ; Mon, 22 Oct 2012 18:54:59 +0200 Message-ID: <50857A63.3030102@gmail.com> Date: Mon, 22 Oct 2012 18:54:59 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> <5082E933.60205@gmail.com> <50831CF0.7050106@inria.fr> In-Reply-To: <50831CF0.7050106@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:55:17 -0000 Le 20/10/2012 23:51, Thierry Ernst a écrit : > > Dear Alex, > > Would you explain why the vehicle would need to get a new prefix (and > thus I assume configure all the nodes in the vehicle) every time it > enters a new area ? Well, whenever MR of a vehicle changes its attachment point it would get a new different address, right? I can only suppose it would get a different delegated prefix as well. It's hard to imagine that it would get a different address but a same delegated prefix, no? (it's hard to make same prefix valid at so many different places, harder than doing it with addresses and it's not done with them). Or do you ask why LV gets a new prefix when IV changes its prefix? I think this is obvious, no? (for topological correctness, right?) Or do you ask from the NEMO perspective? In this V2V2I work we first consider there's no MIP nor NEMO neither on IV nor on LV. We'll see later about adding MIP. We can discuss it as well, see how MIP would fit in this. Is this answering in the direction you made the question? Alex > > Thierry > > > On 20/10/12 20:10, Alexandru Petrescu wrote: >> Le 20/10/2012 18:42, Mikael Abrahamsson a écrit : >>> On Sat, 20 Oct 2012, Alexandru Petrescu wrote: >>> >>>> One point that guided towards choosing ND over DHCP is >>>> topology. DHCP topology can be relatively complex with >>>> Client/Relay/Server, whereas ND is simpler one-on-one. >>> >>> There is nothing saying DHCPv6-PD can't be done in a single >>> device (the router itself). That's what I do in my home, cisco >>> router, local DHCPv6-PD pool, local DHCPv6-PD server, also >>> installing routes into RIB. >> >> YEs, because at home one typically puts up the interface once a >> month and gets typically the same prefix from ADSL operator as 1 >> year before. >> >> But with vehicles, one connects a vehicle here and gets a prefix, >> then moves in that area and gets another prefix. At that point, if >> the router obtaining a prefix wants to delegate further to another >> vehicle needs to change the delegated prefix. >> >> This dynamic change between the received prefix and the delegated >> prefix is not a matter of DHCP. It can be implemented by like >> scripting which are independent of DHCP implementation. One has to >> touch the conf files be it of DHCP or of ND. >> >>>> _and_ Relay (or Server). This may be feasible in practice but >>>> I think it would be cleaner to have distinct protocols on a >>>> same machine for receiving a prefix and for sending a prefix. >>> >>> What is cleaner is to use existing standards where there already >>> is running code. >> >> Right, there is cleanliness in reuse. Reuse as much as possible. >> >>>> There is also the question of availability of DHCP software on >>>> smaller platforms which have no SIM card. It may be easier to >>>> do this with ND in smaller settings. >>> >>> I'd imagine that there already are 2-3 existing FOSS available >>> implementations that do what you need for DHCPv6-PD client and >>> server. Instead you want to invent a new standard and create new >>> code. >> >> In addition to FOSS (what is FOSS?) DHCP one also needs to >> dynamically change the delegated prefix when the assigned prefix >> changed. >> >>> I'm not saying this shouldn't be done, I'm just saying I don't >>> really see the rationale for it. I used to hate DHCPv6 role in >>> IPv6, but after a few years of being exposed to it, I've come to >>> accept that this is the way it is. There is code going back to a >>> standard Windows Vista that correctly implements DHCPv6-PD >>> client, and that is what, 5-6 years ago it was released? I've had >>> PD in my home on Cisco code for 3-5 years already, with no server >>> infrastructure at all, just single device doing "everything" for >>> the role needed. >>> >>> If this was 2002, I'd agree with you that ND PD could be >>> feasable, but I believe the train has already left the station >>> and we should focus on keeping IPv6 stable when it comes to how >>> it works, and get implementations going, not new standards. >> >> WEll yes, I agree that IPv6 should be kept stable and part of that >> may be that we try to make sure that a new proposal does not break >> existing implementation. This is a matter of further work. >> >> Alex >> >> -------------------------------------------------------------------- >> >> IETF IPv6 working group mailing list >> ipv6@ietf.org Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > >> > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From alexandru.petrescu@gmail.com Mon Oct 22 09:56:44 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC6021F842F for ; Mon, 22 Oct 2012 09:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.025 X-Spam-Level: X-Spam-Status: No, score=-10.025 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnpqtFHtZMh0 for ; Mon, 22 Oct 2012 09:56:41 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id C03FD21F8A0F for ; Mon, 22 Oct 2012 09:56:40 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q9MGud0D012045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 22 Oct 2012 18:56:39 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q9MGud6b003273 for ; Mon, 22 Oct 2012 18:56:39 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q9MGuc4f028470 for ; Mon, 22 Oct 2012 18:56:39 +0200 Message-ID: <50857AC7.5070404@gmail.com> Date: Mon, 22 Oct 2012 18:56:39 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:56:44 -0000 Le 21/10/2012 02:45, Hesham Soliman a écrit : >> >> The obvious conclusion to this argument is that a *lot* of DHCP >> functionality will be duplicated in ND. Is this where we want to >> go? >> >> I'm coming from the DHCP side of the argument. In my world DHCP is >> needed because it gives you a single place to handle dynamic >> address allocation, *and* it ties in with all sorts of support & >> backend systems. > > => Agreed. I'm not coming from a DHCP side of the argument but I see > the only reason for having this feature is that some people think > adding/implementing this in ND is more convenient than adding a DHCP > agent/relay. I don't agree. But even if that's the truth, it seems to > be six of one and half dozen of the other. No compelling reason > AFAICS. There is already ND on MR-LV and MR-IV. And it's not enough to do Prefix Delegation. We add a new protocol DHCP-PD but that is not enough per se, it needs ND. I wonder why do we always have to use two protocols when one should be sufficient. Alex > > Hesham > > >> >> I am against adding lots of new ND functionality until we have >> DHCPv6 that is considerably more feature complete. Some of this is >> probably coming (client MAC address), some of it is still being >> opposed for mostly religious reasons (e.g. running DHCP without >> RA). >> >> Steinar Haug, AS 2116 >> -------------------------------------------------------------------- >> >> IETF IPv6 working group mailing list >> ipv6@ietf.org Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > From alexandru.petrescu@gmail.com Mon Oct 22 09:58:17 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4924C21F8B7E for ; Mon, 22 Oct 2012 09:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.04 X-Spam-Level: X-Spam-Status: No, score=-10.04 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcr6ZO-VhEAo for ; Mon, 22 Oct 2012 09:58:14 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id E642021F8B76 for ; Mon, 22 Oct 2012 09:58:13 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q9MGw6LL011914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Oct 2012 18:58:06 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q9MGw5Wm003518; Mon, 22 Oct 2012 18:58:06 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q9MGw5Z6028814; Mon, 22 Oct 2012 18:58:05 +0200 Message-ID: <50857B1D.3060500@gmail.com> Date: Mon, 22 Oct 2012 18:58:05 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Mark Smith Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt References: <5082C948.3080109@gmail.com> <20121020.183628.74709756.sthaug@nethelp.no> <5082E5CC.90502@gmail.com> <1350855918.42829.YahooMailNeo@web32503.mail.mud.yahoo.com> In-Reply-To: <1350855918.42829.YahooMailNeo@web32503.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:58:17 -0000 Le 21/10/2012 23:45, Mark Smith a écrit : > > > > > ----- Original Message ----- >> From: Alexandru Petrescu >> To: sthaug@nethelp.no >> Cc: ipv6@ietf.org >> Sent: Sunday, 21 October 2012 4:56 AM >> Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt >> >> Le 20/10/2012 18:36, sthaug@nethelp.no a écrit : >>>> There is also the question of availability of DHCP software on >>>> smaller platforms which have no SIM card. It may be easier to do >>>> this with ND in smaller settings. >>> >>> The obvious conclusion to this argument is that a *lot* of DHCP >>> functionality will be duplicated in ND. Is this where we want to go? >> >> I guess yes, and vice-versa. >> >>> I'm coming from the DHCP side of the argument. In my world DHCP is >>> needed because it gives you a single place to handle dynamic address >>> allocation, *and* it ties in with all sorts of support & backend >>> systems. >> >> Well yes, when that backend is a fixed infrastructure with things >> planned, highly human assisted. But in a dynamic yet simple network >> (without assistance of various backend) it's hard to use DHCP: a Relay >> can't 'discover' a Server, > > > Actually it can, as the destination address for the server the relay uses > can be the all-dhcp-serviers site-local (FF05:0:0:0:0:0:1:3) multicast > address. DHCPv6 uses multicast addresses where ever possible for these > sorts of scenario. But isn't it that the DHCPv6 server must have a conf file which records in a fixed way the Relay's IP address? Alex Geographically distributed DHCPv6 servers can then be > a member of a multicast that spans locations across the network. > > > RFC3315, 5.1. Multicast Addresses > > DHCP makes use of the following multicast addresses: > > All_DHCP_Relay_Agents_and_Servers (FF02::1:2) A link-scoped > multicast address used by a client to communicate with > neighboring (i.e., on-link) relay agents and servers. > All servers and relay agents are members of this > multicast group. > > All_DHCP_Servers (FF05::1:3) A site-scoped multicast address used > by a relay agent to communicate with servers, either > because the relay agent wants to send messages to > all servers or because it does not know the unicast > addresses of the servers. Note that in order for > a relay agent to use this address, it must have an > address of sufficient scope to be reachable by the > servers. All servers within the site are members of > this multicast group. > > > From alexandru.petrescu@gmail.com Mon Oct 22 10:06:31 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DCE21F894D for ; Mon, 22 Oct 2012 10:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.053 X-Spam-Level: X-Spam-Status: No, score=-10.053 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MAqc2lq6Wu7 for ; Mon, 22 Oct 2012 10:06:28 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1BD21F88F5 for ; Mon, 22 Oct 2012 10:06:28 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q9MH6Rin013941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 22 Oct 2012 19:06:27 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q9MH6R9V005202 for ; Mon, 22 Oct 2012 19:06:27 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q9MH6NGq026693 for ; Mon, 22 Oct 2012 19:06:26 +0200 Message-ID: <50857D0F.5070307@gmail.com> Date: Mon, 22 Oct 2012 19:06:23 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt References: <5082C948.3080109@gmail.com> <20121020.183628.74709756.sthaug@nethelp.no> <5082E5CC.90502@gmail.com> <1350855918.42829.YahooMailNeo@web32503.mail.mud.yahoo.com> <1350863554.3457.88.camel@karl> <1350867264.15372.YahooMailNeo@web32505.mail.mud.yahoo.com> In-Reply-To: <1350867264.15372.YahooMailNeo@web32505.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:06:31 -0000 Le 22/10/2012 02:54, Mark Smith a écrit : [...] > off. My point was that there is a method available for a relay to > discover DHCPv6 servers without the configuration issues related to > only being able to use a specific GUA or ULA unicast address. Well, the use of multicast to identify the servers may indeed seen as a good way towards discovering a server. But that would assume the IP multicast is working beyond just one link. Which is good if it is deployed, but is it. Shoudl one require PIM-SM in the infrastructure in order to make sure that DHCP-PD works on a road between an LV and an IV? I doubt. (as with homenet - should I require my operator to run PIM-SM in its network in order for me to be able to turn on an IPv6 WiFi range extender DHCP Client which connects to the ADSL box DHCP Relay?) Alex >> It seems to me that it is asking for trouble - anyone could set up >> a server and add themselves to that group, then receive - and >> answer! - DHCP queries. That is of course true anyway on the >> client link, but it's a different scale of problem on the wider >> network. Mitigation would need filters everywhere, just in case. > > True, however you also have the same sort of vulnerability issues to > rogue > > DHCP servers. That would be one of the considerations of whether to > do it or not. > >> Unicasting from relays requires configuration of all relays, but >> that is required anyway - and all the relays could have the *same* >> configuration, which is always good. >> > > Well, the same multicast address would be used on the relays' > configurations, > > so they'd all be the same. The drawback of unicast is that the relay > target DHCPv6 server becomes a single point of failure. I'm not > sure if you could use or whether it would be wise to use an anycast > address as a DHCPv6 server address in that scenario. > > >> My understanding (poor) is that since site-local was deprecated, >> the various ff05::/16 addresses were pretty much deprecated as >> well. > > I'm pretty sure site-local multicast scope wasn't deprecated with > site-local > > unicast addresses were. The issue with site-local unicast addresses > wasn't that the idea of a site was invalid, it was their > non-uniqueness and therefore it recreated in IPv6 all the sorts of > issues similar we suffer from with overlapping or duplicated RFC1918 > address spaces. If you ever want to explain to IPv4 people the > issues with duplicated RFC1918 address spaces, the IPv6 site local > deprecation RFC provides a good list. > > >> Actually that's not an understanding, it's an assumption :-) And I >> can see that an alternative path would be to let all the site-local >> well-known addresses stand alone; no longer site-local as such, >> just "they are what they are". >> >> Regards, K. >> > > > Regards, Mark. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > From kauer@biplane.com.au Mon Oct 22 15:42:02 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201DB11E80E7 for ; Mon, 22 Oct 2012 15:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[AWL=-0.521, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, PLING_QUERY=1.39] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3kVvWG5MsdX for ; Mon, 22 Oct 2012 15:42:01 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 0374C1F0C49 for ; Mon, 22 Oct 2012 15:41:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArIBAHbKhVCWZX+7/2dsb2JhbAANOMExgzUBAQEDAWcXCwsYLkkBDRkJh3URqECDKZBJi3KGVQOIJYoajl6IEIFP Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.201]) ([150.101.127.187]) by ipmail05.adl6.internode.on.net with ESMTP; 23 Oct 2012 09:11:57 +1030 Message-ID: <1350945715.3457.196.camel@karl> Subject: Re: Win7 - no managed flag, DHCP address released?!? From: Karl Auer To: ipv6@ietf.org Date: Tue, 23 Oct 2012 09:41:55 +1100 In-Reply-To: References: <1350563448.2987.14.camel@karl> <1350864259.15057.YahooMailNeo@web32502.mail.mud.yahoo.com> <83C07165-A450-4E7D-93FC-E17121D6B593@ecs.soton.ac.uk> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 22:42:02 -0000 On Mon, 2012-10-22 at 13:53 +0100, Tim Chown wrote: > This issue has come up recently in 6renum discussions, actually from > Karl as well :) > http://www.ietf.org/mail-archive/web/ipv6/current/msg16179.html In that discussion I said that I thought a host MAY deconfigure an address if it was configured due to an M flag, but I've changed my mind. I now feel that a host MUST NOT deconfigure (or even deprecate) an address solely because the state of the M or O flags changes, even if from the same sender. Why? 22.6. IA Address Option [...]In a message sent by a server to a client, the client MUST use the values in the preferred and valid lifetime fields for the preferred and valid lifetimes. The assignment of a address via DHCPv6 is a contract with the host - "you may have this address for this many seconds". The lifetimes sent by the server and their ability to be set by the administrator are the means of controlling the length of the contract. Once a DHCPv6 address is configured for a prefix, the M and O flags cease to be relevant unless or until that address has been deconfigured. Having read the RFC a few times now :-) I an convinced that there is no intention, implied or otherwise, that the absence (or disappearance) of the M or O flags should have any effect at all on a configured address. However much people may wish for that symmetry, it is not there and is not necessary. However, there is also no statement, implied or otherwise, that a host SHOULD NOT or MUST NOT deconfigure an address whenever it darn well feels like it. The snippet of code above may suggest otherwise, but I think it is clear that it is setting a maximum, not a minimum. So I have to come to the reluctant conclusion that Windows is not doing anything formally wrong in this regard, it is just doing something very stupid[1]. And I stand by my opinion that these flags are unnecessary and should be deprecated as soon as possible. > The example being considered here with two senders and inconsistent > settings is a misconfiguration. The inconsistency should be logged and > corrected, regardless of what the host behaviour is. If the second RA > is a rogue, then methods for rogue RA suppression should be in place. All true - but the host should also avoid a trivial DoS by not "flapping" outside the lifetimes received with the address(es) it configured. > A similar discussion could be had if each RA carried different DNS > resolver addresses in the RFC6106 option. That RFC says > "configurations where different information is provided by different > sources may lead to problems. Therefore, the network administrator > needs to configure DNS options in multiple sources in order to prevent > such problems from happening." A similar argument. Similar, yes. But not the same, given the DHCPv6 contract. If a host was fooled into entering the contract, that's too bad - but being able to fool it out of the contract is equally bad. Regards, K. [1] If indeed it is doing it at all - I still haven't double checked this. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 From internet-drafts@ietf.org Mon Oct 22 15:59:40 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F10321F8906; Mon, 22 Oct 2012 15:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYESZsyqNPPW; Mon, 22 Oct 2012 15:59:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6210B21F8451; Mon, 22 Oct 2012 15:59:39 -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 Subject: I-D Action: draft-ietf-6man-impatient-nud-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022225939.28839.26283.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 15:59:39 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 22:59:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Neighbor Unreachability Detection is too impatient Author(s) : Erik Nordmark Igor Gashinsky Filename : draft-ietf-6man-impatient-nud-03.txt Pages : 8 Date : 2012-10-22 Abstract: IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. That function is very useful when a host has an alternative, for instance multiple default routers, since it allows the host to switch to the alternative in short time. This time is 3 seconds after the node starts probing by default. However, if there are no alternatives, this is far too impatient. This document specifies relaxed rules for Neighbor Discovery retransmissions that allows an implementation to choose different timeout behavior based on whether or not there are alternatives. This document updates RFC 4861. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-impatient-nud There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-impatient-nud-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-impatient-nud-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 22 16:03:31 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2076421F8A21; Mon, 22 Oct 2012 16:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HXt0rNl-ip9; Mon, 22 Oct 2012 16:03:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B0221F8A71; Mon, 22 Oct 2012 16:03:29 -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 Subject: I-D Action: draft-ietf-6man-impatient-nud-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022230328.28835.94491.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 16:03:28 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 23:03:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Neighbor Unreachability Detection is too impatient Author(s) : Erik Nordmark Igor Gashinsky Filename : draft-ietf-6man-impatient-nud-04.txt Pages : 8 Date : 2012-10-22 Abstract: IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. That function is very useful when a host has an alternative, for instance multiple default routers, since it allows the host to switch to the alternative in short time. This time is 3 seconds after the node starts probing by default. However, if there are no alternatives, this is far too impatient. This document specifies relaxed rules for Neighbor Discovery retransmissions that allows an implementation to choose different timeout behavior based on whether or not there are alternatives. This document updates RFC 4861. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-impatient-nud There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-impatient-nud-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-impatient-nud-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 22 16:16:45 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC71B11E8107; Mon, 22 Oct 2012 16:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxxbDXVvmDoF; Mon, 22 Oct 2012 16:16:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D640D11E810A; Mon, 22 Oct 2012 16:16:44 -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 Subject: I-D Action: draft-ietf-6man-udpchecksums-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022231644.25130.21816.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 16:16:44 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 23:16:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : UDP Checksums for Tunneled Packets Author(s) : Marshall Eubanks P.F. Chimento Magnus Westerlund Filename : draft-ietf-6man-udpchecksums-05.txt Pages : 11 Date : 2012-10-22 Abstract: This document provides an update of the Internet Protocol version 6 (IPv6) specification (RFC2460) to improve the performance of IPv6 in the use case when a tunnel protocol uses UDP with IPv6 to tunnel packets. The performance improvement is obtained by relaxing the IPv6 UDP checksum requirement for suitable tunneling protocol where header information is protected on the "inner" packet being carried. This relaxation removes the overhead associated with the computation of UDP checksums on IPv6 packets used to carry tunnel protocols and thereby improves the efficiency of the traversal of firewalls and other network middleboxes by such protocols. We describe how the IPv6 UDP checksum requirement can be relaxed in the situation where the encapsulated packet itself contains a checksum, the limitations and risks of this approach, and define restrictions on the use of this relaxation to mitigate these risks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-udpchecksums-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-udpchecksums-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 22 16:16:46 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238B811E8114 for ; Mon, 22 Oct 2012 16:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTnU63DDxXMd; Mon, 22 Oct 2012 16:16:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2F711E808D; Mon, 22 Oct 2012 16:16:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: 6man-chairs@tools.ietf.org, draft-ietf-6man-udpchecksums@tools.ietf.org, ipv6@ietf.org, brian@innovationslab.net, barryleiba@computer.org, stbryant@cisco.com Subject: New Version Notification - draft-ietf-6man-udpchecksums-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022231645.25130.91396.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 16:16:45 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 23:16:46 -0000 A new version (-05) has been submitted for draft-ietf-6man-udpchecksums: http://www.ietf.org/internet-drafts/draft-ietf-6man-udpchecksums-05.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-udpchecksums-05 IETF Secretariat. From magnus.westerlund@ericsson.com Mon Oct 22 16:23:52 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070DC21F855C for ; Mon, 22 Oct 2012 16:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.228 X-Spam-Level: X-Spam-Status: No, score=-106.228 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nzFV-ibOe+9 for ; Mon, 22 Oct 2012 16:23:51 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBC221F8427 for ; Mon, 22 Oct 2012 16:23:49 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-40-5085d584bbb2 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A8.95.11467.485D5805; Tue, 23 Oct 2012 01:23:48 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Tue, 23 Oct 2012 01:23:48 +0200 Message-ID: <5085D57C.4050108@ericsson.com> Date: Tue, 23 Oct 2012 01:23:40 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: I-D Action: draft-ietf-6man-udpchecksums-05.txt References: <20121022231644.25130.21816.idtracker@ietfa.amsl.com> In-Reply-To: <20121022231644.25130.21816.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGfG3VrflamuAQft7RYuXZ98zOTB6LFny kymAMYrLJiU1J7MstUjfLoEro+/pPqaC55IV2z/dY2xg3C7SxcjJISFgInF2+WEmCFtM4sK9 9WxdjFwcQgKnGCU+rJ7FBOEsZ5TYdGEeK0gVr4C2xNldt4FsDg4WAVWJ//MtQMJsAhYSN380 soGERQWCJZ53FENUC0qcnPmEBcQWAbK3P/gBZgsL2Eic+76GHaRcSMBR4vD3DJAwp4CTxKrj xxghzpGUePv+FTOIzSygJzHlagsjhC0v0bx1NlhcCOiYhqYO1gmMgrOQbJuFpGUWkpYFjMyr GIVzEzNz0ssN9VKLMpOLi/Pz9IpTNzECQ/Lglt+6OxhPnRM5xCjNwaIkzsuVtN9fSCA9sSQ1 OzW1ILUovqg0J7X4ECMTB6dUA6PdNNOWmj1PfH88tdj1Y8IW68/f796dFiI9f93n/xtTHY48 9RBxvqeSfCJJTOUFz293Fq3yLYmhCi3ngvbdCVk60cz7YKxjVrrUvqfHpz3QUr7psJNdWS73 HN+lm0HLWGfprpv5u6rXU2S76Exfrt8W26XLEt8k3tJdZPtdI+o0y9LVS7LsetYpsRRnJBpq MRcVJwIAlLiN7xcCAAA= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 23:23:52 -0000 WG, The submitted version is not yet addressing all the issues raised during IESG review. This is testing the proposed direction without overworking the details. Thus one thing this document definitely needs to be improved at is the following: - Security consideration comments raised - The analysis of the impact on the inner traffic with UDP tunnels. - Clear how the requirements are or can be meet with the general class of UDP tunnel using protocols carrying IP or transport protocol. Cheers Magnus On 2012-10-23 01:16, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Maintenance Working Group of the IETF. > > Title : UDP Checksums for Tunneled Packets > Author(s) : Marshall Eubanks > P.F. Chimento > Magnus Westerlund > Filename : draft-ietf-6man-udpchecksums-05.txt > Pages : 11 > Date : 2012-10-22 > > Abstract: > This document provides an update of the Internet Protocol version 6 > (IPv6) specification (RFC2460) to improve the performance of IPv6 in > the use case when a tunnel protocol uses UDP with IPv6 to tunnel > packets. The performance improvement is obtained by relaxing the > IPv6 UDP checksum requirement for suitable tunneling protocol where > header information is protected on the "inner" packet being carried. > This relaxation removes the overhead associated with the computation > of UDP checksums on IPv6 packets used to carry tunnel protocols and > thereby improves the efficiency of the traversal of firewalls and > other network middleboxes by such protocols. We describe how the > IPv6 UDP checksum requirement can be relaxed in the situation where > the encapsulated packet itself contains a checksum, the limitations > and risks of this approach, and define restrictions on the use of > this relaxation to mitigate these risks. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-6man-udpchecksums-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-udpchecksums-05 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From internet-drafts@ietf.org Mon Oct 22 16:44:10 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDB111E80EA; Mon, 22 Oct 2012 16:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hk-GgRKLEIRI; Mon, 22 Oct 2012 16:44:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4BA11E80D9; Mon, 22 Oct 2012 16:44:09 -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 Subject: I-D Action: draft-ietf-6man-impatient-nud-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022234409.12297.3495.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 16:44:09 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 23:44:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Neighbor Unreachability Detection is too impatient Author(s) : Erik Nordmark Igor Gashinsky Filename : draft-ietf-6man-impatient-nud-05.txt Pages : 9 Date : 2012-10-22 Abstract: IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. That function is very useful when a host has an alternative, for instance multiple default routers, since it allows the host to switch to the alternative in short time. This time is 3 seconds after the node starts probing by default. However, if there are no alternatives, this is far too impatient. This document specifies relaxed rules for Neighbor Discovery retransmissions that allows an implementation to choose different timeout behavior based on whether or not there are alternatives. This document updates RFC 4861. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-impatient-nud There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-impatient-nud-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-impatient-nud-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nordmark@sonic.net Mon Oct 22 16:06:35 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81DAC21F8B80 for ; Mon, 22 Oct 2012 16:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmJVx+-1EXw0 for ; Mon, 22 Oct 2012 16:06:34 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id B178D21F8530 for ; Mon, 22 Oct 2012 16:06:34 -0700 (PDT) Received: from [10.154.212.77] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id q9MN6W3F017260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2012 16:06:32 -0700 Message-ID: <5085D178.3040502@sonic.net> Date: Mon, 22 Oct 2012 16:06:32 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Hemant Singh (shemant)" Subject: Re: 6MAN WG Last Call: References: <72907536-3B88-4E29-87EA-562A8DAD3A85@gmail.com> <75B6FA9F576969419E42BECB86CB1B890838A7@xmb-rcd-x06.cisco.com> In-Reply-To: <75B6FA9F576969419E42BECB86CB1B890838A7@xmb-rcd-x06.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 22 Oct 2012 18:00:33 -0700 Cc: "ipv6@ietf.org Mailing List" , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 23:06:35 -0000 Hemant, Thanks for your comments. On 9/9/12 2:43 PM, Hemant Singh (shemant) wrote: > I support this document - it's important work and the document is really close to ship to the IESG. > > I thought this document should be on Standards Track but the document does not say anything about the Intended Status of the document. Please fix that so that document includes Intended Status. Additionally, if the document is on Standards Track, do we have at least one implementation of the protocol changes covered in the document? Or the protocol changes are deemed minor and one does not need at least one implementation? Fixed. > Comments included below. > > COMMENTS: > > 1. In the first paragraph of the Protocol Update section, please replace "route" by "router". At least all of RFC 4861 works with a default router not a default route. Fixed. > 2. I think the following text in the Protocol Update section can be removed because the text is redundant with RFC 4861. > > [The UNREACHABLE state is conceptual and not a required part of this > specification. A node merely needs to satisfy the externally > observable behavior of this specification.] I instead expanded on it to say that this is consistent with the 4861 - I wanted to keep the statement in there to make it clear that this expansion with an additional state might not be that cumbersome since it depends on the implementation. I've also taken care of the editorial comments below. All included in -04 of the draft. Thanks again, Erik > > Editorial comments: > > 1. In the first paragraph of the Introduction section, please add a space between the two words shown below. > > [reachable.The]. > > 2. In the Protocol Update section, change > > "Cache Entry as any time" > > to > > "Cache Entry at any time" > > In the same section change > > "no IPv6 packets" > > To > > "no IPv6 packet" > > > 3. In the Example Algorithm section, do we need to change > > "An Implementation" > > to > > "An implementation"? > > > 4. In the Security Considerations section, "belived" is misspelled. > > Regards, > > Hemant > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob Hinden > Sent: Tuesday, September 04, 2012 1:28 PM > To: ipv6@ietf.org Mailing List > Cc: Bob Hinden > Subject: 6MAN WG Last Call: > > All, > > This message starts a two week 6MAN Working Group on advancing: > > Title : Neighbor Unreachability Detection is too impatient > Author(s) : Erik Nordmark > Igor Gashinsky > Filename : draft-ietf-6man-impatient-nud-02.txt > Pages : 8 > Date : 2012-07-31 > > http://tools.ietf.org/html/draft-ietf-6man-impatient-nud-02 > > as Proposed Standard. Substantive comments and statements of support for advancing this document should be directed to the mailing list. Editorial suggestions can be sent to the authors. This last call will end on September 18, 2012. > > Regards, > Ole Troan & Bob Hinden > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nordmark@sonic.net Mon Oct 22 16:44:52 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737C91F0C60 for ; Mon, 22 Oct 2012 16:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Rwrz8U7NbmP for ; Mon, 22 Oct 2012 16:44:52 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id DDBAE1F0C5F for ; Mon, 22 Oct 2012 16:44:51 -0700 (PDT) Received: from [10.154.212.77] (128-107-239-234.cisco.com [128.107.239.234]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id q9MNikeE020957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2012 16:44:46 -0700 Message-ID: <5085DA6E.6050201@sonic.net> Date: Mon, 22 Oct 2012 16:44:46 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Tina TSOU Subject: Re: 6MAN WG Last Call: References: <72907536-3B88-4E29-87EA-562A8DAD3A85@gmail.com>, <2671C6CDFBB59E47B64C10B3E0BD592304E7B092@PRVPEXVS15.corp.twcable.com> , In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 22 Oct 2012 18:00:33 -0700 Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "draft-ietf-6man-impatient-nud@tools.ietf.org" , 6man , "nordmark@cisco.com" , Bob Hinden , Igor Gashinsky X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 23:44:52 -0000 Tina, Thank you for your comments. >>> Hi Erik and Igor, >>> >>> The draft is well explained in regards to the case when there is no alternative default router in the lest of default routers. >>> >>> I wanted some clarification in the content below: >>> >>> In the draft, >>> The recommended behavior is to have 5 attempts, with timing spacing >>> of 0 (initial request), 1 second later, 3 seconds later, then 9, and >>> then 27, and switch to UNREACHABLE after 3 transmissions, which >>> represents:-------after the initial request, we transmit a packet after 1 sec, then another after 3 seconds, then another after 9 seconds and finally after 27 secs right? The times in the example are relatively to the previous (re)transmission. I've expanded the example to also show the cumulative time since the first transmission. As part of doing that I also formalized the cap on the exponential backoff (suggested in the text as 60 seconds) by introducing a MAX_RETRANS_TIMER. Your questions below indicate to me that the text is confused since in some places we say that we switch to multicast and mark UNREACHABLE at the same time. But the example was intended to show a case when those occur at different times. >>> MAX_UNICAST_SOLICIT=5----This would imply 5 attempts? Yes, 5 unicasts. >>> RETRANS_TIMER=1 (default) >>> >>> BACKOFF_MULTIPLE=3 >>> >>> MARK_UNREACHABLE=3------Do we mark it unreachable after 9 secs OR 4 secs 0r 27 secs? After 1 transmission plus 2 retransmissions. With the recommended timer and backoff values that occurs at 4 seconds since the initial transmission. >>> After marking unreachable, multicast NS will be send instead of Unicast NS right? The (non-normative) example is slightly more sophisticated in that it first marks as unreachable and later switches to multicast. That allows for more quickly switching to an alternate (e.g., in a case with multiple default routers), while reducing the impact of multicast packets. The downside of this is that it takes longer to detect a node (host or router) which keeps its IPv6 address while changing its MAC address. >>> Since there will be 5 attempts, would it imply it will wait 27 seconds before declaring it unreachable? No, in the example (which was confusing and contradictory) it was supposed to be after 4 seconds, while discarding the NCE (implicitly switching to multicast NS) after 40 seconds after the initial transmission. I think I finally got this right in version 05 that I just posted. I'd appreciate if you can look it over for clarity on these matters. Thanks, Erik From markzzzsmith@yahoo.com.au Mon Oct 22 21:38:01 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1E01F0C69 for ; Mon, 22 Oct 2012 21:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.948 X-Spam-Level: X-Spam-Status: No, score=-0.948 tagged_above=-999 required=5 tests=[AWL=-0.839, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_21=0.6, PLING_QUERY=1.39] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLSsYjRhKM7i for ; Mon, 22 Oct 2012 21:38:00 -0700 (PDT) Received: from nm12-vm3.bullet.mail.ne1.yahoo.com (nm12-vm3.bullet.mail.ne1.yahoo.com [98.138.91.142]) by ietfa.amsl.com (Postfix) with ESMTP id 36E241F0C54 for ; Mon, 22 Oct 2012 21:38:00 -0700 (PDT) Received: from [98.138.90.54] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 23 Oct 2012 04:37:55 -0000 Received: from [98.138.88.234] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 23 Oct 2012 04:37:55 -0000 Received: from [127.0.0.1] by omp1034.mail.ne1.yahoo.com with NNFMP; 23 Oct 2012 04:37:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 359395.76824.bm@omp1034.mail.ne1.yahoo.com Received: (qmail 41939 invoked by uid 60001); 23 Oct 2012 04:37:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1350967074; bh=u/tEjJi0vjg9s37sqcInUYdXW1HRsXp2qSY/buCykAM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fLYsD3G7DisGmJj5MmWHBIqA7CVLzIFBMfBh2bPRWYJ8jvQPsaJhrnBXyc6MnccedwwX2hZ7bweHUeEC70Nyu7APjFyHxHj5IhUQDYs/enqhVEy5RmdrgXDWn0t+aKxL9fVwUkdU3imX4OesYR901wp8Q+Q5tH4DOykE0+YUAFM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=jd/CrOsjG5mc3ckCZM6ECPv+T8Z7ZYGLws3BhOgsRccQ+tI20u4vXWyJJtprA1EMdWWyr/oKwTztO8WXVB9wr33NnshUAKMkWJJ2qpcygLeXFxH+T50fj8+HzUpcUoexkte/DygFlxnauCHPE8Mqq8vKHhh0N+dxzrRJJe7vtKc=; X-YMail-OSG: isxfdBkVM1nIWmBOZnzoTLH83C4trN85kpPTG4iYmf6T5Wi 4gauMA0zIeoAzNp15yCZ9Z0UBzUgqnE9SrtA0NUA6V761uPKpmT0Kmu3L4fV V_pjVS_qi1djy8oRJiml5WGILvhF2nsJv56RvD.rsKEi55Neey17oKP8DIrQ ueoGGZHKJvkZodjP0yq7Z9vrWG8i7jxyb1JmggqQ1g3qoTgYiZVRxAz1BuYC WTeE9zBLDRccFRzQqZrn3dTScsm55sWPHQNd5BrafdEif_Nvdej38Hc31.yO 1F0UYFblDEMzcMAyt7U7zeSuDaDUY62YlRJyJRq24VEJ7s7ACWrBkXYfLOO_ NDRpbhFj.DH9gLtB1nRJKOIjI94AWIk5j_xl.W6FWE4a5hpQlvBCSfNL4Wz. ZhDIcw8YniMcRoUTYv18.qmfscGy6JysaagKndmvy7K5P_jtPf7V37NQhm_X 9n4bt0x_K0s.SMZeniwDnQMr_P8TFbrdDCiSuEDmD58609l7hmVYX.bdn4dw R5jxMUN0nZT55DP7AvbvUep2YFwA- Received: from [150.101.221.237] by web32504.mail.mud.yahoo.com via HTTP; Mon, 22 Oct 2012 21:37:54 PDT X-Rocket-MIMEInfo: 001.001, SGksCgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo.IEZyb206IEthcmwgQXVlciA8a2F1ZXJAYmlwbGFuZS5jb20uYXU.Cj4gVG86IGlwdjZAaWV0Zi5vcmcKPiBDYzogCj4gU2VudDogVHVlc2RheSwgMjMgT2N0b2JlciAyMDEyIDk6NDEgQU0KPiBTdWJqZWN0OiBSZTogV2luNyAtIG5vIG1hbmFnZWQgZmxhZywgREhDUCBhZGRyZXNzIHJlbGVhc2VkPyE_Cj4gCj4gT24gTW9uLCAyMDEyLTEwLTIyIGF0IDEzOjUzICswMTAwLCBUaW0gQ2hvd24gd3JvdGU6Cj4.ICBUaGlzIGlzc3VlIGhhcyBjb21lIHUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <1350563448.2987.14.camel@karl> <1350864259.15057.YahooMailNeo@web32502.mail.mud.yahoo.com> <83C07165-A450-4E7D-93FC-E17121D6B593@ecs.soton.ac.uk> <1350945715.3457.196.camel@karl> Message-ID: <1350967074.92894.YahooMailNeo@web32504.mail.mud.yahoo.com> Date: Mon, 22 Oct 2012 21:37:54 -0700 (PDT) From: Mark Smith Subject: Re: Win7 - no managed flag, DHCP address released?!? To: Karl Auer , "ipv6@ietf.org" In-Reply-To: <1350945715.3457.196.camel@karl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 04:38:01 -0000 Hi,=0A=0A=0A----- Original Message -----=0A> From: Karl Auer =0A> To: ipv6@ietf.org=0A> Cc: =0A> Sent: Tuesday, 23 October 2012 = 9:41 AM=0A> Subject: Re: Win7 - no managed flag, DHCP address released?!?= =0A> =0A> On Mon, 2012-10-22 at 13:53 +0100, Tim Chown wrote:=0A>> This is= sue has come up recently in 6renum discussions, actually from=0A>> Karl as= well :)=0A>> http://www.ietf.org/mail-archive/web/ipv6/current/msg16179.h= tml=0A> =0A> In that discussion I said that I thought a host MAY deconfigur= e an=0A> address if it was configured due to an M flag, but I've changed my= mind.=0A> I now feel that a host MUST NOT deconfigure (or even deprecate) = an=0A> address solely because the state of the M or O flags changes, even i= f=0A> from the same sender. Why?=0A>=A0=0A=0AAgree.=A0=0A=0A> =A0 22.6. IA= Address Option=0A> =0A> =A0 [...]In a message sent by a server to a=0A> = =A0 client, the client MUST use the values in the preferred and valid=0A> = =A0 lifetime fields for the preferred and valid lifetimes.=0A> =0A= =0A> =0A> However, there is also no statement, implied or otherwise, that a= host=0A> SHOULD NOT or MUST NOT deconfigure an address whenever it darn we= ll=0A> feels like it.=0A=0AI don't think you'd find that statement in the D= HCPv6 RFC, instead,=0Ait'd be in the one that describes what preferred and = valid lifetimes=0Amean and how they're used i.e. address aging. DHCPv6 is o= nly acting as an=0Aaddress configuration protocol in this case, not an addr= ess aging protocol=0Atoo. Otherwise there'd be statements in the DHCPv6 RFC= that the preferred=0Aand valid lifetimes for addresses must not be larger = than the T1/T2 timer=0Avalues in DHCPv6, to constrain the life of addresses= to be within the life=0Aof a DHCPv6 session. The MUST in the text above is= saying that what ever=0Athe IA Address Option ages are, they MUST be used = for address aging.=0A=0AI consider Windows to be broken in this case, becau= se it seems to=0A=0Afundamentally is assuming DHCPv6 session validity const= rains the valid=0Aages of any of the DHCPv6 options, when those options hav= e their own specific=0Aage values.=0A=0A> The snippet of code above may sug= gest otherwise, but I=0A> think it is clear that it is setting a maximum, n= ot a minimum. So I have=0A> to come to the reluctant conclusion that Window= s is not doing anything=0A> formally wrong in this regard, it is just doing= something very=0A> stupid[1].=0A> =0A> And I stand by my opinion that thes= e flags are unnecessary and should be=0A> deprecated as soon as possible.= =0A>=A0=0A=0AAssuming you're talking about the M & O bits, I think a drawba= ck of that=0A=0Ais that it then requires a DHCPv6 server, at the least a st= ateless one, to=0Aalways be present. Otherwise all hosts would be periodica= lly multicasting=0ADHCPv6 solicit messages constantly, regardless of whethe= r a DHCPv6 server is=0Aever going to be present. This periodic sending of m= ulticasts by all devices=0Aand possibly flooding of multicast to all device= s (i.e. without MLD snooping=0Aat layer 2) could be quite detrimental to de= vices operating on batteries.=0A=0AOTOH, if that forced people to deploy st= ateless DHCPv6 for=0A=0Aapplication/service configuration instead of thinki= ng that DHCPv6 options=0Ashould be in RAs, I'd personally be for it.=0A=0A= =0A>> The example being considered here with two senders and inconsistent= =0A>> settings is a misconfiguration. The inconsistency should be logged a= nd=0A>> corrected, regardless of what the host behaviour is. If the second= RA=0A>> is a rogue, then methods for rogue RA suppression should be in pl= ace.=0A> =0A> All true - but the host should also avoid a trivial DoS by no= t=0A> "flapping" outside the lifetimes received with the address(es) it=0A>= configured.=0A> =0A>> A similar discussion could be had if each RA carrie= d different DNS=0A>> resolver addresses in the RFC6106 option. That RFC sa= ys=0A>> "configurations where different information is provided by differe= nt=0A>> sources may lead to problems. Therefore, the network administrator= =0A>> needs to configure DNS options in multiple sources in order to preve= nt=0A>> such problems from happening." A similar argument.=0A> =0A> Simila= r, yes. But not the same, given the DHCPv6 contract. If a host was=0A> fool= ed into entering the contract, that's too bad - but being able to=0A> fool = it out of the contract is equally bad.=0A> =0A> Regards, K.=0A> =0A> [1] If= indeed it is doing it at all - I still haven't double checked=0A> this.=0A= > =0A> -- =0A> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~=0A> Karl Auer (kauer@biplane.com.au)=0A> http://www.biplane.com= .au/kauer=0A> http://www.biplane.com.au/blog=0A> =0A> GPG fingerprint: AE1D= 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017=0A> Old fingerprint: DA41 51B= 1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687=0A> =0A> ------------------------= --------------------------------------------=0A> IETF IPv6 working group ma= iling list=0A> ipv6@ietf.org=0A> Administrative Requests: https://www.ietf.= org/mailman/listinfo/ipv6=0A> ---------------------------------------------= -----------------------=0A> From shemant@cisco.com Tue Oct 23 04:06:56 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA4E21F86F7 for ; Tue, 23 Oct 2012 04:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.456 X-Spam-Level: X-Spam-Status: No, score=-10.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InfHXHALqanx for ; Tue, 23 Oct 2012 04:06:55 -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 8953521F86E9 for ; Tue, 23 Oct 2012 04:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4162; q=dns/txt; s=iport; t=1350990415; x=1352200015; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HjmCgQFrBJM0RZcsmFp03XOePwY8oppIjANhsY3FBOw=; b=fV0yme7hCagj916avFxtu0VnlyFAgCZ/zNKh4Q/kifWY9jp2uu3rioZ1 5VtUuPHX9cqPBjlgECXKnHBgqGVndEgSJNuOvfql8gin4DqXtotFPbdxE vkRfLPjgXOuv2kTk7msV3KCZR0e2wuqJguWkEZ2dI+Cdau+mjYxlpEJg5 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAG55hlCtJXG+/2dsb2JhbABEwWOBCIIeAQEBAwEBAQEPASc0CwUHBAIBCBEEAQEBChQJBycLFAkIAgQOBQgah1wGC5xej1yQQotfhX5gA5IFhQONN4Frgm+CGA X-IronPort-AV: E=Sophos;i="4.80,634,1344211200"; d="scan'208";a="134398708" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 23 Oct 2012 11:06:55 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9NB6twi008867 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Oct 2012 11:06:55 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.76]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 06:06:54 -0500 From: "Hemant Singh (shemant)" To: Erik Nordmark Subject: RE: 6MAN WG Last Call: Thread-Topic: 6MAN WG Last Call: Thread-Index: AQHNsKnqLH/XeCmjvEmdodkfAa+kSJfGu3OQ Date: Tue, 23 Oct 2012 11:06:53 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B890E61D0@xmb-rcd-x06.cisco.com> References: <72907536-3B88-4E29-87EA-562A8DAD3A85@gmail.com> <75B6FA9F576969419E42BECB86CB1B890838A7@xmb-rcd-x06.cisco.com> <5085D178.3040502@sonic.net> In-Reply-To: <5085D178.3040502@sonic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.48] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19298.000 x-tm-as-result: No--42.317200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org Mailing List" , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 11:06:56 -0000 Erik, Your responses and closure sounds good to me. The document looks good to s= end to the IESG. Thanks, Hemant -----Original Message----- From: Erik Nordmark [mailto:nordmark@sonic.net]=20 Sent: Monday, October 22, 2012 7:07 PM To: Hemant Singh (shemant) Cc: Bob Hinden; ipv6@ietf.org Mailing List Subject: Re: 6MAN WG Last Call: Hemant, Thanks for your comments. On 9/9/12 2:43 PM, Hemant Singh (shemant) wrote: > I support this document - it's important work and the document is really = close to ship to the IESG. > > I thought this document should be on Standards Track but the document doe= s not say anything about the Intended Status of the document. Please fix t= hat so that document includes Intended Status. Additionally, if the docume= nt is on Standards Track, do we have at least one implementation of the pro= tocol changes covered in the document? Or the protocol changes are deemed = minor and one does not need at least one implementation? Fixed. > Comments included below. > > COMMENTS: > > 1. In the first paragraph of the Protocol Update section, please replace= "route" by "router". At least all of RFC 4861 works with a default router= not a default route. Fixed. > 2. I think the following text in the Protocol Update section can be remov= ed because the text is redundant with RFC 4861. > > [The UNREACHABLE state is conceptual and not a required part of this > specification. A node merely needs to satisfy the externally > observable behavior of this specification.] I instead expanded on it to say that this is consistent with the 4861 -=20 I wanted to keep the statement in there to make it clear that this=20 expansion with an additional state might not be that cumbersome since it=20 depends on the implementation. I've also taken care of the editorial comments below. All included in=20 -04 of the draft. Thanks again, Erik > > Editorial comments: > > 1. In the first paragraph of the Introduction section, please add a space= between the two words shown below. > > [reachable.The]. > > 2. In the Protocol Update section, change > > "Cache Entry as any time" > > to > > "Cache Entry at any time" > > In the same section change > > "no IPv6 packets" > > To > > "no IPv6 packet" > > > 3. In the Example Algorithm section, do we need to change > > "An Implementation" > > to > > "An implementation"? > > > 4. In the Security Considerations section, "belived" is misspelled. > > Regards, > > Hemant > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of B= ob Hinden > Sent: Tuesday, September 04, 2012 1:28 PM > To: ipv6@ietf.org Mailing List > Cc: Bob Hinden > Subject: 6MAN WG Last Call: > > All, > > This message starts a two week 6MAN Working Group on advancing: > > Title : Neighbor Unreachability Detection is too impatient > Author(s) : Erik Nordmark > Igor Gashinsky > Filename : draft-ietf-6man-impatient-nud-02.txt > Pages : 8 > Date : 2012-07-31 > > http://tools.ietf.org/html/draft-ietf-6man-impatient-nud-02 > > as Proposed Standard. Substantive comments and statements of support for= advancing this document should be directed to the mailing list. Editorial= suggestions can be sent to the authors. This last call will end on Septem= ber 18, 2012. > > Regards, > Ole Troan & Bob Hinden > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From brian.e.carpenter@gmail.com Tue Oct 23 05:06:02 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D29D921F86F6 for ; Tue, 23 Oct 2012 05:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.678 X-Spam-Level: X-Spam-Status: No, score=-101.678 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VK0QGESjMBM2 for ; Tue, 23 Oct 2012 05:06:02 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2907C21F86F4 for ; Tue, 23 Oct 2012 05:06:02 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so1338082bkc.31 for ; Tue, 23 Oct 2012 05:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/Jmao2fPXwn3ZeJrMrzFv7g4G0rY8onrdyLi/E3JkHc=; b=BNwuQzy1LduRd6G10tUdKkXA20x0H3qDvzvqI23pEMxamdSA3frPhmz1dETdZulHgL /B5n4CuSIA210wHUXoLKpycit+/DY9XmIJlFYhM96ldNz06Vyzj/xAK0PqoG4wREESFJ TXaG5czy/2Ew3pkY9ok+88uJR+bhe3GX8KNabcPZhNbeKqOrEsxF5U+WQPZPSjWoLfXN NSROeD5ypsd4xFKftJ/CiEf3dcioxj8POtMrw5pJ+zSoG2NxC+OLV/ALb5yPv1qZjMKf /AyNBopWCruNCKFSIN7MAJRoCXJN9I1FbQ9T9Zq8YPoj88lYj08ajUqMi99J8jnPtAaJ z84Q== Received: by 10.204.147.148 with SMTP id l20mr3633332bkv.112.1350993961293; Tue, 23 Oct 2012 05:06:01 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-219-57.as13285.net. [2.102.219.57]) by mx.google.com with ESMTPS id x13sm5657380bkv.16.2012.10.23.05.05.58 (version=SSLv3 cipher=OTHER); Tue, 23 Oct 2012 05:05:59 -0700 (PDT) Message-ID: <50868827.9020509@gmail.com> Date: Tue, 23 Oct 2012 13:05:59 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> <5082E933.60205@gmail.com> In-Reply-To: <5082E933.60205@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 12:06:02 -0000 On 20/10/2012 19:10, Alexandru Petrescu wrote: .. > But with vehicles, one connects a vehicle here and gets a prefix, then > moves in that area and gets another prefix. At that point, if the > router obtaining a prefix wants to delegate further to another vehicle > needs to change the delegated prefix. Why wouldn't RPL be used for such networks? It has built-in PD for dynamic networks, if I understand it correctly, with RA used at the subnet level. Brian From brian.e.carpenter@gmail.com Tue Oct 23 05:19:32 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D530C21F8671 for ; Tue, 23 Oct 2012 05:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.52 X-Spam-Level: X-Spam-Status: No, score=-101.52 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J59pOAn7kGWn for ; Tue, 23 Oct 2012 05:19:32 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2F42721F85D5 for ; Tue, 23 Oct 2012 05:19:32 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so1345479bkc.31 for ; Tue, 23 Oct 2012 05:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XLlxPysZvVl7znDYBom77WjuU4O2Q/FEnBg+1+7B1VY=; b=iiXiAsFeutcyze0vSDVSwUhCXh8ByK3+quPagfaTej+nSesHKISRrsUvrY3KCSR/US iTisxnNEeqmvVNHD2xoII5gEy28dghxjZgPt9IDfF6PG7J7PLIbPFqbnLr/ktLZKxj83 qsy3tc1HF88tfpM/sCyloWAuOPBu3p3Lqn0E2uwuyll50ABKEHOTGmOn2T5qb/oF45vP f4mDNXC3n0QlA3/K4VVVQjb7INwth0N5YQYB6wo0yZJjgJO/O7jGt2ss738u2Nb9bhl/ UqArY3I8WAYj3sBz8taH2YhujufRpTOnHQ4z41zcMIutFLK/Ufr3rdcYyYV5IVMvjudB EnTg== Received: by 10.205.121.7 with SMTP id ga7mr3604239bkc.30.1350994771151; Tue, 23 Oct 2012 05:19:31 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-219-57.as13285.net. [2.102.219.57]) by mx.google.com with ESMTPS id k21sm5638046bkv.1.2012.10.23.05.19.29 (version=SSLv3 cipher=OTHER); Tue, 23 Oct 2012 05:19:30 -0700 (PDT) Message-ID: <50868B52.9000105@gmail.com> Date: Tue, 23 Oct 2012 13:19:30 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: Re: I-D Action: draft-kaiser-nd-pd-00.txt References: <20121015135008.32010.58361.idtracker@ietfa.amsl.com> In-Reply-To: <20121015135008.32010.58361.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-kaiser-nd-pd@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 12:19:32 -0000 I realised while reading this draft that I just don't understand its operating model. It refers to the "requesting" router supplying Prefix Collection and Prefix Information to the delegating router: > When requesting prefixes a requesting router MUST add for each > requested prefix a Prefix Information in the Prefix Delegation option > of the RS message. However, by definition the requesting router doesn't know what prefix(es) it will be given. So surely all it can ask for is N unspecified prefixes of given lengths? It also says: > PC_ID: An unique identifier of the Prefix Collection. The > PC_ID MUST be unique among all PC_ID known by the > requesting router. How can the requesting router provide this in its REQ message? By guessing? > 11. Security Considerations > > TBD OK, but since a vehicular network is open to any one of millions of unmanaged devices, this will need to be *very* convincing, especially in preventing DOS. Regards Brian Carpenter From rdroms.ietf@gmail.com Tue Oct 23 10:44:47 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9987911E80D9 for ; Tue, 23 Oct 2012 10:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.549 X-Spam-Level: X-Spam-Status: No, score=-103.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZAh0RSvc7qi for ; Tue, 23 Oct 2012 10:44:47 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id EBA2211E80D5 for ; Tue, 23 Oct 2012 10:44:46 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so4979613vbb.31 for ; Tue, 23 Oct 2012 10:44:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=AA5Mqwx4+SmJ3/QsvE1oa/kL9bsrPsxv3jNJJOxM/0w=; b=ClzyzQHX5L1dck/mDXDVkjBPSi/Iyu2VTVZBSLhOdJk86cAdrf+J7P7Tkkx+hA9Gb+ 3kOT1PocKJ8Oz6wO1E6qFy4QlZEgS/RFfcG+va93HA1Isj3WjOmPDg65+1y0kLCWsSXI aZXr7IzmpXRI7NBuYDMZHe5WSb0MKtiTkvJcisbxvLgXdHnKtCmOD55/UTO8QVWZSZ8D Ou4odXnMuIY8zXShWs2AdbMKVFrSWw7EcQ57eVhVnDyIGkSMxHVc24vkjJk3YctMglnO Zcs8Mw4tNvNi7NxA0iB040TYduIhBwPUPEteSUGxOOE669ftb2yMm4jIe4a7Tz3TBl5P IUww== Received: by 10.52.37.196 with SMTP id a4mr17832394vdk.104.1351014286026; Tue, 23 Oct 2012 10:44:46 -0700 (PDT) Received: from [10.86.246.227] (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPS id qj8sm12994015veb.2.2012.10.23.10.44.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Oct 2012 10:44:38 -0700 (PDT) Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <50868827.9020509@gmail.com> Date: Tue, 23 Oct 2012 19:44:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <68437632-7990-47ED-8364-EBF80791D318@gmail.com> References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> <5082E933.60205@gmail.com> <50868827.9020509@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1283) Cc: Alexandru Petrescu , IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 17:44:47 -0000 On Oct 23, 2012, at 2:05 PM 10/23/12, Brian E Carpenter wrote: > On 20/10/2012 19:10, Alexandru Petrescu wrote: > .. >> But with vehicles, one connects a vehicle here and gets a prefix, = then >> moves in that area and gets another prefix. At that point, if the >> router obtaining a prefix wants to delegate further to another = vehicle >> needs to change the delegated prefix. >=20 > Why wouldn't RPL be used for such networks? It has built-in PD for > dynamic networks, if I understand it correctly, with RA used at the > subnet level. My understanding is that RPL assumes a multi-link subnet, with a single = prefix used across the entire network and source routing or = host-specific routing. - Ralph >=20 > Brian >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nordmark@acm.org Tue Oct 23 10:56:42 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE97721F8689 for ; Tue, 23 Oct 2012 10:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.619 X-Spam-Level: X-Spam-Status: No, score=-102.619 tagged_above=-999 required=5 tests=[AWL=0.980, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0JqIZdC8C1k for ; Tue, 23 Oct 2012 10:56:42 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id 6E24721F868F for <6man@ietf.org>; Tue, 23 Oct 2012 10:56:42 -0700 (PDT) Received: from [10.154.212.77] (128-107-239-234.cisco.com [128.107.239.234]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id q9NHudbh014192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Oct 2012 10:56:39 -0700 Message-ID: <5086DA57.8010804@acm.org> Date: Tue, 23 Oct 2012 10:56:39 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: 6man@ietf.org Subject: Fwd: New Version Notification for draft-ietf-6man-impatient-nud-05.txt References: <20121022234410.12297.80174.idtracker@ietfa.amsl.com> In-Reply-To: <20121022234410.12297.80174.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121022234410.12297.80174.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 23 Oct 2012 12:49:36 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 17:56:43 -0000 This document has corrections and clarifications based on the comments during the WG last call. Erik -------- Original Message -------- Subject: New Version Notification for draft-ietf-6man-impatient-nud-05.txt Date: Mon, 22 Oct 2012 16:44:10 -0700 From: To: CC: A new version of I-D, draft-ietf-6man-impatient-nud-05.txt has been successfully submitted by Erik Nordmark and posted to the IETF repository. Filename: draft-ietf-6man-impatient-nud Revision: 05 Title: Neighbor Unreachability Detection is too impatient Creation date: 2012-10-22 WG ID: 6man Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-ietf-6man-impatient-nud-05.txt Status: http://datatracker.ietf.org/doc/draft-ietf-6man-impatient-nud Htmlized: http://tools.ietf.org/html/draft-ietf-6man-impatient-nud-05 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-impatient-nud-05 Abstract: IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. That function is very useful when a host has an alternative, for instance multiple default routers, since it allows the host to switch to the alternative in short time. This time is 3 seconds after the node starts probing by default. However, if there are no alternatives, this is far too impatient. This document specifies relaxed rules for Neighbor Discovery retransmissions that allows an implementation to choose different timeout behavior based on whether or not there are alternatives. This document updates RFC 4861. The IETF Secretariat From john.mann@monash.edu Tue Oct 23 17:56:57 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016D611E814B for ; Tue, 23 Oct 2012 17:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VW-uErxLzAi for ; Tue, 23 Oct 2012 17:56:55 -0700 (PDT) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by ietfa.amsl.com (Postfix) with ESMTP id 41AF211E8149 for ; Tue, 23 Oct 2012 17:56:55 -0700 (PDT) Received: from mail-fa0-f70.google.com ([209.85.161.70]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKUIc81iiTacDneswTN/4YrHJXJzYgig6o@postini.com; Tue, 23 Oct 2012 17:56:55 PDT Received: by mail-fa0-f70.google.com with SMTP id v1so3988593fav.1 for ; Tue, 23 Oct 2012 17:56:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=v042AP0qVp4OmyPC27UhTI6fpFB1viO2oRqKh5sLtBY=; b=R8bjPq0yWQjOXxOY92tPFAvecJkEgwngrfNN/G2RzgrZRMrR/wYhZza4kgDUEJDFU9 vHrYlo8xuHu+qo5ZRIMP4Ype7NeYtY4eorVZxtiK61diw2x2CIZRKzrL71ItSj2btQBR 1ia0gYgDOwtjbtlTV79oP7MIQFNYFETNUuljGoJRHSuKoalF0P26zlypYLNf3aVkpMF8 JHkpmwKDHngi+1Qyb3BxedcHM7J+fHJB8uJcCW2CrCt/NDbd8iuFctGradrN/7Ia22qo 4OxIhKVar08NiuSotlPP8ocqugaijq4oo41hBjYuAIwhcPyINk6orMR5MfMmSBA8pzJj fyvA== Received: by 10.14.225.71 with SMTP id y47mr4299544eep.0.1351040213463; Tue, 23 Oct 2012 17:56:53 -0700 (PDT) Received: by 10.14.225.71 with SMTP id y47mr4299535eep.0.1351040213354; Tue, 23 Oct 2012 17:56:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.199.133 with HTTP; Tue, 23 Oct 2012 17:56:33 -0700 (PDT) In-Reply-To: <50857A63.3030102@gmail.com> References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> <5082E933.60205@gmail.com> <50831CF0.7050106@inria.fr> <50857A63.3030102@gmail.com> From: John Mann Date: Wed, 24 Oct 2012 11:56:33 +1100 Message-ID: Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=047d7b66fa51fe8a3504ccc38f1c X-Gm-Message-State: ALoCoQlzQVwzw/YFgm65NdIJaTijJ6Zq9dt86QV8jDK80Pd525MNOnwM1Mn8gj6j6gFyj/M1QQe1qCqQO6EV4HGKW2jb5VevMAKVLox1RY2HDUCIT2ux7gbMl8oBZduT+vXwauuyHjYz Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 00:56:57 -0000 --047d7b66fa51fe8a3504ccc38f1c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, On 23 October 2012 03:54, Alexandru Petrescu wrote: > Le 20/10/2012 23:51, Thierry Ernst a =E9crit : > > >> Dear Alex, >> >> Would you explain why the vehicle would need to get a new prefix (and >> thus I assume configure all the nodes in the vehicle) every time it >> enters a new area ? >> > > Well, whenever MR of a vehicle changes its attachment point it would get > a new different address, right? I can only suppose it would get a > different delegated prefix as well. It's hard to imagine that it would > get a different address but a same delegated prefix, no? (it's hard to > make same prefix valid at so many different places, harder than doing it > with addresses and it's not done with them). > > Or do you ask why LV gets a new prefix when IV changes its prefix? I > think this is obvious, no? (for topological correctness, right?) > > Or do you ask from the NEMO perspective? > > In this V2V2I work we first consider there's no MIP nor NEMO neither on > IV nor on LV. We'll see later about adding MIP. We can discuss it as > well, see how MIP would fit in this. > > Is this answering in the direction you made the question? > > Alex I'm confused about what problems are being solved / created here. I assume V2V2I is vehicle-to-vehicle-to-Internet. Why do you _want_ the LFN end devices to change IPv6 address as the vehicles move around? How about if you one-off assign prefixes to the in-car subnets, and then one-off assign host addresses to the LFNs. Then use tunnels / NEMO / Proxy MIPv6 / whatever to connect the cars to the Internet. The LFNs having stable addresses would facilitate connections to and from the Internet. Is there some soft of association between IVs and LVs? - are they owned / managed by the same people? - is there guaranteed to always be a IV in range of every LV? - are the IV's happy that the LVs are using their bandwidth to the Internet= ? - is there any need for the LFNs on IVs and LVs to communicate with each other? locally? Do e.g. cellular or satellite networks used for connecting IVs to the Internet give out different IPv6 address or delegate different prefixes as you move around? Or does it take a roam plus a "reboot" to get a new address and prefix? Thanks, John >> Thierry >> >> >> On 20/10/12 20:10, Alexandru Petrescu wrote: >> >>> Le 20/10/2012 18:42, Mikael Abrahamsson a =E9crit : >>> >>>> On Sat, 20 Oct 2012, Alexandru Petrescu wrote: >>>> >>>> One point that guided towards choosing ND over DHCP is >>>>> topology. DHCP topology can be relatively complex with >>>>> Client/Relay/Server, whereas ND is simpler one-on-one. >>>>> >>>> >>>> There is nothing saying DHCPv6-PD can't be done in a single >>>> device (the router itself). That's what I do in my home, cisco >>>> router, local DHCPv6-PD pool, local DHCPv6-PD server, also >>>> installing routes into RIB. >>>> >>> >>> YEs, because at home one typically puts up the interface once a >>> month and gets typically the same prefix from ADSL operator as 1 >>> year before. >>> >>> But with vehicles, one connects a vehicle here and gets a prefix, >>> then moves in that area and gets another prefix. At that point, if >>> the router obtaining a prefix wants to delegate further to another >>> vehicle needs to change the delegated prefix. >>> >>> This dynamic change between the received prefix and the delegated >>> prefix is not a matter of DHCP. It can be implemented by like >>> scripting which are independent of DHCP implementation. One has to >>> touch the conf files be it of DHCP or of ND. >>> >>> _and_ Relay (or Server). This may be feasible in practice but >>>>> I think it would be cleaner to have distinct protocols on a >>>>> same machine for receiving a prefix and for sending a prefix. >>>>> >>>> >>>> What is cleaner is to use existing standards where there already >>>> is running code. >>>> >>> >>> Right, there is cleanliness in reuse. Reuse as much as possible. >>> >>> There is also the question of availability of DHCP software on >>>>> smaller platforms which have no SIM card. It may be easier to >>>>> do this with ND in smaller settings. >>>>> >>>> >>>> I'd imagine that there already are 2-3 existing FOSS available >>>> implementations that do what you need for DHCPv6-PD client and >>>> server. Instead you want to invent a new standard and create new >>>> code. >>>> >>> >>> In addition to FOSS (what is FOSS?) DHCP one also needs to >>> dynamically change the delegated prefix when the assigned prefix >>> changed. >>> >>> I'm not saying this shouldn't be done, I'm just saying I don't >>>> really see the rationale for it. I used to hate DHCPv6 role in >>>> IPv6, but after a few years of being exposed to it, I've come to >>>> accept that this is the way it is. There is code going back to a >>>> standard Windows Vista that correctly implements DHCPv6-PD >>>> client, and that is what, 5-6 years ago it was released? I've had >>>> PD in my home on Cisco code for 3-5 years already, with no server >>>> infrastructure at all, just single device doing "everything" for >>>> the role needed. >>>> >>>> If this was 2002, I'd agree with you that ND PD could be >>>> feasable, but I believe the train has already left the station >>>> and we should focus on keeping IPv6 stable when it comes to how >>>> it works, and get implementations going, not new standards. >>>> >>> >>> WEll yes, I agree that IPv6 should be kept stable and part of that >>> may be that we try to make sure that a new proposal does not break >>> existing implementation. This is a matter of further work. >>> >>> Alex >>> >>> ------------------------------**------------------------------**-------= - >>> >>> >>> IETF IPv6 working group mailing list > >> ipv6@ietf.org Administrative Requests: >>> https://www.ietf.org/mailman/**listinfo/ipv6 >>> ------------------------------**------------------------------**-------= - >>> >> >> >>> >> >> ------------------------------**------------------------------**-------- >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests: https://www.ietf.org/mailman/**listinfo/ipv6 >> ------------------------------**------------------------------**-------- >> >> > > ------------------------------**------------------------------**-------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/**listinfo/ipv6 > ------------------------------**------------------------------**-------- > --047d7b66fa51fe8a3504ccc38f1c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,


On 23 October 2012 03= :54, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
Le 20/10/2012 23:51, Thierry Ernst a =E9crit= :


Dear Alex,

Would you explain why the vehicle would need to get a new prefix (and
=A0thus I assume configure all the nodes in the vehicle) every time it
=A0enters a new area ?

Well, whenever MR of a vehicle changes its attachment point it would get a new different address, right? =A0I can only suppose it would get a
different delegated prefix as well. =A0It's hard to imagine that it wou= ld
get a different address but a same delegated prefix, no? (it's hard to<= br> make same prefix valid at so many different places, harder than doing it with addresses and it's not done with them).

Or do you ask why LV gets a new prefix when IV changes its prefix? =A0I
think this is obvious, no? (for topological correctness, right?)

Or do you ask from the NEMO perspective?

In this V2V2I work we first consider there's no MIP nor NEMO neither on=
IV nor on LV. =A0We'll see later about adding MIP. =A0We can discuss it= as
well, see how MIP would fit in this.

Is this answering in the direction you made the question?

Alex

I'm confused about what problems a= re being solved / created here.

I assume V2V2I= is vehicle-to-vehicle-to-Internet.

Why do you _wa= nt_ the LFN end devices to change IPv6 address as the vehicles move around?=

How about if you one-off assign prefixes to the in-car = subnets, and then one-off assign host addresses to the LFNs.
Then= use tunnels / NEMO / Proxy MIPv6 / whatever to connect the cars to the Int= ernet.
The LFNs having stable addresses would facilitate connections to and f= rom the Internet.

Is there some soft of associatio= n between IVs and LVs? =A0
- are they owned / managed by the same= people?
- is there guaranteed to always be a IV in range of every LV?
- are the IV's happy that the LVs are using their bandwidth to the In= ternet?
- is there any need for the LFNs on IVs and LVs to commun= icate with each other? locally?
=A0
Do e.g. cellular or satellite networks used for connecti= ng IVs to the Internet give out different IPv6 address or delegate differen= t prefixes as you move around?
Or does it take a roam plus a &quo= t;reboot" to get a new address and prefix?

Thanks,
=A0 =A0 John



Thierry


On 20/10/12 20:10, Alexandru Petrescu wrote:
Le 20/10/2012 18:42, Mikael Abrahamsson a =E9crit :
On Sat, 20 Oct 2012, Alexandru Petrescu wrote:

One point that guided towards choosing ND over DHCP is
topology. DHCP topology can be relatively complex with
Client/Relay/Server, whereas ND is simpler one-on-one.

There is nothing saying DHCPv6-PD can't be done in a single
device (the router itself). That's what I do in my home, cisco
router, local DHCPv6-PD pool, local DHCPv6-PD server, also
installing routes into RIB.

YEs, because at home one typically puts up the interface once a
month and gets typically the same prefix from ADSL operator as 1
year before.

But with vehicles, one connects a vehicle here and gets a prefix,
then moves in that area and gets another prefix. =A0At that point, if
the router obtaining a prefix wants to delegate further to another
vehicle needs to change the delegated prefix.

This dynamic change between the received prefix and the delegated
prefix is not a matter of DHCP. =A0It can be implemented by like
scripting which are independent of DHCP implementation. =A0One has to
touch the conf files be it of DHCP or of ND.

_and_ Relay (or Server). =A0This may be feasible in practice but
I think it would be cleaner to have distinct protocols on a
same machine for receiving a prefix and for sending a prefix.

What is cleaner is to use existing standards where there already
is running code.

Right, there is cleanliness in reuse. =A0Reuse as much as possible.

There is also the question of availability of DHCP software on
smaller platforms which have no SIM card. =A0It may be easier to
do this with ND in smaller settings.

I'd imagine that there already are 2-3 existing FOSS available
implementations that do what you need for DHCPv6-PD client and
server. Instead you want to invent a new standard and create new
code.

In addition to FOSS (what is FOSS?) DHCP one also needs to
dynamically change the delegated prefix when the assigned prefix
changed.

I'm not saying this shouldn't be done, I'm just saying I don= 9;t
really see the rationale for it. I used to hate DHCPv6 role in
IPv6, but after a few years of being exposed to it, I've come to
accept that this is the way it is. There is code going back to a
standard Windows Vista that correctly implements DHCPv6-PD
client, and that is what, 5-6 years ago it was released? I've had
PD in my home on Cisco code for 3-5 years already, with no server
infrastructure at all, just single device doing "everything" for<= br> the role needed.

If this was 2002, I'd agree with you that ND PD could be
feasable, but I believe the train has already left the station
and we should focus on keeping IPv6 stable when it comes to how
it works, and get implementations going, not new standards.

WEll yes, I agree that IPv6 should be kept stable and part of that
may be that we try to make sure that a new proposal does not break
existing implementation. =A0This is a matter of further work.

Alex

-------------------------------------------------------------= -------


IETF IPv6 working group mailing list
ipv6@ietf.org Admini= strative Requests:
ht= tps://www.ietf.org/mailman/listinfo/ipv6
-------------------------------------------------------------= -------




-------------------------------------------------------------= -------
IETF IPv6 working group mailing list ipv6@ietf.org Administrative
Requests: https://www.ietf.org/mailman/listinfo/ipv6
-------------------------------------------------------------= -------



-------------------------------------------------------------= -------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
-------------------------------------------------------------= -------

--047d7b66fa51fe8a3504ccc38f1c-- From n@arifumi.net Tue Oct 23 23:03:26 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6EA721F8D5C for ; Tue, 23 Oct 2012 23:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.877 X-Spam-Level: X-Spam-Status: No, score=-102.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qDhjIvapPuC for ; Tue, 23 Oct 2012 23:03:26 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1098F21F8D56 for ; Tue, 23 Oct 2012 23:03:25 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so162688vbb.31 for ; Tue, 23 Oct 2012 23:03:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=FRPm/QWyXqmbfxiAtmfrIyw0tg9ZdiH1ta1kL1HCabE=; b=HDswVOCBxqR+FaxmT1q8iY7i7nhBH/5fiKAvGuyEysWGG8PZ6d4l2RJfk1ktgM2Ww6 7Dj1TRFV7TLvQQnGqSX0Ig1EZZT4zh5LJrIEFXDazG4fHqHPkR76GpTJ/f7loocNywpv JPojjLyYv0mwIjGYkBmSnmRFWmZZluvBzQWdVHD1o8aI0jRE/RtbYHAx7EHLiOTpOqcy CoP15hx9aWpGaWfZV7SVkYTbRtd/Gb6NAz6ECFxSpTK1GI0bRwZ2ugBiIc/Uhtry77jc z1Yfw2oi1TP0zrkOTZseBSIOzIXxn7SC8mUT05tvCVpK1ZEi++ts2A4J/Hb2DgTcapiP HMlw== MIME-Version: 1.0 Received: by 10.220.208.210 with SMTP id gd18mr6330644vcb.43.1351058605483; Tue, 23 Oct 2012 23:03:25 -0700 (PDT) Sender: n@arifumi.net Received: by 10.58.178.229 with HTTP; Tue, 23 Oct 2012 23:03:25 -0700 (PDT) X-Originating-IP: [192.47.162.190] In-Reply-To: <50854C48.4050808@globis.net> References: <0D1941A7-217D-44E1-A3E3-45D30D51A273@employees.org> <50754741.9090506@globis.net> <507D78AA.7020502@globis.net> <3BC7566D-CC2B-4B8A-A186-6EA840EB9341@ecs.soton.ac.uk> <50854C48.4050808@globis.net> Date: Wed, 24 Oct 2012 15:03:25 +0900 X-Google-Sender-Auth: 6oH9ct5k6mo_X1qb4DAV0ImiZ5A Message-ID: Subject: Re: Re: 6MAN WG Last Call: From: Arifumi Matsumoto To: Ray Hunter Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn5DJUoYsLNqAzYk1h9ow2SY76FvM7nNZYStdJ0xNOstIk/pzmf20OesXGhq+lP9ZmpjB2j Cc: Tim Chown , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 06:03:27 -0000 Ray, > Suggested text for Section 4.2 > > s/When the information from the DHCP server goes stale, the policy > received form the DHCP server should be removed and the default policy > should be restored./When the information from the DHCP server goes > stale, the policy received from the DHCP server should be deprecated./ I think the text above looks reasonable. > > Optionally add to 4.2. /Which policy should then become active is a > matter for the local implementation./ I think we do not need this one. Thanks. 2012/10/22 Ray Hunter : > Tim Chown wrote: >> On 22 Oct 2012, at 10:00, Arifumi Matsumoto wrote: >> >>> 2012/10/17 Ray Hunter : >>>> It's really a question of if we need to further clarify what is meant by >>>> "default policy" in Section 4.2 of draft-ietf-6man-addr-select-opt-06. >>>> >>>> Is it the manually configured node-specific default, or the RFC6724 section >>>> 2.1 default policy table, or is this behaviour simply implementation >>>> dependent and we should remain silent on an appropriate default? >>> IMHO, it should be complex to allow to receive distributed policy even >>> when the policy is manually configured. However, I agree that it should be >>> out-of-scope of this document. This document should just state the >>> requirements as in 4.1. >> >> The idea in the original discussions was that 'default policy' meant the default described in the RFC, rather than something local to the site. After all, the reason a site may be using this DHCPv6 option is to change that default. >> >> Tim > Not necessarily. In the days of highly mobile nodes, the concept of site > is going to become vague. > > Any manual configured policy on a node is likely to be node specific, > and not site specific. It might even be that the manual config detects > network settings before becoming active. e.g. based on local interface > address ranges. There's plenty examples of this today in e.g. Windows. > > The network operator may want to positively hint to the end node that it > should be running the RFC6724 defined default policy on this network > (and not some manually configured policy used by this node when > connected to other networks.) I agree that it is possible to implement > this behavior by the network operator configuring an explicit DHCPv6 > policy table that matches the RFC6724 default table, and the user > accepting this policy as defined in 4.1. > > > I believe in symmetry, so handling stale DHCPv6 information should > really be the reverse process of 4.1 > > For example, when the DHCPv6 policy expires (due to a timeout, or the > end node disconnecting from the network), you could get a situation > where the user has accepted a DHCPv6 distributed policy from network X, > but they may revert to a connection to another network Y that does not > support DHCPv6 distributed policy, but does require a manually > configured policy. Then it would make sense to install the manually > configured policy. Equally, they may also still be connected to network > X and it's just the DHCPv6 that has timed out. In which case keeping the > DHCPv6 policy active might be the correct thing to do. Or they might be > connected to a completely new network, in which case the RFC6724 default > is appropriate. > > I therefore think it probably should then be left to the end node > whether the end node should reactivate the manually configured (node > default) policy, or the RFC6724 defined default policy, or keep the > DHCPv6 learned policy active even though it has timed out. > > Suggested text for Section 4.2 > > s/When the information from the DHCP server goes stale, the policy > received form the DHCP server should be removed and the default policy > should be restored./When the information from the DHCP server goes > stale, the policy received from the DHCP server should be deprecated./ > > Optionally add to 4.2. /Which policy should then become active is a > matter for the local implementation./ > > regards, > RayH From alexandru.petrescu@gmail.com Wed Oct 24 05:41:59 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F6121F8B7E for ; Wed, 24 Oct 2012 05:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmhClaghHDHu for ; Wed, 24 Oct 2012 05:41:58 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id E774221F8B4F for ; Wed, 24 Oct 2012 05:41:57 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q9OCftMF005775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Oct 2012 14:41:55 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q9OCftU2010589; Wed, 24 Oct 2012 14:41:55 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q9OCfmVF027971; Wed, 24 Oct 2012 14:41:55 +0200 Message-ID: <5087E20C.8090409@gmail.com> Date: Wed, 24 Oct 2012 14:41:48 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: draft-kaiser-nd-pd-00.txt (was: Announcing...) References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> <5082E933.60205@gmail.com> <50868827.9020509@gmail.com> In-Reply-To: <50868827.9020509@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 12:41:59 -0000 Le 23/10/2012 14:05, Brian E Carpenter a écrit : > On 20/10/2012 19:10, Alexandru Petrescu wrote: .. >> But with vehicles, one connects a vehicle here and gets a prefix, >> then moves in that area and gets another prefix. At that point, >> if the router obtaining a prefix wants to delegate further to >> another vehicle needs to change the delegated prefix. > > Why wouldn't RPL be used for such networks? It has built-in PD for > dynamic networks, if I understand it correctly, with RA used at the > subnet level. RA used to exchange routes - if this is what you mean, and yes it may be used by RPL (last time I read it). If the question is about this, then I think it is pertinent. One may imagine a way to use RPL on the MRs for that purpose. However, I doubt RPL can Delegate Prefixes (in the pure sense of Prefix Delegation). What we need here is a means to Delegate Prefixes, not to exchange routes. A Prefix is Delegated by one Router to Another by setting up a route at self towards the other _and_ informing the other about this Delegated Prefix. The route exchange operation is different: router sets up a route entry about a route that the other router tells. For the operation of exchanging routes we use a different protocol than RPL, which is also based on RA, but not ND-PD (it is http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-02) Alex > > Brian > > > From alexandru.petrescu@gmail.com Wed Oct 24 05:53:02 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6536D21F8B93 for ; Wed, 24 Oct 2012 05:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.05 X-Spam-Level: X-Spam-Status: No, score=-10.05 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbZRxW4WiatO for ; Wed, 24 Oct 2012 05:53:01 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id E7F7D21F8B88 for ; Wed, 24 Oct 2012 05:53:00 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q9OCqxU4009439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Oct 2012 14:52:59 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q9OCqwmT014775; Wed, 24 Oct 2012 14:52:58 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q9OCqs3G003013; Wed, 24 Oct 2012 14:52:58 +0200 Message-ID: <5087E4A6.60600@gmail.com> Date: Wed, 24 Oct 2012 14:52:54 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: John Mann Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> <5082E933.60205@gmail.com> <50831CF0.7050106@inria.fr> <50857A63.3030102@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 12:53:02 -0000 Hi, Le 24/10/2012 02:56, John Mann a écrit : > Hi, > > > On 23 October 2012 03:54, Alexandru Petrescu > > wrote: > > Le 20/10/2012 23:51, Thierry Ernst a écrit : > > > Dear Alex, > > Would you explain why the vehicle would need to get a new prefix > (and > thus I assume configure all the nodes in the vehicle) every > time it > enters a new area ? > > > Well, whenever MR of a vehicle changes its attachment point it would get > a new different address, right? I can only suppose it would get a > different delegated prefix as well. It's hard to imagine that it would > get a different address but a same delegated prefix, no? (it's hard to > make same prefix valid at so many different places, harder than doing it > with addresses and it's not done with them). > > Or do you ask why LV gets a new prefix when IV changes its prefix? I > think this is obvious, no? (for topological correctness, right?) > > Or do you ask from the NEMO perspective? > > In this V2V2I work we first consider there's no MIP nor NEMO neither on > IV nor on LV. We'll see later about adding MIP. We can discuss it as > well, see how MIP would fit in this. > > Is this answering in the direction you made the question? > > Alex > > > I'm confused about what problems are being solved / created here. > > I assume V2V2I is vehicle-to-vehicle-to-Internet. Yes. > Why do you _want_ the LFN end devices to change IPv6 address as the > vehicles move around? Well, it may indeed be desirable to avoid that change. But there is still a need for initial assignment of IP addresses, no? Since this is IPv6 no NAT, what IP addresses should be initially assigned to devices in vehicles? > How about if you one-off assign prefixes to the in-car subnets, and then > one-off assign host addresses to the LFNs. It is a possible way. When pre-assigning theses addresses one realizes though they are topologically correct at only one place in the Internet. I.e. if we assign a vehicle the prefix A which is valid in by lab X when I move the vehicle in area Y the prefix A is no longer valid. I.e. one must absolutely use a tunnelling form to connect prefix A in area Y, right? Or, first we don't want to use MIP (we'll see later about MIP). > Then use tunnels / NEMO / Proxy MIPv6 / whatever to connect the cars to > the Internet. Well yes. But we try it here without tunnels. This has certain advantages: no need to use HA, no tunnelling, no triangular routing, etc. (I wonder whether there's any other tunneling form than MIP, PMIP, VPN and 6to4). > The LFNs having stable addresses would facilitate connections to and > from the Internet. Yes, only if tunnelling is used. There are additional ways to form stable addresses (we consider VIN, more later) in a vehicle. These can be used to connect vehicles between selves forming a local domain, but disconnected from the Internet. This has still advantages over no connection at all. It would be abnormal to forbid two vehicles in close vicinity to talk to each other just because Internet is not available there, or because their MIP can not connect to the HA. For this we use VIN to generate ULA prefixes and http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-02 to exchange prefixes. > Is there some soft of association between IVs and LVs? > - are they owned / managed by the same people? no, not really. > - is there guaranteed to always be a IV in range of every LV? no, not really. There may be question of several IVs present near one LV and vice-versa. > - are the IV's happy that the LVs are using their bandwidth to the Internet? Probably yes. Advertisement billboard vehicles are such kind. > - is there any need for the LFNs on IVs and LVs to communicate with each > other? locally? YEs, like at an incident scene, where law enforcement fire department vehicles deployed need to exchange files about a casualty. > Do e.g. cellular or satellite networks used for connecting IVs to the > Internet give out different IPv6 address or delegate different prefixes > as you move around? I guess yes - different as we move around. > Or does it take a roam plus a "reboot" to get a new address and prefix? I guess yes, a roam and a reboot, some times. Alex > > Thanks, > John > > > > Thierry > > > On 20/10/12 20:10, Alexandru Petrescu wrote: > > Le 20/10/2012 18:42, Mikael Abrahamsson a écrit : > > On Sat, 20 Oct 2012, Alexandru Petrescu wrote: > > One point that guided towards choosing ND over DHCP is > topology. DHCP topology can be relatively complex with > Client/Relay/Server, whereas ND is simpler one-on-one. > > > There is nothing saying DHCPv6-PD can't be done in a single > device (the router itself). That's what I do in my home, > cisco > router, local DHCPv6-PD pool, local DHCPv6-PD server, also > installing routes into RIB. > > > YEs, because at home one typically puts up the interface once a > month and gets typically the same prefix from ADSL operator as 1 > year before. > > But with vehicles, one connects a vehicle here and gets a > prefix, > then moves in that area and gets another prefix. At that > point, if > the router obtaining a prefix wants to delegate further to > another > vehicle needs to change the delegated prefix. > > This dynamic change between the received prefix and the > delegated > prefix is not a matter of DHCP. It can be implemented by like > scripting which are independent of DHCP implementation. One > has to > touch the conf files be it of DHCP or of ND. > > _and_ Relay (or Server). This may be feasible in > practice but > I think it would be cleaner to have distinct > protocols on a > same machine for receiving a prefix and for sending > a prefix. > > > What is cleaner is to use existing standards where there > already > is running code. > > > Right, there is cleanliness in reuse. Reuse as much as > possible. > > There is also the question of availability of DHCP > software on > smaller platforms which have no SIM card. It may be > easier to > do this with ND in smaller settings. > > > I'd imagine that there already are 2-3 existing FOSS > available > implementations that do what you need for DHCPv6-PD > client and > server. Instead you want to invent a new standard and > create new > code. > > > In addition to FOSS (what is FOSS?) DHCP one also needs to > dynamically change the delegated prefix when the assigned prefix > changed. > > I'm not saying this shouldn't be done, I'm just saying I > don't > really see the rationale for it. I used to hate DHCPv6 > role in > IPv6, but after a few years of being exposed to it, I've > come to > accept that this is the way it is. There is code going > back to a > standard Windows Vista that correctly implements DHCPv6-PD > client, and that is what, 5-6 years ago it was released? > I've had > PD in my home on Cisco code for 3-5 years already, with > no server > infrastructure at all, just single device doing > "everything" for > the role needed. > > If this was 2002, I'd agree with you that ND PD could be > feasable, but I believe the train has already left the > station > and we should focus on keeping IPv6 stable when it comes > to how > it works, and get implementations going, not new standards. > > > WEll yes, I agree that IPv6 should be kept stable and part > of that > may be that we try to make sure that a new proposal does not > break > existing implementation. This is a matter of further work. > > Alex > > ------------------------------__------------------------------__-------- > > > IETF IPv6 working group mailing list > > ipv6@ietf.org Administrative Requests: > https://www.ietf.org/mailman/__listinfo/ipv6 > > ------------------------------__------------------------------__-------- > > > > > > ------------------------------__------------------------------__-------- > IETF IPv6 working group mailing list ipv6@ietf.org > Administrative > Requests: https://www.ietf.org/mailman/__listinfo/ipv6 > > ------------------------------__------------------------------__-------- > > > > ------------------------------__------------------------------__-------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: > https://www.ietf.org/mailman/__listinfo/ipv6 > > ------------------------------__------------------------------__-------- > > From bs7652@att.com Wed Oct 24 10:04:54 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF62B21F847D for ; Wed, 24 Oct 2012 10:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAW7UKmt3KES for ; Wed, 24 Oct 2012 10:04:54 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id C1E1921F847C for ; Wed, 24 Oct 2012 10:04:53 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo08.seg.att.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-12) with ESMTP id 5bf18805.7dfa7940.282429.00-534.765138.nbfkord-smmo08.seg.att.com (envelope-from ); Wed, 24 Oct 2012 17:04:53 +0000 (UTC) X-MXL-Hash: 50881fb5270ff5f1-736dec06b9b83011beccf2aa6aee0f221348afaa Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 4bf18805.0.282406.00-479.765069.nbfkord-smmo08.seg.att.com (envelope-from ); Wed, 24 Oct 2012 17:04:52 +0000 (UTC) X-MXL-Hash: 50881fb41b850f01-261651199b29072fb1469aea12e18e049d3ae09b Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q9OH4qa2020397; Wed, 24 Oct 2012 13:04:52 -0400 Received: from sflint03.pst.cso.att.com (sflint03.pst.cso.att.com [144.154.234.230]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q9OH4ckZ019943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Oct 2012 13:04:47 -0400 Received: from GAALPA1MSGHUB9F.ITServices.sbc.com (gaalpa1msghub9f.itservices.sbc.com [130.8.36.92]) by sflint03.pst.cso.att.com (RSA Interceptor); Wed, 24 Oct 2012 13:04:21 -0400 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([130.8.36.71]) by GAALPA1MSGHUB9F.ITServices.sbc.com ([130.8.36.92]) with mapi id 14.02.0318.001; Wed, 24 Oct 2012 13:04:16 -0400 From: "STARK, BARBARA H" To: Alexandru Petrescu Subject: RE: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt Thread-Topic: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt Thread-Index: AQHNrc/KcdZYweJ3cUeP1IPiw82z0ZfAiVKAgACBAICAAAdggIABjDMAgAANUQCAABi7gIAAPa4AgALRwICAAhjhgIAAyCYA///IQ5A= Date: Wed, 24 Oct 2012 17:04:15 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6112446A6C4@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> <5082E933.60205@gmail.com> <50831CF0.7050106@inria.fr> <50857A63.3030102@gmail.com> <5087E4A6.60600@gmail.com> In-Reply-To: <5087E4A6.60600@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.102.30] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=fKeOK+me c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=sUbhmq7IQm4A:10 a=MR_RECZg5L8A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=X2pa4iLV5bgA:10 a=YYyMG6lJALyOlqVL-v4A:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 17:04:55 -0000 If an LV never ever wanted to get a PD from anything other than an IV, and = an IV could only ever expect to delegate to a LV, then I see no problem. On= the other hand, if these things do expect the same physical links to be us= ed to connect with other ecosystems (like home networks or hotspots) that w= ill be well-established in the IPv6 world by the time these vehicles come a= long, then I think this proposal has some undesirable ramifications.=20 Questions: Would an LV ever expect to use the same physical link to connect to a home = network or hotspot, instead of an IV? Would an IV ever expect to provide connectivity for devices that think they= 're inside a home network (e.g., maybe they're in a RV park, and the RV-own= ers networks are made up of traditional home networking components, so they= can connect to non-cellular uplinks when such are available; maybe the IV = is the truck pulling a trailer, and there's a regular home network set up i= n the trailer). If the answer is no, then read no further. If the answer is yes, then I'd like to dive a little deeper into understand= ing the ramifications of what is proposed. Hotspots and CE (home network) routers will use IA_PD for prefix delegation= . Sub-delegating routers attaching to them will request prefixes by IA_PD. Which means either the LV would have to support both ND_PD and IA_PD, or th= e hotspot/CE router would have to do so. And whoever does both would have t= o know which to use in which case, and make sure they don't get things conf= used between the two. Somebody's complexity-of-code has just been doubled (= or more) by the addition of a 2nd way to do the same thing. If it's the hot= spot/CE router, then it would have to run both delegation mechanisms simult= aneously and keep track of prefixes delegated by IA_PD and ND_PD -- making = sure there's no overlap in delegated prefixes and such. On the IV side -- if the IV expects to be able to provide connectivity to r= egular CE routers as well as LVs, then either all of the CE routers would h= ave to support both requesting mechanisms, or the IV would have to support = both delegating mechanisms (simultaneously, in case some attaching devices = are LV and some are regular CE routers). It would be interesting to see who ended up having to do both mechanisms: v= ehicles or everyone else. My preference would be that vehicles should be th= e ones to incur the additional complexity, since they're the ones who cause= d the additional complexity. Of course, we don't get to choose -- the marke= tplace chooses. Generally, the choice is made according to (1) who sees gre= ater benefit in being able to connect to the other, and (2) who was there f= irst and already has a significant embedded base. My tea leaf reading is th= at there's going to be a huge embedded base of IPv6-connected hotspots and = CE routers with IA_PD long before these vehicles come to fruition. Home net= works and hotspots are already successful without connecting to vehicles. F= or "connected vehicles" to be desirable in the eyes of consumers, I believe= they will have to be able to connect to the consumers' home networks. So I= think vehicles will have to be the ones to go the extra mile to connect to= existing ecosystems. My Conclusion: If vehicles are really only ever expected to talk to other v= ehicles via this particular link, the proposal could be considered in the v= acuum of its stand-alone ecosystem. But if the possibility is likely that v= ehicles will want to interact with other ecosystems over that same link, th= en somebody has to suffer and support both ways of doing the same thing. Th= e savings of a couple of short messages at attachment time is, IMO, not wor= th the additional complexity on either side. And the advantage to vehicles = of being able to operate in both ecosystems is much greater than the advant= age of saving a couple of messages at attachment time. Barbara From sarikaya2012@gmail.com Wed Oct 24 12:19:17 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD5A21F86EB for ; Wed, 24 Oct 2012 12:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.527 X-Spam-Level: X-Spam-Status: No, score=-3.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGK1ulONXT6E for ; Wed, 24 Oct 2012 12:19:16 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id D128321F86E5 for ; Wed, 24 Oct 2012 12:19:16 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so1388970iec.31 for ; Wed, 24 Oct 2012 12:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ZAePjMkjw3pPwKCTBpfOFvA3SBuQjYFG9uaI9a6n75M=; b=qefw4CH0/8Jak/1Ly1jZYVo3rUKuWpOBbt4N3xlnjsnFUiiMQQ03riLTolA1b8N060 YezAUtRPVu2zcttV+WcKDv4WRnH2G5/l3uDN6eMMUBn8Lct8Z1i4m/1Ed4HpynKbNwDk QMzI9CX2RR7dkhVkBDcZ/7/cSEw+nbPFljUjho54OnlNGhIKjIHpPILqim8loK82JwjV /SzqKSd01b/2UkN56CkKROBAFzz2uAwfYf0UyZZ/jAKJinxNDHYfHJ2yvQZecNkUZs/h RWSKK8JdtsshO2USxoJh+shtny9k5qoxFIIbdNWKw1jquYWiVqdOJJUUyjR+k9qSylhd pD/w== MIME-Version: 1.0 Received: by 10.50.173.37 with SMTP id bh5mr3633367igc.45.1351106356514; Wed, 24 Oct 2012 12:19:16 -0700 (PDT) Received: by 10.231.85.26 with HTTP; Wed, 24 Oct 2012 12:19:16 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Oct 2012 14:19:16 -0500 Message-ID: Subject: Re: 6man IETF85 Call for agenda items From: Behcet Sarikaya To: Bob Hinden Content-Type: text/plain; charset=ISO-8859-1 Cc: "ipv6@ietf.org Mailing List" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 19:19:17 -0000 Hi Bob, I would like to request a slot to present: my draft on IPv6 RA Options for Multiple Interface Next Hop Routes at http://tools.ietf.org/html/draft-sarikaya-mif-6man-ra-route-01 and also IPv6 RA Options for Translation Multicast Prefixes at http://tools.ietf.org/html/draft-sarikaya-softwire-6man-raoptions-00. Regards, Behcet On Thu, Oct 4, 2012 at 3:24 PM, Bob Hinden wrote: > 6MAN has a 2 1/2 hour slot allocated for Atlanta: > > 6man Session 1 (2:30:00) > 5 November 2012 > Monday, Morning Session I 0900-1130 > Room Name: Salon D > > [Note the date and time might change] > > If you have a draft you would like to discuss, please send your request for agenda time to the 6man chairs. Please include in the request, the title and file name of the draft, the speakers name (and email), and how much time you need. > > We will prioritise drafts that are working group items, drafts that have been actively discussed on the list, and other individual submissions in that order. > > Please have agenda items to us by 15 October 2012 and also note the following deadlines for IETF85: > > 2012-10-15 (Monday): Internet Draft Cut-off for initial document (-00) submission by UTC 24:00 > 2012-10-22 (Monday): Internet Draft final submission cut-off by UTC 24:00 > > Regards, > > Bob & Ole > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From otroan@employees.org Thu Oct 25 00:57:27 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE17321F899D for ; Thu, 25 Oct 2012 00:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.271 X-Spam-Level: X-Spam-Status: No, score=-10.271 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0H+XnnXqRNKz for ; Thu, 25 Oct 2012 00:57:27 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2797121F899A for ; Thu, 25 Oct 2012 00:57:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4KAL7viFCQ/khR/2dsb2JhbABEg3+BTrxRgQiCHwEBBBIBCh0/EAtGVwYcGYdiC505oAeRbWEDm1eIaoFrgnE X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="145782809" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 25 Oct 2012 07:57:23 +0000 Received: from [10.148.10.39] ([10.148.10.39]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9P7vNJB000387 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Oct 2012 07:57:23 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) Subject: Re: 6man IETF85 Call for agenda items From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Thu, 25 Oct 2012 09:57:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "ipv6@ietf.org Mailing List" X-Mailer: Apple Mail (2.1498) Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 07:57:28 -0000 All, I have posted a draft agenda at: http://www.ietf.org/proceedings/85/agenda/agenda-85-6man If something has been missed, please let the chairs know. As we are meeting first thing Monday morning, please let the chairs have = the slides as soon as possible, no later than Saturday the 3rd of = November please. Best regards, Ole and Bob From mcr@sandelman.ca Thu Oct 25 04:15:36 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69AFD21F8998 for ; Thu, 25 Oct 2012 04:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwzVT5at6fmY for ; Thu, 25 Oct 2012 04:15:35 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id BD13F21F8997 for ; Thu, 25 Oct 2012 04:15:35 -0700 (PDT) Received: from sandelman.ca (CPE0011450204d7-CM18593396feb1.cpe.net.cable.rogers.com [99.232.135.228]) by relay.sandelman.ca (Postfix) with ESMTPS id C4BEF81A9 for ; Thu, 25 Oct 2012 07:07:49 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A0CC0CA0BC for ; Thu, 25 Oct 2012 07:14:53 -0400 (EDT) From: Michael Richardson To: IPv6 Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt In-reply-to: <68437632-7990-47ED-8364-EBF80791D318@gmail.com> References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> <5082E933.60205@gmail.com> <50868827.9020509@gmail.com> <68437632-7990-47ED-8364-EBF80791D318@gmail.com> Comments: In-reply-to Ralph Droms message dated "Tue, 23 Oct 2012 19:44:32 +0200." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 25 Oct 2012 07:14:53 -0400 Message-ID: <21235.1351163693@sandelman.ca> Sender: mcr@sandelman.ca X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 11:15:36 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Ralph Droms wrote: >>> But with vehicles, one connects a vehicle here and gets a prefix, t= hen >>> moves in that area and gets another prefix. At that point, if the >>> router obtaining a prefix wants to delegate further to another vehi= cle >>> needs to change the delegated prefix. >>=20 >> Why wouldn't RPL be used for such networks? It has built-in PD for >> dynamic networks, if I understand it correctly, with RA used at the >> subnet level. RD> My understanding is that RPL assumes a multi-link subnet, with a RD> single prefix used across the entire network and source routing or RD> host-specific routing.=20 RPL doesn't care.=20=20 It's all /128 routes to anything not on the local (physical) link.=20 Whether it's source routes or hop-by-hop LPM depends upon whether the mode of operation is storing or not. They don't have to come from the same subnet. The RPL Target Option, contained in the DAO that travels up the tree, has a prefix and length. In typical layer-3 subnet mesh networks, it contains /128 prefixes.=20=20 Like others on this thread, I'd like to know how real this vehicle use case is. Is CAE really working on such a thing? My opinion is that vendor of vehicles should obtain a Non-Connected Network prefix from a suitable registry, or from not-yet-agreed-to-be-useful ULA-Central, and have the the MR-IV and MR-LV (permanently) number the LFNs.=20=20=20 When two cars connect for some non-Internet access reason (including to talk into the homenet), they should speak RPL to each other across the E1 link(s). The DAG would not be grounded. Like all the other home LLNs, the gateway into the homenet would need to run RPL on one side, and homenet-routing-protocol on the other side (zOSPF, whatever). It would announce the prefixes of the vehicle into the homenet (another kind of "walled garden"!!), just like the lighting system does. If Internet connectivity is available/desired, then one of two things occur (not both): 1) the Internet connected vehicle obtains topologically significant (PA) address via homenet-routing-protocol, and then forms a new (grounded) DODAG which can be shared with adjacent vehicles that want connectivity. This solution is probably more secure and probably will work in many non-homenet environments, since homenet-routing-protocol isn't the only way to get prefixes, and even if you get only a single /64, RPL will let you "share" it. 2) the Internet connected vehicle becomes a homenet router, and speaks homenet-routing-protocol on E1 link and enough address space for all vehicles is obtained. The PA addresses live only for the duration that the vehicle(s) are connected. Again, maybe I missed the bigger picture: who is building these IPv6 enabled vehicles? (And where can I get one?) =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQiR8tAAoJEKD0KQ7Gj3P2zDQIAJbIwIJ9Mlxu6K/S3GBBL7Re sSiPuB4b1pNOEZHrQA89jc1JQLheoNMM1RTkGXoBHEv+iRJ1bpNnErAy0obiYA+L 6IUvE3xXFOCQBA05qdGFy1DYOS23YphbVwG1E3/WmOWAEGFwJeDEG9kpb0qcqFWh A0wZqDv2trjFvXvhbL4hGanjWifU5YIzXcY/pDu6fxfhZS/t2J/1qclp2IBamLJD 8yb2zN6xSYhs0FuG1xFX7IUPbvCTULpMBVsiWP5wnNtx5hAeBWiWV4+F7SDRkfJs WyYTEjX1dbveXKqSj4IT2rXpmWGIW4RUylb8HvTV2Ngl8Z/duTZfvjDWoOSJIZ8= =V8NG -----END PGP SIGNATURE----- --=-=-=-- From alexandru.petrescu@gmail.com Thu Oct 25 05:07:13 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA5321F8AF7 for ; Thu, 25 Oct 2012 05:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.06 X-Spam-Level: X-Spam-Status: No, score=-10.06 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4truX9kaqRHS for ; Thu, 25 Oct 2012 05:07:13 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id E390721F8AF3 for ; Thu, 25 Oct 2012 05:07:12 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q9PC7B7I006552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 25 Oct 2012 14:07:11 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q9PC7B80020595; Thu, 25 Oct 2012 14:07:11 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q9PC719S014005; Thu, 25 Oct 2012 14:07:10 +0200 Message-ID: <50892B65.6090302@gmail.com> Date: Thu, 25 Oct 2012 14:07:01 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: 6man chair <6man-chairs@tools.ietf.org> Subject: Re: 6man IETF85 Call for agenda items References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IPv6 , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 12:07:13 -0000 Hello 6man chairs, If it fits within available space, I would like to request a short slot to present Prefix Delegation extensions to ND : "Prefix Delegation extension to Neighbor Discovery protocol" draft-kaiser-nd-pd-00 Speaker: Alexandru Petrescu, alexandru.petrescu@cea.fr 5min(?) For information I copy the list letting know I would like to present if possible. Yours, Alex Le 04/10/2012 22:24, Bob Hinden a écrit : > 6MAN has a 2 1/2 hour slot allocated for Atlanta: > > 6man Session 1 (2:30:00) > 5 November 2012 > Monday, Morning Session I 0900-1130 > Room Name: Salon D > > [Note the date and time might change] > > If you have a draft you would like to discuss, please send your request for agenda time to the 6man chairs. Please include in the request, the title and file name of the draft, the speakers name (and email), and how much time you need. > > We will prioritise drafts that are working group items, drafts that have been actively discussed on the list, and other individual submissions in that order. > > Please have agenda items to us by 15 October 2012 and also note the following deadlines for IETF85: > > 2012-10-15 (Monday): Internet Draft Cut-off for initial document (-00) submission by UTC 24:00 > 2012-10-22 (Monday): Internet Draft final submission cut-off by UTC 24:00 > > Regards, > > Bob & Ole > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > From mcr@sandelman.ca Thu Oct 25 07:01:28 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05F721F896F for ; Thu, 25 Oct 2012 07:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ve833l9FMwF for ; Thu, 25 Oct 2012 07:01:28 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3278F21F896B for ; Thu, 25 Oct 2012 07:01:28 -0700 (PDT) Received: from sandelman.ca (unknown [67.71.177.200]) by relay.sandelman.ca (Postfix) with ESMTPS id 687DC81AC; Thu, 25 Oct 2012 09:53:51 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6817ACA0C6; Thu, 25 Oct 2012 09:52:22 -0400 (EDT) From: Michael Richardson To: IPv6 , Alexandru Petrescu Subject: Re: draft-kaiser-nd-pd-00.txt (was: Announcing...) In-reply-to: <5087E20C.8090409@gmail.com> References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> <5082E933.60205@gmail.com> <50868827.9020509@gmail.com> <5087E20C.8090409@gmail.com> Comments: In-reply-to Alexandru Petrescu message dated "Wed, 24 Oct 2012 14:41:48 +0200." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 25 Oct 2012 09:52:22 -0400 Message-ID: <28590.1351173142@sandelman.ca> Sender: mcr@sandelman.ca X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 14:01:28 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable ralph> Why wouldn't RPL be used for such networks? It has built-in PD f= or ralph> dynamic networks, if I understand it correctly, with RA used at = the ralph> subnet level. Alexandru Petrescu wrote: AP> RA used to exchange routes - if this is what you mean, and yes it m= ay be AP> used by RPL (last time I read it). AP> If the question is about this, then I think it is pertinent. One m= ay AP> imagine a way to use RPL on the MRs for that purpose. AP> However, I doubt RPL can Delegate Prefixes (in the pure sense of Pr= efix AP> Delegation). RPL doesn't do this in protocol, but then, neither does ND. I wouldn't extend RPL to do this, however, I'd send a DHCPv6 PD format message. It can be a single exchange, and nobody said a single program can't speak multiple protocols. But, I question whether one always needs to get address space, vs announce it. I don't know the answer: it really depends upon who your second vehicle needs to talk to, and why it thinks that vehicle one (and vehicle one's ISP) is willing to give it bandwidth. If you don't want to speak RPL, then you need to pick the TBD homenet-routi= ng-protocol. We don't need a third. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQiUQUAAoJEKD0KQ7Gj3P2urAIAI4xBZ8UjAXbRLKoWqTYFLyZ V2QDCUJkqjFkOoXIJYD3fRtpOk1pAv9/VIPBlMzEAHvbsX/L8NCFAwovAYZJLrAx LFtduIuJRizEngxboDEa9Q0KoteM7erSN1Mh2ZOHv7swxic6frNlQ8mixTQIpkPP oNDMmM6ghrJ6DUKQEj8VOVi8DqZRtenfkQG91Vo3E50SvJF5FgxtGXsd0tQVA9we XUyhyZ67HJDlPCwmHCPXUhCx3JRYJzYXM6c8cLSfWWCZRPqx/TyokATGL/Q1kkxX 7C7xzUEpgITsOUXp2EYFQiKXPqUhsYq+edrkjIG/fUYDUTr5YnkhpO2YgwVEnGQ= =RDzG -----END PGP SIGNATURE----- --=-=-=-- From alexandru.petrescu@gmail.com Thu Oct 25 07:19:09 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617FA21F86E1 for ; Thu, 25 Oct 2012 07:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.069 X-Spam-Level: X-Spam-Status: No, score=-10.069 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44Ky+opVqQBu for ; Thu, 25 Oct 2012 07:19:08 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 233B221F85C0 for ; Thu, 25 Oct 2012 07:19:07 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q9PEJ4Wn009007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 25 Oct 2012 16:19:04 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q9PEJ3rA013555; Thu, 25 Oct 2012 16:19:03 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q9PEIx9G003216; Thu, 25 Oct 2012 16:19:03 +0200 Message-ID: <50894A53.5050502@gmail.com> Date: Thu, 25 Oct 2012 16:18:59 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "STARK, BARBARA H" Subject: Re: draft-kaiser-nd-pd-00.txt (was: Announcing...) References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> <5082E933.60205@gmail.com> <50831CF0.7050106@inria.fr> <50857A63.3030102@gmail.com> <5087E4A6.60600@gmail.com> <2D09D61DDFA73D4C884805CC7865E6112446A6C4@GAALPA1MSGUSR9N.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6112446A6C4@GAALPA1MSGUSR9N.ITServices.sbc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 14:19:09 -0000 Le 24/10/2012 19:04, STARK, BARBARA H a écrit : > If an LV never ever wanted to get a PD from anything other than an > IV, and an IV could only ever expect to delegate to a LV, then I see > no problem. I understand in that case there would be no problem use ND instead of DHCP to realize PD. > On the other hand, if these things do expect the same physical links > to be used to connect with other ecosystems (like home networks or > hotspots) that will be well-established in the IPv6 world by the time > these vehicles come along, then I think this proposal has some > undesirable ramifications. > > Questions: Would an LV ever expect to use the same physical link to > connect to a home network or hotspot, instead of an IV? YEs, LV would use that egress interface to connect to a fixed hotspot sometimes, instead of an IV. > Would an IV ever expect to provide connectivity for devices that > think they're inside a home network (e.g., maybe they're in a RV > park, and the RV-owners networks are made up of traditional home > networking components, so they can connect to non-cellular uplinks > when such are available; maybe the IV is the truck pulling a > trailer, and there's a regular home network set up in the trailer). Well, the trailer is still mobile, a vehicle, I think. But, even though IV would mostly be like a billboard advertisement vehicle on a highway whose clients would be other vehicles most of the time, there may also exist clients other than mobile vehicles. I can't see which right away, but why not. > If the answer is no, then read no further. If the answer is yes, > then I'd like to dive a little deeper into understanding the > ramifications of what is proposed. > > Hotspots and CE (home network) routers will use IA_PD for prefix > delegation. Yes. It would be the case for devices like LTE-WiFi boxes and for CE customer equipment. Remark though that for CE, the nature of the uplink - a cable - would make it hard to see a vehicle on it: it only sees the operator's end. I doubt there would be a conflict there. > Sub-delegating routers attaching to them will request prefixes by > IA_PD. Which would be these sub-delegating routers? WiFi range extenders? Others? I am not aware of which direction these devices take - whether or not they'd use DHCP to obtain prefixes, or open to something else. This something else may be open, even to protocols which transform an IPv4 address into some IPv6 prefix, or 6rd, or so. > Which means either the LV would have to support both ND_PD and > IA_PD, or the hotspot/CE router would have to do so. And whoever does > both would have to know which to use in which case, and make sure > they don't get things confused between the two. Somebody's > complexity-of-code has just been doubled (or more) by the addition of > a 2nd way to do the same thing. If it's the hotspot/CE router, then > it would have to run both delegation mechanisms simultaneously and > keep track of prefixes delegated by IA_PD and ND_PD -- making sure > there's no overlap in delegated prefixes and such. Well yes, code complexity. I agree that if there existed two means to delegate prefixes then complexity is added up. In that sense, one may consider that one out of the two ways to realize PD is maybe of lesser importance than the other, with less ambition in deployment. Just don't break existing DHCP-PD deployments present only where this ND-PD is tinkered with. > On the IV side -- if the IV expects to be able to provide > connectivity to regular CE routers as well as LVs, then either all > of the CE routers would have to support both requesting mechanisms, > or the IV would have to support both delegating mechanisms > (simultaneously, in case some attaching devices are LV and some are > regular CE routers). > > It would be interesting to see who ended up having to do both > mechanisms: vehicles or everyone else. My preference would be that > vehicles should be the ones to incur the additional complexity, > since they're the ones who caused the additional complexity. Of > course, we don't get to choose -- the marketplace chooses. Generally, > the choice is made according to (1) who sees greater benefit in being > able to connect to the other, and (2) who was there first and already > has a significant embedded base. My tea leaf reading is that there's > going to be a huge embedded base of IPv6-connected hotspots and CE > routers with IA_PD long before these vehicles come to fruition. Home > networks and hotspots are already successful without connecting to > vehicles. I wonder whether any device in home networks has this sub-delegating capability, I guess not. > For "connected vehicles" to be desirable in the eyes of consumers, I > believe they will have to be able to connect to the consumers' home > networks. So I think vehicles will have to be the ones to go the > extra mile to connect to existing ecosystems. In a sense I agree. It seems vehicles are the newcomers when compared to fixed networks. However, to make the DHCP-PD work in a vehicle-to-vehicle manner one would need to modify DHCP (at least make the relationship between Relay and Server be dynamic). I wonder whether any work was pursued that way. > My Conclusion: If vehicles are really only ever expected to talk to > other vehicles via this particular link, the proposal could be > considered in the vacuum of its stand-alone ecosystem. But if the > possibility is likely that vehicles will want to interact with other > ecosystems over that same link, then somebody has to suffer and > support both ways of doing the same thing. The savings of a couple > of short messages at attachment time is, IMO, not worth the > additional complexity on either side. And the advantage to vehicles > of being able to operate in both ecosystems is much greater than the > advantage of saving a couple of messages at attachment time. Barbara I read and thank you for the message. Alex > > From alexandru.petrescu@gmail.com Thu Oct 25 07:55:54 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001E821F8A14 for ; Thu, 25 Oct 2012 07:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.077 X-Spam-Level: X-Spam-Status: No, score=-10.077 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGUpe5lQwcPL for ; Thu, 25 Oct 2012 07:55:43 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA8A21F89EE for ; Thu, 25 Oct 2012 07:55:42 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q9PEtfaj028283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 25 Oct 2012 16:55:41 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q9PEtfKK029038 for ; Thu, 25 Oct 2012 16:55:41 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q9PEtXOp021508 for ; Thu, 25 Oct 2012 16:55:40 +0200 Message-ID: <508952E5.4050701@gmail.com> Date: Thu, 25 Oct 2012 16:55:33 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> <5082E933.60205@gmail.com> <50868827.9020509@gmail.com> <68437632-7990-47ED-8364-EBF80791D318@gmail.com> <21235.1351163693@sandelman.ca> In-Reply-To: <21235.1351163693@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 14:55:54 -0000 Le 25/10/2012 13:14, Michael Richardson a écrit : > > Ralph Droms wrote: >>>> But with vehicles, one connects a vehicle here and gets a >>>> prefix, then moves in that area and gets another prefix. At >>>> that point, if the router obtaining a prefix wants to delegate >>>> further to another vehicle needs to change the delegated >>>> prefix. >>> >>> Why wouldn't RPL be used for such networks? It has built-in PD >>> for dynamic networks, if I understand it correctly, with RA used >>> at the subnet level. > > RD> My understanding is that RPL assumes a multi-link subnet, with a > RD> single prefix used across the entire network and source routing > or RD> host-specific routing. > > RPL doesn't care. It's all /128 routes to anything not on the local > (physical) link. That is with route exxchange, right? Something like Router1 informs Router2 about a prefix and a next-hop, and Router2 informs Router1 about the other prefix and next-hop. But with ND-PD and PD in general one contemplates the assignment of prefix (maybe accompanied by modifying routing tables), instead of route exchange. > Whether it's source routes or hop-by-hop LPM depends upon whether > the mode of operation is storing or not. Ok, that is the way of forwarding application data packets. But it's not a way to attribute prefixes. RPL does not seem to assign neither addresses nor prefixes, which is good, if I am not mistaken. > They don't have to come from the same subnet. The RPL Target > Option, contained in the DAO that travels up the tree, has a prefix > and length. In typical layer-3 subnet mesh networks, it contains > /128 prefixes. Is that for communicating the prefix in the sense of 'route exchange' or in the sense of 'prefix delegation'? > Like others on this thread, I'd like to know how real this vehicle > use case is. Is CAE really working on such a thing? CAE... Computer-Assisted Engineering? I know not. > My opinion is that vendor of vehicles should obtain a Non-Connected > Network prefix from a suitable registry, In the vehicle industry there may exist such registry already which distributes VINs (Vehicle Identifier Numbers). But not IP addresses. Is there another such vehicular specific registry? > or from not-yet-agreed-to-be-useful ULA-Central, and have the the > MR-IV and MR-LV (permanently) number the LFNs. Or, have a method to convert from VIN to a ULA address or prefix. Like when converting MAC addresses to Interface Identifiers. > When two cars connect for some non-Internet access reason (including > to talk into the homenet), they should speak RPL to each other > across the E1 link(s). Well, we can discuss this. As much as RPL can be seen as a routing protocol for many things, hence maybe useful for vehicles too, and for homenets, it may also be seen as dedicated to Low-Power and Lossy Networks, which LTE and intra-vehicular WiFi and CAN networks are less. > The DAG would not be grounded. Like all the other home LLNs, the > gateway into the homenet would need to run RPL on one side, and > homenet-routing-protocol on the other side (zOSPF, whatever). It > would announce the prefixes of the vehicle into the homenet (another > kind of "walled garden"!!), just like the lighting system does. I read. > If Internet connectivity is available/desired, then one of two > things occur (not both): 1) the Internet connected vehicle obtains > topologically significant (PA) address via homenet-routing-protocol, > and then forms a new (grounded) DODAG which can be shared with > adjacent vehicles that want connectivity. This solution is probably > more secure and probably will work in many non-homenet environments, > since homenet-routing-protocol isn't the only way to get prefixes, > and even if you get only a single /64, RPL will let you "share" it. > > 2) the Internet connected vehicle becomes a homenet router, and > speaks homenet-routing-protocol on E1 link and enough address space > for all vehicles is obtained. > > The PA addresses live only for the duration that the vehicle(s) are > connected. I agree that IV should obtain topologically significant prefixes. Supposedly giving some of them to others interested. I doubt though RPL could do this? > Again, maybe I missed the bigger picture: who is building these IPv6 > enabled vehicles? (And where can I get one?) It's hard to answer straight without doubt. It's not my specialty, I am coming more from networks research than from vehicle field. But I couldn't imagine a connected vehicle manufacturer not considering IPv6, especially when IPv4 space has run out and NAT would make impossible the new applications querying data from vehicle, etc. And I am listening too about this. A vehicle which is IPv6 does not exist probably on the market, as we speak. What one can buy right now is equipment that is dedicated to vehicles and add it, (like in "tuning a vehicle"). This includes ruggedized linux computers, dedicated linux boards, antennas. For connection inside, one widely used CAN access is OBD-II cheap. In addition the classic short-range WiFi/Bluetooth/ZigBee could be deployed intra-vehicle, provided their chipsets can be powered on 12-24V or so. For outside vehicle one may consider 3G, GPS, DVB, LTE cheap devices and maybe cheap 802.11p although not as widely available. Having all that one faces the problem of how to assign addresses and establish routes. Alex > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From alexandru.petrescu@gmail.com Thu Oct 25 09:04:05 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2E621F8901 for ; Thu, 25 Oct 2012 09:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.927 X-Spam-Level: X-Spam-Status: No, score=-9.927 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUsz2kZeQaIa for ; Thu, 25 Oct 2012 09:04:05 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 1283821F859E for ; Thu, 25 Oct 2012 09:04:04 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q9PG3rJ2023413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 25 Oct 2012 18:03:53 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q9PG3rAN017651; Thu, 25 Oct 2012 18:03:53 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q9PG3n8H025777; Thu, 25 Oct 2012 18:03:53 +0200 Message-ID: <508962E5.3070306@gmail.com> Date: Thu, 25 Oct 2012 18:03:49 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: I-D Action: draft-kaiser-nd-pd-00.txt References: <20121015135008.32010.58361.idtracker@ietfa.amsl.com> <50868B52.9000105@gmail.com> In-Reply-To: <50868B52.9000105@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: draft-kaiser-nd-pd@tools.ietf.org, 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 16:04:05 -0000 Hello Brian, Thank you for the email. Please see below some comments. Le 23/10/2012 14:19, Brian E Carpenter a écrit : > I realised while reading this draft that I just don't understand > its operating model. It refers to the "requesting" router supplying > Prefix Collection and Prefix Information to the delegating router: > >> When requesting prefixes a requesting router MUST add for each >> requested prefix a Prefix Information in the Prefix Delegation option >> of the RS message. > > However, by definition the requesting router doesn't know what prefix(es) > it will be given. So surely all it can ask for is N unspecified prefixes > of given lengths? Right, this may be wrong. I checked the document and it misses, I think, something important. The first and most naïve request of a prefix by a Requesting Router should have all bits zero and maybe the prefix length 0, or around 64. Would this be ok? > It also says: > >> PC_ID: An unique identifier of the Prefix Collection. The >> PC_ID MUST be unique among all PC_ID known by the >> requesting router. > > How can the requesting router provide this in its REQ message? By guessing? I think the PC_ID is generated by the requesting router (not by the delegating router), just as with IA_ID, no? >> 11. Security Considerations >> >> TBD > > OK, but since a vehicular network is open to any one of millions of > unmanaged devices, this will need to be *very* convincing, especially > in preventing DOS. I agree. We currently try to understand these threats, and especially how they are specific to ND, to prefix delegation and to new flags we add. We may add more threat descritpion in the next versions of the draft. Alex > > Regards > Brian Carpenter > > > From brian.e.carpenter@gmail.com Thu Oct 25 11:25:55 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C33D21F895D for ; Thu, 25 Oct 2012 11:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.538 X-Spam-Level: X-Spam-Status: No, score=-101.538 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slKRYITtGsvo for ; Thu, 25 Oct 2012 11:25:54 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD7821F8958 for ; Thu, 25 Oct 2012 11:25:54 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so710821eaa.31 for ; Thu, 25 Oct 2012 11:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=SPxZaRXC1NbjY0ib7tY8OliW98bFllJtKyu9lIWUhsQ=; b=kKJHpLBiBniAbpRXHQpckxRc/9MTp9Gk4j2m2BTm+pcRcYfbu60GmTWX1b78TkmGwJ 9wxJ8ubivtia8NX1WTPG1+NHbZXovPwQ8gEIjqLosC0hZYQd9wd+MdZtaAtd3oA1ExnO XiUQVPxI5tacrwG8YSl/yhpFMD7YAvr8dyoIg25CVtR2dWuQkhMqs2kSlotwqB+D4YjY LuCf6jkkbdiDDjDn9omgD6W1stcvFX3wyVykpBlBrEUjifZrO25Eq8+5Wp7jx2gX0PVX MGnVG2NvysaYQau/Kl4GYphbPrmJe1g0xu+kmxPWvZ3LALBZHmU39YP860KF5h6MPIbL X0dw== Received: by 10.14.199.134 with SMTP id x6mr28265765een.31.1351189553742; Thu, 25 Oct 2012 11:25:53 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-218-61.as13285.net. [2.102.218.61]) by mx.google.com with ESMTPS id t7sm31809842eel.14.2012.10.25.11.25.50 (version=SSLv3 cipher=OTHER); Thu, 25 Oct 2012 11:25:51 -0700 (PDT) Message-ID: <50898436.1040401@gmail.com> Date: Thu, 25 Oct 2012 19:25:58 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: I-D Action: draft-kaiser-nd-pd-00.txt References: <20121015135008.32010.58361.idtracker@ietfa.amsl.com> <50868B52.9000105@gmail.com> <508962E5.3070306@gmail.com> In-Reply-To: <508962E5.3070306@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: draft-kaiser-nd-pd@tools.ietf.org, 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 18:25:55 -0000 On 25/10/2012 17:03, Alexandru Petrescu wrote: > Hello Brian, >=20 > Thank you for the email. Please see below some comments. >=20 > Le 23/10/2012 14:19, Brian E Carpenter a =C3=A9crit : >> I realised while reading this draft that I just don't understand >> its operating model. It refers to the "requesting" router supplying >> Prefix Collection and Prefix Information to the delegating router: >> >>> When requesting prefixes a requesting router MUST add for each >>> requested prefix a Prefix Information in the Prefix Delegation >>> option >>> of the RS message. >> >> However, by definition the requesting router doesn't know what prefix(= es) >> it will be given. So surely all it can ask for is N unspecified prefix= es >> of given lengths? >=20 > Right, this may be wrong. >=20 > I checked the document and it misses, I think, something important. The= > first and most na=C3=AFve request of a prefix by a Requesting Router sh= ould > have all bits zero and maybe the prefix length 0, or around 64. >=20 > Would this be ok? Wouldn't the request typically be for a /48 or a /56? If I'm renumbering an existing network, I will want a prefix that is no longer than what I already used. I wonder whether an expensive BMW will always request a shorter prefix than a Nissan Versa. >> It also says: >> >>> PC_ID: An unique identifier of the Prefix Collection. = The >>> PC_ID MUST be unique among all PC_ID known by th= e >>> requesting router. >> >> How can the requesting router provide this in its REQ message? By >> guessing? >=20 > I think the PC_ID is generated by the requesting router (not by the > delegating router), just as with IA_ID, no? Ah yes, I simply misread the text, sorry! Brian >=20 >>> 11. Security Considerations >>> >>> TBD >> >> OK, but since a vehicular network is open to any one of millions of >> unmanaged devices, this will need to be *very* convincing, especially >> in preventing DOS. >=20 > I agree. We currently try to understand these threats, and especially > how they are specific to ND, to prefix delegation and to new flags we a= dd. >=20 > We may add more threat descritpion in the next versions of the draft. >=20 > Alex >=20 >> >> Regards >> Brian Carpenter >> >> >> >=20 >=20 From otroan@employees.org Fri Oct 26 00:38:00 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A13621F8556 for ; Fri, 26 Oct 2012 00:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.272 X-Spam-Level: X-Spam-Status: No, score=-10.272 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBD0uOhqPq7C for ; Fri, 26 Oct 2012 00:37:59 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 903FE21F8468 for ; Fri, 26 Oct 2012 00:37:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgFADA9ilCQ/khR/2dsb2JhbABEhVC8ZoEIgh4BAQEDARIBClwFCwtGVwYTIodcBp0yoBWRdWEDm1yIbIFrgnE X-IronPort-AV: E=Sophos;i="4.80,653,1344211200"; d="scan'208";a="9117846" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 26 Oct 2012 07:37:58 +0000 Received: from [10.148.2.55] ([10.148.2.55]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9Q7bvDI012560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Oct 2012 07:37:58 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) Subject: Re: 6man IETF85 Call for agenda items From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <50892B65.6090302@gmail.com> Date: Fri, 26 Oct 2012 09:37:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50892B65.6090302@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1498) Cc: 6man chair <6man-chairs@tools.ietf.org>, Bob Hinden , IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 07:38:00 -0000 Alex, > If it fits within available space, I would like to request a short = slot to present Prefix Delegation extensions to ND : >=20 > "Prefix Delegation extension to Neighbor Discovery protocol" > draft-kaiser-nd-pd-00 > Speaker: Alexandru Petrescu, alexandru.petrescu@cea.fr > 5min(?) we do have time on the agenda. I've put in a 10 minute slot, so if you take 5 minutes presenting there = is 5 minutes for discussion as well. Best regards, Ole= From alexandru.petrescu@gmail.com Fri Oct 26 03:10:55 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAA521F84C6 for ; Fri, 26 Oct 2012 03:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.098 X-Spam-Level: X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jN0sPK82Cd1S for ; Fri, 26 Oct 2012 03:10:54 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB8421F84C4 for ; Fri, 26 Oct 2012 03:10:53 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q9QAAprk031029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Oct 2012 12:10:52 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q9QAAppI031759; Fri, 26 Oct 2012 12:10:51 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q9QAAlQL022456; Fri, 26 Oct 2012 12:10:51 +0200 Message-ID: <508A61A7.8000107@gmail.com> Date: Fri, 26 Oct 2012 12:10:47 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: I-D Action: draft-kaiser-nd-pd-00.txt References: <20121015135008.32010.58361.idtracker@ietfa.amsl.com> <50868B52.9000105@gmail.com> <508962E5.3070306@gmail.com> <50898436.1040401@gmail.com> In-Reply-To: <50898436.1040401@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: draft-kaiser-nd-pd@tools.ietf.org, 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 10:10:55 -0000 Le 25/10/2012 20:25, Brian E Carpenter a écrit : [...] >> I checked the document and it misses, I think, something important. >> The first and most naïve request of a prefix by a Requesting Router >> should have all bits zero and maybe the prefix length 0, or around >> 64. >> >> Would this be ok? > > Wouldn't the request typically be for a /48 or a /56? If I'm > renumbering an existing network, I will want a prefix that is no > longer than what I already used. The 'end' router in a Leaf Vehicle would probably need 1 or 2 /64 for its own in-vehicle links. Or maybe a single /63 to make these 2 /64s our of it. Or similar. This MR-LV would not sub-delegate to other vehicles. On another hand, the router in an Internet Vehicle IV would use DHCPv6-Prefix-Delegation to obtain an as short prefix as possible (/48, /56) because it knows it would 'sub-delegate' to other LVs - it has dedicated interfaces for that. > I wonder whether an expensive BMW will always request a shorter > prefix than a Nissan Versa. That is an excellent comment. The IV would have a SIM card with precise billing scheme; existing more expensive cars have higher subscription plans. One would expect a large BMW connected to e.g. T-Mobile to be more likely to obtain a shorter prefix (or several longer prefixes) than a cheaper car. On another hand, the LV without a SIM would be subject to more flexible billing plans, like with free-access WiFi but advertisement, and where the notion of longer or shorter prefix would less be related to the cost of the vehicle. I think the ND-PD happening between IV and LV would not put restrictions on the length of prefix requested or allocated. Let me add the the size and cost of vehicle is not much related to how much electronics and computers it has inside. Smaller vehicles are more and more automated and full of devices. Also, it may be that new small vehicles coming out these days have much more computers inside than an older but large and comfortable sedan. Alex >>> It also says: >>> >>>> PC_ID: An unique identifier of the Prefix Collection. >>>> The PC_ID MUST be unique among all PC_ID known by the >>>> requesting router. >>> >>> How can the requesting router provide this in its REQ message? >>> By guessing? >> >> I think the PC_ID is generated by the requesting router (not by >> the delegating router), just as with IA_ID, no? > > Ah yes, I simply misread the text, sorry! > > Brian > >> >>>> 11. Security Considerations >>>> >>>> TBD >>> >>> OK, but since a vehicular network is open to any one of millions >>> of unmanaged devices, this will need to be *very* convincing, >>> especially in preventing DOS. >> >> I agree. We currently try to understand these threats, and >> especially how they are specific to ND, to prefix delegation and to >> new flags we add. >> >> We may add more threat descritpion in the next versions of the >> draft. >> >> Alex >> >>> >>> Regards Brian Carpenter >>> >>> >>> >> >> > > > From thierry.ernst@inria.fr Sat Oct 27 07:26:28 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6E621F86C8 for ; Sat, 27 Oct 2012 07:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.692 X-Spam-Level: X-Spam-Status: No, score=-9.692 tagged_above=-999 required=5 tests=[AWL=0.512, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBsm6vpiJc-M for ; Sat, 27 Oct 2012 07:26:27 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id 2504821F853A for ; Sat, 27 Oct 2012 07:26:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,662,1344204000"; d="vcf'?scan'208,217";a="179194476" Received: from roc086r.vpn.inria.fr (HELO Mont-Ventoux.local) ([128.93.183.86]) by mail1-relais-roc.national.inria.fr with ESMTP; 27 Oct 2012 16:26:23 +0200 Message-ID: <508BA9C3.9070905@inria.fr> Date: Sat, 27 Oct 2012 11:30:43 +0200 From: Thierry Ernst Organization: INRIA User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Announcing Prefix Delegation extensions to ND draft-kaiser-nd-pd-00.txt References: <5081087D.2020807@gmail.com> <5082C948.3080109@gmail.com> <5082E933.60205@gmail.com> <50831CF0.7050106@inria.fr> <50857A63.3030102@gmail.com> In-Reply-To: Content-Type: multipart/mixed; boundary="------------000105030108090500050707" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2012 14:26:29 -0000 This is a multi-part message in MIME format. --------------000105030108090500050707 Content-Type: multipart/alternative; boundary="------------020701090806070900070504" --------------020701090806070900070504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Many thanks to John for his post. Yes, what is the problem we are trying to solve here ? With NEMO, there is no problem related to changing IP addresses ? NEMO is the solution for that. The in-vehicle router would still get a new CoA while in the in-vehicle nodes would keep the prefix initially allocated. This is the solution adopted by ISO TC204 (technical committee working on ITS), see the published standard ISO 21210. This is also what is being experimented in ITS field operational tests. Of course, with a solution like NEMO the route is not optimized, but the scenarios currently being considered for deployment from the automotive industry wouldn't require direct routing between two vehicles nor would require optimized routing between a vehicle and a correspondent in the Internet. The scenarios where we really need direct communications are when an in-vehicle node need to speak with a roadside node that is attached to the access router. Other scenarios depicted by Alexandru are good for research. For the scenario involving the roadside and the vehicle, the prefix can be exchanged as proposed by Lee (draft-jhlee-mext-mnpp). The solution from Lee is being integrated in the ISO TC204 standards related to ISO 21210. Regards, Thierry. On 24/10/12 02:56, John Mann wrote: > Hi, > > > On 23 October 2012 03:54, Alexandru Petrescu > > > wrote: > > Le 20/10/2012 23:51, Thierry Ernst a écrit : > > > Dear Alex, > > Would you explain why the vehicle would need to get a new > prefix (and > thus I assume configure all the nodes in the vehicle) every > time it > enters a new area ? > > > Well, whenever MR of a vehicle changes its attachment point it > would get > a new different address, right? I can only suppose it would get a > different delegated prefix as well. It's hard to imagine that it > would > get a different address but a same delegated prefix, no? (it's hard to > make same prefix valid at so many different places, harder than > doing it > with addresses and it's not done with them). > > Or do you ask why LV gets a new prefix when IV changes its prefix? I > think this is obvious, no? (for topological correctness, right?) > > Or do you ask from the NEMO perspective? > > In this V2V2I work we first consider there's no MIP nor NEMO > neither on > IV nor on LV. We'll see later about adding MIP. We can discuss it as > well, see how MIP would fit in this. > > Is this answering in the direction you made the question? > > Alex > > > I'm confused about what problems are being solved / created here. > > I assume V2V2I is vehicle-to-vehicle-to-Internet. > > Why do you _want_ the LFN end devices to change IPv6 address as the > vehicles move around? > > How about if you one-off assign prefixes to the in-car subnets, and > then one-off assign host addresses to the LFNs. > Then use tunnels / NEMO / Proxy MIPv6 / whatever to connect the cars > to the Internet. > The LFNs having stable addresses would facilitate connections to and > from the Internet. > > Is there some soft of association between IVs and LVs? > - are they owned / managed by the same people? > - is there guaranteed to always be a IV in range of every LV? > - are the IV's happy that the LVs are using their bandwidth to the > Internet? > - is there any need for the LFNs on IVs and LVs to communicate with > each other? locally? > Do e.g. cellular or satellite networks used for connecting IVs to the > Internet give out different IPv6 address or delegate different > prefixes as you move around? > Or does it take a roam plus a "reboot" to get a new address and prefix? > > Thanks, > John > > > > Thierry > > > On 20/10/12 20:10, Alexandru Petrescu wrote: > > Le 20/10/2012 18:42, Mikael Abrahamsson a écrit : > > On Sat, 20 Oct 2012, Alexandru Petrescu wrote: > > One point that guided towards choosing ND over DHCP is > topology. DHCP topology can be relatively complex with > Client/Relay/Server, whereas ND is simpler one-on-one. > > > There is nothing saying DHCPv6-PD can't be done in a > single > device (the router itself). That's what I do in my > home, cisco > router, local DHCPv6-PD pool, local DHCPv6-PD server, also > installing routes into RIB. > > > YEs, because at home one typically puts up the interface > once a > month and gets typically the same prefix from ADSL > operator as 1 > year before. > > But with vehicles, one connects a vehicle here and gets a > prefix, > then moves in that area and gets another prefix. At that > point, if > the router obtaining a prefix wants to delegate further to > another > vehicle needs to change the delegated prefix. > > This dynamic change between the received prefix and the > delegated > prefix is not a matter of DHCP. It can be implemented by like > scripting which are independent of DHCP implementation. > One has to > touch the conf files be it of DHCP or of ND. > > _and_ Relay (or Server). This may be feasible in > practice but > I think it would be cleaner to have distinct > protocols on a > same machine for receiving a prefix and for > sending a prefix. > > > What is cleaner is to use existing standards where > there already > is running code. > > > Right, there is cleanliness in reuse. Reuse as much as > possible. > > There is also the question of availability of DHCP > software on > smaller platforms which have no SIM card. It may > be easier to > do this with ND in smaller settings. > > > I'd imagine that there already are 2-3 existing FOSS > available > implementations that do what you need for DHCPv6-PD > client and > server. Instead you want to invent a new standard and > create new > code. > > > In addition to FOSS (what is FOSS?) DHCP one also needs to > dynamically change the delegated prefix when the assigned > prefix > changed. > > I'm not saying this shouldn't be done, I'm just saying > I don't > really see the rationale for it. I used to hate DHCPv6 > role in > IPv6, but after a few years of being exposed to it, > I've come to > accept that this is the way it is. There is code going > back to a > standard Windows Vista that correctly implements DHCPv6-PD > client, and that is what, 5-6 years ago it was > released? I've had > PD in my home on Cisco code for 3-5 years already, > with no server > infrastructure at all, just single device doing > "everything" for > the role needed. > > If this was 2002, I'd agree with you that ND PD could be > feasable, but I believe the train has already left the > station > and we should focus on keeping IPv6 stable when it > comes to how > it works, and get implementations going, not new > standards. > > > WEll yes, I agree that IPv6 should be kept stable and part > of that > may be that we try to make sure that a new proposal does > not break > existing implementation. This is a matter of further work. > > Alex > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > ipv6@ietf.org Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org > Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --------------020701090806070900070504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Many thanks to John for his post. Yes, what is the problem we are trying to solve here ? With NEMO, there is no problem related to changing IP addresses ? NEMO is the solution for that. The in-vehicle router would still get a new CoA while in the in-vehicle nodes would keep the prefix initially allocated. This is the solution adopted by ISO TC204 (technical committee working on ITS), see the published standard ISO 21210. This is also what is being experimented in ITS field operational tests.

Of course, with a solution like NEMO the route is not optimized, but the scenarios currently being considered for deployment from the automotive industry wouldn't require direct routing between two vehicles nor would require optimized routing between a vehicle and a correspondent in the Internet. The scenarios where we really need direct communications are when an in-vehicle node need to speak with a roadside node that is attached to the access router. Other scenarios depicted by Alexandru are good for research.

For the scenario involving the roadside and the vehicle, the prefix can be exchanged as proposed by Lee (draft-jhlee-mext-mnpp). The solution from Lee is being integrated in the ISO TC204 standards related to ISO 21210.

Regards,
Thierry.





On 24/10/12 02:56, John Mann wrote:
Hi,


On 23 October 2012 03:54, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
Le 20/10/2012 23:51, Thierry Ernst a écrit :


Dear Alex,

Would you explain why the vehicle would need to get a new prefix (and
 thus I assume configure all the nodes in the vehicle) every time it
 enters a new area ?

Well, whenever MR of a vehicle changes its attachment point it would get
a new different address, right?  I can only suppose it would get a
different delegated prefix as well.  It's hard to imagine that it would
get a different address but a same delegated prefix, no? (it's hard to
make same prefix valid at so many different places, harder than doing it
with addresses and it's not done with them).

Or do you ask why LV gets a new prefix when IV changes its prefix?  I
think this is obvious, no? (for topological correctness, right?)

Or do you ask from the NEMO perspective?

In this V2V2I work we first consider there's no MIP nor NEMO neither on
IV nor on LV.  We'll see later about adding MIP.  We can discuss it as
well, see how MIP would fit in this.

Is this answering in the direction you made the question?

Alex

I'm confused about what problems are being solved / created here.

I assume V2V2I is vehicle-to-vehicle-to-Internet.

Why do you _want_ the LFN end devices to change IPv6 address as the vehicles move around?

How about if you one-off assign prefixes to the in-car subnets, and then one-off assign host addresses to the LFNs.
Then use tunnels / NEMO / Proxy MIPv6 / whatever to connect the cars to the Internet.
The LFNs having stable addresses would facilitate connections to and from the Internet.

Is there some soft of association between IVs and LVs?  
- are they owned / managed by the same people?
- is there guaranteed to always be a IV in range of every LV?
- are the IV's happy that the LVs are using their bandwidth to the Internet?
- is there any need for the LFNs on IVs and LVs to communicate with each other? locally?
 
Do e.g. cellular or satellite networks used for connecting IVs to the Internet give out different IPv6 address or delegate different prefixes as you move around?
Or does it take a roam plus a "reboot" to get a new address and prefix?

Thanks,
    John



Thierry


On 20/10/12 20:10, Alexandru Petrescu wrote:
Le 20/10/2012 18:42, Mikael Abrahamsson a écrit :
On Sat, 20 Oct 2012, Alexandru Petrescu wrote:

One point that guided towards choosing ND over DHCP is
topology. DHCP topology can be relatively complex with
Client/Relay/Server, whereas ND is simpler one-on-one.

There is nothing saying DHCPv6-PD can't be done in a single
device (the router itself). That's what I do in my home, cisco
router, local DHCPv6-PD pool, local DHCPv6-PD server, also
installing routes into RIB.

YEs, because at home one typically puts up the interface once a
month and gets typically the same prefix from ADSL operator as 1
year before.

But with vehicles, one connects a vehicle here and gets a prefix,
then moves in that area and gets another prefix.  At that point, if
the router obtaining a prefix wants to delegate further to another
vehicle needs to change the delegated prefix.

This dynamic change between the received prefix and the delegated
prefix is not a matter of DHCP.  It can be implemented by like
scripting which are independent of DHCP implementation.  One has to
touch the conf files be it of DHCP or of ND.

_and_ Relay (or Server).  This may be feasible in practice but
I think it would be cleaner to have distinct protocols on a
same machine for receiving a prefix and for sending a prefix.

What is cleaner is to use existing standards where there already
is running code.

Right, there is cleanliness in reuse.  Reuse as much as possible.

There is also the question of availability of DHCP software on
smaller platforms which have no SIM card.  It may be easier to
do this with ND in smaller settings.

I'd imagine that there already are 2-3 existing FOSS available
implementations that do what you need for DHCPv6-PD client and
server. Instead you want to invent a new standard and create new
code.

In addition to FOSS (what is FOSS?) DHCP one also needs to
dynamically change the delegated prefix when the assigned prefix
changed.

I'm not saying this shouldn't be done, I'm just saying I don't
really see the rationale for it. I used to hate DHCPv6 role in
IPv6, but after a few years of being exposed to it, I've come to
accept that this is the way it is. There is code going back to a
standard Windows Vista that correctly implements DHCPv6-PD
client, and that is what, 5-6 years ago it was released? I've had
PD in my home on Cisco code for 3-5 years already, with no server
infrastructure at all, just single device doing "everything" for
the role needed.

If this was 2002, I'd agree with you that ND PD could be
feasable, but I believe the train has already left the station
and we should focus on keeping IPv6 stable when it comes to how
it works, and get implementations going, not new standards.

WEll yes, I agree that IPv6 should be kept stable and part of that
may be that we try to make sure that a new proposal does not break
existing implementation.  This is a matter of further work.

Alex

--------------------------------------------------------------------


IETF IPv6 working group mailing list
ipv6@ietf.org Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------




--------------------------------------------------------------------
IETF IPv6 working group mailing list ipv6@ietf.org Administrative
Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--------------020701090806070900070504-- --------------000105030108090500050707 Content-Type: text/x-vcard; charset=utf-8; name="thierry_ernst.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="thierry_ernst.vcf" begin:vcard fn:Thierry Ernst n:Ernst;Thierry org:INRIA - Project Team IMARA - LaRA JRU tel;work:+33 1 3963 59 30 tel;fax:+33 1 39 63 54 91 tel;cell:+33 6 76 56 25 96 url:http://www.lara.prd.fr version:2.1 end:vcard --------------000105030108090500050707-- From brian@innovationslab.net Sat Oct 27 08:41:19 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4E821F849E for ; Sat, 27 Oct 2012 08:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.403 X-Spam-Level: X-Spam-Status: No, score=-102.403 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUpaPf9ZnEG6 for ; Sat, 27 Oct 2012 08:41:18 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id DA30F21F846A for ; Sat, 27 Oct 2012 08:41:18 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id BBADE88168 for ; Sat, 27 Oct 2012 08:41:18 -0700 (PDT) Received: from clemson.local (c-69-140-213-249.hsd1.md.comcast.net [69.140.213.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 7C21D14003D for ; Sat, 27 Oct 2012 08:41:18 -0700 (PDT) Message-ID: <508C009F.5070500@innovationslab.net> Date: Sat, 27 Oct 2012 11:41:19 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: ID Tracker State Update Notice: References: <20121011180909.5356.68505.idtracker@ietfa.amsl.com> In-Reply-To: <20121011180909.5356.68505.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2012 15:41:19 -0000 All, The messages to the mailing list that have a Subject: that starts with "ID Tracker State Update Notice" are generated by the Datatracker when the state of a document changes. Normally, these messages are sent to WG chairs, draft authors, responsible AD, and any AD holding a Discuss position on the draft. I had added the WG mailing list to the distribution at the request of a chair. However, there have been several complaints about these notifications going to the mailing list. Given those complaints, I am removing the WG mailing list from the notification list for the 6MAN documents currently being considered by the IESG for publication. I will leave it to the discretion of the chairs and authors as to when the WG should be made aware of a document's status change. Regards, Brian On 10/11/12 2:09 PM, IETF Secretariat wrote: > State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation > ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From otroan@employees.org Mon Oct 29 11:46:54 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB5C21F8711 for ; Mon, 29 Oct 2012 11:46:54 -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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhzA8xRdjhqE for ; Mon, 29 Oct 2012 11:46:53 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4D73721F86E7 for ; Mon, 29 Oct 2012 11:46:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAEnOjlCQ/khL/2dsb2JhbABEwwKBCII3ASc/gT41h2ScEJ90kXFhA5tdiG6Ba4Jw X-IronPort-AV: E=Sophos;i="4.80,673,1344211200"; d="scan'208";a="77846868" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 29 Oct 2012 18:46:52 +0000 Received: from [10.61.99.118] (dhcp-10-61-99-118.cisco.com [10.61.99.118]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9TIkpPI017740 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Oct 2012 18:46:52 GMT From: =?iso-8859-1?Q?Ole_Tr=F8an?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: IETF85: Move 6man to Tuesday? Date: Mon, 29 Oct 2012 19:46:51 +0100 Message-Id: To: IPv6 List Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) X-Mailer: Apple Mail (2.1498) Cc: Brian Haberman , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 18:46:54 -0000 All, there is a suggestion by our AD to move the 6man session from Monday = morning to Tuesday morning. this is to allow Apps people to participate in the discussion on the URI = draft. If anyone has strong objections to moving the session to Tuesday, please = let us know. Best regards, Ole & Bob= From tjc@ecs.soton.ac.uk Mon Oct 29 12:56:58 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83FD521F85E4 for ; Mon, 29 Oct 2012 12:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxqB03DPC0HO for ; Mon, 29 Oct 2012 12:56:58 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id AB31621F85E0 for ; Mon, 29 Oct 2012 12:56:56 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9TJukrU004018; Mon, 29 Oct 2012 19:56:46 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q9TJukrU004018 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1351540608; bh=9yOwkv00k2L/YimjT4oYkNETfU0=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=UrRfjLPn3af8bsBk36p3IAbTQQS547sFDS4eXXDc77snxA00Vfv0m+W6uddYRzOH9 NKMUJc02QmuUOPOW8oyKGoroWe8e5s5Nh9F1Lk53meCmLKtPzdCcaKM+Ks/oPkhdS7 F3k081gVzF+roTRGdy6+0H63MrsvNfAc6T3wiRxU= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id o9SJuk0430604895el ret-id none; Mon, 29 Oct 2012 19:56:48 +0000 Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9TJtQQh021135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Oct 2012 19:55:26 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: IETF85: Move 6man to Tuesday? From: Tim Chown In-Reply-To: Date: Mon, 29 Oct 2012 19:55:26 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <326B8FE0-3C98-4EE7-840D-5387E48165C4@ecs.soton.ac.uk> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o9SJuk043060489500; tid=o9SJuk0430604895el; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q9TJukrU004018 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: Bob Hinden , Brian Haberman , IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 19:56:58 -0000 On 29 Oct 2012, at 18:46, Ole Tr=F8an wrote: > All, >=20 > there is a suggestion by our AD to move the 6man session from Monday = morning to Tuesday morning. > this is to allow Apps people to participate in the discussion on the = URI draft. >=20 > If anyone has strong objections to moving the session to Tuesday, = please let us know. That would cause a clash with SDN, which is a very popular session (one = of the biggest three room requests). Tim= From gorry@erg.abdn.ac.uk Tue Oct 30 00:38:11 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C519721F8461 for ; Tue, 30 Oct 2012 00:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.885 X-Spam-Level: X-Spam-Status: No, score=-99.885 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7miEJ3keh7w for ; Tue, 30 Oct 2012 00:38:10 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id C5B3B21F8460 for ; Tue, 30 Oct 2012 00:38:10 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 7DD612B4356; Tue, 30 Oct 2012 07:38:08 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Tue, 30 Oct 2012 07:38:08 -0000 Message-ID: In-Reply-To: References: Date: Tue, 30 Oct 2012 07:38:08 -0000 Subject: Re: IETF85: Move 6man to Tuesday? From: gorry@erg.abdn.ac.uk To: =?iso-8859-1?Q?=22Ole_Tr=F8an=22?= User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Bob Hinden , Brian Haberman , IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 07:38:11 -0000 My thoughts are: This moves to clash with TCPM, where I have a draft and is a busy meeting for me. Gorry > All, > > there is a suggestion by our AD to move the 6man session from Monday > morning to Tuesday morning. > this is to allow Apps people to participate in the discussion on the URI > draft. > > If anyone has strong objections to moving the session to Tuesday, please > let us know. > > Best regards, > Ole & Bob > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From brian.e.carpenter@gmail.com Tue Oct 30 00:58:41 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A16B21F84CF for ; Tue, 30 Oct 2012 00:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.466 X-Spam-Level: X-Spam-Status: No, score=-101.466 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rL3AgFQYSkkJ for ; Tue, 30 Oct 2012 00:58:40 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC0921F84C8 for ; Tue, 30 Oct 2012 00:58:39 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so2449634wib.13 for ; Tue, 30 Oct 2012 00:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xekbZkFc8QAkOthmZwFQcSe0xbHksGhqc/8TUOLDZ48=; b=r55QA8yb2jIXZAFPfXmYAGQntArkYDDMxCSMCoM+r0WZjB3pqwFRe6VMBobg3KfFKv XfUnJTMKoojyVhcw7aINLLoKqklAwDcR1Avxg8gsYUlfxtO/qNSgJc/eV0BbBZiv8fIm f5ByebTVKlF1gEPpyFO4Kv5XyKaBo1ACcOp2eH2WITUkbE5IEUdAXeO2sKXEkjEtyQfH x7xFc3BkLsZsgKETAGrB8+oPX9iIVC0LC5yhu/JXAUKFT5ItHlCX7tmhh6EaO8dwugi2 +NvnVdEGZw5hatZF1sK5IWSy68b44lVQItQ6BI172d71/Cy4Gg5aDGBFwH7w8OORox+6 JLmg== Received: by 10.180.106.2 with SMTP id gq2mr1148777wib.18.1351583919107; Tue, 30 Oct 2012 00:58:39 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-66.as13285.net. [2.102.217.66]) by mx.google.com with ESMTPS id bn7sm9258wib.8.2012.10.30.00.58.36 (version=SSLv3 cipher=OTHER); Tue, 30 Oct 2012 00:58:37 -0700 (PDT) Message-ID: <508F88AD.5060305@gmail.com> Date: Tue, 30 Oct 2012 07:58:37 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?T2xlIFRyw7hhbg==?= Subject: Re: IETF85: Move 6man to Tuesday? References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Bob Hinden , Brian Haberman , IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 07:58:41 -0000 On 29/10/2012 18:46, Ole Tr=C3=B8an wrote: > All, >=20 > there is a suggestion by our AD to move the 6man session from Monday mo= rning to Tuesday morning. > this is to allow Apps people to participate in the discussion on the UR= I draft. >=20 > If anyone has strong objections to moving the session to Tuesday, pleas= e let us know. As Tim noted, the collision with IRTF/SDN is unfortunate, but also, I don= 't see how we can deal with this in a 15 minute slot. The point is to discus= s an unknown objection with Apps people who have presumably not followed th= e preceding discussion at all. If we get a written explanation of the objection in advance, we could hav= e a useful discussion in the time available. Brian > Best regards, > Ole & Bob > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From tjc@ecs.soton.ac.uk Tue Oct 30 04:17:12 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF0521F8511 for ; Tue, 30 Oct 2012 04:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+fA93KJJ4KX for ; Tue, 30 Oct 2012 04:17:12 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id B559521F84DA for ; Tue, 30 Oct 2012 04:17:11 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9UBH5gc010320; Tue, 30 Oct 2012 11:17:05 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q9UBH5gc010320 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1351595826; bh=1KyN1v1ihEDzo6H7WMLUPDVYHb8=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=XUeAdNlIMSevdRKgFww46yVcEO61h27287wj6GTzCUA3ZDceVoftTLV56n7895ext irlJzQI+BMsaC4gXJrhWpeagfL/3fDYnaeZqKGgdRgNjq2SOfFsTq0bxFyQcdyvXpT VxLwIL74RafvYT4EV0FIpmlpMdEAI5kS/NiShN6g= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id o9YBH504306090800s ret-id none; Tue, 30 Oct 2012 11:17:06 +0000 Received: from ip-204-027.eduroam.soton.ac.uk (ip-204-027.eduroam.soton.ac.uk [152.78.204.27]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9UBH0ii002219 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 30 Oct 2012 11:17:00 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: IETF85: Move 6man to Tuesday? From: Tim Chown In-Reply-To: <508F88AD.5060305@gmail.com> Date: Tue, 30 Oct 2012 11:17:10 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <508F88AD.5060305@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o9YBH5043060908000; tid=o9YBH504306090800s; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=5:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q9UBH5gc010320 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: IPv6 List , Bob Hinden , Brian Haberman X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 11:17:12 -0000 On 30 Oct 2012, at 07:58, Brian E Carpenter = wrote: > On 29/10/2012 18:46, Ole Tr=F8an wrote: >> All, >>=20 >> there is a suggestion by our AD to move the 6man session from Monday = morning to Tuesday morning. >> this is to allow Apps people to participate in the discussion on the = URI draft. >>=20 >> If anyone has strong objections to moving the session to Tuesday, = please let us know. >=20 > As Tim noted, the collision with IRTF/SDN is unfortunate, but also, I = don't > see how we can deal with this in a 15 minute slot. The point is to = discuss > an unknown objection with Apps people who have presumably not followed = the > preceding discussion at all. Well, it's "unfortunate" in that I'd have to miss 6man, when I have an = active draft being presented there. But I also have no idea how many = other people are in my boat, or how many apps people want 6man moved. > If we get a written explanation of the objection in advance, we could = have > a useful discussion in the time available. That sounds prudent.=20 It's not like we have a whole subject area clash here, as would be the = case with homenet and 6man, rather we seem to be proposing this = significant schedule change that would put two of the biggest WG = sessions in the same slot in order to allow people to take part in a = 10-minute discussion (assuming it's draft-ietf-appsawg-acct-uri on the = APPSAWG agenda)? Is it possible to schedule of individual items in each WG that people = who want to pop to APPSAWG can do so for those 10 minutes? Tim= From cabo@tzi.org Tue Oct 30 04:24:36 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA91021F8550 for ; Tue, 30 Oct 2012 04:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.974 X-Spam-Level: X-Spam-Status: No, score=-106.974 tagged_above=-999 required=5 tests=[AWL=-0.725, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQPIPICBQzPv for ; Tue, 30 Oct 2012 04:24:36 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 06EEF21F854F for ; Tue, 30 Oct 2012 04:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q9UBOQ5m029325; Tue, 30 Oct 2012 12:24:26 +0100 (CET) Received: from [192.168.217.105] (p54891A96.dip.t-dialin.net [84.137.26.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2D06C432; Tue, 30 Oct 2012 12:24:26 +0100 (CET) Subject: Re: IETF85: Move 6man to Tuesday? Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Tue, 30 Oct 2012 12:24:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <44DA8F20-A441-4E90-B910-74CBD5B23DC4@tzi.org> References: <508F88AD.5060305@gmail.com> To: Tim Chown X-Mailer: Apple Mail (2.1499) Cc: Bob Hinden , Brian Haberman , IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 11:24:36 -0000 On Oct 30, 2012, at 12:17, Tim Chown wrote: > apps people ... that care about URIs and the Web are going to be in HTTPBIS anyway. Instead, leave 6man where it is and synchronize with the AOB slot of the = appsarea meeting on Monday. Gr=FC=DFe, Carsten From rdroms.ietf@gmail.com Tue Oct 30 04:59:35 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF6521F857E for ; Tue, 30 Oct 2012 04:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.901 X-Spam-Level: X-Spam-Status: No, score=-102.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKX86tZfdnUY for ; Tue, 30 Oct 2012 04:59:35 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 623A821F854E for ; Tue, 30 Oct 2012 04:59:31 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id b25so122707qca.31 for ; Tue, 30 Oct 2012 04:59:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=kkouq+Xql5zfL19iTHfnIwJCSKiNerbZI8/ZgqxufDE=; b=LQDaQIhFlPqp6cxQcyHEJLOtIgO7JidjmwZhmGG8kdoKiAixVfuFBhW0dHNUhmc+4F 0czHl46vGxwPQGftZh+fLso1TRqD6DPla0TJaFl0foYRt6e725+Cco/TG8utlxjaI8Ej KU/P49TQQzXn5MrX7WnbRyK/vBYwF5Ex58JtolN3R26HdkTiKPGbrX5NIhD/rHarnbxv x+JieXBf158j5wnmilVP6UDSs3kavHdhoZhd0RcT6UJXGEnDPdySNL2mN+nL7smFQbZ0 HFLVxQE7ubfIEsmGwV0zc44xjUW8VV9Mqzf5frbx04rILT/vzDhHChmYedCzaSaYxnVp KRfQ== Received: by 10.49.82.113 with SMTP id h17mr25174128qey.24.1351598370868; Tue, 30 Oct 2012 04:59:30 -0700 (PDT) Received: from [192.168.1.114] (c-24-62-106-121.hsd1.ma.comcast.net. [24.62.106.121]) by mx.google.com with ESMTPS id t14sm127526qef.3.2012.10.30.04.59.29 (version=SSLv3 cipher=OTHER); Tue, 30 Oct 2012 04:59:30 -0700 (PDT) References: <508F88AD.5060305@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <8CC033A1-7EF3-4771-BE24-D5E2179A7F48@gmail.com> X-Mailer: iPhone Mail (10A405) From: Ralph Droms Subject: Re: IETF85: Move 6man to Tuesday? Date: Tue, 30 Oct 2012 07:59:28 -0400 To: Tim Chown Cc: Bob Hinden , Brian Haberman , IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 11:59:35 -0000 On Oct 30, 2012, at 7:17 AM, Tim Chown wrote: >=20 > On 30 Oct 2012, at 07:58, Brian E Carpenter w= rote: >=20 >> On 29/10/2012 18:46, Ole Tr=C3=B8an wrote: >>> All, >>>=20 >>> there is a suggestion by our AD to move the 6man session from Monday mor= ning to Tuesday morning. >>> this is to allow Apps people to participate in the discussion on the URI= draft. >>>=20 >>> If anyone has strong objections to moving the session to Tuesday, please= let us know. >>=20 >> As Tim noted, the collision with IRTF/SDN is unfortunate, but also, I don= 't >> see how we can deal with this in a 15 minute slot. The point is to discus= s >> an unknown objection with Apps people who have presumably not followed th= e >> preceding discussion at all. >=20 > Well, it's "unfortunate" in that I'd have to miss 6man, when I have an act= ive draft being presented there. But I also have no idea how many other peop= le are in my boat, or how many apps people want 6man moved. >=20 >> If we get a written explanation of the objection in advance, we could hav= e >> a useful discussion in the time available. >=20 > That sounds prudent.=20 And preliminary discussion on the 6man mailing list would enable most effici= ent use of meeting time in Atlanta. - Ralph >=20 > It's not like we have a whole subject area clash here, as would be the cas= e with homenet and 6man, rather we seem to be proposing this significant sch= edule change that would put two of the biggest WG sessions in the same slot i= n order to allow people to take part in a 10-minute discussion (assuming it'= s draft-ietf-appsawg-acct-uri on the APPSAWG agenda)? >=20 > Is it possible to schedule of individual items in each WG that people who w= ant to pop to APPSAWG can do so for those 10 minutes? >=20 > Tim > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From bob.hinden@gmail.com Wed Oct 31 09:59:20 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482A421F8634 for ; Wed, 31 Oct 2012 09:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.398 X-Spam-Level: X-Spam-Status: No, score=-103.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+bziNb3fj5X for ; Wed, 31 Oct 2012 09:59:19 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 32F4921F8605 for ; Wed, 31 Oct 2012 09:59:18 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so772173bkc.31 for ; Wed, 31 Oct 2012 09:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=nUArnrsPA55CQC65mp+JXM7oP51caeF9pDI+5Spkwlw=; b=iOD4PeejztUb0TVDbXwwLmoBHFj2qI1YANdhzi9aPcRP0Yr5xH5zqkdg+eosmLpmSN n8d8KqdK4bhieCTTmJ0HvWAjSCiPH+O/LaPDfS/TjubqzaP/CXmZt2yi/RHp8Y9+3hvT HPLiF4910bHVHo53cNqxZK/Usu7+TtWo6EEtkJUaScI+bN7RBKxUmcWuByj32Hp32/1y x4FuFZ1c/34iRzgZwvMCnahWjaT7I/dyEW4738SEgWjTcSBb8qRyMK9ffCti/UhvHZwb jRMH4sORk2dT8MAl+Ou/tpeuF0ECZlIvah9/ziQ9BhDYv+8CC/NADli0xTKLNdnOT3pS NaNA== Received: by 10.204.148.146 with SMTP id p18mr11777189bkv.51.1351702757849; Wed, 31 Oct 2012 09:59:17 -0700 (PDT) Received: from [10.0.0.38] (c-24-130-151-138.hsd1.ca.comcast.net. [24.130.151.138]) by mx.google.com with ESMTPS id e3sm3944748bks.7.2012.10.31.09.59.16 (version=SSLv3 cipher=OTHER); Wed, 31 Oct 2012 09:59:17 -0700 (PDT) Subject: Re: IETF85: Move 6man to Tuesday? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Bob Hinden In-Reply-To: Date: Wed, 31 Oct 2012 09:59:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <17AA82D7-726F-40B5-9A07-8117290EC7B1@gmail.com> References: To: IPv6 List X-Mailer: Apple Mail (2.1283) Cc: Bob Hinden , Brian Haberman X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 16:59:20 -0000 The 6MAN session will remain on Monday morning at 9am. Bob On Oct 29, 2012, at 11:46 AM, Ole Tr=F8an wrote: > All, >=20 > there is a suggestion by our AD to move the 6man session from Monday = morning to Tuesday morning. > this is to allow Apps people to participate in the discussion on the = URI draft. >=20 > If anyone has strong objections to moving the session to Tuesday, = please let us know. >=20 > Best regards, > Ole & Bob